1Name 2 3 OES_tessellation_shader 4 5Name Strings 6 7 GL_OES_tessellation_shader 8 GL_OES_tessellation_point_size 9 10Contact 11 12 Jon Leech (oddhack 'at' sonic.net) 13 Daniel Koch, NVIDIA (dkoch 'at' nvidia.com) 14 15Contributors 16 17 Daniel Koch, NVIDIA (dkoch 'at' nvidia.com) 18 Pat Brown, NVIDIA (pbrown 'at' nvidia.com) 19 Bill Licea-Kane, Qualcomm (billl 'at' qti.qualcomm.com) 20 Jesse Hall, Google (jessehall 'at' google.com) 21 Dominik Witczak, Mobica 22 Jan-Harald Fredriksen, ARM 23 Maurice Ribble, Qualcomm 24 Vineet Goel, Qualcomm 25 Alex Chalfin, ARM 26 Graham Connor, Imagination 27 Ben Bowman, Imagination 28 Jonathan Putsman, Imagination 29 Slawomir Grajewski, Intel 30 Contributors to ARB_tessellation_shader 31 32Notice 33 34 Copyright (c) 2010-2016 The Khronos Group Inc. Copyright terms at 35 http://www.khronos.org/registry/speccopyright.html 36 37Specification Update Policy 38 39 Khronos-approved extension specifications are updated in response to 40 issues and bugs prioritized by the Khronos OpenGL ES Working Group. For 41 extensions which have been promoted to a core Specification, fixes will 42 first appear in the latest version of that core Specification, and will 43 eventually be backported to the extension document. This policy is 44 described in more detail at 45 https://www.khronos.org/registry/OpenGL/docs/update_policy.php 46 47 Portions Copyright (c) 2013-2014 NVIDIA Corporation. 48 49Status 50 51 Approved by the OpenGL ES Working Group 52 Ratified by the Khronos Board of Promoters on November 7, 2014 53 54Version 55 56 Last Modified Date: December 10, 2018 57 Revision: 7 58 59Number 60 61 OpenGL ES Extension #214 62 63Dependencies 64 65 OpenGL ES 3.1 and OpenGL ES Shading Language 3.10 are required. 66 67 This specification is written against the OpenGL ES 3.1 (March 17, 2014) 68 and OpenGL ES 3.10 Shading Language (March 17, 2014) Specifications. 69 70 OES_geometry_shader is required in order to share language modifying the 71 OpenGL ES 3.1 specifications, which would otherwise have to be repeated 72 here. 73 74 OES_shader_io_blocks or EXT_shader_io_blocks is required. 75 76 OES_gpu_shader5 or EXT_gpu_shader5 is required. 77 78 This extension interacts with OES_shader_multisample_interpolation. 79 80Overview 81 82 This extension introduces new tessellation stages and two new shader types 83 to the OpenGL ES primitive processing pipeline. These pipeline stages 84 operate on a new basic primitive type, called a patch. A patch consists 85 of a fixed-size collection of vertices, each with per-vertex attributes, 86 plus a number of associated per-patch attributes. Tessellation control 87 shaders transform an input patch specified by the application, computing 88 per-vertex and per-patch attributes for a new output patch. A 89 fixed-function tessellation primitive generator subdivides the patch, and 90 tessellation evaluation shaders are used to compute the position and 91 attributes of each vertex produced by the tessellator. 92 93 When tessellation is active, it begins by running the optional 94 tessellation control shader. This shader consumes an input patch and 95 produces a new fixed-size output patch. The output patch consists of an 96 array of vertices, and a set of per-patch attributes. The per-patch 97 attributes include tessellation levels that control how finely the patch 98 will be tessellated. For each patch processed, multiple tessellation 99 control shader invocations are performed -- one per output patch vertex. 100 Each tessellation control shader invocation writes all the attributes of 101 its corresponding output patch vertex. A tessellation control shader may 102 also read the per-vertex outputs of other tessellation control shader 103 invocations, as well as read and write shared per-patch outputs. The 104 tessellation control shader invocations for a single patch effectively run 105 as a group. A built-in barrier() function is provided to allow 106 synchronization points where no shader invocation will continue until all 107 shader invocations have reached the barrier. 108 109 The tessellation primitive generator then decomposes a patch into a new 110 set of primitives using the tessellation levels to determine how finely 111 tessellated the output should be. The primitive generator begins with 112 either a triangle or a quad, and splits each outer edge of the primitive 113 into a number of segments approximately equal to the corresponding element 114 of the outer tessellation level array. The interior of the primitive is 115 tessellated according to elements of the inner tessellation level array. 116 The primitive generator has three modes: "triangles" and "quads" split a 117 triangular or quad-shaped patch into a set of triangles that cover the 118 original patch; "isolines" splits a quad-shaped patch into a set of line 119 strips running across the patch horizontally. Each vertex generated by 120 the tessellation primitive generator is assigned a (u,v) or (u,v,w) 121 coordinate indicating its relative location in the subdivided triangle or 122 quad. 123 124 For each vertex produced by the tessellation primitive generator, the 125 tessellation evaluation shader is run to compute its position and other 126 attributes of the vertex, using its (u,v) or (u,v,w) coordinate. When 127 computing final vertex attributes, the tessellation evaluation shader can 128 also read the attributes of any of the vertices of the patch written by 129 the tessellation control shader. Tessellation evaluation shader 130 invocations are completely independent, although all invocations for a 131 single patch share the same collection of input vertices and per-patch 132 attributes. 133 134 The tessellator operates on vertices after they have been transformed by a 135 vertex shader. The primitives generated by the tessellator are passed 136 further down the OpenGL ES pipeline, where they can be used as inputs to 137 geometry shaders, transform feedback, and the rasterizer. 138 139 The tessellation control and evaluation shaders are both optional. If 140 neither shader type is present, the tessellation stage has no effect. 141 However, if either a tessellation control or a tessellation evaluation 142 shader is present, the other must also be present. 143 144 Not all tessellation shader implementations have the ability to write the 145 point size from a tessellation shader. Thus a second extension string and 146 shading language enable are provided for implementations which do 147 support tessellation shader point size. 148 149 This extension relies on the OES_shader_io_blocks or EXT_shader_io_blocks 150 extension to provide the required functionality for declaring input and 151 output blocks and interfacing between shaders. 152 153 This extension relies on the OES_gpu_shader5 or EXT_gpu_shader5 extension 154 to provide the 'precise' and 'fma' functionality which are necessary to 155 ensure crack-free tessellation. 156 157IP Status 158 159 No known IP claims. 160 161New Procedures and Functions 162 163 void PatchParameteriOES(enum pname, int value); 164 165New Tokens 166 167 Accepted by the <mode> parameter of DrawArrays, DrawElements, 168 and other commands which draw primitives: 169 170 PATCHES_OES 0xE 171 172 Accepted by the <pname> parameter of PatchParameteriOES, GetBooleanv, 173 GetFloatv, GetIntegerv, and GetInteger64v: 174 175 PATCH_VERTICES_OES 0x8E72 176 177 Accepted by the <pname> parameter of GetProgramiv: 178 179 TESS_CONTROL_OUTPUT_VERTICES_OES 0x8E75 180 TESS_GEN_MODE_OES 0x8E76 181 TESS_GEN_SPACING_OES 0x8E77 182 TESS_GEN_VERTEX_ORDER_OES 0x8E78 183 TESS_GEN_POINT_MODE_OES 0x8E79 184 185 Returned by GetProgramiv when <pname> is TESS_GEN_MODE_OES: 186 187 TRIANGLES 188 ISOLINES_OES 0x8E7A 189 QUADS_OES 0x0007 190 191 Returned by GetProgramiv when <pname> is TESS_GEN_SPACING_OES: 192 193 EQUAL 194 FRACTIONAL_ODD_OES 0x8E7B 195 FRACTIONAL_EVEN_OES 0x8E7C 196 197 Returned by GetProgramiv when <pname> is TESS_GEN_VERTEX_ORDER_OES: 198 199 CCW 200 CW 201 202 Returned by GetProgramiv when <pname> is TESS_GEN_POINT_MODE_OES: 203 204 FALSE 205 TRUE 206 207 Accepted by the <pname> parameter of GetBooleanv, GetFloatv, 208 GetIntegerv, and GetInteger64v: 209 210 MAX_PATCH_VERTICES_OES 0x8E7D 211 MAX_TESS_GEN_LEVEL_OES 0x8E7E 212 MAX_TESS_CONTROL_UNIFORM_COMPONENTS_OES 0x8E7F 213 MAX_TESS_EVALUATION_UNIFORM_COMPONENTS_OES 0x8E80 214 MAX_TESS_CONTROL_TEXTURE_IMAGE_UNITS_OES 0x8E81 215 MAX_TESS_EVALUATION_TEXTURE_IMAGE_UNITS_OES 0x8E82 216 MAX_TESS_CONTROL_OUTPUT_COMPONENTS_OES 0x8E83 217 MAX_TESS_PATCH_COMPONENTS_OES 0x8E84 218 MAX_TESS_CONTROL_TOTAL_OUTPUT_COMPONENTS_OES 0x8E85 219 MAX_TESS_EVALUATION_OUTPUT_COMPONENTS_OES 0x8E86 220 MAX_TESS_CONTROL_UNIFORM_BLOCKS_OES 0x8E89 221 MAX_TESS_EVALUATION_UNIFORM_BLOCKS_OES 0x8E8A 222 MAX_TESS_CONTROL_INPUT_COMPONENTS_OES 0x886C 223 MAX_TESS_EVALUATION_INPUT_COMPONENTS_OES 0x886D 224 MAX_COMBINED_TESS_CONTROL_UNIFORM_COMPONENTS_OES 0x8E1E 225 MAX_COMBINED_TESS_EVALUATION_UNIFORM_COMPONENTS_OES 0x8E1F 226 MAX_TESS_CONTROL_ATOMIC_COUNTER_BUFFERS_OES 0x92CD 227 MAX_TESS_EVALUATION_ATOMIC_COUNTER_BUFFERS_OES 0x92CE 228 MAX_TESS_CONTROL_ATOMIC_COUNTERS_OES 0x92D3 229 MAX_TESS_EVALUATION_ATOMIC_COUNTERS_OES 0x92D4 230 MAX_TESS_CONTROL_IMAGE_UNIFORMS_OES 0x90CB 231 MAX_TESS_EVALUATION_IMAGE_UNIFORMS_OES 0x90CC 232 MAX_TESS_CONTROL_SHADER_STORAGE_BLOCKS_OES 0x90D8 233 MAX_TESS_EVALUATION_SHADER_STORAGE_BLOCKS_OES 0x90D9 234 PRIMITIVE_RESTART_FOR_PATCHES_SUPPORTED_OES 0x8221 235 236 Accepted by the <props> parameter of 237 GetProgramResourceiv: 238 239 IS_PER_PATCH_OES 0x92E7 240 REFERENCED_BY_TESS_CONTROL_SHADER_OES 0x9307 241 REFERENCED_BY_TESS_EVALUATION_SHADER_OES 0x9308 242 243 Accepted by the <type> parameter of CreateShader, by the <pname> 244 parameter of GetProgramPipelineiv, and returned by the 245 <params> parameter of GetShaderiv: 246 247 TESS_EVALUATION_SHADER_OES 0x8E87 248 TESS_CONTROL_SHADER_OES 0x8E88 249 250 Accepted by the <stages> parameter of UseProgramStages: 251 252 TESS_CONTROL_SHADER_BIT_OES 0x00000008 253 TESS_EVALUATION_SHADER_BIT_OES 0x00000010 254 255Additions to the OpenGL ES 3.1 Specification 256 257 Modify chapter 3 "Dataflow Model" 258 259 Change the second paragraph, on p. 28: 260 261 ... In the next stage vertices may be transformed, followed by assembly 262 into geometric primitives. Tessellation and geometry shaders may then 263 optionally generate multiple new primitives from single input 264 primitives. Optionally, the results ... 265 266 267 Modify figure 3.1 "Block diagram of the OpenGL ES pipeline" as modified 268 by OES_geometry_shader to insert new boxes "Tessellation Control 269 Shader", "Tessellation Primitive Generation", and "Tessellation 270 Evaluation Shader" in sequence following "Vertex Shader" and preceding 271 "Geometry Shader". Extend the arrows from the boxes "Image Load/Store" 272 .. "Uniform Block" to the right of "Vertex Shader" to connect to the new 273 "Control" and "Evaluation" boxes. 274 275 276 Replace the two paragraphs of chapter 7, "Programs and Shaders" on p. 64 277 starting "Shader stages including ..." with: 278 279 Shader stages including vertex, tessellation control, tessellation 280 evaluation, geometry, fragment, and compute shaders can be created, 281 compiled, and linked into program objects. 282 283 Vertex shaders describe the operations that occur on vertex attributes. 284 Tessellation control and evaluation shaders are used to control 285 the operation of the tessellator (see section 11.1ts). Geometry shaders 286 affect the processing of primitives assembled from vertices (see section 287 11.1gs). Fragment shaders affect the processing of fragments during 288 rasterization (see chapter 14). A single program object can contain all 289 of these shaders, or any subset thereof. 290 291 Compute shaders ... 292 293 294 Add to table 7.1 "CreateShader <type> values" on p. 65: 295 296 <type> Shader Stage 297 -------------------------- ------------------------------ 298 TESS_CONTROL_SHADER_OES Tessellation control shader 299 TESS_EVALUATION_SHADER_OES Tessellation evaluation shader 300 301 302 Add to the bullet list describing reasons for link failure below the 303 LinkProgram command on p. 70, as modified by OES_geometry_shader: 304 305 * The program object contains an object to form a tessellation control 306 shader (see section 11.1ts.1), and 307 - the program is not separable and contains no object to form a 308 vertex shader; or 309 - the program is not separable and contains no object to form a 310 tessellation evaluation shader; or 311 - the output patch vertex count is not specified in the compiled 312 tessellation control shader object. 313 * The program object contains an object to form a tessellation 314 evaluation shader (see section 11.1ts.3), and 315 - the program is not separable and contains no object to form a 316 vertex shader; or 317 - the program is not separable and contains no object to form a 318 tessellation control shader; or 319 - the tessellation primitive mode is not specified in the compiled 320 tessellation evaluation shader object. 321 322 323 Modify section 7.3, "Program Objects", as modified by 324 OES_geometry_shader: 325 326 Add to the second paragraph after UseProgram on p. 71: 327 328 The executable code ... the results of vertex and/or fragment processing 329 will be undefined. However, this is not an error. If there is no active 330 program for the tessellation control, tessellation evaluation, or 331 geometry shader stages, those stages are ignored. If there is no active 332 program for the compute shader stage ... 333 334 335 Modify section 7.3.1, Program Interfaces: 336 337 Modify table 7.2 "GetProgramResourceiv properties and supported 338 interfaces" on p. 81 to add "REFERENCED_BY_TESS_CONTROL_SHADER_OES" and 339 "REFERENCED_BY_TESS_EVALUATION_SHADER_OES" to the "Property" cell 340 already containing REFERENCED_BY_<stage>_SHADER for VERTEX, GEOMETRY, 341 FRAGMENT, and COMPUTE stages, with the same supported interfaces. 342 343 Add to table 7.2: 344 345 Property Supported Interfaces 346 ---------------------------------------- ----------------------------- 347 IS_PER_PATCH_OES PROGRAM_INPUT, PROGRAM_OUTPUT 348 349 Add a new paragraph preceding the paragraph "For property IS_ROW_MAJOR" 350 on p. 83: 351 352 For the property IS_PER_PATCH_OES, a single integer identifying whether 353 the input or output is a per-patch attribute is written to <params>. If 354 the active variable is a per-patch attribute (declared with the "patch" 355 qualifier), the value one is written to <params>; otherwise the value 356 zero is written to <params>. 357 358 359 Add tessellation shaders to the paragraph describing the REFERENCED_BY 360 properties, on p. 83: 361 362 For the properties REFERENCED_BY_VERTEX_SHADER, 363 REFERENCED_BY_TESS_CONTROL_SHADER_OES, 364 REFERENCED_BY_TESS_EVALUATION_SHADER_OES, 365 REFERENCED_BY_GEOMETRY_SHADER_OES, REFERENCED_BY_FRAGMENT_SHADER, and 366 REFERENCED_BY_COMPUTE_SHADER, a single integer is written to <params>, 367 identifying whether the active resource is referenced by the vertex, 368 tessellation control, tessellation evaluation, geometry, fragment, or 369 compute shaders, respectively, in the program object. ... 370 371 372 Modify section 7.4, "Program Pipeline Objects" in the first 373 paragraph after UseProgramStages on p. 89: 374 375 ... These stages may include vertex, tessellation control, tessellation 376 evaluation, geometry, fragment, or compute, indicated respectively by 377 VERTEX_SHADER_BIT, TESS_CONTROL_SHADER_BIT_OES, TESS_EVALUATION_BIT_OES, 378 GEOMETRY_SHADER_BIT_OES, FRAGMENT_SHADER_BIT, or COMPUTE_SHADER_BIT. ... 379 380 381 Modify section 7.4.1, "Shader Interface Matching" on p. 91, changing the 382 new paragraph starting "Geometry shader per-vertex ...": 383 384 Tessellation control shader per-vertex output variables and blocks and 385 tessellation control, tessellation evaluation, and geometry shader 386 per-vertex input variables are required to be declared as arrays... 387 388 389 Modify section 7.4.2 "Program Pipeline Object State" on p. 92, 390 replacing the first bullet point: 391 392 * Unsigned integers are required to hold the names of the active program 393 and each of the current vertex, tessellation control, tessellation 394 evaluation, geometry, fragment, and compute stage programs. Each 395 integer is initially zero. 396 397 398 Modify section 7.6, "Uniform Variables" 399 400 Add to table 7.4 "Query targets for default uniform block storage ..." 401 on p. 96: 402 403 Shader Stage <pname> for querying default uniform block 404 storage, in components 405 ---------------------------------- ------------------------------------------- 406 Tess. control (see sec. 11.1ts.1.1) MAX_TESS_CONTROL_UNIFORM_COMPONENTS_OES 407 Tess. eval (see sec. 11.1ts.3.1) MAX_TESS_EVALUATION_UNIFORM_COMPONENTS_OES 408 409 410 Add to table 7.5 "Query targets for combined uniform block storage ..." 411 on p. 96: 412 413 414 Shader Stage <pname> for querying combined uniform block 415 storage, in components 416 ---------------------------------- --------------------------------------------------- 417 Tess. control MAX_COMBINED_TESS_CONTROL_UNIFORM_COMPONENTS_OES 418 Tess. eval MAX_COMBINED_TESS_EVALUATION_UNIFORM_COMPONENTS_OES 419 420 421 Modify section 7.6.2, "Uniform Blocks" on p. 104, changing the second 422 paragraph of the section: 423 424 There is a set of implementation-dependent maximums for the number of 425 active uniform blocks used by each shader. If the number of uniform 426 blocks used by any shader in the program exceeds its corresponding 427 limit, the program will fail to link. The limits for vertex, 428 tessellation control, tessellation evaluation, geometry, fragment, and 429 compute shaders can be obtained by calling GetIntegerv with <pname> 430 values of MAX_VERTEX_UNIFORM_BLOCKS, 431 MAX_TESS_CONTROL_UNIFORM_BLOCKS_OES, 432 MAX_TESS_EVALUATION_UNIFORM_BLOCKS_OES, MAX_GEOMETRY_UNIFORM_BLOCKS_OES, 433 MAX_FRAGMENT_UNIFORM_BLOCKS, and MAX_COMPUTE_UNIFORM_BLOCKS, 434 respectively. 435 436 437 Modify section 7.7, "Atomic Counter Buffers" on p. 108, changing the 438 second paragraph of the section: 439 440 There is a set of implementation-dependent maximums for the number of 441 active atomic counter buffers referenced by each shader. If the number 442 of atomic counter buffers referenced by any shader in the program 443 exceeds its corresponding limit, the program will fail to link. The 444 limits for vertex, tessellation control, tessellation evaluation, 445 geometry, fragment, and compute shaders can be obtained by calling 446 GetIntegerv with <pname> values of MAX_VERTEX_ATOMIC_COUNTER_BUFFERS, 447 MAX_TESS_CONTROL_ATOMIC_COUNTER_BUFFERS_OES, 448 MAX_TESS_EVALUATION_ATOMIC_COUNTER_BUFFERS_OES, 449 MAX_GEOMETRY_ATOMIC_COUNTER_BUFFERS_OES, 450 MAX_FRAGMENT_ATOMIC_COUNTER_BUFFERS, or 451 MAX_COMPUTE_ATOMIC_COUNTER_BUFFERS, respectively. 452 453 454 Modify section 7.8, "Shader Buffer Variables and Shader Storage Blocks" 455 on p. 110, changing the fourth paragraph: 456 457 If the number of active shader storage blocks referenced by the shaders 458 in a program exceeds implementation-dependent limits, the program will 459 fail to link. The limits for vertex, tessellation control, tessellation 460 evaluation, geometry, fragment, and compute shaders can be obtained by 461 calling GetIntegerv with pname values of 462 MAX_VERTEX_SHADER_STORAGE_BLOCKS, 463 MAX_TESS_CONTROL_SHADER_STORAGE_BLOCKS_OES, 464 MAX_TESS_EVALUATION_SHADER_STORAGE_BLOCKS_OES, 465 MAX_GEOMETRY_SHADER_STORAGE_BLOCKS_OES, 466 MAX_FRAGMENT_SHADER_STORAGE_BLOCKS, and 467 MAX_COMPUTE_SHADER_STORAGE_BLOCKS, respectively. ... 468 469 470 Modify Section 7.11.1, "Shader Memory Access Ordering": 471 472 The order in which texture or buffer object memory is read or written by 473 shaders is largely undefined. For some shader types (vertex, 474 tessellation evaluation, and in some cases, fragment), even the number 475 of shader invocations that might perform loads and stores is undefined. 476 477 In particular, the following rules apply: 478 479 * While a vertex or tessellation evaluation shader will be executed at 480 least once for each unique vertex specified by the application (vertex 481 shaders) or generated by the tessellation primitive genertor 482 (tessellation evaluation shaders), it may be executed more than once 483 for implementation-dependent reasons. Additionally, ... 484 485 486 Modify section 7.12, "Shader, Program, and Program Pipeline Queries" 487 to add to the list of valid <pname>s for GetProgramiv on p. 120: 488 489 If <pname> is TESS_CONTROL_OUTPUT_VERTICES_OES, the number of vertices 490 in the tessellation control shader output patch is returned. 491 492 If <pname> is TESS_GEN_MODE_OES, QUADS_OES, TRIANGLES, or ISOLINES_OES 493 is returned, depending on the primitive mode declaration in the 494 tessellation evaluation shader. If <pname> is TESS_GEN_SPACING_OES, 495 EQUAL, FRACTIONAL_EVEN_OES, or FRACTIONAL_ODD_OES is returned, depending 496 on the spacing declaration in the tessellation evaluation shader. If 497 <pname> is TESS_GEN_VERTEX_ORDER_OES, CCW or CW is returned, depending 498 on the vertex order declaration in the tessellation evaluation shader. 499 If <pname> is TESS_GEN_POINT_MODE_OES, TRUE is returned if point mode is 500 enabled in a tessellation evaluation shader declaration; FALSE is 501 returned otherwise. 502 503 504 Add to the Errors for GetProgramiv on p. 121: 505 506 An INVALID_OPERATION error is generated if TESS_CONTROL_OUTPUT_VERTICES 507 is queried for a program which has not been linked successfully, or 508 which does not contain objects to form a tessellation control shader. 509 510 An INVALID_OPERATION error is generated if TESS_GEN_MODE, 511 TESS_GEN_SPACING, TESS_GEN_VERTEX_ORDER, or TESS_GEN_POINT_MODE are 512 queried for a program which has not been linked successfully, or which 513 does not contain objects to form a tessellation evaluation shader, 514 515 516 Add new section 10.1.7sp following section 10.1.7, "Separate Triangles", 517 on p. 234: 518 519 Section 10.1.7sp, Separate Patches 520 521 Separate patches are specified with mode PATCHES_OES. A patch is an 522 ordered collection of vertices used for primitive tessellation (see 523 section 11.1ts). The vertices comprising a patch have no implied 524 geometric ordering. The vertices of a patch are used by tessellation 525 shaders and the fixed-function tessellator to generate new point, line, 526 or triangle primitives. 527 528 Each patch in the series has a fixed number of vertices, which is 529 specified by calling 530 531 void PatchParameteriOES(enum pname, int value); 532 533 with <pname> set to PATCH_VERTICES_OES. 534 535 Errors 536 537 An INVALID_ENUM error is generated if <pname> is not PATCH_VERTICES_OES. 538 539 An INVALID_VALUE error is generated if <value> is less than or equal to 540 zero, or is greater than the implementation-dependent maximum patch size 541 (the value of MAX_PATCH_VERTICES_OES). The patch size is initially three 542 vertices. 543 544 If the number of vertices in a patch is given by <v>, the <v>*<i>+1st 545 through <v>*<i>+<v>th vertices (in that order) determine a patch for 546 each i = 0, 1, ..., n-1, where there are <v>*<n>+<k> vertices. <k> is in 547 the range [0,<v>-1]; if <k> is not zero, the final <k> vertices are 548 ignored. 549 550 551 Add to the end of section 10.3.4, "Primitive Restart" on p. 243: 552 553 Implementations are not required to support primitive restart for 554 separate patch primitives (primitive type PATCHES_OES). Support can be 555 queried by calling GetBooleanv with the symbolic constant 556 PRIMITIVE_RESTART_FOR_PATCHES_SUPPORTED_OES. A value of FALSE indicates 557 that primitive restart is treated as disabled when drawing patches, no 558 matter the value of the enable. A value of TRUE indicates that primitive 559 restart behaves normally for patches. 560 561 562 Modify section 11.1.2.1, "Output Variables" on p. 262, starting with the 563 second paragraph of the section: 564 565 ... These output variables are used to communicate values to the next 566 active stage in the vertex processing pipeline; either the tessellation 567 control or geometry shader, or the fixed-function vertex processing 568 stages leading to rasterization. 569 570 ... 571 572 The number of components (individual scalar numeric values) of output 573 variables that can be written by the vertex shader, whether or not a 574 tessellation control or geometry shader is active, is given by the value 575 of the implementation-dependent constant MAX_VERTEX_OUTPUT_COMPONENTS. 576 For the purposes of counting ... 577 578 ... 579 580 Each program object can specify a set of output variables from one 581 shader to be recorded in transform feedback mode (see section 2.14). The 582 variables that can be recorded are those emitted by the first active 583 shader, in order, from the following list: 584 585 * geometry shader 586 * tessellation evaluation shader 587 * vertex shader 588 589 The set of variables to record is specified with the command 590 591 void TransformFeedbackVaryings ... 592 593 594 Modify the bullet point starting "the <count> specified" in the list of 595 TransformFeedbackVaryings link failures on p. 263: 596 597 * the <count> specified by TransformFeedbackVaryings is non-zero, but 598 the program object has no vertex, tessellation evaluation, or geometry 599 shader; ... 600 601 602 Modify Section 11.1.3, Shader Execution 603 604 Change the first paragraph and bullet list on p. 264: 605 606 If there is an active program object present for the vertex, 607 tessellation control, tessellation evaluation, or geometry shader 608 stages, the executable code for those active programs is used to process 609 incoming vertex values. The following sequence of operations is 610 performed: 611 612 * Vertices are processed by the vertex shader (see section 11.1) and 613 assembled into primitives as described in sections 10.1 through 10.3. 614 * If the current program contains a tessellation control shader, each 615 individual patch primitive is processed by the tessellation control 616 shader (section 11.1ts.1). Otherwise, primitives are passed through 617 unmodified. If active, the tessellation control shader consumes its 618 input patch and produces a new patch primitive, which is passed to 619 subsequent pipeline stages. 620 * If the current program contains a tessellation evaluation shader, each 621 individual patch primitive is processed by the tessellation primitive 622 generator (section 11.1ts.2) and tessellation evaluation shader (see 623 section 11.1ts.3). Otherwise, primitives are passed through unmodified. 624 When a tessellation evaluation shader is active, the tessellation 625 primitive generator produces a new collection of point, line, or 626 triangle primitives to be passed to subsequent pipeline stages. The 627 vertices of these primitives are processed by the tessellation 628 evaluation shader. The patch primitive passed to the tessellation 629 primitive generator is consumed by this process. 630 * If the current program contains a geometry shader, ... 631 632 633 Modify the bullet list in section 11.1.3.5 "Texture Access" on p. 266 to 634 add limits for tessellation shaders: 635 636 * MAX_VERTEX_TEXTURE_IMAGE_UNITS (for vertex shaders), 637 * MAX_TESS_CONTROL_TEXTURE_IMAGE_UNITS_OES (for tessellation control 638 shaders), 639 * MAX_TESS_EVALUATION_TEXTURE_IMAGE_UNITS_OES (for tessellation 640 evaluation shaders), 641 * MAX_GEOMETRY_TEXTURE_IMAGE_UNITS_OES (for geometry shaders), and 642 * MAX_TEXTURE_IMAGE_UNITS (for fragment shaders). 643 644 645 Modify the bullet list in section 11.1.3.6 "Atomic Counter Access" on p. 646 268 to add a limit for geometry shaders: 647 648 * MAX_TESS_CONTROL_ATOMIC_COUNTERS_OES (for tessellation control 649 shaders), 650 * MAX_TESS_EVALUATION_ATOMIC_COUNTERS_OES (for tessellation evaluation 651 shaders), 652 653 654 Modify the bullet list in section 11.1.3.7 "Image Access" on p. 268 to 655 add a limit for geometry shaders: 656 657 * MAX_TESS_CONTROL_IMAGE_UNIFORMS_OES (for tessellation control 658 shaders), 659 * MAX_TESS_EVALUATION_IMAGE_UNIFORMS_OES (for tessellation evaluation 660 shaders), 661 662 663 Modify the bullet list in section 11.1.3.8 "Shader Storage Buffer 664 Access" on p. 268 to add a limit for geometry shaders: 665 666 * MAX_TESS_CONTROL_SHADER_STORAGE_BLOCKS_OES (for tessellation control 667 shaders), 668 * MAX_TESS_EVALUATION_SHADER_STORAGE_BLOCKS_OES (for tessellation 669 evaluation shaders), 670 671 672 Modify section 11.1.3.11, "Validation" to replace the bullet point 673 starting "There is an active program for the geometry stage ..." on p. 674 270: 675 676 * There is an active program for tessellation control, tessellation 677 evaluation, or geometry stages with corresponding executable shader, 678 but there is no active program with an executable vertex shader. 679 680 681 Add a new bullet point in the same section: 682 683 * One but not both of the tessellation control and tessellation 684 evaluation stages have an active program with corresponding executable 685 shader. 686 687 688 Insert new section 11.1ts, "Tessellation", between section 11.1 "Vertex 689 Shaders" and section 11.1gs "Geometry Shaders": 690 691 Tessellation is a process that reads a patch primitive and generates new 692 primitives used by subsequent pipeline stages. The generated primitives 693 are formed by subdividing a single triangle or quad primitive according 694 to fixed or shader-computed levels of detail and transforming each of 695 the vertices produced during this subdivision. 696 697 Tessellation functionality is controlled by two types of tessellation 698 shaders: tessellation control shaders and tessellation evaluation 699 shaders. Tessellation is considered active if and only if the active 700 program object or program pipeline object includes both a tessellation 701 control shader and a tessellation evaluation shader. 702 703 The tessellation control shader is used to read an input patch provided 704 by the application, and emit an output patch. The tessellation control 705 shader is run once for each vertex in the output patch and computes the 706 attributes of that vertex. Additionally, the tessellation control shader 707 may compute additional per-patch attributes of the output patch. The 708 most important per-patch outputs are the tessellation levels, which are 709 used to control the number of subdivisions performed by the tessellation 710 primitive generator. The tessellation control shader may also write 711 additional per-patch attributes for use by the tessellation evaluation 712 shader. If no tessellation control shader is active, patch primitives 713 may not be provided by the application. 714 715 If a tessellation evaluation shader is active, the tessellation 716 primitive generator subdivides a triangle or quad primitive into a 717 collection of points, lines, or triangles according to the tessellation 718 levels of the patch and the set of layout declarations specified in the 719 tessellation evaluation shader text. 720 721 When a tessellation evaluation shader is active, it is run on each 722 vertex generated by the tessellation primitive generator to compute the 723 final position and other attributes of the vertex. The tessellation 724 evaluation shader can read the relative location of the vertex in the 725 subdivided output primitive, given by an (u,v) or (u,v,w) coordinate, as 726 well as the position and attributes of any or all of the vertices in the 727 input patch. 728 729 Tessellation operates only on patch primitives. 730 731 Patch primitives are not supported by pipeline stages below the 732 tessellation evaluation shader. 733 734 A non-separable program object or program pipeline object that includes 735 a tessellation shader of any kind must also include a vertex shader. 736 737 738 Errors 739 740 An INVALID_OPERATION error is generated by any command that transfers 741 vertices to the GL if the current program state has one but not both of 742 a tessellation control shader and tessellation evaluation shader. 743 744 An INVALID_OPERATION error is generated by any command that transfers 745 vertices to the GL if tessellation is active and the primitive mode is 746 not PATCHES_OES. 747 748 An INVALID_OPERATION error is generated by any command that transfers 749 vertices to the GL if tessellation is not active and the primitive mode 750 is PATCHES_OES. 751 752 An INVALID_OPERATION error is generated by any command that transfers 753 vertices to the GL if the current program state has a tessellation 754 shader but no vertex shader. 755 756 757 Section 11.1ts.1, Tessellation Control Shaders 758 759 The tessellation control shader consumes an input patch provided by the 760 application and emits a new output patch. The input patch is an array of 761 vertices with attributes corresponding to output variables written by 762 the vertex shader. The output patch consists of an array of vertices 763 with attributes corresponding to per-vertex output variables written by 764 the tessellation control shader and a set of per-patch attributes 765 corresponding to per-patch output variables written by the tessellation 766 control shader. Tessellation control output variables are per-vertex by 767 default, but may be declared as per-patch using the "patch" qualifier. 768 769 The number of vertices in the output patch is fixed when the program is 770 linked, and is specified in tessellation control shader source code 771 using the output layout qualifier "vertices", as described in the OpenGL 772 ES Shading Language Specification. A program will fail to link if the 773 output patch vertex count is not specified by the tessellation control 774 shader object attached to the program, if it is less than or equal to 775 zero, or if it is greater than the implementation-dependent maximum 776 patch size. The output patch vertex count may be queried by calling 777 GetProgramiv with the symbolic constant 778 TESS_CONTROL_OUTPUT_VERTICES_OES. 779 780 Tessellation control shaders are created as described in section 7.1, 781 using a <type> of TESS_CONTROL_SHADER_OES. When a new input patch is 782 received, the tessellation control shader is run once for each vertex in 783 the output patch. The tessellation control shader invocations 784 collectively specify the per-vertex and per-patch attributes of the 785 output patch. The per-vertex attributes are obtained from the per-vertex 786 output variables written by each invocation. Each tessellation control 787 shader invocation may only write to per-vertex output variables 788 corresponding to its own output patch vertex. The output patch vertex 789 number corresponding to a given tessellation control point shader 790 invocation is given by the built-in variable gl_InvocationID. Per-patch 791 attributes are taken from the per-patch output variables, which may be 792 written by any tessellation control shader invocation. While 793 tessellation control shader invocations may read any per-vertex and 794 per-patch output variable and write any per-patch output variable, 795 reading or writing output variables also written by other invocations 796 has ordering hazards discussed below. 797 798 799 Section 11.1ts.1.1, Tessellation Control Shader Variables 800 801 Tessellation control shaders can access uniforms belonging to the 802 current program object. Limits on uniform storage and methods for 803 manipulating uniforms are described in section 7.6. 804 805 Tessellation control shaders also have access to samplers to perform 806 texturing operations, as described in section 7.9. 807 808 Tessellation control shaders can access the transformed attributes of 809 all vertices for their input primitive using input variables. A vertex 810 shader writing to output variables generates the values of these input 811 variables. Values for any inputs that are not written by a vertex shader 812 are undefined. 813 814 Additionally, tessellation control shaders can write to one or more 815 output variables, including per-vertex attributes for the vertices of 816 the output patch and per-patch attributes of the patch. Tessellation 817 control shaders can also write to a set of built-in per-vertex and 818 per-patch outputs defined in the OpenGL ES Shading Language. The 819 per-vertex and per-patch attributes of the output patch are used by the 820 tessellation primitive generator (section 11.1ts.2) and may be read by 821 tessellation evaluation shader (section 11.1ts.3). 822 823 824 Section 11.1ts.1.2, Tessellation Control Shader Execution Environment 825 826 If there is an active program for the tessellation control stage, the 827 executable version of the program's tessellation control shader is used 828 to process patches resulting from the primitive assembly stage. When 829 tessellation control shader execution completes, the input patch is 830 consumed. A new patch is assembled from the per-vertex and per-patch 831 output variables written by the shader and is passed to subsequent 832 pipeline stages. 833 834 There are several special considerations for tessellation control shader 835 execution described in the following sections. 836 837 838 Section 11.1ts.1.2.1, Texture Access 839 840 Section 11.1.3.1 describes texture lookup functionality accessible to a 841 vertex shader. The texel fetch and texture size query functionality 842 described there also applies to tessellation control shaders. 843 844 845 Section 11.1ts.1.2.2, Tessellation Control Shader Inputs 846 847 Section 7.1 ("Built-In Variables") of the OpenGL ES Shading Language 848 Specification describes the built-in variable array gl_in[] available as 849 input to a tessellation control shader. gl_in[] receives values from 850 equivalent built-in output variables written by the vertex shader. Each 851 array element of gl_in[] is a structure holding values for a specific 852 vertex of the input patch. The length of gl_in[] is equal to the 853 implementation-dependent maximum patch size (gl_MaxPatchVertices). 854 Behavior is undefined if gl_in[] is indexed with a vertex index greater 855 than or equal to the current patch size. The members of each element of 856 the gl_in[] array are gl_Position 857 [[ If OES_tessellation_point_size is supported: ]] 858 and gl_PointSize. 859 860 Tessellation control shaders have available several other special input 861 variables not replicated per-vertex and not contained in gl_in[], 862 including: 863 864 * The variable gl_PatchVerticesIn holds the number of vertices in the 865 input patch being processed by the tessellation control shader. 866 867 * The variable gl_PrimitiveID is filled with the number of primitives 868 processed by the drawing command which generated the input vertices. 869 The first primitive generated by a drawing command is numbered zero, 870 and the primitive ID counter is incremented after every individual 871 point, line, or triangle primitive is processed. The counter is 872 reset to zero between each instance drawn. Restarting a primitive 873 topology using the primitive restart index has no effect on the 874 primitive ID counter. 875 876 * The variable gl_InvocationID holds an invocation number for the 877 current tessellation control shader invocation. Tessellation control 878 shaders are invoked once per output patch vertex, and invocations 879 are numbered beginning with zero. 880 881 Similarly to the built-in inputs, each user-defined input variable has a 882 value for each vertex and thus needs to be declared as arrays or inside 883 input blocks declared as arrays. Declaring an array size is optional. If 884 no size is specified, it will be taken from the implementation-dependent 885 maximum patch size (gl_MaxPatchVertices). If a size is specified, it must 886 match the maximum patch size; otherwise, a compile or link error will 887 occur. Since the array size may be larger than the number of vertices 888 found in the input patch, behavior is undefined if a per-vertex input 889 variable is accessed using an index greater than or equal to the number of 890 vertices in the input patch. The OpenGL ES Shading Language doesn't 891 support multi-dimensional arrays as shader inputs or outputs; therefore, 892 user-defined tessellation control shader inputs corresponding to vertex 893 shader outputs declared as arrays must be declared as array members of 894 an input block that is itself declared as an array. 895 896 Similarly to the limit on vertex shader output components (see section 897 11.1.2.1), there is a limit on the number of components of input 898 variables that can be read by the tessellation control shader, given by 899 the value of the implementation-dependent constant 900 MAX_TESS_CONTROL_INPUT_COMPONENTS_OES. 901 902 When a program is linked, all components of any input read by a 903 tessellation control shader will count against this limit. A program 904 whose tessellation control shader exceeds this limit may fail to link, 905 unless device-dependent optimizations are able to make the program fit 906 within available hardware resources. 907 908 Component counting rules for different variable types and variable 909 declarations are the same as for MAX_VERTEX_OUTPUT_COMPONENTS (see 910 section 11.1.2.1). 911 912 913 Section 11.1ts.1.2.3, Tessellation Control Shader Outputs 914 915 Section 7.1 ("Built-In Variables") of the OpenGL ES Shading Language 916 Specification describes the built-in variable array gl_out[] available 917 as an output for a tessellation control shader. gl_out[] passes values 918 to equivalent built-in input variables read by subsequent shader stages 919 or to subsequent fixed functionality vertex processing pipeline stages. 920 Each array element of gl_out[] is a structure holding values for a 921 specific vertex of the output patch. The length of gl_out[] is equal to 922 the output patch size specified in the tessellation control shader 923 output layout declaration. The members of each element of the gl_out[] 924 array are gl_Position 925 [[ If OES_tessellation_point_size is supported: ]] 926 and gl_PointSize. 927 They behave identically to equivalently named vertex shader outputs 928 (see section 11.1.2.1). 929 930 Tessellation shaders additionally have two built-in per-patch output 931 arrays, gl_TessLevelOuter[] and gl_TessLevelInner[]. These arrays are not 932 replicated for each output patch vertices and are not members of gl_out[]. 933 gl_TessLevelOuter[] is an array of four floating-point values specifying 934 the approximate number of segments that the tessellation primitive 935 generator should use when subdividing each outer edge of the primitive it 936 subdivides. gl_TessLevelInner[] is an array of two floating-point values 937 specifying the approximate number of segments used to produce a 938 regularly-subdivided primitive interior. The values written to 939 gl_TessLevelOuter and gl_TessLevelInner need not be integers, and their 940 interpretation depends on the type of primitive the tessellation 941 primitive generator will subdivide and other tessellation parameters, as 942 discussed in the following section. 943 944 A tessellation control shader may also declare user-defined per-vertex 945 output variables. User-defined per-vertex output variables are declared 946 with the qualifier "out" and have a value for each vertex in the output 947 patch. Such variables must be declared as arrays or inside output blocks 948 declared as arrays. Declaring an array size is optional. If no size is 949 specified, it will be taken from output patch size declared in the 950 shader. If a size is specified, it must match the maximum patch size; 951 otherwise, a compile or link error will occur. The OpenGL ES Shading 952 Language doesn't support multi-dimensional arrays as shader inputs or 953 outputs; therefore, user-defined per-vertex tessellation control shader 954 outputs with multiple elements per vertex must be declared as array members 955 of an output block that is itself declared as an array. 956 957 While per-vertex output variables are declared as arrays indexed by 958 vertex number, each tessellation control shader invocation may write 959 only to those outputs corresponding to its output patch vertex. 960 Tessellation control shaders must use the special variable 961 gl_InvocationID as the vertex number index when writing to per-vertex 962 output variables. 963 964 Additionally, a tessellation control shader may declare per-patch output 965 variables using the qualifier "patch out". Unlike per-vertex outputs, 966 per-patch outputs do not correspond to any specific vertex in the patch, 967 and are not indexed by vertex number. Per-patch outputs declared as 968 arrays have multiple values for the output patch; similarly declared 969 per-vertex outputs would indicate a single value for each vertex in the 970 output patch. User-defined per-patch outputs are not used by the 971 tessellation primitive generator, but may be read by tessellation 972 evaluation shaders. 973 974 There are several limits on the number of components of built-in and 975 user-defined output variables that can be written by the tessellation 976 control shader. The number of components of active per-vertex output 977 variables may not exceed the value of 978 MAX_TESS_CONTROL_OUTPUT_COMPONENTS_OES. The number of components of 979 active per-patch output variables may not exceed the value of 980 MAX_TESS_PATCH_COMPONENTS_OES. The built-in outputs gl_TessLevelOuter[] 981 and gl_TessLevelInner[] are not counted against the per-patch limit. The 982 total number of components of active per-vertex and per-patch outputs is 983 derived by multiplying the per-vertex output component count by the output 984 patch size and then adding the per-patch output component count. The total 985 component count may not exceed 986 MAX_TESS_CONTROL_TOTAL_OUTPUT_COMPONENTS_OES. 987 988 When a program is linked, all components of any output variable written 989 by a tessellation control shader will count against this limit. A 990 program exceeding any of these limits may fail to link, unless 991 device-dependent optimizations are able to make the program fit within 992 available hardware resources. 993 994 Component counting rules for different variable types and variable 995 declarations are the same as for MAX_VERTEX_OUTPUT_COMPONENTS. (see 996 section 11.1.2.1). 997 998 999 Section 11.1ts.1.2.4, Tessellation Control Shader Execution Order 1000 1001 For tessellation control shaders with a declared output patch size 1002 greater than one, the shader is invoked more than once for each input 1003 patch. The order of execution of one tessellation control shader 1004 invocation relative to the other invocations for the same input patch is 1005 largely undefined. The built-in function barrier() provides some control 1006 over relative execution order. When a tessellation control shader calls 1007 the barrier() function, its execution pauses until all other invocations 1008 have also called the same function. Output variable assignments 1009 performed by any invocation executed prior to calling barrier() will be 1010 visible to any other invocation after the call to barrier() returns. 1011 Shader output values read in one invocation but written by another may 1012 be undefined without proper use of barrier(); full rules are found in 1013 the OpenGL ES Shading Language Specification. 1014 1015 The barrier() function may only be called inside the main entry point of 1016 the tessellation control shader and may not be called in potentially 1017 divergent flow control. In particular, barrier() may not be called 1018 inside a switch statement, in either sub-statement of an if statement, 1019 inside a do, for, or while loop, or at any point after a return 1020 statement in the function main(). 1021 1022 1023 Section 11.1ts.2, Tessellation Primitive Generation 1024 1025 The tessellation primitive generator consumes the input patch and 1026 produces a new set of basic primitives (points, lines, or triangles). 1027 These primitives are produced by subdividing a geometric primitive 1028 (rectangle or triangle) according to the per-patch tessellation levels 1029 written by the tessellation control shader. This subdivision is 1030 performed in an implementation- dependent manner. 1031 1032 The type of subdivision performed by the tessellation primitive 1033 generator is specified by an input layout declaration in the 1034 tessellation evaluation shader using one of the identifiers "triangles", 1035 "quads", and "isolines". For "triangles", the primitive generator 1036 subdivides a triangle primitive into smaller triangles. For "quads", the 1037 primitive generator subdivides a rectangle primitive into smaller 1038 triangles. For "isolines", the primitive generator subdivides a 1039 rectangle primitive into a collection of line segments arranged in 1040 strips stretching horizontally across the rectangle. Each vertex 1041 produced by the primitive generator has an associated (u,v,w) or (u,v) 1042 position in a normalized parameter space, with parameter values in the 1043 range [0,1], as illustrated in Figure 11.X1. For "triangles", the vertex 1044 position is a barycentric coordinate (u,v,w), where u+v+w==1, and 1045 indicates the relative influence of the three vertices of the triangle 1046 on the position of the vertex. For "quads" and "isolines", the position 1047 is a (u,v) coordinate indicating the relative horizontal and vertical 1048 position of the vertex relative to the subdivided rectangle. The 1049 subdivision process is explained in more detail in subsequent sections. 1050 1051 (0,1) OL3 (1,1) (0,1,0) (0,1) (1,1) 1052 +--------------+ + ^ + <no edge> + 1053 | | / \ | 1054 | +--------+ | / \ | +--------------+ 1055 | | IL0 | | OL0 / + \ OL2 | 1056 OL0| |IL1 | |OL2 / / \ \ | +--------------+ 1057 | | | | / /IL0\ \ OL0 1058 | +--------+ | / +-----+ \ | +--------------+ 1059 | | / \ | 1060 +--------------+ +---------------+ v +--------------+ 1061 (0,0) OL1 (1,0) (0,0,1) OL1 (1,0,0) (0,0) OL1 (1,0) 1062 1063 quads triangles isolines 1064 1065 Figure 11.X1: Domain parameterization for tessellation generator 1066 primitive modes (triangles, quads, or isolines). The coordinates 1067 illustrate the value of gl_TessCoord at the corners of the domain. The 1068 labels on the edges indicate the inner (IL0 and IL1) and outer (OL0 1069 through OL3) tessellation level values used to control the number of 1070 subdivisions along each edge of the domain. 1071 1072 A patch is discarded by the tessellation primitive generator if any 1073 relevant outer tessellation level is less than or equal to zero. Patches 1074 will also be discarded if any relevant outer tessellation level 1075 corresponds to a floating-point NaN (not a number) in implementations 1076 supporting NaN. When patches are discarded, no new primitives will be 1077 generated and the tessellation evaluation program will not be run. For 1078 "quads", all four outer levels are relevant. For "triangles" and 1079 "isolines", only the first three or two outer levels, respectively, are 1080 relevant. Negative inner levels will not cause a patch to be discarded; 1081 they will be clamped as described below. 1082 1083 Each of the tessellation levels is used to determine the number and 1084 spacing of segments used to subdivide a corresponding edge. The method 1085 used to derive the number and spacing of segments is specified by an 1086 input layout declaration in the tessellation evaluation shader using one 1087 of the identifiers "equal_spacing", "fractional_even_spacing", or 1088 "fractional_odd_spacing". If no spacing is specified in the tessellation 1089 evaluation shader, "equal_spacing" will be used. 1090 1091 If "equal_spacing" is used, the floating-point tessellation level is 1092 first clamped to the range [1,<max>], where <max> is the 1093 implementation-dependent maximum tessellation level (the value of 1094 MAX_TESS_GEN_LEVEL_OES). The result is rounded up to the nearest integer 1095 <n>, and the corresponding edge is divided into <n> segments of equal 1096 length in (u,v) space. 1097 1098 If "fractional_even_spacing" is used, the tessellation level is first 1099 clamped to the range [2,<max>] and then rounded up to the nearest even 1100 integer <n>. If "fractional_odd_spacing" is used, the tessellation level 1101 is clamped to the range [1,<max>-1] and then rounded up to the nearest 1102 odd integer <n>. If <n> is one, the edge will not be subdivided. 1103 Otherwise, the corresponding edge will be divided into <n>-2 segments of 1104 equal length, and two additional segments of equal length that are 1105 typically shorter than the other segments. The length of the two 1106 additional segments relative to the others will decrease monotonically 1107 with the value of <n>-<f>, where <f> is the clamped floating-point 1108 tessellation level. When <n>-<f> is zero, the additional segments will 1109 have equal length to the other segments. As <n>-<f> approaches 2.0, the 1110 relative length of the additional segments approaches zero. The two 1111 additional segments should be placed symmetrically on opposite sides of 1112 the subdivided edge. The relative location of these two segments is 1113 undefined, but must be identical for any pair of subdivided edges with 1114 identical values of <f>. 1115 1116 When the tessellation primitive generator produces triangles (in the 1117 "triangles" or "quads" modes), the orientation of all triangles can be 1118 specified by an input layout declaration in the tessellation evaluation 1119 shader using the identifiers "cw" and "ccw". If the order is "cw", the 1120 vertices of all generated triangles will have a clockwise ordering in 1121 (u,v) or (u,v,w) space, as illustrated in Figure 11.X1. If the order is 1122 "ccw", the vertices will be specified in counter-clockwise order. If no 1123 layout is specified, "ccw" will be used. 1124 1125 For all primitive modes, the tessellation primitive generator is capable 1126 of generating points instead of lines or triangles. If an input layout 1127 declaration in the tessellation evaluation shader specifies the identifier 1128 "point_mode", the primitive generator will generate one point for each 1129 distinct vertex produced by tessellation. Otherwise, the primitive 1130 generator will produce a collection of line segments or triangles 1131 according to the primitive mode. When tessellating triangles or quads in 1132 point mode with fractional odd spacing, the tessellation primitive 1133 generator may produce "interior" vertices that are positioned on the edge 1134 of the patch if an inner tessellation level is less than or equal to one. 1135 Such vertices are considered distinct from vertices produced by 1136 subdividing the outer edge of the patch, even if there are pairs of 1137 vertices with identical coordinates. 1138 1139 The points, lines, or triangles produced by the tessellation primitive 1140 generator are passed to subsequent pipeline stages in an 1141 implementation-dependent order. 1142 1143 1144 Section 11.1ts.2.1, Triangle Tessellation 1145 1146 If the tessellation primitive mode is "triangles", an equilateral 1147 triangle is subdivided into a collection of triangles covering the area 1148 of the original triangle. First, the original triangle is subdivided 1149 into a collection of concentric equilateral triangles. The edges of each 1150 of these triangles are subdivided, and the area between each triangle 1151 pair is filled by triangles produced by joining the vertices on the 1152 subdivided edges. The number of concentric triangles and the number of 1153 subdivisions along each triangle except the outermost is derived from 1154 the first inner tessellation level. The edges of the outermost triangle 1155 are subdivided independently, using the first, second, and third outer 1156 tessellation levels to control the number of subdivisions of the u==0 1157 (left), v==0 (bottom), and w==0 (right) edges, respectively. The second 1158 inner tessellation level and the fourth outer tessellation level have no 1159 effect in this mode. 1160 1161 If the first inner tessellation level and all three outer tessellation 1162 levels are exactly one after clamping and rounding, only a single 1163 triangle with (u,v,w) coordinates of (0,0,1), (1,0,0), and (0,1,0) is 1164 generated. If the inner tessellation level is one and any of the outer 1165 tessellation levels is greater than one, the inner tessellation level is 1166 treated as though it were originally specified as 1+epsilon and will be 1167 rounded up to result in a two- or three-segment subdivision according to 1168 the tessellation spacing. 1169 1170 If any tessellation level is greater than one, tessellation begins by 1171 producing a set of concentric inner triangles and subdividing their 1172 edges. First, the three outer edges are temporarily subdivided using the 1173 clamped and rounded first inner tessellation level and the specified 1174 tessellation spacing, generating <n> segments. For the outermost inner 1175 triangle, the inner triangle is degenerate -- a single point at the 1176 center of the triangle -- if <n> is two. Otherwise, for each corner of 1177 the outer triangle, an inner triangle corner is produced at the 1178 intersection of two lines extended perpendicular to the corner's two 1179 adjacent edges running through the vertex of the subdivided outer edge 1180 nearest that corner. If <n> is three, the edges of the inner triangle 1181 are not subdivided and is the final triangle in the set of concentric 1182 triangles. Otherwise, each edge of the inner triangle is divided into 1183 <n>-2 segments, with the <n>-1 vertices of this subdivision produced by 1184 intersecting the inner edge with lines perpendicular to the edge running 1185 through the <n>-1 innermost vertices of the subdivision of the outer 1186 edge. Once the outermost inner triangle is subdivided, the previous 1187 subdivision process repeats itself, using the generated triangle as an 1188 outer triangle. This subdivision process is illustrated in Figure 11.X2. 1189 1190 (0,1,0) 1191 + 1192 / \ 1193 (0,1,0) O. .O 1194 + / + \ 1195 / \ O. / \ .O 1196 O. .O / O. .O \ 1197 / + \ / / + \ \ 1198 O. / \ .O / / / \ \ \ 1199 / O. .O \ O. / / \ \ .O 1200 / / O \ \ / O. / \ .O \ 1201 O. / . \ .O / / O-------O \ \ 1202 / O----O----O \ O. / . . \ .O 1203 / . . . \ / O----O-------O----O \ 1204 O----O----O----O----O / . . . . \ 1205 (0,0,1) (1,0,0) O----O----O-------O----O----O 1206 (0,0,1) (1,0,0) 1207 1208 Figure 11.X2, Inner Triangle Tessellation with inner tessellation 1209 levels of four and five (not to scale). This figure depicts the 1210 vertices along the bottom edge of the concentric triangles. The edges 1211 of inner triangles are subdivided by intersecting the edge with 1212 segments perpendicular to the edge passing through each inner vertex 1213 of the subdivided outer edge. 1214 1215 Once all the concentric triangles are produced and their edges are 1216 subdivided, the area between each pair of adjacent inner triangles is 1217 filled completely with a set of non-overlapping triangles. In this 1218 subdivision, two of the three vertices of each triangle are taken from 1219 adjacent vertices on a subdivided edge of one triangle; the third is one 1220 of the vertices on the corresponding edge of the other triangle. If the 1221 innermost triangle is degenerate (i.e., a point), the triangle 1222 containing it is subdivided into six triangles by connecting each of the 1223 six vertices on that triangle with the center point. If the innermost 1224 triangle is not degenerate, that triangle is added to the set of 1225 generated triangles as-is. 1226 1227 After the area corresponding to any inner triangles is filled, the 1228 primitive generator generates triangles to cover area between the 1229 outermost triangle and the outermost inner triangle. To do this, the 1230 temporary subdivision of the outer triangle edge above is discarded. 1231 Instead, the u==0, v==0, and w==0 edges are subdivided according to the 1232 first, second, and third outer tessellation levels, respectively, and 1233 the tessellation spacing. The original subdivision of the first inner 1234 triangle is retained. The area between the outer and first inner 1235 triangles is completely filled by non-overlapping triangles as described 1236 above. If the first (and only) inner triangle is degenerate, a set of 1237 triangles is produced by connecting each vertex on the outer triangle 1238 edges with the center point. 1239 1240 After all triangles are generated, each vertex in the subdivided 1241 triangle is assigned a barycentric (u,v,w) coordinate based on its 1242 location relative to the three vertices of the outer triangle. 1243 1244 The algorithm used to subdivide the triangular domain in (u,v,w) space 1245 into individual triangles is implementation-dependent. However, the set 1246 of triangles produced will completely cover the domain, and no portion 1247 of the domain will be covered by multiple triangles. The order in which 1248 the generated triangles passed to subsequent pipeline stages and the 1249 order of the vertices in those triangles are both 1250 implementation-dependent. However, when depicted in a manner similar to 1251 Figure 11.X2, the order of the vertices in the generated triangles will 1252 be either all clockwise or all counter-clockwise, according to the 1253 vertex order layout declaration. 1254 1255 1256 Section 11.1ts.2.2, Quad Tessellation 1257 1258 If the tessellation primitive mode is "quads", a rectangle is subdivided 1259 into a collection of triangles covering the area of the original 1260 rectangle. First, the original rectangle is subdivided into a regular 1261 mesh of rectangles, where the number of rectangles along the u==0 and 1262 u==1 (vertical) and v==0 and v==1 (horizontal) edges are derived from 1263 the first and second inner tessellation levels, respectively. All 1264 rectangles, except those adjacent to one of the outer rectangle edges, 1265 are decomposed into triangle pairs. The outermost rectangle edges are 1266 subdivided independently, using the first, second, third, and fourth 1267 outer tessellation levels to control the number of subdivisions of the 1268 u==0 (left), v==0 (bottom), u==1 (right), and v==1 (top) edges, 1269 respectively. The area between the inner rectangles of the mesh and the 1270 outer rectangle edges are filled by triangles produced by joining the 1271 vertices on the subdivided outer edges to the vertices on the edge of 1272 the inner rectangle mesh. 1273 1274 If both clamped inner tessellation levels and all four clamped outer 1275 tessellation levels are exactly one, only a single triangle pair covering 1276 the outer rectangle is generated. Otherwise, if either clamped inner 1277 tessellation level is one, that tessellation level is treated as though it 1278 were originally specified as 1+epsilon and will result in a two- or 1279 three-segment subdivision depending on the tessellation spacing. When 1280 used with fractional odd spacing, the three-segment subdivision may 1281 produce "inner" vertices positioned on the edge of the rectangle. 1282 1283 If any tessellation level is greater than one, tessellation begins by 1284 subdividing the u==0 and u==1 edges of the outer rectangle into <m> 1285 segments using the clamped and rounded first inner tessellation level 1286 and the tessellation spacing. The v==0 and v==1 edges are subdivided 1287 into <n> segments using using the second inner tessellation level. Each 1288 vertex on the u==0 and v==0 edges are joined with the corresponding 1289 vertex on the u==1 and v==1 edges to produce a set of vertical and 1290 horizontal lines that divide the rectangle into a grid of smaller 1291 rectangles. The primitive generator emits a pair of non-overlapping 1292 triangles covering each such rectangle not adjacent to an edge of the 1293 outer rectangle. The boundary of the region covered by these triangles 1294 forms an inner rectangle, the edges of which are subdivided by the grid 1295 vertices that lie on the edge. If either <m> or <n> is two, the inner 1296 rectangle is degenerate, and one or both of the rectangle's "edges" 1297 consist of a single point. This subdivision is illustrated in Figure 1298 11.X3. 1299 1300 (0,1) (1,1) 1301 +--+--+--+--+--+--+--+ 1302 | . . . . . . | 1303 (0,1) (1,1) | . . . . . . | 1304 +--+--+--+--+ +..O--O--O--O--O--O..+ 1305 | . . . | | |**|**|**|**|**| | 1306 | . . . | | |**|**|**|**|**| | 1307 +..O--O--O..+ +..O--+--+--+--+--O..+ 1308 | . . . | | |**|**|**|**|**| | 1309 | . . . | | |**|**|**|**|**| | 1310 +--+--+--+--+ +..O--O--O--O--O--O..+ 1311 (0,0) (1,0) | . . . . . . | 1312 | . . . . . . | 1313 +--+--+--+--+--+--+--+ 1314 (0,0) (1,0) 1315 1316 Figure 11.X3, Inner Quad Tessellation with inner tessellation levels 1317 of (4,2) and (7,4). The areas labeled with "*" on the right depict the 1318 10 inner rectangles, each of which will be subdivided into two 1319 triangles. The points labeled "O" depict vertices on the boundary of 1320 the inner rectangle, where the inner rectangle on the left side is 1321 degenerate (a single line segment). The dotted lines (".") depict the 1322 horizontal and vertical edges connecting corresponding points on the 1323 outer rectangle edge. 1324 1325 After the area corresponding to the inner rectangle is filled, the 1326 primitive generator must produce triangles to cover area between the 1327 inner and outer rectangles. To do this, the subdivision of the outer 1328 rectangle edge above is discarded. Instead, the u==0, v==0, u==1, and 1329 v==1 edges are subdivided according to the first, second, third, and 1330 fourth outer tessellation levels, respectively, and the tessellation 1331 spacing. The original subdivision of the inner rectangle is retained. 1332 The area between the outer and inner rectangles is completely filled by 1333 non-overlapping triangles. Two of the three vertices of each triangle 1334 are adjacent vertices on a subdivided edge of one rectangle; the third 1335 is one of the vertices on the corresponding edge of the other triangle. 1336 If either edge of the innermost rectangle is degenerate, the area near 1337 the corresponding outer edges is filled by connecting each vertex on the 1338 outer edge with the single vertex making up the inner "edge". 1339 1340 The algorithm used to subdivide the rectangular domain in (u,v) space 1341 into individual triangles is implementation-dependent. However, the set 1342 of triangles produced will completely cover the domain, and no portion 1343 of the domain will be covered by multiple triangles. The order in which 1344 the generated triangles passed to subsequent pipeline stages and the 1345 order of the vertices in those triangles are both 1346 implementation-dependent. However, when depicted in a manner similar to 1347 Figure 11.X3, the order of the vertices in the generated triangles will 1348 be either all clockwise or all counter-clockwise, according to the 1349 vertex order layout declaration. 1350 1351 1352 Isoline Tessellation 1353 1354 If the tessellation primitive mode is "isolines", a set of independent 1355 horizontal line segments is drawn. The segments are arranged into 1356 connected strips called "isolines", where the vertices of each isoline 1357 have a constant v coordinate and u coordinates covering the full range 1358 [0,1]. The number of isolines generated is derived from the first outer 1359 tessellation level; the number of segments in each isoline is derived 1360 from the second outer tessellation level. Both inner tessellation levels 1361 and the third and fourth outer tessellation levels have no effect in 1362 this mode. 1363 1364 As with quad tessellation above, isoline tessellation begins with a 1365 rectangle. The u==0 and u==1 edges of the rectangle are subdivided 1366 according to the first outer tessellation level. For the purposes of 1367 this subdivision, the tessellation spacing mode is ignored and treated 1368 as "equal_spacing". A line is drawn connecting each vertex on the u==0 1369 rectangle edge to the corresponding vertex on the u==1 rectangle edge, 1370 except that no line is drawn between (0,1) and (1,1). If the number of 1371 segments on the subdivided u==0 and u==1 edges is <n>, this process will 1372 result in <n> equally spaced lines with constant v coordinates of 0, 1373 1/<n>, 2/<n>, ..., (<n>-1)/<n>. 1374 1375 Each of the <n> lines is then subdivided according to the second outer 1376 tessellation level and the tessellation spacing, resulting in <m> line 1377 segments. Each segment of each line is emitted by the tessellation 1378 primitive generator, as illustrated in Figure 11.X4. 1379 1380 (0,1) (1,1) 1381 + + (0,1) (1,1) 1382 + + 1383 O---O---O---O---O---O---O 1384 1385 O---O---O---O---O---O---O 1386 1387 O---O---O---O---O---O---O 1388 O-----O-----O-----O 1389 O---O---O---O---O---O---O (0,0) (1,0) 1390 (0,0) (1,0) 1391 1392 Figure 11.X4, Isoline Tessellation with the first two outer 1393 tessellation levels of (4,6) and (1,3), respectively. The lines 1394 connecting the vertices labeled "O" are emitted by the primitive 1395 generator. The vertices labeled "+" correspond to (u,v) coordinates of 1396 (0,1) and (1,1), where no line segments are generated. 1397 1398 The order in which the generated line segments are passed to subsequent 1399 pipeline stages and the order of the vertices in each generated line 1400 segment are both implementation-dependent. 1401 1402 1403 Section 11.1ts.3, Tessellation Evaluation Shaders 1404 1405 If active, the tessellation evaluation shader takes the (u,v) or (u,v,w) 1406 location of each vertex in the primitive subdivided by the tessellation 1407 primitive generator, and generates a vertex with a position and 1408 associated attributes. The tessellation evaluation shader can read any 1409 of the vertices of its input patch, which is the output patch produced 1410 by the tessellation control shader. Tessellation evaluation shaders are 1411 created as described in section 7.1, using a <type> of 1412 TESS_EVALUATION_SHADER_OES. 1413 1414 Each invocation of the tessellation evaluation shader writes the 1415 attributes of exactly one vertex. The number of vertices evaluated per 1416 patch depends on the tessellation level values computed by the 1417 tessellation control shaders. Tessellation evaluation shader invocations 1418 run independently, and no invocation can access the variables belonging 1419 to another invocation. All invocations are capable of accessing all the 1420 vertices of their corresponding input patch. 1421 1422 The number of the vertices in the input patch is fixed and is equal to 1423 the tessellation control shader output patch size parameter in effect 1424 when the program was last linked. 1425 1426 1427 Section 11.1ts.3.1, Tessellation Evaluation Shader Variables 1428 1429 Tessellation evaluation shaders can access uniforms belonging to the 1430 current program object. The amount of storage available for uniform 1431 variables, except for atomic counters, in the default uniform block 1432 accessed by a tessellation evaluation shader is specified by the value 1433 of the implementation-dependent constant 1434 MAX_TESS_EVALUATION_UNIFORM_COMPONENTS_OES. The total amount of combined 1435 storage available for uniform variables in all uniform blocks accessed 1436 by a tessellation evaluation shader (including the default uniform 1437 block) is specified by the value of the implementation-dependent 1438 constant MAX_COMBINED_TESS_EVALUATION_UNIFORM_COMPONENTS_OES. These 1439 values represent the numbers of individual floating-point, integer, or 1440 boolean values that can be held in uniform variable storage for a 1441 tessellation evaluation shader. A uniform matrix in the default uniform 1442 block with single-precision components will consume no more than 4 x 1443 min(r,c) uniform components. A link error is generated if an attempt is 1444 made to utilize more than the space available for tessellation 1445 evaluation shader uniform variables. Uniforms are manipulated as 1446 described in section 2.11.6. Tessellation evaluation shaders also have 1447 access to samplers to perform texturing operations, as described in 1448 section 2.11.7. 1449 1450 Tessellation evaluation shaders can access the transformed attributes of 1451 all vertices for their input primitive using input variables. A 1452 tessellation control shader writing to output variables generates the 1453 values of these input varying variables, including values for built-in 1454 as well as user- defined varying variables. Values for any varying 1455 variables that are not written by a tessellation control shader are 1456 undefined. 1457 1458 Additionally, tessellation evaluation shaders can write to one or more 1459 output variables that will be passed to subsequent programmable shader 1460 stages or fixed functionality vertex pipeline stages. 1461 1462 1463 Section 11.1ts.3.2, Tessellation Evaluation Shader Execution Environment 1464 1465 If there is an active program for the tessellation evaluation stage, the 1466 executable version of the program's tessellation evaluation shader is 1467 used to process vertices produced by the tessellation primitive 1468 generator. During this processing, the shader may access the input patch 1469 processed by the primitive generator. When tessellation evaluation 1470 shader execution completes, a new vertex is assembled from the output 1471 variables written by the shader and is passed to subsequent pipeline 1472 stages. 1473 1474 There are several special considerations for tessellation evaluation 1475 shader execution described in the following sections. 1476 1477 1478 Section 11.1ts.3.2.1, Texture Access 1479 1480 Section 11.1.3.1 describes texture lookup functionality accessible to a 1481 vertex shader. The texel fetch and texture size query functionality 1482 described there also applies to tessellation evaluation shaders. 1483 1484 1485 Section 11.1ts.3.3, Tessellation Evaluation Shader Inputs 1486 1487 Section 7.1 ("Built-In Variables") of the OpenGL ES Shading Language 1488 Specification describes the built-in variable array gl_in[] available as 1489 input to a tessellation evaluation shader. gl_in[] receives values from 1490 equivalent built-in output variables written by a previous shader 1491 (section 11.1.3). Each array element of gl_in[] is a structure holding 1492 values for a specific vertex of the input patch. The length of gl_in[] 1493 is equal to the implementation- dependent maximum patch size 1494 (gl_MaxPatchVertices). Behavior is undefined if gl_in[] is indexed with 1495 a vertex index greater than or equal to the current patch size. The 1496 members of each element of the gl_in[] array are gl_Position 1497 [[ If OES_tessellation_point_size is supported: ]] 1498 and gl_PointSize. 1499 1500 Tessellation evaluation shaders have available several other special 1501 input variables not replicated per-vertex and not contained in gl_in[], 1502 including: 1503 1504 * The variables gl_PatchVerticesIn and gl_PrimitiveID are filled with 1505 the number of the vertices in the input patch and a primitive 1506 number, respectively. They behave exactly as the identically named 1507 inputs for tessellation control shaders. 1508 1509 * The variable gl_TessCoord is a three-component floating-point vector 1510 consisting of the (u,v,w) coordinate of the vertex being processed 1511 by the tessellation evaluation shader. The values of u, v, and w are 1512 in the range [0,1], and vary linearly across the primitive being 1513 subdivided. For tessellation primitive modes of "quads" or 1514 "isolines", the w value is always zero. The (u,v,w) coordinates are 1515 generated by the tessellation primitive generator in a manner 1516 dependent on the primitive mode, as described in section 11.1ts.2. 1517 gl_TessCoord is not an array; it specifies the location of the 1518 vertex being processed by the tessellation evaluation shader, not of 1519 any vertex in the input patch. 1520 1521 * The variables gl_TessLevelOuter[] and gl_TessLevelInner[] are arrays 1522 holding outer and inner tessellation levels of the patch, as used by 1523 the tessellation primitive generator. Tessellation level values 1524 loaded in these variables will be prior to the clamping and rounding 1525 operations performed by the primitive generator as described in 1526 Section 11.1ts.2. For triangular tessellation, gl_TessLevelOuter[3] 1527 and gl_TessLevelInner[1] will be undefined. For isoline 1528 tessellation, gl_TessLevelOuter[2], gl_TessLevelOuter[3], and both 1529 values in gl_TessLevelInner[] are undefined. 1530 1531 A tessellation evaluation shader may also declare user-defined 1532 per-vertex input variables. User-defined per-vertex input variables are 1533 declared with the qualifier "in" and have a value for each vertex in the 1534 input patch. User-defined per-vertex input varying variables have a 1535 value for each vertex and thus need to be declared as arrays or inside 1536 input blocks declared as arrays. Declaring an array size is optional. If 1537 no size is specified, it will be taken from the implementation-dependent 1538 maximum patch size (gl_MaxPatchVertices). If a size is specified, it must 1539 match the maximum patch size; otherwise, a compile or link error will 1540 occur. Since the array size may be larger than the number of vertices 1541 found in the input patch, behavior is undefined if a per-vertex input 1542 variable is accessed using an index greater than or equal to the number of 1543 vertices in the input patch. The OpenGL ES Shading Language doesn't 1544 support multi-dimensional arrays as shader inputs or outputs; therefore, 1545 user-defined tessellation evaluation shader inputs corresponding to 1546 shader outputs declared as arrays must be declared as array members of 1547 an input block that is itself declared as an array. 1548 1549 Additionally, a tessellation evaluation shader may declare per-patch 1550 input variables using the qualifier "patch in". Unlike per-vertex 1551 inputs, per-patch inputs do not correspond to any specific vertex in the 1552 patch, and are not indexed by vertex number. Per-patch inputs declared 1553 as arrays have multiple values for the input patch; similarly declared 1554 per-vertex inputs would indicate a single value for each vertex in the 1555 output patch. User-defined per-patch input variables are filled with 1556 corresponding per-patch output values written by the tessellation 1557 control shader. 1558 1559 Similarly to the limit on vertex shader output components (see section 1560 11.1.2.1), there is a limit on the number of components of per-vertex 1561 and per-patch input variables that can be read by the tessellation 1562 evaluation shader, given by the values of the implementation-dependent 1563 constants MAX_TESS_EVALUATION_INPUT_COMPONENTS_OES and 1564 MAX_TESS_PATCH_COMPONENTS_OES, respectively. The built-in inputs 1565 gl_TessLevelOuter[] and gl_TessLevelInner[] are not counted against the 1566 per-patch limit. 1567 1568 When a program is linked, all components of any input variable read by a 1569 tessellation evaluation shader will count against this limit. A program 1570 whose tessellation evaluation shader exceeds this limit may fail to 1571 link, unless device-dependent optimizations are able to make the program 1572 fit within available hardware resources. 1573 1574 Component counting rules for different variable types and variable 1575 declarations are the same as for MAX_VERTEX_OUTPUT_COMPONENTS (see 1576 section 11.1.2.1). 1577 1578 1579 Section 11.1ts.3.4, Tessellation Evaluation Shader Outputs 1580 1581 Tessellation evaluation shaders have a number of built-in output 1582 variables used to pass values to equivalent built-in input variables 1583 read by subsequent shader stages or to subsequent fixed functionality 1584 vertex processing pipeline stages. These variables are gl_Position 1585 [[ If OES_tessellation_point_size is supported: ]] 1586 and gl_PointSize, 1587 and behave identically to equivalently named vertex shader outputs (see 1588 section 11.1.3). A tessellation evaluation shader may also declare 1589 user-defined per-vertex output variables. 1590 1591 Similarly to the limit on vertex shader output components (see section 1592 11.1.2.1), there is a limit on the number of components of built-in and 1593 user-defined output variables that can be written by the tessellation 1594 evaluation shader, given by the values of the implementation-dependent 1595 constant MAX_TESS_EVALUATION_OUTPUT_COMPONENTS_OES. 1596 1597 When a program is linked, all components of any output variable written 1598 by a tessellation evaluation shader will count against this limit. A 1599 program whose tessellation evaluation shader exceeds this limit may fail 1600 to link, unless device-dependent optimizations are able to make the 1601 program fit within available hardware resources. 1602 1603 Component counting rules for different variable types and variable 1604 declarations are the same as for MAX_VERTEX_OUTPUT_COMPONENTS. (see 1605 section 11.1.2.1). 1606 1607 1608 Modify section 12.1, "Transform Feedback" 1609 1610 Replace the second paragraph of the section on p. 274 (as modified 1611 by OES_geometry_shader): 1612 1613 The data captured in transform feedback mode depends on the active 1614 programs on each of the shader stages. If a program is active for the 1615 geometry shader stage, transform feedback captures the vertices of each 1616 primitive emitted by the geometry shader. Otherwise, if a program is 1617 active for the tessellation evaluation shader stage, transform feedback 1618 captures each primitive produced by the tessellation primitive generator, 1619 whose vertices are processed by the tessellation evaluation shader. 1620 Otherwise, transform feedback captures each primitive processed by the 1621 vertex shader. 1622 1623 Modify the second paragraph following ResumeTransformFeedback on p. 277 1624 (as modified by OES_geometry_shader): 1625 1626 When transform feedback is active and not paused ... If a tessellation 1627 evaluation or geometry shader is active, the type of primitive emitted 1628 by that shader is used instead of the <mode> parameter passed to drawing 1629 commands for the purposes of this error check. If tessellation 1630 evaluation and geometry shaders are both active, the output primitive 1631 type of the geometry shader will be used for the purposes of this error. 1632 Any primitive type may be used while transform feedback is paused. 1633 1634 1635 Modify the second paragraph of section 12.2, "Primitive Queries" on p. 1636 281: 1637 1638 When BeginQuery is called with a target of PRIMITIVES_GENERATED_OES, ... 1639 This counter counts the number of primitives emitted by a geometry 1640 shader, if active, possibly further tessellated into separate primitives 1641 during the transform feedback stage, if active. 1642 1643 1644 Modify section 13.3, "Points" 1645 1646 Replace the text starting "The point size is determined ..." on p. 290: 1647 1648 The point size is determined by the last active stage before the 1649 rasterizer: 1650 1651 * the geometry shader, if active; or 1652 * the tessellation evaluation shader, if active and no geometry shader 1653 is active; 1654 * the vertex shader, otherwise. 1655 1656 If the last active stage is not a vertex shader and does not statically 1657 assign a value to gl_PointSize, the point size is 1.0. Otherwise, the 1658 point size is taken from the shader built-in gl_PointSize written by 1659 that stage. 1660 [[ Note that it is impossible to assign a value to gl_PointSize 1661 if OES_geometry_point_size or OES_tessellation_point_size is not 1662 supported and enabled in the relevant shader stages. ]] 1663 1664 If the last active stage is a vertex shader, the point size is taken 1665 from the shader built-in gl_PointSize written by the vertex shader. 1666 1667 In all cases, the point size is clamped to the implementation-dependent 1668 point size range. If the value written to gl_PointSize is less than or 1669 equal to zero, or if no value is written to gl_PointSize (except as 1670 noted above) the point size is undefined. The supported range ... 1671 1672 1673 Add new section A.3ts in Appendix A before section A.4, "Atomic Counter 1674 Invariance" on p. 405: 1675 1676 Section A.3ts, Tessellation Invariance 1677 1678 When using a program containing tessellation evaluation shaders, the 1679 fixed-function tessellation primitive generator consumes the input patch 1680 specified by an application and emits a new set of primitives. The 1681 following invariance rules are intended to provide repeatability 1682 guarantees. Additionally, they are intended to allow an application with 1683 a carefully crafted tessellation evaluation shader to ensure that the 1684 sets of triangles generated for two adjacent patches have identical 1685 vertices along shared patch edges, avoiding "cracks" caused by minor 1686 differences in the positions of vertices along shared edges. 1687 1688 Rule 1: When processing two patches with identical outer and inner 1689 tessellation levels, the tessellation primitive generator will emit an 1690 identical set of point, line, or triangle primitives as long as the 1691 active program used to process the patch primitives has tessellation 1692 evaluation shaders specifying the same tessellation mode, spacing, 1693 vertex order, and point mode input layout qualifiers. Two sets of 1694 primitives are considered identical if and only if they contain the same 1695 number and type of primitives and the generated tessellation coordinates 1696 for the vertex numbered <m> of the primitive numbered <n> are identical 1697 for all values of <m> and <n>. 1698 1699 Rule 2: The set of vertices generated along the outer edge of the 1700 subdivided primitive in triangle and quad tessellation, and the 1701 tessellation coordinates of each, depends only on the corresponding 1702 outer tessellation level and the spacing input layout qualifier in the 1703 tessellation evaluation shader of the active program. 1704 1705 Rule 3: The set of vertices generated when subdividing any outer 1706 primitive edge is always symmetric. For triangle tessellation, if the 1707 subdivision generates a vertex with tessellation coordinates of the form 1708 (0,x,1-x), (x,0,1-x), or (x,1-x,0), it will also generate a vertex with 1709 coordinates of exactly (0,1-x,x), (1-x,0,x), or (1-x,x,0), respectively. 1710 For quad tessellation, if the subdivision generates a vertex with 1711 coordinates of (x,0) or (0,x), it will also generate a vertex with 1712 coordinates of exactly (1-x,0) or (0,1-x), respectively. For isoline 1713 tessellation, if it generates vertices at (0,x) and (1,x) where <x> is 1714 not zero, it will also generate vertices at exactly (0,1-x) and (1,1-x), 1715 respectively. 1716 1717 Rule 4: The set of vertices generated when subdividing outer edges in 1718 triangular and quad tessellation must be independent of the specific 1719 edge subdivided, given identical outer tessellation levels and spacing. 1720 For example, if vertices at (x,1-x,0) and (1-x,x,0) are generated when 1721 subdividing the w==0 edge in triangular tessellation, vertices must be 1722 generated at (x,0,1-x) and (1-x,0,x) when subdividing an otherwise 1723 identical v==0 edge. For quad tessellation, if vertices at (x,0) and 1724 (1-x,0) are generated when subdividing the v==0 edge, vertices must be 1725 generated at (0,x) and (0,1-x) when subdividing an otherwise identical 1726 u==0 edge. 1727 1728 Rule 5: When processing two patches that are identical in all respects 1729 enumerated in rule 1 except for vertex order, the set of triangles 1730 generated for triangle and quad tessellation must be identical except 1731 for vertex and triangle order. For each triangle <n1> produced by 1732 processing the first patch, there must be a triangle <n2> produced when 1733 processing the second patch each of whose vertices has the same 1734 tessellation coordinates as one of the vertices in <n1>. 1735 1736 Rule 6: When processing two patches that are identical in all respects 1737 enumerated in rule 1 other than matching outer tessellation levels 1738 and/or vertex order, the set of interior triangles generated for 1739 triangle and quad tessellation must be identical in all respects except 1740 for vertex and triangle order. For each interior triangle <n1> produced 1741 by processing the first patch, there must be a triangle <n2> produced 1742 when processing the second patch each of whose vertices has the same 1743 tessellation coordinates as one of the vertices in <n1>. A triangle 1744 produced by the tessellator is considered an interior triangle if none 1745 of its vertices lie on an outer edge of the subdivided primitive. 1746 1747 Rule 7: For quad and triangle tessellation, the set of triangles 1748 connecting an inner and outer edge depends only on the inner and outer 1749 tessellation levels corresponding to that edge and the spacing input 1750 layout qualifier. 1751 1752 Rule 8: The value of all defined components of gl_TessCoord will be in 1753 the range [0,1]. Additionally, for any defined component <x> of 1754 gl_TessCoord, the results of computing (1.0-<x>) in a tessellation 1755 evaluation shader will be exact. Some floating-point values in the range 1756 [0,1] may fail to satisfy this property, but such values may never be 1757 used as tessellation coordinate components. 1758 1759 1760Dependencies on OES_shader_multisample_interpolation 1761 1762 If OES_shader_multisample_interpolation is not supported ignore all 1763 references to the "sample in" and "sample out" qualifiers. 1764 1765New State 1766 1767 Add new table 20.1ts "Current Values and Associated Data" preceding table 1768 20.2 on p. 354: 1769 1770 Default 1771 Get Value Type Get Command Value Description Sec. 1772 ------------------------ ---- -------------- --------- ------------------------ ------------ 1773 PATCH_VERTICES_OES Z+ GetIntegerv 3 Number of vertices in 10.1.7sp 1774 input patch 1775 1776 Add to table 20.19, "Program Pipeline Object State": 1777 1778 Initial 1779 Get Value Type Get Command Value Description Sec 1780 -------------------------- ---- -------------------- ------- -------------------------------- --- 1781 TESS_CONTROL_SHADER_OES Z+ GetProgramPipelineiv 0 Name of current tess. control 7.4 1782 shader program object 1783 TESS_EVALUATION_SHADER_OES Z+ GetProgramPipelineiv 0 Name of current tess. evaluation 7.4 1784 shader program object 1785 1786 Add new table 20.25ts, "Program Object State (cont.)": 1787 1788 Default 1789 Get Value Type Get Command Value Description Sec. 1790 -------------------------------- ---- ------------ --------- ------------------------ -------- 1791 TESS_CONTROL_OUTPUT_VERTICES_OES Z+ GetProgramiv 0 Output patch size 11.1ts.1 1792 for tess. control shader 1793 TESS_GEN_MODE_OES E GetProgramiv QUADS_OES Base primitive type for 11.1ts.2 1794 tess. prim. generator 1795 TESS_GEN_SPACING_OES E GetProgramiv EQUAL Spacing of tess. prim. 11.1ts.2 1796 generator edge subdivision 1797 TESS_GEN_VERTEX_ORDER_OES E GetProgramiv CCW Order of vertices in 11.1ts.2 1798 primitives generated by 1799 tess. prim generator 1800 TESS_GEN_POINT_MODE_OES B GetProgramiv FALSE Tess prim. generator 11.1ts.2 1801 emits points? 1802 1803 Add to table 20.28, "Program Object Resource State (cont.)": 1804 1805 Initial 1806 Get Value Type Get Command Value Description Sec. 1807 ---------------------------------------- ---- -------------------- ------- ----------------------- ----- 1808 REFERENCED_BY_TESS_CONTROL_SHADER_OES Z+ GetProgramResourceiv - Active resource used by 7.3.1 1809 tess. control shader? 1810 REFERENCED_BY_TESS_EVALUATION_SHADER_OES Z+ GetProgramResourceiv - Active resource used by 7.3.1 1811 tess. eval. shader? 1812 1813New Implementation Dependent State 1814 1815 Add to table 20.39 "Implementation Dependent Values": 1816 1817 Minimum 1818 Get Value Type Get Command Value Description Sec. 1819 ------------------------------------------- ---- ----------- ------- ---------------------------- ------ 1820 PRIMITIVE_RESTART_FOR_PATCHES_SUPPORTED_OES B GetBooleanv - True if primitive restart is 10.3.4 1821 supported for patches 1822 1823 Add new table 20.43ts "Implementation Dependent Tessellation Shader Limits" 1824 following table 6.31 "Implementation Dependent Vertex Shader Limits": 1825 1826 Minimum 1827 Get Value Type Get Command Value Description Sec. 1828 ------------------------- ---- ----------- ------- ------------------------------- ------ 1829 MAX_TESS_GEN_LEVEL_OES Z+ GetIntegerv 64 Max. level supported by 11.1ts.2 1830 tess. primitive generator 1831 MAX_PATCH_VERTICES_OES Z+ GetIntegerv 32 Maximum patch size 10.1 1832 MAX_TESS_CONTROL_UNIFORM_COMPONENTS_OES Z+ GetIntegerv 1024 No. of words for TCS uniforms 11.1ts.1.1 1833 MAX_TESS_EVALUATION_UNIFORM_COMPONENTS_OES Z+ GetIntegerv 1024 No. of words for TES uniforms 11.1ts.3.1 1834 MAX_TESS_CONTROL_TEXTURE_IMAGE_UNITS_OES Z+ GetIntegerv 16 No. of tex. image units for TCS 11.1.3.5 1835 MAX_TESS_EVALUATION_TEXTURE_IMAGE_UNITS_OES Z+ GetIntegerv 16 No. of tex. image units for TES 11.1.3.5 1836 MAX_TESS_CONTROL_OUTPUT_COMPONENTS_OES Z+ GetIntegerv 64 No. components for per-patch 11.1ts.1.2 1837 vertex outputs in TCS 1838 MAX_TESS_PATCH_COMPONENTS_OES Z+ GetIntegerv 120 No. components for per-patch 11.1ts.1.2 1839 output varyings for TCS 1840 MAX_TESS_CONTROL_TOTAL_OUTPUT_COMPONENTS_OES Z+ GetIntegerv 2048 Total no. components for TCS 11.1ts.1.2 1841 outputs 1842 MAX_TESS_EVALUATION_OUTPUT_COMPONENTS_OES Z+ GetIntegerv 64 No. components for per-vertex 11.1ts.3.2 1843 outputs in TES 1844 MAX_TESS_CONTROL_INPUT_COMPONENTS_OES Z+ GetIntegerv 64 No. components for per-vertex 11.1ts.1.2 1845 inputs in TCS 1846 MAX_TESS_EVALUATION_INPUT_COMPONENTS_OES Z+ GetIntegerv 64 No. components for per-vertex 11.1ts.3.2 1847 inputs in TES 1848 MAX_TESS_CONTROL_UNIFORM_BLOCKS_OES Z+ GetIntegerv 12 No. of supported uniform 7.6.2 1849 blocks for TCS 1850 MAX_TESS_EVALUATION_UNIFORM_BLOCKS_OES Z+ GetIntegerv 12 No. of supported uniform 7.6.2 1851 blocks for TES 1852 MAX_TESS_CONTROL_ATOMIC_COUNTER_BUFFERS_OES Z+ GetIntegerv 0 No. of AC (atomic counter) 7.7 1853 buffers accessed by a TCS 1854 MAX_TESS_EVALUATION_ATOMIC_COUNTER_BUFFERS_OES Z+ GetIntegerv 0 No. of AC (atomic counter) 7.7 1855 buffers accessed by a TES 1856 MAX_TESS_CONTROL_ATOMIC_COUNTERS_OES Z+ GetIntegerv 0 Number of ACs accessed by a TCS 11.1.3.6 1857 MAX_TESS_EVALUATION_ATOMIC_COUNTERS_OES Z+ GetIntegerv 0 Number of ACs accessed by a TES 11.1.3.6 1858 MAX_TESS_CONTROL_SHADER_STORAGE_BLOCKS_OES Z+ GetIntegerv 0 No. of shader storage blocks 7.8 1859 accessed by a TCS 1860 MAX_TESS_EVALUATION_SHADER_STORAGE_BLOCKS_OES Z+ GetIntegerv 0 No. of shader storage blocks 7.8 1861 accessed by a TES 1862 1863 1864 Add to table 20.46 "Implementation Dependent Aggregate Shader Limits" 1865 ([fn] is a dagger mark referring to existing text in the table caption): 1866 1867 1868 Minimum 1869 Get Value Type Get Command Value Description Sec. 1870 --------------------------------------------------- ---- ----------- ------- ----------------------------- ---------- 1871 MAX_TESS_CONTROL_IMAGE_UNIFORMS_OES Z+ GetIntegerv 0 No. of image variables in TCS 11.1.3.7 1872 in TCS 1873 MAX_TESS_EVALUATION_IMAGE_UNIFORMS_OES Z+ GetIntegerv 0 No. of image variables in TES 11.1.3.7 1874 MAX_COMBINED_TESS_CONTROL_UNIFORM_COMPONENTS_OES Z+ GetIntegerv [fn] No. of words for TCS uniform 11.1ts.1.1 1875 variables in all uniform 1876 blocks (including default) 1877 MAX_COMBINED_TESS_EVALUATION_UNIFORM_COMPONENTS_OES Z+ GetIntegerv [fn] No. of words for TES uniform 11.1ts.3.1 1878 variables in all uniform 1879 blocks (including default) 1880 1881 Modify existing entries in table 20.46: 1882 1883 Minimum 1884 Get Value Type Get Command Value Description Sec. 1885 -------------------------------------------- ---- ----------- ------- -------------------------- ------- 1886 MAX_UNIFORM_BUFFER_BINDINGS Z+ GetIntegerv 72 Max. no. of uniform buffer 7.6.2 1887 binding points 1888 MAX_COMBINED_UNIFORM_BLOCKS Z+ GetIntegerv 60 Max. no. of uniform 7.6.2 1889 buffers per program 1890 MAX_COMBINED_TEXTURE_IMAGE_UNITS Z+ GetIntegerv 96 Total no. of tex. units 11.1.3.5 1891 accessible by the GL 1892 1893Additions to the OpenGL ES Shading Language 3.10 Specification 1894 1895 Including the following line in a shader can be used to control the 1896 language features described in this extension: 1897 1898 #extension GL_OES_tessellation_shader : <behavior> 1899 #extension GL_OES_tessellation_point_size : <behavior> 1900 1901 where <behavior> is as specified in section 3.4. 1902 1903 A new preprocessor #define is added to the OpenGL ES Shading Language: 1904 1905 #define GL_OES_tessellation_shader 1 1906 #define GL_OES_tessellation_point_size 1 1907 1908 If the OES_tessellation_shader extension is enabled, the 1909 OES_shader_io_blocks extension is also implicitly enabled. 1910 1911 1912 Change the introduction to Chapter 2 "Overview of OpenGL ES Shading" as 1913 follows: 1914 1915 The OpenGL ES Shading Language is actually several closely related 1916 languages. These languages are used to create shaders for each of the 1917 programmable processors contained in the OpenGL ES processing pipeline. 1918 Currently, these processors are the compute, vertex, tessellation 1919 control, tessellation evaluation, geometry, and fragment processors. 1920 1921 Unless otherwise noted in this Specification, a language feature applies 1922 to all languages, and common usage will refer to these languages as a 1923 single language. The specific languages will be referred to by the name 1924 of the processor they target: compute, vertex, tessellation control, 1925 tessellation evalution, geometry, or fragment. 1926 1927 1928 Add new subsections 2.ts1 and 2.ts2 preceding subsection 2.gs "Geometry 1929 Processor": 1930 1931 Section 2.ts1, Tessellation Control Processor 1932 1933 The <tessellation control processor> is a programmable unit that 1934 operates on a patch of incoming vertices and their associated data, 1935 emitting a new output patch. Compilation units written in the OpenGL ES 1936 Shading Language to run on this processor are called tessellation 1937 control shaders. When a tessellation control shader is compiled and 1938 linked, it results in a tessellation control shader executable that runs 1939 on the tessellation control processor. 1940 1941 The tessellation control processor is invoked for each each vertex of 1942 the output patch. Each invocation can read the attributes of any vertex 1943 in the input or output patches, but can only write per-vertex attributes 1944 for the corresponding output patch vertex. The shader invocations 1945 collectively produce a set of per-patch attributes for the output patch. 1946 After all tessellation control shader invocations have completed, the 1947 output vertices and per-patch attributes are assembled to form a patch 1948 to be used by subsequent pipeline stages. 1949 1950 Tessellation control shader invocations run mostly independently, with 1951 undefined relative execution order. However, the built-in function 1952 barrier() can be used to control execution order by synchronizing 1953 invocations, effectively dividing tessellation control shader execution 1954 into a set of phases. Tessellation control shaders will get undefined 1955 results if one invocation reads a per-vertex or per-patch attribute 1956 written by another invocation at any point during the same phase, or if 1957 two invocations attempt to write different values to the same per-patch 1958 output in a single phase. 1959 1960 Section 2.ts2, Tessellation Evaluation Processor 1961 1962 The <tessellation evaluation processor> is a programmable unit that 1963 evaluates the position and other attributes of a vertex generated by the 1964 tessellation primitive generator, using a patch of incoming vertices and 1965 their associated data. Compilation units written in the OpenGL ES 1966 Shading Language to run on this processor are called tessellation 1967 evaluation shaders. When a tessellation evaluation shader is compiled 1968 and linked, it results in a tessellation evaluation shader executable 1969 that runs on the tessellation evaluation processor. 1970 1971 Each invocation of the tessellation evaluation executable computes the 1972 position and attributes of a single vertex generated by the tessellation 1973 primitive generator. The executable can read the attributes of any 1974 vertex in the input patch, plus the tessellation coordinate, which is 1975 the relative location of the vertex in the primitive being tessellated. 1976 The executable writes the position and other attributes of the vertex. 1977 1978 1979 Modifications to Section 3.7 (Keywords) 1980 1981 Remove "patch" from the list of reserved keywords and add it to the list 1982 of keywords. 1983 1984 1985 Modify Section 4.3, Storage Qualifiers 1986 1987 Add two new qualifiers to the storage qualifier table on p. 38: 1988 1989 Qualifier Meaning 1990 --------- ------------------------------------------------------------- 1991 patch in linkage of per-patch attributes into a shader from a previous 1992 stage (tessellation evaluation shaders only) 1993 1994 patch out linkage out of a shader to a subsequent stage (tessellation 1995 control shaders only) 1996 1997 1998 Modify section 4.3.4, Input Variables 1999 2000 Replace the paragraphs starting with "Geometry shader input variables 2001 get ..." and ending with "Fragment shader inputs get ..." on p. 40: 2002 2003 Tessellation control, evaluation, and geometry shader input variables 2004 get the per-vertex values written out by output variables of the same 2005 names in the previous active (vertex) shader stage. For these inputs, 2006 "centroid in", "sample in", and interpolation qualifiers are allowed, 2007 but are equivalent to "in". Since these shader stages operate on a set 2008 of vertices, each input variable or input block (see section 4.3.9 2009 "Interface Blocks") needs to be declared as an array. For example, 2010 2011 in float foo[]; // geometry shader input for vertex "out float foo" 2012 2013 Each element of such an array corresponds to one vertex of the primitive 2014 being processed. Each array can optionally have a size declared. The 2015 array size will be set by (or if provided must be consistent with) the 2016 input layout declaration(s) establishing the type of input primitive, as 2017 described later in section 4.4.1 "Input Layout Qualifiers". 2018 2019 Some inputs and outputs are <arrayed>, meaning that for an interface 2020 between two shader stages either the input or output declaration 2021 requires an extra level of array indexing for the declarations to match. 2022 For example, with the interface between a vertex shader and a geometry 2023 shader, vertex shader output variables and geometry shader input 2024 variables of the same name must match in type and qualification (other 2025 than precision and "out" matching to "in"), except that the geometry 2026 shader will have one more array dimension than the vertex shader, to 2027 allow for vertex indexing. If such an arrayed interface variable is not 2028 declared with the necessary additional input or output array dimension, 2029 a link-time error will result. 2030 2031 For non-arrayed interfaces (meaning array dimensionally stays the same 2032 between stages), it is a link-time error if the input variable is not 2033 declared with the same type, including array dimensionality, and 2034 qualification (other than precision and "out" matching to "in") as the 2035 matching output variable. 2036 2037 Additionally, tessellation evaluation shaders support per-patch input 2038 variables declared with the "patch in" qualifier. Per-patch input 2039 variables are filled with the values of per-patch output variables 2040 written by the tessellation control shader. Per-patch inputs may be 2041 declared as one-dimensional arrays, but are not indexed by vertex 2042 number. Applying the "patch in" qualifier to inputs can only be done in 2043 tessellation evaluation shaders. As with other input variables, 2044 per-patch inputs must be declared using the same type and qualification 2045 (other than precision and "out" matching to "in") as per-patch outputs 2046 from the previous (tessellation control) shader stage. 2047 2048 It is a compile-time error to use the "patch in" qualifier with inputs 2049 in any type of shader other than tessellation evaluation. 2050 2051 Fragment shader inputs get ... 2052 2053 2054 Modify section 4.3.6 "Output Variables" starting with the third 2055 paragraph of the section, on p. 42: 2056 2057 Vertex, tessellation evaluation, and geometry output variables output 2058 per-vertex data and are declared using the "out", "centroid out", or 2059 "sample out" storage qualifiers. Applying the "patch out" qualifier to 2060 an output can only be done in tessellation control shaders. Output 2061 variables can only be floating-point scalars, floating-point vectors, 2062 matrices, signed or unsigned integers or integer vectors, or arrays or 2063 structures of any of these. 2064 2065 It is a compile-time error to use the "patch out" qualifier with outputs 2066 in any other type of shader other than tessellation control. 2067 2068 Individual vertex, tessellation control, tessellation evaluation, and 2069 geometry outputs are declared as in the following examples: ... 2070 2071 2072 Following this modified language and leading into the last paragraph of 2073 section 4.3.6 on p. 37 (starting "Fragment outputs output 2074 per-fragment"), add: 2075 2076 Tessellation control shader output variables are used to output 2077 per-vertex and per-patch data. Per-vertex output variables are arrayed 2078 (see "arrayed" in section 4.3.4, "Inputs") and declared using the "out", 2079 "centroid out", or "sample out" qualifiers; the "patch out" qualifier is 2080 not allowed. Per-patch output variables must be declared using the 2081 "patch out" qualifier. Per-vertex and per-patch output variables can 2082 only be floating-point scalars, vectors, or matrices, signed or unsigned 2083 integers or integer vectors, or arrays or structures of these. Since 2084 tessellation control shaders produce an arrayed primitive comprising 2085 multiple vertices, each per-vertex output variable (or output block, see 2086 interface blocks below) needs to be declared as an array. For example, 2087 2088 out float foo[]; // feeds next stage input "in float foo[]" 2089 2090 Each element of such an array corresponds to one vertex of the primitive 2091 being produced. Each array can optionally have a size declared. The 2092 array size will be set by (or if provided must be consistent with) the 2093 output layout declaration(s) establishing the number of vertices in the 2094 output patch, as described later in section 4.4.2.ts "Tessellation 2095 Control Outputs". 2096 2097 Each tessellation control shader invocation has a corresponding output 2098 patch vertex, and may assign values to per-vertex outputs only if they 2099 belong to that corresponding vertex. If a per-vertex output variable is 2100 used as an l-value, it is a compile- or link-time error if the expression 2101 indicating the vertex index is not the identifier gl_InvocationID. 2102 2103 The order of execution of a tessellation control shader invocation 2104 relative to the other invocations for the same input patch is undefined 2105 unless the built-in function barrier() is used. This provides some 2106 control over relative execution order. When a shader invocation calls 2107 barrier(), its execution pauses until all other invocations have reached 2108 the same point of execution. Output variable assignments performed by 2109 any invocation executed prior to calling barrier() will be visible to 2110 any other invocation after the call to barrier() returns. 2111 2112 Because tessellation control shader invocations execute in undefined 2113 order between barriers, the values of per-vertex or per-patch output 2114 variables will sometimes be undefined. Consider the beginning and end of 2115 shader execution and each call to barrier() as synchronization points. 2116 The value of an output variable will be undefined in any of the three 2117 following cases: 2118 2119 1. At the beginning of execution. 2120 2121 2. At each synchronization point, unless 2122 * the value was well-defined after the previous synchronization point 2123 and was not written by any invocation since, or 2124 * the value was written by exactly one shader invocation since the 2125 previous synchronization point, or 2126 * the value was written by multiple shader invocations since the 2127 previous synchronization point, and the last write performed by all 2128 such invocations wrote the same value. 2129 3. When read by a shader invocation, if 2130 * the value was undefined at the previous synchronization point and 2131 has not been writen by the same shader invocation since, or 2132 * the output variable is written to by any other shader invocation 2133 between the previous and next synchronization points, even if that 2134 assignment occurs in code following the read. 2135 2136 Fragment outputs output per-fragment data and are declared ... 2137 2138 2139 Modify section 4.4.1 "Input Layout Qualifiers" to add new subsections 2140 4.4.1.ts and 4.4.2.ts, preceding the new subsection 4.4.1.gs "Geometry 2141 Shader Inputs": 2142 2143 Section 4.4.1.ts, Tessellation Evaluation Inputs 2144 2145 Additional input layout qualifier identifiers allowed for tessellation 2146 evaluation shaders are: 2147 2148 <layout-qualifier-id> 2149 triangles 2150 quads 2151 isolines 2152 equal_spacing 2153 fractional_even_spacing 2154 fractional_odd_spacing 2155 cw 2156 ccw 2157 point_mode 2158 2159 One group of these identifiers, <primitive mode>, is used to specify a 2160 tessellation primitive mode to be used by the tessellation primitive 2161 generator. To specify a primitive mode, the identifier must be one of 2162 "triangles", "quads", or "isolines", which specify that the tessellation 2163 primitive generator should subdivide a triangle into smaller triangles, 2164 a quad into triangles, or a quad into a collection of lines, 2165 respectively. 2166 2167 A second group of these identifiers, <vertex spacing>, is used to 2168 specify the spacing used by the tessellation primitive generator when 2169 subdividing an edge. To specify vertex spacing, the identifier must be 2170 one of: 2171 2172 * "equal_spacing", signifying that edges should be divided into a 2173 collection of <N> equal-sized segments; 2174 2175 * "fractional_even_spacing", signifying that edges should be divided 2176 into an even number of equal-length segments plus two additional 2177 shorter "fractional" segments; or 2178 2179 * "fractional_odd_spacing", signifying that edges should be divided 2180 into an odd number of equal-length segments plus two additional 2181 shorter "fractional" segments. 2182 2183 A third subset of these identifiers, <ordering>, specifies whether the 2184 tessellation primitive generator produces triangles in clockwise or 2185 counter-clockwise order, according to the coordinate system depicted in 2186 the OpenGL ES Specification. The identifiers "cw" and "ccw" indicate 2187 clockwise and counter-clockwise triangles, respectively. If the 2188 tessellation primitive generator does not produce triangles, the order 2189 is ignored. 2190 2191 Finally, <point mode> is specified with the identifier "point_mode" 2192 indicating that the tessellation primitive generator should produce one 2193 point for each distinct vertex in the subdivided primitive, rather than 2194 generating lines or triangles. 2195 2196 Any or all of these identifiers may be specified one or more times in a 2197 single input layout declaration. 2198 2199 The tessellation evaluation shader object in a program must declare a 2200 primitive mode in its input layout. Declaring vertex spacing, ordering, 2201 or point mode identifiers is optional. If spacing or vertex order 2202 declarations are omitted, the tessellation primitive generator will use 2203 equal spacing or counter-clockwise vertex ordering, respectively. If a 2204 point mode declaration is omitted, the tessellation primitive generator 2205 will produce lines or triangles according to the primitive mode. 2206 2207 2208 Section 4.4.2.ts, Tessellation Control Outputs 2209 2210 Other than for the transform feedback layout qualifiers, tessellation 2211 control shaders allow output layout qualifiers only on the interface 2212 qualifier "out", not on an output block, block member, or variable 2213 declaration. The output layout qualifier identifiers allowed for 2214 tessellation control shaders are: 2215 2216 layout-qualifier-id 2217 vertices = integer-constant 2218 2219 The identifier "vertices" specifies the number of vertices in the output 2220 patch produced by the tessellation control shader, which also specifies 2221 the number of times the tessellation control shader is invoked. It is a 2222 compile- or link-time error for the output vertex count to be less than 2223 or equal to zero, or greater than the implementation-dependent maximum 2224 patch size. 2225 2226 The intrinsically declared tessellation control output array gl_out[] 2227 will also be sized by any output layout declaration. Hence, the 2228 expression 2229 2230 gl_out.length() 2231 2232 will return the output patch vertex count specified in a previous output 2233 layout qualifier. For outputs declared without an array size, including 2234 intrinsically declared outputs (i.e., gl_out), a layout must be declared 2235 before any use of the method length() or other array use that requires 2236 its size to be known. 2237 2238 It is a compile-time error if the output patch vertex count specified in 2239 an output layout qualifier does not match the array size specified in 2240 any output variable declaration in the same shader. 2241 2242 All tessellation control shader layout declarations in a program must 2243 specify the same output patch vertex count. There must be at least one 2244 layout qualifier specifying an output patch vertex count in any program 2245 containing a tessellation control shader. 2246 2247 2248 Modify section 7 to add new subsections 7.1ts1 and 7.1ts2 following 2249 section 7.1.1 "Vertex Shader Special Variables": 2250 2251 Section 7.1ts1, Tessellation Control Special Variables 2252 2253 In the tessellation control language, built-in variables are 2254 intrinsically declared as: 2255 2256 [[ If OES_tessellation_point_size is supported and enabled: ]] 2257 in gl_PerVertex { 2258 highp vec4 gl_Position; 2259 hihgp float gl_PointSize; 2260 } gl_in[gl_MaxPatchVertices]; 2261 2262 [[ Otherwise: ]] 2263 in gl_PerVertex { 2264 highp vec4 gl_Position; 2265 } gl_in[gl_MaxPatchVertices]; 2266 2267 in highp int gl_PatchVerticesIn; 2268 in highp int gl_PrimitiveID; 2269 in highp int gl_InvocationID; 2270 2271 [[ If OES_tessellation_point_size is supported and enabled: ]] 2272 out gl_PerVertex { 2273 highp vec4 gl_Position; 2274 highp float gl_PointSize; 2275 } gl_out[]; 2276 2277 [[ Otherwise: ]] 2278 out gl_PerVertex { 2279 highp vec4 gl_Position; 2280 } gl_out[]; 2281 2282 patch out highp float gl_TessLevelOuter[4]; 2283 patch out highp float gl_TessLevelInner[2]; 2284 2285 2286 Section 7.1ts1.1, Tessellation Control Input Variables 2287 2288 gl_Position contains the output written in the previous shader stage to 2289 gl_Position. 2290 2291 [[ If OES_tessellation_point_size is supported: ]] 2292 gl_PointSize contains the output written in the previous shader stage to 2293 gl_PointSize. 2294 2295 gl_PatchVerticesIn contains the number of vertices in the input patch 2296 being processed by the shader. A single shader can read patches of 2297 differing sizes, so the value of gl_PatchVerticesIn may differ between 2298 patches. 2299 2300 gl_PrimitiveID contains the number of primitives processed by the 2301 shader since the current set of rendering primitives was started. 2302 2303 gl_InvocationID contains the number of the output patch vertex assigned 2304 to the tessellation control shader invocation. It is assigned integer 2305 values in the range [0, N-1], where N is the number of output patch 2306 vertices per primitive. 2307 2308 2309 Section 7.1ts1.2, Tessellation Control Output Variables 2310 2311 gl_Position is used in the same fashion as the 2312 corresponding output variable in the vertex shader. 2313 2314 [[ If OES_tessellation_point_size is supported: ]] 2315 gl_PointSize is used in the same fashion as the corresponding output 2316 variable in the vertex shader. 2317 2318 The values written to gl_TessLevelOuter and gl_TessLevelInner are 2319 assigned to the corresponding outer and inner tessellation levels of the 2320 output patch. They are used by the tessellation primitive generator to 2321 control primitive tessellation, and may be read by tessellation 2322 evaluation shaders. 2323 2324 2325 Section 7.1ts2, Tessellation Evaluation Special Variables 2326 2327 In the tessellation evaluation language, built-in variables are 2328 intrinsically declared as: 2329 2330 [[ If OES_tessellation_point_size is supported and enabled: ]] 2331 in gl_PerVertex { 2332 highp vec4 gl_Position; 2333 highp float gl_PointSize; 2334 } gl_in[gl_MaxPatchVertices]; 2335 2336 [[ Otherwise: ]] 2337 in gl_PerVertex { 2338 highp vec4 gl_Position; 2339 } gl_in[gl_MaxPatchVertices]; 2340 2341 in highp int gl_PatchVerticesIn; 2342 in highp int gl_PrimitiveID; 2343 in highp vec3 gl_TessCoord; 2344 patch in highp float gl_TessLevelOuter[4]; 2345 patch in highp float gl_TessLevelInner[2]; 2346 2347 [[ If OES_tessellation_point_size is supported and enabled: ]] 2348 out gl_PerVertex { 2349 highp vec4 gl_Position; 2350 hihgp float gl_PointSize; 2351 }; 2352 2353 [[ Otherwise: ]] 2354 out gl_PerVertex { 2355 highp vec4 gl_Position; 2356 }; 2357 2358 Section 7.1ts2.1, Tessellation Evaluation Input Variables 2359 2360 gl_Position contains the output written in the previous shader stage to 2361 gl_Position. 2362 2363 [[ If OES_tessellation_point_size is supported: ]] 2364 gl_PointSize contains the output written in the previous shader stage to 2365 gl_PointSize. 2366 2367 gl_PatchVerticesIn and gl_PrimitiveID are defined in the same fashion as 2368 the corresponding input variables in the tessellation control shader. 2369 2370 gl_TessCoord specifies a three-component (u,v,w) vector identifying the 2371 position of the vertex being processed by the shader relative to the 2372 primitive being tessellated. Its values will obey the properties 2373 2374 gl_TessCoord.x == 1.0 - (1.0 - gl_TessCoord.x) // two operations performed 2375 gl_TessCoord.y == 1.0 - (1.0 - gl_TessCoord.y) // two operations performed 2376 gl_TessCoord.z == 1.0 - (1.0 - gl_TessCoord.z) // two operations performed 2377 2378 gl_TessLevelOuter and gl_TessLevelInner are filled with the corresponding 2379 output variables written by the active tessellation control shader. 2380 2381 2382 Section 7.1ts2.2, Tessellation Evaluation Output Variables 2383 2384 gl_Position is used in the same fashion as the 2385 corresponding output variable in the vertex shader. 2386 2387 [[ If OES_tessellation_point_size is supported: ]] 2388 gl_PointSize is used in the same fashion as the corresponding output 2389 variable in the vertex shader. 2390 2391 2392 Add to Section 7.2 "Built-In Constants", matching the 2393 corresponding API implementation-dependent limits: 2394 2395 const mediump int gl_MaxTessControlInputComponents = 64; 2396 const mediump int gl_MaxTessControlOutputComponents = 64; 2397 const mediump int gl_MaxTessControlTextureImageUnits = 16; 2398 const mediump int gl_MaxTessControlUniformComponents = 1024; 2399 const mediump int gl_MaxTessControlTotalOutputComponents = 2048; 2400 2401 const mediump int gl_MaxTessEvaluationInputComponents = 64; 2402 const mediump int gl_MaxTessEvaluationOutputComponents = 64; 2403 const mediump int gl_MaxTessEvaluationTextureImageUnits = 16; 2404 const mediump int gl_MaxTessEvaluationUniformComponents = 1024; 2405 2406 const mediump int gl_MaxTessPatchComponents = 120; 2407 2408 const mediump int gl_MaxPatchVertices = 32; 2409 const mediump int gl_MaxTessGenLevel = 64; 2410 2411 Modify gl_MaxCombinedTextureImageUnits to match the API: 2412 2413 const mediump int gl_MaxCombinedTextureImageUnits = 96; 2414 2415 2416 Modify section 8.15 "Shader Invocation Control Functions": 2417 2418 The shader invocation control function is only available in tessellation 2419 control and compute shaders. It is used to control the relative 2420 execution order of multiple shader invocations used to process a patch 2421 (in the case of tessellation control shaders) or a workgroup (in 2422 the case of compute shaders), which are otherwise executed with an 2423 undefined order. 2424 2425 +------------------+---------------------------------------------------------------+ 2426 | Syntax | Description | 2427 +------------------+---------------------------------------------------------------+ 2428 | void | For any given static instance of barrier(), all | 2429 | barrier(void) | tessellation control shader invocations for a single input | 2430 | | patch, or all compute shader invocations for a single work | 2431 | | group must enter it before any will continue beyond it. | 2432 +------------------+---------------------------------------------------------------+ 2433 2434 The function barrier() provides a partially defined order of execution 2435 between shader invocations. This ensures that values written by one 2436 invocation prior to a given static instance of barrier() can be safely 2437 read by other invocations after their call to the same static instance 2438 barrier(). Because invocations may execute in an undefined order between 2439 these barrier calls, the values of a per-vertex or per-patch output 2440 variable for tessellation control shaders, or the values of shared 2441 variables for compute shaders will be undefined in a number of cases 2442 enumerated in section 4.3.6 "Output Variables" (for tessellation control 2443 shaders) and section 4.3.7 "Shared Variables" (for compute shaders). 2444 2445 For tessellation control shaders, the barrier() function may only be 2446 placed inside the function main() of the shader and may not be called 2447 within any control flow. Barriers are also disallowed after a return 2448 statement in the function main(). Any such misplaced barriers result in 2449 a compile-time error. 2450 2451 For compute shaders, the barrier() function ... 2452 2453 2454Issues 2455 2456 Note: These issues apply specifically to the definition of the 2457 OES_tessellation_shader specification, which is based on the OpenGL 2458 extension ARB_tessellation_shader as updated in OpenGL 4.x. Resolved 2459 issues from ARB_tessellation_shader have been removed, but remain 2460 largely applicable to this extension. ARB_tessellation_shader can be 2461 found in the OpenGL Registry. 2462 2463 (1) What functionality was removed from ARB_tessellation_shader? 2464 2465 Very little. Tessellation shaders are largely self-contained 2466 functionality and the only removed interactions with features not 2467 supported by the underlying OpenGL ES 3.1 API and Shading Language 2468 were: 2469 * Fixed-function inputs and outputs present only in the GL 2470 compatibility profile. 2471 * gl_ClipDistance shader inputs and outputs. 2472 * While multi-dimensional arrays are supported by GLSL-ES 3.10, 2473 they are explicitly not supported 2474 as shader inputs and outputs, and that decision is respected 2475 here. 2476 * Using a tessellation evaluation shader without a tessellation 2477 control shader is not allowed. See issue 13. 2478 * PATCH_DEFAULT_*_LEVEL parameters (issue 13). 2479 2480 (2) What functionality was changed and added relative to 2481 ARB_tessellation_shader? 2482 2483 - OES_tessellation_shader closely matches OpenGL 4.4 tessellation 2484 shader language, rather than ARB_tessellation_shader language. 2485 - Spec language is now based off of changes introduced by 2486 OES_geometry_shader, especially with regard to input and output 2487 blocks. 2488 - Note that although this spec mentions quad primitives repeatedly, 2489 this is not inconsistent with the lack of support for QUADS drawing 2490 primitives in OpenGL ES. The quad primitives discussed here occur 2491 only during patch tessellation and are emitted as triangles to later 2492 stages of the pipeline. 2493 - Writing point size from tessellation shaders is optional functionality. 2494 If it's not supported or written, the point size of 1.0 is used. 2495 - Added precision qualifiers to builtins. 2496 - ARB_tessellation_shader required that the tessellation primitive 2497 generator reject a patch when any outer tessellation level contained a 2498 NaN, even if the outer tessellation level is irrelevant for the 2499 primitive type. As that was likely unintended (see Khronos bug 11484), 2500 OES_tessellation_shader only rejects patches if relevant outer 2501 tessellation levels contain NaN. 2502 - Added program interface query properties relevant to tessellation 2503 shaders. 2504 2505 (3) Are any grammar additions required in chapter 9? 2506 2507 Probably, but such changes are not included in the original 2508 ARB_tessellation_shader extension, either. TBD. 2509 2510 (4) Should GetActiveUniformBlockiv 2511 support queries for uniform blocks and atomic counter buffers 2512 referenced by tessellation shaders? 2513 2514 RESOLVED: No. Use the new generic query interface supported by 2515 OpenGL ES 3.1, following the resolution for other features such as 2516 compute shaders, which also dropped these legacy tokens / queries. 2517 2518 (5) How are aggregate shader limits computed? 2519 2520 RESOLVED: Following the GL 4.4 model, but we restrict uniform 2521 buffer bindings to 12/stage instead of 14, this results in 2522 2523 MAX_UNIFORM_BUFFER_BINDINGS = 72 2524 This is 12 bindings/stage * 6 shader stages, allowing a static 2525 partitioning of the bindings even though at most 5 stages can 2526 appear in a program object). 2527 MAX_COMBINED_UNIFORM_BLOCKS = 60 2528 This is 12 blocks/stage * 5 stages, since compute shaders can't 2529 be mixed with other stages. 2530 MAX_COMBINED_TEXTURE_IMAGE_UNITS = 96 2531 This is 16 textures/stage * 6 stages. 2532 2533 Khronos internal bugs 5870, 8891, and 9424 cover the ARB's thinking on 2534 these limits for GL 4.0 and beyond. 2535 2536 (6) Are arrays supported as shader inputs and outputs? 2537 2538 RESOLVED: No. In several places in the tessellation and geometry API 2539 language based on GL 4.4, it says that "the OpenGL ES Shading Language 2540 doesn't support multi-dimensional arrays" and restricts declarations of 2541 inputs and outputs which are array members to blocks themselves declared 2542 as arrays. 2543 2544 Strictly speaking this is no longer true. GLSL-ES 3.10 supports 2545 multi-dimensional arrays, but also notes in issue 0 that "arrays of 2546 arrays are not allowed as shader inputs or outputs." 2547 2548 Given this constraint, and since the same constraint is in OpenGL 4.4, I 2549 propose we resolve this by continuing to limit array inputs and outputs 2550 in this fashion, and change the language to "...doesn't support 2551 multi-dimensional arrays as shader inputs or outputs". 2552 2553 (7) What component counting rules are used for inputs and outputs? 2554 2555 RESOLVED: In several places I've inserted language from OpenGL 4.4 to 2556 the effect of 2557 2558 "Component counting rules for different variable types and variable 2559 declarations are the same as for MAX_VERTEX_OUTPUT_COMPONENTS (see 2560 section 11.1.2.1)." 2561 2562 I think this is essentially cleaning up an oversight in the earlier ARB 2563 extension language but it is a bit orthogonal to the extension 2564 functionality and I'm bringing it up in case this is a potential issue. 2565 2566 (8) What component counting rules are used for the default 2567 uniform block? 2568 2569 RESOLVED: In several places I've inserted language from OpenGL 4.2 to 2570 the effect of 2571 2572 "A uniform matrix in the default uniform block with single-precision 2573 components will consume no more than 4 x min(r,c) uniform 2574 components." 2575 2576 This is based on bug 5432 and is language that was later expanded in 2577 OpenGL 4.4 and refactored into the generic "Uniform Variables" section, 2578 which is something we should consider in the OES extensions as well to 2579 avoid duplication. I believe it is what we want but am noting it for the 2580 same reason as the language in issue (8). I'm hoping to be able to 2581 include this refactored language into the OpenGL ES 3.1 Specification, 2582 so we can refer to it more easily here. Tracking bug 11192 has been 2583 opened for this and this language was approved there. 2584 2585 (9) The edits on section 4.4.1.ts (Tessellation Evaluation Inputs) 2586 says that "Any or all of these identifiers may be specified one or more 2587 times in a single input layout declaration." Do we need to add in the 2588 language from GLSL 4.40 Section 4.4 "Layout Qualifiers" that defines this? 2589 2590 RESOLVED: ES 3.1 will be picking up the relaxed qualifier ordering 2591 and it is presumed that this language will be coming along with it. 2592 In any case, the OES_shader_io_blocks extension clarifies this. 2593 2594 (10) Due to HW limitations, some vendors may not be able 2595 to support writing gl_PointSize from tessellation shaders, how should we 2596 accomodate this? 2597 2598 RESOLVED: There are two extensions described in this document. The 2599 base extension does not support writing to gl_PointSize from tessellation 2600 shaders and the gl_PerVertex block does not include gl_PointSize. 2601 Additionally there is a layered extension which provides the ability 2602 to write to gl_PointSize from tessellation shaders. When this extension 2603 is enabled, the gl_PerVertex block does include gl_PointSize and it 2604 can be written from a tessellation control or evaluation shader as normal. 2605 2606 If the point-size extension is not supported, all points written 2607 from a tessellation shader will have size of one. If the point-size 2608 extension is supported but not enabled, or if it's enabled but 2609 gl_PointSize is not written, it as if a point size of one was written. 2610 Otherwise, if you statically assign gl_PointSize in the last stage 2611 before the rasterizer, the (potentially clamped) value written will 2612 determine the size of the point for rasterization. 2613 2614 (11) Do we need a separate point_size extension from the one included 2615 in OES_geometry_shader or can we use the some one? 2616 2617 RESOLVED. We will use a separate extension to allow for maximum 2618 implementation flexibility. 2619 2620 (12) Can a tessellation evaluation shader be used without a tessellation 2621 control shader? 2622 2623 RESULT: No. This isn't allowed in other graphics APIs, and some vendors 2624 designed hardware based on those APIs. Attempts to draw with only one of the 2625 two tessellation shaders active results in an INVALID_OPERATION error. 2626 Vendors that designed hardware for ARB_tessellation_shader or versions of 2627 OpenGL that included it may choose to relax this restriction via extension. 2628 One implication of this is that the default tessellation levels are useless, 2629 since an active tessellation control shader always overrides them, so they 2630 are not included in this spec. 2631 2632 (13) What happens if you use "patch out" in a tessellation evaluation 2633 shader or "patch in" in a tessellation control shader? 2634 2635 RESOLVED. GLSL 4.40 spec only says "Applying the patch qualifier to 2636 inputs can only be done in tessellation evaluation shaders." and 2637 "Applying patch to an output can only be done in a tessellation control 2638 shader." There is also a statement that says "It is a compile-time error 2639 to use patch in a fragment shader." In Bug 11527 the ARB decided this 2640 should be a compile-time error as this can be determined by solely by 2641 looking at variable declaration. 2642 2643 (14) Do we need to make accommodations for tile-based implementations? 2644 2645 RESOLVED. Yes, but it will be done as a separate extension as it is 2646 applicable to more than just tessellation shaders. 2647 2648 (15) Can inputs and outputs from tessellation shaders be arrays of 2649 structures? 2650 2651 RESOLVED. Yes they can. OpenGL ES 3.1 disallows passing arrays of 2652 structures between stages. However, since vertex shader outputs 2653 can be structures we need to add the extra level of 2654 array-ness when these are accessed from a tessellation control shader. 2655 Similarly this applies to outputs from a tessellation control shader 2656 and inputs to a tessellation evaluation shader. However as in GL, 2657 arrays of arrays are not supported. 2658 2659 (16) Tessellation using "point_mode" is supposed to emit each distinct 2660 vertex produced by the tessellation primitive generator exactly once. 2661 Are there cases where this can produce multiple vertices with the same 2662 position? 2663 2664 RESOLVED: Yes. If fractional odd spacing is used, we have outer 2665 tessellation levels that are greater than 1.0, and inner tessellation 2666 levels less than or equal to 1.0, this can occur. If any outer level is 2667 greater than 1.0, we will subdivide the outer edges of the patch, and 2668 will need a subdivided patch interior to connect to. We handle this by 2669 treating inner levels less than or equal to 1.0 as though they were 2670 slightly greater than 1.0 ("1+epsilon"). 2671 2672 With fractional odd spacing, inner levels between 1.0 and 3.0 will 2673 produce a three-segment subdivision, with one full-size interior segment 2674 and two smaller ones on the outside. The following figure illustrates 2675 what happens to quad tessellation if the horizontal inner LOD (IL0) goes 2676 from 3.0 toward 1.0 in fractional odd mode: 2677 2678 IL0==3 IL0==2 IL0=1.5 IL0=1.2 2679 +-----------+ +-----------+ +-----------+ +-----------+ 2680 | | | | | | | | 2681 | +---+ | | +-----+ | | +-------+ | |+---------+| 2682 | | | | | | | | | | | | || || 2683 | | | | | | | | | | | | || || 2684 | +---+ | | +-----+ | | +-------+ | |+---------+| 2685 | | | | | | | | 2686 +-----------+ +-----------+ +-----------+ +-----------+ 2687 2688 As the inner level approaches 1.0, the vertical inner edges in this 2689 example get closer and closer to the outer edge. The distance between 2690 the inner and outer vertical edges approaches zero for an inner level of 2691 1+epsilon, and the positions of vertices produced by subdividing such 2692 edges may be numerically indistinguishable. 2693 2694 2695Revision History 2696 2697 Rev. Date Author Changes 2698 ---- ---------- --------- ------------------------------------------------- 2699 7 12/10/2018 Jon Leech Use 'workgroup' consistently throughout (Bug 2700 11723, internal API issue 87). 2701 2702 6 05/31/2016 Jon Leech Note that primitive ID counters are reset to zero 2703 after each instance drawn (Bug 14024). 2704 2705 5 04/29/2016 Jon Leech Fix GLSL-ES built-in constants to match API 2706 limits (Bug 12823). 2707 2708 4 04/27/2016 Jon Leech Reduce minimum value of 2709 MAX_TESS_CONTROL_TOTAL_OUTPUT_COMPONENTS 2710 from 4096 to 2048 (Bug 12823). 2711 2712 3 07/23/2015 Jon Leech Reduce minimum value of 2713 MAX_TESS_{CONTROL,EVALUATION}_{IN,OUT}PUT_COMPONENTS 2714 to 64 (Bug 12823) 2715 2716 2 05/05/2015 dkoch Remove "per-patch" part of description of 2717 MAX_TESS_CONTROL_TOTAL_OUTPUT_COMPONENTS 2718 (Bug 13765). 2719 Allow arrays for both per-patch and per-vertex 2720 TCS outputs (Bug 13658). 2721 Fix typo in issue 15 suggesting that VS outputs 2722 could be an array of structures (Bug 13824). 2723 2724 1 06/18/2014 dkoch Initial OES version based on EXT. 2725 No functional changes. 2726