| GL_EXT_separate_shader_objects |
EXT_separate_shader_objects
GL_EXT_separate_shader_objects
Mark Kilgard, NVIDIA (mjk 'at' nvidia.com)
Pat Brown
Eric Werness
Robert Ohannessian
Jason Green, TransGaming
Greg Roth
Proposed
Last Modified Date: March 2, 2009
Version: 6
???
Written based on the wording of the OpenGL 3.0 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.
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.
   New Procedures and Functions |
void UseShaderProgramEXT(enum type, uint program);
void ActiveProgramEXT(uint program);
uint CreateShaderProgramEXT(enum type, const char *string);
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);
}
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 will not actually link if the linked program would
contain active user-defined varyings. If this situation arises,
the info log will 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 79)
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 occurs."
-- 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."
The following rendering command is sent to the server as part of a
glXRender request:
UseShaderProgramEXT
2 8 rendering command length
2 ZZZZ rendering command opcode
4 ENUM type
4 CARD32 program
ActiveProgramEXT
2 4 rendering command length
2 ZZZZ rendering command opcode
4 CARD32 program
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.
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
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.
UNRESOLVED:
LIKELY RESOLUTION (written into current spec): 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 an 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?
UNRESOLVED
Likely resolution depending on issue 2: NO, they should be errors
(and the spec is written this way currently).
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?
UNRESOLVED:
Tenative resolution: Interpolation modifiers are only provided
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?
UNRESOLVED:
Tenative resolution: 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?
UNRESOLVED:
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.
16. Can you use glBindFragDataLocation to direct varying output
variables from a fragment shader program created by
glCreateShaderProgramEXT to specific color buffers?
UNRESOLVED:
Tenative resolution: 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.
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 an 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.
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
GL_UNIFORM_SHADER_EXT
 |  | Last update: November 14, 2006.
Cette page doit être lue avec un navigateur récent respectant le standard XHTML 1.1.
|
