1Name 2 3 NV_tessellation_program5 4 5Name Strings 6 7 (none) 8 9Contact 10 11 Pat Brown, NVIDIA Corporation (pbrown 'at' nvidia.com) 12 13Status 14 15 Shipping. 16 17Version 18 19 Last Modified Date: 12/19/2011 20 NVIDIA Revision: 3 21 22Number 23 24 391 25 26Dependencies 27 28 OpenGL 1.1 is required. 29 30 This extension is written against the OpenGL 2.1 specification. 31 32 NV_gpu_program5 is required. This extension is supported if and only 33 "GL_NV_gpu_program5" is found in the extension string. This extension is 34 written against the NV_gpu_program5 extension. 35 36 This specification interacts with ARB_tessellation_shader. 37 38 This specification interacts with NV_parameter_buffer_object. 39 40Overview 41 42 This extension, in conjunction with the ARB_tessellation_shader extension, 43 introduces a new tessellation stage to the OpenGL primitive processing 44 pipeline. The ARB_tessellation_shader extension provides programmable 45 shading functionality using the OpenGL Shading Language as its base; this 46 extension provides assembly programmable shaders building on the family of 47 assembly programmability extensions including ARB_vertex_program, 48 ARB_fragment_program, NV_gpu_program4, and NV_geometry_program4. 49 50 This extension adds a new basic primitive type, called a patch, which 51 consists of an array of vertices plus some associated per-patch state. It 52 also adds two new assembly program types: a tessellation control program 53 that transforms a patch into a new patch and a tessellation evaluation 54 program that computes the position and attributes of each vertex produced 55 by the tesselator. 56 57 When tessellation is active, it begins by running the optional 58 tessellation control program, if enabled. This program consumes a 59 variable-size input patch and produces a new fixed-size output patch. The 60 output patch consists of an array of vertices, and a set of per-patch 61 attributes. The per-patch attributes include tessellation levels that 62 control how finely the patch will be tessellated. For each patch 63 processed, multiple tessellation control program invocations are performed 64 -- one per output patch vertex. Each tessellation control program 65 invocation writes all the attributes of its corresponding output patch 66 vertex. A tessellation control program may also read the per-vertex 67 outputs of other tessellation control program invocations, as well as read 68 and write shared per-patch outputs. The tessellation control program 69 invocations for a single patch effectively run as a group. The GL 70 automatically synchronizes threads to ensure that when executing a given 71 instruction, all previous instructions have completed for all program 72 invocations in the group. 73 74 The tessellation primitive generator then decomposes a patch into a new 75 set of primitives using the tessellation levels to determine how finely 76 tessellated the output should be. The primitive generator begins with 77 either a triangle or a quad, and splits each outer edge of the primitive 78 into a number of segments approximately equal to the corresponding element 79 of the outer tessellation level array. The interior of the primitive is 80 tessellated according to elements of the inner tessellation level array. 81 The primitive generator has three modes: TRIANGLES and QUADS split a 82 triangular or quad-shaped patch into a set of triangles that cover the 83 original patch; ISOLINES_NV splits a quad-shaped patch into a set of line 84 strips spanning the patch. Each vertex generated by the tessellation 85 primitive generator is assigned a (u,v) or (u,v,w) coordinate indicating 86 its relative location in the subdivided triangle or quad. 87 88 For each vertex produced by the tessellation primitive generator, the 89 tessellation evaluation program is run to compute its position and other 90 attributes of the vertex, using its (u,v) or (u,v,w) coordinate. When 91 computing the final vertex attributes, the tessellation evaluation program 92 can also read the attributes of any of the vertices of the patch written 93 by the tessellation control program. Tessellation evaluation program 94 invocations are completely independent, although all invocations for a 95 single patch share the same collection of input vertices and per-patch 96 attributes. 97 98 The tessellator operates on vertices after they have been transformed by a 99 vertex program or fixed-function vertex processing. The primitives 100 generated by the tessellator are passed further down the OpenGL pipeline, 101 where they can be used as inputs to geometry programs, transform feedback, 102 and the rasterizer. 103 104 The tessellation control and evaluation programs are both optional. If 105 neither program type is present, the tessellation stage has no effect. If 106 no tessellation control program is present, the input patch provided by 107 the application is passed directly to the tessellation primitive 108 generator, and a set of fixed tessellation level parameters (specified via 109 the PatchParameterfv function) is used to control primitive generation. 110 If no tessellation evaluation program is present, the output patch 111 produced by the tessellation control program is passed as a patch to 112 subsequent pipeline stages, where it can be consumed by geometry programs, 113 transform feedback, or the rasterizer. 114 115 116New Procedures and Functions 117 118 None 119 120 (Note: The PatchParameteri and PatchParameterfv functions from 121 ARB_tessellation_shader will also be used by this extension.) 122 123New Tokens 124 125 Accepted by the <cap> parameter of Disable, Enable, and IsEnabled, 126 by the <pname> parameter of GetBooleanv, GetIntegerv, GetFloatv, 127 and GetDoublev, and by the <target> parameter of ProgramStringARB, 128 BindProgramARB, ProgramEnvParameter4[df][v]ARB, 129 ProgramLocalParameter4[df][v]ARB, GetProgramEnvParameter[df]vARB, 130 GetProgramLocalParameter[df]vARB, GetProgramivARB and 131 GetProgramStringARB: 132 133 TESS_CONTROL_PROGRAM_NV 0x891E 134 TESS_EVALUATION_PROGRAM_NV 0x891F 135 136 Accepted by the <target> parameter of ProgramBufferParametersfvNV, 137 ProgramBufferParametersIivNV, and ProgramBufferParametersIuivNV, 138 BindBufferRangeNV, BindBufferOffsetNV, BindBufferBaseNV, and BindBuffer 139 and the <value> parameter of GetIntegerIndexedvEXT: 140 141 TESS_CONTROL_PROGRAM_PARAMETER_BUFFER_NV 0x8C74 142 TESS_EVALUATION_PROGRAM_PARAMETER_BUFFER_NV 0x8C75 143 144 Accepted by the <pname> parameter of GetProgramivARB: 145 146 MAX_PROGRAM_PATCH_ATTRIBS_NV 0x86D8 147 148 (Note: Various enumerants from ARB_tessellation_shader will also be used 149 by this extension.) 150 151 152Additions to Chapter 2 of the OpenGL 1.5 Specification (OpenGL Operation) 153 154 (Incorporate Section 2.X of the ARB_tessellation_shader specification, 155 Tessellation in its entirety.) 156 157 Insert a new section after Section 2.X.1 in ARB_tessellation_shader, 158 Tessellation Control Shaders 159 160 Tessellation Control Programs 161 162 Each patch primitive may be optionally processed by a tessellation control 163 program, which operates similarly to the tessellation control shader 164 described above. Tessellation control programs are enabled by calling 165 Enable with the value TESS_CONTROL_PROGRAM_NV. If a GLSL program is 166 active, the tessellation control program enable is ignored and treated as 167 disabled unless the program contains only fragment shaders. 168 169 When enabled, each patch primitive received by the GL will be processed by 170 the tessellation control program to produce a new patch. The tessellation 171 control program emits a patch with a fixed number of vertices, given by 172 the value specified in the VERTICES_OUT declaration. It computes the 173 attributes of each vertex of the output patch in parallel, and assembles 174 the emitted vertices into an output patch. The program also computes 175 per-patch tessellation level values that control the number of vertices 176 produced by the tessellation primitive generator when that patch is 177 processed. The program may also compute additional generic per-patch 178 attributes that may be accessed by invocations of the tessellation 179 evaluation program or a subsequent geometry program when processing the 180 patch. When the tessellation control program completes, the input patch 181 is discarded and the output patch is processed by the remainder of the GL 182 pipeline. 183 184 Each patch processed by the tessellation control program will result in 185 multiple program invocations (threads), with one invocation per output 186 patch vertex. Each program invocation has a corresponding output patch 187 vertex, and can write per-vertex attributes only for that vertex. All 188 program invocations may read and write per-patch attributes of the output 189 patch, and may read per-vertex attributes of any vertex in the output 190 patch. 191 192 The tessellation control program threads are run as a group, and execute 193 effectively in lock-step. In this model, the execution of each 194 instruction completes for all active threads before the execution of 195 subsequent instruction is started. All threads in the group are initially 196 active, but the set of active threads change as flow-control instructions 197 are encountered. Full details on the execution model are specified in 198 Section 2.X.5. 199 200 Tessellation control programs execute using the instruction set documented 201 in the GL_NV_gpu_program5 extension specification. Tessellation control 202 programs can read attributes from all vertices of the input patch, and 203 each vertex attribute access must identify the vertex number being 204 accessed. For example, "vertex[1].position" and "vertex.in[1].position" 205 identify the position of the second vertex (numbered "1") in the input 206 patch. Programs may also read attributes of all vertices of the output 207 patch (e.g., "vertex.out[2].position") and per-patch attributes of the 208 output patch (e.g., "primitive.out.attrib[3]"). In both cases, the output 209 patch vertices or attributes accessed in this manner are undefined unless 210 written by a previous instruction executed on one of the threads. 211 Programs may also write attributes of their corresponding vertex in the 212 output patch (e.g., "result.attrib[0]") and shared per-patch attributes 213 (e.g., "result.patch.attrib[4]"). When writing output patch vertex 214 attributes, a vertex number is not supplied. 215 216 The only input primitives supported by tessellation control programs are 217 patches. The error INVALID_OPERATION is generated by Begin (or vertex 218 array functions that implicitly call Begin) if a tessellation control 219 program is active and <mode> is not PATCHES_NV. 220 221 222 Modify section after Section 2.X.2 of ARB_tessellation_shader, 223 Tessellation Primitive Generation 224 225 (add to the end of the section describing the operation of the 226 tessellation primitive generator when assembly tessellation evaluation 227 programs are used) 228 229 If no GLSL program object is active, or if the active program contains 230 only a fragment shader, the tessellation primitive generator will be 231 active if and only if an assembly tessellation evaluation program is 232 enabled. When a tessellation evaluation program is used, the tessellation 233 primitive generator will operate in exactly the manner describe above, 234 except that the parameters controlling tessellation will be taken from 235 declaration statements in the tessellation evaluation program. The 236 declaration statements used to specify each tessellation parameter are as 237 described in Table X.1. 238 239 GLSL Program Parameter TEP Declaration 240 ------------------------ ----------------- 241 TESS_GEN_MODE_NV TESS_MODE 242 TESS_GEN_SPACING_NV TESS_SPACING 243 TESS_GEN_VERTEX_ORDER_NV TESS_VERTEX_ORDER 244 TESS_GEN_POINT_MODE_NV TESS_POINT_MODE 245 246 Table X.1, Parameters used to control tessellation when a program object 247 with a tessellation evaluation shader is active and their tessellation 248 evaluation program equivalents. 249 250 If no tessellation control program is enabled, the default tessellation 251 levels specified by calling PatchParameterfvNV with a <pname> of 252 PATCH_DEFAULT_OUTER_LEVEL_NV or PATCH_DEFAULT_INNER_LEVEL_NV. 253 254 If a GLSL program containing only a fragment shader is active, any 255 tessellation-related program parameters in effect when the program was 256 linked have no effect on tessellation. 257 258 259 Insert a new section after Section 2.X.3 in ARB_tessellation_shader, 260 Tessellation Evaluation Shaders 261 262 Tessellation Evaluation Programs 263 264 If a tessellation evaluation program is active, the tessellation primitive 265 generator will subdivide a basic primitive and run the tessellation 266 evaluation program on each generated vertex. Tessellation evaluation 267 programs are enabled by calling Enable with the value 268 TESS_EVALUATION_PROGRAM_NV. If a GLSL program is active, the tessellation 269 evaluation program enable is ignored and treated as disabled unless the 270 program contains only fragment shaders. 271 272 When tessellation evaluation programs are enabled, each patch primitive 273 received by the GL will trigger the tessellation primitive generator to 274 perform primitive subdivision and generate a new set of vertices. For 275 each generated vertex, the tessellation evaluation program is invoked. 276 Each tessellation evaluation program invocation produces a single output 277 vertex. These vertices are assembled into primitives according to the 278 subdivision produced by the tessellation primitive generator, and these 279 primitives are processed by the remainder of the GL pipeline. The input 280 patch used by the tessellation evaluation program is discarded. 281 282 Tessellation evaluation programs execute using the instruction set 283 documented in the GL_NV_gpu_program5 extension specification and in a 284 manner similar to vertex programs. Tessellation control programs can read 285 attributes from all vertices of the input patch, and each vertex attribute 286 access must identify the vertex number being accessed. For example, 287 "vertex[1].position" identifies the transformed position of "vertex[1]", 288 which is the second vertex in the input patch. Additionally, the special 289 attribute variable "vertex.tesscoord" is available to specify the location 290 of the vertex within the subdivided primitive. Per-patch attributes, 291 including the tessellation levels, are also available. 292 293 The only input primitives supported by tessellation evaluation programs 294 are patches. The error INVALID_OPERATION is generated by Begin (or vertex 295 array functions that implicitly call Begin) if a tessellation evaluation 296 program is active and <mode> is not PATCHES_NV. 297 298 299 Modify Section 2.X.2 of NV_gpu_program4, Program Grammar 300 301 (replace third paragraph) 302 303 Tessellation control programs are required to begin with the header string 304 "!!NVtcp5.0". Tessellation evaluation programs are required to begin with 305 the header string "!!NVtep5.0". These header strings identify the 306 subsequent program body as being a tessellation control or evaluation 307 program, respectively, and indicate that they should be parsed according 308 to the base NV_gpu_program5 grammar plus the additions below. Program 309 string parsing begins with the character immediately following the header 310 string. 311 312 (For tessellation control programs, add the following grammar rules to the 313 NV_gpu_program5 base grammar) 314 315 <declSequence> ::= <declaration> <declSequence> 316 317 <attribUseV> ::= <attribColor> "." <faceType> <swizzleSuffix> 318 | <attribColor> "." <faceType> "." <colorType> 319 <swizzleSuffix> 320 321 <resultUseW> ::= <resultVarName> <arrayMem> <optWriteMask> 322 | <resultColor> <optWriteMask> 323 | <resultColor> "." <colorType> <optWriteMask> 324 | <resultColor> "." <faceType> <optWriteMask> 325 | <resultColor> "." <faceType> "." <colorType> 326 "." <optWriteMask> 327 328 <resultUseD> ::= <resultColor> <optFaceColorType> 329 | <resultMulti> 330 331 <optFaceColorType> ::= <optColorType> 332 | "." <faceType> <optColorType> 333 334 <declaration> ::= "VERTICES_OUT" <int> 335 336 <attribBasic> ::= <vtxPrefix> "position" 337 | <vtxPrefix> "fogcoord" 338 | <vtxPrefix> "pointsize" 339 | <vtxPrefix> "id" 340 | <attribTexCoord> <optArrayMemAbs> 341 | <attribClip> <arrayMemAbs> 342 | <attribGeneric> <arrayMemAbs> 343 | <primPrefix> "." "id" 344 | <primPrefix> "." "invocation" 345 | <primPrefix> "." "vertexcount" 346 | <attribTessOuter> <arrayMemAbs> 347 | <attribTessInner> <arrayMemAbs> 348 | <attribPatchGeneric> <arrayMemAbs> 349 350 <attribColor> ::= <vtxPrefix> "color" 351 352 <attribMulti> ::= <attribTexCoord> <arrayRange> 353 | <attribClip> <arrayRange> 354 | <attribGeneric> <arrayRange> 355 | <attribTessOuter> <arrayRange> 356 | <attribTessInner> <arrayRange> 357 | <attribPatchGeneric> <arrayRange> 358 359 <attribTexCoord> ::= <vtxPrefix> "texcoord" 360 361 <attribClip> ::= <vtxPrefix> "clip" 362 363 <attribGeneric> ::= <vtxPrefix> "attrib" 364 365 <attribTessOuter> ::= <primPrefix> "." "tessouter" 366 367 <attribTessInner> ::= <primPrefix> "." "tessinner" 368 369 <attribPatchGeneric> ::= <primPrefix> "." "patch" "." "attrib" 370 371 <vtxPrefix> ::= "vertex" "." 372 | "vertex" <arrayMemAbs> "." 373 | "vertex" "." "in" <optArrayMemAbs> "." 374 | "vertex" "." "out" <optArrayMemAbs> "." 375 376 <primPrefix> ::= "primitive" "." 377 | "primitive" "." "in" "." 378 | "primitive" "." "out" "." 379 380 <resultBasic> ::= <resPrefix> "position" 381 | <resPrefix> "fogcoord" 382 | <resPrefix> "pointsize" 383 | <resultTexCoord> <optArrayMemAbs> 384 | <resultClip> <arrayMemAbs> 385 | <resultGeneric> <arrayMemAbs> 386 | <resPrefix> "id" 387 | <resultTessOuter> <arrayMemAbs> 388 | <resultTessInner> <arrayMemAbs> 389 | <resultPatchGeneric> <arrayMemAbs> 390 391 <resultColor> ::= <resPrefix> "color" 392 393 <resultMulti> ::= <resultTexCoord> <arrayRange> 394 | <resultClip> <arrayRange> 395 | <resultGeneric> <arrayRange> 396 | <resultTessOuter> <arrayRange> 397 | <resultTessInner> <arrayRange> 398 | <resultPatchGeneric> <arrayRange> 399 400 <resultTexCoord> ::= <resPrefix> "texcoord" 401 402 <resultClip> ::= <resPrefix> "clip" 403 404 <resultGeneric> ::= <resPrefix> "attrib" 405 406 <resultTessOuter> ::= <resPrefix> "." "patch" "." "tessouter" 407 408 <resultTessInner> ::= <resPrefix> "." "patch" "." "tessinner" 409 410 <resultPatchGeneric> ::= <resPrefix> "." "patch" "." "attrib" 411 412 <resPrefix> ::= "result" "." 413 414 415 (For tessellation evaluation programs, add the following grammar rules to 416 the NV_gpu_program5 base grammar) 417 418 <declSequence> ::= <declaration> <declSequence> 419 420 <attribUseV> ::= <attribColor> "." <faceType> <swizzleSuffix> 421 | <attribColor> "." <faceType> "." <colorType> 422 <swizzleSuffix> 423 424 <resultUseW> ::= <resultVarName> <arrayMem> <optWriteMask> 425 | <resultColor> <optWriteMask> 426 | <resultColor> "." <colorType> <optWriteMask> 427 | <resultColor> "." <faceType> <optWriteMask> 428 | <resultColor> "." <faceType> "." <colorType> 429 "." <optWriteMask> 430 431 <resultUseD> ::= <resultColor> <optFaceColorType> 432 | <resultMulti> 433 434 <optFaceColorType> ::= <optColorType> 435 | "." <faceType> <optColorType> 436 437 <declaration> ::= "TESS_MODE" <declTessMode> 438 | "TESS_SPACING" <declTessSpacing> 439 | "TESS_VERTEX_ORDER" <declTessVtxOrder> 440 | "TESS_POINT_MODE" 441 442 <declTessMode> ::= "TRIANGLES" 443 | "QUADS" 444 | "ISOLINES" 445 446 <declTessSpacing> ::= "EQUAL" 447 | "FRACTIONAL_ODD" 448 | "FRACTIONAL_EVEN" 449 450 <declTessVtxOrder> ::= "CW" 451 | "CCW" 452 453 <attribBasic> ::= <vtxPrefix> "position" 454 | <vtxPrefix> "fogcoord" 455 | <vtxPrefix> "pointsize" 456 | <vtxPrefix> "id" 457 | <attribTexCoord> <optArrayMemAbs> 458 | <attribClip> <arrayMemAbs> 459 | <attribGeneric> <arrayMemAbs> 460 | "vertex" "." "tesscoord" 461 | <primPrefix> "id" 462 | <primPrefix> "vertexcount" 463 | <attribTessOuter> <optArrayMemAbs> 464 | <attribTessInner> <optArrayMemAbs> 465 | <attribPatchGeneric> <optArrayMemAbs> 466 467 <attribColor> ::= <vtxPrefix> "color" 468 469 <attribMulti> ::= <attribTexCoord> <arrayRange> 470 | <attribClip> <arrayRange> 471 | <attribGeneric> <arrayRange> 472 | <attribTessOuter> <arrayRange> 473 | <attribTessInner> <arrayRange> 474 | <attribPatchGeneric> <arrayRange> 475 476 <attribTexCoord> ::= <vtxPrefix> "texcoord" 477 478 <attribClip> ::= <vtxPrefix> "clip" 479 480 <attribGeneric> ::= <vtxPrefix> "attrib" 481 482 <attribTessOuter> ::= <primPrefix> "." "tessouter" 483 484 <attribTessInner> ::= <primPrefix> "." "tessinner" 485 486 <attribPatchGeneric> ::= <primPrefix> "." "patch" "." "attrib" 487 488 <vtxPrefix> ::= "vertex" "." 489 | "vertex" <arrayMemAbs> "." 490 | "vertex" "." "in" <optArrayMemAbs> "." 491 | "vertex" "." "out" <optArrayMemAbs> "." 492 493 <primPrefix> ::= "primitive" "." 494 | "primitive" "." "in" "." 495 496 <resultBasic> ::= <resPrefix> "position" 497 | <resPrefix> "fogcoord" 498 | <resPrefix> "pointsize" 499 | <resultTexCoord> <optArrayMemAbs> 500 | <resultClip> <arrayMemAbs> 501 | <resultGeneric> <arrayMemAbs> 502 | <resPrefix> "id" 503 504 <resultColor> ::= <resPrefix> "color" 505 506 <resultMulti> ::= <resultTexCoord> <arrayRange> 507 | <resultClip> <arrayRange> 508 | <resultGeneric> <arrayRange> 509 510 <resultTexCoord> ::= <resPrefix> "texcoord" 511 512 <resultClip> ::= <resPrefix> "clip" 513 514 <resultGeneric> ::= <resPrefix> "attrib" 515 516 <resPrefix> ::= "result" "." 517 518 519 (add the following subsection to section 2.X.3.2 of NV_gpu_program4, 520 Program Attribute Variables) 521 522 Tessellation control and evaluation program attribute variables describe 523 inputs accessible to the program. There are several different classes of 524 attribute bindings available, identified by the binding prefix. The set 525 of attribute binding classes and their corresponding prefixes are 526 described in Table X.2. The specific attributes for each class are 527 identified by a binding suffix. 528 529 Attribute Binding Prefix Description 530 ------------------------ ------------------------------------------ 531 vertex[m] Vertex <m> of the input patch 532 vertex.in[m] Vertex <m> of the input patch 533 vertex Array spanning vertices of the input patch 534 or the specific vertex being evaluated 535 vertex.in Array spanning vertices of the input patch 536 or the specific vertex being evaluated 537 primitive Per-patch value of the input patch 538 primitive.in Per-patch value of the input patch 539 vertex.out[m] Vertex <m> of the output patch 540 vertex.out Array spanning vertices of the output patch 541 primitive.out Per-patch value of the output patch 542 543 Table X.2, Tessellation Control and Evaluation Program Attribute Binding 544 Prefixes. <m> refers to a constant integer vertex number in the input 545 or output patch. 546 547 If an attribute binding prefix matches "vertex[m]" or "vertex.in[m]", the 548 attribute binding refers to an attribute of the vertex numbered <m> in the 549 input patch. If <m> is greater than or equal to the number of vertices in 550 the input patch, the values corresponding to the binding are undefined. 551 552 If an attribute binding prefix matches "vertex" or "vertex.in" and the 553 suffix identifies an attribute of the vertex being processed by a 554 tessellation evaluation program (e.g., "tesscoord"), the attribute binding 555 refers to that attribute. 556 557 If an attribute binding prefix matches "vertex" or "vertex.in" and the 558 suffix identifies any other vertex attribute, the attribute binding refers 559 to that specific attribute for each of the vertices of the input patch. 560 Bindings of this form may only be used in explicit variable declarations. 561 If the variable declaration identifies an array, the program will fail to 562 load unless each binding in the binding list uses an attribute prefix of 563 this form. When such variables are used in instructions, they must be 564 accessed as an array, with the first array index identifying the vertex 565 number. If such variables are declared as an array, a second array index 566 must be provided to identify the specific per-vertex attribute to select. 567 If the first array index is negative or greater than or equal to the 568 number of vertices in the input patch, the value obtained is undefined. 569 570 If an attribute binding prefix matches "primitive" or "primitive.in", the 571 attribute binding refers to an attribute of the input patch. 572 573 If a tessellation control program attribute binding prefix matches 574 "vertex.out[m]", the attribute binding refers to an attribute of the 575 vertex numbered <m> in the output patch. These attributes correspond to 576 per-vertex output values written by the tessellation control program 577 thread numbered <m>. A program will fail to load if the vertex number <m> 578 is greater than or equal to the number of vertices in the output patch. 579 Tessellation evaluation programs do not have an output patch and do not 580 support this attribute binding prefix. 581 582 If a tessellation control program attribute binding prefix matches 583 "vertex.out", the attribute binding identifies a specific attribute for 584 each of the vertices of the output patch. Bindings of this form may only 585 be used in explicit variable declarations, and all the usage rules 586 described above for bindings using the prefix "vertex.in" apply. If the 587 vertex number identified when accessing such variables is negative or 588 greater than or equal to the number of vertices in the output patch, the 589 resulting values are undefined. Tessellation evaluation programs do not 590 have an output patch and do not support this attribute binding suffix. 591 592 If an attribute binding prefix matches "primitive.out", the attribute 593 binding refers to a per-patch attribute of the output patch. These 594 attributes correspond to per-patch result values written by one of the 595 tessellation control program threads. Tessellation evaluation programs do 596 not have an output patch and do not support this attribute binding suffix. 597 598 The following examples illustrate various legal and illegal program 599 bindings and their meanings. 600 601 ATTRIB pos = vertex.position; 602 ATTRIB pos2 = vertex.in[2].position; 603 ATTRIB outpos = vertex.out.position; 604 ATTRIB outpos2 = vertex.out[2].position; 605 ATTRIB texcoords[] = { vertex.texcoord[0..3] }; 606 ATTRIB tcoords1[4] = { vertex[1].texcoord[1..4] }; 607 ATTRIB outattr[2] = { vertex.out.attrib[0..1] }; 608 INT TEMP A0; 609 ... 610 MOV R0, pos[1]; # position of input vertex 1 611 MOV R0, vertex[1].position; # position of input vertex 1 612 MOV R0, pos2; # position of input vertex 2 613 MOV R0, outpos; # ILLEGAL - needs a vertex number 614 MOV R0, outpos[1]; # position of output vertex 1 (TCP) 615 MOV R0, outpos2; # position of output vertex 2 (TCP) 616 MOV R0, texcoords[A0.x][1]; # texcoord 1 of input vertex A0.x 617 MOV R0, texcoords[A0.x][A0.y]; # texcoord A0.y of input vertex A0.x 618 MOV R0, tcoords1[2]; # texcoord 3 of input vertex 1 619 MOV R0, outattr[A0.x][1]; # generic attr 1 of output vertex 620 # A0.x (TCP) 621 MOV R0, vertex[A0.x].texcoord[1]; # ILLEGAL -- vertex number must be 622 # constant or must use variables like 623 # "texcoords" using bindings w/o 624 # vertex numbers 625 626 Attributes from input patch vertices will be obtained from the per-vertex 627 outputs of the previous program used to generate the vertex in question. 628 For tessellation evaluation programs, that previous program would be the 629 tessellation control program, if enabled, or the vertex program otherwise. 630 For tessellation control programs, the previous program is always the 631 vertex program. Tessellation control and evaluation program attributes 632 should be read using the same component data type used to write the 633 corresponding vertex program results. If input patch vertices are 634 specified to come from vertex program outputs but no vertex program is 635 enabled, the values are instead produced from fixed-function vertex 636 processing. The value of any attribute corresponding to a vertex output 637 not written by the previous program stage is undefined, as are the values 638 of all generic attributes if the vertex was produced by fixed-function 639 vertex processing. 640 641 Attributes from output patch vertices are only available in tessellation 642 control programs, and will be obtained from the per-vertex outputs of the 643 same program. When executing an instruction, the values of any output 644 patch vertex attribute are undefined unless the corresponding program 645 output was written by a previously executed instruction. 646 647 Per-patch attributes of the input patch are only available in tessellation 648 evaluation and geometry programs. If a tessellation control program is 649 enabled, they will be obtained from the corresponding per-patch outputs of 650 the tessellation control program producing the patch, and any attributes 651 not written by any thread of the control program are undefined. If no 652 tessellation control program is enabled, the inner and outer tessellation 653 levels are taken from the default tessellation levels, and all other 654 per-patch attributes are undefined. 655 656 Per-patch attributes of the output patch are available only in 657 tessellation control programs and will be obtained from the per-patch 658 outputs of the same program. When executing an instruction, the values of 659 any output patch attribute are undefined unless the corresponding program 660 output was written by a previously executed instruction. 661 662 The attributes of the vertices of an input or output patch vertex are 663 selected by an attribute binding suffix, as identified in Table X.3. All 664 such bindings correspond to one of multiple patch vertices and require a 665 vertex number, either in the binding prefix used in the instruction or as 666 the first array index when using an explicitly declared attribute variable 667 whose bindings have no vertex number. 668 669 Vertex Binding Suffix Components Description 670 ------------------------ ---------- ---------------------------- 671 position (x,y,z,w) clip coordinates 672 color (r,g,b,a) front primary color 673 color.primary (r,g,b,a) front primary color 674 color.secondary (r,g,b,a) front secondary color 675 color.front (r,g,b,a) front primary color 676 color.front.primary (r,g,b,a) front primary color 677 color.front.secondary (r,g,b,a) front secondary color 678 color.back (r,g,b,a) back primary color 679 color.back.primary (r,g,b,a) back primary color 680 color.back.secondary (r,g,b,a) back secondary color 681 fogcoord (f,-,-,-) fog coordinate 682 pointsize (s,-,-,-) point size 683 texcoord (s,t,r,q) texture coordinate, unit 0 684 texcoord[n] (s,t,r,q) texture coordinate, unit n 685 attrib[n] (x,y,z,w) generic interpolant n 686 clip[n] (d,-,-,-) clip plane distance 687 texcoord[n..o] (s,t,r,q) array of texture coordinates 688 attrib[n..o] (x,y,z,w) array of generic interpolants 689 clip[n..o] (d,-,-,-) array of clip distances 690 id (id,-,-,-) vertex id 691 692 Table X.3, Tessellation Control and Evaluation Program Per-Patch Vertex 693 Attribute Bindings. <n> and <o> refer to integer constants. 694 695 If an attribute binding suffix matches "position", the "x", "y", "z" and 696 "w" components of the attribute variable are filled with the "x", "y", 697 "z", and "w" components, respectively, of the transformed position of the 698 specified vertex, in clip coordinates. 699 700 If an attribute binding suffix matches any binding in Table X.3 beginning 701 with "color", the "x", "y", "z", and "w" components of the attribute 702 variable are filled with the "r", "g", "b", and "a" components, 703 respectively, of the corresponding color of the specified vertex. 704 Bindings containing "front" and "back" refer to the front and back colors, 705 respectively. Bindings containing "primary" and "secondary" refer to 706 primary and secondary colors, respectively. If face or color type is 707 omitted in the binding, the binding is treated as though "front" and 708 "primary", respectively, were specified. 709 710 If an attribute binding suffix matches "fogcoord", the "x" component of 711 the attribute variable is filled with the fog coordinate of the specified 712 vertex. The "y", "z", and "w" components are undefined. 713 714 If an attribute binding suffix matches "pointsize", the "x" component of 715 the attribute variable is filled with the point size of the specified 716 vertex. If the vertex was produced by fixed-function vertex processing, 717 the point size attribute is undefined. The "y", "z", and "w" components 718 are always undefined. 719 720 If an attribute binding suffix matches "texcoord" or "texcoord[n]", the 721 "x", "y", "z", and "w" coordinates of the attribute variable are filled 722 with the "s", "t", "r", and "q" coordinates of texture coordinate set <n> 723 of the specified vertex. If <n> is omitted, texture coordinate set zero 724 is used. 725 726 If an attribute binding suffix matches "attrib[n]", the "x", "y", "z", and 727 "w" components of the attribute variable are filled with the "x", "y", 728 "z", and "w" coordinates of generic interpolant <n> of the specified. All 729 generic interpolants will be undefined when the vertex is produced by 730 fixed-function vertex processing. 731 732 If an attribute binding suffix matches "clip[n]", the "x" component of the 733 attribute variable is filled the clip distance of the specified vertex for 734 clip plane <n>, as written by the vertex program. If the vertex was 735 produced by fixed-function vertex processing or a position-invariant 736 vertex program, the clip distance is obtained by computing the per-clip 737 plane dot product: 738 739 (p_1' p_2' p_3' p_4') dot (x_e y_e z_e w_e), 740 741 at the vertex location, as described in section 2.12. The clip distance 742 for clip plane <n> is undefined if clip plane <n> is disabled. The "y", 743 "z", and "w" components of the attribute are undefined. 744 745 If an attribute binding suffix matches "texcoord[n..o]", "attrib[n..o]", 746 or "clip[n..o]", a sequence of 1+<o>-<n> texture coordinate, generic 747 attribute, or clip distance bindings is created. For texture coordinate 748 bindings, it is as though the sequence "vertex[m].texcoord[n], 749 vertex[m].texcoord[n+1], ... vertex[m].texcoord[o]" were specfied. These 750 bindings are available only in explicit declarations of array variables. 751 A program will fail to load if <n> is greater than <o>. 752 753 If an attribute binding suffix matches "id", the "x" component is filled 754 with the vertex ID of the specified vertex. If the vertex was generated 755 by a previous program, the attribute variable is filled with the vertex ID 756 result written by that program. Otherwise, the vertex ID is undefined. 757 The "y", "z", and "w" components of the attribute are undefined. 758 759 Attribute bindings other than those corresponding to individual vertices 760 in input and output patch are identified in Table X.4. All of these items 761 except for "vertex.tesscoord" are per-patch attributes, and require one of 762 the prefixes beginning with "primitive". 763 764 Primitive Binding Suffix Components Description 765 ------------------------ ---------- ---------------------------- 766 id (id,-,-,-) primitive number 767 invocation (id,-,-,-) tess. control invocation 768 vertexcount (c,-,-,-) vertices in primitive 769 tessouter[n] (x,-,-,-) outer tess. level n 770 tessinner[n] (x,-,-,-) inner tess. level n 771 patch.attrib[n] (x,y,z,w) generic patch attribute n 772 tessouter[n..o] (x,-,-,-) outer tess. levels n to o 773 tessinner[n..o] (x,-,-,-) inner tess. levels n to o 774 patch.attrib[n..o] (x,y,z,w) generic patch attrib n to o 775 vertex.tesscoord (*) (u,v,w,-) tess. coordinate in [0,1] 776 777 Table X.4, Tessellation Control and Evaluation Miscellaneous Attribute 778 Bindings. <n> and <o> refer to integer constants. 779 780 If an attribute binding suffix matches "id", the "x" component is filled 781 with the number of primitives received by the GL since the last time Begin 782 was called (directly or indirectly via vertex array functions). The first 783 primitive generated after a Begin is numbered zero, and the primitive ID 784 counter is incremented after every individual point, line, or polygon 785 primitive is processed. Restarting a primitive topology using the 786 primitive restart index has no effect on the primitive ID counter. The 787 "y", "z", and "w" components of the variable are always undefined. This 788 suffix may only be used with the prefixes "primitive", "primitive.in", or 789 "primitive.out", and produces the same value in all cases. 790 791 If a tessellation control program attribute binding suffix matches 792 "invocation", the "x" component is filled with the thread number of the 793 program invocation. The invocation number identifies the number of the 794 vertex in the output patch whose attributes are produced by this 795 invocation, and is in the range [0..<n>-1], where <n> is given by the 796 VERTICES_OUT declaration. The "y", "z", and "w" components of the 797 variable are always undefined. This suffix is not available to 798 tessellation evaluation programs and may only be used with the prefixes 799 "primitive", "primitive.in", or "primitive.out", and produces the same 800 value in all cases. 801 802 If an attribute binding suffix matches "vertexcount", the "x" component is 803 filled with the number of vertices in the input primitive being processed. 804 The "y", "z", and "w" components of the variable are always undefined. 805 This suffix is available only with the prefixes "primitive" and 806 "primitive.in". 807 808 If an attribute binding suffix matches "tessouter[n]", the "x" component 809 is filled with the per-patch outer tessellation level numbered <n> of the 810 identified input or output patch. <n> must be less than four. The "y", 811 "z", and "w" components are always undefined. This suffix is available 812 only with the prefixes "primitive", "primitive.in", and "primitive.out". 813 For tessellation control programs, this suffix is available only with 814 "primitive.out". 815 816 If an attribute binding suffix matches "tessinner[n]", the "x" component 817 is filled with the per-patch inner tessellation level numbered <n> of the 818 identified input or output patch. <n> must be less than two. The "y", 819 "z", and "w" components are always undefined. This suffix is available 820 only with the prefixes "primitive", "primitive.in", and "primitive.out". 821 For tessellation control programs, this suffix is available only with 822 "primitive.out". 823 824 If an attribute binding suffix matches "patch.attrib[n]", the "x", "y", 825 "z", and "w" components are filled with the corresponding components of 826 the per-patch generic attribute numbered <n> of the identified input or 827 output patch. This suffix is available only with the prefixes 828 "primitive", "primitive.in", and "primitive.out". For tessellation 829 control programs, this suffix is available only with "primitive.out". 830 831 If an attribute binding suffix matches "tessouter[n..o]", 832 "tessinner[n..o]", or "patch.attrib[n..o]", a sequence of 1+<o>-<n> outer 833 tessellation level, inner tessellation level, or per-patch generic 834 attribute bindings is created. For per-patch generic attribute bindings, 835 it is as though the sequence "primitive.patch.attrib[n], 836 primitive.patch.attrib[n+1], ... primitive.patch.attrib[o]" were 837 specfied. These bindings are available only in explicit declarations of 838 array variables. A program will fail to load if <n> is greater than <o>. 839 840 If a tessellation evaluation program attribute binding suffix matches 841 "vertex.tesscoord", the "x", "y", and "z" components are filled with the 842 floating-point (u,v,w) values, respectively, corresponding to the vertex 843 being processed by the tessellation evaluation program. For triangle 844 tessellation, the (u,v,w) values are barycentric coordinates that specify 845 the location of the vertex relative to the three corners of the subdivided 846 triangle. The (u,v,w) values are in the range [0,1] and sum to one. For 847 quad and isoline tessellation, the (u,v) values are in the range [0,1] and 848 specify the relative horizontal and vertical position in the subdivided 849 quad. The third component of the (u,v,w) vector is undefined for quad and 850 isoline tessellation. The "w" component of the variable is always 851 undefined. This suffix is not available to tessellation control shaders 852 and may only be used with the prefix "vertex". 853 854 855 (add the following subsection to section 2.X.3.5 of NV_gpu_program4, 856 Program Results.) 857 858 The attributes of individual output vertices are written by tessellation 859 control and evaluation programs. For tessellation control programs, these 860 attributes are those of the output patch vertex corresponding to the 861 program invocation. For tessellation evaluation programs, these 862 attributes specify the attributes of the vertex in the tessellated patch 863 corresponding to the program invocation. The set of allowable per-vertex 864 result variable bindings is the same for tessellation control and 865 evaluation programs correspond to attributes of output vertices and is 866 given in Table X.5. 867 868 Binding Components Description 869 ----------------------------- ---------- ---------------------------- 870 result.position (x,y,z,w) position in clip coordinates 871 result.color (r,g,b,a) front-facing primary color 872 result.color.primary (r,g,b,a) front-facing primary color 873 result.color.secondary (r,g,b,a) front-facing secondary color 874 result.color.front (r,g,b,a) front-facing primary color 875 result.color.front.primary (r,g,b,a) front-facing primary color 876 result.color.front.secondary (r,g,b,a) front-facing secondary color 877 result.color.back (r,g,b,a) back-facing primary color 878 result.color.back.primary (r,g,b,a) back-facing primary color 879 result.color.back.secondary (r,g,b,a) back-facing secondary color 880 result.fogcoord (f,*,*,*) fog coordinate 881 result.pointsize (s,*,*,*) point size 882 result.texcoord (s,t,r,q) texture coordinate, unit 0 883 result.texcoord[n] (s,t,r,q) texture coordinate, unit n 884 result.attrib[n] (x,y,z,w) generic interpolant n 885 result.clip[n] (d,*,*,*) clip plane distance 886 result.texcoord[n..o] (s,t,r,q) texture coordinates n thru o 887 result.attrib[n..o] (x,y,z,w) generic interpolants n thru o 888 result.clip[n..o] (d,*,*,*) clip distances n thru o 889 890 Table X.5: Tessellation Control and Evaluation Program Per-Vertex 891 Result Variable Bindings. Components labeled "*" are unused. 892 893 If a result variable binding matches "result.position", updates to the 894 "x", "y", "z", and "w" components of the result variable modify the "x", 895 "y", "z", and "w" components, respectively, of the transformed vertex's 896 clip coordinates. Final window coordinates of vertices used for 897 rasterization will be generated for the vertex as described in section 898 2.14.4.4. 899 900 If a result variable binding match begins with "result.color", updates to 901 the "x", "y", "z", and "w" components of the result variable modify the 902 "r", "g", "b", and "a" components, respectively, of the corresponding 903 vertex color attribute in Table X.3. Color bindings that do not specify 904 "front" or "back" are consided to refer to front-facing colors. Color 905 bindings that do not specify "primary" or "secondary" are considered to 906 refer to primary colors. 907 908 If a result variable binding matches "result.fogcoord", updates to the "x" 909 component of the result variable set the transformed vertex's fog 910 coordinate. Updates to the "y", "z", and "w" components of the result 911 variable have no effect. 912 913 If a result variable binding matches "result.pointsize", updates to the 914 "x" component of the result variable set the transformed vertex's point 915 size. Updates to the "y", "z", and "w" components of the result variable 916 have no effect. 917 918 If a result variable binding matches "result.texcoord" or 919 "result.texcoord[n]", updates to the "x", "y", "z", and "w" components of 920 the result variable set the "s", "t", "r" and "q" components, 921 respectively, of the transformed vertex's texture coordinates for texture 922 unit <n>. If "[n]" is omitted, texture unit zero is selected. 923 924 If a result variable binding matches "result.attrib[n]", updates to the 925 "x", "y", "z", and "w" components of the result variable set the "x", "y", 926 "z", and "w" components of the generic interpolant <n>. 927 928 If a result variable binding matches "result.clip[n]", updates to the "x" 929 component of the result variable set the clip distance for clip plane <n>. 930 931 If a result variable binding matches "result.texcoord[n..o]", 932 "result.attrib[n..o]", or "result.clip[n..o]", a sequence of 1+<o>-<n> 933 bindings is created. For texture coordinates, it is as though the 934 sequence "result.texcoord[n], result.texcoord[n+1], 935 ... result.texcoord[o]" were specfied. These bindings are available only 936 in explicit declarations of array variables. A program will fail to load 937 if <n> is greater than <o>. 938 939 In addition to per-vertex attribute bindings, a set of per-patch result 940 bindings are available to tessellation control programs, as described in 941 Table X.6. These bindings are not available to tessellation evaluation 942 programs. 943 944 Binding Components Description 945 ----------------------------- ---------- ---------------------------- 946 result.patch.tessouter[n] (x,*,*,*) tessctl outer level n 947 result.patch.tessinner[n] (x,*,*,*) tessctl inner level n 948 result.patch.attrib[n] (x,y,z,w) per-patch generic attrib n 949 result.patch.tessouter[n..o] (x,*,*,*) tessctl outer levels n thru o 950 result.patch.tessinner[n..o] (x,*,*,*) tessctl inner levels n thru o 951 result.patch.attrib[n..o] (x,y,z,w) per-patch attribs n thru o 952 953 Table X.4: Tessellation Control Per-Patch Result Variable Bindings. 954 Components labeled "*" are unused. 955 956 If a result variable binding matches "result.patch.tessouter[n]", updates 957 to the "x" component set the outer tessellation level numbered <n> for the 958 output patch. Updates to the "y", "z", and "w" components have no effect. 959 960 If a result variable binding matches "result.patch.tessinner[n]", updates 961 to the "x" component set the inner tessellation level numbered <n> for the 962 output patch. Updates to the "y", "z", and "w" components have no effect. 963 964 If a result variable binding matches "result.patch.attrib[n]", updates to 965 the "x", "y", "z", and "w" components of the result variable set the "x", 966 "y", "z", and "w" components of the per-patch generic attribute numbered 967 <n> for the output patch. 968 969 If a result variable binding matches "result.patch.tessouter[n..o]", 970 "result.patch.tessinner[n..o]", or "result.patch.attrib[n..o]", a sequence 971 of 1+<o>-<n> bindings is created. For per-patch generic attributes, it is 972 as though the sequence "result.patch.attrib[n], result.patch.attrib[n+1], 973 ... result.patch.attrib[o]" were specfied. These bindings are available 974 only in explicit declarations of array variables. A program will fail to 975 load if <n> is greater than <o>. 976 977 978 Modify Section 2.X.5 of NV_gpu_program4, Program Flow Control 979 980 (modify spec language at the end of the section to account for the 981 different flow control model for tessellation control programs) 982 983 Tessellation Control Program Flow Control 984 985 For tessellation control programs, there are multiple program invocations 986 for each patch processed that run as a group. Any given program 987 invocation can read per-vertex or per-patch attributes of the output 988 patch, which may be computed during the execution of the program and may 989 be computed by a different program invocation. To provide defined 990 behavior for such accesses, we specify that all threads for each patch run 991 as a group. When executing any block of instructions, all active threads 992 will complete the excecution of one instruction before starting the 993 execution of the subsequent instruction. Flow control instructions may 994 cause the flow of threads in a group to diverge and will modify the set of 995 active threads. The handling of flow control instructions is described in 996 more detail below. 997 998 A tessellation control program is handled by executing all instructions in 999 a block of instructions corresponding to the main subroutine, with all 1000 threads initially active. This block consists of all instructions between 1001 the "main" label and the next subroutine label. If no "main" label is 1002 present, the block starts with the first instruction in the program. If 1003 there is no subroutine label following the beginning of the block, the 1004 block ends at the END instruction. Instructions in the block are executed 1005 in order until all threads reach a termination condition. A thread will 1006 terminate: 1007 1008 * if it executes a RET anywhere within the main subroutine, unless the 1009 RET instruction is conditional and the condition code test fails; or 1010 1011 * if it completes the execution of all instructions in the subroutine 1012 block. 1013 1014 When an individual thread terminates processing of the main subroutine, 1015 the thread will become inactive and remain inactive for the remainder of 1016 program execution. When all threads have terminated the main subroutine 1017 block, program execution is complete and the output patch is passed to 1018 subsequent pipeline stages. 1019 1020 When a CAL instruction is executed, the current set of active threads will 1021 execute a block of instructions corresponding to the specified subroutine 1022 label. This block consists of all instructions between the specified 1023 label and the next subroutine label. If there is no subroutine label 1024 following the beginning of the block, the block ends at the END 1025 instruction. Instructions in the block are executed in order until all 1026 active threads reach a termination condition. A thread will complete 1027 execution of a subroutine block: 1028 1029 * if the CAL instruction is conditional and the condition code test 1030 fails; 1031 1032 * if it executes a RET anywhere within the subroutine block, unless the 1033 RET instruction is conditional and the condition code test fails; or 1034 1035 * if it completes the execution of all instructions in the subroutine 1036 block. 1037 1038 When an individual thread terminates processing of a called subroutine, 1039 the thread will become inactive and remain inactive until all threads have 1040 reached their termination condition. When all threads have terminated the 1041 subroutine, execution continues at the instruction following the CAL 1042 instruction. All threads active for initial CAL instruction become active 1043 again; all other threads will remain inactive. 1044 1045 When a REP instruction is executed, the current set of active threads will 1046 repeatedly execute the instructions between the REP and corresponding 1047 ENDREP instruction in order. Execution of this instruction loop will 1048 continue until all threads active when the REP instruction is executed 1049 reach a termination condition. A thread will terminate the processing of 1050 a REP/ENDREP block: 1051 1052 * if the REP instruction specifies a loop count, and the initial loop 1053 count is not positive; 1054 1055 * if the REP instruction specifies a loop count, and the current value 1056 of the loop count for the thread reaches zero when decremented by an 1057 ENDREP instruction; 1058 1059 * if a RET instruction is executed anywhere within the REP/ENDREP block, 1060 unless the RET instruction is conditional and the condition code test 1061 fails; or 1062 1063 * if a BRK instruction is executed inside the REP/ENDREP block, unless 1064 the BRK instruction is contained inside a more-deeply nested 1065 REP/ENDREP block or the BRK instruction is conditional and the 1066 condition code test fails. 1067 1068 When an individual thread terminates processing of a REP/ENDREP loop, the 1069 thread will become inactive and remain inactive until all threads have 1070 terminated the loop. When all threads have terminated the loop, execution 1071 continues at the instruction following the ENDREP instruction. All 1072 threads active for initial REP instruction become active again, unless 1073 they executed a RET instruction inside the REP/ENDREP block. All other 1074 threads will be inactive. 1075 1076 If a conditional CONT instruction is executed inside a REP/ENDREP block, 1077 all active threads passing the condition code test will become inactive 1078 and remain inactive until the next ENDREP instruction. If all active 1079 threads become inactive following the completion of a CONT instruction, 1080 processing continues at the next ENDIF or ENDREP instruction. An 1081 unconditional CONT instruction is treated identically to a conditional 1082 CONT instruction where all active threads pass the condition code test. 1083 1084 When an IF instruction belonging to an IF/ELSE/ENDIF block is executed, 1085 the current set of active threads is split into two groups. The first 1086 group consists of all active threads passing the condition code test, and 1087 will execute a block of instructions between the IF and ELSE. The second 1088 group consists of all active threads failing the condition code test, and 1089 will execute a block of instructions between the ELSE and ENDIF. 1090 Instructions within each group are executed in lock-step order. However, 1091 the order of execution of instructions for threads in the first group are 1092 undefined relative to those in the second group. 1093 1094 When executing a block of instructions for either of the two groups in an 1095 IF/ELSE/ENDIF block, instructions within the block will be executed in 1096 order with only the threads in that group active. The instructions of the 1097 block are executed until all threads in the group reach a block 1098 termination condition. A thread will terminate the processing of its 1099 block: 1100 1101 * if it executes a RET instruction, unless the RET instruction is 1102 conditional and the condition code test fails; 1103 1104 * if it executes a BRK or CONT instruction inside the IF/ENDIF block, 1105 unless that instruction is contained in a more-deeply nested 1106 REP/ENDREP block or if the instruction is conditional and the 1107 condition code test fails; or 1108 1109 * if it completes the execution of all instructions in the instruction 1110 block. 1111 1112 When both groups have completed their instruction blocks, execution 1113 continues at the instruction following the ENDIF. No instruction 1114 following the ENDIF will be executed until both groups have completed. At 1115 that point, any thread active for the IF instruction will become active 1116 again unless the execution of its instruction block was terminated due to 1117 the execution of a RET, BRK, or CONT instruction. All other threads will 1118 be inactive. 1119 1120 An IF instruction belonging to an IF/ENDIF block (with no corresponding 1121 ELSE) is handled as above, except that only one thread group created. 1122 That group will consists of all active threads passing the condition code, 1123 and it executes a block of instructions between the IF and ENDIF. 1124 1125 The order of execution imposed by this flow control model typically 1126 produces defined results when a tessellation control shader writes an 1127 output patch attribute, and then reads it (possibly on a different thread) 1128 for further computation. There are two cases where undefined instruction 1129 execution order will lead to undefined attribute values. When two or more 1130 threads access an attribute in a single executed instruction: 1131 1132 * the value of the attribute after the instruction completes will be 1133 undefined if multiple threads write different values; and 1134 1135 * the value of the attribute read by one thread will be undefined if the 1136 same attribute is written by another thread executing the same 1137 instruction. 1138 1139 Also, when an IF/ELSE/ENDIF block is executed and a thread from each of 1140 the two thread groups access an attribute within its block: 1141 1142 * the value of the attribute after the completion of the block will be 1143 undefined if both threads write different values; 1144 1145 * the value of the attribute read by one thread will be undefined if the 1146 same attribute is written by another thread. 1147 1148 If either thread group in an IF/ELSE/ENDIF block issue CAL instructions, 1149 these restrictions also apply to the instructions executed in the called 1150 subroutine. 1151 1152 The additional complexities of this tessellation control program flow 1153 control model are not fundamentally incompatible with the simpler flow 1154 control rules above. They are simply intended to provide a useful model 1155 allowing for multiple cooperating threads. In particular, two models are 1156 completely equivalent if there is only number of tessellation control 1157 program threads per patch is one. 1158 1159 1160 (add the following subsections to section 2.X.6 of NV_gpu_program4, 1161 Program Options.) 1162 1163 Section 2.X.6.Y, Tessellation Control Program Options 1164 1165 No options are supported at present for tessellation control programs. 1166 1167 1168 Section 2.X.6.Y, Tessellation Evaluation Program Options 1169 1170 No options are supported at present for tessellation evaluation programs. 1171 1172 1173 (add the following subsections to section 2.X.7 of NV_gpu_program4, 1174 Program Declarations.) 1175 1176 Section 2.X.7.Y, Tessellation Control Program Declarations 1177 1178 Tessellation control programs support one type of declaration statement, 1179 as described below. 1180 1181 - Output Vertex Count (VERTICES_OUT) 1182 1183 The VERTICES_OUT statement declares the number of vertices in the output 1184 patch produced by the tessellation control program, which also specifies 1185 the number of program invocations for each input patch. The single 1186 argument must be a positive integer less than or equal to the value of the 1187 implementation-dependent limit MAX_PATCH_VERTICES_NV. Each program 1188 invocation will have the same inputs except for the built-in input 1189 variable "primitive.invocation". This variable will be an integer between 1190 0 and <n>-1, where <n> is the declared number of invocations. A program 1191 will fail to load unless it contains exactly one VERTICES_OUT declaration. 1192 1193 1194 Section 2.X.7.Y, Tessellation Evaluation Program Declarations 1195 1196 Tessellation evaluation programs support several declaration statements. 1197 Each of these may be included at most in a tessellation evaluation 1198 program. 1199 1200 - Tessellation Primitive Generation Mode (TESS_MODE) 1201 1202 The TESS_MODE statement declares the type of subdivision performed by the 1203 tessellation primitive generator when the tessellation evaluation program, 1204 as described for the TESS_GEN_MODE_NV parameter in Section 2.X.2. The 1205 single argument must be "TRIANGLES", "QUADS", or "ISOLINES". A 1206 tessellation evaluation program will fail to load if it has no primitive 1207 generation mode declaration. 1208 1209 - Tessellation Primitive Spacing (TESS_SPACING) 1210 1211 The TESS_SPACING statement declares the type of spacing the tessellation 1212 primitive generator applies when subdivides primitive edge, as described 1213 for the TESS_GEN_SPACING_NV parameter in Section 2.X.2. The single 1214 argument must be "EQUAL", "FRACTIONAL_ODD", or "FRACTIONAL_EVEN". If a 1215 program omits a spacing declaration, "EQUAL" will be used. 1216 1217 - Tessellation Vertex Order (TESS_VERTEX_ORDER) 1218 1219 The TESS_VERTEX_ORDER statement declares the order of the vertices in the 1220 triangles emitted by the tessellation primitive generator in TRIANGLES or 1221 QUADS mode, as described for the TESS_GEN_VERTEX_ORDER_NV parameter in 1222 Section 2.X.2. The single argument must be "CW" or "CCW". If a program 1223 omits a vertex order declaration, "CCW" will be used. 1224 1225 - Tessellation Point Mode (TESS_POINT_MODE) 1226 1227 The TESS_POINT_MODE statement declares that the tessellation primitive 1228 generator will emit points for each vertex in the subdivided primitive 1229 instead of lines or triangles, as described for the TESS_GEN_POINT_MODE_NV 1230 parameter in Section 2.X.2. The declaration takes no arguments. If a 1231 program omits a point mode declaration, the primitives emitted will be 1232 lines (for ISOLINES mode) or triangles (for TRIANGLES and QUADS mode). 1233 1234 1235Additions to Chapter 3 of the OpenGL 1.5 Specification (Rasterization) 1236 1237 None. 1238 1239Additions to Chapter 4 of the OpenGL 1.5 Specification (Per-Fragment 1240Operations and the Frame Buffer) 1241 1242 None. 1243 1244Additions to Chapter 5 of the OpenGL 1.5 Specification (Special Functions) 1245 1246 None. 1247 1248Additions to Chapter 6 of the OpenGL 1.5 Specification (State and 1249State Requests) 1250 1251 None. 1252 1253Additions to Appendix A of the OpenGL 1.5 Specification (Invariance) 1254 1255 None. 1256 1257Additions to the AGL/GLX/WGL Specifications 1258 1259 None. 1260 1261GLX Protocol 1262 1263 None. 1264 1265Errors 1266 1267 The error INVALID_OPERATION is generated if Begin, or any command that 1268 implicitly calls Begin, is called when tessellation control programs are 1269 enabled and the currently bound tessellation control program object does 1270 not contain a valid program. 1271 1272 The error INVALID_OPERATION is generated if Begin, or any command that 1273 implicitly calls Begin, is called when tessellation evaluation programs 1274 are enabled and the currently bound tessellation evaluation program object 1275 does not contain a valid program. 1276 1277 The error INVALID_OPERATION is generated if Begin, or any command that 1278 implicitly calls Begin, is called when tessellation control programs are 1279 enabled and <mode> is not PATCHES_NV. 1280 1281 The error INVALID_OPERATION is generated if Begin, or any command that 1282 implicitly calls Begin, is called when tessellation evaluation programs 1283 are enabled and <mode> is not PATCHES_NV. 1284 1285New State 1286 1287 (Modify ARB_vertex_program, Table X.6 -- Program State) 1288 1289 Initial 1290 Get Value Type Get Command Value Description Sec. Attribute 1291 ------------------------- ---- ----------- ------- ------------------------ ------ --------- 1292 TESS_CONTROL_PROGRAM_NV B IsEnabled FALSE Tessellation control 2.14.6 enable 1293 program enable 1294 TESS_EVALUATION_PROGRAM_NV B IsEnabled FALSE Tess. evaluation 2.14.6 enable 1295 program enable 1296 1297 TESS_CONTROL_PROGRAM_ Z+ GetIntegerv 0 Active tess control 2.14.1 - 1298 PARAMETER_BUFFER_NV program buffer object 1299 binding 1300 TESS_CONTROL_PROGRAM_ nxZ+ GetInteger- 0 Buffer objects bound for 2.14.1 - 1301 PARAMETER_BUFFER_NV IndexedvEXT tess. control program use 1302 1303 TESS_EVALUATION_PROGRAM_ Z+ GetIntegerv 0 Active tess evaluation 2.14.1 - 1304 PARAMETER_BUFFER_NV program buffer object 1305 binding 1306 TESS_EVALUATION_PROGRAM_ nxZ+ GetInteger- 0 Buffer objects bound for 2.14.1 - 1307 PARAMETER_BUFFER_NV IndexedvEXT tess. eval. program use 1308 1309 1310 Additionally, some tessellation-related state applicable to this extension 1311 is added by ARB_tessellation_shader. 1312 1313New Implementation Dependent State 1314 1315 Minimum 1316 Get Value Type Get Command Value Description Sec. Attrib 1317 -------------------------------- ---- --------------- ------- ----------------------- -------- ------ 1318 MAX_PROGRAM_PATCH_ATTRIBS_NV Z+ GetProgramivARB 30 number of generic patch 2.X.3.2 - 1319 attribute vectors 1320 supported 1321 1322 Additionally, some tessellation-related state applicable to this extension 1323 is added by ARB_tessellation_shader. 1324 1325 1326Dependencies on ARB_tessellation_shader 1327 1328 This spec incorporates the text of ARB_tessellation_shader in its 1329 entirety. If ARB_tessellation_shader is not supported, language 1330 documenting GLSL tessellation control and evaluation shaders should be 1331 removed; tessellation would be available only using the assembly 1332 interface. Language describing the operation of patch primitives and the 1333 tessellation primitive generator would be retained. 1334 1335Dependencies on NV_parameter_buffer_object 1336 1337 The NV_parameter_buffer_object (PaBO) extension provides the ability to 1338 bind buffer objects to be read by vertex, geometry, and fragment programs. 1339 1340 If NV_parameter_buffer_object is supported, this extension adds the 1341 ability to bind buffer objects to be accessed by tessellation control and 1342 evaluation programs. The NV_parameter_buffer_object should be modified to 1343 accept the enums TESS_CONTROL_PROGRAM_PARAMETER_BUFFER_NV and 1344 TESS_EVALUATION_PROGRAM_PARAMETER_BUFFER_NV where the three previously 1345 defined enums (for vertex, geometry, and fragment programs) are accepted. 1346 1347 If NV_parameter_buffer_object is not supported, references to the two new 1348 buffer object binding points should be removed. 1349 1350Issues 1351 1352 (1) How does tessellation fit into the existing GL pipeline? 1353 1354 RESOLVED: See issue (1) in the ARB_tessellation_shader specification, 1355 which contains beautifully crafted ASCII art depicting the pipeline. 1356 1357 (2) What other considerations were involved in the design of the 1358 tessellation API? 1359 1360 RESOLVED: Go look at the detailed issues section of the GLSL-based 1361 ARB_tessellation_shader specification. There are a good number of 1362 issues that apply equally to the assembly APIs that won't be duplicated 1363 here. 1364 1365 (3) Should the tessellation-related parameters (e.g., the primitive 1366 decomposition, spacing, vertex orientation) be context state or 1367 provided with the program? If the latter, how should they be 1368 provided. 1369 1370 RESOLVED: We are providing declaration statements to specify each of 1371 these parameters in the tessellation evaluation program. Because they 1372 are part of the program text, they can't be changed independently of the 1373 program. We don't think that limitation is serious, and the same 1374 limitation applies to GLSL shaders (you need to re-link when changing 1375 these parameters). 1376 1377 Putting these declarations in the shader means that it wasn't necessary 1378 to create a new "tessellation parameter" API to set this state. Such an 1379 API would only apply to assembly programs and could be a source of 1380 confusion if developers thought it might apply to GLSL shaders as well. 1381 1382 (4) The programming model for tessellation control programs supports 1383 multiple threads, each providing attributes for a single vertex. But 1384 it also supports the ability to read the per-vertex outputs written by 1385 other threads and to read and write shared per-patch attribute 1386 outputs. The latter capabilities require some sort of synchronization 1387 to ensure consistently ordered reads and writes whenever possible. 1388 How should this be handled? 1389 1390 RESOLVED: We will expose a programming model where we run groups of <N> 1391 parallel threads in lock-step. In this model, all <N> threads 1392 effectively retire one instruction before starting the next. This 1393 execution model provides a simple abstraction, and provides an obvious 1394 instruction order allowing an application to avoid most read-write and 1395 write-write hazards. 1396 1397 There are three places where we have explicitly undefined behavior: 1398 1399 * If flow control diverges in an IF/ELSE/ENDIF block, the relative 1400 order of writes in the "IF" side of the block and those in the 1401 "ELSE" side of the block is undefined. 1402 1403 * If multiple threads write different values to the same per-patch 1404 attribute in the same instruction, the order in which the writes 1405 land is undefined. 1406 1407 * If any single instruction has one thread reading a per-vertex output 1408 or a per-patch attribute and another thread writing the same output, 1409 the order in which the reads and writes land is undefined. 1410 1411 Implementations need not actually run the threads in this manner, as 1412 long as the compiler properly synchronizes threads at the points where 1413 execution order dependencies do occur. Since the NV_gpu_program4 1414 programming model uses structured branching (e.g., IF/ELSE/ENDIF 1415 blocks), the points at which threads may diverge and converge again are 1416 easily identified. We expect that the number of such synchronization 1417 points will be low for most tessellation control programs. 1418 1419 One other approach considered is to limit the flow control model and the 1420 capabilities of the system to result in a minimal number of required 1421 synchronization points. For example, the tessellation control program 1422 might be split into phases where the capabilities of each thread to 1423 access outputs would be limited. For example, one might have a 1424 three-phase model like the following: 1425 1426 Per-Vertex Outputs Per-Patch Outputs 1427 Phase can read? can write? can read? can write? 1428 ----- --------- ---------- --------- ---------- 1429 1 NO YES NO NO 1430 2 YES NO NO YES(a) 1431 3 YES NO YES(a) YES(b) 1432 1433 In this model, there would be two explicit synchronization points -- 1434 between each pair of phases. The limits on access prevent most cases 1435 where conficts could occur (e.g., you can't read any per-vertex outputs 1436 until you're completely done writing all). To further limit conflicts, 1437 per-patch attributes might be divided into two sets -- set (a) can be 1438 written only in phase 2 and read only in phase (3), and set (b) can be 1439 written only in phase 3. 1440 1441 We decided to expose a general model on the grounds that having the 1442 compiler automatically determine possible synchronization points was easy 1443 enough. Optimizing compilers that reorder instructions already have to 1444 deal with this exact type of issue -- they can't move instructions that 1445 write a variable past subsequent instructions that read it. 1446 1447 The programming model adopted for GLSL in ARB_tessellation_shader 1448 similarly has a set of parallel threads running one executable, but it 1449 provides a barrier() call that serves as a synchronization point and can 1450 be used to split shader execution into phases. 1451 1452 Note that while all previous OpenGL programmability extensions exposed a 1453 model of completely independent threads (i.e., one thread can't read the 1454 outputs of another), threads weren't always completely independent! In 1455 fragment programs/shaders, some texture and all partial derivative 1456 built-ins (dFdx, dFdy in GLSL) require screen-space derivatives. If the 1457 quantity used for derivatives is computed by the shader, OpenGL 1458 implementations generally run threads in groups arranged by screen-space 1459 location and approximate derivatives by computing differences of the 1460 inputs between threads. This approach requires the same sort of 1461 automatic synchronization between threads, since derivatives implicitly 1462 read values computed by other threads. 1463 1464 1465Revision History 1466 1467 Rev. Date Author Changes 1468 ---- -------- -------- ----------------------------------------- 1469 3 12/19/11 pbrown Clarify that "primitive.tessouter[n]", 1470 "primitive.tessinner[n]", and "primitive. 1471 patch.attrib[n]" are not available on the input 1472 patch for tessellation control programs. Remove 1473 stray language referring to a non-existent 1474 vector tessellation level. 1475 1476 2 03/22/10 pbrown Rename references to ARB_tessellation_shader 1477 (formerly EXT). Minor other cleanups, including 1478 the issues section. 1479 1480 1 pbrown Internal revisions. 1481 1482