1Name 2 3 ARB_tessellation_shader 4 5Name Strings 6 7 GL_ARB_tessellation_shader 8 9Contact 10 11 Pat Brown, NVIDIA Corporation (pbrown 'at' nvidia.com) 12 13Contributors 14 15 Barthold Lichtenbelt, NVIDIA 16 Bill Licea-Kane, AMD 17 Bruce Merry, ARM 18 Chris Dodd, NVIDIA 19 Eric Werness, NVIDIA 20 Graham Sellers, AMD 21 Greg Roth, NVIDIA 22 Ignacio Castano, NVIDIA 23 Jeff Bolz, NVIDIA 24 Nick Haemel, AMD 25 Pierre Boudier, AMD 26 Piers Daniell, NVIDIA 27 28Notice 29 30 Copyright (c) 2010-2019 The Khronos Group Inc. Copyright terms at 31 http://www.khronos.org/registry/speccopyright.html 32 33Specification Update Policy 34 35 Khronos-approved extension specifications are updated in response to 36 issues and bugs prioritized by the Khronos OpenGL Working Group. For 37 extensions which have been promoted to a core Specification, fixes will 38 first appear in the latest version of that core Specification, and will 39 eventually be backported to the extension document. This policy is 40 described in more detail at 41 https://www.khronos.org/registry/OpenGL/docs/update_policy.php 42 43Status 44 45 Complete. Approved by the ARB at the 2010/01/22 F2F meeting. 46 Approved by the Khronos Board of Promoters on March 10, 2010. 47 48Version 49 50 Last Modified Date: September 17, 2019 51 Revision: 23 52 53Number 54 55 ARB Extension #91 56 57Dependencies 58 59 This extension is written against the OpenGL 3.2 (Compatibility Profile) 60 Specification. 61 62 This extension is written against Version 1.50 (Revision 09) of the OpenGL 63 Shading Language Specification. 64 65 OpenGL 3.2 and GLSL 1.50 are required. 66 67 This specification interacts with the core profile of OpenGL 3.2. 68 69 This specification interacts with ARB_gpu_shader5. 70 71 This specification interacts with ARB_gpu_shader_fp64. 72 73 This specification interacts with NV_gpu_shader5. 74 75 This specification interacts with NV_primitive_restart. 76 77Overview 78 79 This extension introduces new tessellation stages and two new shader types 80 to the OpenGL primitive processing pipeline. These pipeline stages 81 operate on a new basic primitive type, called a patch. A patch consists 82 of a fixed-size collection of vertices, each with per-vertex attributes, 83 plus a number of associated per-patch attributes. Tessellation control 84 shaders transform an input patch specified by the application, computing 85 per-vertex and per-patch attributes for a new output patch. A 86 fixed-function tessellation primitive generator subdivides the patch, and 87 tessellation evaluation shaders are used to compute the position and 88 attributes of each vertex produced by the tessellator. 89 90 When tessellation is active, it begins by running the optional 91 tessellation control shader. This shader consumes an input patch and 92 produces a new fixed-size output patch. The output patch consists of an 93 array of vertices, and a set of per-patch attributes. The per-patch 94 attributes include tessellation levels that control how finely the patch 95 will be tessellated. For each patch processed, multiple tessellation 96 control shader invocations are performed -- one per output patch vertex. 97 Each tessellation control shader invocation writes all the attributes of 98 its corresponding output patch vertex. A tessellation control shader may 99 also read the per-vertex outputs of other tessellation control shader 100 invocations, as well as read and write shared per-patch outputs. The 101 tessellation control shader invocations for a single patch effectively run 102 as a group. A built-in barrier() function is provided to allow 103 synchronization points where no shader invocation will continue until all 104 shader invocations have reached the barrier. 105 106 The tessellation primitive generator then decomposes a patch into a new 107 set of primitives using the tessellation levels to determine how finely 108 tessellated the output should be. The primitive generator begins with 109 either a triangle or a quad, and splits each outer edge of the primitive 110 into a number of segments approximately equal to the corresponding element 111 of the outer tessellation level array. The interior of the primitive is 112 tessellated according to elements of the inner tessellation level array. 113 The primitive generator has three modes: "triangles" and "quads" split a 114 triangular or quad-shaped patch into a set of triangles that cover the 115 original patch; "isolines" splits a quad-shaped patch into a set of line 116 strips running across the patch horizontally. Each vertex generated by 117 the tessellation primitive generator is assigned a (u,v) or (u,v,w) 118 coordinate indicating its relative location in the subdivided triangle or 119 quad. 120 121 For each vertex produced by the tessellation primitive generator, the 122 tessellation evaluation shader is run to compute its position and other 123 attributes of the vertex, using its (u,v) or (u,v,w) coordinate. When 124 computing final vertex attributes, the tessellation evaluation shader can 125 also read the attributes of any of the vertices of the patch written by 126 the tessellation control shader. Tessellation evaluation shader 127 invocations are completely independent, although all invocations for a 128 single patch share the same collection of input vertices and per-patch 129 attributes. 130 131 The tessellator operates on vertices after they have been transformed by a 132 vertex shader. The primitives generated by the tessellator are passed 133 further down the OpenGL pipeline, where they can be used as inputs to 134 geometry shaders, transform feedback, and the rasterizer. 135 136 The tessellation control and evaluation shaders are both optional. If 137 neither shader type is present, the tessellation stage has no effect. If 138 no tessellation control shader is present, the input patch provided by the 139 application is passed directly to the tessellation primitive generator, 140 and a set of default tessellation level parameters is used to control 141 primitive generation. In this extension, patches may not be passed beyond 142 the tessellation evaluation shader, and an error is generated if an 143 application provides patches and the current program object contains no 144 tessellation evaluation shader. 145 146IP Status 147 148 No known IP claims. 149 150New Procedures and Functions 151 152 void PatchParameteri(enum pname, int value); 153 void PatchParameterfv(enum pname, const float *values); 154 155New Tokens 156 157 Accepted by the <mode> parameter of Begin and all vertex array functions 158 that implicitly call Begin: 159 160 PATCHES 0xE 161 162 Accepted by the <pname> parameter of PatchParameteri, GetBooleanv, 163 GetDoublev, GetFloatv, GetIntegerv, and GetInteger64v: 164 165 PATCH_VERTICES 0x8E72 166 167 Accepted by the <pname> parameter of PatchParameterfv, GetBooleanv, 168 GetDoublev, GetFloatv, and GetIntegerv, and GetInteger64v: 169 170 PATCH_DEFAULT_INNER_LEVEL 0x8E73 171 PATCH_DEFAULT_OUTER_LEVEL 0x8E74 172 173 Accepted by the <pname> parameter of GetProgramiv: 174 175 TESS_CONTROL_OUTPUT_VERTICES 0x8E75 176 TESS_GEN_MODE 0x8E76 177 TESS_GEN_SPACING 0x8E77 178 TESS_GEN_VERTEX_ORDER 0x8E78 179 TESS_GEN_POINT_MODE 0x8E79 180 181 Returned by GetProgramiv when <pname> is TESS_GEN_MODE: 182 183 TRIANGLES 184 QUADS 185 ISOLINES 0x8E7A 186 187 Returned by GetProgramiv when <pname> is TESS_GEN_SPACING: 188 189 EQUAL 190 FRACTIONAL_ODD 0x8E7B 191 FRACTIONAL_EVEN 0x8E7C 192 193 Returned by GetProgramiv when <pname> is TESS_GEN_VERTEX_ORDER: 194 195 CCW 196 CW 197 198 Returned by GetProgramiv when <pname> is TESS_GEN_POINT_MODE: 199 200 FALSE 201 TRUE 202 203 Accepted by the <pname> parameter of GetBooleanv, GetDoublev, GetFloatv, 204 GetIntegerv, and GetInteger64v: 205 206 MAX_PATCH_VERTICES 0x8E7D 207 MAX_TESS_GEN_LEVEL 0x8E7E 208 MAX_TESS_CONTROL_UNIFORM_COMPONENTS 0x8E7F 209 MAX_TESS_EVALUATION_UNIFORM_COMPONENTS 0x8E80 210 MAX_TESS_CONTROL_TEXTURE_IMAGE_UNITS 0x8E81 211 MAX_TESS_EVALUATION_TEXTURE_IMAGE_UNITS 0x8E82 212 MAX_TESS_CONTROL_OUTPUT_COMPONENTS 0x8E83 213 MAX_TESS_PATCH_COMPONENTS 0x8E84 214 MAX_TESS_CONTROL_TOTAL_OUTPUT_COMPONENTS 0x8E85 215 MAX_TESS_EVALUATION_OUTPUT_COMPONENTS 0x8E86 216 MAX_TESS_CONTROL_UNIFORM_BLOCKS 0x8E89 217 MAX_TESS_EVALUATION_UNIFORM_BLOCKS 0x8E8A 218 MAX_TESS_CONTROL_INPUT_COMPONENTS 0x886C 219 MAX_TESS_EVALUATION_INPUT_COMPONENTS 0x886D 220 MAX_COMBINED_TESS_CONTROL_UNIFORM_COMPONENTS 0x8E1E 221 MAX_COMBINED_TESS_EVALUATION_UNIFORM_COMPONENTS 0x8E1F 222 223 Accepted by the <pname> parameter of GetActiveUniformBlockiv: 224 225 UNIFORM_BLOCK_REFERENCED_BY_TESS_CONTROL_SHADER 0x84F0 226 UNIFORM_BLOCK_REFERENCED_BY_TESS_EVALUATION_SHADER 0x84F1 227 228 Accepted by the <type> parameter of CreateShader and returned by the 229 <params> parameter of GetShaderiv: 230 231 TESS_EVALUATION_SHADER 0x8E87 232 TESS_CONTROL_SHADER 0x8E88 233 234 235Additions to Chapter 2 of the OpenGL 3.2 (Compatibility Profile) Specification (OpenGL 236Operation) 237 238 Modify Section 2.6.1, Begin and End, p. 22 239 240 (insert before the last paragraph, p. 27) 241 242 Separate Patches 243 244 Separate patches are specified with mode PATCHES. A patch is an ordered 245 collection of vertices used for primitive tessellation (section 2.X). The 246 vertices comprising a patch have no implied geometric ordering. The 247 vertices of a patch are used by tessellation shaders and a fixed-function 248 tessellator to generate new point, line, or triangle primitives. 249 250 Each patch in the series has a fixed number of vertices, which is 251 specified by calling 252 253 void PatchParameteri(enum pname, int value); 254 255 with <pname> set to PATCH_VERTICES. The error INVALID_VALUE is generated 256 if <value> is less than or equal to zero or is greater than the 257 implementation-dependent maximum patch size, MAX_PATCH_VERTICES. The 258 patch size is initially three vertices. 259 260 If the number of vertices in a patch is given by <v>, the <v>*<i>+1st 261 through <v>*<i>+<v>th vertices (in that order) determine a patch for each 262 i = 0, 1, ..., n-1, where there are <v>*<n>+<k> vertices. <k> is in the 263 range [0,<v>-1]; if <k> is not zero, the final <k> vertices are ignored. 264 265 266 (modify second paragraph, p. 29) The state required for Begin and End 267 consists of a sixteen-valued integer indicating either one of the fifteen 268 possible Begin/End modes, or that no Begin/End mode is being processed. 269 270 271 Modify Section 2.14, Vertex Shaders, p. 82 272 273 (modify fourth paragraph, p. 82) In addition to vertex shaders, 274 tessellation control shaders, tessellation evaluation shaders, geometry 275 shaders, and fragment shaders can be created, compiled, and linked into 276 program objects. Tessellation control and evaluation shaders are used to 277 control the operation of the tessellator, and are described in section 278 2.X. Geometry shaders affect the processing of primitives assembled from 279 vertices (see section 2.15). Fragment shaders affect the processing of 280 fragments during rasterization (see section 3.12). A single program 281 object can contain vertex, tessellation control, tessellation evaluation, 282 geometry, and fragment shaders. 283 284 285 Modify Section 2.14.2, Program Objects, p. 84 286 287 (insert before third paragraph, p. 85) 288 289 Linking will fail if the program object contains objects to form a 290 tessellation control shader (see section 2.X.1), and 291 292 * the program contains no objects to form a vertex shader; 293 294 * the output patch vertex count is not specified in any compiled 295 tessellation control shader object; or 296 297 * the output patch vertex count is specified differently in multiple 298 tessellation control shader objects. 299 300 Linking will fail if the program object contains objects to form a 301 tessellation evaluation shader (see section 2.X.3), and 302 303 * the program contains no objects to form a vertex shader; 304 305 * the tessellation primitive mode is not specified in any compiled 306 tessellation evaluation shader object; or 307 308 * the tessellation primitive mode, spacing, vertex order, or point mode 309 is specified differently in multiple tessellation evaluation shader 310 objects. 311 312 313 Modify Section 2.14.4, Uniform Variables, p, 89 314 315 (modify sixth paragraph, p. 93) If <pname> is 316 UNIFORM_BLOCK_REFERENCED_BY_VERTEX_SHADER, 317 UNIFORM_BLOCK_REFERENCED_BY_TESS_CONTROL_SHADER, 318 UNIFORM_BLOCK_REFERENCED_BY_TESS_EVALUATION_SHADER, 319 UNIFORM_BLOCK_REFERENCED_BY_GEOMETRY_SHADER, or 320 UNIFORM_BLOCK_REFERENCED_BY_FRAGMENT_SHADER, then a boolean value 321 indicating whether the uniform block identified by <uniformBlockIndex> is 322 referenced by the vertex, tessellation control, tessellation evaluation, 323 geometry, or fragment shaders of <program>, respectively, is returned. 324 325 (modify next-to-last paragraph, p. 101) There is a set of 326 implementation-dependent maximums for the number of active uniform blocks 327 used by each shader. If the number of uniform blocks used by any shader 328 in the program exceeds its corresponding limit, the program will fail to 329 link. The limits for vertex, tessellation control, tessellation 330 evaluation, geometry, and fragment shaders can be obtained by calling 331 GetIntegerv with pname values of MAX_VERTEX_UNIFORM_BLOCKS, 332 MAX_TESS_CONTROL_UNIFORM_BLOCKS, MAX_TESS_EVALUATION_UNIFORM_BLOCKS, 333 MAX_GEOMETRY_UNIFORM_BLOCKS, and MAX_FRAGMENT_UNIFORM_BLOCKS, 334 respectively. 335 336 337 Modify Section 2.14.6, Varying Variables, p. 106 338 339 (modify three paragraphs starting with the last paragraph, p. 106, to 340 refer less specifically to geometry shaders) ... These varying variables 341 are used as the mechanism to communicate values to the next active stage 342 in the vertex processing pipeline: either the tessellation control 343 shader, the tessellation evaluation shader, the geometry shader, or the 344 fixed-function vertex processing stages leading to rasterization. 345 346 If the varying variables are passed directly to the vertex processing 347 stages leading to rasterization, the values of all varying and special 348 variables are expected to be interpolated across the primitive being 349 rendered, unless flatshaded. Otherwise, the values of all varying and 350 special variables are collected by the primitive assembly stage and passed 351 on to the subsequent pipeline stage once enough data for one primitive has 352 been collected 353 354 The number of components (individual scalar numeric values) of varying and 355 special variables that can be written by the vertex shader, whether or not 356 a tessellation control, tessellation evaluation, or geometry shader is 357 active, is given by the value of the implementation-dependent constant 358 MAX_VERTEX_OUTPUT_COMPONENTS. Outputs declared as vectors, matrices, and 359 arrays will all consume multiple components. 360 361 (modify next-to-last paragraph, p. 107) Each program object can specify a 362 set of output variables from one shader to be recorded in transform 363 feedback mode (see section 2.19). If a geometry shader is active, its 364 output variables are the ones that can be recorded. Otherwise, 365 tessellation evaluation shader outputs will be recorded, if that shader is 366 active. Otherwise, tessellation control shader outputs will be recorded, 367 if that shader is active. Otherwise, vertex shader outputs will be 368 recorded. The values to record are specified with the command ... 369 370 (modify bullet list, p. 108) 371 372 * the count specified by TransformFeedbackVaryings is non-zero, but the 373 program object has no vertex, tessellation control, tessellation 374 evaluation, or geometry shader; 375 376 * any variable name specified in the varyings array is not declared as 377 an output in the shader stage whose outputs can be recorded; 378 379 ... 380 381 382 Modify Section 2.14.7, Shader Execution, p. 109 383 384 (Modify the part of the section describing what is and is not done for 385 processing vertices when vertex shaders are active, p. 109 and 110. This 386 rewrite is intended to apply to all programmable vertex processing 387 pipeline stages. Ideally, we should refactor the spec to first have a 388 general programmable shading section describing common shader 389 functionality and this pipeline, followed by sections containing 390 domain-specific items.) 391 392 If a successfully linked program object that contains a vertex, 393 tessellation control, tessellation evaluation, or geometry shader is made 394 current by calling UseProgram, the executable version of these shaders are 395 used to process incoming vertex values, rather than the fixed-function 396 vertex processing described in sections 2.16 through 2.13. In particular, 397 398 (keep list of fixed-function operations that are not performed) 399 400 Instead, the following sequence of operations is performed: 401 402 * Vertices are processed by the vertex shader (section 2.14) and 403 assembled into primitives as described in sections 2.6 through 2.10. 404 405 * If the current program contains a tessellation control shader, each 406 individual patch primitive is processed by the tessellation control 407 shader (section 2.X.1). Otherwise, primitives are passed through 408 unmodified. If active, the tessellation control shader consumes its 409 input patch and produces a new patch primitive, which is passed to 410 subsequent pipeline stages. 411 412 * If the current program contains a tessellation evaluation shader, each 413 individual patch primitive is processed by the tessellation primitive 414 generator (section 2.X.2) and tessellation evaluation shader (section 415 2.X.3). Otherwise, primitives are passed through unmodified. When a 416 tessellation evaluation shader is active, the tessellation primitive 417 generator produces a new collection of point, line, or triangle 418 primitives to be passed to subsequent pipeline stages. The vertices 419 of these primitives are processed by the tessellation evaluation 420 shader. The patch primitive passed to the tessellation primitive 421 generator is consumed by this process. 422 423 * If the current program contains a geometry shader, each individual 424 primitive is processed by the geometry shader (section 2.15). 425 Otherwise, primitives are passed through unmodified. If active, the 426 geometry shader consumes its input patch. However, each geometry 427 shader invocation may emit new vertices, which are arranged into 428 primitives and passed to subsequent pipeline stages. 429 430 * The primitives reaching this stage in the pipeline are then processed 431 by the following fixed-function operations: 432 433 (NOTE: This change rearranges the order of some of the operations, 434 and adds explicit references to transform feedback and rasterization. 435 The pipeline stages have been in the wrong order since OpenGL 2.0 -- 436 in particular, clipping logically happens before perspective division 437 and viewport transformations.) 438 439 * Color clamping or masking (section 2.13.6). 440 441 * Transform feedback (section 2.19). 442 443 * Flatshading (section 2.21). 444 445 * Clipping, including client-defined clip planes (section 2.22). 446 447 * Perspective division on clip coordinates (section 2.16). 448 449 * Viewport mapping, including depth range scaling (section 2.16.1). 450 451 * Front face determination (section 2.13.1). 452 453 * Color, texture coordinate, fog, point-size and generic attribute 454 clipping (section 2.22.1). 455 456 * Final color processing (section 2.23). 457 458 * Rasterization (chapter 3). 459 460 461 Modify Section 2.14.7, Shader Execution, p. 109 462 463 (modify last paragraph, p. 110) This section describes texture 464 functionality that is only accessible through vertex, tessellation 465 control, tessellation evaluation, geometry, or fragment shaders. ... 466 467 (modify first paragraph under "Texture Access", p. 112) Shaders have the 468 ability to do a lookup into a texture map. The maximum number of texture 469 image units available to vertex, tessellation control, tessellation 470 evaluation, geometry, or fragment shaders are the values of 471 the implementation-dependent constants 472 473 * MAX_VERTEX_TEXTURE_IMAGE_UNITS (vertex), 474 * MAX_TESS_CONTROL_TEXTURE_IMAGE_UNITS (tessellation control), 475 * MAX_TESS_EVALUATION_TEXTURE_IMAGE_UNITS (tessellation evaluation), 476 * MAX_GEOMETRY_TEXTURE_IMAGE_UNITS (geometry), and 477 * MAX_TEXTURE_IMAGE_UNITS (fragment). 478 479 The vertex shader, tessellation control and evaluation shader, geometry 480 shader, and fragment processing combined cannot use more than the value of 481 MAX_COMBINED_TEXTURE_IMAGE_UNITS texture image units. If more than one 482 pipeline stage accesses the same texture image unit, each such access 483 counts separately against the MAX_COMBINED_TEXTURE_IMAGE_UNITS limit. 484 485 (modify next-to-last paragraph p. 112) When a texture lookup is performed 486 in a shader, the filtered ... 487 488 (modify last paragraph p. 112) In shaders other than fragment shaders, it 489 is not possible... 490 491 (modify last paragraph before "Shader Inputs", p. 113) If a shader uses a 492 sampler where the associated ... 493 494 495 Insert a new section immediately after Section 2.14, Vertex Shaders. 496 497 Section 2.X, Tessellation 498 499 Tessellation is a process that reads a patch primitive and generates new 500 primitives used by subsequent pipeline stages. The generated primitives 501 are formed by subdividing a single triangle or quad primitive according to 502 fixed or shader-computed levels of detail and transforming each of the 503 vertices produced during this subdivision. 504 505 Tessellation functionality is controlled by two types of tessellation 506 shaders: tessellation control shaders and tessellation evaluation 507 shaders. Tessellation is considered active if and only if there is an 508 active program object, and that program object contains a tessellation 509 control or evaluation shader. 510 511 The tessellation control shader is used to read an input patch provided by 512 the application, and emit an output patch. The tessellation control 513 shader is run once for each vertex in the output patch and computes the 514 attributes of that vertex. Additionally, the tessellation control shader 515 may compute additional per-patch attributes of the output patch. The most 516 important per-patch outputs are the tessellation levels, which are used to 517 control the number of subdivisions performed by the tessellation primitive 518 generator. The tessellation control shader may also write additional 519 per-patch attributes for use by the tessellation evaluation shader. If no 520 tessellation control shader is active, the patch provided is passed 521 through to the tessellation primitive generator stage unmodified. 522 523 If a tessellation evaluation shader is active, the tessellation primitive 524 generator subdivides a triangle or quad primitive into a collection of 525 points, lines, or triangles according to the tessellation levels of the 526 patch and the set of layout declarations specified in the tessellation 527 evaluation shader text. The tessellation levels used to control 528 subdivision are normally written by the tessellation control shader. If 529 no tessellation control shader is active, default tessellation levels are 530 instead used. 531 532 When a tessellation evaluation shader is active, it is run on each vertex 533 generated by the tessellation primitive generator to compute the final 534 position and other attributes of the vertex. The tessellation evaluation 535 shader can read the relative location of the vertex in the subdivided 536 output primitive, given by an (u,v) or (u,v,w) coordinate, as well as the 537 position and attributes of any or all of the vertices in the input patch. 538 539 Tessellation operates only on patch primitives. If tessellation is 540 active, the error INVALID_OPERATION is generated by Begin (or vertex array 541 commands that implicitly call Begin) if the primitive mode is not 542 PATCHES. 543 544 Patch primitives are not supported by pipeline stages below the 545 tessellation evaluation shader. If there is no active program object or 546 the active program object does not contain a tessellation evaluation 547 shader, the error INVALID_OPERATION is generated by Begin (or vertex array 548 commands that implicitly call Begin) if the primitive mode is PATCHES. 549 550 A program object that includes a tessellation shader of any kind must also 551 include a vertex shader, and will fail to link if no vertex shader is 552 provided. 553 554 555 Section 2.X.1, Tessellation Control Shaders 556 557 The tessellation control shader consumes an input patch provided by the 558 application and emits a new output patch. The input patch is an array of 559 vertices with attributes corresponding to output variables written by the 560 vertex shader. The output patch consists of an array of vertices with 561 attributes corresponding to per-vertex output variables written by the 562 tessellation control shader and a set of per-patch attributes 563 corresponding to per-patch output variables written by the tessellation 564 control shader. Tessellation control output variables are per-vertex by 565 default, but may be declared as per-patch using the "patch" qualifier. 566 567 The number of vertices in the output patch is fixed when the program is 568 linked, and is specified in tessellation control shader source code using 569 the output layout qualifier "vertices", as described in the OpenGL Shading 570 Language Specification. A program will fail to link if the output patch 571 vertex count is not specified by any tessellation control shader object 572 attached to the program, if it is specified differently by multiple 573 tessellation control shader objects, if it is less than or equal to zero, 574 or if it is greater than the implementation-dependent maximum patch 575 size. The output patch vertex count may be queried by calling GetProgramiv 576 with the symbolic constant TESS_CONTROL_OUTPUT_VERTICES. 577 578 Tessellation control shaders are created as described in section 2.14.1, 579 using a <type> of TESS_CONTROL_SHADER. When a new input patch is 580 received, the tessellation control shader is run once for each vertex in 581 the output patch. The tessellation control shader invocations 582 collectively specify the per-vertex and per-patch attributes of the output 583 patch. The per-vertex attributes are obtained from the per-vertex output 584 variables written by each invocation. Each tessellation control shader 585 invocation may only write to per-vertex output variables corresponding to 586 its own output patch vertex. The output patch vertex number corresponding 587 to a given tessellation control point shader invocation is given by the 588 built-in variable gl_InvocationID. Per-patch attributes are taken from 589 the per-patch output variables, which may be written by any tessellation 590 control shader invocation. While tessellation control shader invocations 591 may read any per-vertex and per-patch output variable and write any 592 per-patch output variable, reading or writing output variables also 593 written by other invocations has ordering hazards discussed below. 594 595 596 Section 2.X.1.1, Tessellation Control Shader Variables 597 598 Tessellation control shaders can access uniforms belonging to the current 599 program object. The amount of storage available for uniform variables in 600 the default uniform block accessed by a tessellation control shader is 601 specified by the value of the implementation-dependent constant 602 MAX_TESS_CONTROL_UNIFORM_COMPONENTS. The total amount of combined storage 603 available for uniform variables in all uniform blocks accessed by a 604 tessellation control shader (including the default uniform block) is 605 specified by the value of the implementation-dependent constant 606 MAX_COMBINED_TESS_CONTROL_UNIFORM_COMPONENTS. These values represent the 607 numbers of individual floating-point, integer, or boolean values that can 608 be held in uniform variable storage for a tessellation evaluation shader. 609 A link error is generated if an attempt is made to utilize more than the 610 space available for tessellation control shader uniform variables. 611 Uniforms are manipulated as described in section 2.14.4. Tessellation 612 control shaders also have access to samplers to perform texturing 613 operations, as described in sections 2.14.5. 614 615 Tessellation control shaders can access the transformed attributes of all 616 vertices for their input primitive using input variables. A vertex shader 617 writing to output variables generates the values of these input varying 618 variables, including values for built-in as well as user-defined varying 619 variables. Values for any varying variables that are not written by a 620 vertex shader are undefined. 621 622 Additionally, tessellation control shaders can write to one or more output 623 variables, including per-vertex attributes for the vertices of the output 624 patch and per-patch attributes of the patch. Tessellation control shaders 625 can also write to a set of built-in per-vertex and per-patch outputs 626 defined in the OpenGL Shading Language. The per-vertex and per-patch 627 attributes of the output patch are used by the tessellation primitive 628 generator (section 2.X.2) and may be read by tessellation evaluation 629 shader (section 2.X.3). 630 631 632 Section 2.X.1.2, Tessellation Control Shader Execution Environment 633 634 If a successfully linked program object that contains a tessellation 635 control shader is made current by calling UseProgram, the executable 636 version of the tessellation control shader is used to process patches 637 resulting from the primitive assembly stage. When tessellation control 638 shader execution completes, the input patch is consumed. A new patch is 639 assembled from the per-vertex and per-patch output variables written by 640 the shader and is passed to subsequent pipeline stages. 641 642 There are several special considerations for tessellation control shader 643 execution described in the following sections. 644 645 Texture Access 646 647 The Shader-Only Texturing subsection of section 2.14.7 describes texture 648 lookup functionality accessible to a vertex shader. The texel fetch and 649 texture size query functionality described there also applies to 650 tessellation control shaders. 651 652 Tessellation Control Shader Inputs 653 654 Section 7.1 of the OpenGL Shading Language Specification describes the 655 built-in variable array gl_in[] available as input to a tessellation 656 control shader. gl_in[] receives values from equivalent built-in output 657 variables written by the vertex shader (section 2.14.7). Each array 658 element of gl_in[] is a structure holding values for a specific vertex of 659 the input patch. The length of gl_in[] is equal to the 660 implementation-dependent maximum patch size (gl_MaxPatchVertices). 661 Behavior is undefined if gl_in[] is indexed with a vertex index greater 662 than or equal to the current patch size. The members of each element of 663 the gl_in[] array are gl_Position, gl_PointSize, gl_ClipDistance[], 664 gl_ClipVertex, gl_FrontColor, gl_BackColor, gl_FrontSecondaryColor, 665 gl_BackSecondaryColor, gl_TexCoord[], and gl_FogFragCoord[]. 666 667 Tessellation control shaders have available several other special input 668 variables not replicated per-vertex and not contained in gl_in[], 669 including: 670 671 * The variable gl_PatchVerticesIn holds the number of vertices in the 672 input patch being processed by the tessellation control shader. 673 674 * The variable gl_PrimitiveID is filled with the number of primitives 675 processed since the last time Begin was called (directly or indirectly 676 via vertex array functions). The first primitive generated after a 677 Begin is numbered zero, and the primitive ID counter is incremented 678 after every individual point, line, or triangle primitive is 679 processed. Restarting a primitive topology using the primitive 680 restart index has no effect on the primitive ID counter. 681 682 * The variable gl_InvocationID holds an invocation number for the 683 current tessellation control shader invocation. Tessellation control 684 shaders are invoked once per output patch vertex, and invocations are 685 numbered beginning with zero. 686 687 Similarly to the built-in varying variables, each user-defined input 688 varying variable has a value for each vertex and thus needs to be declared 689 as arrays or inside input blocks declared as arrays. Declaring an array 690 size is optional. If no size is specified, it will be taken from the 691 implementation-dependent maximum patch size (gl_MaxPatchVertices). If a 692 size is specified, it must match the maximum patch size; otherwise, a 693 compile or link 694 error will occur. Since the array size may be larger than the number of 695 vertices found in the input patch, behavior is undefined if a per-vertex 696 input variable is accessed using an index greater than or equal to the 697 number of vertices in the input patch. The OpenGL Shading Language 698 doesn't support multi-dimensional arrays; therefore, user-defined 699 tessellation control shader inputs corresponding to vertex shader outputs 700 declared as arrays must be declared as array members of an input block 701 that is itself declared as an array. 702 703 (Note: minor restructuring in the following paragraph relative to the 704 equivalent geometry shader language.) 705 706 Similarly to the limit on vertex shader output components (see section 707 2.14.6), there is a limit on the number of components of built-in and 708 user-defined input varying variables that can be read by the tessellation 709 control shader, given by the value of the implementation-dependent 710 constant MAX_TESS_CONTROL_INPUT_COMPONENTS. When a program is linked, all 711 components of any varying and special variable read by a tessellation 712 control shader will count against this limit. A program whose 713 tessellation control shader exceeds this limit may fail to link, unless 714 device-dependent optimizations are able to make the program fit within 715 available hardware resources. 716 717 718 Tessellation Control Shader Outputs 719 720 Section 7.1 of the OpenGL Shading Language Specification describes the 721 built-in variable array gl_out[] available as an output for a tessellation 722 control shader. gl_out[] passes values to equivalent built-in input 723 variables read by subsequent shader stages or to subsequent fixed 724 functionality vertex processing pipeline stages. Each array element of 725 gl_out[] is a structure holding values for a specific vertex of the output 726 patch. The length of gl_out[] is equal to the output patch size specified 727 in the tessellation control shader output layout declaration 728 (gl_VerticesOut). The members of each element of the gl_out[] array are 729 gl_Position, gl_PointSize, gl_ClipDistance[], gl_ClipVertex, 730 gl_FrontColor, gl_BackColor, gl_FrontSecondaryColor, 731 gl_BackSecondaryColor, gl_TexCoord[], and gl_FogFragCoord[], and behave 732 identically to equivalently named vertex shader outputs (section 2.14.7). 733 734 Tessellation shaders additionally have two built-in per-patch output 735 arrays, gl_TessLevelOuter[] and gl_TessLevelInner[]. These arrays are not 736 replicated for each output patch vertices and are not members of gl_out[]. 737 gl_TessLevelOuter[] is an array of four floating-point values specifying 738 the approximate number of segments that the tessellation primitive 739 generator should use when subdividing each outer edge of the primitive it 740 subdivides. gl_TessLevelInner[] is an array of two floating-point values 741 specifying the approximate number of segments used to produce a 742 regularly-subdivided primitive interior. The values written to 743 gl_TessLevelOuter and gl_TessLevelInner need not be integers, and their 744 interpretation depends on the type of primitive the tessellation primitive 745 generator will subdivide and other tessellation parameters, as discussed 746 in the following section. 747 748 A tessellation control shader may also declare user-defined per-vertex 749 output variables. User-defined per-vertex output variables are declared 750 with the qualifier "out" and have a value for each vertex in the output 751 patch. Such variables must be declared as arrays or inside output blocks 752 declared as arrays. Declaring an array size is optional. If no size is 753 specified, it will be taken from the output patch size (gl_VerticesOut) 754 declared in the shader. If a size is specified, it must match the maximum 755 patch size; otherwise, a compile or link link error will occur. The OpenGL Shading 756 Language doesn't support multi-dimensional arrays; therefore, user-defined 757 per-vertex tessellation control shader outputs with multiple elements per 758 vertex must be declared as array members of an output block that is itself 759 declared as an array. 760 761 While per-vertex output variables are declared as arrays indexed by vertex 762 number, each tessellation control shader invocation may write only to 763 those outputs corresponding to its output patch vertex. Tessellation 764 control shaders must use the special variable gl_InvocationID as the 765 vertex number index when writing to per-vertex output variables. 766 767 Additionally, a tessellation control shader may declare per-patch output 768 variables using the qualifier "patch out". Unlike per-vertex outputs, 769 per-patch outputs do not correspond to any specific vertex in the patch, 770 and are not indexed by vertex number. Per-patch outputs declared as 771 arrays have multiple values for the output patch; similarly declared 772 per-vertex outputs would indicate a single value for each vertex in the 773 output patch. User-defined per-patch outputs are not used by the 774 tessellation primitive generator, but may be read by tessellation 775 evaluation shaders. 776 777 There are several limits on the number of components of built-in and 778 user-defined output variables that can be written by the tessellation 779 control shader. The number of components of active per-vertex output 780 variables may not exceed the value of MAX_TESS_CONTROL_OUTPUT_COMPONENTS. 781 The number of components of active per-patch output variables may not 782 exceed the value of MAX_TESS_PATCH_COMPONENTS. The built-in outputs 783 gl_TessLevelOuter[] and gl_TessLevelInner[] are not counted against the 784 per-patch limit. The total number of components of active per-vertex and 785 per-patch outputs is derived by multiplying the per-vertex output 786 component count by the output patch size and then adding the per-patch 787 output component count. The total component count may not exceed 788 MAX_TESS_CONTROL_TOTAL_OUTPUT_COMPONENTS. When a program is linked, all 789 components of any varying and special variables written by a tessellation 790 control shader will count against this limit. A program exceeding any of 791 these limits may fail to link, unless device-dependent optimizations are 792 able to make the program fit within available hardware resources. 793 794 795 Tessellation Control Shader Execution Order 796 797 For tessellation control shaders with a declared output patch size greater 798 than one, the shader is invoked more than once for each input patch. The 799 order of execution of one tessellation control shader invocation relative 800 to the other invocations for the same input patch is largely undefined. 801 The built-in function barrier() provides some control over relative 802 execution order. When a tessellation control shader calls the barrier() 803 function, its execution pauses until all other invocations have also 804 called the same function. Output variable assignments performed by any 805 invocation executed prior to calling barrier() will be visible to any 806 other invocation after the call to barrier() returns. Shader output 807 values read in one invocation but written by another may be undefined 808 without proper use of barrier(); full rules are found in the OpenGL 809 Shading Language Specification. 810 811 The barrier() function may only be called inside the main entry point of 812 the tessellation control shader and may not be called in potentially 813 divergent flow control. In particular, barrier() may not be called inside 814 a switch statement, in either sub-statement of an if statement, inside a 815 do, for, or while loop, or at any point after a return statement in the 816 function main(). 817 818 819 Section 2.X.2, Tessellation Primitive Generation 820 821 If a tessellation evaluation shader is present, the tessellation primitive 822 generator consumes the input patch and produces a new set of basic 823 primitives (points, lines, or triangles). These primitives are produced 824 by subdividing a geometric primitive (rectangle or triangle) according to 825 the per-patch tessellation levels written by the tessellation control 826 shader, if present, or taken from default patch parameter values. This 827 subdivision is performed in an implementation-dependent manner. If no 828 tessellation evaluation shader is present, the tessellation primitive 829 generator passes incoming primitives through without modification. 830 831 The type of subdivision performed by the tessellation primitive generator 832 is specified by an input layout declaration in the tessellation evaluation 833 shader using one of the identifiers "triangles", "quads", and "isolines". 834 For "triangles", the primitive generator subdivides a triangle primitive 835 into smaller triangles. For "quads", the primitive generator subdivides a 836 rectangle primitive into smaller triangles. For "isolines", the primitive 837 generator subdivides a rectangle primitive into a collection of line 838 segments arranged in strips stretching horizontally across the rectangle. 839 Each vertex produced by the primitive generator has an associated (u,v,w) 840 or (u,v) position in a normalized parameter space, with parameter values 841 in the range [0,1], as illustrated in Figure X.1. For "triangles", the 842 vertex position is a barycentric coordinate (u,v,w), where u+v+w==1, and 843 indicates the relative influence of the three vertices of the triangle on 844 the position of the vertex. For "quads" and "isolines", the position is a 845 (u,v) coordinate indicating the relative horizontal and vertical position 846 of the vertex relative to the subdivided rectangle. The subdivision 847 process is explained in more detail in subsequent sections. 848 849 (0,1) OL3 (1,1) (0,1,0) (0,1) (1,1) 850 +--------------+ + ^ + <no edge> + 851 | | / \ | 852 | +--------+ | / \ | +--------------+ 853 | | IL0 | | OL0 / + \ OL2 | 854 OL0| |IL1 | |OL2 / / \ \ | +--------------+ 855 | | | | / /IL0\ \ OL0 856 | +--------+ | / +-----+ \ | +--------------+ 857 | | / \ | 858 +--------------+ +---------------+ v +--------------+ 859 (0,0) OL1 (1,0) (0,0,1) OL1 (1,0,0) (0,0) OL1 (1,0) 860 861 quads triangles isolines 862 863 Figure X.1: Domain parameterization for tessellation generator 864 primitive modes (triangles, quads, or isolines). The coordinates 865 illustrate the value of gl_TessCoord at the corners of the domain. The 866 labels on the edges indicate the inner (IL0 and IL1) and outer (OL0 867 through OL3) tessellation level values used to control the number of 868 subdivisions along each edge of the domain. 869 870 When no tessellation control shader is present, the tessellation levels 871 are taken from default patch tessellation levels. These default levels 872 are set by calling 873 874 void PatchParameterfv(enum pname, const float *values); 875 876 If <pname> is PATCH_DEFAULT_OUTER_LEVEL, <values> specifies an array of 877 four floating-point values corresponding to the four outer tessellation 878 levels for each subsequent patch. If <pname> is 879 PATCH_DEFAULT_INNER_LEVEL, <values> specifies an array of two 880 floating-point values corresponding to the two inner tessellation levels. 881 882 A patch is discarded by the tessellation primitive generator if any 883 relevant outer tessellation level is less than or equal to zero. Patches 884 will also be discarded if any outer tessellation level corresponds to a 885 floating-point NaN (not a number) in implementations supporting NaN. 886 When patches are discarded, no new primitives will be generated and the 887 tessellation evaluation program will not be run. For "quads", all four 888 outer levels are relevant. For "triangles" and "isolines", only the first 889 three or two outer levels, respectively, are relevant. Negative inner 890 levels will not cause a patch to be discarded; they will be clamped as 891 described below. 892 893 Each of the tessellation levels is used to determine the number and 894 spacing of segments used to subdivide a corresponding edge. The method 895 used to derive the number and spacing of segments is specified by an input 896 layout declaration in the tessellation evaluation shader using one of the 897 identifiers "equal_spacing", "fractional_even_spacing", or 898 "fractional_odd_spacing". If no spacing is specified in the tessellation 899 evaluation shader, "equal_spacing" will be used. 900 901 If "equal_spacing" is used, the floating-point tessellation level is first 902 clamped to the range [1,<max>], where <max> is implementation-dependent 903 maximum tessellation level (MAX_TESS_GEN_LEVEL). The result is rounded up 904 to the nearest integer <n>, and the corresponding edge is divided into <n> 905 segments of equal length in (u,v) space. 906 907 If "fractional_even_spacing" is used, the tessellation level is first 908 clamped to the range [2,<max>] and then rounded up to the nearest even 909 integer <n>. If "fractional_odd_spacing" is used, the tessellation level 910 is clamped to the range [1,<max>-1] and then rounded up to the nearest odd 911 integer <n>. If <n> is one, the edge will not be subdivided. Otherwise, 912 the corresponding edge will be divided into <n>-2 segments of equal 913 length, and two additional segments of equal length that are typically 914 shorter than the other segments. The length of the two additional 915 segments relative to the others will decrease monotonically with the value 916 of <n>-<f>, where <f> is the clamped floating-point tessellation level. 917 When <n>-<f> is zero, the additional segments will have equal length to 918 the other segments. As <n>-<f> approaches 2.0, the relative length of the 919 additional segments approaches zero. The two additional segments should 920 be placed symmetrically on opposite sides of the subdivided edge. The 921 relative location of these two segments is undefined, but must be 922 identical for any pair of subdivided edges with identical values of <f>. 923 924 When the tessellation primitive generator produces triangles (in the 925 "triangles" or "quads" modes), the orientation of all triangles can be 926 specified by an input layout declaration in the tessellation evaluation 927 shader using the identifiers "cw" and "ccw". If the order is "cw", the 928 vertices of all generated triangles will have a clockwise ordering in 929 (u,v) or (u,v,w) space, as illustrated in Figure X.1. If the order is 930 "ccw", the vertices will be specified in counter-clockwise order. If no 931 layout is specified, "ccw" will be used. 932 933 For all primitive modes, the tessellation primitive generator is capable 934 of generating points instead of lines or triangles. If an input layout 935 declaration in the tessellation evaluation shader specifies the identifier 936 "point_mode", the primitive generator will generate one point for each 937 distinct vertex produced by tessellation. Otherwise, the primitive 938 generator will produce a collection of line segments or triangles 939 according to the primitive mode. When tessellating triangles or quads in 940 point mode with fractional odd spacing, the tessellation primitive 941 generator may produce "interior" vertices that are positioned on the edge 942 of the patch if an inner tessellation level is less than or equal to one. 943 Such vertices are considered distinct from vertices produced by 944 subdividing the outer edge of the patch, even if there are pairs of 945 vertices with identical coordinates. 946 947 The points, lines, or triangles produced by the tessellation primitive 948 generator are passed to subsequent pipeline stages in an 949 implementation-dependent order. 950 951 952 Section 2.X.2.1, Triangle Tessellation 953 954 If the tessellation primitive mode is "triangles", an equilateral triangle 955 is subdivided into a collection of triangles covering the area of the 956 original triangle. First, the original triangle is subdivided into a 957 collection of concentric equilateral triangles. The edges of each of 958 these triangles are subdivided, and the area between each triangle pair is 959 filled by triangles produced by joining the vertices on the subdivided 960 edges. The number of concentric triangles and the number of subdivisions 961 along each triangle except the outermost is derived from the first inner 962 tessellation level. The edges of the outermost triangle are subdivided 963 independently, using the first, second, and third outer tessellation 964 levels to control the number of subdivisions of the u==0 (left), v==0 965 (bottom), and w==0 (right) edges, respectively. The second inner 966 tessellation level and the fourth outer tessellation level have no effect 967 in this mode. 968 969 If the first inner tessellation level and all three outer tessellation 970 levels are exactly one after clamping and rounding, only a single triangle 971 with (u,v,w) coordinates of (0,0,1), (1,0,0), and (0,1,0) is generated. 972 If the inner tessellation level is one and any of the outer tessellation 973 levels is greater than one, the inner tessellation level is treated as 974 though it were originally specified as 1+epsilon and will result in a two- 975 or three-segment subdivision depending on the tessellation spacing. When 976 used with fractional odd spacing, the three-segment subdivision may 977 produce "inner" vertices positioned on the edge of the triangle. 978 979 If any tessellation level is greater than one, tessellation begins by 980 producing a set of concentric inner triangles and subdividing their edges. 981 First, the three outer edges are temporarily subdivided using the clamped 982 and rounded first inner tessellation level and the specified tessellation 983 spacing, generating <n> segments. For the outermost inner triangle, the 984 inner triangle is degenerate -- a single point at the center of the 985 triangle -- if <n> is two. Otherwise, for each corner of the outer 986 triangle, an inner triangle corner is produced at the intersection of two 987 lines extended perpendicular to the corner's two adjacent edges running 988 through the vertex of the subdivided outer edge nearest that corner. If 989 <n> is three, the edges of the inner triangle are not subdivided and is 990 the final triangle in the set of concentric triangles. Otherwise, each 991 edge of the inner triangle is divided into <n>-2 segments, with the <n>-1 992 vertices of this subdivision produced by intersecting the inner edge with 993 lines perpendicular to the edge running through the <n>-1 innermost 994 vertices of the subdivision of the outer edge. Once the outermost inner 995 triangle is subdivided, the previous subdivision process repeats itself, 996 using the generated triangle as an outer triangle. This subdivision 997 process is illustrated in Figure X.2. 998 999 (0,1,0) 1000 + 1001 / \ 1002 (0,1,0) O. .O 1003 + / + \ 1004 / \ O. / \ .O 1005 O. .O / O. .O \ 1006 / + \ / / + \ \ 1007 O. / \ .O / / / \ \ \ 1008 / O. .O \ O. / / \ \ .O 1009 / / O \ \ / O. / \ .O \ 1010 O. / . \ .O / / O-------O \ \ 1011 / O----O----O \ O. / . . \ .O 1012 / . . . \ / O----O-------O----O \ 1013 O----O----O----O----O / . . . . \ 1014 (0,0,1) (1,0,0) O----O----O-------O----O----O 1015 (0,0,1) (1,0,0) 1016 1017 Figure X.2, Inner Triangle Tessellation with inner tessellation levels 1018 of four and five (not to scale). This figure depicts the vertices along 1019 the bottom edge of the concentric triangles. The edges of inner 1020 triangles are subdivided by intersecting the edge with segments 1021 perpendicular to the edge passing through each inner vertex of the 1022 subdivided outer edge. 1023 1024 Once all the concentric triangles are produced and their edges are 1025 subdivided, the area between each pair of adjacent inner triangles is 1026 filled completely with a set of non-overlapping triangles. In this 1027 subdivision, two of the three vertices of each triangle are taken from 1028 adjacent vertices on a subdivided edge of one triangle; the third is one 1029 of the vertices on the corresponding edge of the other triangle. If the 1030 innermost triangle is degenerate (i.e., a point), the triangle containing 1031 it is subdivided into six triangles by connecting each of the six vertices 1032 on that triangle with the center point. If the innermost triangle is not 1033 degenerate, that triangle is added to the set of generated triangles 1034 as-is. 1035 1036 After the area corresponding to any inner triangles is filled, the 1037 primitive generator generates triangles to cover area between the 1038 outermost triangle and the outermost inner triangle. To do this, the 1039 temporary subdivision of the outer triangle edge above is discarded. 1040 Instead, the u==0, v==0, and w==0 edges are subdivided according to the 1041 first, second, and third outer tessellation levels, respectively, and the 1042 tessellation spacing. The original subdivision of the first inner 1043 triangle is retained. The area between the outer and first inner 1044 triangles is completely filled by non-overlapping triangles as described 1045 above. If the first (and only) inner triangle is degenerate, a set of 1046 triangles is produced by connecting each vertex on the outer triangle 1047 edges with the center point. 1048 1049 After all triangles are generated, each vertex in the subdivided triangle 1050 is assigned a barycentric (u,v,w) coordinate based on its location 1051 relative to the three vertices of the outer triangle. 1052 1053 The algorithm used to subdivide the triangular domain in (u,v,w) space 1054 into individual triangles is implementation-dependent. However, the set 1055 of triangles produced will completely cover the domain, and no portion of 1056 the domain will be covered by multiple triangles. The order in which the 1057 generated triangles passed to subsequent pipeline stages and the order of 1058 the vertices in those triangles are both implementation-dependent. 1059 However, when depicted in a manner similar to Figure X.2, the order of the 1060 vertices in the generated triangles will be either all clockwise or all 1061 counter-clockwise, according to the vertex order layout declaration. 1062 1063 1064 Section 2.X.2.2, Quad Tessellation 1065 1066 If the tessellation primitive mode is "quads", a rectangle is subdivided 1067 into a collection of triangles covering the area of the original 1068 rectangle. First, the original rectangle is subdivided into a regular 1069 mesh of rectangles, where the number of rectangles along the u==0 and u==1 1070 (vertical) and v==0 and v==1 (horizontal) edges are derived from the first 1071 and second inner tessellation levels, respectively. All rectangles, 1072 except those adjacent to one of the outer rectangle edges, are decomposed 1073 into triangle pairs. The outermost rectangle edges are subdivided 1074 independently, using the first, second, third, and fourth outer 1075 tessellation levels to control the number of subdivisions of the u==0 1076 (left), v==0 (bottom), u==1 (right), and v==1 (top) edges, respectively. 1077 The area between the inner rectangles of the mesh and the outer rectangle 1078 edges are filled by triangles produced by joining the vertices on the 1079 subdivided outer edges to the vertices on the edge of the inner rectangle 1080 mesh. 1081 1082 If both clamped inner tessellation levels and all four clamped outer 1083 tessellation levels are exactly one, only a single triangle pair covering 1084 the outer rectangle is generated. Otherwise, if either clamped inner 1085 tessellation level is one, that tessellation level is treated as though it 1086 were originally specified as 1+epsilon and will result in a two- or 1087 three-segment subdivision depending on the tessellation spacing. When 1088 used with fractional odd spacing, the three-segment subdivision may 1089 produce "inner" vertices positioned on the edge of the rectangle. 1090 1091 If any tessellation level is greater than one, tessellation begins by 1092 subdividing the u==0 and u==1 edges of the outer rectangle into <m> 1093 segments using the clamped and rounded first inner tessellation level and 1094 the tessellation spacing. The v==0 and v==1 edges are subdivided into <n> 1095 segments using using the second inner tessellation level. Each vertex on 1096 the u==0 and v==0 edges are joined with the corresponding vertex on the 1097 u==1 and v==1 edges to produce a set of vertical and horizontal lines that 1098 divide the rectangle into a grid of smaller rectangles. The primitive 1099 generator emits a pair of non-overlapping triangles covering each such 1100 rectangle not adjacent to an edge of the outer rectangle. The boundary of 1101 the region covered by these triangles forms an inner rectangle, the edges 1102 of which are subdivided by the grid vertices that lie on the edge. If 1103 either <m> or <n> is two, the inner rectangle is degenerate, and one or 1104 both of the rectangle's "edges" consist of a single point. This 1105 subdivision is illustrated in Figure X.3. 1106 1107 (0,1) (1,1) 1108 +--+--+--+--+--+--+--+ 1109 | . . . . . . | 1110 (0,1) (1,1) | . . . . . . | 1111 +--+--+--+--+ +..O--O--O--O--O--O..+ 1112 | . . . | | |**|**|**|**|**| | 1113 | . . . | | |**|**|**|**|**| | 1114 +..O--O--O..+ +..O--+--+--+--+--O..+ 1115 | . . . | | |**|**|**|**|**| | 1116 | . . . | | |**|**|**|**|**| | 1117 +--+--+--+--+ +..O--O--O--O--O--O..+ 1118 (0,0) (1,0) | . . . . . . | 1119 | . . . . . . | 1120 +--+--+--+--+--+--+--+ 1121 (0,0) (1,0) 1122 1123 Figure X.3, Inner Quad Tessellation with inner tessellation levels of 1124 (4,2) and (7,4). The areas labeled with "*" on the right depict the 10 1125 inner rectangles, each of which will be subdivided into two triangles. 1126 The points labeled "O" depict vertices on the boundary of the inner 1127 rectangle, where the inner rectangle on the left side is degenerate (a 1128 single line segment). The dotted lines (".") depict the horizontal and 1129 vertical edges connecting corresponding points on the outer rectangle 1130 edge. 1131 1132 After the area corresponding to the inner rectangle is filled, the 1133 primitive generator must produce triangles to cover area between the inner 1134 and outer rectangles. To do this, the subdivision of the outer rectangle 1135 edge above is discarded. Instead, the u==0, v==0, u==1, and v==1 edges 1136 are subdivided according to the first, second, third, and fourth outer 1137 tessellation levels, respectively, and the tessellation spacing. The 1138 original subdivision of the inner rectangle is retained. The area between 1139 the outer and inner rectangles is completely filled by non-overlapping 1140 triangles. Two of the three vertices of each triangle are adjacent 1141 vertices on a subdivided edge of one rectangle; the third is one of the 1142 vertices on the corresponding edge of the other rectangle. If either edge 1143 of the innermost rectangle is degenerate, the area near the corresponding 1144 outer edges is filled by connecting each vertex on the outer edge with the 1145 single vertex making up the inner "edge". 1146 1147 The algorithm used to subdivide the rectangular domain in (u,v) space into 1148 individual triangles is implementation-dependent. However, the set of 1149 triangles produced will completely cover the domain, and no portion of the 1150 domain will be covered by multiple triangles. The order in which the 1151 generated triangles passed to subsequent pipeline stages and the order of 1152 the vertices in those triangles are both implementation-dependent. 1153 However, when depicted in a manner similar to Figure X.3, the order of the 1154 vertices in the generated triangles will be either all clockwise or all 1155 counter-clockwise, according to the vertex order layout declaration. 1156 1157 1158 Isoline Tessellation 1159 1160 If the tessellation primitive mode is "isolines", a set of independent 1161 horizontal line segments is drawn. The segments are arranged into 1162 connected strips called "isolines", where the vertices of each isoline 1163 have a constant v coordinate and u coordinates covering the full range 1164 [0,1]. The number of isolines generated is derived from the first outer 1165 tessellation level; the number of segments in each isoline is derived from 1166 the second outer tessellation level. Both inner tessellation levels and 1167 the third and fourth outer tessellation levels have no effect in this 1168 mode. 1169 1170 As with quad tessellation above, isoline tessellation begins with a 1171 rectangle. The u==0 and u==1 edges of the rectangle are subdivided 1172 according to the first outer tessellation level. For the purposes of this 1173 subdivision, the tessellation spacing mode is ignored and treated as 1174 equal_spacing. An isoline is drawn connecting each vertex on the u==0 1175 rectangle edge to the corresponding vertex on the u==1 rectangle edge, 1176 except that no line is drawn between (0,1) and (1,1). If the number of 1177 isolines on the subdivided u==0 and u==1 edges is <n>, this process will 1178 result in <n> equally spaced lines with constant v coordinates of 0, 1179 1/<n>, 2/<n>, ..., and (<n>-1)/<n>. 1180 1181 Each of the <n> isolines is then subdivided according to the second outer 1182 tessellation level and the tessellation spacing, resulting in <m> line 1183 segments. Each segment of each line is emitted by the tessellation 1184 primitive generator, as illustrated in Figure X.4. 1185 1186 (0,1) (1,1) 1187 + + (0,1) (1,1) 1188 + + 1189 O---O---O---O---O---O---O 1190 1191 O---O---O---O---O---O---O 1192 1193 O---O---O---O---O---O---O 1194 O-----O-----O-----O 1195 O---O---O---O---O---O---O (0,0) (1,0) 1196 (0,0) (1,0) 1197 1198 Figure X.4, Isoline Tessellation with the first two outer tessellation 1199 levels of (4,6) and (1,3), respectively. The lines connecting the 1200 vertices labeled "O" are emitted by the primitive generator. The 1201 vertices labeled "+" correspond to (u,v) coordinates of (0,1) and (1,1), 1202 where no line segments are generated. 1203 1204 The order in which the generated line segments are passed to subsequent 1205 pipeline stages and the order of the vertices in each generated line 1206 segment are both implementation-dependent. 1207 1208 1209 Section 2.X.3, Tessellation Evaluation Shaders 1210 1211 If active, the tessellation evaluation shader takes the (u,v) or (u,v,w) 1212 location of each vertex in the primitive subdivided by the tessellation 1213 primitive generator, and generates a vertex with a position and associated 1214 attributes. The tessellation evaluation shader can read any of the 1215 vertices of its input patch, which is the output patch produced by the 1216 tessellation control shader (if present) or provided by the application 1217 and transformed by the vertex shader (if no control shader is used). 1218 Evaluating the bivariate polynomials described in Section 5.1 (Evaluators) 1219 using the vertices of the provided patch as control points is one example 1220 of the type of computations that a tessellation evaluation shader might be 1221 expected to perform. Tessellation evaluation shaders are created as 1222 described in section 2.14.1, using a <type> of TESS_EVALUATION_SHADER. 1223 1224 Each invocation of the tessellation evaluation shader writes the 1225 attributes of exactly one vertex. The number of vertices evaluated per 1226 patch depends on the tessellation level values computed by the 1227 tessellation control shaders (if present) or specified as patch 1228 parameters. Tessellation evaluation shader invocations run independently, 1229 and no invocation can access the variables belonging to another 1230 invocation. All invocations are capable of accessing all the vertices of 1231 their corresponding input patch. 1232 1233 If a tessellation control shader is present, the number of the vertices in 1234 the input patch is fixed and is equal to the tessellation control shader 1235 output patch size parameter in effect when the program was last linked. 1236 If no tessellation control shader is present, the input patch is provided 1237 by the application can have a variable number of vertices, as specified by 1238 the PatchParameteri function. 1239 1240 1241 Section 2.X.3.1, Tessellation Evaluation Shader Variables 1242 1243 Tessellation evaluation shaders can access uniforms belonging to the 1244 current program object. The amount of storage available for uniform 1245 variables in the default uniform block accessed by a tessellation 1246 evaluation shader is specified by the value of the 1247 implementation-dependent constant MAX_TESS_EVALUATION_UNIFORM_COMPONENTS. 1248 The total amount of combined storage available for uniform variables in 1249 all uniform blocks accessed by a tessellation evaluation shader (including 1250 the default uniform block) is specified by the value of the 1251 implementation-dependent constant 1252 MAX_COMBINED_TESS_EVALUATION_UNIFORM_COMPONENTS. These values represent 1253 the numbers of individual floating-point, integer, or boolean values that 1254 can be held in uniform variable storage for a tessellation evaluation 1255 shader. A link error is generated if an attempt is made to utilize more 1256 than the space available for tessellation evaluation shader uniform 1257 variables. Uniforms are manipulated as described in section 2.14.4. 1258 Tessellation evaluation shaders also have access to samplers to perform 1259 texturing operations, as described in sections 2.14.5. 1260 1261 Tessellation evaluation shaders can access the transformed attributes of 1262 all vertices for their input primitive using input variables. If active, 1263 a tessellation control shader writing to output variables generates the 1264 values of these input varying variables, including values for built-in as 1265 well as user-defined varying variables. If no tessellation control shader 1266 is active, input variables will be obtained from vertex shader outputs. 1267 Values for any varying variables that are not written by a vertex or 1268 tessellation control shader are undefined. 1269 1270 Additionally, tessellation evaluation shaders can write to one or more 1271 built-in or user-defined output variables that will be passed to 1272 subsequent programmable shader stages or fixed functionality vertex 1273 pipeline stages. 1274 1275 1276 Section 2.X.3.2, Tessellation Evaluation Shader Execution Environment 1277 1278 If a successfully linked program object that contains a tessellation 1279 evaluation shader is made current by calling UseProgram, the executable 1280 version of the tessellation evaluation shader is used to process vertices 1281 produced by the tessellation primitive generator. During this processing, 1282 the shader may access the input patch processed by the primitive 1283 generator. When tessellation evaluation shader execution completes, a new 1284 vertex is assembled from the output variables written by the shader and is 1285 passed to subsequent pipeline stages. 1286 1287 There are several special considerations for tessellation evaluation 1288 shader execution described in the following sections. 1289 1290 Texture Access 1291 1292 The Shader-Only Texturing subsection of section 2.14.7 describes texture 1293 lookup functionality accessible to a vertex shader. The texel fetch and 1294 texture size query functionality described there also applies to 1295 tessellation evaluation shaders. 1296 1297 Tessellation Evaluation Shader Inputs 1298 1299 Section 7.1 of the OpenGL Shading Language Specification describes the 1300 built-in variable array gl_in[] available as input to a tessellation 1301 evaluation shader. gl_in[] receives values from equivalent built-in 1302 output variables written by a previous shader (section 2.14.7). If a 1303 tessellation control shader active, the values of gl_in[] will be taken 1304 from tessellation control shader outputs. Otherwise, they will be taken 1305 from vertex shader outputs. Each array element of gl_in[] is a structure 1306 holding values for a specific vertex of the input patch. The length of 1307 gl_in[] is equal to the implementation-dependent maximum patch size 1308 (gl_MaxPatchVertices). Behavior is undefined if gl_in[] is indexed with a 1309 vertex index greater than or equal to the current patch size. The members 1310 of each element of the gl_in[] array are gl_Position, gl_PointSize, 1311 gl_ClipDistance[], gl_ClipVertex, gl_FrontColor, gl_BackColor, 1312 gl_FrontSecondaryColor, gl_BackSecondaryColor, gl_TexCoord[], and 1313 gl_FogFragCoord[]. 1314 1315 Tessellation evaluation shaders have available several other special input 1316 variables not replicated per-vertex and not contained in gl_in[], 1317 including: 1318 1319 * The variables gl_PatchVerticesIn and gl_PrimitiveID are filled with 1320 the number of the vertices in the input patch and a primitive number, 1321 respectively. They behave exactly as the identically named inputs for 1322 tessellation control shaders. 1323 1324 * The variable gl_TessCoord is a three-component floating-point vector 1325 consisting of the (u,v,w) coordinate of the vertex being processed by 1326 the tessellation evaluation shader. The values of u, v, and w are in 1327 the range [0,1], and vary linearly across the primitive being 1328 subdivided. For tessellation primitive modes of "quads" or 1329 "isolines", the w value is always zero. The (u,v,w) coordinates are 1330 generated by the tessellation primitive generator in a manner 1331 dependent on the primitive mode, as described in section 2.X.2. 1332 gl_TessCoord is not an array; it specifies the location of the vertex 1333 being processed by the tessellation evaluation shader, not of any 1334 vertex in the input patch. 1335 1336 * The variables gl_TessLevelOuter[] and gl_TessLevelInner[] are arrays 1337 holding outer and inner tessellation levels of the patch, as used by 1338 the tessellation primitive generator. If a tessellation control 1339 shader is active, the tessellation levels will be taken from the 1340 corresponding outputs of the tessellation control shader. Otherwise, 1341 the default levels provided as patch parameters are used. 1342 Tessellation level values loaded in these variables will be prior to 1343 the clamping and rounding operations performed by the primitive 1344 generator as described in Section 2.X.2. For triangular tessellation, 1345 gl_TessLevelOuter[3] and gl_TessLevelInner[1] will be undefined. For 1346 isoline tessellation, gl_TessLevelOuter[2], gl_TessLevelOuter[3], and 1347 both values in gl_TessLevelInner[] are undefined. 1348 1349 A tessellation evaluation shader may also declare user-defined per-vertex 1350 input variables. User-defined per-vertex input variables are declared 1351 with the qualifier "in" and have a value for each vertex in the input 1352 patch. User-defined per-vertex input varying variables have a value for 1353 each vertex and thus need to be declared as arrays or inside input blocks 1354 declared as arrays. Declaring an array size is optional. If no size is 1355 specified, it will be taken from the implementation-dependent maximum 1356 patch size (gl_MaxPatchVertices). If a size is specified, it must match 1357 the maximum patch size; otherwise, a compile or link error will occur. Since the 1358 array size may be larger than the number of vertices found in the input 1359 patch, behavior is undefined if a per-vertex input variable is accessed 1360 using an index greater than or equal to the number of vertices in the 1361 input patch. The OpenGL Shading Language doesn't support 1362 multi-dimensional arrays; therefore, user-defined tessellation evaluation 1363 shader inputs corresponding to vertex shader outputs declared as arrays 1364 must be declared as array members of an input block that is itself 1365 declared as an array. 1366 1367 Additionally, a tessellation evaluation shader may declare per-patch input 1368 variables using the qualifier "patch in". Unlike per-vertex inputs, 1369 per-patch inputs do not correspond to any specific vertex in the patch, 1370 and are not indexed by vertex number. Per-patch inputs declared as arrays 1371 have multiple values for the input patch; similarly declared per-vertex 1372 inputs would indicate a single value for each vertex in the output patch. 1373 User-defined per-patch input variables are filled with corresponding 1374 per-patch output values written by the tessellation control shader. If no 1375 tessellation control shader is active, all such variables are undefined. 1376 1377 (Note: minor restructuring in the following paragraph relative to the 1378 equivalent geometry shader language.) 1379 1380 Similarly to the limit on vertex shader output components (see section 1381 2.14.6), there is a limit on the number of components of built-in and 1382 user-defined per-vertex and per-patch input variables that can be read by 1383 the tessellation evaluation shader, given by the values of the 1384 implementation-dependent constants MAX_TESS_EVALUATION_INPUT_COMPONENTS 1385 and MAX_TESS_PATCH_COMPONENTS, respectively. The built-in inputs 1386 gl_TessLevelOuter[] and gl_TessLevelInner[] are not counted against the 1387 per-patch limit. When a program is linked, all components of any varying 1388 and special variable read by a tessellation evaluation shader will count 1389 against this limit. A program whose tessellation evaluation shader 1390 exceeds this limit may fail to link, unless device-dependent optimizations 1391 are able to make the program fit within available hardware resources. 1392 1393 1394 Tessellation Evaluation Shader Outputs 1395 1396 Tessellation evaluation shaders have a number of built-in output variables 1397 used to pass values to equivalent built-in input variables read by 1398 subsequent shader stages or to subsequent fixed functionality vertex 1399 processing pipeline stages. These variables are gl_Position, 1400 gl_PointSize, gl_ClipDistance[], gl_ClipVertex, gl_FrontColor, 1401 gl_BackColor, gl_FrontSecondaryColor, gl_BackSecondaryColor, 1402 gl_TexCoord[], and gl_FogFragCoord[], and all behave identically to 1403 equivalently named vertex shader outputs (section 2.14.7). A tessellation 1404 evaluation shader may also declare user-defined per-vertex output 1405 variables. 1406 1407 (Note: minor restructuring in the following paragraph relative to the 1408 equivalent geometry shader language.) 1409 1410 Similarly to the limit on vertex shader output components (see section 1411 2.14.6), there is a limit on the number of components of built-in and 1412 user-defined output variables that can be written by the tessellation 1413 evaluation shader, given by the values of the implementation-dependent 1414 constant MAX_TESS_EVALUATION_OUTPUT_COMPONENTS. When a program is linked, 1415 all components of any varying and special variable written by a 1416 tessellation evaluation shader will count against this limit. A program 1417 whose tessellation evaluation shader exceeds this limit may fail to link, 1418 unless device-dependent optimizations are able to make the program fit 1419 within available hardware resources. 1420 1421 1422 Modify Section 2.19, Transform Feedback, p. 130 1423 1424 (modify fourth paragraph, p. 131) When transform feedback is active, all 1425 geometric primitives generated must be compatible with the value of 1426 <primitiveMode> ... If a tessellation evaluation or geometry shader is 1427 active, the type of primitive emitted by that shader is used instead of 1428 the <mode> parameter passed to drawing commands. If tessellation 1429 evaluation and geometry shaders are both active, the output primitive type 1430 of the geometry shader will be used for the purposes of this error. 1431 1432 1433Additions to Chapter 3 of the OpenGL 3.2 (Compatibility Profile) Specification (Rasterization) 1434 1435 None. 1436 1437 1438Additions to Chapter 4 of the OpenGL 3.2 (Compatibility Profile) Specification (Per-Fragment 1439Operations and the Frame Buffer) 1440 1441 None. 1442 1443 1444Additions to Chapter 5 of the OpenGL 3.2 (Compatibility Profile) Specification (Special Functions) 1445 1446 None. 1447 1448 1449Additions to Chapter 6 of the OpenGL 3.2 (Compatibility Profile) Specification (State and State 1450Requests) 1451 1452 Modify Section 6.1.16, Shader and Program Queries, p. 384 1453 1454 (modify second paragraph, p. 385) If <pname> is SHADER TYPE, VERTEX 1455 SHADER, TESS_CONTROL_SHADER, TESS_EVALUATION_SHADER, GEOMETRY_SHADER, or 1456 FRAGMENT_SHADER is returned if <shader> is a vertex, tessellation control, 1457 tessellation evaluation, geometry, or fragment shader, respectively. ... 1458 1459 (modify the next-to-last paragraph, p. 385) The command 1460 1461 void GetProgramiv(uint program, enum pname, int *params); 1462 1463 returns integer-valued properties of the program object... 1464 1465 (add two paragraphs after the first paragraph, p. 385) 1466 1467 If <pname> is TESS_CONTROL_OUTPUT_VERTICES, the number of vertices in the 1468 tessellation control shader output patch is returned. If 1469 TESS_CONTROL_OUTPUT_VERTICES is queried for a program which has not been 1470 linked successfully, or which does not contain objects to form a 1471 tessellation control shader, then an INVALID_OPERATION error is generated. 1472 1473 If <pname> is TESS_GEN_MODE, QUADS, TRIANGLES, or ISOLINES is returned, 1474 depending on the primitive mode declaration in the tessellation evaluation 1475 shader. If <pname> is TESS_GEN_SPACING, EQUAL, FRACTIONAL_EVEN, or 1476 FRACTIONAL_ODD is returned, depending on the spacing declaration in the 1477 tessellation evaluation shader. If <pname> is TESS_GEN_VERTEX_ORDER, CCW 1478 or CW is returned, depending on the vertex order declaration in the 1479 tessellation evaluation shader. If <pname> is TESS_GEN_POINT_MODE, TRUE 1480 is returned if point mode is enabled in a tessellation evaluation shader 1481 declaration; FALSE is returned otherwise. If any of the <pname> values in 1482 this paragraph are queried for a program which has not been linked 1483 successfully, or which does not contain objects to form a tessellation 1484 evaluation shader, then an INVALID_OPERATION error is generated. 1485 1486 1487Additions to Appendix A of the OpenGL 3.2 (Compatibility Profile) Specification (Invariance) 1488 1489 Insert new section before Section A.4, What this All Means (p. 457) 1490 1491 Section A.X, Tessellation Invariance 1492 1493 When using a program containing tessellation evaluation shaders, the 1494 fixed-function tessellation primitive generator consumes the input patch 1495 specified by an application and emits a new set of primitives. The 1496 following invariance rules are intended to provide repeatability 1497 guarantees. Additionally, they are intended to allow an application with 1498 a carefully crafted tessellation evaluation shader to ensure that the sets 1499 of triangles generated for two adjacent patches have identical vertices 1500 along shared patch edges, avoiding "cracks" caused by minor differences in 1501 the positions of vertices along shared edges. 1502 1503 Rule 1: When processing two patches with identical outer and inner 1504 tessellation levels, the tessellation primitive generator will emit an 1505 identical set of point, line, or triangle primitives as long as the active 1506 program used to process the patch primitives has tessellation evaluation 1507 shaders specifying the same tessellation mode, spacing, vertex order, and 1508 point mode input layout qualifiers. Two sets of primitives are considered 1509 identical if and only if they contain the same number and type of 1510 primitives and the generated tessellation coordinates for the vertex 1511 numbered <m> of the primitive numbered <n> are identical for all values of 1512 <m> and <n>. 1513 1514 Rule 2: The set of vertices generated along the outer edge of the 1515 subdivided primitive in triangle and quad tessellation, and the 1516 tessellation coordinates of each, depends only on the corresponding outer 1517 tessellation level and the spacing input layout qualifier in the 1518 tessellation evaluation shader of the active program. 1519 1520 Rule 3: The set of vertices generated when subdividing any outer 1521 primitive edge is always symmetric. For triangle tessellation, if the 1522 subdivision generates a vertex with tessellation coordinates of the form 1523 (0,x,1-x), (x,0,1-x), or (x,1-x,0), it will also generate a vertex with 1524 coordinates of exactly (0,1-x,x), (1-x,0,x), or (1-x,x,0), respectively. 1525 For quad tessellation, if the subdivision generates a vertex with 1526 coordinates of (x,0) or (0,x), it will also generate a vertex with 1527 coordinates of exactly (1-x,0) or (0,1-x), respectively. For isoline 1528 tessellation, if it generates vertices at (0,x) and (1,x) where <x> is 1529 not zero, it will also generate vertices at exactly (0,1-x) and (1,1-x), 1530 respectively. 1531 1532 Rule 4: The set of vertices generated when subdividing outer edges in 1533 triangular and quad tessellation must be independent of the specific edge 1534 subdivided, given identical outer tessellation levels and spacing. For 1535 example, if vertices at (x,1-x,0) and (1-x,x,0) are generated when 1536 subdividing the w==0 edge in triangular tessellation, vertices must be 1537 generated at (x,0,1-x) and (1-x,0,x) when subdividing an otherwise 1538 identical v==0 edge. For quad tessellation, if vertices at (x,0) and 1539 (1-x,0) are generated when subdividing the v==0 edge, vertices must be 1540 generated at (0,x) and (0,1-x) when subdividing an otherwise identical 1541 u==0 edge. 1542 1543 Rule 5: When processing two patches that are identical in all respects 1544 enumerated in rule 1 except for vertex order, the set of triangles 1545 generated for triangle and quad tessellation must be identical except for 1546 vertex and triangle order. For each triangle <n1> produced by processing 1547 the first patch, there must be a triangle <n2> produced when processing 1548 the second patch each of whose vertices has the same tessellation 1549 coordinates as one of the vertices in <n1>. 1550 1551 Rule 6: When processing two patches that are identical in all respects 1552 enumerated in rule 1 other than matching outer tessellation levels and/or 1553 vertex order, the set of interior triangles generated for triangle and 1554 quad tessellation must be identical in all respects except for vertex and 1555 triangle order. For each interior triangle <n1> produced by processing 1556 the first patch, there must be a triangle <n2> produced when processing 1557 the second patch each of whose vertices has the same tessellation 1558 coordinates as one of the vertices in <n1>. A triangle produced by the 1559 tessellator is considered an interior triangle if none of its vertices lie 1560 on an outer edge of the subdivided primitive. 1561 1562 Rule 7: For quad and triangle tessellation, the set of triangles 1563 connecting an inner and outer edge depends only on the inner and outer 1564 tessellation levels corresponding to that edge and the spacing input 1565 layout qualifier. 1566 1567 Rule 8: The value of all defined components of gl_TessCoord will be in 1568 the range [0,1]. Additionally, for any defined component <x> of 1569 gl_TessCoord, the results of computing (1.0-<x>) in a tessellation 1570 evaluation shader will be exact. Some floating-point values in the range 1571 [0,1] may fail to satisfy this property, but such values may never be used 1572 as tessellation coordinate components. 1573 1574 1575Additions to the AGL/GLX/WGL Specifications 1576 1577 None. 1578 1579 1580Additions to the OpenGL Shading Language Specification, version 1.50 (Revision 158109) 1582 1583 Including the following line in a shader can be used to control the 1584 language features described in this extension: 1585 1586 #extension GL_ARB_tessellation_shader : <behavior> 1587 1588 where <behavior> is as specified in section 3.3. 1589 1590 A new preprocessor #define is added to the OpenGL Shading Language: 1591 1592 #define GL_ARB_tessellation_shader 1 1593 1594 1595 Modify Chapter 2, Overview of OpenGL Shading, p. 5 1596 1597 (modify first two introductory paragraphs) 1598 1599 The OpenGL Shading Language is actually several closely related languages. 1600 These languages are used to create shaders for the programmable processors 1601 contained in the OpenGL processing pipeline. Currently, these processors 1602 are the vertex, tessellation control, tessellation evaluation, geometry, 1603 and fragment processors. 1604 1605 Unless otherwise noted in this paper, a language feature applies to all 1606 languages, and common usage will refer to these languages as a single 1607 language. The specific languages will be referred to by the name of the 1608 processor they target: vertex, tessellation control, tessellation 1609 evalution, geometry, or fragment. 1610 1611 (Insert two new sections after Section 2.1, Vertex Processor, p. 5.) 1612 1613 1614 Section 2.X, Tessellation Control Processor 1615 1616 The tessellation control processor is a programmable unit that operates on 1617 a patch of incoming vertices and their associated data, emitting a new 1618 output patch. Compilation units written in the OpenGL Shading Language to 1619 run on this processor are called tessellation control shaders. When a 1620 complete set of tessellation control shaders are compiled and linked, they 1621 result in a tessellation control shader executable that runs on the 1622 tessellation control processor. 1623 1624 The tessellation control processor spawns a separate shader invocation for 1625 each vertex of the output patch. Each invocation can read the attributes 1626 of any vertex in the input or output patches, but can only write 1627 per-vertex attributes for the corresponding output patch vertex. The 1628 shader invocations collectively produce a set of per-patch attributes for 1629 the output patch. After all tessellation control shader invocations have 1630 completed, the output vertices and per-patch attributes are assembled to 1631 form a patch to be used by subsequent pipeline stages. 1632 1633 Tessellation control shader invocations run mostly independently, with 1634 undefined relative execution order. However, the built-in function 1635 barrier() can be used to control execution order by synchronizing 1636 invocations, effectively dividing tessellation control shader execution 1637 into a set of phases. Tessellation control shaders will get undefined 1638 results if one invocation reads a per-vertex or per-patch attribute 1639 written by another invocation at any point during the same phase, or if 1640 two invocations attempt to write different values to the same per-patch 1641 output in a single phase. 1642 1643 1644 Section 2.Y, Tessellation Evaluation Processor 1645 1646 The tessellation evaluation processor is a programmable unit that 1647 evaluates the position and other attributes of a vertex generated by the 1648 tessellation primitive generator, using a patch of incoming vertices and 1649 their associated data. Compilation units written in the OpenGL Shading 1650 Language to run on this processor are called tessellation evaluation 1651 shaders. When a complete set of tessellation evaluation shaders are 1652 compiled and linked, they result in a tessellation evaluation shader 1653 executable that runs on the tessellation evaluation processor. 1654 1655 The tessellation evaluation processor operates to compute the position and 1656 attributes of a single vertex generated by the tessellation primitive 1657 generator. The executable can read the attributes of any vertex in the 1658 input patch, plus the tessellation coordinate, which is the relative 1659 location of the vertex in the primitive being tessellated. The executable 1660 writes the position and other attributes of the vertex. 1661 1662 1663 Modify Section 3.6, Keywords, p. 14 1664 1665 (add the following to the keyword list) 1666 1667 patch 1668 1669 1670 Modify Section 4.2, Scoping, p. 27 1671 1672 (remove "(vertex, geometry, or fragment)" from the last paragraph of p. 28) 1673 1674 1675 Modify Section 4.3, Storage Qualifiers, p. 29 1676 1677 (add two new qualifiers to the first table, p. 29) 1678 1679 Qualifier Meaning 1680 --------- ------------------------------------------------------------- 1681 patch in linkage of per-patch attributes into a shader from a previous 1682 stage (tessellation evaluation shaders only) 1683 1684 patch out linkage out of a shader to a subsequent stage (tessellation 1685 control shaders only) 1686 1687 1688 Modify Section 4.3.4, Inputs, p. 31 1689 1690 (modify second paragraph, p. 31) Shader input variables are declared with 1691 the "in", "centroid in", or "patch in" storage qualifiers. They form the 1692 input interface between previous stages of the OpenGL pipeline and the 1693 declaring shader. ... 1694 1695 (modify third paragraph, p. 31) Vertex shader input variables (or 1696 attributes) ... It is an error to use "centroid in" or "patch in" in a 1697 vertex shader. ... 1698 1699 (modify next-to-last paragraph, p. 31, and subsequent paragraphs, making 1700 geometry shader language apply to tessellation control and evaluation 1701 shaders as well) 1702 1703 Tessellation control, evaluation, and geometry shader input variables get 1704 the per-vertex values written out to output variables of the same names in 1705 the previous active shader stage. They are typically declared with the 1706 "in" or "centroid in" storage qualifier. For these inputs, "centroid in" 1707 and interpolation qualifiers are allowed, but have no effect. Since 1708 tessellation control, tessellation evaluation, and geometry shaders 1709 operate on a primitive comprising multiple vertices, each input varying 1710 variable (or input block, see interface blocks below) needs to be declared 1711 as an array. For example, 1712 1713 in float foo[]; // input for previous-stage output "out float foo" 1714 1715 Each element of such an array corresponds to one vertex of the primitive 1716 being processed. Each array can optionally have a size declared. The array 1717 size will be set by, (or if provided must be consistent with) the input 1718 layout declaration(s) establishing the type of input primitive, as 1719 described later in section 4.3.8.1 Input Layout Qualifiers. 1720 1721 For the interface from a previous shader stage to a tessellation control, 1722 tessellation evaluation, or geometry shader, output variables from the 1723 previous stage must match input variables of the same name in type and 1724 qualification, except perhaps that the inputs must be declared as an array 1725 indexed by vertex number. If any variables fail to match, a link error 1726 will occur. 1727 1728 If the output of the previous shader is itself an array with multiple 1729 values per vertex, it must appear in an output block (see interface blocks 1730 below) in the previous shader and in an input block in the tessellation 1731 control, evaluation, or geometry shader with a block instance name 1732 declared as an array. Use of blocks are required because two-dimensional 1733 arrays are not supported. 1734 1735 Additionally, tessellation evaluation shaders support per-patch input 1736 variables declared with the "patch in" qualifier. Per-patch input 1737 variables are filled with the values of per-patch output variables written 1738 by the tessellation control shader. Per-patch inputs may be declared as 1739 one-dimensional arrays, but are not indexed by vertex number. Input 1740 variables may not be declared using the "patch in" qualifier in 1741 tessellation control or geometry shaders. As with other input variables, 1742 per-patch inputs must be declared using the same type and qualifiers as 1743 per-patch outputs from the previous (tessellation control) shader stage. 1744 1745 (modify third paragraph, p. 32) Fragment shader ... deprecated "varying" 1746 and "centroid varying" modifiers. It is an error to use "patch in" in a 1747 fragment shader. ... 1748 1749 (modify last paragraph of the section) The fragment shader inputs form an 1750 interface with the last active shader in the vertex processing pipeline. 1751 For this interface, the prior stage shader output variables and fragment 1752 shader input variables of the same name must match in type and 1753 qualification (other than out matching to in). 1754 1755 1756 Modify Section 4.3.6, Outputs, p. 33 1757 1758 (modify first paragraph of the section, p. 33) Shader output variables are 1759 declared with the "out", "centroid out", or "patch out" storage 1760 qualifiers. ... 1761 1762 (modify third paragraph of the section, p. 33) Vertex, tessellation 1763 evaluation, and geometry shader output variables output per-vertex data 1764 ... deprecated varying storage qualifier. It is an error to use "patch 1765 out" in a vertex, tessellation evaluation, or geometry shader. ... 1766 1767 (modify the fourth paragraph of the section, p. 33) Individual vertex, 1768 tessellation evaluation, and geometry outputs are ... 1769 1770 (insert prior to the last paragraph, p. 33) 1771 1772 Tessellation control shader output variables may be used to output 1773 per-vertex and per-patch data. Per-vertex output variables are declared 1774 using the "out" or "centroid out" storage qualifiers; per-patch output 1775 variables are declared using the "patch out" storage qualifier. 1776 Per-vertex and per-patch output variables can only be float, 1777 floating-point vectors, matrices, signed or unsigned integers or integer 1778 vectors, or arrays or structures of any these. Since tessellation control 1779 shaders produce a primitive comprising multiple vertices, each per-vertex 1780 output variable (or output block, see interface blocks below) needs to be 1781 declared as an array. For example, 1782 1783 out float foo[]; // feeds next-stage input "in float foo[]" 1784 1785 Each element of such an array corresponds to one vertex of the primitive 1786 being produced. Each array can optionally have a size declared. The 1787 array size will be set by (or if provided must be consistent with) the 1788 output layout declaration(s) establishing the number of vertices in the 1789 output patch, as described later in section 4.3.8.2, Output Layout 1790 Qualifiers. 1791 1792 If a per-vertex output of the tessellation control shader is itself an 1793 array with multiple values per vertex, it must appear in an output block 1794 (see interface blocks below) in the tessellation control shader with a 1795 block instance name declared as an array. Use of blocks are required 1796 because two-dimensional arrays are not supported. 1797 1798 Each tessellation control shader invocation has a corresponding output 1799 patch vertex, and may assign values to per-vertex outputs only if they 1800 belong to that corresponding vertex. If a per-vertex output variable is 1801 used as an l-value, it is an error if the expression indicating the vertex 1802 number is not the identifier "gl_InvocationID". 1803 1804 The order of execution of a tessellation control shader invocation 1805 relative to the other invocations for the same input patch is undefined 1806 unless the built-in function barrier() is used. This provides some 1807 control over relative execution order. When a shader invocation calls the 1808 barrier() function, its execution pauses until all other invocations have 1809 called the same function. Output variable assignments performed by any 1810 invocation executed prior to calling barrier() will be visible to any 1811 other invocation after the call to barrier() returns. 1812 1813 Because tessellation control shader invocations may execute in undefined 1814 order between barriers, the values of per-vertex or per-patch output 1815 variables will sometimes be undefined. If the beginning and end of shader 1816 execution and each call to barrier() are considered synchronization 1817 points, the value of an output variable will be undefined in any of the 1818 three following cases: 1819 1820 (1) at the beginning of execution; 1821 1822 (2) at each synchronization point, unless: 1823 1824 * the value was well-defined after the previous synchronization 1825 point and was not written by any invocation since; 1826 1827 * the value was written by exactly one shader invocation since the 1828 previous synchronization point; or 1829 1830 * the value was written by multiple shader invocations since the 1831 previous synchronization point, and the last write performed by 1832 all such invocations wrote the same value; or 1833 1834 (3) when read by a shader invocation, if: 1835 1836 * the value was undefined at the previous synchronization point and 1837 has not been writen by the same shader invocation since; or 1838 1839 * the output variable is written to by any other shader invocation 1840 between the previous and next synchronization points, even if that 1841 assignment occurs in code following the read. 1842 1843 If the value of an output variable is undefined at the end of shader 1844 execution, the value passed to subsequent pipeline stages will be likewise 1845 undefined. 1846 1847 1848 (modify last paragraph, p. 33) Fragment outputs ... "out" storage 1849 qualifier. It is an error to use "centroid out" or "patch out" in a 1850 fragment shader. ... 1851 1852 1853 Modify Section 4.3.8.1, Input Layout Qualifiers, p. 37 1854 1855 (modify first paragraph of the section) Vertex and tessellation control 1856 shaders do not have any input layout qualifiers. 1857 1858 (insert after first paragraph of the section) 1859 1860 Tessellation evaluation shaders allow input layout qualifiers only on the 1861 interface qualifier in, not on an input block, block member, or variable 1862 declarations. The input layout qualifier identifiers allowed for 1863 tessellation evaluation shaders are: 1864 1865 layout-qualifier-id 1866 triangles 1867 quads 1868 isolines 1869 equal_spacing 1870 fractional_even_spacing 1871 fractional_odd_spacing 1872 cw 1873 ccw 1874 point_mode 1875 1876 One group of identifiers is used to specify a tessellation primitive mode 1877 to be used by the tessellation primitive generator. To specify a 1878 primitive mode, the identifier must be one of "triangles", "quads", or 1879 "isolines", which specify that the tessellation primitive generator should 1880 subdivide a triangle into smaller triangles, a quad into triangles, or a 1881 quad into a collection of lines, respectively. 1882 1883 A second group of identifiers is used to specify the vertex spacing used 1884 by the tessellation primitive generator when subdividing an edge. To 1885 specify vertex spacing, the identifier must be one of: 1886 1887 * "equal_spacing", signifying that edges should be divided into a 1888 collection of <N> equal-sized segments; 1889 1890 * "fractional_even_spacing", signifying that edges should be divided 1891 into an even number of equal-length segments plus two additional 1892 shorter "fractional" segments; or 1893 1894 * "fractional_odd_spacing", signifying that edges should be divided into 1895 an odd number of equal-length segments plus two additional shorter 1896 "fractional" segments. 1897 1898 A third group of identifiers specifies whether the tessellation primitive 1899 generator produces triangles in clockwise or counter-clockwise order, 1900 according to the coordinate system depicted in the OpenGL specification. 1901 The identifiers "cw" and "ccw" indicate clockwise and counter-clockwise 1902 triangles, respectively. If the tessellation primitive generator does not 1903 produce triangles, the order is ignored. 1904 1905 The identifier "point_mode" specifies that the tessellation primitive 1906 generator should produce one point for each distinct vertex in the 1907 subdivided primitive, rather than generating lines or triangles. 1908 1909 Any or all of these identifiers may be specified one or more times in a 1910 single input layout declaration. 1911 1912 At least one tessellation evaluation shader (compilation unit) in a 1913 program must declare a primitive mode in its input layout; declarations 1914 spacing, vertex order, and point mode qualifiers are optional. It is not 1915 required that all tessellation evaluation shaders in a program declare a 1916 primitive mode. If spacing or vertex order declarations are omitted, the 1917 tessellation primitive generator will use equal spacing or 1918 counter-clockwise vertex ordering, respectively. If a point mode 1919 declaration is omitted, the tessellation primitive generator will produce 1920 lines or triangles according to the primitive mode. If primitive mode, 1921 spacing, or vertex order is declared more than once in the tessellation 1922 evaluation shaders of a program, all such declarations must use the same 1923 identifier. 1924 1925 (modify third paragraph, p. 38) All unsized tessellation control and 1926 evaluation shader input array declations will be sized to match the 1927 implementation-dependent maximum patch size (gl_MaxPatchVertices). All 1928 unsized geometry shader input declarations ... 1929 1930 (modify fourth paragraph, p. 38) The intrinsically declared input array 1931 gl_in[] will also be sized according to the maximum patch size or a 1932 geometry shader input layout declaration. Hence, the expression 1933 1934 gl_in.length() 1935 1936 will return the maximum patch size or a value from the table above. 1937 1938 1939 Modify Section 4.3.8.2, Output Layout Qualifiers, p. 40 1940 1941 (modify first paragraph, p. 40) Vertex, tessellation evaluation, and 1942 fragment shaders cannot have output layout qualifiers. 1943 1944 (insert after first paragraph of the section) 1945 1946 Tessellation control shaders allow output layout qualifiers only on the 1947 interface qualifier out, not on an output block, block member, or variable 1948 declarations. The output layout qualifier identifiers allowed for 1949 tessellation control shaders are: 1950 1951 layout-qualifier-id 1952 vertices = integer-constant 1953 1954 The identifier "vertices" specifies the number of vertices in the output 1955 patch produced by the tessellation control shader, which also specifies 1956 the number of times the tessellation control shader is invoked. It is an 1957 error for the output vertex count to be less than or equal to zero, or 1958 greater than the implementation-dependent maximum patch size. 1959 1960 The intrinsically declared tessellation control output array gl_out[] will 1961 also be sized by any output layout declaration. Hence, the expression 1962 1963 gl_out.length() 1964 1965 will return the output patch vertex count specified in a previous output 1966 layout qualifier. For outputs declared without an array size, including 1967 intrinsically declared outputs (i.e., gl_out), a layout must be declared 1968 before any use of the method length() or other array use that requires its 1969 size to be known. 1970 1971 It is a compile-time error if the output patch vertex count specified in 1972 an output layout qualifier does not match the array size specified in any 1973 output variable declaration in the same shader. 1974 1975 All tessellation control shader layout declarations in a program must 1976 specify the same output patch vertex count. There must be at least one 1977 layout qualifier specifying an output patch vertex count in any program 1978 containing tessellation control shaders; however, such a declaration is 1979 not required in all tessellation control shader compilation units. 1980 1981 1982 (Coalesce Sections 7.1., 7.2, and 7.6 into a single section, as described 1983 below.) 1984 1985 Section 7.1, Built-In Shader Special Inputs and Outputs 1986 1987 Some OpenGL operations occur in fixed functionality and need to provide 1988 values to or receive values from shader executables. Shaders communicate 1989 with fixed-function OpenGL pipeline stages, and optionally with other 1990 shaders, through the use of built-in input and output variables. 1991 1992 1993 In the vertex language, built-in input and output variables are 1994 intrinsically declared as: 1995 1996 in int gl_VertexID; 1997 in int gl_InstanceID; 1998 1999 out gl_PerVertex { 2000 vec4 gl_Position; 2001 float gl_PointSize; 2002 float gl_ClipDistance[]; 2003 }; 2004 2005 The variable gl_VertexID is a vertex shader input variable that holds an 2006 integer index for the vertex, as defined under Shader Inputs in section 2007 2.11.7 in the OpenGL Graphics System Specification. While the variable 2008 gl_VertexID is always present, its value is not always defined. 2009 2010 The variable gl_InstanceID is a vertex shader input variable that holds 2011 the integer index of the current primitive in an instanced draw call (see 2012 Shader Inputs in section 2.11.7 in the OpenGL Graphics System 2013 Specification). If the current primitive does not come from an instanced 2014 draw call, the value of gl_InstanceID is zero. 2015 2016 The variable gl_Position is intended for writing the homogeneous vertex 2017 position. It can be written at any time during shader execution. This 2018 value will be used by primitive assembly, clipping, culling, and other 2019 fixed functionality operations, if present, that operate on primitives 2020 after vertex processing has occurred. Its value is undefined after the 2021 vertex processing stage if the vertex shader executable does not write 2022 gl_Position, and it is undefined after geometry processing if the geometry 2023 executable calls EmitVertex() without having written gl_Position since the 2024 last EmitVertex() (or hasn't written it at all). 2025 2026 The variable gl_PointSize is intended for a shader to write the size of 2027 the point to be rasterized. It is measured in pixels. If gl_PointSize is 2028 not written to, its value is undefined in subsequent pipe stages. 2029 2030 (note: Changed the wording of this a bit from 1.50, to remove the mention 2031 of maintaining clip planes and computing distances, which isn't required 2032 to use the feature. Also tweaked a reference to gl_MaxVaryingComponents 2033 in the following paragraph.) 2034 2035 The variable gl_ClipDistance provides the forward compatible mechanism for 2036 controlling user clipping. gl_ClipDistance[i] specifies a clip distance 2037 for each plane i. A distance of 0 means the vertex is on the plane, a 2038 positive distance means the vertex is inside the clip plane, and a 2039 negative distance means the point is outside the clip plane. The clip 2040 distances will be linearly interpolated across the primitive and the 2041 portion of the primitive with interpolated distances less than 0 will be 2042 clipped. 2043 2044 The gl_ClipDistance array is predeclared as unsized and must be sized by 2045 the shader either redeclaring it with a size or indexing it only with 2046 integral constant expressions. This needs to size the array to include all 2047 the clip planes that are enabled via the OpenGL API; if the size does not 2048 include all enabled planes, results are undefined. The size can be at most 2049 gl_MaxClipDistances. The number of input or output components consumed by 2050 gl_ClipDistance will match the size of the array, no matter how many 2051 planes are enabled. The shader must also set all values in gl_ClipDistance 2052 that have been enabled via the OpenGL API, or results are 2053 undefined. Values written into gl_ClipDistance for planes that are not 2054 enabled have no effect. 2055 2056 2057 In the tessellation control language, built-in input and output variables 2058 are intrinsically declared as: 2059 2060 in gl_PerVertex { 2061 vec4 gl_Position; 2062 float gl_PointSize; 2063 float gl_ClipDistance[]; 2064 } gl_in[gl_MaxPatchVertices]; 2065 in int gl_PatchVerticesIn; 2066 in int gl_PrimitiveID; 2067 in int gl_InvocationID; 2068 2069 out gl_PerVertex { 2070 vec4 gl_Position; 2071 float gl_PointSize; 2072 float gl_ClipDistance[]; 2073 } gl_out[gl_VerticesOut]; 2074 2075 patch out float gl_TessLevelOuter[4]; 2076 patch out float gl_TessLevelInner[2]; 2077 2078 The input variables gl_Position, gl_PointSize, and gl_ClipDistance read 2079 corresponding outputs written by the vertex shader. The output variables 2080 of the same names behave as described for the identical vertex shader 2081 outputs. 2082 2083 The variable gl_PatchVerticesIn is available only in the tessellation 2084 control and evaluation languages. It is an integer specifying the number 2085 of vertices in the input patch being processed by the shader. A single 2086 tessellation control or evaluation shader can read patches of differening 2087 sizes, so the value of gl_PatchVerticesIn may differ between patches. 2088 2089 The input variable gl_PrimitiveID is available only in the tessellation 2090 control, tessellation evaluation, and fragment languages. For 2091 tessellation control and evaluation shaders, it is filled with the number 2092 of primitives processed by the shader since the current set of rendering 2093 primitives was started. For fragment shaders, it is filled with the value 2094 written to the gl_PrimitiveID geometry shader output if a geometry shader 2095 is present. Otherwise, it is assigned in the same manner as with 2096 tessellation control and evaluation shaders. 2097 2098 The input variable gl_InvocationID is available only in the tessellation 2099 control and geometry language. In the tessellation control shader, it 2100 identifies the number of the output patch vertex assigned to the 2101 tessellation control shader invocation. In the geometry shader, it 2102 identifies the invocation number assigned to the geometry shader 2103 invocation. In both cases, gl_InvocationID is assigned integer values in 2104 the range [0, <N>-1], where <N> is the number of output patch vertices or 2105 geometry shader invocations per primitive. 2106 2107 The output variables gl_TessLevelOuter[] and gl_TessLevelInner[] are 2108 available only in the tessellation control language. The values written 2109 to these variables are assigned to the corresponding outer and inner 2110 tessellation levels of the output patch. They are used by the 2111 tessellation primitive generator to control primitive tessellation and may 2112 be read by tessellation evaluation shaders. 2113 2114 2115 In the tessellation evaluation language, built-in input and output 2116 variables are intrinsically declared as: 2117 2118 in gl_PerVertex { 2119 vec4 gl_Position; 2120 float gl_PointSize; 2121 float gl_ClipDistance[]; 2122 } gl_in[gl_MaxPatchVertices]; 2123 in int gl_PatchVerticesIn; 2124 in int gl_PrimitiveID; 2125 in vec3 gl_TessCoord; 2126 patch in float gl_TessLevelOuter[4]; 2127 patch in float gl_TessLevelInner[2]; 2128 2129 out gl_PerVertex { 2130 vec4 gl_Position; 2131 float gl_PointSize; 2132 float gl_ClipDistance[]; 2133 }; 2134 2135 The input variables gl_Position, gl_PointSize, gl_ClipDistance read 2136 corresponding outputs written by the previous shader (vertex or 2137 tessellation control). The output variables of the same names behave as 2138 described for the identical vertex shader outputs. 2139 2140 The input variables gl_PatchVerticesIn and gl_PrimitiveID behave as in the 2141 identically-named tessellation control shader inputs. 2142 2143 The variable gl_TessCoord is available only in the tessellation evaluation 2144 language. It specifies a three-component (u,v,w) vector identifying the 2145 position of the vertex being processed by the shader relative to the 2146 primitive being tessellated. 2147 2148 The input variables gl_TessLevelOuter[] and gl_TessLevelInner[] are 2149 available only in the tessellation evaluation shader. If a tessellation 2150 control shader is active, these variables are filled with corresponding 2151 outputs written by the tessellation control shader. Otherwise, they are 2152 assigned with default tessellation levels specified in the OpenGL API. 2153 2154 2155 In the geometry language, built-in input and output variables are 2156 intrinsically declared as: 2157 2158 in gl_PerVertex { 2159 vec4 gl_Position; 2160 float gl_PointSize; 2161 float gl_ClipDistance[]; 2162 } gl_in[]; 2163 in int gl_PrimitiveIDIn; 2164 2165 out gl_PerVertex { 2166 vec4 gl_Position; 2167 float gl_PointSize; 2168 float gl_ClipDistance[]; 2169 }; 2170 out int gl_PrimitiveID; 2171 out int gl_Layer; 2172 2173 The input variables gl_Position, gl_PointSize, gl_ClipDistance read 2174 corresponding outputs written by the previous shader (vertex or 2175 tessellation control). The output variables of the same names behave as 2176 described for the identical vertex shader outputs. 2177 2178 The input variable gl_PrimitiveIDIn behaves identically to the 2179 tessellation control and evaluation shader input variable gl_PrimitiveID. 2180 2181 The output variable gl_PrimitiveID is available only in the geometry 2182 language and provides a single integer that serves as a primitive 2183 identifier. This is then available to fragment shaders as the fragment 2184 input gl_PrimitiveID, which will select the written primitive ID from the 2185 provoking vertex in the primitive being shaded. If a fragment shader using 2186 gl_PrimitiveID is active and a geometry shader is also active, the 2187 geometry shader must write to gl_PrimitiveID or the fragment shader input 2188 gl_PrimitiveID is undefined. See section 2.12.4 (under Geometry Shader 2189 Outputs) and section 3.9.2 (under Shader Inputs) of the OpenGL Graphics 2190 System Specification for more information. 2191 2192 The output variable gl_Layer is available only in the geometry language, 2193 and is used to select a specific layer of a multi-layer framebuffer 2194 attachment. The actual layer used will come from one of vertices in the 2195 primitive being shaded. Which vertex the layer comes from is undefined, so 2196 it is best to write the same layer value for all vertices of a 2197 primitive. If a shader statically assigns a value to gl_Layer, layered 2198 rendering mode is enabled. See section 2.12.4 (under Geometry Shader 2199 Outputs) and section 4.4.7 Layered Framebuffers of the OpenGL Graphics 2200 System Specification for more information. If a shader statically assigns 2201 a value to gl_Layer, and there is an execution path through the shader 2202 that does not set gl_Layer, then the value of gl_Layer is undefined for 2203 executions of the shader that take that path. 2204 2205 2206 In the fragment language, built-in input and output variables are 2207 intrinsically declared as: 2208 2209 in vec4 gl_FragCoord; 2210 in bool gl_FrontFacing; 2211 in float gl_ClipDistance[]; 2212 in vec2 gl_PointCoord; 2213 in int gl_PrimitiveID; 2214 2215 out vec4 gl_FragColor; // deprecated 2216 out vec4 gl_FragData[gl_MaxDrawBuffers]; // deprecated 2217 out float gl_FragDepth; 2218 2219 (copy the variable descriptions verbatim from Section 7.2) 2220 2221 2222 Section 7.1.1, Compatibility Profile Built-In Shader Special Variables 2223 2224 When using the compatibility profile, the GL can provide fixed 2225 functionality behavior for the vertex and fragment programmable pipeline 2226 stages. For example, mixing a fixed functionality vertex stage with a 2227 programmable fragment stage. 2228 2229 The following built-in vertex, tessellation control, tessellation 2230 evaluation, and geometry output variables are available to specify inputs 2231 for the subsequent programmable shader stage or the fixed functionality 2232 fragment stage. A particular one should be written to if any 2233 functionality in a corresponding shader or fixed pipeline uses it or state 2234 derived from it. Otherwise, behavior is undefined. The following members 2235 are added to the output gl_PerVertex block in these languages: 2236 2237 out gl_PerVertex { 2238 // in addition to other gl_PerVertex members... 2239 vec4 gl_ClipVertex; 2240 vec4 gl_FrontColor; 2241 vec4 gl_BackColor; 2242 vec4 gl_FrontSecondaryColor; 2243 vec4 gl_BackSecondaryColor; 2244 vec4 gl_TexCoord[]; 2245 float gl_FogFragCoord; 2246 }; 2247 2248 The variable gl_ClipVertex provides a place for vertex and geometry 2249 shaders to write the coordinate to be used with the user clipping planes. 2250 2251 The user must ensure the clip vertex and user clipping planes are defined 2252 in the same coordinate space. User clip planes work properly only under 2253 linear transform. It is undefined what happens under nonlinear transform. 2254 2255 If a linked set of shaders forming a program contains no static write to 2256 gl_ClipVertex or gl_ClipDistance, but the application has requested 2257 clipping against user clip planes through the API, then the coordinate 2258 written to gl_Position is used for comparison against the user clip 2259 planes. Writing to gl_ClipDistance is the preferred method for user 2260 clipping. It is an error for the set of shaders forming a program to 2261 statically read or write both gl_ClipVertex and gl_ClipDistance. 2262 2263 gl_FrontColor, glFrontSecondaryColor, gl_BackColor, and 2264 glBackSecondaryColor assigns primary and secondary colors for front and 2265 back faces of primitives containing the vertex being processed. 2266 gl_TexCoord assigns texture coordinates for the vertex being processed. 2267 2268 For gl_FogFragCoord, the value written will be used as the "c" value in 2269 section 3.11 of the OpenGL Graphics System Specification, by the fixed 2270 functionality pipeline. For example, if the z-coordinate of the fragment 2271 in eye space is desired as "c", then that's what the vertex shader 2272 executable should write into gl_FogFragCoord. 2273 2274 As with all arrays, indices used to subscript gl_TexCoord must either be 2275 an integral constant expressions, or this array must be re-declared by the 2276 shader with a size. The size can be at most gl_MaxTextureCoords. Using 2277 indexes close to 0 may aid the implementation in preserving varying 2278 resources. 2279 2280 In the tessellation control, evaluation, and geometry shaders, the outputs 2281 of the previous stage described above are also available in the input 2282 gl_PerVertex block in these languages. 2283 2284 in gl_PerVertex { 2285 // in addition to other gl_PerVertex members... 2286 vec4 gl_ClipVertex; 2287 vec4 gl_FrontColor; 2288 vec4 gl_BackColor; 2289 vec4 gl_FrontSecondaryColor; 2290 vec4 gl_BackSecondaryColor; 2291 vec4 gl_TexCoord[]; 2292 float gl_FogFragCoord; 2293 } gl_in[]; 2294 2295 The following fragment inputs are also available in a fragment shader when 2296 using the compatibility profile: 2297 2298 in vec4 gl_Color; 2299 in vec4 gl_SecondaryColor; 2300 in vec4 gl_TexCoord[]; 2301 in float gl_FogFragCoord; 2302 2303 The values in gl_Color and gl_SecondaryColor will be derived automatically 2304 by the system from gl_FrontColor, gl_BackColor, gl_FrontSecondaryColor, 2305 and gl_BackSecondaryColor based on which face is visible in the primitive 2306 producing the fragment. If fixed functionality is used for vertex 2307 processing, then gl_FogFragCoord will either be the z-coordinate of the 2308 fragment in eye space, or the interpolation of the fog coordinate, as 2309 described in section 3.11 of the OpenGL Graphics System Specification. The 2310 gl_TexCoord[] values are the interpolated gl_TexCoord[] values from a 2311 vertex shader or the texture coordinates of any fixed pipeline based 2312 vertex functionality. 2313 2314 Indices to the fragment shader gl_TexCoord array are as described above in 2315 the vertex shader text. 2316 2317 2318 Modify Section 7.4, Built-In Constants, p. 74 2319 2320 (add to the list of constants at the bottom of p. 74) 2321 2322 const int gl_MaxTessControlInputComponents = 128; 2323 const int gl_MaxTessControlOutputComponents = 128; 2324 const int gl_MaxTessControlTextureImageUnits = 16; 2325 const int gl_MaxTessControlUniformComponents = 1024; 2326 const int gl_MaxTessControlTotalOutputComponents = 4096; 2327 2328 const int gl_MaxTessEvaluationInputComponents = 128; 2329 const int gl_MaxTessEvaluationOutputComponents = 128; 2330 const int gl_MaxTessEvaluationTextureImageUnits = 16; 2331 const int gl_MaxTessEvaluationUniformComponents = 1024; 2332 2333 const int gl_MaxTessPatchComponents = 120; 2334 2335 const int gl_MaxPatchVertices = 32; 2336 const int gl_MaxTessGenLevel = 64; 2337 2338 (modify the minimum value for one other constant) 2339 2340 const int gl_MaxCombinedTextureImageUnits = 80; 2341 2342 2343 Modify Section 8.7, Texture Lookup Functions, p. 90 2344 2345 (modify first paragraph, accounting for all the new shader types) Texture 2346 lookup functions are available to all shaders. However, automatic level 2347 of detail computations are only performed for fragment shaders; other 2348 shaders operate as though the base level of detail were computed as zero. 2349 The functions in the table below ... 2350 2351 (modify first paragraph, p. 91) In all functions below, the bias parameter 2352 is optional for fragment shaders. The bias parameter is not accepted in 2353 any other shader type. For ... 2354 2355 (Also, make miscellaneous modifications elsewhere in the spec to account 2356 for the fact that vertex and fragment shaders are not the only two 2357 supported shader types.) 2358 2359 2360 Insert a new section after Section 8.10, Geometry Shader Functions, 2361 p. 103. 2362 2363 Section 8.X, Shader Invocation Control Functions 2364 2365 Shader invocation control functions are available only in tessellation 2366 control shaders. These functions are used to control the relative 2367 execution order of the multiple shader invocations used to process a 2368 patch, which are otherwise executed with an undefined relative order. 2369 2370 The function barrier() provides a partially defined order of execution 2371 between shader invocations. This ensures that values written by one 2372 invocation prior to the call to barrier() can be safely read by other 2373 invocations after the call to barrier(). Because invocations may execute 2374 in undefined order between barriers, the values of a per-vertex or 2375 per-patch output variable will be undefined in a number of cases 2376 enumerated in Section 4.3.6. 2377 2378 The barrier() function may only be called inside the main entry point of 2379 the tessellation control shader and may not be called within any control 2380 flow. Barriers are also disallowed after a return statement in function 2381 main(). 2382 2383 Syntax Description 2384 ------------- -------------------------------------------------- 2385 void barrier(void) For any given static instance of barrier(), all 2386 tessellation control shader invocations for a single 2387 input patch must enter it before any will be allowed 2388 to continue beyond it. 2389 2390 Modify Section 9, Shading Language Grammar, p. 105 2391 2392 !!! TBD 2393 2394 2395GLX Protocol 2396 2397 None. 2398 2399 2400Errors 2401 2402 The error INVALID_VALUE is generated by PatchParameteri if <pname> is 2403 PATCH_VERTICES and <value> is less than or equal to zero or is greater 2404 than the implementation-dependent maximum patch size. 2405 2406 The error INVALID_OPERATION is generated by Begin (or vertex array 2407 commands that implicitly call Begin) if the active program contains a 2408 tessellation control or evaluation shader and the primitive mode is not 2409 PATCHES. 2410 2411 The error INVALID_OPERATION is generated by Begin (or vertex array 2412 commands that implicitly call Begin) if the primitive mode is PATCHES if 2413 either: 2414 2415 * the active program contains no tessellation evaluation shader, or 2416 * no program is active. 2417 2418 The error INVALID_OPERATION is generated by GetProgramiv if <pname> 2419 identifies a tessellation control or evaluation shader-specific property 2420 and <program> has not been linked successfully, or does not contain 2421 objects to form a shader whose type corresponds to <pname>. 2422 2423 2424Dependencies on OpenGL 3.2 (Core Profile) 2425 2426 If only the core profile of OpenGL 3.2 is supported, references to 2427 functionality deprecated by OpenGL 3.0 (built-in input/output variables 2428 corresponding to fixed-function vertex attributes, glBegin, fixed-function 2429 vertex processing) should be removed and/or replaced with functionality 2430 supported in the core profile. In such an environment, the PATCHES 2431 primitive type is not supported by the deleted Begin() function but will 2432 still be supported by vertex array draw calls such as DrawArrays() and 2433 DrawElements(). 2434 2435Dependencies on ARB_gpu_shader5 2436 2437 If ARB_gpu_shader5 is not supported, references to the input variable 2438 gl_InvocationID in the geometry shader language should be deleted. This 2439 spec references gl_InvocationID in order to provide a complete set of 2440 language for implementations supporting GLSL 1.50 and both extensions. 2441 2442Dependencies on ARB_gpu_shader_fp64 2443 2444 If ARB_gpu_shader_fp64 is supported, discussion of the maximum number of 2445 input, output, and uniform components supported by the implementation for 2446 tessellation control and evaluation shaders should note each 2447 double-precision floating-point value is counted as two components. 2448 2449Dependencies on NV_gpu_shader5 2450 2451 If NV_gpu_shader5 is supported, discussion of the maximum number of input, 2452 output, and uniform components supported by the implementation for 2453 tessellation control and evaluation shaders should note each 64-bit 2454 integer value is counted as two components. 2455 2456Dependencies on NV_primitive_restart 2457 2458 If primitive restart is enabled, sending a vertex with the restart index 2459 will start a new patch at the beginning. Any vertices specified prior to 2460 the restart index that form a partial patch will be discarded. 2461 2462New State 2463 2464 Add the following state to Table 6.5, Current Values and Associated Data, 2465 p. 343 2466 2467 Default 2468 Get Value Type Get Command Value Description Sec. Attr. 2469 ------------------------ ---- -------------- --------- ------------------------ ------ ------- 2470 PATCH_VERTICES Z+ GetIntegerv 3 Number of vertices in 2.6.1 current 2471 input patch 2472 PATCH_DEFAULT_OUTER_ 4xR GetFloatv 4 x 1.0 Default outer tessellation 2.X.2 - 2473 LEVEL level w/o control shader 2474 PATCH_DEFAULT_INNER_ 2xR GetFloatv 2 x 1.0 Default outer tessellation 2.X.2 - 2475 LEVEL level w/o control shader 2476 2477 Add the following state to Table 6.40, Program Object State, p. 378 2478 2479 Default 2480 Get Value Type Get Command Value Description Sec. Attr. 2481 ------------------------ ---- -------------- --------- ------------------------ ------ ----- 2482 TESS_CONTROL_OUTPUT_ Z+ GetProgramiv 0 Output patch size 2.X.1 - 2483 VERTICES for tess. control shader 2484 TESS_GEN_MODE Z+ GetProgramiv QUADS Base primitive type for 2.X.2 - 2485 tess. prim. generator 2486 TESS_GEN_SPACING Z+ GetProgramiv EQUAL Spacing of tess. prim. 2.X.2 - 2487 generator edge subdivision 2488 TESS_GEN_VERTEX_ORDER Z+ GetProgramiv CCW Order of vertices in 2.X.2 - 2489 primitives generated by 2490 tess. prim generator 2491 TESS_GEN_POINT_MODE Z+ GetProgramiv FALSE Tess prim. generator 2.X.2 - 2492 emits points? 2493 UNIFORM_BLOCK_REF- B GetActive- 0 True if uniform block is 2494 ERENCED_BY_TESS_ UniformBlockiv actively referenced by 2.14.4 - 2495 CONTROL_SHADER tess. control stage 2496 UNIFORM_BLOCK_REF- B GetActive- 0 True if uniform block is 2.14.4 - 2497 ERENCED_BY_TESS_ UniformBlockiv actively referenced by 2498 EVALUTION_SHADER tess evaluation stage 2499 2500New Implementation Dependent State 2501 2502 Minimum 2503 Get Value Type Get Command Value Description Sec. 2504 ------------------------- ---- ----------- ------- -------------------------- ------ 2505 MAX_TESS_GEN_LEVEL Z+ GetIntegerv 64 maximum tessellation level 2.X.2 2506 supported by tessellation 2507 primitive generator 2508 MAX_PATCH_VERTICES Z+ GetIntegerv 32 maximum patch size 2.6.1 2509 MAX_TESS_CONTROL_ Z+ GetIntegerv 1024 number of words for tess. 2.X.1.1 2510 UNIFORM_COMPONENTS control shader uniforms 2511 MAX_TESS_EVALUATION_ Z+ GetIntegerv 1024 number of words for tess. 2.X.3.1 2512 UNIFORM_COMPONENTS evaluation shader uniforms 2513 MAX_TESS_CONTROL_TEXTURE_ Z+ GetIntegerv 16 number of tex. image units 2.14.7 2514 IMAGE_UNITS for tess. control shaders 2515 MAX_TESS_EVALUATION_ Z+ GetIntegerv 16 number of tex. image units 2.14.7 2516 TEXTURE_IMAGE_UNITS for tess. eval. shaders 2517 MAX_TESS_CONTROL_ Z+ GetIntegerv 128 num. components for per- 2.X.1.2 2518 OUTPUT_COMPONENTS vertex outputs in tess. 2519 control shaders 2520 MAX_TESS_PATCH_ Z+ GetIntegerv 120 num. components for per- 2.X.1.2 2521 COMPONENTS patch output varyings 2522 for tess. control shaders 2523 MAX_TESS_CONTROL_TOTAL_ Z+ GetIntegerv 4096 Total num components for 2.X.1.2 2524 OUTPUT_COMPONENTS tess. control shader 2525 outputs 2526 MAX_TESS_EVALUATION_ Z+ GetIntegerv 128 num. components for per- 2.X.3.2 2527 OUTPUT_COMPONENTS vertex outputs in tess. 2528 evaluation shaders 2529 MAX_TESS_CONTROL_ Z+ GetIntegerv 128 num. components for per- 2.X.1.2 2530 INPUT_COMPONENTS vertex inputs in tess. 2531 control shaders 2532 MAX_TESS_EVALUATION_ Z+ GetIntegerv 128 num. components for per- 2.X.3.2 2533 INPUT_COMPONENTS vertex inputs in tess. 2534 evaluation shaders 2535 MAX_TESS_CONTROL_ Z+ GetIntegerv 12 num. of supported uniform 2.14.4 2536 UNIFORM_BLOCKS blocks for tess. control 2537 shaders 2538 MAX_TESS_EVALUATION_ Z+ GetIntegerv 12 num. of supported uniform 2.14.4 2539 UNIFORM_BLOCKS blocks for tess. evaluation 2540 shaders 2541 MAX_COMBINED_TESS_ Z+ GetIntegerv * number of words for tess. 2.X.1.1 2542 CONTROL_UNIFORM_ control uniform variables 2543 COMPONENTS in all uniform blocks 2544 (including default) 2545 MAX_COMBINED_TESS_ Z+ GetIntegerv * number of words for tess. 2.X.3.1 2546 EVALUATION_UNIFORM_ evaluation uniform vari- 2547 COMPONENTS ables in all uniform 2548 blocks (including default) 2549 2550 The minimum values for MAX_COMBINED_*_UNIFORM_COMPONENTS by computing the 2551 value of: 2552 2553 MAX_*_UNIFORM_COMPONENTS + MAX_*_UNIFORM_BLOCKS * (MAX_UNIFORM_BLOCK_SIZE/4) 2554 2555 using the minimum values of the corresponding terms. 2556 2557 Also, increase the minimum for MAX_COMBINED_UNIFORM_BLOCKS to 60 (12 2558 blocks per stage, five stages) and MAX_COMBINED_TEXTURE_IMAGE_UNITS to 80 2559 (16 image units per stage, five stages). 2560 2561 2562Issues 2563 2564 (1) How does tessellation fit into the existing GL pipeline? 2565 2566 RESOLVED: The following diagram illustrates how tessellation shaders 2567 fit into the "vertex processing" portion of the GL (Chapter 2 of the 2568 OpenGL 3.2 Specification). 2569 2570 First, vertex attributes are specified via immediate-mode commands or 2571 through vertex arrays. They can be conventional attributes (e.g., 2572 glVertex, glColor, glTexCoord) or generic (numbered) attributes. 2573 2574 Vertices are then transformed, either using a vertex shader or 2575 fixed-function vertex processing. Fixed-function vertex processing 2576 includes position transformation (modelview and projection matrices), 2577 lighting, texture coordinate generation, and other calculations. The 2578 results of either method are a "transformed vertex", which has a 2579 position (in clip coordinates), front and back colors, texture 2580 coordinates, generic attributes (vertex shader only), and so on. Note 2581 that on many current GL implementations, vertex processing is performed 2582 by executing a "fixed function vertex shader" generated by the driver. 2583 2584 After vertex transformation, vertices are assembled into primitives, 2585 according to the topology (e.g., TRIANGLES, QUAD_STRIP) provided by the 2586 call to glBegin(). Primitives are points, lines, triangles, quads, 2587 polygons, lines or triangles with adjacency, or patches. Many GL 2588 implementations do not directly support quads or polygons, but instead 2589 decompose them into triangles as permitted by the spec. 2590 2591 After initial primitive assembly, patch primitives are processed by the 2592 tessellation control shader, if present. The tessellation control 2593 shader reads the vertices of the incoming patch and generates a new 2594 patch, consisting of a set of vertices and per-patch data. The 2595 tessellation control shader runs with multiple invocations, one per 2596 vertex in the output patch. Each invocation computes the properties of 2597 its own vertex; the invocations collectively compute any per-patch data. 2598 The vertices and per-patch data are then assembled into a new patch 2599 primitive. 2600 2601 If a tessellation evaluation shader is present, the tessellation 2602 primitive generator and the tessellation evaluation shader will convert 2603 an incoming patch into a new set of point, line, or triangle primitives. 2604 The tessellation primitive generator uses the per-patch tessellation 2605 levels and output layout qualifiers to appropriately subdivide a 2606 triangle or quadrilateral into point, line, or triangle primitives. For 2607 each vertex in the subdivided surface, the tessellation evaluation 2608 shader is run to compute its position and other attributes, given a 2609 (u,v) or (u,v,w) location within the subdivided primitive, the vertices 2610 of the patch, and any per-patch data produced by the tessellation 2611 control shader. The results are assembled into primitives for 2612 processing by subsequent stages. 2613 2614 After vertex transformation and tessellation, a geometry shader is 2615 executed on each individual point, line, triangle, or patch primitive, 2616 if one is active. It can read the attributes of each transformed vertex 2617 in the primitive, perform arbitrary computations, and emit new 2618 transformed vertices. These emitted vertices are themselves assembled 2619 into primitives according to the output primitive type of the geometry 2620 shader. 2621 2622 Then, the colors of the vertices of each primitive are clamped to [0,1] 2623 (if color clamping is enabled), and flat shading may be performed by 2624 taking the color from the provoking vertex of the primitive. 2625 2626 Each primitive is clipped to the view volume, and to any enabled 2627 user-defined clip planes. Color, texture coordinate, and other 2628 attribute values are computed for each new vertex introduced by 2629 clipping. 2630 2631 After clipping, the position of each vertex (in clip coordinates) is 2632 converted to normalized device coordinates in the perspective division 2633 (divide by w) step, and to window coordinates in the viewport 2634 transformation step. 2635 2636 At the same time, color values may be converted to normalized 2637 fixed-point values according to the "Final Color Processing" portion of 2638 the specification. 2639 2640 After the vertices of the primitive are transformed to window 2641 coordinate, the GL determines if the primitive is front- or back-facing. 2642 That information is used for two-sided color selection, where a single 2643 set of colors is selected from either the front or back colors 2644 associated with each transformed vertex. 2645 2646 When all this is done, the final transformed position, colors (primary 2647 and secondary), and other attributes are used for rasterization (Chapter 2648 3 in the OpenGL 2.0 Specification). 2649 2650 When the raster position is specified (via glRasterPos), it goes through 2651 the entire vertex processing pipeline as though it were a point. 2652 However, tessellation and geometry shaders are never run on the raster 2653 position. 2654 2655 2656 |generic |conventional 2657 |vertex |vertex 2658 |attributes |attributes 2659 | | 2660 | +-------------------+ 2661 | | | 2662 V V V 2663 vertex fixed-function 2664 shader vertex 2665 | processing 2666 | | 2667 | | 2668 +<-------------------+ 2669 | 2670 |position, color, 2671 |other vertex data 2672 | 2673 V 2674 Begin/ primitive patch tessellation (control point, 2675 End -----> assembly -----------> control parallel patch, 2676 State | shaders final patch) 2677 | | | 2678 | vertices| |per-patch 2679 | | |data 2680 | | | 2681 | | | 2682 V patch V V 2683 +<------------- primitive 2684 | assembly 2685 | 2686 | patch 2687 +-------+-+---------------+ output 2688 | | | |tess layout 2689 | vert-| |per-patch |levels qualifiers 2690 | ices | |data | | 2691 | | | V | 2692 | | | (u,v,w) tessellation | 2693 | | | +------ primitive <--------+ 2694 | | | | generator 2695 | V V V | 2696 | tessellation | 2697 | evaluation |connectivity 2698 | shader | 2699 | | V 2700 | +--------> primitive 2701 | vertex assembly 2702 V | 2703 +<-------------------------+ 2704 | Output 2705 |position, color, Primitive 2706 |other vertex data Type 2707 | | 2708 | geometry primitive | 2709 +----------> shader ------> assembly <-+ 2710 | | 2711 V | 2712 +<------------------------------+ 2713 | 2714 | 2715 | color flat 2716 +----------> clamping -----> shading 2717 | | 2718 V | 2719 +<------------------------------+ 2720 | 2721 clipping 2722 | perspective viewport 2723 +------> divide ----> transform 2724 | | 2725 | +---+-----+ 2726 | V | 2727 | final facing | 2728 +------> color determination | 2729 | processing | | 2730 | | | | 2731 | | | | 2732 | +-----+ +----+ | 2733 | | | | 2734 | V V | 2735 | two-sided | 2736 | coloring | 2737 | | | 2738 | | | 2739 +------------------+ | +-------------+ 2740 | | | 2741 V V V 2742 rasterization 2743 | 2744 | 2745 V 2746 2747 (2) Should we introduce new "patch" primitive types, or should 2748 tessellation be allowed to operate on patches assembled from a point 2749 list or other primitive types? 2750 2751 RESOLVED: Provide new patch primitives. 2752 2753 (3) Unlike other primitive types, patches don't have a definite number of 2754 vertices. How should the number of vertices in a patch be specified? 2755 2756 RESOLVED: Use a piece of "patch parameter" context state specified by 2757 the PatchParameteri entry point to indicate a patch size. 2758 2759 Several other options were considered, including creating a new set of 2760 APIs to draw patches, having the input patch size be a (GLSL) program 2761 parameter, or providing a separate "patch" enum for each supported patch 2762 size (e.g., "PATCH16" for a 16-vertex patch). The new API was rejected 2763 because the new calls may need to interact with a wide variety of vertex 2764 APIs (e.g., multi-draw array calls, instancing, ranged element arrays); 2765 a patch size parameter is orthogonal to all of these. Having a fixed 2766 input patch size in a GLSL program may be fine in some cases. We expect 2767 that some tessellation control shaders may want handle input patches 2768 with a variable number of extraordinary vertices, which would be 2769 incompatible with a fixed patch size in the program. Handling many 2770 different "patch" enums in a frequently invoked draw calls didn't seem 2771 to make sense, either. 2772 2773 (4) Should we support "overlap" of patches -- strips where some points in 2774 one patch are reused in neighboring ones? If so, how should the 2775 overlap be specified? Using a separate GL call? Using a parameter in 2776 the program specifying a strip? Using an overlap parameter that says 2777 how many vertices from one patch are carried over to the next one? 2778 Something else? 2779 2780 RESOLVED: We will not support patch strips in this extension. Regular 2781 strips of patches can be drawn efficiently using DrawElements and an 2782 index buffer. 2783 2784 (5) May patches be specified in immediate mode, and if so, how? 2785 2786 RESOLVED: Yes; this support falls out of the API definition. Immediate 2787 mode may be useful in the compatibility profile to allow Begin/End-based 2788 applications to use tessellation without changing the way they specify 2789 vertices. 2790 2791 For the core profile, immediate mode is not supported for any primitive 2792 type, including patches. 2793 2794 (6) How are the vertices of patch primitives interpreted when compiled 2795 into display lists (compatibility profile)? 2796 2797 RESOLVED: During compilation, the vertices are simply stored into the 2798 display list as-is. During execution, they are interpreted according to 2799 the current patch size values specified by PatchParameteri. To 2800 interpret patches according to values determined at display list compile 2801 time, compile PatchParameteri calls to set the size and stride into the 2802 display list. 2803 2804 One downside of this choice is that making the interpretation of patch 2805 vertices dependent on run-time state means that the display list 2806 compiler may not be able to determine the number of vertices in a patch 2807 primitive, and would be unable to perform any operations that require 2808 knowing the patch structure. 2809 2810 (7) What should these shaders be called? 2811 2812 RESOLVED: The shader that converts an input patch to an output patch is 2813 called a "tessellation control shader" (TCS). The use of "control" has 2814 several connotations -- the vertices of the input and output patches are 2815 often called "control points" and the tessellation levels computed are 2816 used to control the tessellation primitive generator. The shader that 2817 takes the (u,v,w) or (u,v) points generated by the tessellation 2818 primitive generator are called tessellation evaluation shaders (TES), as 2819 they evaluate the position and other attributes of all the vertices of 2820 the tessellated primitive. 2821 2822 Other options considered for TCS include "patch shaders" or "primitive 2823 shaders". These choices seemed too general; the existing geometry 2824 shaders are arguably already primitive shaders. The term "tessellation 2825 shader" was also considered for TES, but that choice also seemed too 2826 general -- TCS is strongly related to tessellation as well. 2827 2828 Other APIs may refer to the tessellation control and evaluation shaders 2829 as "hull shaders" and "domain shaders", respectively. 2830 2831 (8) Should coupling of tessellation control and evaluation shaders be 2832 required? 2833 2834 RESOLVED: No. A tessellation control shader without an evaluation 2835 shader might be used in conjunction with transform feedback to generate 2836 regular transformed patches. Also, if the set of patches provided by 2837 the application is already in a form usable by the tessellator, the 2838 tessellation control shader may be bypassed. In this use case, the 2839 application would be required to provide default tessellation levels via 2840 the PatchParameterfv API, since no shader would be available to compute 2841 them. 2842 2843 It may be useful to have a patch produced by a tessellation control 2844 shader to be fed directly to a geometry shader that performs some 2845 operation on full patches, rather than individual triangles of a 2846 tessellated patch. However, such capability is not provided in this 2847 extension. 2848 2849 (9) What measures are provided to ensure crack-free tessellation, where 2850 the results of tessellating multiple adjacent meshes produce the same 2851 vertices along the edges? 2852 2853 RESOLVED: The most likely cause of cracking is due to shared patch 2854 edges being subdivided differently. In order to get consistent 2855 tessellation along shared edges, the tessellation control shaders (or 2856 default levels) must be constructed so that outer tessellation level 2857 corresponding to the shared edge must be exactly the same in both 2858 patches. 2859 2860 Hardware implementations should guarantee that the same set of vertices 2861 is produced when subdividing a shared patch edge where the corresponding 2862 outer tessellation level matches. Hardware implementations of this 2863 extension should also guarantee that the (u,v,w) parameters generated 2864 are complementary. Walking along a shared patch edge may take you from 2865 a u/v/w coordinate of 0.0 to 1.0 in one patch, and from 1.0 to 0.0. In 2866 this case, the u/v/w coordinates generated for any given vertex along 2867 this edge should sum to *exactly* 1.0. 2868 2869 Even with proper hardware support, tessellation evaluation shaders need 2870 to be crafted carefully to avoid arithmetic errors caused by the order 2871 of operations. For example, errors in floating-point math mean that 2872 it's not always the case that: 2873 2874 ((A + B) + C) + D = A + (B + (C + D)) 2875 2876 An evaluation shader walking a shared edge in opposite directions 2877 could easily run into errors such as this. 2878 2879 The "precise" qualifier provided by the ARB_gpu_shader5 extension can be 2880 used to reduce the risk of cracking due to compiler optimizations. 2881 2882 The full details of how to guarantee crack-free tessellation are beyond 2883 the scope of this specification. 2884 2885 (10) Should we provide special built-ins or other mechanisms to assist in 2886 crack-free tessellation or other common tessellation shader usages? 2887 If so, what should be provided? 2888 2889 RESOLVED: Options considered include: 2890 2891 * a test if a vertex is at the edge of a patch (for some common patch 2892 topologies); 2893 2894 * a special directive to ensure that certain math operations requiring 2895 precise results are not adversely affected by compiler optimizations 2896 (e.g, reordering of operations, using asymmetric floating-point 2897 multiply-add operations); 2898 2899 * special "lerp" intrinsics to ensure exact results for 2900 "complementary" weights; and 2901 2902 * special built-ins for commonly used attribute evaluations (e.g., 2903 linear, bicubic, and other polynomial evaluations) 2904 2905 This extension doesn't provide any such mechanisms; however, the 2906 "precise" qualifier in ARB_gpu_shader5 addresses the second issue. 2907 2908 (11) Should we provide specific invariance guarantees to ensure crack-free 2909 tessellation? If so, what would they be? 2910 2911 RESOLVED: Formulating guarantees of this sort is difficult. The 2912 "precise" qualifier can be used to guarantee that expressions are 2913 evaluated in the manner specified in the shader code. 2914 2915 (12) In what domain should position parameters for tessellation shaders be 2916 provided? 2917 2918 RESOLVED: We will provide tessellation coordinates in a standard [0,1] 2919 parameterization. Two-dimensional (u,v) coordinates with components in 2920 [0,1] is a standard parameterization; for example, it is what is used 2921 for OpenGL evaluators. 2922 2923 A [-1,+1] parameterization has some advantages; in particular, the 2924 equivalent of "1-u" in this scheme is simply "-u". Floating-point 2925 calculations involving these terms would result in values of identical 2926 magnitude, but opposite sign. This advantage is not particularly 2927 important if the [0,1] parameterization is computed in a way that 2928 ensures that u+(1-u) == 1.0, with no floating-point rounding error. 2929 2930 Three-dimensional barycentric coordinates are provided for triangular 2931 patches, where each coordinate is a linear weight for one of the corners 2932 of the subdivided primitive. Four-dimensional barycentric coordinates 2933 may be useful quad patches, but can be computed easily enough by a 2934 tessellation evaluation shader if required. 2935 2936 (13) What type of patches are supported by the tessellation primitive 2937 generator? 2938 2939 RESOLVED: The primitive generator will subdivide triangular and 2940 rectangular patches into triangles, and will also subdivide a 2941 rectangular patch into line strips (called "isolines"). Triangular and 2942 rectangular patches are useful for direct rendering of higher-order 2943 surfaces; isolines are useful for a number of things, including 2944 realistic hair rendering. 2945 2946 Note that the notion of a patch in the tessellation API is simply an 2947 ordered collection of vertices of a fixed size. There is no requirement 2948 that the vertices of the patch be arranged in a triangular or 2949 rectangular pattern at all. Even for "normal" patches, there is no 2950 required vertex ordering. Applications should be careful that the 2951 vertices of the patches they provide are ordered in the manner expected 2952 by the tessellation shaders they use. 2953 2954 (14) Should the tessellation control and evaluation shaders be provided in 2955 a single compliation unit, or in multiple units? 2956 2957 RESOLVED: Separate units. While tessellation control and evaluation 2958 shaders might often be tightly coupled, they can exist separately. With 2959 the current GLSL program object API, all shader types are linked 2960 together into a single "program" unit, regardless. A future API may 2961 allow decoupled shaders, in which case the tessellation control and 2962 evaluation shaders may want to be packaged separately. 2963 2964 (15) Should the tessellation control shader be provided in a single 2965 compilation unit with a single entry point, a single compilation unit 2966 with multiple entry points, or in multiple compilation units? 2967 2968 RESOLVED: The extension packages the tessellation control shader into a 2969 single entry point that is run once per output vertex. The barrier() 2970 function is provided to divide the tessellation control shader into 2971 execution phases that allow the separate threads to communicate via 2972 shared output variables. 2973 2974 We considered an approach that explicitly packages the different phases 2975 of execution into separate functions. Such a shader might have a 2976 "control point entrypoint" run independently in parallel and would be 2977 responsible for computing per-vertex attributes for each control point 2978 of the output patch. The shader might also have one or more "patch 2979 entrypoints" run independently that would be responsible for per-patch 2980 attributes. Restrictions on the capabilities might also be provided to 2981 limit the communication between threads and entrypoints to specific 2982 well-defined points. For example, the control point entrypoint might be 2983 allowed to write per-vertex outputs, but could be forbidden to read 2984 outputs written by other threads. Patch entrypoints could be guaranteed 2985 to run after control point entrypoints, forbidden from writing 2986 per-vertex outputs, and restricted to reading and writing disjoint 2987 per-patch outputs. Because shader outputs are defined at global scope 2988 in GLSL, enforcing such restrictions in a single shader executable would 2989 be difficult. For example, the compiler might be required to forbid 2990 calls to utility functions reading/writing global outputs in a specific 2991 manner. Such a restriction might need to apply to a lengthy call chain 2992 (i.e., an entrypoint calls function A, which calls function B, which 2993 calls function C, which performs specific operations on an output). 2994 2995 We also considered an approach with completely separate shader types in 2996 separate compilation units. For example, we might provide separate 2997 "tessellation control point shaders" and one or more types of 2998 "tessellation control patch shaders". The linker would build a single 2999 tessellation control executable from one or more of these shaders. The 3000 languages for these different shader types could be constrained to 3001 enforce restrictions. For example, tessellation control point shaders 3002 could be forbidden from declaring per-patch outputs, and per-vertex 3003 outputs would be non-arrays to prevent threads from reading the outputs 3004 of other control point shaders. Per-vertex attributes of the output 3005 patch could be declared as inputs to the tessellation control patch 3006 shaders to forbid writes. 3007 3008 Another option considered provided a single shader entry point called 3009 once per patch and have an optimizing compiler extract the same sort of 3010 parallel execution units provided by the explicitly parallel shader 3011 model. However, we didn't want to depend on "compiler magic" to get 3012 acceptable performance. 3013 3014 (17) Tessellation control shaders have a shared output patch, where 3015 individual threads can read and write these shared outputs. Should 3016 we do anything to prevent multiple theads from reading and writing 3017 the same output? If not, what should happen if they do? 3018 3019 RESOLVED: We are currently enforcing no compile-time restrictions on 3020 these cases. The built-in function barrier() can be used by the shader 3021 writer to segregate shader execution into phases. No problems should 3022 arise as long as no two threads access the same shared output in the 3023 same phase. Reading outputs written by other threads would not be a 3024 problem as long as the output was written in a previous phase. 3025 3026 The relative execution order of the shader threads within a single phase 3027 is undefined; a single phase may be run fully in parallel or fully 3028 serially. If multiple threads write different values to the same output 3029 in the same phase, the thread that "wins" is undefined -- and for 3030 vectors, different components may have a different "winning thread". If 3031 one thread reads an output written by another thread in the same phase, 3032 the newly written value may or may not be available at the time the read 3033 is executed. 3034 3035 In some of the alternate programming models considered in the discussion 3036 of the previous issue, it might be possible for the compiler to avoid 3037 read/write and write/write hazards. For example, the compiler might 3038 allow an output variable to be written by only a single entrypoint, and 3039 could allow only those entrypoints logically "after" the entry point to 3040 read it. Such enforcement would prevent undefined behavior, but would 3041 have some drawbacks of its own. In particular, it doesn't solve the 3042 problem of multiple threads computing a single per-patch attribute. One 3043 very natural use would be to use a patch entrypoint to compute the four 3044 outer tessellation levels in parallel. If all threads only write to 3045 gl_TessLevelOuter[gl_InvocationID], there are no hazards. However, 3046 detecting and preventing hazards are problematic if more complicated 3047 array indexing is used. Also, there would be a problem if a parallel 3048 shader was structured in such a way that one output might be written by 3049 exactly one thread, but it wasn't obvious to the compiler which thread 3050 actually would write it. 3051 3052 (19) How should we name the parameters that control the degree of 3053 tessellation along edges of a given patch and the (u,v) or (u,v,w) 3054 parameter driving the tessellation shader evaluation? 3055 3056 RESOLVED: The parameters controlling subdivision are called 3057 "tessellation levels". The ones controlling subdivision of the outer 3058 edges of the patch are called "outer tessellation levels"; the ones 3059 controlling the interior are called "inner tessellation levels". The 3060 built-in variables are called "gl_TessLevelOuter[]" and 3061 "gl_TessLevelInner[]". Both are declared as arrays of floating-point 3062 scalars, rather than vectors, so they can be accessed with indexing. 3063 The (u,v) or (u,v,w) coordinate used by the tessellation evaluation 3064 shader is referred to as the "tessellation coordinate", giving the 3065 relative coordinates of the vertex in the primitive being tessellated. 3066 The built-in input variable holding this value is called "gl_TessCoord". 3067 3068 (20) How would applications handle attributes that may want to be sampled 3069 with different frequency? For example, OpenGL evaluators can specify 3070 evaluator maps of different order for different attributes? For 3071 example, evaluating (u,v) with a cubic 2D map (order == 4) requires 3072 16 control points, while a linear map (order == 2) only requires 4. 3073 3074 RESOLVED: Tessellation evaluation shaders can read from any vertex or 3075 per-patch attribute, so they can read whatever the tessellation control 3076 shader throws at them. Tessellation control shaders may choose to 3077 compute attributes sampled at a different frequency than per-control 3078 point in one of several ways: 3079 3080 * Compute and output the attribute in only a subset of the 3081 tessellation control shader threads; for example, only compute the 3082 "linear" attributes in threads 0-3. 3083 3084 * Encode the attribute across multiple control points. For example, 3085 four vec4 values could be passed out as a float for each vertex if 3086 16 control point shader threads were used. Doing this may be tricky 3087 in some cases. 3088 3089 * Compute the "linear" attributes as four-element per-patch outputs. 3090 If using this technique, it would be desirable to compute these 3091 independently in the tessellation control shader, if possible. 3092 3093 (21) To what level should we enforce that different shader types in a 3094 program match exactly, and to what level does the current program 3095 need to match the topology enums (e.g., GL_POINTS) provided by the 3096 application? 3097 3098 RESOLVED: If the tessellator is being used, we will require a patch 3099 primitive as input and throw an INVALID_OPERATION error if any other 3100 primitive type is provided. This is consistent with geometry shaders 3101 requiring primitives consistent with their input topology. 3102 3103 If no tessellation evaluation shader is present, a patch primitive would 3104 need to be passed through to the geometry shader, or potentially 3105 transform feedback and rasterization. That capability will not be 3106 provided by this extension, but may be provided in the future or in a 3107 vendor-specific extension. 3108 3109 (22) If we have a notion of a "patch" as a random (though possibly 3110 fixed-size) blob of vertices, should we extend this concept to 3111 encompass geometry shaders as well? 3112 3113 RESOLVED: No, we will not allow geometry shaders to receive patches in 3114 this extension. That limitation may be relaxed in a future extension. 3115 3116 Such a mechanism would allow patches to be used by geometry shaders in 3117 settings other than tessellation. For example, QUADS primitives are 3118 subdivided into two triangles when passed to geometry shaders. However, 3119 this mechanism allows applications to pass 4-vertex PATCHES primitives 3120 to geometry shaders, which can treat the four vertices as a quad. Note 3121 also that the only way one could get patches to geometry shaders is if 3122 no tessellation evaluation shader is present, because the tessellation 3123 primitive generator will consume an input patch. 3124 3125 (23) Should we support a programming model where the tessellation control 3126 shader can be written serially rather than explicitly requiring 3127 parallel execution? 3128 3129 RESOLVED: Not in this extension. The parallel programming model allows 3130 for improved efficiency. While an optimizing compiler could refactor 3131 the code to execute in parallel, depending on this refactoring would run 3132 the risk of major performance pitfalls. 3133 3134 (24) Should the use of tessellation shaders be allowed with fixed-function 3135 vertex processing, or should we require the use of a vertex shader? 3136 3137 RESOLVED: When using tessellation control or evaluation shaders, 3138 programmable vertex shaders will be required. This follows the 3139 precedent established by EXT_geometry_shader4 that requires that if you 3140 use a programmable shader for any stage prior to rasterization, you 3141 can't mix that with fixed-function vertex processing. 3142 3143 (25) Should we support variable-size input patches in the tessellation 3144 control or evaluation shaders? If so, how can one get at the number 3145 of vertices in the input patch? 3146 3147 RESOLVED: Yes, variable-size input patches are supported, though the 3148 input size can not be changed within a single draw call or Begin/End 3149 pair. The vertex count for a specific input patch can be obtained in a 3150 shader using the input variable "gl_PatchVerticesIn". Additionally, the 3151 maximum patch size supported by the implementation, used for sizing 3152 unsigned per-vertex input arrays, is given by the constant 3153 "gl_MaxPatchVertices". 3154 3155 The EXT_geometry_shader4 provided a constant "gl_VerticesIn" 3156 corresponding to the fixed input primitive size set by the input 3157 primitive type. This variable was dropped when geometry shaders were 3158 included in GLSL 1.50 because the value of this constant couldn't be 3159 known at CompileShader() time. Using GLSL 1.50, a shader could extract 3160 the same value using "gl_in.length()" as long as the input primitive 3161 type was declared prior to the use of "length()". 3162 3163 This spec initially repurposed "gl_VerticesIn" for tessellation shaders 3164 to refer to the input "gl_PatchVerticesIn", but having a variable that 3165 was a constant in some shaders/#extension configurations and an input in 3166 others was confusing. 3167 3168 (26) Must per-vertex input variables be declared as arrays indexed by 3169 vertex number? What syntax should be used in the declaration? 3170 3171 RESOLVED: Yes, they must be declared as arrays or members of blocks 3172 declared as arrays. We strongly recommend that shaders simply omit the 3173 vertex size; a default size will be injected automatically by the 3174 compiler. For example, if each input patch vertex a vec3 named position 3175 an array of four vec2 values called "texcoords" and the implementation's 3176 maximum patch size is 32, any of the following declarations are legal. 3177 3178 in vec3 position[]; 3179 in vec3 position[gl_MaxPatchVertices]; 3180 in vec3 position[32]; 3181 in TexCoords { 3182 vec2 coords[4]; 3183 } tex[]; 3184 in TexCoords { 3185 vec2 coords[4]; 3186 } tex[gl_MaxPatchVertices]; 3187 in TexCoords { 3188 vec2 coords[4]; 3189 } tex[32]; 3190 3191 Shaders using the "32" form won't be portable; they will break when run 3192 on any implementation that has a different patch size limit. Shaders 3193 using "gl_MaxPatchVertices" will be portable, but there's no point in 3194 specifying a vertex count. Just say no. 3195 3196 (27) Can tessellation shaders be run on primitives such as triangles or 3197 triangle strips? 3198 3199 RESOLVED: Not directly. However, if an application is drawing 3200 independent triangles using DrawElements, it can pass the same set of 3201 indices using PATCHES and a patch size of 3 vertices and use the 3202 tessellator normally. 3203 3204 (29) How does tessellation interact with PolygonMode? Edge flags? 3205 3206 RESOLVED: When the tessellation primitive generator decomposes a patch 3207 and emits triangles, each triangle will be drawn with all edge flags set 3208 to TRUE (as with regular TRIANGLE_STRIP primitives). If the polygon 3209 mode is not FILL, each triangle will be drawn using points or lines, as 3210 with any other primitive. PolygonMode and edge flags have no effect on 3211 point or line primitives, and will thus have no effect if a patch is 3212 used to generate points or isolines, or if the patch makes it to the 3213 rasterizer. 3214 3215 (30) Are any of the clamped/filtered gl_TessLevel values computed by the 3216 tessellation primitive generator available to tessellation evaluation 3217 shaders? 3218 3219 RESOLVED: No, the only tessellation levels directly available to the 3220 tessellation evaluation shaders will be the raw values written by the 3221 tessellation control shaders or taken from default tessellation 3222 levels. 3223 3224 If a tessellation evaluation shader requires clamped or rounded levels, 3225 it can perform the clamping itself. Alternately, the clamped levels can 3226 be computed in the tessellation control patch shaders and passed to the 3227 evaluation shader using a per-patch output declared as "patch out". 3228 3229 (31) Should any of the patch parameters or the maximum input patch size 3230 parameter have a "TESS_" prefix? 3231 3232 RESOLVED: No. These are properties of patches, not any tessellation 3233 units. While patches may be commonly used for tessellation, they might 3234 also be used in the future by geometry shaders or transform feedback 3235 with no tessellation shaders present. 3236 3237 (32) How are primitives generated by the tessellator wound in (u,v) space? 3238 Can we wind in either direction, or is only one way supported? At 3239 the very least, we should guarantee that the winding is internally 3240 consistent. 3241 3242 RESOLVED: We will support both clockwise and counter-clockwise winding 3243 in the normalized (u,v) space, where the winding can be specified using 3244 a layout qualifier. Note that the final position of the vertices are 3245 computed in the tessellation evaluation shader, and a triangle that is 3246 counter-clockwise in (u,v) space may end up clockwise in screen space. 3247 3248 (35) Tessellation evaluation shaders have a fixed input patch size if a 3249 tessellation control shader is present, but a variable input patch 3250 size otherwise. Is that a problem? 3251 3252 RESOLVED: No, we don't think so. 3253 3254 (36) How do patches interact with primitive restart indices? 3255 3256 RESOLVED: Primitive restart terminates the existing patch and start a 3257 new one, just like any other primitive. Since we only support 3258 independent patch primitives, primtive restart with patches is every bit 3259 as pointless as it is with independent point, line, triangle, and quad 3260 primitives. 3261 3262 (37) Should the default tessellation levels be used automatically if they 3263 are not written by the tessellation control shader? 3264 3265 RESOLVED: No. If you don't write tessellation levels in a tessellation 3266 control patch shader, they will be undefined. If an application really 3267 want a "default" tessellation level in conjunction with the tessellation 3268 control shader, it can simply copy one from a uniform. 3269 3270 (40) How does tessellation interact with rasterization features such as 3271 flat shading and stippled lines? How are the vertices produced by 3272 the tessellator presented to the geometry shader, if one is present? 3273 3274 RESOLVED: For quad and triangle tessellation, a set of independent 3275 triangles is generated by the tessellation primitive generator. For 3276 isoline tessellation, a set of independent lines is generated. In both 3277 cases, the order in which the triangles or lines are drawn is undefined. 3278 Additionally, the order of vertices in the triangles or lines are also 3279 undefined. The only thing that is defined is that when triangles are 3280 generated, their winding will be consistent with the "cw" or "ccw" 3281 layout qualifer. 3282 3283 As a result, using flat shading and line stipple with tessellation 3284 shaders may not produce regular results given that the first vertex 3285 (resetting stipple) and last vertex (provoking vertex for flat shading) 3286 of each primitive are undefined. Additionally, the order of vertices 3287 presented to a geometry shader will not be predictable. All of these 3288 features will work with tessellation; they just won't produce results 3289 that are as regular as what you'd get decomposing a patch into a set of 3290 triangle strips. 3291 3292 Note that for the isoline tessellation, while the line segments appear 3293 to be arranged in strips, they are rendered as independent segments and 3294 have their stipple reset at the beginning of each segment. 3295 3296 (41) Tessellation control shaders declare per-vertex outputs as arrays or 3297 members of block arrays indexed by vertex number. However, we only 3298 allow each thread to write per-vertex outputs for its own vertex. 3299 How should we impose this restriction? 3300 3301 RESOLVED: The current specification requires that the value of the 3302 expression used as a vertex input must be the identifier 3303 "gl_InvocationID". This does mean that even trivially equivalent 3304 expressions such as "(gl_InvocationID)" or "glInvocationID + 0" should 3305 not be accepted by the compiler. 3306 3307 We considered allowing compilers to accept equivalent expressions like 3308 "(gl_InvocationID)", "(gl_InvocationID + 0)", or a temporary variable 3309 assigned the value of "gl_InvocationID". We also considered allowing 3310 any expression, with undefined behavior if the value of the index 3311 turned out to not be equal to "gl_InvocationID". We chose to have a 3312 stronger restriction to avoid undefined behavior and errors that 3313 depending on specific compiler behavior. 3314 3315 Applications not wishing to use the string "gl_InvocationID" can use 3316 the #define preprocessor feature to define an alternate name. 3317 3318 (42) What restrictions should apply to the barrier() built-in? 3319 3320 RESOLVED: Given that the barrier() function must be reached by all 3321 threads before any thread continues, it would be possible for shader 3322 thread groups to hang if any thread in the group never reaches the 3323 barrier because of conditional flow control. 3324 3325 We would prefer not to provide a mechanism allowing improperly-coded 3326 shaders to hang, so it would be necessary to rely on compiler analysis 3327 to prevent the use of barrier() in places where it isn't safe, which 3328 would include: 3329 3330 * calls within "if" or "else" substatements of an if statement, 3331 3332 * calls within "do", "for", or "while" loops if the number of loop 3333 iterations is not known to be uniform, or if any thread may execute 3334 a "continue" or "break" statement, 3335 3336 * calls within functions called directly or indirectly by main() in 3337 cases any call in the chain is in conditional code, and 3338 3339 * calls within the main() entrypoint issued after one or more threads 3340 have executed a "return" statement. 3341 3342 Relying on such analysis on fully general shader code may be fragile and 3343 difficult to replicate uniformly across all compiler implementations. 3344 As a result, we choose a heavy-handed approach in which we only allow 3345 calls to barrier() inside main(). Even within main, barrier() calls are 3346 forbidden inside loops (even those that turn out to have constant loop 3347 counts and don't execute "break" or "continue" statements), if 3348 statements, or after a return statement. 3349 3350 (43) Why provide a limit on the maximum number of components (both 3351 per-vertex and per-patch) emitted by a tessellation control shader, 3352 i.e. MAX_TESS_CONTROL_TOTAL_OUTPUT_COMPONENTS? 3353 3354 RESOLVED: We expect that some implementations of this extension might 3355 have a fixed limit on output buffering that may not not allow the 3356 combined use of a maximum number of per-patch and per-vertex attributes. 3357 3358 (44) What is the meaning of a "vertex shader" inside a pipeline with 3359 tessellation enabled? 3360 3361 RESOLVED: There are two different types of "vertex" when tessellation 3362 is involved. We have the vertices of the input patch, and we have the 3363 vertices generated by the tessellation primitive generator. If one 3364 considers "vertices" to be points used to control rasterized primitives, 3365 the former may be more reasonably considered "control points", since 3366 they typically won't be used as-in in primitives sent to the rasterizer. 3367 Additionally, operations typically performed in a vertex shader 3368 (lighting, texture coordinate generation) may instead be performed by a 3369 after evaluating the position and normal in the tessellation evaluation 3370 shader. In such a world view, one might rename the pipeline stage 3371 typically called "vertex shader" when tessellation is disabled to be a 3372 "control point shader" stage. A logically separate pipeline stage with 3373 a lot in common with existing vertex shaders would be run after the 3374 tessellation evaluation shader. 3375 3376 This extension chooses not to adopt the above approach, however. While 3377 a post-tessellation vertex shader may have a lot in common with the 3378 vertex shader used without tessellation, it's not likely that the shader 3379 code used in these two cases will be completely identical. In 3380 particular, the vertex positions and normals computed by the 3381 tessellation coordinate shader will likely be in a different coordinate 3382 system than the "object space" positions and normals used for vanilla 3383 vertex shaders. The linkage between the two types of vertex shader and 3384 the previous stage are also very different -- post-tessellation vertex 3385 shaders would get their inputs from the outputs of the tessellation 3386 evaluation shader; "normal" vertex shaders get their inputs from vertex 3387 attribute arrays specified with the OpenGL API. Additionally, allowing 3388 a vertex shader to live at the beginning or middle of the pipeline would 3389 have problems if/when OpenGL releases the monolithic single program 3390 model in the current GLSL API. In such an API, it would be necessary to 3391 generate code for a vertex shader without knowledge of whether it would 3392 be run with or without tessellation. 3393 3394 In the model we do expose, developers need to keep in mind that with 3395 tessellation: 3396 3397 * vertex shaders are run on control points, not post-tessellation 3398 vertices, and 3399 3400 * many of the vertex processing operations typically performed by the 3401 vertex shader will be performed by the tessellation evaluation 3402 shader. 3403 3404 It may be possible to share some or all portions of existing vertex 3405 shader code verbatim with the tessellation evaluation shaders via clever 3406 use of #ifdefs or multiple shader objects. Additionally, higher-level 3407 shader or effects libraries may be able to expose a different pipeline 3408 configuration as long as they generate code and shader/program objects 3409 that fit the existing pipeline. 3410 3411 (45) Should we provide the ability for the implementation to automatically 3412 generate a "pass-through" vertex shader, effectively making vertex 3413 shaders optional when tessellating. In some tessellation algorithms, 3414 the bulk of the work will be done in the tessellation control and 3415 evaluation shaders, and the vertex shader will have little or no 3416 interesting work to do. 3417 3418 RESOLVED: Not in this extension. This functionality might be useful, 3419 but making such a change would have significant impact. First, there 3420 would be quite a bit of text to rewrite regarding vertex attributes, all 3421 of which is now in the "vertex shader" section but might want to be done 3422 more neutrally. Additionally, the input variables for 3423 tessellation/geometry shaders would presumably now receive vertex 3424 attributes. However, TCS/TES/GS can have inputs that are not supported 3425 as equivalent vertex shader inputs. In particular, structures are 3426 allowed as inputs in TCS/TES/GS, but not in VS. This probably has 3427 further impact on the vertex attribute language. We chose to leave out 3428 this functionality for simplicity. 3429 3430 (46) Should we reserve "patch" as a keyword for per-patch input 3431 qualifiers, or use something more obscure, such as "per_patch"? 3432 Whatever keyword we choose, should it be reserved in all languages or 3433 just tessellation control and evaluation? 3434 3435 RESOLVED: This extension uses "patch". 3436 3437 (47) Should we allow tessellation control or evaluation inputs and outputs 3438 to be declared as "centroid in" or "centroid out", or with 3439 interpolation modifiers, even if those variables aren't being 3440 interpolated? 3441 3442 RESOLVED: Yes. This allows for mix-and-match linkage where you can 3443 feed an output from a single vertex shader to a fragment shader in one 3444 program and a tessellation/geometry shader in another. The shading 3445 language requires that variables on each interface match in type and 3446 qualification. Therefore, if a fragment shader input is declared as 3447 "centroid in", the vertex shader output must be declared similarly. 3448 When used on inputs in tessellation control, tessellation evaluation, 3449 and geometry shaders, "centroid" and any other interpolation modifiers 3450 have no effect. 3451 3452 (48) Should we provide a tessellation spacing mode where the tessellation 3453 levels are snapped to powers of two? 3454 3455 RESOLVED: No. Such a mode would be useful to avoid motion of generated 3456 vertices as the tessellation levels change. When using a power of two, 3457 an increasing tessellation level snaps from 2 to 4 to 8 to 16. In each 3458 transition, the <n> existing points generated by the tessellator on each 3459 edge don't move -- new vertices are introduced at the midpoint of each 3460 old edge in the subdivision. 3461 3462 Applications can implement this behavior themselves by manually snapping 3463 the levels of detail they compute in the tessellation control shader. 3464 3465 (49) Should we make clockwise/counter-clockwise winding of tessellation 3466 output program state or context state? 3467 3468 RESOLVED: Program state, for simplicity. Making it program state means 3469 that if an application wants to use the same tessellation evaluation 3470 shader with different winding orders, it would need to generate two 3471 separate programs/tessellation evaluation shaders. This doesn't seem to 3472 be a significant enough usage case to justify the overhead of having to 3473 program a separate piece of tessellation state. 3474 3475 Note that applications that want to use the same program with different 3476 windings can work around this limitation by toggling the FrontFace API 3477 state as required. Counter-clockwise primitives with FrontFace set to 3478 CCW will generally be indistinguishable from clockwise primitives with 3479 FrontFace set to CW. The only limitation of this approach is that it 3480 doesn't affect the winding of primitives captured by transform feedback. 3481 3482 (50) Tessellation using "point_mode" is supposed to emit each distinct 3483 vertex produced by the tessellation primitive generator exactly once. 3484 Are there cases where this can produce multiple vertices with the same 3485 position? 3486 3487 RESOLVED: Yes. If fractional odd spacing is used, we have outer 3488 tessellation levels that are greater than 1.0, and inner tessellation 3489 levels less than or equal to 1.0, this can occur. If any outer level is 3490 greater than 1.0, we will subdivide the outer edges of the patch, and 3491 will need a subdivided patch interior to connect to. We handle this by 3492 treating inner levels less than or equal to 1.0 as though they were 3493 slightly greater than 1.0 ("1+epsilon"). 3494 3495 With fractional odd spacing, inner levels between 1.0 and 3.0 will 3496 produce a three-segment subdivision, with one full-size interior segment 3497 and two smaller ones on the outside. The following figure illustrates 3498 what happens to quad tessellation if the horizontal inner LOD (IL0) goes 3499 from 3.0 toward 1.0 in fractional odd mode: 3500 3501 IL0==3 IL0==2 IL0=1.5 IL0=1.2 3502 +-----------+ +-----------+ +-----------+ +-----------+ 3503 | | | | | | | | 3504 | +---+ | | +-----+ | | +-------+ | |+---------+| 3505 | | | | | | | | | | | | || || 3506 | | | | | | | | | | | | || || 3507 | +---+ | | +-----+ | | +-------+ | |+---------+| 3508 | | | | | | | | 3509 +-----------+ +-----------+ +-----------+ +-----------+ 3510 3511 As the inner level approaches 1.0, the vertical inner edges in this 3512 example get closer and closer to the outer edge. The distance between 3513 the inner and outer vertical edges approaches zero for an inner level of 3514 1+epsilon, and the positions of vertices produced by subdividing such 3515 edges may be numerically indistinguishable. 3516 3517Revision History 3518 3519 Rev. Date Author Changes 3520 ---- -------- --------- ----------------------------------------- 3521 23 09/17/19 Jon Leech Fix typo in quad tessellation language 3522 (internal API issue 113). 3523 22 04/21/15 Jon Leech Allow user-defined TCS input and output, 3524 and TES input variable array size mismatches 3525 to be detected at compile as well as link time 3526 (Bug 12185). 3527 3528 21 04/20/15 Jon Leech Remove "per-patch" part of description of 3529 MAX_TESS_CONTROL_TOTAL_OUTPUT_COMPONENTS 3530 (Bug 13765). 3531 3532 20 04/25/14 pbrown Clarify that the tessellation primitive 3533 generator may produce multiple vertices with 3534 the same gl_TessCoord values in point mode when 3535 fractional odd spacing is used with an inner 3536 tessellation level less than or equal to 1.0 3537 (bug 11979). 3538 3539 19 10/25/12 pbrown Update spec language describing tessellation of 3540 isolines. Fix the inconsistent/incorrect 3541 language describing the handling of tessellation 3542 levels -- outer level 0 controls the number of 3543 isolines generated and outer level 1 controls 3544 the number of segements in each isoline (bug 3545 9195/9607). Minor isoline tessellation wording 3546 fixes for improved clarity. 3547 3548 18 03/29/10 pbrown Update issues (42), (46), and (47). 3549 3550 17 03/22/10 pbrown Minor corrections to the Dependencies section. 3551 3552 16 01/29/10 pbrown Updates from ARB review (bug 5905). In 3553 particular, we again allow only the token 3554 "gl_Invocation" for indexing TCS outputs, 3555 reversing changes in version 7. Added some 3556 clarifications to barrier(). Increased minimum 3557 value of gl_MaxCombinedTextureImageUnits. 3558 3559 15 01/26/10 pbrown Reflow some ragged paragraphs. 3560 3561 14 01/20/10 Jon Leech Make behavior, not just results undefined 3562 when reading gl_in beyond the number of 3563 vertices in the input patch (Bug 5880). 3564 3565 13 01/20/10 pbrown Clarify the required minimum values for 3566 MAX_COMBINED_*_UNIFORM_COMPONENTS (bug 5919). 3567 3568 12 01/14/10 Jon Leech Remove erroneous reference to triangles from 3569 tesselation control shader input language 3570 (Bug 5881). 3571 3572 11 01/14/10 pbrown Minor clarifications from spec reviews. Add 3573 missing edits for gl_InvocationID changes from 3574 version 7. 3575 3576 10 12/14/09 pbrown Rename "gl_VerticesIn" to "gl_PatchVerticesIn" 3577 to avoid collision with the EXT_geometry_shader4 3578 variable of the same name. Add language 3579 clarifying the size applied to unsized input 3580 arrays for tessellation control and evaluation 3581 shaders. 3582 3583 9 12/10/09 pbrown Rename the layout qualifiers for vertex order to 3584 "cw" and "ccw". Minor changes to invariance 3585 rules, including addition of a rule guaranteeing 3586 that <x> + (1-<x>) is exactly 1.0 for 3587 gl_TessCoord components. 3588 3589 8 12/10/09 pbrown Convert from EXT to ARB. 3590 3591 7 12/09/09 pbrown Miscellaneous fixes from spec review: Added a 3592 new invariance section describing a set of 3593 hopefully useful rules for tessellation. 3594 Slightly relaxed the rules requiring 3595 gl_InvocationID for TCS per-vertex outputs. 3596 Cleaned up language on primitive generation and 3597 when outputs are defined in TCS w.r.t. barrier. 3598 General typo fixes and language clarifications. 3599 3600 6 11/02/09 pbrown Fix cut-and-paste error in the definition of 3601 gl_PrimitiveID. 3602 3603 5 10/23/09 pbrown Change the name of one GLSL constant to 3604 gl_MaxTessPatchComponents (was "TessControl") 3605 to match the API constant name. This limit 3606 also applies to evaluation shaders. 3607 3608 4 10/13/09 pbrown Minor typo fixes. 3609 3610 3 10/01/09 pbrown Renamed some of the tessellation evaluation 3611 shader input layout qualifiers to more closely 3612 match geometry shader conventions. Renamed 3613 gl_ThreadID to gl_InvocationID. Fixed one 3614 reference to an old layout qualifier name. 3615 3616 2 09/28/09 pbrown Typo fix. 3617 3618 1 pbrown Internal revisions. 3619 3620