| Name |
| |
| EXT_separate_shader_objects |
| |
| Name Strings |
| |
| GL_EXT_separate_shader_objects |
| |
| Contact |
| |
| Mark Kilgard, NVIDIA (mjk 'at' nvidia.com) |
| |
| Contributors |
| |
| Pat Brown |
| Eric Werness |
| Robert Ohannessian |
| Jason Green, TransGaming |
| Kevin Rogovin |
| Greg Roth |
| |
| Status |
| |
| Shipping in NVIDIA 190.00 release drivers |
| |
| NOTE: there is an unrelated OpenGL ES extension also named |
| "GL_EXT_separate_shader_objects", found in the OpenGL ES extension |
| registry at http://www.khronos.org/registry/gles/ . These two extensions |
| have similar purposes, but completely different interfaces. |
| |
| Version |
| |
| Last Modified Date: March 7, 2013 |
| Version: 11 |
| |
| Number |
| |
| 377 |
| |
| Dependencies |
| |
| Written based on the wording of the OpenGL 3.0 (August 11, 2008) |
| specification. |
| |
| This extension requires OpenGL 2.0 or ARB_shader_objects. |
| |
| This extension depends on ARB_geometry_shader4, EXT_geometry_shader4, |
| and/or NV_geometry_shader4. |
| |
| Overview |
| |
| Prior to this extension, GLSL requires multiple shader domains |
| (vertex, fragment, geometry) to be linked into a single monolithic |
| program object to specify a GLSL shader for each domain. |
| |
| While GLSL's monolithic approach has some advantages for |
| optimizing shaders as a unit that span multiple domains, all |
| existing GPU hardware supports the more flexible mix-and-match |
| approach. |
| |
| HLSL9, Cg, the prior OpenGL assembly program extensions, and game |
| console programmers favor a more flexible "mix-and-match" approach to |
| specifying shaders independently for these different shader domains. |
| Many developers build their shader content around the mix-and-match |
| approach where they can use a single vertex shader with multiple |
| fragment shaders (or vice versa). |
| |
| This keep-it-simple extension adapts the "mix-and-match" shader |
| domain model for GLSL so different GLSL program objects can be bound |
| to different shader domains. |
| |
| This extension redefines the operation of glUseProgram(GLenum program) |
| to be equivalent to: |
| |
| glUseShaderProgramEXT(GL_VERTEX_SHADER, program); |
| glUseShaderProgramEXT(GL_GEOMETRY_SHADER_EXT, program); |
| glUseShaderProgramEXT(GL_FRAGMENT_SHADER, program); |
| glActiveProgramEXT(program); |
| |
| You can also call these commands separately to bind each respective |
| domain. The GL_VERTEX_SHADER, GL_GEOMETRY_SHADER_EXT, and |
| GL_FRAGMENT_SHADER tokens refer to the conventional vertex, geometry, |
| and fragment domains respectively. glActiveProgramEXT specifies |
| the program that glUniform* commands will update. |
| |
| Separate linking creates the possibility that certain output varyings |
| of a shader may go unread by the subsequent shader inputting varyings. |
| In this case, the output varyings are simply ignored. It is also |
| possible input varyings from a shader may not be written as output |
| varyings of a preceding shader. In this case, the unwritten input |
| varying values are undefined. Implementations are encouraged to |
| zero these undefined input varying values. |
| |
| This extension is a proof-of-concept that separate shader objects |
| can work for GLSL and a response to repeated requests for this |
| functionality. There are various loose ends, particularly when |
| dealing with user-defined varyings. The hope is a future extension |
| will improve this situation. |
| |
| New Procedures and Functions |
| |
| void UseShaderProgramEXT(enum type, uint program); |
| |
| void ActiveProgramEXT(uint program); |
| |
| uint CreateShaderProgramEXT(enum type, const char *string); |
| |
| New Tokens |
| |
| Accepted by <type> parameter to GetIntegerv and GetFloatv: |
| |
| ACTIVE_PROGRAM_EXT 0x8B8D (alias for CURRENT_PROGRAM) |
| |
| Additions to Chapter 2 of the OpenGL 3.0 Specification (OpenGL Operation) |
| |
| -- Section 2.20.2 "Program Objects" (page 91) |
| |
| Add this paragraph after the 6th paragraph: |
| |
| "The command |
| |
| uint CreateShaderProgramEXT(enum type, const char *sting); |
| |
| creates a stand-alone program from a source code string for a single |
| shader type. This command is equivalent to the following command |
| sequence: |
| |
| const uint shader = CreateShader(type); |
| if (shader) { |
| const int len = (int) strlen(string); |
| ShaderSource(shader, 1, &string, &len); |
| CompileShader(shader); |
| const uint program = CreateProgram(); |
| if (program) { |
| int compiled = FALSE; |
| GetShaderiv(shader, COMPILE_STATUS, &compiled); |
| if (compiled) { |
| AttachShader(program, shader); |
| LinkProgram(program); |
| DetachShader(program, shader); |
| } |
| |
| // Possibly... |
| if (active-user-defined-varyings-in-linked-program) { |
| append-error-to-info-log |
| set-program-link-status-false |
| } |
| |
| append-shader-info-log-to-program-info-log |
| } |
| DeleteShader(shader); |
| return program; |
| } else { |
| return 0; |
| } |
| |
| Notice the program may not actually link if the linked program would |
| contain active user-defined varyings (because such varyings would |
| not be well-defined for a single shader domain). If this situation |
| arises, the info log may explain this. |
| |
| Because no shader is returned by CreateShaderProgramEXT and the shader |
| that is created is deleted in the course of the command sequence, |
| the info log of the shader object is copied to the program so the |
| shader's failed info log for the failed compilation is accessible |
| to the application." |
| |
| Replace the 7th paragraph with: |
| |
| "If a valid executable is created, it can be made part of the current |
| rendering state with the command: |
| |
| void UseShaderProgramEXT(enum type, uint program); |
| |
| where type is one of VERTEX_SHADER, GEOMETRY_SHADER_ARB, or |
| FRAGMENT_SHADER program shader types, and program is the program |
| object program containing valid executable code, i.e. has been linked |
| successfully. Based on the type, the program becomes the current |
| vertex, fragment, or geometry shader program respectively and the |
| command installs the executable code as part of the respective current |
| rendering state. If UseShaderProgramEXT is called with program set |
| to zero, it is as if the GL has no respective (vertex, geometry, |
| or fragment) programmable stage configured and the corresponding |
| fixed-function path will be used instead. If program has not been |
| successfully linked, the error INVALID_OPERATION is generated and |
| the respective current shader state is not modified. |
| |
| The command |
| |
| void ActiveProgramEXT(uint program); |
| |
| sets the linked program named by program to be the active program |
| (discussed later in the "Uniform Variables" subsection of section |
| 2.20.3). If program has not been successfully linked, the error |
| INVALID_OPERATION is generated and active program is not modified. |
| |
| The command |
| |
| void UseProgram(uint program); |
| |
| is equivalent (modulo errors) to calling |
| |
| UseShaderProgramEXT(VERTEX_SHADER, program); |
| UseShaderProgramEXT(GEOMETRY_SHADER_EXT, program); |
| UseShaderProgramEXT(FRAGMENT_SHADER, program); |
| ActiveProgramEXT(program); |
| |
| If a program object contains multiple shader types but is not bound |
| for all its supported shader types, the program object's shader |
| types not bound do not affect GL's current rendering operation." |
| |
| -- Section 2.15.3 "Shader Variables" (page 97) |
| |
| Replace the 15th paragraph of the "Uniform Variables" section: |
| |
| "To load values into the uniform variables of the active program |
| object (specified by ActiveProgramEXT), use the commands ..." |
| |
| Change the last bullet in the "Uniform Variables" section to: |
| |
| "* if there is no active program in use." |
| |
| -- Section 2.20.4 "Shader Execution" (page 103) |
| |
| Change the first paragraph to read: |
| |
| "If a successfully linked program object that contains a vertex |
| shader is made current by calling UseShaderProgramEXT with a type of |
| VERTEX_SHADER, the executable version of the vertex shader is used to |
| process incoming vertex values rather than the fixed-function vertex |
| processing described in section 2.11 through 2.14. In particular, |
| ..." |
| |
| -- Section 2.20.5 "Required State" (page 109) |
| |
| Change the last paragraph to read: |
| |
| "Additionally, four unsigned integers (initially all zero) are |
| required to hold the each respective name of the current vertex |
| shader program, current geometry shader program, current fragment |
| shader program, and active program respectively." |
| |
| Additions to Chapter 3 of the OpenGL 3.0 Specification (Rasterization) |
| |
| -- Section 3.12 "Fragment Shaders" (page 231) |
| |
| Replace the second to the last paragraph with: |
| |
| "When the current fragment shader program object currently includes |
| a fragment shader, its fragment shader is considered active, and is |
| used to process fragments. If the fragment shader program object |
| has no fragment shader, or no fragment shader program object is |
| currently in use, the fixed-function fragment processing operations |
| described in the previous sections are used." |
| |
| -- Section 3.12.1 "Shader Variables" (page 232) |
| |
| Add this paragraph after the third paragraph: |
| |
| "User-defined varying values are well-defined only when the fragment |
| shader program object and the preceding programmable shading stage, |
| either the geometry shader stage if the geometry shader program |
| object contains geometry shader or else the vertex shader stage |
| if the vertex shader program object contains a vertex shader, are |
| the same program object. So user-defined varying values are only |
| well-defined when both the varying variable's output shader and |
| input shader are the same program object. |
| |
| In order to ensure well-defined behavior between a fragment shader |
| program with a different preceding geometry shader program or |
| vertex shader program when the current geometry shader program is |
| zero, applications must use the built-in varying variables such |
| as gl_TexCoord[0]. If the current fragment shader program object |
| uses user-defined input varying variables when the preceded current |
| geometry shader program is not the same program object or, in the |
| case the geometry shader program is zero, the preceding current |
| vertex shader program object is not the same program object, then |
| the values of such input varying variables are undefined. |
| |
| The state of user-defined varying inputs to a fragment shader |
| are undefined /even if/ the preceding shader has varying outputs |
| that match the same name and type of the subsequent shader. |
| Implementations are encouraged but not required to force these |
| undefined input varying variables to zero." |
| |
| Additions to Chapter 4 of the OpenGL 3.0 Specification (Per-Fragment |
| Operations and the Frame Buffer) |
| |
| None |
| |
| Additions to Chapter 5 of the OpenGL 3.0 Specification (Special |
| Functions) |
| |
| None |
| |
| Additions to Chapter 6 of the OpenGL 3.0 Specification (State and |
| State Requests) |
| |
| -- Section 5.4 "Display Lists" (page 311) |
| |
| Add "CreateShaderProgramEXT" to the "Program and shader objects" |
| list of commands that cannot be compiled into a display list but |
| are instead executed immediately. |
| |
| Additions to the AGL/GLX/WGL Specifications |
| |
| None |
| |
| Additions to the OpenGL Shading Language |
| |
| None |
| |
| Additions to the ARB_geometry_shader4 specification |
| |
| -- Section 2.16, Geometry Shaders |
| |
| Replace the 3rd and 4th paragraphs to read: |
| |
| "Geometry shaders are created as described in section 2.15.1 using a |
| type parameter of GEOMETRY_SHADER_ARB. They are attached to and used |
| in program objects as described in section 2.15.2. When a geometry |
| shader program object currently in use includes a geometry shader, |
| its geometry shader is considered active, and is used to process |
| primitives. If the geometry shader program object has no geometry |
| shader, or no program object is in use, this new primitive processing |
| pipeline stage is bypassed. |
| |
| A program object that includes a geometry shader without a vertex |
| shader must only use built-in input varying variables; otherwise |
| a link error may occur." |
| |
| -- Section 2.16.4, Geometry Shader Execution Environment |
| |
| Change the first paragraph to read: |
| |
| "If a successfully linked program object that contains a geometry shader is |
| made current as the geometry shader program object by calling |
| UseShaderProgramEXT with a type of GL_GEOMETRY_SHADER_ARB, the |
| executable version of the geometry shader is used to process |
| primitives resulting from the primitive assembly stage." |
| |
| Add these paragraphs to the end of the section: |
| |
| "User-defined varying values are well-defined only when the geometry |
| shader program object and the preceding vertex shader program object |
| are the same program object. So user-defined varying values are only |
| well-defined when both the varying variable's output shader and |
| input shader are the same program object. |
| |
| In order to ensure well-defined behavior between a geometry shader |
| program with a different preceding vertex shader program, applications |
| must use the built-in varying variables such as gl_TexCoord[0]. |
| If the current geometry shader program object uses user-defined |
| input varying variables when the preceded current vertex shader |
| program object is not the same program object, then the values of |
| such input varying variables are undefined. |
| |
| The state of user-defined varying inputs to a geometry shader |
| are undefined /even if/ the preceding vertex shader has varying |
| outputs that match the same name and type of the subsequent shader. |
| Implementations are encouraged but not required to force these |
| undefined input varying variables to zero." |
| |
| GLX Protocol |
| |
| UNDER DEVELOPMENT |
| |
| Errors |
| |
| UseShaderProgramEXT generates INVALID_ENUM if the type parameter is |
| not one of VERTEX_SHADER, GEOMETRY_SHADER_ARB, or FRAGMENT_SHADER. |
| |
| UseShaderProgramEXT generates INVALID_OPERATION if the program |
| parameter has not been successfully linked. |
| |
| UseShaderProgramEXT generates INVALID_OPERATION if transform feedback |
| is active. |
| |
| ActiveProgramEXT generates INVALID_OPERATION if the program parameter |
| has not been successfully linked. |
| |
| LinkProgram NO LONGER generates an INVALID_OPERATION if the program |
| object has a geometry shader attached and no vertex shader attached |
| as long as the geometry shader uses only built-in varying input |
| variables. |
| |
| Dependencies on ARB_geometry_shader4, EXT_geometry_shader4, and/or NV_geometry_shader4 |
| |
| If none of ARB_geometry_shader4, EXT_geometry_shader4, or |
| NV_geometry_shader4 are supported by the implementation, ignore all |
| references to geometry shaders and generate an INVALID_ENUM error |
| when UseShaderProgramEXT is called with the token GEOMETRY_SHADER_ARB. |
| |
| New State |
| |
| Remove CURRENT_PROGRAM from table 6.30 (Program Object State) and |
| append these rows: |
| |
| Get Value Type Get Command Initial Value Description Sec Attribute |
| ------------------- ---- ----------- ------------- ------------------------ ------ --------- |
| ACTIVE_PROGRAM_EXT Z+ GetIntegerv 0 The program object 2.20.2 - |
| (alias for that Uniform* commands |
| CURRENT_PROGRAM) update |
| VERTEX_SHADER Z+ GetIntegerv 0 Name of current vertex 2.20.2 - |
| shader program object |
| GEOMETRY_SHADER_ARB Z+ GetIntegerv 0 Name of current geometry 2.20.2 - |
| shader program object |
| FRAGMENT_SHADER Z+ GetIntegerv 0 Name of current fragment 2.20.2 - |
| shader program object |
| |
| New Implementation Dependent State |
| |
| None |
| |
| Issues |
| |
| 1. What should this extension be called? |
| |
| RESOLVED: EXT_separate_shader_objects |
| |
| The adjective "separate" is used in several extension names |
| (EXT_blend_equation_separate, EXT_blend_func_separate, |
| EXT_separate_specular_color, ATI_separate_stencil) when joined |
| state is made configurable separately. |
| |
| The phrase "shader_objects" refers generally to GLSL shader |
| objects, matching the ARB_shader_objects name. |
| |
| Whether the name should be "separate_shader_objects" |
| or "shader_objects_separate" is less clear. The various |
| "separate" extensions have different conventions as to whether |
| separate is prefixed or suffixed with the separated state. |
| The prefixed form is more natural to say aloud, is consistent |
| with the ATI_separate_stencil naming approach, and abbreviates |
| to SSO (instead of the inopportune abbreviation SOS). |
| |
| 2. What happens to a user-defined input varying variable that are |
| not written by a preceding shader's write to the corresponding |
| output varying variable. |
| |
| RESOLVED: The input variable variable's value is left undefined. |
| Implementations are encouraged but not required to zero the |
| value. |
| |
| GLSL has a "rendezvous by name" model for connecting varying |
| output variables to varying input variables of a subsequent |
| shader. With separate shaders, there's no assurance whether a |
| preceding shader will write a given user-defined input varying |
| variable. HLSL9, Cg, and OpenGL assembly extension programs |
| handle this situation by with "rendezvous by API resource" model. |
| In GLSL terms, this means separate GLSL shaders /must/ communicate |
| by built-in varying variables rather than user-defined varying |
| variables. |
| |
| It is undesirable from a performance standpoint to attempt to |
| support "rendezvous by name" for arbitrary separate shaders |
| because the separate shaders won't be naturally compiled to |
| match their varying inputs and outputs of the same name without |
| a special link step. Such a special link would introduce an |
| extra validation overhead to binding separate shaders. The link |
| itself would have to be deferred until glBegin time since separate |
| shaders won't match when transitioning from one set of consistent |
| shaders to another. This special link would still create errors |
| or undefined behavior when the names of input and output varyings |
| matched but their types did not match. |
| |
| Also the expectation from other shading APIs that support |
| mix-and-match shader usage is that "rendezvous by API resource" |
| is the expected norm. |
| |
| Specifying the behavior being undefined allows a future ARB |
| version of this extension to be more specific without encumbering |
| this extension with enforcing a specific error. |
| |
| 3. Do different program objects currently used by different shader |
| types share a single name space for uniforms? |
| |
| RESOLVED: No, different program objects have their own separate |
| name space for uniforms and each has locations specific to its |
| unique program object. |
| |
| 4. How do the glUniform* commands determine what program object |
| to query? |
| |
| RESOLVED: This extension introduces the active program specified |
| by glActiveProgramEXT (similar to the active texture selector |
| specified by glActiveTexture) to specify the selector used by |
| glUniform* commands. |
| |
| This active program is simply a selector and doesn't actually |
| control any rendering operation. |
| |
| The active program can be queried with glGetIntegerv with |
| the GL_ACTIVE_PROGRAM_EXT token which is an alias for |
| GL_CURRENT_PROGRAM. |
| |
| As an alternative to setting the GL_ACTIVE_PROGRAM_EXT selector |
| with glActiveProgramEXT, applications are instead encouraged |
| to use the glProgramUniform* commands introduced by the |
| EXT_direct_state_access extension which do not depend on a |
| selector but specify the program object with which to update |
| the specified uniform location explicitly. |
| |
| 5. Do the glGetUniform* queries depend on the active program state |
| (GL_ACTIVE_PROGRAM_EXT)? |
| |
| RESOLVED: No, the glGetUniform* queries take the program |
| object for the query as an explicit parameter to the query. |
| These commands do not rely on a selector. |
| |
| 6a. Should the fragment shader program object be allowed to changed |
| within transform feedback mode? |
| |
| RESOLVED: No, this should generate a GL_INVALID_OPERATION error. |
| |
| The OpenGL 3.0 and EXT_transform_feedback specifications say |
| glUseProgram generates a GL_INVALID_OPERATION error when transform |
| feedback is active. |
| |
| The rationale for this is that user-defined varying outputs from |
| the vertex or geometry shader might change. |
| |
| Perhaps it is desirable to allow different shader program objects |
| when transform feedback mode is active, but this extension |
| doesn't change the existing GLSL error behavior. In fact, |
| glUseShaderProgramEXT generate the same error glUseProgram does. |
| |
| 6b. Should the active program be allowed to changed within transform |
| feedback mode? |
| |
| RESOLVED: Yes. |
| |
| The active program simply allows uniforms to be changed but |
| doesn't actually change how the graphics pipeline itself is |
| configured or what programs are used for vertex, geometry, |
| and fragment processing. |
| |
| 7. What if a program object contains shaders from two domains, say |
| both a vertex shader and a geometry shader, and the program object |
| is just used as the current fragment shader program object? |
| |
| RESOLVED: The vertex shader within the program object is |
| simply ignored. |
| |
| 8. What if a program object contains both a vertex and fragment |
| shader and this program object is bound to both the current |
| vertex shader and fragment shader program object but there is |
| also a different geometry shader program object bound? |
| |
| RESOLVED: This works as long as the vertex shader and fragment |
| shader rely on built-in varying variables to communicate and don't |
| depend on passing values between each other with user-defined |
| varying variables because such variables are undefined if an |
| intervening different geometry shader program object is currently |
| used. Specifically, the vertex shader will output to its |
| built-in varying output variables and the different geometry |
| shader program object can read those built-in varying values |
| through input varying variables. Likewise the fragment shader |
| can use built-in varying input variables to get varying data |
| from the different geometry shader program object. |
| |
| 9. Is glUseShaderProgramEXT allowed to be compiled within a |
| display list? |
| |
| RESOLVED: Yes, just like glUseProgram is allowed within a |
| display list. |
| |
| 10. Should there be some easier to use API for creating a GLSL |
| program that programs a single shader type? |
| |
| RESOLVED: Yes, see the glCreateShaderProgramEXT command. |
| |
| The existing GLSL API for creating a GLSL program involves a lot |
| of steps to support multiple source strings, re-specification of |
| source code, attaching and detaching multiple shader objects, |
| and cross-domain linking. These features are not particularly |
| relevant for creating separate shader programs. |
| |
| 11. Can glCreateShaderProgramEXT be compiled into a display list? |
| |
| RESOLVED: No. |
| |
| glCreateShaderProgramEXT is equivalent to a sequence of commands |
| that are themselves not allowed to be compiled into a display |
| list. |
| |
| 12. Should glCreateShaderProgramEXT allow user-defined varyings? |
| |
| RESOLVED: User-defined varyings are permitted (without error) |
| but shouldn't be used because their behavior is not defined. |
| |
| glCreateShaderProgramEXT is likely to be used for compiling |
| separate shaders. The tenative resolution to issue 2 says the |
| values of user-defined varying input varaibles are undefined if |
| the preceding shader doesn't belong to the same program object. |
| Since the programs returned by glCreateShaderProgramEXT are |
| always for a single domain, there's no point allowing user-defined |
| varyings if they can't be assumed to be well-defined. |
| |
| 13. How are interpolation modifiers handled for separate shader |
| programs? |
| |
| RESOLVED: For now, interpolation modifiers aren't supported |
| for separate shader object varyings. |
| |
| Future resolution: Unfortunately GLSL only provides interpolation |
| modifiers for user-defined varyings which aren't well-defined |
| for separate shader programs. |
| |
| In the short-term, interpolation modifiers aren't commonly used |
| so not supporting interpolation modifiers for seperate GLSL |
| shader programs is probably acceptable. |
| |
| Long-term, GLSL can be extended with #pragma constructs that |
| specify to the compiler the interpolation modifier for a given |
| fragment shader built-in varying. Something like: |
| |
| #pragma interpolation(gl_TexCoord[0], centroid) |
| #pragma interpolation(gl_TexCoord[1], flat) |
| #pragma interpolation(gl_TexCoord[2], smooth) |
| #pragma interpolation(gl_TexCoord[3], invariant) |
| #pragma interpolation(gl_TexCoord[4], noperspective) |
| |
| This pragma is only legal within a fragment shader compilation |
| unit. The pragma can be specified multiple times, but |
| inconsistent specification of a specific built-in varying's |
| interpolation is not allowed. |
| |
| Alternatively, this extenion could add new built-in input varying |
| variables for the fragment shader: |
| |
| // TexCoord category |
| varying in centroid vec4 gl_CentroidTexCoord[]; |
| varying in centroid noperspective vec4 gl_CentroidNoPerspectiveTexCoord[]; |
| varying in float vec4 gl_FlatTexCoord[]; |
| varying in noperspective vec4 gl_NoPerspectiveTexCoord[]; |
| varying in ivec4 gl_IntTexCoord[]; |
| |
| // Color category |
| varying in centroid vec4 gl_CentroidColor; |
| |
| // Secondary color category |
| varying in centroid vec4 gl_CentroidSecondaryColor; |
| |
| // Fog category |
| varying in centroid vec4 gl_CentroidFogFragCoord; |
| |
| It would be an error to use a varying from more than one category |
| in a single program. |
| |
| 14. Should glLinkProgram work to re-link a shader created with |
| glCreateShaderProgramEXT? |
| |
| RESOLVED: NO because the shader created by glCreateShaderProgram |
| is detached and deleted as part of the glCreateShaderProgramEXT |
| sequence. This means if you call glLinkProgram on a program |
| returned from glCreateShaderProgram, you'll find the re-link |
| fails because no shader object is attached. |
| |
| An application is free to attach one or more new shader objects |
| to the program and then relink would work. |
| |
| This is fine because re-linking isn't necessary/expected. |
| |
| 15. Wouldn't re-linking be necessary if the application wanted to |
| use glBindAttribLocation to assign a user-defined attribute to |
| a specific vertex attribute? |
| |
| RESOLVED: Yes and that's a problem if glCreateShaderProgramEXT |
| is used because the shader object is detached and deleted. |
| |
| User-defined attributes will work when glCreateShaderProgramEXT |
| is used to easily create a vertex shader program, but the |
| appliation must be satisfied with the implementation-dependent |
| linker-assigned user-defined attributes returned by |
| glGetAttribLocation. |
| |
| We could provide a new set of built-in attributes that correspond |
| to declared as: |
| |
| attribute vec4 gl_VertexAttrib[]; |
| |
| How would these attributes map to the other built-in attributes? |
| That would depend on the implementation. As with ARB_vertex_program, |
| some implementations could choose to alias such generate vertex attributes |
| with conventional vertex attributes (color, fog coord, etc.) or |
| an implementation could treat the generic attributes as disjoint |
| from the conventional vertex attributes. |
| |
| If this is unsatisfactory, the solution is to avoid using |
| glCreateShaderProgramEXT and instead use the traditional GLSL |
| approach for creating programs (create shader, compile shader, |
| attach shader, bind attributes, link shader, use shader). |
| |
| Demonstrating how to workaround this particular issue, here's |
| an example of creating and using a vertex shader for use with |
| separate shader objects that includes explicit binding of output |
| varyings to fragment data locations. First the shader: |
| |
| varying in vec4 attribA; |
| varying in vec4 attribB; |
| void main() |
| { |
| gl_Position = ftransform(); |
| gl_FrontColor = attribA; |
| gl_BackColor = attribB; |
| } |
| |
| Now creating and using a linked program from this shader where |
| attribA is initialized by vertex attribute 5 and attribB is |
| initialized by vertex attribute 7. |
| |
| const GLuint shader = glCreateShader(GL_VERTEX_SHADER); |
| if (shader) { |
| const GLint len = (GLint) strlen(aboveShaderString); |
| glShaderSource(shader, 1, &aboveShaderString, &len); |
| glCompileShader(shader); |
| const uint program = glCreateProgram(); |
| if (program) { |
| GLint compiled = FALSE; |
| glGetShaderiv(shader, COMPILE_STATUS, &compiled); |
| if (compiled) { |
| glAttachShader(program, shader); |
| |
| // Crucial code that glCreateShaderProgramEXT doesn't do |
| glBindAttribLocation(program, 5, "attribA"); |
| glBindAttribLocation(program, 7, "attribB"); |
| |
| glLinkProgram(program); |
| glDetachShader(program, shader); |
| |
| // Show this program can actually be used as a vertex shader |
| glUseShaderProgramEXT(GL_VERTEX_SHADER, program); |
| } |
| } |
| glDeleteShader(shader); |
| return program; |
| } else { |
| return 0; |
| } |
| |
| Optionally, the glDetachShader and glDeleteShader commands could |
| be removed to allow this program to be re-linked after different |
| glBindAttribLocation calls. |
| |
| 16. Can you use glBindFragDataLocation to direct varying output |
| variables from a fragment shader program created by |
| glCreateShaderProgramEXT to specific color buffers? |
| |
| RESOLVED: NO for much the same reason you can't do this with |
| attributes as described in issue 15. But you could create the |
| program with the standard GLSL creation process where you attach |
| your own shaders and relink. |
| |
| For fragment shader programs created with |
| glCreateShaderProgramEXT, there is already the gl_FragData[] |
| builtin to output to numbered color buffers. For integer |
| framebuffers, we would need to add: |
| |
| varying out ivec4 gl_IntFragData[]; |
| |
| User-defined output fragment shader varyings can still be used |
| as long as the application is happy with the linker-assigned |
| locations. |
| |
| Demonstrating how to workaround this particular issue, here's |
| an example of creating and using a fragment shader for use with |
| separate shader objects that includes explicit binding of output |
| varyings to fragment data locations. First the shader: |
| |
| varying out ivec4 bufferA; |
| varying out ivec4 bufferB; |
| void main() |
| { |
| bufferA = ivec4(1,2,3,4); |
| bufferB = ivec4(5,6,7,8); |
| } |
| |
| Now creating and using a linked program from this shader where |
| bufferA outputs to color buffer 0 and bufferB outputs to color |
| buffer 1: |
| |
| const GLuint shader = glCreateShader(GL_FRAGMENT_SHADER); |
| if (shader) { |
| const GLint len = (GLint) strlen(aboveShaderString); |
| glShaderSource(shader, 1, &aboveShaderString, &len); |
| glCompileShader(shader); |
| const uint program = glCreateProgram(); |
| if (program) { |
| GLint compiled = FALSE; |
| glGetShaderiv(shader, COMPILE_STATUS, &compiled); |
| if (compiled) { |
| glAttachShader(program, shader); |
| |
| // Crucial code that glCreateShaderProgramEXT doesn't do |
| glBindFragDataLocation(program, 0, "bufferA"); |
| glBindFragDataLocation(program, 1, "bufferB"); |
| |
| glLinkProgram(program); |
| glDetachShader(program, shader); |
| |
| // Show this program can actually be used as a fragment shader |
| glUseShaderProgramEXT(GL_FRAGMENT_SHADER, program); |
| } |
| } |
| glDeleteShader(shader); |
| return program; |
| } else { |
| return 0; |
| } |
| |
| Optionally, the glDetachShader and glDeleteShader could be |
| removed to allow this program to be re-linked after different |
| glBindFragDataLocation calls. |
| |
| 17. Can you output varyings from a seperate shader program created |
| with glCreateShaderProgramEXT? |
| |
| RESOLVED: No. |
| |
| glTransformFeedbackVaryings requires a re-link to take effect on a |
| program. glCreateShaderProgramEXT detaches and deletes the shader |
| object use to create the program so a glLinkProgram will fail. |
| |
| You can still create a vertex or geometry shader program |
| with the standard GLSL creation process where you could use |
| glTransformFeedbackVaryings and glLinkProgram. |
| |
| 18. I just don't get it? Why is it such a big deal to just require |
| apps to link all their vertex and fragment shaders together? |
| Please explain a situation where mix-and-match shaders is |
| substantially better than GLSL as it exists without this |
| extension? |
| |
| RESOLUTION: Consider the (not uncommon) case of a vertex shader |
| for skinning a character. The vertex shader is used in four |
| distinct types of rendering passes, each using the one vertex |
| shader but different fragment shaders. |
| |
| For GLSL today, this situation today requires 4 program objects, |
| each containing the one vertex shader paired with each one of |
| the fragment shaders. |
| |
| The one vertex shader has an array of dozens of skinning matrices |
| along with numerous other uniform parameters. |
| |
| Each fragment shader has its own different set of uniforms too. |
| |
| Each GLSL program object has its own (combined) set of GLuint |
| locations for the active uniforms of the vertex and fragment |
| shaders objects linked into the particular program object. |
| |
| The locations for a given program object are arbitrary and |
| the location values of two distinct program objects have no |
| correlation. This is true even when they each link in the same |
| vertex shader (or alternatively same fragment shader). |
| |
| Now the application is saddled with the burden of managing |
| distinct location values for the same vertex shader skinning |
| matrices and other uniform variables as well as making sure |
| the values of these variables are mirroed over all four program |
| objects containing the skinning vertex shader. |
| |
| What's worse is despite all the program objects being loaded |
| with the same vertex shader uniform variables for skinning, the |
| driver is exceedingly unlikely to recoginize that binding from |
| one of these program objects to another is going to result in |
| no actual vertex shader state change. Noticing that the uniform |
| vertex shader variables are changing in lock-step over a series |
| of program objects (when the uniform fragment shader variables |
| ARE allowed to diverge) is exceedingly expensive. |
| |
| This situation is simple to optimize with mix-and-match shaders |
| because there is just a single vertex shader to worry about. |
| It's only the current fragment shader program that is changing |
| so only the fragment shader state must be updated/re-validated. |
| |
| It's also much easier and less expensive for the application to |
| update the vertex shader state because there is just one copy |
| of it to update. |
| |
| 19. In case of indirect rendering, should glCreateShaderProgramEXT |
| explicitly send string length parameter to server? |
| |
| PROPOSED: Yes. Although source code passed to |
| glCreateShaderProgramEXT is NUL terminated, the server can not |
| safely rely on the client to terminate the string so it must |
| add the NUL terminator before passing the protocol buffer to |
| the GL command processor. The string length is needed to do this |
| accurately. |
| |
| 20. Can glCreateShaderProgramEXT support command larger than the |
| maximum command length supported by a single command? |
| |
| PROPOSED: Yes. Source code passed to glCreateShaderProgramEXT is |
| unbounded. Command length can be more than the maximum command |
| length supported by a single command. Support for "large single" |
| command needs to be added. |
| |
| |
| |
| Revision History |
| |
| Rev. Date Author Changes |
| ---- -------- -------- ---------------------------------------- |
| 1 11/06/08 mjk Initial revision |
| 2 11/10/08 mjk add glCreateShaderProgramEXT |
| 3 11/12/08 mjk fixed glCreateShaderProgramEXT |
| add issues 12 and 13 |
| 4 11/14/08 mjk issues 13 through 17 |
| 5 12/03/08 mjk glActiveProgram replaces |
| GL_UNIFORM_SHADER_EXT |
| 6 04/01/09 mjk corrections from Jason Green |
| 7 08/12/09 mjk Marked as shipping, resolve and |
| improve issues 15 & 16 |
| 8 09/09/09 mjk Assign number |
| 9 09/09/09 mjk Fix transposed page number |
| 10 24/02/10 srahman added glx protocol for |
| glCreateShaderProgramEXT |
| added issues 19 and 20 |
| 11 03/07/13 Jon Leech Added note about the unrelated OpenGL ES |
| extension of the same name. |
