1Name 2 3 EXT_separate_shader_objects 4 5Name Strings 6 7 GL_EXT_separate_shader_objects 8 9Contact 10 11 Mark Kilgard, NVIDIA (mjk 'at' nvidia.com) 12 13Contributors 14 15 Pat Brown 16 Eric Werness 17 Robert Ohannessian 18 Jason Green, TransGaming 19 Kevin Rogovin 20 Greg Roth 21 22Status 23 24 Shipping in NVIDIA 190.00 release drivers 25 26 NOTE: there is an unrelated OpenGL ES extension also named 27 "GL_EXT_separate_shader_objects", found in the OpenGL ES extension 28 registry at http://www.khronos.org/registry/gles/ . These two extensions 29 have similar purposes, but completely different interfaces. 30 31Version 32 33 Last Modified Date: March 7, 2013 34 Version: 11 35 36Number 37 38 377 39 40Dependencies 41 42 Written based on the wording of the OpenGL 3.0 (August 11, 2008) 43 specification. 44 45 This extension requires OpenGL 2.0 or ARB_shader_objects. 46 47 This extension depends on ARB_geometry_shader4, EXT_geometry_shader4, 48 and/or NV_geometry_shader4. 49 50Overview 51 52 Prior to this extension, GLSL requires multiple shader domains 53 (vertex, fragment, geometry) to be linked into a single monolithic 54 program object to specify a GLSL shader for each domain. 55 56 While GLSL's monolithic approach has some advantages for 57 optimizing shaders as a unit that span multiple domains, all 58 existing GPU hardware supports the more flexible mix-and-match 59 approach. 60 61 HLSL9, Cg, the prior OpenGL assembly program extensions, and game 62 console programmers favor a more flexible "mix-and-match" approach to 63 specifying shaders independently for these different shader domains. 64 Many developers build their shader content around the mix-and-match 65 approach where they can use a single vertex shader with multiple 66 fragment shaders (or vice versa). 67 68 This keep-it-simple extension adapts the "mix-and-match" shader 69 domain model for GLSL so different GLSL program objects can be bound 70 to different shader domains. 71 72 This extension redefines the operation of glUseProgram(GLenum program) 73 to be equivalent to: 74 75 glUseShaderProgramEXT(GL_VERTEX_SHADER, program); 76 glUseShaderProgramEXT(GL_GEOMETRY_SHADER_EXT, program); 77 glUseShaderProgramEXT(GL_FRAGMENT_SHADER, program); 78 glActiveProgramEXT(program); 79 80 You can also call these commands separately to bind each respective 81 domain. The GL_VERTEX_SHADER, GL_GEOMETRY_SHADER_EXT, and 82 GL_FRAGMENT_SHADER tokens refer to the conventional vertex, geometry, 83 and fragment domains respectively. glActiveProgramEXT specifies 84 the program that glUniform* commands will update. 85 86 Separate linking creates the possibility that certain output varyings 87 of a shader may go unread by the subsequent shader inputting varyings. 88 In this case, the output varyings are simply ignored. It is also 89 possible input varyings from a shader may not be written as output 90 varyings of a preceding shader. In this case, the unwritten input 91 varying values are undefined. Implementations are encouraged to 92 zero these undefined input varying values. 93 94 This extension is a proof-of-concept that separate shader objects 95 can work for GLSL and a response to repeated requests for this 96 functionality. There are various loose ends, particularly when 97 dealing with user-defined varyings. The hope is a future extension 98 will improve this situation. 99 100New Procedures and Functions 101 102 void UseShaderProgramEXT(enum type, uint program); 103 104 void ActiveProgramEXT(uint program); 105 106 uint CreateShaderProgramEXT(enum type, const char *string); 107 108New Tokens 109 110 Accepted by <type> parameter to GetIntegerv and GetFloatv: 111 112 ACTIVE_PROGRAM_EXT 0x8B8D (alias for CURRENT_PROGRAM) 113 114Additions to Chapter 2 of the OpenGL 3.0 Specification (OpenGL Operation) 115 116 -- Section 2.20.2 "Program Objects" (page 91) 117 118 Add this paragraph after the 6th paragraph: 119 120 "The command 121 122 uint CreateShaderProgramEXT(enum type, const char *sting); 123 124 creates a stand-alone program from a source code string for a single 125 shader type. This command is equivalent to the following command 126 sequence: 127 128 const uint shader = CreateShader(type); 129 if (shader) { 130 const int len = (int) strlen(string); 131 ShaderSource(shader, 1, &string, &len); 132 CompileShader(shader); 133 const uint program = CreateProgram(); 134 if (program) { 135 int compiled = FALSE; 136 GetShaderiv(shader, COMPILE_STATUS, &compiled); 137 if (compiled) { 138 AttachShader(program, shader); 139 LinkProgram(program); 140 DetachShader(program, shader); 141 } 142 143 // Possibly... 144 if (active-user-defined-varyings-in-linked-program) { 145 append-error-to-info-log 146 set-program-link-status-false 147 } 148 149 append-shader-info-log-to-program-info-log 150 } 151 DeleteShader(shader); 152 return program; 153 } else { 154 return 0; 155 } 156 157 Notice the program may not actually link if the linked program would 158 contain active user-defined varyings (because such varyings would 159 not be well-defined for a single shader domain). If this situation 160 arises, the info log may explain this. 161 162 Because no shader is returned by CreateShaderProgramEXT and the shader 163 that is created is deleted in the course of the command sequence, 164 the info log of the shader object is copied to the program so the 165 shader's failed info log for the failed compilation is accessible 166 to the application." 167 168 Replace the 7th paragraph with: 169 170 "If a valid executable is created, it can be made part of the current 171 rendering state with the command: 172 173 void UseShaderProgramEXT(enum type, uint program); 174 175 where type is one of VERTEX_SHADER, GEOMETRY_SHADER_ARB, or 176 FRAGMENT_SHADER program shader types, and program is the program 177 object program containing valid executable code, i.e. has been linked 178 successfully. Based on the type, the program becomes the current 179 vertex, fragment, or geometry shader program respectively and the 180 command installs the executable code as part of the respective current 181 rendering state. If UseShaderProgramEXT is called with program set 182 to zero, it is as if the GL has no respective (vertex, geometry, 183 or fragment) programmable stage configured and the corresponding 184 fixed-function path will be used instead. If program has not been 185 successfully linked, the error INVALID_OPERATION is generated and 186 the respective current shader state is not modified. 187 188 The command 189 190 void ActiveProgramEXT(uint program); 191 192 sets the linked program named by program to be the active program 193 (discussed later in the "Uniform Variables" subsection of section 194 2.20.3). If program has not been successfully linked, the error 195 INVALID_OPERATION is generated and active program is not modified. 196 197 The command 198 199 void UseProgram(uint program); 200 201 is equivalent (modulo errors) to calling 202 203 UseShaderProgramEXT(VERTEX_SHADER, program); 204 UseShaderProgramEXT(GEOMETRY_SHADER_EXT, program); 205 UseShaderProgramEXT(FRAGMENT_SHADER, program); 206 ActiveProgramEXT(program); 207 208 If a program object contains multiple shader types but is not bound 209 for all its supported shader types, the program object's shader 210 types not bound do not affect GL's current rendering operation." 211 212 -- Section 2.15.3 "Shader Variables" (page 97) 213 214 Replace the 15th paragraph of the "Uniform Variables" section: 215 216 "To load values into the uniform variables of the active program 217 object (specified by ActiveProgramEXT), use the commands ..." 218 219 Change the last bullet in the "Uniform Variables" section to: 220 221 "* if there is no active program in use." 222 223 -- Section 2.20.4 "Shader Execution" (page 103) 224 225 Change the first paragraph to read: 226 227 "If a successfully linked program object that contains a vertex 228 shader is made current by calling UseShaderProgramEXT with a type of 229 VERTEX_SHADER, the executable version of the vertex shader is used to 230 process incoming vertex values rather than the fixed-function vertex 231 processing described in section 2.11 through 2.14. In particular, 232 ..." 233 234 -- Section 2.20.5 "Required State" (page 109) 235 236 Change the last paragraph to read: 237 238 "Additionally, four unsigned integers (initially all zero) are 239 required to hold the each respective name of the current vertex 240 shader program, current geometry shader program, current fragment 241 shader program, and active program respectively." 242 243Additions to Chapter 3 of the OpenGL 3.0 Specification (Rasterization) 244 245 -- Section 3.12 "Fragment Shaders" (page 231) 246 247 Replace the second to the last paragraph with: 248 249 "When the current fragment shader program object currently includes 250 a fragment shader, its fragment shader is considered active, and is 251 used to process fragments. If the fragment shader program object 252 has no fragment shader, or no fragment shader program object is 253 currently in use, the fixed-function fragment processing operations 254 described in the previous sections are used." 255 256 -- Section 3.12.1 "Shader Variables" (page 232) 257 258 Add this paragraph after the third paragraph: 259 260 "User-defined varying values are well-defined only when the fragment 261 shader program object and the preceding programmable shading stage, 262 either the geometry shader stage if the geometry shader program 263 object contains geometry shader or else the vertex shader stage 264 if the vertex shader program object contains a vertex shader, are 265 the same program object. So user-defined varying values are only 266 well-defined when both the varying variable's output shader and 267 input shader are the same program object. 268 269 In order to ensure well-defined behavior between a fragment shader 270 program with a different preceding geometry shader program or 271 vertex shader program when the current geometry shader program is 272 zero, applications must use the built-in varying variables such 273 as gl_TexCoord[0]. If the current fragment shader program object 274 uses user-defined input varying variables when the preceded current 275 geometry shader program is not the same program object or, in the 276 case the geometry shader program is zero, the preceding current 277 vertex shader program object is not the same program object, then 278 the values of such input varying variables are undefined. 279 280 The state of user-defined varying inputs to a fragment shader 281 are undefined /even if/ the preceding shader has varying outputs 282 that match the same name and type of the subsequent shader. 283 Implementations are encouraged but not required to force these 284 undefined input varying variables to zero." 285 286Additions to Chapter 4 of the OpenGL 3.0 Specification (Per-Fragment 287Operations and the Frame Buffer) 288 289 None 290 291Additions to Chapter 5 of the OpenGL 3.0 Specification (Special 292Functions) 293 294 None 295 296Additions to Chapter 6 of the OpenGL 3.0 Specification (State and 297State Requests) 298 299 -- Section 5.4 "Display Lists" (page 311) 300 301 Add "CreateShaderProgramEXT" to the "Program and shader objects" 302 list of commands that cannot be compiled into a display list but 303 are instead executed immediately. 304 305Additions to the AGL/GLX/WGL Specifications 306 307 None 308 309Additions to the OpenGL Shading Language 310 311 None 312 313Additions to the ARB_geometry_shader4 specification 314 315 -- Section 2.16, Geometry Shaders 316 317 Replace the 3rd and 4th paragraphs to read: 318 319 "Geometry shaders are created as described in section 2.15.1 using a 320 type parameter of GEOMETRY_SHADER_ARB. They are attached to and used 321 in program objects as described in section 2.15.2. When a geometry 322 shader program object currently in use includes a geometry shader, 323 its geometry shader is considered active, and is used to process 324 primitives. If the geometry shader program object has no geometry 325 shader, or no program object is in use, this new primitive processing 326 pipeline stage is bypassed. 327 328 A program object that includes a geometry shader without a vertex 329 shader must only use built-in input varying variables; otherwise 330 a link error may occur." 331 332 -- Section 2.16.4, Geometry Shader Execution Environment 333 334 Change the first paragraph to read: 335 336 "If a successfully linked program object that contains a geometry shader is 337 made current as the geometry shader program object by calling 338 UseShaderProgramEXT with a type of GL_GEOMETRY_SHADER_ARB, the 339 executable version of the geometry shader is used to process 340 primitives resulting from the primitive assembly stage." 341 342 Add these paragraphs to the end of the section: 343 344 "User-defined varying values are well-defined only when the geometry 345 shader program object and the preceding vertex shader program object 346 are the same program object. So user-defined varying values are only 347 well-defined when both the varying variable's output shader and 348 input shader are the same program object. 349 350 In order to ensure well-defined behavior between a geometry shader 351 program with a different preceding vertex shader program, applications 352 must use the built-in varying variables such as gl_TexCoord[0]. 353 If the current geometry shader program object uses user-defined 354 input varying variables when the preceded current vertex shader 355 program object is not the same program object, then the values of 356 such input varying variables are undefined. 357 358 The state of user-defined varying inputs to a geometry shader 359 are undefined /even if/ the preceding vertex shader has varying 360 outputs that match the same name and type of the subsequent shader. 361 Implementations are encouraged but not required to force these 362 undefined input varying variables to zero." 363 364GLX Protocol 365 366 UNDER DEVELOPMENT 367 368Errors 369 370 UseShaderProgramEXT generates INVALID_ENUM if the type parameter is 371 not one of VERTEX_SHADER, GEOMETRY_SHADER_ARB, or FRAGMENT_SHADER. 372 373 UseShaderProgramEXT generates INVALID_OPERATION if the program 374 parameter has not been successfully linked. 375 376 UseShaderProgramEXT generates INVALID_OPERATION if transform feedback 377 is active. 378 379 ActiveProgramEXT generates INVALID_OPERATION if the program parameter 380 has not been successfully linked. 381 382 LinkProgram NO LONGER generates an INVALID_OPERATION if the program 383 object has a geometry shader attached and no vertex shader attached 384 as long as the geometry shader uses only built-in varying input 385 variables. 386 387Dependencies on ARB_geometry_shader4, EXT_geometry_shader4, and/or NV_geometry_shader4 388 389 If none of ARB_geometry_shader4, EXT_geometry_shader4, or 390 NV_geometry_shader4 are supported by the implementation, ignore all 391 references to geometry shaders and generate an INVALID_ENUM error 392 when UseShaderProgramEXT is called with the token GEOMETRY_SHADER_ARB. 393 394New State 395 396 Remove CURRENT_PROGRAM from table 6.30 (Program Object State) and 397 append these rows: 398 399 Get Value Type Get Command Initial Value Description Sec Attribute 400 ------------------- ---- ----------- ------------- ------------------------ ------ --------- 401 ACTIVE_PROGRAM_EXT Z+ GetIntegerv 0 The program object 2.20.2 - 402 (alias for that Uniform* commands 403 CURRENT_PROGRAM) update 404 VERTEX_SHADER Z+ GetIntegerv 0 Name of current vertex 2.20.2 - 405 shader program object 406 GEOMETRY_SHADER_ARB Z+ GetIntegerv 0 Name of current geometry 2.20.2 - 407 shader program object 408 FRAGMENT_SHADER Z+ GetIntegerv 0 Name of current fragment 2.20.2 - 409 shader program object 410 411New Implementation Dependent State 412 413 None 414 415Issues 416 417 1. What should this extension be called? 418 419 RESOLVED: EXT_separate_shader_objects 420 421 The adjective "separate" is used in several extension names 422 (EXT_blend_equation_separate, EXT_blend_func_separate, 423 EXT_separate_specular_color, ATI_separate_stencil) when joined 424 state is made configurable separately. 425 426 The phrase "shader_objects" refers generally to GLSL shader 427 objects, matching the ARB_shader_objects name. 428 429 Whether the name should be "separate_shader_objects" 430 or "shader_objects_separate" is less clear. The various 431 "separate" extensions have different conventions as to whether 432 separate is prefixed or suffixed with the separated state. 433 The prefixed form is more natural to say aloud, is consistent 434 with the ATI_separate_stencil naming approach, and abbreviates 435 to SSO (instead of the inopportune abbreviation SOS). 436 437 2. What happens to a user-defined input varying variable that are 438 not written by a preceding shader's write to the corresponding 439 output varying variable. 440 441 RESOLVED: The input variable variable's value is left undefined. 442 Implementations are encouraged but not required to zero the 443 value. 444 445 GLSL has a "rendezvous by name" model for connecting varying 446 output variables to varying input variables of a subsequent 447 shader. With separate shaders, there's no assurance whether a 448 preceding shader will write a given user-defined input varying 449 variable. HLSL9, Cg, and OpenGL assembly extension programs 450 handle this situation by with "rendezvous by API resource" model. 451 In GLSL terms, this means separate GLSL shaders /must/ communicate 452 by built-in varying variables rather than user-defined varying 453 variables. 454 455 It is undesirable from a performance standpoint to attempt to 456 support "rendezvous by name" for arbitrary separate shaders 457 because the separate shaders won't be naturally compiled to 458 match their varying inputs and outputs of the same name without 459 a special link step. Such a special link would introduce an 460 extra validation overhead to binding separate shaders. The link 461 itself would have to be deferred until glBegin time since separate 462 shaders won't match when transitioning from one set of consistent 463 shaders to another. This special link would still create errors 464 or undefined behavior when the names of input and output varyings 465 matched but their types did not match. 466 467 Also the expectation from other shading APIs that support 468 mix-and-match shader usage is that "rendezvous by API resource" 469 is the expected norm. 470 471 Specifying the behavior being undefined allows a future ARB 472 version of this extension to be more specific without encumbering 473 this extension with enforcing a specific error. 474 475 3. Do different program objects currently used by different shader 476 types share a single name space for uniforms? 477 478 RESOLVED: No, different program objects have their own separate 479 name space for uniforms and each has locations specific to its 480 unique program object. 481 482 4. How do the glUniform* commands determine what program object 483 to query? 484 485 RESOLVED: This extension introduces the active program specified 486 by glActiveProgramEXT (similar to the active texture selector 487 specified by glActiveTexture) to specify the selector used by 488 glUniform* commands. 489 490 This active program is simply a selector and doesn't actually 491 control any rendering operation. 492 493 The active program can be queried with glGetIntegerv with 494 the GL_ACTIVE_PROGRAM_EXT token which is an alias for 495 GL_CURRENT_PROGRAM. 496 497 As an alternative to setting the GL_ACTIVE_PROGRAM_EXT selector 498 with glActiveProgramEXT, applications are instead encouraged 499 to use the glProgramUniform* commands introduced by the 500 EXT_direct_state_access extension which do not depend on a 501 selector but specify the program object with which to update 502 the specified uniform location explicitly. 503 504 5. Do the glGetUniform* queries depend on the active program state 505 (GL_ACTIVE_PROGRAM_EXT)? 506 507 RESOLVED: No, the glGetUniform* queries take the program 508 object for the query as an explicit parameter to the query. 509 These commands do not rely on a selector. 510 511 6a. Should the fragment shader program object be allowed to changed 512 within transform feedback mode? 513 514 RESOLVED: No, this should generate a GL_INVALID_OPERATION error. 515 516 The OpenGL 3.0 and EXT_transform_feedback specifications say 517 glUseProgram generates a GL_INVALID_OPERATION error when transform 518 feedback is active. 519 520 The rationale for this is that user-defined varying outputs from 521 the vertex or geometry shader might change. 522 523 Perhaps it is desirable to allow different shader program objects 524 when transform feedback mode is active, but this extension 525 doesn't change the existing GLSL error behavior. In fact, 526 glUseShaderProgramEXT generate the same error glUseProgram does. 527 528 6b. Should the active program be allowed to changed within transform 529 feedback mode? 530 531 RESOLVED: Yes. 532 533 The active program simply allows uniforms to be changed but 534 doesn't actually change how the graphics pipeline itself is 535 configured or what programs are used for vertex, geometry, 536 and fragment processing. 537 538 7. What if a program object contains shaders from two domains, say 539 both a vertex shader and a geometry shader, and the program object 540 is just used as the current fragment shader program object? 541 542 RESOLVED: The vertex shader within the program object is 543 simply ignored. 544 545 8. What if a program object contains both a vertex and fragment 546 shader and this program object is bound to both the current 547 vertex shader and fragment shader program object but there is 548 also a different geometry shader program object bound? 549 550 RESOLVED: This works as long as the vertex shader and fragment 551 shader rely on built-in varying variables to communicate and don't 552 depend on passing values between each other with user-defined 553 varying variables because such variables are undefined if an 554 intervening different geometry shader program object is currently 555 used. Specifically, the vertex shader will output to its 556 built-in varying output variables and the different geometry 557 shader program object can read those built-in varying values 558 through input varying variables. Likewise the fragment shader 559 can use built-in varying input variables to get varying data 560 from the different geometry shader program object. 561 562 9. Is glUseShaderProgramEXT allowed to be compiled within a 563 display list? 564 565 RESOLVED: Yes, just like glUseProgram is allowed within a 566 display list. 567 568 10. Should there be some easier to use API for creating a GLSL 569 program that programs a single shader type? 570 571 RESOLVED: Yes, see the glCreateShaderProgramEXT command. 572 573 The existing GLSL API for creating a GLSL program involves a lot 574 of steps to support multiple source strings, re-specification of 575 source code, attaching and detaching multiple shader objects, 576 and cross-domain linking. These features are not particularly 577 relevant for creating separate shader programs. 578 579 11. Can glCreateShaderProgramEXT be compiled into a display list? 580 581 RESOLVED: No. 582 583 glCreateShaderProgramEXT is equivalent to a sequence of commands 584 that are themselves not allowed to be compiled into a display 585 list. 586 587 12. Should glCreateShaderProgramEXT allow user-defined varyings? 588 589 RESOLVED: User-defined varyings are permitted (without error) 590 but shouldn't be used because their behavior is not defined. 591 592 glCreateShaderProgramEXT is likely to be used for compiling 593 separate shaders. The tenative resolution to issue 2 says the 594 values of user-defined varying input varaibles are undefined if 595 the preceding shader doesn't belong to the same program object. 596 Since the programs returned by glCreateShaderProgramEXT are 597 always for a single domain, there's no point allowing user-defined 598 varyings if they can't be assumed to be well-defined. 599 600 13. How are interpolation modifiers handled for separate shader 601 programs? 602 603 RESOLVED: For now, interpolation modifiers aren't supported 604 for separate shader object varyings. 605 606 Future resolution: Unfortunately GLSL only provides interpolation 607 modifiers for user-defined varyings which aren't well-defined 608 for separate shader programs. 609 610 In the short-term, interpolation modifiers aren't commonly used 611 so not supporting interpolation modifiers for seperate GLSL 612 shader programs is probably acceptable. 613 614 Long-term, GLSL can be extended with #pragma constructs that 615 specify to the compiler the interpolation modifier for a given 616 fragment shader built-in varying. Something like: 617 618 #pragma interpolation(gl_TexCoord[0], centroid) 619 #pragma interpolation(gl_TexCoord[1], flat) 620 #pragma interpolation(gl_TexCoord[2], smooth) 621 #pragma interpolation(gl_TexCoord[3], invariant) 622 #pragma interpolation(gl_TexCoord[4], noperspective) 623 624 This pragma is only legal within a fragment shader compilation 625 unit. The pragma can be specified multiple times, but 626 inconsistent specification of a specific built-in varying's 627 interpolation is not allowed. 628 629 Alternatively, this extenion could add new built-in input varying 630 variables for the fragment shader: 631 632 // TexCoord category 633 varying in centroid vec4 gl_CentroidTexCoord[]; 634 varying in centroid noperspective vec4 gl_CentroidNoPerspectiveTexCoord[]; 635 varying in float vec4 gl_FlatTexCoord[]; 636 varying in noperspective vec4 gl_NoPerspectiveTexCoord[]; 637 varying in ivec4 gl_IntTexCoord[]; 638 639 // Color category 640 varying in centroid vec4 gl_CentroidColor; 641 642 // Secondary color category 643 varying in centroid vec4 gl_CentroidSecondaryColor; 644 645 // Fog category 646 varying in centroid vec4 gl_CentroidFogFragCoord; 647 648 It would be an error to use a varying from more than one category 649 in a single program. 650 651 14. Should glLinkProgram work to re-link a shader created with 652 glCreateShaderProgramEXT? 653 654 RESOLVED: NO because the shader created by glCreateShaderProgram 655 is detached and deleted as part of the glCreateShaderProgramEXT 656 sequence. This means if you call glLinkProgram on a program 657 returned from glCreateShaderProgram, you'll find the re-link 658 fails because no shader object is attached. 659 660 An application is free to attach one or more new shader objects 661 to the program and then relink would work. 662 663 This is fine because re-linking isn't necessary/expected. 664 665 15. Wouldn't re-linking be necessary if the application wanted to 666 use glBindAttribLocation to assign a user-defined attribute to 667 a specific vertex attribute? 668 669 RESOLVED: Yes and that's a problem if glCreateShaderProgramEXT 670 is used because the shader object is detached and deleted. 671 672 User-defined attributes will work when glCreateShaderProgramEXT 673 is used to easily create a vertex shader program, but the 674 appliation must be satisfied with the implementation-dependent 675 linker-assigned user-defined attributes returned by 676 glGetAttribLocation. 677 678 We could provide a new set of built-in attributes that correspond 679 to declared as: 680 681 attribute vec4 gl_VertexAttrib[]; 682 683 How would these attributes map to the other built-in attributes? 684 That would depend on the implementation. As with ARB_vertex_program, 685 some implementations could choose to alias such generate vertex attributes 686 with conventional vertex attributes (color, fog coord, etc.) or 687 an implementation could treat the generic attributes as disjoint 688 from the conventional vertex attributes. 689 690 If this is unsatisfactory, the solution is to avoid using 691 glCreateShaderProgramEXT and instead use the traditional GLSL 692 approach for creating programs (create shader, compile shader, 693 attach shader, bind attributes, link shader, use shader). 694 695 Demonstrating how to workaround this particular issue, here's 696 an example of creating and using a vertex shader for use with 697 separate shader objects that includes explicit binding of output 698 varyings to fragment data locations. First the shader: 699 700 varying in vec4 attribA; 701 varying in vec4 attribB; 702 void main() 703 { 704 gl_Position = ftransform(); 705 gl_FrontColor = attribA; 706 gl_BackColor = attribB; 707 } 708 709 Now creating and using a linked program from this shader where 710 attribA is initialized by vertex attribute 5 and attribB is 711 initialized by vertex attribute 7. 712 713 const GLuint shader = glCreateShader(GL_VERTEX_SHADER); 714 if (shader) { 715 const GLint len = (GLint) strlen(aboveShaderString); 716 glShaderSource(shader, 1, &aboveShaderString, &len); 717 glCompileShader(shader); 718 const uint program = glCreateProgram(); 719 if (program) { 720 GLint compiled = FALSE; 721 glGetShaderiv(shader, COMPILE_STATUS, &compiled); 722 if (compiled) { 723 glAttachShader(program, shader); 724 725 // Crucial code that glCreateShaderProgramEXT doesn't do 726 glBindAttribLocation(program, 5, "attribA"); 727 glBindAttribLocation(program, 7, "attribB"); 728 729 glLinkProgram(program); 730 glDetachShader(program, shader); 731 732 // Show this program can actually be used as a vertex shader 733 glUseShaderProgramEXT(GL_VERTEX_SHADER, program); 734 } 735 } 736 glDeleteShader(shader); 737 return program; 738 } else { 739 return 0; 740 } 741 742 Optionally, the glDetachShader and glDeleteShader commands could 743 be removed to allow this program to be re-linked after different 744 glBindAttribLocation calls. 745 746 16. Can you use glBindFragDataLocation to direct varying output 747 variables from a fragment shader program created by 748 glCreateShaderProgramEXT to specific color buffers? 749 750 RESOLVED: NO for much the same reason you can't do this with 751 attributes as described in issue 15. But you could create the 752 program with the standard GLSL creation process where you attach 753 your own shaders and relink. 754 755 For fragment shader programs created with 756 glCreateShaderProgramEXT, there is already the gl_FragData[] 757 builtin to output to numbered color buffers. For integer 758 framebuffers, we would need to add: 759 760 varying out ivec4 gl_IntFragData[]; 761 762 User-defined output fragment shader varyings can still be used 763 as long as the application is happy with the linker-assigned 764 locations. 765 766 Demonstrating how to workaround this particular issue, here's 767 an example of creating and using a fragment shader for use with 768 separate shader objects that includes explicit binding of output 769 varyings to fragment data locations. First the shader: 770 771 varying out ivec4 bufferA; 772 varying out ivec4 bufferB; 773 void main() 774 { 775 bufferA = ivec4(1,2,3,4); 776 bufferB = ivec4(5,6,7,8); 777 } 778 779 Now creating and using a linked program from this shader where 780 bufferA outputs to color buffer 0 and bufferB outputs to color 781 buffer 1: 782 783 const GLuint shader = glCreateShader(GL_FRAGMENT_SHADER); 784 if (shader) { 785 const GLint len = (GLint) strlen(aboveShaderString); 786 glShaderSource(shader, 1, &aboveShaderString, &len); 787 glCompileShader(shader); 788 const uint program = glCreateProgram(); 789 if (program) { 790 GLint compiled = FALSE; 791 glGetShaderiv(shader, COMPILE_STATUS, &compiled); 792 if (compiled) { 793 glAttachShader(program, shader); 794 795 // Crucial code that glCreateShaderProgramEXT doesn't do 796 glBindFragDataLocation(program, 0, "bufferA"); 797 glBindFragDataLocation(program, 1, "bufferB"); 798 799 glLinkProgram(program); 800 glDetachShader(program, shader); 801 802 // Show this program can actually be used as a fragment shader 803 glUseShaderProgramEXT(GL_FRAGMENT_SHADER, program); 804 } 805 } 806 glDeleteShader(shader); 807 return program; 808 } else { 809 return 0; 810 } 811 812 Optionally, the glDetachShader and glDeleteShader could be 813 removed to allow this program to be re-linked after different 814 glBindFragDataLocation calls. 815 816 17. Can you output varyings from a seperate shader program created 817 with glCreateShaderProgramEXT? 818 819 RESOLVED: No. 820 821 glTransformFeedbackVaryings requires a re-link to take effect on a 822 program. glCreateShaderProgramEXT detaches and deletes the shader 823 object use to create the program so a glLinkProgram will fail. 824 825 You can still create a vertex or geometry shader program 826 with the standard GLSL creation process where you could use 827 glTransformFeedbackVaryings and glLinkProgram. 828 829 18. I just don't get it? Why is it such a big deal to just require 830 apps to link all their vertex and fragment shaders together? 831 Please explain a situation where mix-and-match shaders is 832 substantially better than GLSL as it exists without this 833 extension? 834 835 RESOLUTION: Consider the (not uncommon) case of a vertex shader 836 for skinning a character. The vertex shader is used in four 837 distinct types of rendering passes, each using the one vertex 838 shader but different fragment shaders. 839 840 For GLSL today, this situation today requires 4 program objects, 841 each containing the one vertex shader paired with each one of 842 the fragment shaders. 843 844 The one vertex shader has an array of dozens of skinning matrices 845 along with numerous other uniform parameters. 846 847 Each fragment shader has its own different set of uniforms too. 848 849 Each GLSL program object has its own (combined) set of GLuint 850 locations for the active uniforms of the vertex and fragment 851 shaders objects linked into the particular program object. 852 853 The locations for a given program object are arbitrary and 854 the location values of two distinct program objects have no 855 correlation. This is true even when they each link in the same 856 vertex shader (or alternatively same fragment shader). 857 858 Now the application is saddled with the burden of managing 859 distinct location values for the same vertex shader skinning 860 matrices and other uniform variables as well as making sure 861 the values of these variables are mirroed over all four program 862 objects containing the skinning vertex shader. 863 864 What's worse is despite all the program objects being loaded 865 with the same vertex shader uniform variables for skinning, the 866 driver is exceedingly unlikely to recoginize that binding from 867 one of these program objects to another is going to result in 868 no actual vertex shader state change. Noticing that the uniform 869 vertex shader variables are changing in lock-step over a series 870 of program objects (when the uniform fragment shader variables 871 ARE allowed to diverge) is exceedingly expensive. 872 873 This situation is simple to optimize with mix-and-match shaders 874 because there is just a single vertex shader to worry about. 875 It's only the current fragment shader program that is changing 876 so only the fragment shader state must be updated/re-validated. 877 878 It's also much easier and less expensive for the application to 879 update the vertex shader state because there is just one copy 880 of it to update. 881 882 19. In case of indirect rendering, should glCreateShaderProgramEXT 883 explicitly send string length parameter to server? 884 885 PROPOSED: Yes. Although source code passed to 886 glCreateShaderProgramEXT is NUL terminated, the server can not 887 safely rely on the client to terminate the string so it must 888 add the NUL terminator before passing the protocol buffer to 889 the GL command processor. The string length is needed to do this 890 accurately. 891 892 20. Can glCreateShaderProgramEXT support command larger than the 893 maximum command length supported by a single command? 894 895 PROPOSED: Yes. Source code passed to glCreateShaderProgramEXT is 896 unbounded. Command length can be more than the maximum command 897 length supported by a single command. Support for "large single" 898 command needs to be added. 899 900 901 902Revision History 903 904 Rev. Date Author Changes 905 ---- -------- -------- ---------------------------------------- 906 1 11/06/08 mjk Initial revision 907 2 11/10/08 mjk add glCreateShaderProgramEXT 908 3 11/12/08 mjk fixed glCreateShaderProgramEXT 909 add issues 12 and 13 910 4 11/14/08 mjk issues 13 through 17 911 5 12/03/08 mjk glActiveProgram replaces 912 GL_UNIFORM_SHADER_EXT 913 6 04/01/09 mjk corrections from Jason Green 914 7 08/12/09 mjk Marked as shipping, resolve and 915 improve issues 15 & 16 916 8 09/09/09 mjk Assign number 917 9 09/09/09 mjk Fix transposed page number 918 10 24/02/10 srahman added glx protocol for 919 glCreateShaderProgramEXT 920 added issues 19 and 20 921 11 03/07/13 Jon Leech Added note about the unrelated OpenGL ES 922 extension of the same name. 923