1Name 2 3 NV_geometry_shader_passthrough 4 5Name Strings 6 7 GL_NV_geometry_shader_passthrough 8 9Contact 10 11 Pat Brown, NVIDIA Corporation (pbrown 'at' nvidia.com) 12 13Contributors 14 15 Jeff Bolz, NVIDIA Corporation 16 Piers Daniell, NVIDIA Corporation 17 Christoph Kubisch, NVIDIA Corporation 18 Mathias Heyer, NVIDIA Corporation 19 Mark Kilgard, NVIDIA Corporation 20 21Status 22 23 Shipping 24 25Version 26 27 Last Modified Date: February 15, 2017 28 NVIDIA Revision: 4 29 30Number 31 32 OpenGL Extension #470 33 OpenGL ES Extension #233 34 35Dependencies 36 37 This extension is written against the OpenGL 4.3 Specification 38 (Compatibility Profile), dated February 14, 2013 39 40 This extension is written against the OpenGL Shading Language 41 Specification, version 4.30, revision 8. 42 43 OpenGL ES 3.1 and EXT_geometry_shader are required for an 44 implementation in OpenGL ES. 45 46 This extension interacts with OpenGL 4.4 and ARB_enhanced_layouts. 47 48 This extension interacts with NV_gpu_program4 and NV_gpu_program5. 49 50 This extension interacts with NV_geometry_shader4 and NV_gpu_shader4. 51 52 This extension interacts with NV_geometry_program4 and NV_gpu_program4. 53 54 This extension interacts with NV_transform_feedback. 55 56 This extension interacts with a combination of NV_gpu_program4, 57 NV_gpu_program5, NV_transform_feedback, EXT_transform_feedback, and OpenGL 58 3.0. 59 60 This extension interacts with NVX_shader_thread_group. 61 62Overview 63 64 Geometry shaders provide the ability for applications to process each 65 primitive sent through the GL using a programmable shader. While geometry 66 shaders can be used to perform a number of different operations, including 67 subdividing primitives and changing primitive type, one common use case 68 treats geometry shaders as largely "passthrough". In this use case, the 69 bulk of the geometry shader code simply copies inputs from each vertex of 70 the input primitive to corresponding outputs in the vertices of the output 71 primitive. Such shaders might also compute values for additional built-in 72 or user-defined per-primitive attributes (e.g., gl_Layer) to be assigned 73 to all the vertices of the output primitive. 74 75 This extension provides a shading language abstraction to express such 76 shaders without requiring explicit logic to manually copy attributes from 77 input vertices to output vertices. For example, consider the following 78 simple geometry shader in unextended OpenGL: 79 80 layout(triangles) in; 81 layout(triangle_strip) out; 82 layout(max_vertices=3) out; 83 84 in Inputs { 85 vec2 texcoord; 86 vec4 baseColor; 87 } v_in[]; 88 out Outputs { 89 vec2 texcoord; 90 vec4 baseColor; 91 }; 92 93 void main() 94 { 95 int layer = compute_layer(); 96 for (int i = 0; i < 3; i++) { 97 gl_Position = gl_in[i].gl_Position; 98 texcoord = v_in[i].texcoord; 99 baseColor = v_in[i].baseColor; 100 gl_Layer = layer; 101 EmitVertex(); 102 } 103 } 104 105 In this shader, the inputs "gl_Position", "Inputs.texcoord", and 106 "Inputs.baseColor" are simply copied from the input vertex to the 107 corresponding output vertex. The only "interesting" work done by the 108 geometry shader is computing and emitting a gl_Layer value for the 109 primitive. 110 111 The following geometry shader, using this extension, is equivalent: 112 113 #extension GL_NV_geometry_shader_passthrough : require 114 115 layout(triangles) in; 116 // No output primitive layout qualifiers required. 117 118 // Redeclare gl_PerVertex to pass through "gl_Position". 119 layout(passthrough) in gl_PerVertex { 120 vec4 gl_Position; 121 } gl_in[]; 122 123 // Declare "Inputs" with "passthrough" to automatically copy members. 124 layout(passthrough) in Inputs { 125 vec2 texcoord; 126 vec4 baseColor; 127 } v_in[]; 128 129 // No output block declaration required. 130 131 void main() 132 { 133 // The shader simply computes and writes gl_Layer. We don't 134 // loop over three vertices or call EmitVertex(). 135 gl_Layer = compute_layer(); 136 } 137 138New Procedures and Functions 139 140 None. 141 142New Tokens 143 144 None. 145 146Modifications to the OpenGL 4.3 Specification (Compatibility Profile) 147 148 Modify Section 11.3.4.5, Geometry Shader Outputs, p. 425 149 150 (add to the end of the section, p. 426): 151 152 For the purposes of component counting, passthrough geometry shaders count 153 all active input variable components declared with the layout qualifier 154 "passthrough" as output components as well, since their values will be 155 copied to the output primitive produced by the geometry shader. 156 157 158Modifications to the OpenGL Shading Language Specification, Version 4.30 159 160 Including the following line in a shader can be used to control the 161 language features described in this extension: 162 163 #extension GL_NV_geometry_shader_passthrough : <behavior> 164 165 where <behavior> is as specified in section 3.3. 166 167 New preprocessor #defines are added to the OpenGL Shading Language: 168 169 #define GL_NV_geometry_shader_passthrough 1 170 171 Modify Section 4.4.1.2, Geometry Shader Inputs (p. 57) 172 173 (add to the list of allowed layout qualifiers, p. 57) 174 175 layout-qualifier-id 176 ... 177 passthrough 178 179 (insert after discussion of the "invocations" layout qualifier, p. 57) 180 181 A geometry shader using the layout qualifier "passthrough" is considered a 182 "passthrough geometry shader". Output primitives in a passthrough 183 geometry shader always have the same topology as the input primitive and 184 are not produced by emitting vertices. The vertices of the output 185 primitive have two different types of attributes. Geometry shader inputs 186 qualified with "passthrough" are considered to produce per-vertex outputs, 187 where values for each output vertex are copied from the corresponding 188 input vertex. Any built-in or user-defined geometry shader outputs are 189 considered per-primitive in a passthrough geometry shader, where a single 190 output value is copied to all output vertices. 191 192 The identifier "passthrough" can not be used to qualify "in", but can be 193 used to qualify input variables, blocks, or block members. It specifies 194 that values of those inputs will be copied to the corresponding vertex of 195 the output primitive. Input variables and block members not qualified 196 with "passthrough" will be consumed by the geometry shader without being 197 passed through to subsequent stages. For the purposes of matching 198 passthrough geometry shader inputs with outputs of the previous pipeline 199 stages, the "passthrough" qualifier itself is ignored. For separable 200 program objects (where geometry shader inputs and outputs may interface 201 with inputs and outputs in other program objects), all inputs qualified 202 with "passthrough" must also be assigned a location using the "location" 203 layout qualifier. It is a link-time error to specify a passthrough 204 geometry shader input in a separable program without an explicitly 205 assigned location. 206 207 For the purposes of matching the outputs of the geometry shader with 208 subsequent pipeline stages, each input qualified with "passthrough" is 209 considered to add an equivalent output with the same name, type, and 210 qualification (except using "out" instead of "in") on the output 211 interface. The output declaration corresponding to an input variable 212 qualified with "passthrough" will be identical to the input declaration, 213 except that it will not be treated as arrayed. The output block 214 declaration corresponding to an input block qualified with "passthrough" 215 or having members qualified with "passthrough" will be identical to the 216 input declaration, except that it will not be treated as arrayed and will 217 not have an instance name. If an input block is qualified with 218 "passthrough", the equivalent output block contains all the members of the 219 input block. Otherwise, the equivalent output block contains only those 220 input block members qualified with "passthrough". If such an input block 221 is qualified with "location" or has members qualified with "location", all 222 members of the corresponding output block members are assigned locations 223 identical to those assigned to corresponding input block members. All 224 such outputs are associated with output vertex stream zero (section 225 4.4.2.2). Output variables and blocks generated from inputs qualified 226 with "passthrough" will only be added to the name space of the output 227 interface; these declarations will not be available to geometry shader 228 code. A program will fail to link if it contains a geometry shader output 229 block with the same name as a geometry shader input block that is 230 qualified with "passthrough" or contains a member qualified with 231 "passthrough". 232 233 A compile-time error is generated if the non-arrayed input variables 234 "gl_PrimitiveIDIn" or "gl_InvocationID" are redeclared with the 235 "passthrough" layout qualifier. 236 237 A compile- or link-time error will be generated if a program contains a 238 passthrough geometry shader and: 239 240 * declares a geometry shader input primitive type using layout 241 qualifiers other than "points", "lines", or "triangles"; 242 243 * declares a geometry shader output primitive type using the output 244 layout qualifiers "points", "line_strip", or "triangle_strip" (section 245 4.4.2.2); 246 247 * declares a geometry shader output primitive vertex count using the 248 output layout qualifier "max_vertices"; 249 250 * declares a geometry shader invocation count other than one using the 251 input layout qualifier "invocations"; 252 253 * declares a geometry shader output variable or block qualified with 254 "stream" with an associated output vertex stream other than zero; 255 256 * includes geometry shader code calling the built-in functions 257 EmitVertex(), EmitStreamVertex(), EndPrimitive(), or 258 EndStreamPrimitive(); or 259 260 * is configured to use transform feedback, using either the geometry 261 shader output layout qualifiers "xfb_offset", "xfb_stride", and 262 "xfb_buffer", or using the OpenGL API command 263 TransformFeedbackVaryings(). 264 265 For the purposes of OpenGL API queries, passthrough geometry shaders are 266 considered to include an output layout qualifier (section 4.4.2.2) 267 specifying an output primitive type and maximum vertex count consistent 268 with an equivalent non-passthrough geometry shader, as per the following 269 table. 270 271 Input Layout Output Layout 272 ---------------- ------------------------------------------ 273 points layout(points, max_vertices=1) out; 274 lines layout(line_strip, max_vertices=2) out; 275 triangles layout(triangle_strip, max_vertices=3) out; 276 277Additions to the AGL/GLX/WGL Specifications 278 279 None. 280 281Errors 282 283 None. 284 285New State 286 287 None. 288 289New Implementation Dependent State 290 291 None. 292 293 294Interactions with OpenGL ES 3.1 295 296 Unless made available by functionality similar to ARB_transform_feedback3 297 and ARB_gpu_shader5, remove references to EmitStreamVertex() and 298 EndStreamPrimitive(), the "stream = N" layout qualifier as well as 299 the notion of multiple transform feedback streams. 300 301Dependencies on OpenGL 4.4 and ARB_enhanced_layouts 302 303 If neither OpenGL 4.4 nor ARB_enhanced_layouts is supported, remove 304 references to the use of the "xfb_offset", "xfb_buffer", and "xfb_stride" 305 layout qualifiers for transform feedback. 306 307Dependencies on NV_gpu_program4 and NV_geometry_program4 308 309 Modify Section 2.X.2, Program Grammar, of the NV_geometry_program4 310 specification (which modifies the NV_gpu_program4 base grammar) 311 312 <declaration> ::= "PASSTHROUGH" <resultUseD> <optWriteMask> 313 314 Modify Section 2.X.6, Program Options 315 316 + Passthrough Geometry Program (NV_geometry_program_passthrough) 317 318 If a geometry program specifies the "NV_geometry_program_passthrough" 319 option, the program will be configured as a passthrough geometry program. 320 A passthrough geometry program is configured to emit a new output 321 primitive with the same type and vertex count as its input primitive. For 322 any result variable components written by a passthrough geometry program 323 instruction, the values are broadcast to all vertices of the output 324 primitive. For any result binding components specified in PASSTHROUGH 325 statements, the component values for each input primitive vertex are 326 copied ("passed through") to their corresponding output primitive vertex 327 without requiring geometry program code to copy attribute values and emit 328 output primitive vertices. A passthrough geometry program will fail to 329 load if it contains an INVOCATIONS, PRIMITIVE_OUT, or VERTICES_OUT 330 declaration, or an EMIT, EMITS, or ENDPRIM instruction. A passthrough 331 geometry program must declare an input primitive type of POINTS, LINES, or 332 TRIANGLES, and the resulting output primitive produced will be a single 333 point, line, or triangle, respectively. The PASSTHROUGH declaration can 334 be used only in programs using this option. 335 336 337 Section 2.X.7.Y, Geometry Program Declarations 338 339 (modify the first paragraph of the section) 340 341 Geometry programs support three types of declaration statements specifying 342 input and output primitive types, as described below. .... 343 344 (add to the end of the section) 345 346 Additionally, if the "NV_geometry_program_passthrough" option is 347 specified, a geometry program can include zero or more instances of the 348 following declaration statement: 349 350 - Passthrough Geometry Shader Attribute (PASSTHROUGH) 351 352 Each PASSTHROUGH declaration statement identifies a set of result binding 353 components whose values for each vertex of the output primitive will be 354 produced by copying the corresponding attribute binding components from 355 the corresponding vertex of the input primitive. The set of result 356 bindings for which this copy is performed is identified by the 357 <resultUseD> grammar rule. For each such binding, the set of components 358 to be copied is identified by the <optWriteMask> grammar rule. If the 359 write mask is omitted, all components of each binding are copied. A 360 program will fail to load if the binding identified by the <resultUseD> 361 grammar rule does not have a corresponding attribute binding; 362 "result.primid", "result.layer", and "result.viewport" may not be used. 363 It is legal to specify an attribute binding more than once in a 364 PASSTHROUGH declaration; a component will be passed through if and only if 365 it is identified in one or more PASSTHROUGH declarations. A program will 366 fail to load if any result binding is both declared in a PASSTHROUGH 367 statement and written by a program instruction, even if the set of 368 components referenced is mutually exclusive. 369 370 Modify Section 13.2.2 of the OpenGL 4.3 Specification, p. 457 371 372 (insert before the errors section, p. 458) 373 374 Transform feedback can not be used with passthrough geometry programs. 375 When transform back is active and not paused, an INVALID_OPERATION error 376 is generated by any command that transfers vertices to the GL if the 377 current geometry program was declared using the 378 "NV_geometry_shader_passthrough" program option. 379 380 381Dependencies on NV_geometry_shader4 and NV_gpu_shader4 382 383 If NV_geometry_shader4 is supported, it is possible to change the maximum 384 geometry shader output vertex count after linking a program. The 385 following language should be added to the end of the description of the 386 the GEOMETRY_VERTICES_OUT_EXT <pname> for the ProgramParameteriEXT API in 387 the NV_geometry_shader4 specification: 388 389 The error INVALID_OPERATION is generated by ProgramParameteriEXT if 390 <program> identifies a program object that has been linked successfully 391 and includes a passthrough geometry shader (one using the "passthrough" 392 layout qualifier). 393 394 Note that NV_geometry_shader4 doesn't have its own extension string entry; 395 it is considered present if and only if NV_gpu_shader4 is advertised. 396 397Dependencies on NV_geometry_program4 and NV_gpu_program4 398 399 If NV_geometry_program4 is supported, it is possible to change the maximum 400 output vertex count after compiling an assembly geometry program. The 401 following language should be added to the end of the description of the 402 ProgramVertexLimitNV API: 403 404 The error INVALID_OPERATION is generated by ProgramVertexLimitNV if the 405 current geometry program uses the NV_geometry_program_passthrough 406 program option. 407 408 Note that NV_geometry_program4 doesn't have its own extension string 409 entry; it is considered present if and only if NV_gpu_program4 is 410 advertised. 411 412Dependencies on NV_transform_feedback 413 414 If NV_transform_feedback is supported, the following language should be 415 added to the end of the description of the TransformFeedbackVaryingsNV 416 API: 417 418 The error INVALID_OPERATION is generated by TransformFeedbackVaryingsNV 419 if <program> identifies a program containing a passthrough geometry 420 shader (i.e., one using the "passthrough" layout qualifier). 421 422Dependencies on NV_gpu_program4, NV_gpu_program5, NV_transform_feedback, 423EXT_transform_feedback, and OpenGL 3.0: 424 425 If NV_gpu_program4 and/or NV_gpu_program5 is supported together with any 426 of NV_transform_feedback, EXT_transform_feedback, or OpenGL 3.0 is 427 supported, the following language should be added to the descriptions of 428 BeginTransformFeedbackNV(), BeginTransformFeedbackEXT(), and 429 BeginTransformFeedback() as applicable: 430 431 Transform feedback is not supported with passthrough geometry programs. 432 The error INVALID_OPERATION error is generated if there is an active 433 geometry program that uses the NV_geometry_program_passthrough program 434 option. 435 436 Note that this issue doesn't apply to GLSL program objects, since we are 437 making it impossible to successfully specify a program that uses transform 438 feedback and a passthrough geometry shader concurrently. 439 440Dependencies on NVX_shader_thread_group 441 442 If NVX_shader_thread_group is supported, the new built-in inputs provided 443 by that extension should not be allowed as passthrough: 444 445 A compile-time error is generated if any of the non-arrayed input 446 variables "gl_PrimitiveIDIn", "gl_InvocationID", "gl_ThreadInWarpNVX", 447 "gl_ThreadEqMaskNVX", "gl_ThreadGeMaskNVX", "gl_ThreadGtMaskNVX", 448 "gl_ThreadLeMaskNVX", "gl_ThreadLtMaskNVX", "gl_WarpIDNVX", or 449 "gl_SMIDNVX" are redeclared with the "passthrough" layout qualifier. 450 451 452Issues 453 454 (1) What should this extension be called? 455 456 RESOLVED: NV_geometry_shader_passthrough. The new layout qualifier 457 specifies new semantics where primitives are largely "passed through" by 458 the geometry shader, copying vertices of the input primitive to the 459 output primitive. The only operation performed by geometry shaders 460 using this extension is to compute a collection of per-primitive 461 attributes assigned to all vertices of the geometry shader. 462 463 (2) This extension is aimed at geometry shaders that show a specific 464 pattern. Why provide an explicit programming model in this extension, 465 as opposed to automatically optimizing regular geometry shaders? 466 467 RESOLVED: The hardware for which this extension was written provides 468 explicit support for passing attributes of geometry shader input 469 vertices through the geometry stage without an explicit copy. While 470 implementations supporting this extension may optimize geometry shaders 471 to use this hardware, we provide an explicit programming model because 472 (a) application developers may prefer to use this model for programming 473 such shaders and (b) automatic optimization may fail to detect a 474 "passthrough" pattern in some geometry shaders. 475 476 (3) How do passthrough geometry shaders interact with GLSL built-in 477 variables? 478 479 RESOLVED: Geometry shaders can redeclare the built-in input block 480 "gl_PerVertex" with the "passthrough" layout qualifier to specify that 481 built-in inputs like "gl_Position" should be passed through. We allow 482 the shader to qualify the entire redeclared block with "passthrough" to 483 pass through all block members. We also allow the shader to qualify 484 individual block members with "passthrough" to pass through some, but 485 not all, block members. 486 487 (4) How do passthrough geometry shaders interact with geometry shader 488 instancing (using the "invocations=N" layout qualifier)? 489 490 RESOLVED: We disallow the use of instancing in passthrough geometry 491 shaders; it will result in a link error. 492 493 We considered specifying the features as orthogonal (with the 494 passthrough geometry shader run N times), but consider the feature to be 495 of limited utility. Making N separate copies of the input primitive 496 type isn't consistent with a model that largely passes through one 497 single primitive. 498 499 (5) How do passthrough geometry shaders interact with transform feedback? 500 501 RESOLVED: We disallow the use of transform feedback with programs with 502 a passthrough geometry shader; it will result in a link error. 503 504 We considered specifying the features as orthogonal, but consider the 505 feature to be of limited utility. In particular, since inputs that are 506 passed through the geometry shader don't have explicit output 507 declarations, there is no way to control transform feedback using the 508 "xfb_offset", "xfb_buffer", and "xfb_stride" layout qualifiers. While 509 it would still be possible to use the OpenGL API command 510 TransformFeedbackVaryings() to specify passed through inputs to capture, 511 we decided it wasn't worth the trouble. 512 513 For GLSL programs in unextended OpenGL 4.3, we can specify a link-time 514 error to enforce this limitation. For applications using GLSL programs 515 and the NV_transform_feedback extension (where transform feedback 516 varyings can be specified post-link), we throw an error when attempting 517 to update transform feedback. We will also prohibit the use of assembly 518 programs with transform feedback for consistency, but need to specify a 519 Draw-time error for that since transform feedback is completely 520 decoupled from assembly program objects. 521 522 (6) How do passthrough geometry shaders interact with multi-stream 523 geometry shader support (using the "stream=N" layout qualifier)? 524 525 RESOLVED: All of the output vertices of a passthrough geometry shader 526 are associated with output vertex stream zero. Additionally, it is an 527 error to declare a GLSL output variable with a stream other than zero. 528 529 (7) Do passthrough geometry shaders need to use layout qualifiers 530 describing the output primitive type? 531 532 RESOLVED: No. We will not allow the use of these layout qualifiers 533 with passthrough geometry shaders. The output primitive type and vertex 534 count will be taken directly from the input primitive type for such 535 shaders. 536 537 (8) Inputs qualified with "passthrough" are copied to the vertices of the 538 output primitive. Do they show up on the PROGRAM_OUTPUT interface for 539 program resource queries (e.g., GetProgramResourceiv)? 540 541 RESOLVED: Yes, passed through variables, blocks, and block members 542 appear on the output interface. 543 544 (9) How should geometry shaders indicate that they want to be 545 "passthrough"? Should we have some sort of declaration at global 546 scope (e.g., "layout(passthrough) in") or infer it from the presence 547 of one or more layout qualifiers on variables, blocks, or block 548 members? 549 550 RESOLVED: We consider a geometry shader to be passthrough if one or 551 more input variables, blocks, or block members are qualified by 552 "passthrough". We won't require or allow the "passthrough" layout 553 qualifier to be used on "in". 554 555 We considered requiring separate declarations for a global "passthrough" 556 mode and passing through individual variables like this: 557 558 layout(passthrough) in; // makes the shader passthrough 559 560 layout(passthrough) in Block { // pass through the contents of <Block> 561 ... 562 } v_in[]; 563 564 We decided not to do this in part because the inheritance semantics for 565 other layout qualifiers might cause the casual programmer to expect that 566 the applying the qualifier "passthrough" to in might cause all 567 subsequent inputs to inherit "passthrough" behavior. 568 569 layout(passthrough) in; 570 in Block { 571 ... 572 } v_in[]; 573 574 We could have resolved this by using a second identifier (e.g., 575 "passthrough_shader") in the layout qualifier, but there don't seem to 576 be any interesting cases where a passthrough geometry shader has no 577 per-vertex outputs. In particular, we expect pass-through geometry 578 shaders to always pass through "gl_Position". 579 580 (10) Should we provide any query in the OpenGL API to determine whether a 581 geometry shader is a "passthrough" shader? 582 583 RESOLVED: We are not going to bother to do so in this extension; there 584 are numerous other optional shader features lacking such query support. 585 586 (11) Should passthrough geometry shaders be allowed to write per-primitive 587 values for arbitrary shader outputs or just the inherently 588 per-primitive built-in outputs (e.g., gl_Layer, gl_ViewportIndex)? 589 590 RESOLVED: We should allow passthrough geometry shaders to write to both 591 built-in and user-defined outputs. Any output variables declared in 592 passthrough geometry shader without the "passthrough" layout qualifier 593 are treated as per-primitive outputs and will be broadcast to all 594 vertices in the output primitive. For example, this shader 595 596 layout(passthrough) in; 597 layout(passthrough) in gl_PerVertex { 598 vec4 gl_Position; 599 } gl_in[]; 600 out vec4 batman; 601 602 void main() 603 { 604 batman = compute_batman(); 605 } 606 607 will attach the value produced by compute_batman() to all the vertices 608 of the output primitive. The value of gl_Position for each vertex of 609 the output primitive will be copied directly from the value of 610 gl_Position for the corresponding input vertex. 611 612 (12) How do per-primitive outputs from passthrough geometry shaders 613 interact with fragment shader inputs? 614 615 RESOLVED: Per-primitive outputs will be broadcast to all the vertices 616 of the output primitive, so reading the corresponding fragment shader 617 input should yield the per-primitive output value. 618 619 We strongly recommend using the "flat" qualifier on all fragment shader 620 inputs corresponding to per-primitive passthrough geometry shader 621 outputs. Using "flat" on such inputs may result in better performance 622 when using passthrough geometry shaders. 623 624 We also recommend using the "flat" qualifier on such inputs to avoid 625 possible arithmetic error that can result from evaluating 626 perspective-correct interpolation equations. For example, 627 perspective-correct attribute interpolation for triangles uses the 628 equation: 629 630 f = (a*f_a/w_a + b*f_b/w_b + c*f_c/w_c) / (a/w_a + b/w_b + c/w_c) 631 632 where a, b, and c are interpolation weights (adding to 1), f_a, f_b, and 633 f_c are per-vertex attribute values, and w_a, w_b, and w_c are 634 per-vertex clip w coordinates. For per-primitive outputs, f_a == f_b == 635 f_c, which equals the per-primitive attribute value f_p, so the equation 636 simplifies to: 637 638 f = (a*f_p/w_a + b*f_p/w_b + c*f_p/w_c) / (a/w_a + b/w_b + c/w_c) 639 = f_p * (a/w_a + b/w_b + c/w_c) / (a/w_a + b/w_b + c/w_c) 640 641 At infinite precision, this computation will produce f_p, however there 642 may be rounding error from the division operators that could result in 643 low-order bit differences in the final interpolated value. 644 645 (13) What values are returned for queries of geometry shader-related 646 program properties that are not specified passthrough geometry 647 shaders (GEOMETRY_OUTPUT_TYPE, GEOMETRY_VERTICES_OUT)? 648 649 RESOLVED: We will return values consistent with the input primitive 650 type, as though a non-passthrough geometry shader were specified. For 651 example, if the input primitive type is "triangles", the shader will be 652 treated as having declared: 653 654 layout(triangle_strip, max_vertices=3) out; 655 656 (14) Do passed through outputs count against the limit of total geometry 657 shader output components? What about the limit on the product of 658 per-vertex components and vertices emitted? 659 660 RESOLVED: Yes, we still want a limit on the total number of components 661 in each output vertex. Input components qualified by "passthrough" are 662 also counted as output components for the purposes of both limit checks. 663 We expect that the latter limit (on the product) will never be relevant 664 because the total number of vertices in the output primitive can be at 665 most three. 666 667 (15) How does this extension interact with the ability to change geometry 668 shader output vertex counts, using ProgramParameteriEXT with 669 GEOMETRY_VERTICES_OUT_EXT for GLSL programs (NV_geometry_shader4) or 670 ProgramVertexLimitNV API for assembly programs 671 (NV_geometry_program4)? 672 673 RESOLVED: These commands allow applications to override the declared 674 maximum output vertex counts for geometry shaders based on information 675 known at runtime. Given that passthrough geometry shaders (and assembly 676 programs) will fail if they declare an output vertex count, it makes no 677 sense to override a declaration that doesn't exist. We will throw 678 INVALID_OPERATION if you try to use these APIs with passthrough geometry 679 shaders. 680 681 (16) Does this extension interact with separable program objects? 682 683 RESOLVED: Yes. All geometry shader inputs qualified with the 684 "passthrough" layout qualifier must also have a location explicitly 685 assigned using the "location" layout qualifier. Failing to do so will 686 result in a link-time error. 687 688 The reason for this restriction is that inputs/outputs of one separable 689 program object may interface at run time with inputs/outputs of a 690 different separable program object. When linking one separable program 691 object, the GL has no idea what other program objects it may be used 692 with. To avoid requiring GL implementations to dynamically link program 693 objects X and Y at run time when they are used together, unextended 694 OpenGL requires an "interface match" to get defined results passing 695 values between stages. Basically, the outputs of program X and inputs 696 of program Y are considered to match: 697 698 * for entire programs, if the set of declared inputs and outputs in 699 the programs are identical in name (or location, if assigned), type, 700 and qualification; or 701 702 * for individual inputs, if the input has a matching output with 703 compatible type and qualification, if both variables use the same 704 location layout qualifier. 705 706 The idea behind the exact matching requirement is that if you have 707 identical declarations on both sides of the interface, the 708 compiler/linker can employ a deterministic algorithm to assign locations 709 internally, based solely on the declared inputs/outputs. For such an 710 algorithm, the variables on both sides of the interface will naturally 711 get the same locations. For a program pipeline with separate vertex, 712 geometry, and fragment programs with "entire program" matches, this 713 implies that: 714 715 * vertex outputs and geometry inputs are declared identically, and so 716 the compiler will assign the same locations; and 717 718 * geometry outputs and fragment inputs are declared identically, and 719 so the compiler will assign the same locations. 720 721 The problem with this extension is that its implementation introduces 722 one additional constraint -- the internal location assigned to a 723 passthrough geometry shader input must match the location assigned to 724 the matching implicitly-declared output. Adding this constraint to the 725 two bullets in the previous example implies that for any variable used 726 as a passthrough input in a geometry shader, there is one additional 727 rule: 728 729 * the vertex outputs and fragment inputs matching a passthrough 730 geometry shader input must have the same locations. 731 732 However, when the vertex and fragment program are linked, they have no 733 idea which variables might interface with a passthrough geometry shader 734 input. And there is clearly no constraint that the vertex outputs and 735 fragment inputs be declared identically -- some vertex outputs may be 736 consumed by the geometry shader, and some fragment inputs may be 737 produced (not by copy) by the geometry shader. Generating matching 738 locations without more information is basically impossible. 739 740 As a result, we require that the passthrough geometry shader inputs in 741 separable programs must be declared with a location. Combining this 742 restriction with normal shader interface matching rules, it implies that 743 "matching" vertex outputs and fragment inputs must also be declared with 744 identical locations to get a complete interface match. 745 746 This limitation doesn't apply to non-separable programs; the linker is 747 able to see all program interfaces and can assign internal locations for 748 all stages that satisfy the relevant constraints. The linker could 749 successfully assign internal locations for separable programs containing 750 multiple stages (e.g., GS+FS with no VS), but we chose to apply this 751 restriction to all separable programs for simplicity. 752 753 (17) When an input block or any of its members is qualified with 754 "passthrough", this extension creates an implicitly declared 755 corresponding output block containing all members to be passed 756 through. How does this feature interact with the "location" layout 757 qualifier? 758 759 RESOLVED: All members of the output block are treated as having 760 explicitly assigned locations inherited from matching input block 761 members. For example, if you had a geometry shader input block declared 762 as: 763 764 layout(location=0) in Block { 765 layout(passthrough) vec4 a; // assigned location 0 766 vec4 b; // assigned location 1 767 layout(passthrough) vec4 c; // assigned location 2 768 } v_in[]; 769 770 the corresponding output block is treated as though it were declared as: 771 772 out Block { 773 layout(location=0) vec4 a; 774 layout(location=2) vec4 c; 775 }; 776 777 A fragment shader matching with such a shader must include a similar 778 input block declaration to get a complete interface match. 779 780 To avoid the need to use location layout qualifiers on a 781 member-by-member basis, a shader author using blocks with location 782 qualifiers could choose to segregate passthrough and other inputs into 783 separate blocks. Alternately, all the passthrough inputs could be 784 placed at the beginning of the geometry input block, which would result 785 in a "normal" output block, except that the non-passthrough inputs would 786 be dropped. 787 788 (18) Do built-in or user-defined inputs qualified with "passthrough" need 789 to be "arrayed"? 790 791 RESOLVED: Yes. Normal geometry shader inputs must be declared in 792 "arrayed" form, where each vertex has its own set of inputs. Blocks 793 must be declared as an array of instances: 794 795 in Block { 796 vec4 a; 797 } v_in[]; 798 799 and non-block inputs must be declared as arrays: 800 801 in vec4 a[]; // <a> is indexed by input vertex number 802 803 It is illegal to declare non-arrayed geometry shader inputs, since it 804 wouldn't be clear which vertex to use when accessing such inputs. 805 806 Passthrough geometry shaders don't change this requirement. 807 Additionally, the requirement still applies even if no code in the 808 passthrough geometry shader reads from the input. Note that in older 809 versions of this specification, some examples declared passthrough 810 inputs that were missing the per-vertex array declaration. 811 812Revision History 813 814 Revision 4, 2017/02/15 (pbrown) 815 - Fix syntax issues in various sample code, including the introduction. 816 Passthrough inputs need to be declared as "arrayed" (with a separate 817 block instance for each vertex). Added issue (18) to clarify further. 818 819 Revision 3, 2015/04/06 (mjk) 820 - Fix typos 821 822 Revision 2, 2015/03/27 823 - Add ES interactions 824 825 Revision 1 826 - Internal revisions. 827 828