1Name 2 3 NV_geometry_program4 4 5Name Strings 6 7 (none) 8 9Contact 10 11 Pat Brown, NVIDIA Corporation (pbrown 'at' nvidia.com) 12 13Status 14 15 Shipping for GeForce 8 Series (November 2006) 16 17Version 18 19 Last Modified Date: 12/14/09 20 NVIDIA Revision: 13 21 22Number 23 24 323 25 26Dependencies 27 28 OpenGL 1.1 is required. 29 30 This extension is written against the OpenGL 2.0 specification. 31 32 NV_gpu_program4 is required. This extension is supported if 33 "GL_NV_gpu_program4" is found in the extension string. 34 35 EXT_framebuffer_object interacts with this extension. 36 37 EXT_framebuffer_blit interacts with this extension. 38 39 EXT_texture_array interacts with this extension. 40 41 ARB_texture_rectangle trivially affects the definition of this extension. 42 43 EXT_texture_buffer_object trivially affects the definition of this 44 extension. 45 46 NV_primitive_restart trivially affects the definition of this extension. 47 48Overview 49 50 NV_geometry_program4 defines a new type of program available to be run on 51 the GPU, called a geometry program. Geometry programs are run on full 52 primitives after vertices are transformed, but prior to flat shading and 53 clipping. 54 55 A geometry program begins with a single primitive - a point, line, or 56 triangle. Quads and polygons are allowed, but are decomposed into 57 individual triangles prior to geometry program execution. It can read the 58 attributes of any of the vertex in the primitive and use them to generate 59 new primitives. A geometry program has a fixed output primitive type, 60 either a point, a line strip, or a triangle strip. It emits vertices 61 (using the EMIT opcode) to define the output primitive. The attributes of 62 emitted vertices are specified by writing to the same set of result 63 bindings (e.g., "result.position") provided for vertex programs. 64 Additionally, a geometry program can emit multiple disconnected primitives 65 by using the ENDPRIM opcode, which is roughly equivalent to calling End 66 and then Begin again. The primitives emitted by the geometry program are 67 then clipped and then processed like an equivalent OpenGL primitive 68 specified by the application. 69 70 This extension provides four additional primitive types: lines with 71 adjacency, line strips with adjacency, separate triangles with adjacency, 72 and triangle strips with adjacency. Some of the vertices specified in 73 these new primitive types are not part of the ordinary primitives. 74 Instead, they represent neighboring vertices that are adjacent to the two 75 line segment end points (lines/strips) or the three triangle edges 76 (triangles/tstrips). These "adjacency" vertices can be accessed by 77 geometry programs and used to match up the outputs of the geometry program 78 with those of neighboring primitives. 79 80 Additionally, geometry programs allow for layered rendering, where entire 81 three-dimensional, cube map, or array textures (EXT_texture_array) can be 82 bound to the current framebuffer. Geometry programs can use the 83 "result.layer" binding to select a layer or cube map face to render to. 84 Each primitive emitted by such a geometry program is rendered to the layer 85 taken from its provoking vertex. 86 87 Since geometry programs expect a specific input primitive type, an error 88 will occur if the application presents primtives of a different type. For 89 example, if an enabled geometry program expects points, an error will 90 occur at Begin() time, if a primitive mode of TRIANGLES is specified. 91 92New Procedures and Functions 93 94 void ProgramVertexLimitNV(enum target, int limit); 95 96 void FramebufferTextureEXT(enum target, enum attachment, 97 uint texture, int level); 98 void FramebufferTextureLayerEXT(enum target, enum attachment, 99 uint texture, int level, int layer); 100 void FramebufferTextureFaceEXT(enum target, enum attachment, 101 uint texture, int level, enum face); 102 103New Tokens 104 105 Accepted by the <cap> parameter of Disable, Enable, and IsEnabled, by 106 the <pname> parameter of GetBooleanv, GetIntegerv, GetFloatv, and 107 GetDoublev, and by the <target> parameter of ProgramStringARB, 108 BindProgramARB, ProgramEnvParameter4[df][v]ARB, 109 ProgramLocalParameter4[df][v]ARB, GetProgramEnvParameter[df]vARB, 110 GetProgramLocalParameter[df]vARB, GetProgramivARB and 111 GetProgramStringARB: 112 113 GEOMETRY_PROGRAM_NV 0x8C26 114 115 Accepted by the <pname> parameter of GetProgramivARB: 116 117 MAX_PROGRAM_OUTPUT_VERTICES_NV 0x8C27 118 MAX_PROGRAM_TOTAL_OUTPUT_COMPONENTS_NV 0x8C28 119 GEOMETRY_VERTICES_OUT_EXT 0x8DDA 120 GEOMETRY_INPUT_TYPE_EXT 0x8DDB 121 GEOMETRY_OUTPUT_TYPE_EXT 0x8DDC 122 123 Accepted by the <pname> parameter of GetBooleanv, GetIntegerv, GetFloatv, 124 and GetDoublev: 125 126 MAX_GEOMETRY_TEXTURE_IMAGE_UNITS_EXT 0x8C29 127 128 Accepted by the <mode> parameter of Begin, DrawArrays, MultiDrawArrays, 129 DrawElements, MultiDrawElements, and DrawRangeElements: 130 131 LINES_ADJACENCY_EXT 0xA 132 LINE_STRIP_ADJACENCY_EXT 0xB 133 TRIANGLES_ADJACENCY_EXT 0xC 134 TRIANGLE_STRIP_ADJACENCY_EXT 0xD 135 136 Returned by CheckFramebufferStatusEXT: 137 138 FRAMEBUFFER_INCOMPLETE_LAYER_TARGETS_EXT 0x8DA8 139 FRAMEBUFFER_INCOMPLETE_LAYER_COUNT_EXT 0x8DA9 140 141 Accepted by the <pname> parameter of 142 GetFramebufferAttachmentParameterivEXT: 143 144 FRAMEBUFFER_ATTACHMENT_LAYERED_EXT 0x8DA7 145 FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT 0x8CD4 146 147 Accepted by the <cap> parameter of Enable, Disable, and IsEnabled, and by 148 the <pname> parameter of GetIntegerv, GetFloatv, GetDoublev, and 149 GetBooleanv: 150 151 PROGRAM_POINT_SIZE_EXT 0x8642 152 153 (Note: The "EXT" tokens above are shared with the EXT_geometry_shader4 154 extension.) 155 156 (Note: FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER is simply an alias for the 157 FRAMEBUFFER_ATTACHMENT_TEXTURE_3D_ZOFFSET_EXT token provided in 158 EXT_framebuffer_object. This extension generalizes the notion of 159 "<zoffset>" to include layers of an array texture.) 160 161 (Note: PROGRAM_POINT_SIZE_EXT is simply an alias for the 162 VERTEX_PROGRAM_POINT_SIZE token provided in OpenGL 2.0, which is itself an 163 alias for VERTEX_PROGRAM_POINT_SIZE_ARB provided by ARB_vertex_program. 164 Program-computed point sizes can be enabled if geometry programs are 165 enabled, even if no vertex program is used.) 166 167Additions to Chapter 2 of the OpenGL 1.5 Specification (OpenGL Operation) 168 169 Modify Section 2.6.1 (Begin and End Objects), p. 13 170 171 (Add to end of section, p. 18) 172 173 (add figure) 174 175 1 - - - 2----->3 - - - 4 1 - - - 2--->3--->4--->5 - - - 6 176 177 5 - - - 6----->7 - - - 8 178 179 (a) (b) 180 181 Figure X.1 (a) Lines with adjacency, (b) Line strip with adjacency. 182 The vertices connected with solid lines belong to the main primitives; 183 the vertices connected by dashed lines are the adjacent vertices that 184 may be used in a geometry program. 185 186 Lines with Adjacency 187 188 Lines with adjacency are independent line segments where each endpoint has 189 a corresponding "adjacent" vertex that can be accessed by a geometry 190 program (Section 2.15). If geometry programs are disabled, the "adjacent" 191 vertices are ignored. 192 193 A line segment is drawn from the 4i + 2nd vertex to the 4i + 3rd vertex 194 for each i = 0, 1, ... , n-1, where there are 4n+k vertices between the 195 Begin and End. k is either 0, 1, 2, or 3; if k is not zero, the final k 196 vertices are ignored. For line segment i, the 4i + 1st and 4i + 4th 197 vertices are considered adjacent to the 4i + 2nd and 4i + 3rd vertices, 198 respectively. See Figure X.1. 199 200 Lines with adjacency are generated by calling Begin with the argument 201 value LINES_ADJACENCY_EXT. 202 203 Line Strips with Adjacency 204 205 Line strips with adjacency are similar to line strips, except that each 206 line segment has a pair of adjacent vertices that can be accessed by 207 geometry programs (Section 2.15). If geometry programs are disabled, the 208 "adjacent" vertices are ignored. 209 210 A line segment is drawn from the i + 2nd vertex to the i + 3rd vertex for 211 each i = 0, 1, ..., n-1, where there are n+3 vertices between the Begin 212 and End. If there are fewer than four vertices between a Begin and End, 213 all vertices are ignored. For line segment i, the i + 1st and i + 4th 214 vertices are considered adjacent to the i + 2nd and i + 3rd vertices, 215 respectively. See Figure X.1. 216 217 Line strips with adjacency are generated by calling Begin with the 218 argument value LINE_STRIP_ADJACENCY_EXT. 219 220 (add figure) 221 2 - - - 3 - - - 4 8 - - - 9 - - - 10 222 ^\ ^\ 223 \ | \ | \ | \ | 224 | \ | \ 225 \ | \ | \ | \ | 226 | \ | \ 227 \ | \ | \ | \ | 228 | v | v 229 1<------5 7<------11 230 231 \ | \ | 232 233 \ | \ | 234 235 \ | \ | 236 237 6 12 238 239 Figure X.2 Triangles with adjacency. The vertices connected with solid 240 lines belong to the main primitive; the vertices connected by dashed 241 lines are the adjacent vertices that may be used in a geometry program. 242 243 Triangles with Adjacency 244 245 Triangles with adjacency are similar to separate triangles, except that 246 each triangle edge has an adjacent vertex that can be accessed by geometry 247 programs (Section 2.15). If geometry programs are disabled, the 248 "adjacent" vertices are ignored. 249 250 The 6i + 1st, 6i + 3rd, and 6i + 5th vertices (in that order) determine a 251 triangle for each i = 0, 1, ..., n-1, where there are 6n+k vertices 252 between the Begin and End. k is either 0, 1, 2, 3, 4, or 5; if k is 253 non-zero, the final k vertices are ignored. For triangle i, the i + 2nd, 254 i + 4th, and i + 6th vertices are considered adjacent to edges from the i 255 + 1st to the i + 3rd, from the i + 3rd to the i + 5th, and from the i + 256 5th to the i + 1st vertices, respectively. See Figure X.2. 257 258 Triangles with adjacency are generated by calling Begin with the argument 259 value TRIANGLES_ADJACENCY_EXT. 260 261 (add figure) 262 6 6 263 264 | \ | \ 265 266 | \ | \ 267 268 | \ | \ 269 270 2 - - - 3- - - >6 2 - - - 3------>7 2 - - - 3------>7- - - 10 271 ^\ ^^ | ^^ ^^ | 272 \ | \ | \ | \ | \ \ | \ | \ 273 | \ | \ | | \ | \ | 274 \ | \ | \ | \ | \ \ | \ | \ 275 | \ | \ | | \ | \ | 276 \ | \ | \ | \ | \ \ | \ | \ 277 | v | vv | vv v| 278 1<------5 1<------5 - - - 8 1<------5<------9 279 280 \ | \ | \ | \ | 281 282 \ | \ | \ | \ | 283 284 \ | \ | \ | \ | 285 286 4 4 4 8 287 288 289 6 10 290 291 | \ | \ 292 293 | \ | \ 294 295 | \ | \ 296 2 - - - 3------>7------>11 297 ^^ ^^ | 298 \ | \ | \ | \ 299 | \ | \ | 300 \ | \ | \ | \ 301 | \ | \ | 302 \ | \ | \ | \ 303 | vv vv 304 1<------5<------9 - - - 12 305 306 \ | \ | 307 308 \ | \ | 309 310 \ | \ | 311 312 4 8 313 314 Figure X.3 Triangle strips with adjacency. The vertices connected with 315 solid lines belong to the main primitives; the vertices connected by 316 dashed lines are the adjacent vertices that may be used in a geometry 317 program. 318 319 Triangle Strips with Adjacency 320 321 Triangle strips with adjacency are similar to triangle strips, except that 322 each triangle edge has an adjacent vertex that can be accessed by geometry 323 programs (Section 2.15). If geometry programs are disabled, the 324 "adjacent" vertices are ignored. 325 326 In triangle strips with adjacency, n triangles are drawn using 2 * (n+2) + 327 k vertices between the Begin and End. k is either 0 or 1; if k is 1, the 328 final vertex is ignored. If fewer than 6 vertices are specified between 329 the Begin and End, the entire primitive is ignored. Table X.1 describes 330 the vertices and order used to draw each triangle, and which vertices are 331 considered adjacent to each edge of the triangle. See Figure X.3. 332 333 (add table) 334 primitive adjacent 335 vertices vertices 336 primitive 1st 2nd 3rd 1/2 2/3 3/1 337 --------------- ---- ---- ---- ---- ---- ---- 338 only (i==0, n==1) 1 3 5 2 6 4 339 first (i==0) 1 3 5 2 7 4 340 middle (i odd) 2i+3 2i+1 2i+5 2i-1 2i+4 2i+7 341 middle (i even) 2i+1 2i+3 2i+5 2i-1 2i+7 2i+4 342 last (i==n-1, i odd) 2i+3 2i+1 2i+5 2i-1 2i+4 2i+6 343 last (i==n-1, i even) 2i+1 2i+3 2i+5 2i-1 2i+6 2i+4 344 345 Table X.1: Triangles generated by triangle strips with adjacency. 346 Each triangle is drawn using the vertices in the "1st", "2nd", and "3rd" 347 columns under "primitive vertices", in that order. The vertices in the 348 "1/2", "2/3", and "3/1" columns under "adjacent vertices" are considered 349 adjacent to the edges from the first to the second, from the second to 350 the third, and from the third to the first vertex of the triangle, 351 respectively. The six rows correspond to the six cases: the first and 352 only triangle (i=0, n=1), the first triangle of several (i=0, n>0), 353 "odd" middle triangles (i=1,3,5...), "even" middle triangles 354 (i=2,4,6,...), and special cases for the last triangle inside the 355 Begin/End, when i is either even or odd. For the purposes of this 356 table, the first vertex specified after Begin is numbered "1" and the 357 first triangle is numbered "0". 358 359 Triangle strips with adjacency are generated by calling Begin with the 360 argument value TRIANGLE_STRIP_ADJACENCY_EXT. 361 362 Modify Section 2.14.1, Lighting (p. 59) 363 364 (modify fourth paragraph, p. 63) Additionally, vertex and geometry shaders 365 and programs can operate in two-sided color mode, which is enabled and 366 disabled by calling Enable or Disable with the symbolic value 367 VERTEX_PROGRAM_TWO_SIDE. When a vertex or geometry shader is active, the 368 shaders can write front and back color values to the gl_FrontColor, 369 gl_BackColor, gl_FrontSecondaryColor and gl_BackSecondaryColor outputs. 370 When a vertex or geometry program is active, programs can write front and 371 back colors using the available color result bindings. When a vertex or 372 geometry shader or program is active and two-sided color mode is enabled, 373 the GL chooses between front and back colors, as described below. If 374 two-sided color mode is disabled, the front color output is always 375 selected. 376 377 Insert New Section 2.14.6, Geometry Programs (between 2.14.5, Color Index 378 Lighting and 2.14.6, Clamping and Masking, p. 69) 379 380 Section 2.14.6, Geometry Programs 381 382 Each primitive may be optionally transformed by a geometry program. 383 Geometry programs are enabled by calling Enable with the value 384 GEOMETRY_PROGRAM_NV. A geometry program takes a single input primitive 385 and generates vertices to be arranged into one or more output primitives. 386 The original input primitive is discarded, and the output primitives are 387 processed in order by the remainder of the GL pipeline. 388 389 Section 2.14.6.1, Geometry Program Input Primitives 390 391 A geometry program can operate on one of five input primitive types, as 392 specified by the mandatory "PRIMITIVE_IN" declaration. Depending on the 393 input primitive type, one to six vertices are available when the program 394 is executed. A geometry program will fail to load unless it contains 395 exactly one such declaration. 396 397 Each input primitive type supports only a subset of the primitives 398 provided by the GL. If geometry programs are enabled, Begin, or any 399 function that implicitly calls Begin, will produce an INVALID_OPERATION 400 error if the <mode> parameter is incompatible with the input primitive 401 type of the current geometry program. 402 403 The supported input primitive types are: 404 405 Points (POINTS) 406 407 Geometry programs that operate on points are valid only for the POINTS 408 primitive type. There is a only a single vertex available for each 409 program invocation: "vertex[0]" refers to the single point. 410 411 Lines (LINES) 412 413 Geometry programs that operate on line segments are valid only for the 414 LINES, LINE_STRIP, and LINE_LOOP primitive types. There are two vertices 415 available for each program invocation: "vertex[0]" and "vertex[1]" refer 416 to the beginning and end of the line segment. 417 418 Lines with Adjacency (LINES_ADJACENCY) 419 420 Geometry programs that operate on line segments with adjacent vertices are 421 valid only for the LINES_ADJACENCY_EXT and LINE_STRIP_ADJACENCY_EXT 422 primitive types. There are four vertices available for each program 423 invocation. "vertex[1]" and "vertex[2]" refer to the beginning and end of 424 the line segment. "vertex[0]" and "vertex[3]" refer to the vertices 425 adjacent to the beginning and end of the line segment, respectively. 426 427 Triangles (TRIANGLES) 428 429 Geometry programs that operate on triangles are valid for the TRIANGLES, 430 TRIANGLE_STRIP, TRIANGLE_FAN, QUADS, QUAD_STRIP, and POLYGON primitive 431 types. 432 433 When used with a geometry program that operates on triangles, QUADS, 434 QUAD_STRIP, and POLYGON primitives are decomposed into triangles in an 435 unspecified, implementation-dependent manner. For convex polygons 436 (already required in the core GL specification), this decomposition 437 satisfies three properties: 438 439 * the collection of triangles fully covers the area of the original 440 primitive, 441 442 * no two triangles in the decomposition overlap, and 443 444 * the orientation of each triangle is consistent with the orientation of 445 the original primitive. 446 447 For such primitives, the program is executed once for each triangle in the 448 decomposition. 449 450 There are three vertices available for each program invocation. 451 "vertex[0]", "vertex[1]", and "vertex[2]", refer to the first, second, and 452 third vertex of the triangle, respectively. 453 454 Triangles with Adjacency (TRIANGLES_ADJACENCY) 455 456 Geometry programs that operate on triangles with adjacent vertices are 457 valid for the TRIANGLES_ADJACENCY_EXT and TRIANGLE_STRIP_ADJACENCY_EXT 458 primitive types. There are six vertices available for each program 459 invocation. "vertex[0]", "vertex[2]", and "vertex[4]" refer to the first, 460 second, and third vertex of the triangle respectively. "vertex[1]", 461 "vertex[3]", and "vertex[5]" refer to the vertices adjacent to the edges 462 from the first to the second vertex, from the second to the third vertex, 463 and from the third to the first vertex, respectively. 464 465 Section 2.14.6.2, Geometry Program Output Primitives 466 467 A geometry program can generate primitives of one of three types, as 468 specified by the mandatory "PRIMITIVE_OUT" declaration. A geometry 469 program will fail to load unless it contains exactly one such declaration. 470 471 The supported output primitive types are points (POINTS), line strips 472 (LINE_STRIP), and triangle strips (TRIANGLE_STRIP). The vertices output 473 by the geometry program are decomposed into points, lines, or triangles 474 based on the output primitive type in the manner described in section 475 2.6.1. 476 477 Section 2.14.6.3, Geometry Program Execution Environment 478 479 Geometry programs execute using the instruction set documented in the 480 GL_NV_gpu_program4 extension specification and in a manner similar to 481 vertex programs. Each vertex attribute access must identify the vertex 482 number being accessed. For example, "vertex[1].position" identifies the 483 transformed position of "vertex[1]" as specified in teh description of the 484 input primitive type. Output vertices are specified by writing to vertex 485 result variables in the same manner as done by vertex programs. 486 487 The special instruction "EMIT" specifies that a vertex is completed. A 488 vertex is added to the current output primitive using the current values 489 of the vertex result variables. The values of any unwritten result 490 variables (or components) are undefined. 491 492 After an EMIT instruction is completed, the current values of all vertex 493 result variables become undefined. If a program wants to ensure that the 494 same result is used for every vertex written by the program, it is 495 necessary to write the corresponding value once per vertex. 496 497 The special instruction "ENDPRIM" specifies that the current output 498 primitive should be completed and a new output primitive should be 499 started. A geometry program starts with an output primitive containing no 500 vertices. When a geometry program terminates, the current output 501 primitive is automatically completed. ENDPRIM has no effect if the 502 geometry program's output primitive type is POINTS. 503 504 When a primitive generated by a geometry program is completed, the 505 vertices added by the EMIT instruction are decomposed into points, lines, 506 or triangles according to the output primitive type in the manner 507 described in Section 2.8.1. The resulting primitives are then clipped and 508 rasterized. If the number of vertices emitted by the geometry program is 509 not sufficient to produce a single primitive, nothing is drawn. 510 511 Like vertex and fragment programs, geometry programs can access textures. 512 The maximum number of texture image units that can be accessed by a 513 geometry program is given by the value of 514 MAX_GEOMETRY_TEXTURE_IMAGE_UNITS_EXT. 515 516 Section 2.14.6.4, Geometry Program Output Limits 517 518 A geometry program may not emit an unlimited number of vertices per 519 invocation. Each geometry program must declare a vertex limit, which is 520 the maximum number of vertices that the program can ever produce. The 521 vertex limit is specified using the "VERTICES_OUT" declaration. A 522 geometry program will fail to load unless it contains exactly one such 523 declaration. 524 525 There are two implementation-dependent limits that limit the total number 526 of vertices that a program can emit. First, the vertex limit may not 527 exceed the value of MAX_PROGRAM_OUTPUT_VERTICES_NV. Second, product of 528 the vertex limit and the number of result variable components written by 529 the program (PROGRAM_RESULT_COMPONENTS_NV, as described in section 2.X.3.5 530 of NV_gpu_program4) may not exceed the value of 531 MAX_PROGRAM_TOTAL_OUTPUT_COMPONENTS_NV. A geometry program will fail to 532 load if its maximum vertex count or maximum total component count exceeds 533 the implementation-dependent limit. The limits may be queried by calling 534 GetProgramiv with a <target> of GEOMETRY_PROGRAM_NV. Note that the 535 maximum number of vertices that a geometry program can emit may be much 536 lower than MAX_PROGRAM_OUTPUT_VERTICES_NV if the program writes a large 537 number of result variable components. 538 539 After a geometry program is compiled, the vertex limit may be changed 540 using the command 541 542 void ProgramVertexLimitNV(enum target, int limit); 543 544 <target> must be GEOMETRY_PROGRAM_NV. <limit> is the new vertex limit, 545 which must satisfy the two rules described above. The error INVALID_VALUE 546 is generated if <limit> is less than or equal to zero, <limit> is greater 547 than or equal to MAX_PROGRAM_OUTPUT_VERTICES_NV, or if the total number of 548 components emitted would exceed MAX_PROGRAM_TOTAL_OUTPUT_COMPONENTS_NV. 549 The error INVALID_OPERATION is generated if the current geometry program 550 has not been successfully loaded. 551 552 When a program executes, the number of vertices it emits should not exceed 553 the vertex limit. Once a geometry program emits a number of vertices 554 equal to the vertex limit, subsequent EMIT instructions may or may not 555 have any effect. 556 557 Modify Section 2.X.2, Program Grammar 558 559 (replace third paragraph) 560 561 Geometry programs are required to begin with the header string 562 "!!NVgp4.0". This header string identifies the subsequent program body as 563 being a geometry program and indicates that it should be parsed according 564 to the base NV_gpu_program4 grammar plus the additions below. Program 565 string parsing begins with the character immediately following the header 566 string. 567 568 (add the following grammar rules to the NV_gpu_program4 base grammar) 569 570 <declSequence> ::= <declaration> <declSequence> 571 572 <instruction> ::= <SpecialInstruction> 573 574 <attribUseV> ::= <attribVarName> <arrayMem> <arrayMem> 575 <swizzleSuffix> 576 577 <attribUseS> ::= <attribVarName> <arrayMem> <arrayMem> 578 <scalarSuffix> 579 580 <attribUseVNS> ::= <attribVarName> <arrayMem> <arrayMem> 581 582 <resultUseW> ::= <resultVarName> <arrayMem> <optWriteMask> 583 | <resultColor> <optWriteMask> 584 | <resultColor> "." <colorType> <optWriteMask> 585 | <resultColor> "." <faceType> <optWriteMask> 586 | <resultColor> "." <faceType> "." <colorType> 587 "." <optWriteMask> 588 589 <resultUseD> ::= <resultColor> 590 | <resultColor> "." <colorType> 591 | <resultMulti> 592 593 <declaration> ::= "PRIMITIVE_IN" <declPrimInType> 594 | "PRIMITIVE_OUT" <declPrimOutType> 595 | "VERTICES_OUT" <int> 596 597 <declPrimInType> ::= "POINTS" 598 | "LINES" 599 | "LINES_ADJACENCY" 600 | "TRIANGLES" 601 | "TRIANGLES_ADJACENCY" 602 603 <declPrimOutType> ::= "POINTS" 604 | "LINE_STRIP" 605 | "TRIANGLE_STRIP" 606 607 <SpecialInstruction> ::= "EMIT" 608 | "ENDPRIM" 609 610 <attribBasic> ::= <vtxPrefix> "position" 611 | <vtxPrefix> "fogcoord" 612 | <vtxPrefix> "pointsize" 613 | <vtxPrefix> "id" 614 | <attribTexCoord> <optArrayMemAbs> 615 | <attribClip> <arrayMemAbs> 616 | <attribGeneric> <arrayMemAbs> 617 | "primitive" "." "id" 618 619 <attribColor> ::= <vtxPrefix> "color" 620 621 <attribMulti> ::= <attribTexCoord> <arrayRange> 622 | <attribClip> <arrayRange> 623 | <attribGeneric> <arrayRange> 624 625 <attribTexCoord> ::= <vtxPrefix> "texcoord" 626 627 <attribClip> ::= <vtxPrefix> "clip" 628 629 <attribGeneric> ::= <vtxPrefix> "attrib" 630 631 <vtxPrefix> ::= "vertex" <optArrayMemAbs> 632 633 <resultBasic> ::= <resPrefix> "position" 634 | <resPrefix> "fogcoord" 635 | <resPrefix> "pointsize" 636 | <resPrefix> "primid" 637 | <resPrefix> "layer" 638 | <resultTexCoord> <optArrayMemAbs> 639 | <resultClip> <arrayMemAbs> 640 | <resultGeneric> <arrayMemAbs> 641 642 <resultColor> ::= <resPrefix> "color" 643 644 <resultMulti> ::= <resultTexCoord> <arrayRange> 645 | <resultClip> <arrayRange> 646 | <resultGeneric> <arrayRange> 647 648 <resultTexCoord> ::= <resPrefix> "texcoord" 649 650 <resultClip> ::= <resPrefix> "clip" 651 652 <resultGeneric> ::= <resPrefix> "attrib" 653 654 <resPrefix> ::= "result" "." 655 656 (add the following subsection to section 2.X.3.2, Program Attribute 657 Variables) 658 659 Geometry program attribute variables describe the attributes of each 660 transformed vertex accessible to the geometry program. Most attributes 661 correspond to the per-vertex results generated by vertex program execution 662 or fixed-function vertex processing. The "primitive.id" attribute is 663 generated specially, as described below. 664 665 If vertex programs are enabled, attributes will be obtained from the 666 per-vertex outputs of the vertex program used to generate the vertex in 667 question. Geometry program attributes should be read using the same 668 component data type used to write the corresponding vertex program 669 results. The value of any attribute corresponding to a vertex output not 670 written by the vertex program is undefined. 671 672 If vertex programs are disabled, attributes will be obtained from the 673 values computed by fixed-function vertex processing. All attributes, 674 except for the primitive ID should be read as floating-point values in 675 this case. 676 677 Geometry Vertex Binding Components Description 678 ----------------------------- ---------- ---------------------------- 679 vertex[m].position (x,y,z,w) clip coordinates 680 vertex[m].color (r,g,b,a) front primary color 681 vertex[m].color.primary (r,g,b,a) front primary color 682 vertex[m].color.secondary (r,g,b,a) front secondary color 683 vertex[m].color.front (r,g,b,a) front primary color 684 vertex[m].color.front.primary (r,g,b,a) front primary color 685 vertex[m].color.front.secondary (r,g,b,a) front secondary color 686 vertex[m].color.back (r,g,b,a) back primary color 687 vertex[m].color.back.primary (r,g,b,a) back primary color 688 vertex[m].color.back.secondary (r,g,b,a) back secondary color 689 vertex[m].fogcoord (f,-,-,-) fog coordinate 690 vertex[m].pointsize (s,-,-,-) point size 691 vertex[m].texcoord (s,t,r,q) texture coordinate, unit 0 692 vertex[m].texcoord[n] (s,t,r,q) texture coordinate, unit n 693 vertex[m].attrib[n] (x,y,z,w) generic interpolant n 694 vertex[m].clip[n] (d,-,-,-) clip plane distance 695 vertex[m].texcoord[n..o] (s,t,r,q) array of texture coordinates 696 vertex[m].attrib[n..o] (x,y,z,w) array of generic interpolants 697 vertex[m].clip[n..o] (d,-,-,-) array of clip distances 698 vertex[m].id (id,-,-,-) vertex id 699 primitive.id (id,-,-,-) primitive number 700 701 Table X.2, Geometry Program Attribute Bindings. <m> refers to a vertex 702 number, while <n>, and <o> refer to integer constants. Only the 703 "vertex[m].texcoord" and "vertex.attrib" bindings are available in 704 arrays. 705 706 For bindings that include "vertex[m]", <m> identifies the vertex number 707 whose attributes are used for the binding. For bindings in explicit 708 variable declarations, "[m]" is optional. If "[m]" is specified, <m> must 709 be an integer constant and must be in the valid range of vertices 710 supported for the input primitive type. If "[m]" is not specified, the 711 declared variable is accessed as an array, with the first array index 712 specifying the vertex number. If such a variable is declared an array, it 713 must have a second array index to identify the individual array element. 714 For bindings used directly in instructions, "[m]" is required and must be 715 an integer constant specifying a vertex number. The following examples 716 illustrate various legal and illegal geometry program bindings and their 717 meanings. 718 719 ATTRIB pos = vertex.position; 720 ATTRIB pos2 = vertex[2].position; 721 ATTRIB texcoords[] = { vertex.texcoord[0..3] }; 722 ATTRIB tcoords1[4] = { vertex[1].texcoord[1..4] }; 723 INT TEMP A0; 724 ... 725 MOV R0, pos[1]; # position of vertex 1 726 MOV R0, vertex[1].position; # position of vertex 1 727 MOV R0, pos2; # position of vertex 2 728 MOV R0, texcoords[A0.x][1]; # texcoord 1 of vertex A0.x 729 MOV R0, texcoords[A0.x][A0.y]; # texcoord A0.y of vertex A0.x 730 MOV R0, tcoords1[2]; # texcoord 3 of vertex 1 731 MOV R0, vertex[A0.x].texcoord[1]; # ILLEGAL allowed -- vertex number 732 # must be constant here. 733 734 If a geometry attribute binding matches "vertex[m].position", the "x", 735 "y", "z" and "w" components of the geometry attribute variable are filled 736 with the "x", "y", "z", and "w" components, respectively, of the 737 transformed position of vertex <m>, in clip coordinates. 738 739 If a geometry attribute binding matches any binding in Table X.2 beginning 740 with "vertex[m].color", the "x", "y", "z", and "w" components of the 741 geometry attribute variable are filled with the "r", "g", "b", and "a" 742 components, respectively, of the corresponding color of vertex <m>. 743 Bindings containing "front" and "back" refer to the front and back colors, 744 respectively. Bindings containing "primary" and "secondary" refer to 745 primary and secondary colors, respectively. If face or color type is 746 omitted in the binding, the binding is treated as though "front" and 747 "primary", respectively, were specified. 748 749 If a geometry attribute binding matches "vertex[m].fogcoord", the "x" 750 component of the geometry attribute variable is filled with the fog 751 coordinate of vertex <m>. The "y", "z", and "w" components are undefined. 752 753 If a geometry attribute binding matches "vertex[m].pointsize", the "x" 754 component of the geometry attribute variable is filled with the point size 755 of vertex <m> computed by the vertex program. For fixed-function vertex 756 processing, the point size attribute is undefined. The "y", "z", and "w" 757 components are always undefined. 758 759 If a geometry attribute binding matches "vertex[m].texcoord" or 760 "vertex[m].texcoord[n]", the "x", "y", "z", and "w" coordinates of the 761 geometry attribute variable are filled with the "s", "t", "r", and "q" 762 coordinates of texture coordinate set <n> of vertex <m>. If <n> is 763 omitted, texture coordinate set zero is used. 764 765 If a geometry attribute binding matches "vertex[m].attrib[n]", the "x", 766 "y", "z", and "w" components of the geometry attribute variable are filled 767 with the "x", "y", "z", and "w" coordinates of generic interpolant <n> of 768 vertex <m>. All generic interpolants will be undefined when used with 769 fixed-function vertex processing. 770 771 If a geometry attribute binding matches "vertex[m].clip[n]", the "x" 772 component of the geometry attribute variable is filled the clip distance 773 of vertex <m> for clip plane <n>, as written by the vertex program. If 774 fixed-function vertex processing or position-invariant vertex programs are 775 used, the clip distance is obtained by computing the per-clip plane dot 776 product: 777 778 (p_1' p_2' p_3' p_4') dot (x_e y_e z_e w_e), 779 780 at the vertex location, as described in section 2.12. The clip distance 781 for clip plane <n> is undefined if clip plane <n> is disabled. The "y", 782 "z", and "w" components of the attribute are undefined. 783 784 If a geometry attribute binding matches "vertex[m].texcoord[n..o]", 785 "vertex[m].attrib[n..o]", or "vertex[m].clip[n..o]", a sequence of 786 1+<o>-<n> texture coordinate bindings is created. For texture coordinate 787 bindings, it is as though the sequence "vertex[m].texcoord[n], 788 vertex[m].texcoord[n+1], ... vertex[m].texcoord[o]" were specfied. These 789 bindings are available only in explicit declarations of array variables. 790 A program will fail to load if <n> is greater than <o>. 791 792 If a geometry attribute binding matches "vertex[m].id", the "x" component 793 is filled with the vertex ID. If a vertex program is currently active, 794 the attribute variable is filled with the vertex ID result written by the 795 vertex program. If fixed-function vertex processing is used, the vertex 796 ID is undefined. The "y", "z", and "w" components of the attribute are 797 undefined. 798 799 If a geometry attribute binding matches "primitive.id", the "x" component 800 is filled with the number of primitives received by the GL since the last 801 time Begin was called (directly or indirectly via vertex array functions). 802 The first primitive generated after a Begin is numbered zero, and the 803 primitive ID counter is incremented after every individual point, line, or 804 polygon primitive is processed. For QUADS and QUAD_STRIP primitives that 805 are decomposed into triangles, the primitive ID is incremented after each 806 complete quad is processed. For POLYGON primitives, the primitive ID 807 counter is zero. Restarting a primitive topology using the primitive 808 restart index has no effect on the primitive ID counter. The "y", "z", 809 and "w" components of the variable are always undefined. 810 811 (add the following subsection to section 2.X.3.5, Program Results.) 812 813 Geometry programs emit vertices, and the set of result variables available 814 to such programs correspond to the attributes of each emitted vertex. The 815 set of allowable result variable bindings for geometry programs is given 816 in Table X.3. 817 818 Binding Components Description 819 ----------------------------- ---------- ---------------------------- 820 result.position (x,y,z,w) position in clip coordinates 821 result.color (r,g,b,a) front-facing primary color 822 result.color.primary (r,g,b,a) front-facing primary color 823 result.color.secondary (r,g,b,a) front-facing secondary color 824 result.color.front (r,g,b,a) front-facing primary color 825 result.color.front.primary (r,g,b,a) front-facing primary color 826 result.color.front.secondary (r,g,b,a) front-facing secondary color 827 result.color.back (r,g,b,a) back-facing primary color 828 result.color.back.primary (r,g,b,a) back-facing primary color 829 result.color.back.secondary (r,g,b,a) back-facing secondary color 830 result.fogcoord (f,*,*,*) fog coordinate 831 result.pointsize (s,*,*,*) point size 832 result.texcoord (s,t,r,q) texture coordinate, unit 0 833 result.texcoord[n] (s,t,r,q) texture coordinate, unit n 834 result.attrib[n] (x,y,z,w) generic interpolant n 835 result.clip[n] (d,*,*,*) clip plane distance 836 result.texcoord[n..o] (s,t,r,q) texture coordinates n thru o 837 result.attrib[n..o] (x,y,z,w) generic interpolants n thru o 838 result.clip[n..o] (d,*,*,*) clip distances n thru o 839 result.primid (id,*,*,*) primitive id 840 result.layer (l,*,*,*) layer for cube/array/3D FBOs 841 842 Table X.3: Geometry Program Result Variable Bindings. 843 Components labeled "*" are unused. 844 845 If a result variable binding matches "result.position", updates to the 846 "x", "y", "z", and "w" components of the result variable modify the "x", 847 "y", "z", and "w" components, respectively, of the transformed vertex's 848 clip coordinates. Final window coordinates will be generated for the 849 vertex as described in section 2.14.4.4. 850 851 If a result variable binding match begins with "result.color", updates to 852 the "x", "y", "z", and "w" components of the result variable modify the 853 "r", "g", "b", and "a" components, respectively, of the corresponding 854 vertex color attribute in Table X.3. Color bindings that do not specify 855 "front" or "back" are consided to refer to front-facing colors. Color 856 bindings that do not specify "primary" or "secondary" are considered to 857 refer to primary colors. 858 859 If a result variable binding matches "result.fogcoord", updates to the "x" 860 component of the result variable set the transformed vertex's fog 861 coordinate. Updates to the "y", "z", and "w" components of the result 862 variable have no effect. 863 864 If a result variable binding matches "result.pointsize", updates to the 865 "x" component of the result variable set the transformed vertex's point 866 size. Updates to the "y", "z", and "w" components of the result variable 867 have no effect. 868 869 If a result variable binding matches "result.texcoord" or 870 "result.texcoord[n]", updates to the "x", "y", "z", and "w" components of 871 the result variable set the "s", "t", "r" and "q" components, 872 respectively, of the transformed vertex's texture coordinates for texture 873 unit <n>. If "[n]" is omitted, texture unit zero is selected. 874 875 If a result variable binding matches "result.attrib[n]", updates to the 876 "x", "y", "z", and "w" components of the result variable set the "x", "y", 877 "z", and "w" components of the generic interpolant <n>. 878 879 If a result variable binding matches "result.clip[n]", updates to the "x" 880 component of the result variable set the clip distance for clip plane <n>. 881 882 If a result variable binding matches "result.texcoord[n..o]", 883 "result.attrib[n..o]", or "result.clip[n..o]", a sequence of 1+<o>-<n> 884 bindings is created. For texture coordinates, it is as though the 885 sequence "result.texcoord[n], result.texcoord[n+1], 886 ... result.texcoord[o]" were specfied. These bindings are available only 887 in explicit declarations of array variables. A program will fail to load 888 if <n> is greater than <o>. 889 890 If a result variable binding matches "result.primid", updates to the "x" 891 component of the result variable provide a single integer that serves as a 892 primitive identifier. The written primitive ID is available to fragment 893 programs using the "primitive.id" attribute binding. If a fragment 894 program using primitive IDs is active and a geometry program is also 895 active, the geometry program must write "result.primid" or the primitive 896 ID number is undefined. 897 898 If a result variable binding matches "result.layer", updates to the "x" 899 component of the result variable provide a single integer that serves as a 900 layer selector for layered rendering (section 2.14.6.5). The layer must 901 be written as an integer value; writing a floating-point layer number will 902 produce undefined results. 903 904 (modify Table X.13 in section 2.X.4, Program Instructions, to include the 905 following.) 906 907 Modifiers 908 Instruction F I C S H D Inputs Out Description 909 ----------- - - - - - - ---------- --- -------------------------------- 910 EMIT - - - - - - - - emit vertex 911 ENDPRIM - - - - - - - - end of primitive 912 913 (add the following subsection to section 2.X.6, Program Options.) 914 915 Section 2.X.6.Y, Geometry Program Options 916 917 No options are supported at present for geometry programs. 918 919 (add the following subsection to section 2.X.7, Program Declarations.) 920 921 Section 2.X.7.Y, Geometry Program Declarations 922 923 Geometry programs support three types of declaration statements, as 924 described below. Each of the three must be included exactly once in the 925 geometry program. 926 927 - Input Primitive Type (PRIMITIVE_IN) 928 929 The PRIMITIVE_IN statement declares the type of primitives seen by a 930 geometry program. The single argument must be one of "POINTS", "LINES", 931 "LINES_ADJACENCY", "TRIANGLES", or "TRIANGLES_ADJACENCY". 932 933 - Output Primitive Type (PRIMITIVE_OUT) 934 935 The PRIMITIVE_OUT statement declares the type of primitive emitted by a 936 geometry program. The single argument must be one of "POINTS", 937 "LINE_STRIP", or "TRIANGLE_STRIP". 938 939 - Maximum Vertex Count (VERTICES_OUT) 940 941 The VERTICES_OUT statement declares the maximum number of vertices that 942 may be emitted by a geometry program. The single argument must be a 943 positive integer. A vertex program that emits more than the specified 944 number of vertices may terminate abnormally. 945 946 (add the following subsections to section 2.X.8, Program Instruction Set.) 947 948 Section 2.X.8.Z, EMIT: Emit Vertex 949 950 The EMIT instruction emits a new vertex to be added to the current output 951 primitive of a geometry program. The attributes of the emitted vertex are 952 given by the current values of the vertex result variables. After the 953 EMIT instruction completes, a new vertex is started and all result 954 variables become undefined. 955 956 Section 2.X.8.Z, ENDPRIM: End of Primitive 957 958 A geometry program can emit multiple primitives in a single invocation. 959 The ENDPRIM instruction is used in a geometry program to signify the end 960 of the current primitive and the beginning of a new primitive of the same 961 type. The effect of ENDPRIM is roughly equivalent to calling End followed 962 by a new Begin, where the primitive mode is specified in the text of the 963 geometry program. 964 965 Like End, the ENDPRIM instruction does not emit a vertex. Any result 966 registers written prior to an ENDPRIM instruction are unchanged, and will 967 be used in the vertex specified by the next EMIT instruction if they are 968 not overwritten first. 969 970 When geometry program execution completes, the current primitive is 971 automatically terminated. It is not necessary to include an ENDPRIM 972 instruction if the geometry program writes only a single primitive. 973 974Additions to Chapter 3 of the OpenGL 1.5 Specification (Rasterization) 975 976 Modify Section 3.3, Points (p. 95) 977 978 (replace all Section 3.3 text on p. 95) A point is drawn by generating a 979 set of fragments in the shape of a square or circle centered around the 980 vertex of the point. Each vertex has an associated point size that 981 controls the size of that square or circle. 982 983 If no vertex or geometry program is active, the size of the point is 984 controlled by 985 986 void PointSize(float size); 987 988 <size> specifies the requested size of a point. The default value is 989 1.0. A value less than or equal to zero results in the error 990 INVALID_VALUE. 991 992 The requested point size is multiplied with a distance attenuation factor, 993 clamped to a specified point size range, and further clamped to the 994 implementation-dependent point size range to produce the derived point 995 size: 996 997 derived size = clamp(size * sqrt(1/(a+b*d+c*d^2))) 998 999 where d is the eye-coordinate distance from the eye, (0,0,0,1) in eye 1000 coordinates, to the vertex, and a, b, and c are distance attenuation 1001 function coefficients. 1002 1003 If a vertex or geometry program is active, the derived size depends on the 1004 per-vertex point size mode enable. Per-vertex point size mode is enabled 1005 or disabled by calling Enable or Disable with the symbolic value 1006 PROGRAM_POINT_SIZE_EXT. If per-vertex point size is enabled and a geometry 1007 program is active, the point size is taken from the point size emitted by 1008 the geometry program. If per-vertex point size is enabled an no geometry 1009 program is active, the point size is taken from the point size result of 1010 the vertex program. Otherwise, the point size is taken from the <size> 1011 value provided to PointSize, with no distance attenuation applied. In all 1012 cases, the point size is clamped to the implementation-dependent point 1013 size range. 1014 1015 If multisampling is not enabled, the derived size is passed on to 1016 rasterization as the point width. ... 1017 1018Additions to Chapter 4 of the OpenGL 1.5 Specification (Per-Fragment 1019Operations and the Frame Buffer) 1020 1021 None. 1022 1023Additions to Chapter 5 of the OpenGL 1.5 Specification (Special Functions) 1024 1025 None. 1026 1027Additions to Chapter 6 of the OpenGL 1.5 Specification (State and 1028State Requests) 1029 1030 None. 1031 1032Additions to Appendix A of the OpenGL 1.5 Specification (Invariance) 1033 1034 None. 1035 1036Additions to the AGL/GLX/WGL Specifications 1037 1038 None. 1039 1040GLX Protocol 1041 1042 The following rendering commands are sent to the server as part of a 1043 glXRender request: 1044 1045 ProgramVertexLimitNV 1046 1047 2 12 rendering command length 1048 2 4312 rendering command opcode 1049 4 ENUM target 1050 4 INT32 limit 1051 1052 1053 The extension EXT_geometry_shader4 defines GLX protocol for 1054 the following non-rendering commands: 1055 1056 FramebufferTextureEXT, FramebufferTextureLayerEXT, 1057 FramebufferTextureFaceEXT. 1058 1059Errors 1060 1061 The error INVALID_OPERATION is generated if Begin, or any command that 1062 implicitly calls Begin, is called when geometry program mode is enabled 1063 and the currently bound geometry program object does not contain a valid 1064 geometry program. 1065 1066 The error INVALID_OPERATION is generated if Begin, or any command that 1067 implicitly calls Begin, is called when geometry program mode is enabled 1068 and: 1069 1070 * the input primitive type of the current geometry program is POINTS and 1071 <mode> is not POINTS, 1072 1073 * the input primitive type of the current geometry program is LINES and 1074 <mode> is not LINES, LINE_STRIP, or LINE_LOOP, 1075 1076 * the input primitive type of the current geometry program is TRIANGLES 1077 and <mode> is not TRIANGLES, TRIANGLE_STRIP, TRIANGLE_FAN, QUADS, 1078 QUAD_STRIP, or POLYGON, 1079 1080 * the input primitive type of the current geometry program is 1081 LINES_ADJACENCY and <mode> is not LINES_ADJACENCY_EXT or 1082 LINE_STRIP_ADJACENCY_EXT, or 1083 1084 * the input primitive type of the current geometry program is 1085 TRIANGLES_ADJACENCY and <mode> is not TRIANGLES_ADJACENCY_EXT or 1086 TRIANGLE_STRIP_ADJACENCY_EXT. 1087 1088 The error INVALID_ENUM is generated if GetProgramivARB is called with a 1089 <pname> of MAX_PROGRAM_OUTPUT_VERTICES_NV or 1090 MAX_PROGRAM_TOTAL_OUTPUT_COMPONENTS_NV and the target isn't 1091 GEOMETRY_PROGRAM_NV. 1092 1093Dependencies on EXT_framebuffer_object 1094 1095 If EXT_framebuffer_object (or similar functionality) is not supported, the 1096 "result.layer" binding should be removed. "FramebufferTextureEXT" and 1097 "FramebufferTextureLayerEXT" should be removed from "New Procedures and 1098 Functions", and FRAMEBUFFER_ATTACHMENT_LAYERED_EXT, 1099 FRAMEBUFFER_INCOMPLETE_LAYER_TARGETS_EXT, and 1100 FRAMEBUFFER_INCOMPLETE_LAYER_COUNT_EXT should be removed from "New 1101 Tokens". 1102 1103 Otherwise, this extension modifies EXT_framebuffer_object to add the 1104 notion of layered framebuffer attachments and framebuffers that can be 1105 used in conjunction with geometry programs to allow programs to direct 1106 primitives to a face of a cube map or layer of a three-dimensional texture 1107 or one- or two-dimensional array texture. The layer used for rendering 1108 can be selected by the geometry program at run time. 1109 1110 (insert before the end of Section 4.4.2, Attaching Images to Framebuffer 1111 Objects) 1112 1113 There are several types of framebuffer-attachable images: 1114 1115 * the image of a renderbuffer object, which is always two-dimensional, 1116 1117 * a single level of a one-dimensional texture, which is treated as a 1118 two-dimensional image with a height of one, 1119 1120 * a single level of a two-dimensional or rectangle texture, 1121 1122 * a single face of a cube map texture level, which is treated as a 1123 two-dimensional image, or 1124 1125 * a single layer of a one- or two-dimensional array texture or 1126 three-dimensional texture, which is treated as a two-dimensional 1127 image. 1128 1129 Additionally, an entire level of a three-dimensional texture, cube map 1130 texture, or one- or two-dimensional array texture can be attached to an 1131 attachment point. Such attachments are treated as an array of 1132 two-dimensional images, arranged in layers, and the corresponding 1133 attachment point is considered to be layered. 1134 1135 (replace section 4.4.2.3, "Attaching Texture Images to a Framebuffer") 1136 1137 GL supports copying the rendered contents of the framebuffer into the 1138 images of a texture object through the use of the routines 1139 CopyTexImage{1D|2D}, and CopyTexSubImage{1D|2D|3D}. Additionally, GL 1140 supports rendering directly into the images of a texture object. 1141 1142 To render directly into a texture image, a specified level of a texture 1143 object can be attached as one of the logical buffers of the currently 1144 bound framebuffer object by calling: 1145 1146 void FramebufferTextureEXT(enum target, enum attachment, 1147 uint texture, int level); 1148 1149 <target> must be FRAMEBUFFER_EXT. <attachment> must be one of the 1150 attachment points of the framebuffer listed in table 1.nnn. 1151 1152 If <texture> is zero, any image or array of images attached to the 1153 attachment point named by <attachment> is detached, and the state of the 1154 attachment point is reset to its initial values. <level> is ignored if 1155 <texture> is zero. 1156 1157 If <texture> is non-zero, FramebufferTextureEXT attaches level <level> of 1158 the texture object named <texture> to the framebuffer attachment point 1159 named by <attachment>. The error INVALID_VALUE is generated if <texture> 1160 is not the name of a texture object, or if <level> is not a supported 1161 texture level number for textures of the type corresponding to <target>. 1162 The error INVALID_OPERATION is generated if <texture> is the name of a 1163 buffer texture. 1164 1165 If <texture> is the name of a three-dimensional texture, cube map texture, 1166 or one- or two-dimensional array texture, the texture level attached to 1167 the framebuffer attachment point is an array of images, and the 1168 framebuffer attachment is considered layered. 1169 1170 The command 1171 1172 void FramebufferTextureLayerEXT(enum target, enum attachment, 1173 uint texture, int level, int layer); 1174 1175 operates like FramebufferTextureEXT, except that only a single layer of 1176 the texture level, numbered <layer>, is attached to the attachment point. 1177 If <texture> is non-zero, the error INVALID_VALUE is generated if <layer> 1178 is negative, or if <texture> is not the name of a texture object. The 1179 error INVALID_OPERATION is generated unless <texture> is zero or the name 1180 of a three-dimensional or one- or two-dimensional array texture. 1181 1182 The command 1183 1184 void FramebufferTextureFaceEXT(enum target, enum attachment, 1185 uint texture, int level, enum face); 1186 1187 operates like FramebufferTextureEXT, except that only a single face of a 1188 cube map texture, given by <face>, is attached to the attachment point. 1189 <face> is one of TEXTURE_CUBE_MAP_POSITIVE_X, TEXTURE_CUBE_MAP_NEGATIVE_X, 1190 TEXTURE_CUBE_MAP_POSITIVE_Y, TEXTURE_CUBE_MAP_NEGATIVE_Y, 1191 TEXTURE_CUBE_MAP_POSITIVE_Z, TEXTURE_CUBE_MAP_NEGATIVE_Z. If <texture> is 1192 non-zero, the error INVALID_VALUE is generated if <texture> is not the 1193 name of a texture object. The error INVALID_OPERATION is generated unless 1194 <texture> is zero or the name of a cube map texture. 1195 1196 The command 1197 1198 void FramebufferTexture1DEXT(enum target, enum attachment, 1199 enum textarget, uint texture, int level); 1200 1201 operates identically to FramebufferTextureEXT, except for two additional 1202 restrictions. If <texture> is non-zero, the error INVALID_ENUM is 1203 generated if <textarget> is not TEXTURE_1D and the error INVALID_OPERATION 1204 is generated unless <texture> is the name of a one-dimensional texture. 1205 1206 The command 1207 1208 void FramebufferTexture2DEXT(enum target, enum attachment, 1209 enum textarget, uint texture, int level); 1210 1211 operates similarly to FramebufferTextureEXT. If <textarget> is TEXTURE_2D 1212 or TEXTURE_RECTANGLE_ARB, <texture> must be zero or the name of a 1213 two-dimensional or rectangle texture. If <textarget> is 1214 TEXTURE_CUBE_MAP_POSITIVE_X, TEXTURE_CUBE_MAP_NEGATIVE_X, 1215 TEXTURE_CUBE_MAP_POSITIVE_Y, TEXTURE_CUBE_MAP_NEGATIVE_Y, 1216 TEXTURE_CUBE_MAP_POSITIVE_Z, or TEXTURE_CUBE_MAP_NEGATIVE_Z, <texture> 1217 must be zero or the name of a cube map texture. For cube map textures, 1218 only the single face of the cube map texture level given by <textarget> is 1219 attached. The error INVALID_ENUM is generated if <texture> is not zero 1220 and <textarget> is not one of the values enumerated above. The error 1221 INVALID_OPERATION is generated if <texture> is the name of a texture whose 1222 type does not match the texture type required by <textarget>. 1223 1224 The command 1225 1226 void FramebufferTexture3DEXT(enum target, enum attachment, 1227 enum textarget, uint texture, 1228 int level, int zoffset); 1229 1230 behaves identically to FramebufferTextureLayerEXT, with the <layer> 1231 parameter set to the value of <zoffset>. The error INVALID_ENUM is 1232 generated if <textarget> is not TEXTURE_3D. The error INVALID_OPERATION 1233 is generated unless <texture> is zero or the name of a three-dimensional 1234 texture. 1235 1236 For all FramebufferTexture commands, if <texture> is non-zero and the 1237 command does not result in an error, the framebuffer attachment state 1238 corresponding to <attachment> is updated based on the new attachment. 1239 FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE_EXT is set to TEXTURE, 1240 FRAMEBUFFER_ATTACHMENT_OBJECT_NAME_EXT is set to <texture>, and 1241 FRAMEBUFFER_ATTACHMENT_TEXTURE_LEVEL is set to <level>. 1242 FRAMEBUFFER_ATTACHMENT_TEXTURE_CUBE_FACE is set to <textarget> if 1243 FramebufferTexture2DEXT is called and <texture> is the name of a cubemap 1244 texture; otherwise, it is set to TEXTURE_CUBE_MAP_POSITIVE_X. 1245 FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT is set to <layer> or <zoffset> if 1246 FramebufferTextureLayerEXT or FramebufferTexture3DEXT is called; 1247 otherwise, it is set to zero. FRAMEBUFFER_ATTACHMENT_LAYERED_EXT is set 1248 to TRUE if FramebufferTextureEXT is called and <texture> is the name of a 1249 three-dimensional texture, cube map texture, or one- or two-dimensional 1250 array texture; otherwise it is set to FALSE. 1251 1252 (modify Section 4.4.4.1, Framebuffer Attachment Completeness -- add to the 1253 conditions necessary for attachment completeness) 1254 1255 The framebuffer attachment point <attachment> is said to be "framebuffer 1256 attachment complete" if ...: 1257 1258 * If FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE_EXT is TEXTURE and 1259 FRAMEBUFFER_ATTACHMENT_OBJECT_NAME_EXT names a three-dimensional 1260 texture, FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT must be smaller than 1261 the depth of the texture. 1262 1263 * If FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE_EXT is TEXTURE and 1264 FRAMEBUFFER_ATTACHMENT_OBJECT_NAME_EXT names a one- or two-dimensional 1265 array texture, FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT must be 1266 smaller than the number of layers in the texture. 1267 1268 (modify section 4.4.4.2, Framebuffer Completeness -- add to the list of 1269 conditions necessary for completeness) 1270 1271 * If any framebuffer attachment is layered, all populated attachments 1272 must be layered. Additionally, all populated color attachments must 1273 be from textures of the same target (i.e., three-dimensional, cube 1274 map, or one- or two-dimensional array textures). 1275 { FRAMEBUFFER_INCOMPLETE_LAYER_TARGETS_EXT } 1276 1277 * If any framebuffer attachment is layered, all attachments must have 1278 the same layer count. For three-dimensional textures, the layer count 1279 is the depth of the attached volume. For cube map textures, the layer 1280 count is always six. For one- and two-dimensional array textures, the 1281 layer count is simply the number of layers in the array texture. 1282 { FRAMEBUFFER_INCOMPLETE_LAYER_COUNT_EXT } 1283 1284 The enum in { brackets } after each clause of the framebuffer completeness 1285 rules specifies the return value of CheckFramebufferStatusEXT (see below) 1286 that is generated when that clause is violated. ... 1287 1288 (add section 4.4.7, Layered Framebuffers) 1289 1290 A framebuffer is considered to be layered if it is complete and all of its 1291 populated attachments are layered. When rendering to a layered 1292 framebuffer, each fragment generated by the GL is assigned a layer number. 1293 The layer number for a fragment is zero if 1294 1295 * the fragment is generated by DrawPixels, CopyPixels, or Bitmap, 1296 1297 * geometry programs are disabled, or 1298 1299 * the current geometry program does not contain an instruction that 1300 writes to the layer result binding. 1301 1302 Otherwise, the layer for each point, line, or triangle emitted by the 1303 geometry program is taken from the layer output of the provoking vertex. 1304 For line strips, the provoking vertex is the second vertex of each line 1305 segment. For triangle strips, the provoking vertex is the third vertex of 1306 each individual triangles. The per-fragment layer can be different for 1307 fragments generated by each individual point, line, or triangle emitted by 1308 a single geometry program invocation. A layer number written by a 1309 geometry program has no effect if the framebuffer is not layered. 1310 1311 When fragments are written to a layered framebuffer, the fragment's layer 1312 number selects a single image from the array of images at each attachment 1313 point to use for the stencil test (section 4.1.5), depth buffer test 1314 (section 4.1.6), and for blending and color buffer writes (section 4.1.8). 1315 If the fragment's layer number is negative or greater than the number of 1316 layers attached, the effects of the fragment on the framebuffer contents 1317 are undefined. 1318 1319 When the Clear command is used to clear a layered framebuffer attachment, 1320 all layers of the attachment are cleared. 1321 1322 When commands such as ReadPixels or CopyPixels read from a layered 1323 framebuffer, the image at layer zero of the selected attachment is always 1324 used to obtain pixel values. 1325 1326 When cube map texture levels are attached to a layered framebuffer, there 1327 are six layers attached, numbered zero through five. Each layer number is 1328 mapped to a cube map face, as indicated in Table X.4. 1329 1330 layer number cube map face 1331 ------------ --------------------------- 1332 0 TEXTURE_CUBE_MAP_POSITIVE_X 1333 1 TEXTURE_CUBE_MAP_NEGATIVE_X 1334 2 TEXTURE_CUBE_MAP_POSITIVE_Y 1335 3 TEXTURE_CUBE_MAP_NEGATIVE_Y 1336 4 TEXTURE_CUBE_MAP_POSITIVE_Z 1337 5 TEXTURE_CUBE_MAP_NEGATIVE_Z 1338 1339 Table X.4, Layer numbers for cube map texture faces. The layers are 1340 numbered in the same sequence as the cube map face token values. 1341 1342 (modify Section 6.1.3, Enumerated Queries -- Modify/add to list of <pname> 1343 values for GetFramebufferAttachmentParameterivEXT if 1344 FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE_EXT is TEXTURE) 1345 1346 If <pname> is FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT and the attached 1347 image is a layer of a three-dimensional texture or one- or 1348 two-dimensional array texture, then <params> will contain the specified 1349 layer number. Otherwise, <params> will contain the value zero. 1350 1351 If <pname> is FRAMEBUFFER_ATTACHMENT_LAYERED_EXT, then <params> will 1352 contain TRUE if an entire level of a three-dimesional texture, cube map 1353 texture, or one- or two-dimensional array texture is attached to the 1354 <attachment>. Otherwise, <params> will contain FALSE. 1355 1356 (Modify the Additions to Chapter 5, section 5.4) 1357 1358 Add the commands FramebufferTextureEXT, FramebufferTextureLayerEXT, and 1359 FramebufferTextureFaceEXT to the list of commands that are not compiled 1360 into a display list, but executed immediately. 1361 1362Dependencies on EXT_framebuffer_blit 1363 1364 If EXT_framebuffer_blit is supported, the EXT_framebuffer_object language 1365 should be further amended so that <target> values passed to 1366 FramebufferTextureEXT and FramebufferTextureLayerEXT can be 1367 DRAW_FRAMEBUFFER_EXT or READ_FRAMEBUFFER_EXT, and that those functions 1368 set/query state for the draw framebuffer if <target> is FRAMEBUFFER_EXT. 1369 1370 If BlitFramebufferEXT() is called with a layered read framebuffer, pixel 1371 values are obtained from layer zero from the read framebuffer. If the 1372 draw framebuffer is layered, pixel values are written to layer zero of the 1373 draw framebuffer. If both framebuffers are layered, the two-dimensional 1374 blit operation is still performed only on layer zero. 1375 1376Dependencies on EXT_texture_array 1377 1378 If EXT_texture_array is not supported, the discussion array textures the 1379 layered rendering edits to EXT_framebuffer_object should be removed. 1380 Layered rendering to cube map and 3D textures would still be supported. 1381 1382 If EXT_texture_array is supported, the edits to EXT_framebuffer_object 1383 supersede those made in EXT_texture_array, except for language pertaining 1384 to mipmap generation of array textures. 1385 1386 There are no functional incompatibilities between the FBO support in these 1387 two specifications. The only differences are that this extension supports 1388 layered rendering and also rewrites certain sections of the core FBO 1389 specification more aggressively. 1390 1391Dependencies on ARB_texture_rectangle 1392 1393 If ARB_texture_rectangle is not supported, all references to rectangle 1394 textures in the EXT_framebuffer_object spec language should be removed. 1395 1396Dependencies on EXT_texture_buffer_object 1397 1398 If EXT_buffer_object is not supported, the reference to an 1399 INVALID_OPERATION error if a buffer texture is passed to 1400 FramebufferTextureEXT should be removed. 1401 1402Dependencies on NV_primitive_restart 1403 1404 The spec describes the behavior that primitive restart does not affect the 1405 primitive ID counter, including for POLYGON primitives (where one could 1406 argue that the restart index starts a new primitive without a new Begin to 1407 reset the count). If NV_primitive_restart is not supported, references to 1408 that extension in the discussion of the "primitive.id" attribute should be 1409 removed. 1410 1411New State 1412 Initial 1413 Get Value Type Get Command Value Description Sec. Attribute 1414 ------------------------- ---- ----------- ------- ---------------------- ------ --------- 1415 GEOMETRY_PROGRAM_NV B IsEnabled FALSE Geometry shader enable 2.14.6 enable 1416 FRAMEBUFFER_ATTACHMENT_ nxB GetFramebuffer- FALSE Framebuffer attachment 4.4.2.3 - 1417 LAYERED_EXT Attachment- is layered 1418 ParameterivEXT 1419 GEOMETRY_VERTICES_OUT_EXT Z+ GetProgramivARB 0 vertex limit of the 2.14.6.4 - 1420 current geometry 1421 program 1422 GEOMETRY_INPUT_TYPE_EXT Z+ GetProgramivARB 0 input primitive type 2.14.6.4 - 1423 of the current geometry 1424 program 1425 GEOMETRY_OUTPUT_TYPE_EXT Z+ GetProgramivARB 0 output primitive type 2.14.6.4 - 1426 of the current geometry 1427 program 1428 1429New Implementation Dependent State 1430 1431 Minimum 1432 Get Value Type Get Command Value Description Sec Attrib 1433 ------------------------------- ---- --------------- ---------- -------------------- ------------ ------ 1434 MAX_GEOMETRY_TEXTURE_ Z+ GetIntegerv 16 maximum number of 2.14.6.3 - 1435 IMAGE_UNITS_EXT texture image units 1436 accessible in a 1437 geometry program 1438 MAX_PROGRAM_OUTPUT_VERTICES_NV Z+ GetProgramivARB 256 maximum number of 2.14.6.4 - 1439 vertices that any 1440 geometry program 1441 could emit 1442 MAX_PROGRAM_TOTAL_OUTPUT_ Z+ GetProgramivARB 1024 maximum number of 2.14.6.4 - 1443 COMPONENTS_NV result components (all 1444 vertices) that a 1445 geometry program 1446 can emit 1447 1448 1449NVIDIA Implementation Details 1450 1451 Because of a hardware limitation, some GeForce 8 series chips use the 1452 odd vertex of an incomplete TRIANGLE_STRIP_ADJACENCY_EXT primitive 1453 as a replacement adjacency vertex rather than ignoring it. 1454 1455Issues 1456 1457 (1) How do geometry programs fit into the existing GL pipeline? 1458 1459 RESOLVED: The following diagram illustrates how geometry programs fit 1460 into the "vertex processing" portion of the GL (Chapter 2 of the OpenGL 1461 2.0 Specification). 1462 1463 First, vertex attributes are specified via immediate-mode commands or 1464 through vertex arrays. They can be conventional attributes (e.g., 1465 glVertex, glColor, glTexCoord) or generic (numbered) attributes. 1466 1467 Vertices are then transformed, either using a vertex program or 1468 fixed-function vertex processing. Fixed-function vertex processing 1469 includes position transformation (modelview and projection matrices), 1470 lighting, texture coordinate generation, and other calculations. The 1471 results of either method are a "transformed vertex", which has a 1472 position (in clip coordinates), front and back colors, texture 1473 coordinates, generic attributes (vertex program only), and so on. Note 1474 that on many current GL implementations, vertex processing is performed 1475 by executing a "fixed function vertex program" generated by the driver. 1476 1477 After vertex transformation, vertices are assembled into primitives, 1478 according to the topology (e.g., TRIANGLES, QUAD_STRIP) provided by the 1479 call to glBegin(). Primitives are points, lines, triangles, quads, or 1480 polygons. Many GL implementations do not directly support quads or 1481 polygons, but instead decompose them into triangles as permitted by the 1482 spec. 1483 1484 After initial primitive assembly, a geometry program is executed on each 1485 individual point, line, or triangle primitive, if enabled. It can read 1486 the attributes of each transformed vertex, perform arbitrary 1487 computations, and emit new transformed vertices. These emitted vertices 1488 are themselves assembled into primitives according to the output 1489 primitive type of the geometry program. 1490 1491 Then, the colors of the vertices of each primitive are clamped to [0,1] 1492 (if color clamping is enabled), and flat shading may be performed by 1493 taking the color from the provoking vertex of the primitive. 1494 1495 Each primitive is clipped to the view volume, and to any enabled 1496 user-defined clip planes. Color, texture coordinate, and other 1497 attribute values are computed for each new vertex introduced by 1498 clipping. 1499 1500 After clipping, the position of each vertex (in clip coordinates) is 1501 converted to normalized device coordinates in the perspective division 1502 (divide by w) step, and to window coordinates in the viewport 1503 transformation step. 1504 1505 At the same time, color values may be converted to normalized 1506 fixed-point values according to the "Final Color Processing" portion of 1507 the specification. 1508 1509 After the vertices of the primitive are transformed to window 1510 coordinate, the GL determines if the primitive is front- or back-facing. 1511 That information is used for two-sided color selection, where a single 1512 set of colors is selected from either the front or back colors 1513 associated with each transformed vertex. 1514 1515 When all this is done, the final transformed position, colors (primary 1516 and secondary), and other attributes are used for rasterization (Chapter 1517 3 in the OpenGL 2.0 Specification). 1518 1519 When the raster position is specified (via glRasterPos), it goes through 1520 the entire vertex processing pipeline as though it were a point. 1521 However, geometry programs are never run on the raster position. 1522 1523 |generic |conventional 1524 |vertex |vertex 1525 |attributes |attributes 1526 | | 1527 | +-------------------+ 1528 | | | 1529 V V V 1530 vertex fixed-function 1531 program vertex 1532 | processing 1533 | | 1534 | | 1535 +<-------------------+ 1536 | Output 1537 |position, color, Primitive 1538 |other vertex data Type 1539 | | 1540 V | 1541 Begin/ primitive geometry primitive | 1542 End ------> assembly -----> program ----> assembly <-+ 1543 State | | 1544 V | 1545 +<------------------------------+ 1546 | 1547 | 1548 | color flat 1549 +----------> clamping ----> shading 1550 | | 1551 V | 1552 +<------------------------------+ 1553 | 1554 | 1555 clipping 1556 | 1557 | perspective viewport 1558 +------> divide ----> transform 1559 | | 1560 | +---+-----+ 1561 | V | 1562 | final facing | 1563 +------> color determination | 1564 | processing | | 1565 | | | | 1566 | | | | 1567 | +-----+ +----+ | 1568 | | | | 1569 | V V | 1570 | two-sided | 1571 | coloring | 1572 | | | 1573 | | | 1574 +------------------+ | +-------------+ 1575 | | | 1576 V V V 1577 rasterization 1578 | 1579 | 1580 V 1581 1582 (2) Why is this called GL_NV_geometry_program4? There aren't any previous 1583 versions of this extension, let alone three? 1584 1585 RESOLVED: The instruction set for GPU programs of all types (vertex, 1586 fragment, and now geometry) have been unified in the GL_NV_gpu_program4 1587 extension, and the "4" suffix in this extension name indicates the 1588 instruction set type. There are three previous NV_vertex_program 1589 variants (four if you count NV_vertex_program1_1), so "4" is the next 1590 available numeric suffix. 1591 1592 (3) Should the GL produce errors at Begin time if an application specifies 1593 a primitive mode that is "incompatible" with the geometry program? For 1594 example, if the geometry program operates on triangles and the application 1595 sends a POINTS primitive? 1596 1597 RESOLVED: Yes. Mismatches of app-specified primitive types and 1598 geometry program input primitive types seem like clear errors and would 1599 produce weird and wonderful effects. 1600 1601 (4) Can the input primitive type of a geometry program be changed at run 1602 time? 1603 1604 RESOLVED: Not in this extension. Each geometry program has a single 1605 input primitive type, and vertices are presented to the program in a 1606 specific order based on that type. 1607 1608 (5) Can the output primitive type of a geometry program be determined at 1609 run time? 1610 1611 RESOLVED: Not in this extension. 1612 1613 (6) Must the output primitive type of a geometry program match the input 1614 primitive type in any way? 1615 1616 RESOLVED: No, you can have a geometry program generate points out of 1617 triangles or triangles out of points. Some combinations are analogous 1618 to existing OpenGL operations: reading triangles and writing points or 1619 line strips can be used to emulate a subset of PolygonMode 1620 functionality. Reading points and writing triangle strips can be used 1621 to emulate point sprites. 1622 1623 (7) Are primitives emitted by a geometry program processed like any other 1624 OpenGL primitive? 1625 1626 RESOLVED: Yes. Antialiasing, stippling, polygon offset, polygon mode, 1627 culling, two-sided lighting and color selection, point sprite 1628 operations, and fragment processing all work as expected. 1629 1630 One limitation is that the only output primitive types supported are 1631 points, line strips, and triangle strips, none of which meaningfully 1632 support edge flags that are sometimes used in conjunction with the POINT 1633 and LINE polygon modes (edge flags are always ignored for line-mode 1634 triangle strips). 1635 1636 (8) Should geometry programs support additional input primitive types? 1637 1638 RESOLVED: Possibly in a future extension. It should be straightforward 1639 to build a future extension to support geometry programs that operate on 1640 quads. Other primitive types might be more demanding on hardware. 1641 Quads with adjacency would require 12 vertices per program execution. 1642 General polygons may require even more, since there is no fixed bound on 1643 the number of vertices in a polygon. 1644 1645 (9) Should geometry programs support additional output primitive types? 1646 1647 RESOLVED: Possibly in a future extension. Additional output types 1648 (e.g., independent lines, line loops, triangle fans, polygons) may be 1649 useful in the future; triangle fans/polygons seem particularly useful. 1650 1651 (10) Should we provide additional adjacency primitive types that can be 1652 used inside a Begin/End? 1653 1654 RESOLVED: Not in this extension. It may be desirable to add new 1655 primitive types (e.g., TRIANGLE_FAN_ADJACENCY) in a future extension. 1656 1657 (11) How do geometry programs interact with RasterPos? 1658 1659 RESOLVED: Geometry programs are ignored when specifying the raster 1660 position. While the raster position could be treated as a point, 1661 turning it into a triangle strip would be quite bizarre. 1662 1663 (12) How do geometry programs interact with pixel primitives (DrawPixels, 1664 Bitmap)? 1665 1666 RESOLVED: They do not. Fragments generated be DrawPixels and Bitmap 1667 are injected into the pipeline after the point where geometry program 1668 execution occurs. 1669 1670 (13) Is there a limit on the number of vertices that can be emitted by a 1671 geometry program? 1672 1673 RESOLVED: Unfortunately, yes. Besides practical hardware limits, there 1674 may also be practical performance advantages when applications guarantee 1675 a tight upper bound on the number of vertices a geometry shader will 1676 emit. GPUs frequently excecute programs in parallel, and there are 1677 substantial implementation challenges to parallel execution of geometry 1678 threads that can write an unbounded number of results, particular given 1679 that the all the primitives generated by the first geometry program 1680 invocation must be consumed before any of the primitives generated by 1681 the second program invocation. Limiting the amount of data a geometry 1682 program can write substantially eases the implementation burden. 1683 1684 A geometry program must declare a maximum number of vertices that can be 1685 emitted, called the vertex limit. There is an implementation-dependent 1686 limit on the total number of vertices a program can emit (256 minimum) 1687 and the product of the vertex limit and the number of active result 1688 components (1024 minimum). A program will fail to load if doesn't 1689 declare a limit or exceeds either of the two implementatoin-dependent 1690 limits. 1691 1692 It would be ideal if the limit could be inferred from the instructions 1693 in the program itself, and that would be possible for many programs, 1694 particularly ones with straight-line flow control. For programs with 1695 more complicated flow control (subroutines, data-dependent looping, and 1696 so on), it would be impossible to make such an inference and a "safe" 1697 limit would have to be used with adverse and possibly unexpected 1698 performance consequences. 1699 1700 The limit on the number of EMIT instructions that can be issued can not 1701 always be enforced at compile time, or even at Begin time. We specify 1702 that if a program tries to emit more vertices than the vertex limit 1703 allows, emits that exceed the limit may or may not have any effect. 1704 1705 (14) Should it be possible to change the limit on the number of vertices 1706 emitted by a geometry program after the program is specified? 1707 1708 RESOLVED: Yes, using the function ProgramVertexLimitNV(). Applications 1709 may want to tweak a piece of data that affects the number of vertices 1710 emitted, but doesn't necessarily require recompiling the entire program. 1711 Examples might be a "circular point sprite" program, that reads a single 1712 point, and draws a circle centered at that point with <N> vertices. An 1713 application could change the value <N> at run time, but it could require 1714 a change in the vertex limit. Another example might be a geometry 1715 program that does some fancy subdivision, where the relevant parameter 1716 might be a limit on how far the primitive is subdivided. 1717 1718 Ideally, this program object state should be set by a "program 1719 parameter" command, much like texture state is set by a "texture 1720 parameter" (TexParameter) command. Unfortunately, there are already 1721 several different "program parameter" functions: 1722 1723 ProgramEnvParameter4fARB() -- sets global environment constants 1724 ProgramLocalParameter4fARB() -- sets per-program constants 1725 ProgramParameter4fNV() -- also sets global environment constants 1726 1727 Additionally, GLSL and OpenGL 2.0 introduced "program objects" which are 1728 linked collections of vertex, fragment, and now geometry shaders. A 1729 GLSL vertex "shader" is equivalent to an ARB_vertex_program vertex 1730 "program", which is nothing like a GLSL program. As of OpenGL 2.0, GLSL 1731 programs do not have settable parameters, by subsequent extensions may 1732 want to add them (for example, EXT_geometry_shader4, which has this same 1733 functionality for GLSL). If that happens, they would want their own 1734 ProgramParameter API, but with a different prototype than this extension 1735 would want. 1736 1737 Naming this function "ProgramVertexLimitNV" sidesteps this issue for 1738 now. 1739 1740 (15) How do edge flags interact with adjacency primitives? 1741 1742 RESOLVED: If geometry programs are disabled, adjacency primitives are 1743 still supported. For TRIANGLES_ADJACENCY_EXT, edge flags will apply as 1744 they do for TRIANGLES. Such primitives are rendered as independent 1745 triangles as though the adjacency vertices were not provided. Edge 1746 flags for the "real" vertices are supported. For all other adjacency 1747 primitive types, edge flags are irrelevant. 1748 1749 (16) How do geometry programs interact with color clamping? 1750 1751 RESOLVED: Geometry program execution occurs prior to color clamping in 1752 the pipeline. This means the colors written by vertex programs or 1753 fixed-function vertex processing are not clamped to [0,1] before they 1754 are read by geometry programs. If color clamping is enabled, any vertex 1755 colors written by the geometry program will have their components 1756 clamped to [0,1]. 1757 1758 (17) How are QUADS, QUAD_STRIP, and POLYGON primitives decomposed into 1759 triangles in the initial implementation of GL_NV_geometry_program4? 1760 1761 RESOLVED: The specification leaves the decomposition undefined, subject 1762 to a small number of rules. Assume that four vertices are specified in 1763 the order V0, V1, V2, V3. 1764 1765 For QUADS primitives, the quad V0->V1->V2->V3 is decomposed into the 1766 triangles V0->V1->V2, and V0->V2->V3. The provoking vertex of the quad 1767 (V3) is only found in the second triangle. If it's necessary to flat 1768 shade over an entire quad, take the attributes from V0, which will be 1769 the first vertex for both triangles in the decomposition. 1770 1771 For QUAD_STRIP primitives, the quad V0->V1->V3->V2 is decomposed into 1772 the triangles V0->V1->V3 and V2->V0->V3. This has the property of 1773 leaving the provoking vertex for the polygon (V3) as the third vertex 1774 for each triangle of the decomposition. 1775 1776 For POLYGON primitives, the polygon V0->V1->V2->V3 is decomposed into 1777 the triangles V1->V2->V0 and V2->V3->V0. This has the property of 1778 leaving the provoking vertex for the polygon (V0) as the third vertex 1779 for each triangle of the decomposition. 1780 1781 (18) Should geometry programs be able to select a layer of a 3D texture, 1782 cube map texture, or array texture at run time? If so, how? 1783 1784 RESOLVED: This extension provides a per-vertex result binding called 1785 "result.layer", which is an integer specifying the layer to render to. 1786 When an each individual point, line, or triangle is emitted by a 1787 geometry program, the layer number is taken from the provoking (last) 1788 vertex of the primitive and is used for all fragments generated by that 1789 primitive. 1790 1791 The EXT_framebuffer_object (FBO) extension is used for rendering to 1792 textures, but for cube maps and 3D textures, it only provides the 1793 ability to attach a single face or layer of such textures. 1794 1795 This extension generalizes FBO by creates new entry points to bind an 1796 entire texture level (FramebufferTextureEXT) or a single layer of a 1797 texture level (FramebufferTextureLayerEXT) to an attachment point. The 1798 existing FBO binding functions, FramebufferTexture[123]DEXT are 1799 retained, and are defined in terms of the more general new functions. 1800 1801 The new functions do not have a dimension in the function name or a 1802 <textarget> parameter, which can be inferred from the provided texture. 1803 They can do anything that the old functions can do, except attach a 1804 single face of a cube map texture. We considered adding a separate 1805 function FramebufferTextureFaceEXT to provide this functionality, but 1806 decided that the existing FramebufferTexture2DEXT API was adequate. We 1807 also considered using FramebufferTextureLayerEXT for this purpose, but 1808 it was not clear whether a layer number (0-5) or face enum (e.g, 1809 TEXTURE_CUBE_MAP_POSITIVE_X) should be provided. 1810 1811 When an entire texel level of a cube map, 3D, or array texture is 1812 attached, that attachment is considered layered. The framebuffer is 1813 considered layered if any attachment is layered. When the framebuffer 1814 is layered, there are three additional completeness requirements: 1815 1816 * all attachments must be layered 1817 * all color attachments must be from textures of identical type 1818 * all attachments must have the same number of layers 1819 1820 We expect subsequent versions of the FBO spec to relax the requirement 1821 that all attachments must have the same width and height, and plan to 1822 relax the similar requirement for layer count at that time. 1823 1824 When rendering to a layered framebuffer, layer zero is used unless a 1825 geometry program that writes the layer result is enabled. When 1826 rendering to a non-layered framebuffer, any layer result emitted from 1827 geometry programs is ignored and the set of single-image attachments are 1828 used. When reading from a layered framebuffer (e.g., ReadPixels), layer 1829 zero is always used. When clearing a layered framebuffer, all layers 1830 are cleared to the corresponding clear values. 1831 1832 Several other approaches were considered, including leveraging existing 1833 FBO attachment functions and requiring the use of FramebufferTexture3D 1834 with a <zoffset> of zero to make a framebuffer attachment "layerable" 1835 (attaching layer zero means that the attachment could be used for either 1836 layered- or non-layered rendering). Whether rendering was layered or 1837 not could either be inferred from the active geometry program, or set as 1838 a new property of the framebuffer object. There is presently 1839 FramebufferParameter API to set a property of a framebuffer, so it would 1840 have been necessary to create new set/query APIs if this approach were 1841 chosen. 1842 1843 (19) How can single-pass cube map rendering be done efficiently in a 1844 geometry program? 1845 1846 UNRESOLVED: To do single-pass cubemap rendering, attach entire cube map 1847 textures to framebuffer attachment points using the new functions 1848 provided by this extension. The vertex program used should only 1849 transform the vertex position to eye coordinates (position relative to 1850 the center of the cube map). A geometry program should be used that 1851 effectively projects each input triangle onto each of the six faces of 1852 the cube map, emitting a triangle for each. Each of the projected 1853 vertices should be emitted with a "result.layer" value matching the face 1854 number (0-5). When the projected triangle is drawn, it is automatically 1855 drawn on the face corresponding to the emitted layer number. 1856 1857 It should be simple to skip projecting primitives onto faces they won't 1858 touch. For example, if all of the X eye coordinates are positive, there 1859 is no reason to project to the "negative X" cube map face. 1860 1861 An example should be provided for this issue. 1862 1863 (20) How should per-vertex point size work with geometry programs? 1864 1865 RESOLVED: We will generalize the existing VERTEX_PROGRAM_POINT_SIZE 1866 enable to control the point size behavior if either vertex or geometry 1867 programs are enabled. 1868 1869 If geometry programs are enabled, the point size is taken from the point 1870 size result of the emitted vertex if VERTEX_PROGRAM_POINT_SIZE is 1871 enabled, or from the PointSize state otherwise. 1872 1873 If no geometry program is enabled, it works like OpenGL 2.0. If a 1874 vertex program is active, it's taken from the point size result or 1875 PointSize state, depending on the VERTEX_PROGRAM_POINT_SIZE enable. If 1876 no program is enabled, normal fixed-function point size handling 1877 (including distance attenuation) is supported. 1878 1879 This extension creates a new alias for the VERTEX_PROGRAM_POINT_SIZE 1880 enum, called PROGRAM_POINT_SIZE_EXT, to reflect that the point size 1881 enable now covers multiple program types. Both enums have the same 1882 value. 1883 1884 (21) How do vertex IDs work with geometry programs? 1885 1886 RESOLVED: Vertex IDs are automatically provided to vertex programs 1887 when applicable, via the "vertex.id" binding. However, they are not 1888 automatically copied the transformed vertex results that are read by 1889 geometry programs. 1890 1891 Geometry programs can read the ID of vertex <n> via the 1892 "vertex[<n>].id" binding, but the vertex ID must have been copied by 1893 the vertex program using an instruction such as: 1894 1895 MOV result.id.x, vertex.id.x; 1896 1897 If a vertex program doesn't write vertex ID, or fixed-function vertex 1898 processing is used, the vertex ID visible to geometry programs is 1899 undefined. 1900 1901 (22) How do primitive IDs work with geometry programs? 1902 1903 RESOLVED: Primitive IDs are automatically available to geometry 1904 programs via the "primitive.id" binding and indicate the number of 1905 input primitives previously processed since the last explicit or 1906 implicit Begin call. 1907 1908 If a geometry program wants to make the primitive ID available to a 1909 fragment program, it should copy the appropriate value to the 1910 "result.primid" binding. 1911 1912 (23) How do primitive IDs work with primitives not supported directly by 1913 geometry program input topologies (e.g., QUADS, POLYGON)? 1914 1915 RESOLVED: QUADS are decomposed into two triangles. Both triangles 1916 will have the same primitive ID, which is the number of full quads 1917 previously processed. POLYGON primitives are decomposed into a series 1918 of triangles, and all of them will have the primitive ID -- zero. 1919 1920 (24) This is an NV extension (NV_geometry_program4). Why do some of the 1921 new tokens have an "EXT" extension? 1922 1923 RESOLVED: Some of the tokens are shared between this extension and the 1924 comparable high-level GLSL programmability extension 1925 (EXT_geometry_shader4). Rather than provide a duplicate set of tokens, 1926 we simply use the EXT versions here. The tokens specific to assembly 1927 shader uses retain an NV suffix. 1928 1929 (25) What happens if you try to do a framebuffer blit (via 1930 EXT_framebuffer_blit) to/from a layered framebuffer? 1931 1932 RESOLVED: BlitFramebufferEXT() is a two-dimensional operation (only has 1933 a width and height), so only reads/writes layer zero. The framebuffer 1934 blit operation is defined partially in terms of CopyPixels, which itself 1935 is defined in terms of ReadPixels and DrawPixels. This spec defines 1936 both operations to use layer zero when a layered framebuffer is 1937 involved. 1938 1939 It may be desirable to provide a three-dimensional framebuffer blit 1940 operation or an explicit copy single-step operation between two 1941 three-dimensional, cube map, or array textures. That functionality is 1942 left for a future extension or OpenGL version. 1943 1944 1945Revision History 1946 1947 Rev. Date Author Changes 1948 ---- -------- -------- -------------------------------------------- 1949 13 12/14/09 mgodse Added GLX protocol. 1950 1951 12 07/21/09 pbrown Clarify that when doing layered rendering, 1952 a layer specified in the shader is used to 1953 select the depth and stencil layers accessed. 1954 1955 Also document several additional entry points 1956 that accept GEOMETRY_PROGRAM_NV. 1957 1958 11 03/11/09 pbrown Fix section numbers for option/declaration 1959 sections. 1960 1961 10 07/29/08 pbrown Clean up garbled language describing vertex 1962 output limits. 1963 1964 9 04/04/08 pbrown Fixed error in the state tables; the geometry 1965 program enable should push/pop only with the 1966 enable bit like all the other program enables. 1967 1968 8 03/15/08 pbrown Additional dependency on EXT_framebuffer_blit; 1969 blits to/from layered targets affect only 1970 layer zero. 1971 1972 7 03/07/08 pbrown Fix grammar to allow vertex ID, as already 1973 allowed in the rest of the spec body. 1974 1975 6 pbrown Internal spec development. 1976 1977