Back to the OpenGL extension cross reference
GL_ARB_fragment_shader
ARB_fragment_shader
Name Strings
GL_ARB_fragment_shader
Contributors
Dave Baldwin
Pat Brown
Evan Hart
Phil Huxley
Dale Kirkland
John Kessenich
Steve Koren
Jon Leech
Bill Licea-Kane
Benjamin Lipchak
Barthold Lichtenbelt
Kent Lin
Jeremy Morris
Teri Morrison
Glenn Ortner
Randi Rost
Jeremy Sandmel
The ARB_fragment_program working group members. Several concepts and
chunks of text are copied from the ARB_fragment_program specification.
Contact
Barthold Lichtenbelt, 3Dlabs, Inc. (barthold 'at' 3dlabs.com)
Randi Rost, 3Dlabs, Inc. (rost 'at' 3dlabs.com)
IP Status
As described in the Contributor License, which can be found at
http://www.3dlabs.com/support/developer/ogl2/specs/3dlabs_contributor.pdf.
Status
Complete. Approved by the ARB on June 11, 2003.
Updated revision 0.79 approved by the ARB on June 17, 2004.
Version
Last Modified Date: May 14, 2004
Author Revision: 0.79
Number
ARB Extension #32
Dependencies
OpenGL 1.0 is required.
This extension is written against version 1.10 of the OpenGL Shading
Language Specification.
The extension is written against the OpenGL 1.4 Specification.
The ARB_shader_objects extension is required.
This extension interacts with the ARB_vertex_shader extension.
Overview
This extension adds functionality to define fragment shader objects. A
fragment shader object is a shader object (see the ARB_shader_objects
extension) that, when attached to a program object, can be compiled and
linked to produce an executable that runs on the fragment processor in
OpenGL. The fragment processor is a programmable unit that replaces the
OpenGL 1.4 fixed-function texturing, color sum and fog stages. This
extension also defines how such an executable interacts with the fixed
functionality fragment processing of OpenGL 1.4. The language used to
write fragment shaders is not discussed here. That language is defined
in the OpenGL Shading Language specification as the Fragment Shading
Language.
Issues
1) Can you clarify texture unit, texture image unit and texture
coordinate sets please?
DISCUSSION: In 'old style' GL a texture unit consists of a texture
coordinate processing unit (consisting of a texture matrix stack and
texture coordinate generation state), and a texture image unit, with all
the texture state defined in section 3.8, as well as texture environment
state, as defined in section 3.8.12. The implementation dependent number
of supported texture units in 'old style' GL is MAX_TEXTURE_UNITS.
In this specification a texture unit consist of one or both of a texture
image unit, and a texture coordinate set. The implementation dependent
number of supported texture image units is MAX_TEXTURE_IMAGE_UNITS_ARB
and the number of supported texture coordinate sets is
MAX_TEXTURE_COORDS_ARB.
The maximum available multi-texture stages (to the fixed-function
pipeline) are MAX_TEXTURE_UNITS. A fragment shader has access to at
least MAX_TEXTURE_UNITS texture image units, and possibly more, up to
MAX_TEXTURE_IMAGE_UNITS_ARB. Where MAX_TEXTURE_IMAGE_UNITS_ARB is equal
or greater than MAX_TEXTURE_UNITS.
RESOLUTION: Yes
2) Should we split the number of available texture coordinate sets and
texture units?
DISCUSSION: Some implementations might provide for more texture image
units than texture coordinate sets. Texture coordinates for the 'new'
texture image units can be derived from other texture coordinates, or
provided through a texture lookup. These new texture coordinates can be
used to index different textures bound to different texture image units.
RESOLUTION: YES, splitting this is useful.
3) Is the texture environment state associated with all texture image
units?
DISCUSSION: A fragment shader has access to the texture environment
color through the shader built-in array gl_TexEnvColor. This array has
MAX_TEXTURE_IMAGE_UNITS_ARB elements. It is also possible, and useful,
to set the texture environment state TEXTURE_LOD_BIAS for all texture
image units. All other texture environment state is not accessible to a
fragment shader (for example, TEXTURE_ENV_MODE, COMBINE_RGB etc).
However, an application can still set this state (and query it).
Note that fixed-function GL caps the number of supported texture stages
to MAX_TEXTURE_UNITS. This limit is generally below the number of
texture image units available to a fragment shader. Each of these
MAX_TEXTURE_UNITS texture stages need all texture environment state for
the multi-texture pipeline to function correctly. Texture units above
this limit still have all the texture environment state associated with
it, even although this state is not accessible in a fragment shader.
Note that ARB_fragment_program also does this, except that it caps
access to the texture environment state to the first MAX_TEXTURE_UNITS
texture image units.
RESOLUTION: Yes.
4) What to do about invariance rules (Appendix A)?
DISCUSSION: Numerous rules and proposals have been discussed. In the
end, simplicity is an important goal. It is always possible to later add
more invariance rules, if it turns out to be desirable.
RESOLUTION: The same shader will produce the same result when run
multiple times with the same input. The wording 'the same shader' means
a program object that is populated with the same source strings, which
are compiled and then linked, possibly multiple times. This program
object is executed using the same GL state vector.
Besides the above general statement, we will limit this specification to
one invariance rule with respect to depth produced by a fragment shader:
All shaders that either conditionally or unconditionally copy the input
gl_FragCoord.z to the output gl_FragDepth are depth-invariant with
respect to each other, for those fragments where this copy actually is
done.
Note that a fragment shader that does not write to gl_FragDepth is
depth-invariant with fixed function (since fixed function depth will be
used for the fragment when gl_FragDepth is not written).
See also Appendix A.
5) Should the output from the pixel rectangle rasterization and bitmap
rasterization stages feed into a fragment shader?
DISCUSSION: See also Issue 2 in the OpenGL Shading Language
specification. Future API additions could make the operations DrawPixels
performs programmable. For the list of specific operations that could be
replaced see Section 3.6.4, Figure 3.7 in the OpenGL 1.4 specification.
Combined with the proposed pack/unpack language, and the proposed pack
and unpack processors, such a future extension will become an extremely
powerful and flexible imaging pipeline.
Most of the harder parts to implement the functionality in Figure 3.7
result from the imaging subset. A conceivable way to implement this
functionality is by using the programmable fragment unit. However, if
the results from the pixel rectangle and bitmap rasterization stages did
feed into the fragment shader, then implementing all the functionality
in Figure 3.7 might become hard or impossible, when a fragment shader is
also active. A possibility that was considered was to say that if a
fragment shader was active, pixel transfer functionality such as scale
and bias, color matrix, lookup, etc., was disabled. A fragment shader
could perform these kinds of operations, after all.
ARB_fragment_program does feed the result of pixel rectangle and bitmap
rasterization into the fragment shader.
RESOLUTION: Yes, this allows fragment shaders to do image processing
type of operations on pixel rectangles and bitmaps.
Note that a fragment shader that is processing fragments resulting from
rasterization of pixel rectangles or bitmaps, can only reference
built-in varying variables starting with "gl_" (gl_Color,
gl_SecondaryColor, gl_TexCoord[] and gl_FogFragCoord). The fragments
produced as a result of rasterizing a pixel rectangle or bitmap have
associated values for those varying variables. If the fragment shader
uses a user-defined varying, results are undefined.
6) What about clamping and conversion for color and depth output
variables?
DISCUSSION: The output variables gl_FragDepth and gl_FragColor are in
floating point format. However, the GL 1.4 pipeline following the
fragment shader expects these values to be in fixed-point, and clamped
to the range [0,1].
RESOLUTION: Color and depth values written by the fragment shader will
be automatically clamped to the range [0,1] and then converted, as
appropriate, to a fixed-point representation. See section 3.11.6.
7) What about clamping and conversion for color and depth input varying
variables?
DISCUSSION: This ties in with issue 18 in the ARB_vertex_shader
specification. There are three cases to consider:
1) An ARB_vertex_shader shader writing colors that are consumed by an
ARB_fragment_shader shader.
2) An ARB_vertex_program shader writing colors that are consumed by an
ARB_fragment_shader shader.
3) Fixed functionality vertex processing outputting colors that are
consumed by an ARB_fragment_shader shader.
Fixed function vertex processing as well as ARB_vertex_shader and
ARB_vertex_program do clamp colors automatically to [0,1]. In all three
cases colors are next converted to fixed-point (section 2.13.9).
RESOLUTION: Depth and color values will be converted to floating-point
before entering the fragment shader.
8) What controls the value of the shader built-in Boolean
gl_FrontFacing?
DISCUSSION: The OpenGL Shading Language says the following: "The
fragment shader has access to the read-only built-in variable
gl_FrontFacing whose value is true if the fragment belongs to a
front-facing primitive."
This specification defines when a fragment is considered front-facing.
A fragment derives its facing direction from the primitive that
generates the fragment. All fragments generated by primitives other than
polygons, triangles, or quadrilaterals are considered to be front
facing. For all other fragments (including ones resulting from point-
and line-mode polygons) the determination is made by examining the sign
of the area computed by equation 2.6 of section 2.13.1 (including the
possible reversal of this sign as indicated by the last call to
FrontFace). If the sign is positive then the fragments are front facing;
otherwise, they are back facing.
ARB_vertex_shader has an enable called VERTEX_PROGRAM_TWO_SIDE_ARB. If
false, the front color is always selected. However, this enable does not
apply to the front or back facing determination of a fragment. The value
of VERTEX_PROGRAM_TWO_SIDE_ARB does not affect the value of
gl_FrontFacing. Thus you can have the following situation:
* VERTEX_PROGRAM_TWO_SIDE_ARB = FALSE. Which forces the front color to
always be selected. Thus gl_Color and gl_SecondaryColor (read-only
accessible in the fragment shader) have the values of the varyings
gl_FrontColor and gl_FrontSecondaryColor (written by the vertex
shader).
* The primitive is a polygon and is determined to be back-facing.
gl_FrontFacing therefore = FALSE.
RESOLUTION: Depending on the primitive type it is either always front
facing, or it is determined by he sign of the polygon's area computed in
window coordinates.
9) OpenGL provides a hierarchy of texture enables (cube map, 3D, 2D,
1D). Should samplers override that hierarchy and select specific
texture targets?
DISCUSSION: How samplers work is explained in issue 25 of the
ARB_shader_objects specification.
RESOLUTION: Yes. This removes a potential pitfall for developers:
Leaving the hierarchy of enables in an undesired state. It makes shaders
more readable as the intent of the code is more obvious. It allows
compilers to be more aggressive as to which texture coordinate
components are "don't cares" without having to recompile programs when
fixed-function texture enables change.
Note that the ARB_shader_objects specification states that it is not
allowed to have samplers of different types point to the same texture
image unit. For example, it is not possible to request a 2D and a 3D
texture lookup using the same texture image unit within a program
object.
10) Is Depth Offset applied to the window z value before it enters the
fragment shader?
DISCUSSION: Depth Offset (polygon offset) is discussed in section 3.5.5
of the GL 1.4 spec. Depth offset is considered part of the rasterization
stage, which happens prior to processing of a fragment shader.
RESOLUTION: As in the base OpenGL specification, the depth offset
generated by polygon offset is added during polygon rasterization. The
depth value provided to shaders in the built-in gl_FragCoord.z already
includes polygon offset, if enabled. If the depth value is replaced by a
fragment shader, the polygon offset value will NOT be recomputed and
added back after shader execution.
NOTE: This is probably not desirable for fragment shaders that modify
depth values since the partials used to generate the offset may not
match the partials of the computed depth value.
11) Should gl_FragColor be aliased to gl_FragData[0]?
RESOLUTION: No. A shader should write either gl_FragColor, or
gl_FragData[n], but not both.
12) Should gl_FragData[n] be clamped?
RESOLUTION: gl_FragData[] is basically an array of colors. The values in
this array might or might not be actual color data, just as is true for
the output variable gl_FragColor. The data assigned to gl_FragData[n]
will be clamped to [0,1]. This restriction can be lifted by a separate
extension, for example by the proposed color_clamp_control extension.
13) What texture operations are not affected by a fragment shader
performing a texture lookup?
RESOLUTION: Whether or not a fragment shader is active, the following
operations still behave as specified:
* texture image specification (pp. 119-128)
* alternate texture image specification (pp. 128-132)
* compressed texture image specification (pp. 132-135)
* texture parameters behave as specified even when a texture is
accessed from within a fragment shader (pp. 135-147)
* texture state and proxy state (pp. 148-149)
* texture object specification (pp. 149-152)
* texture comparison modes (p. 157)
14) What is the interaction with a possible MRT (Multiple Render Target)
extension?
The OpenGL Shading Language defines the array gl_FragData[] to output
values to multiple buffers. There are two situations to consider.
1) There is no MRT extension support. A shader can statically assign a
value to either gl_FragColor or gl_FragData[0] (but not both).
Either way the same buffer will be targeted.
2) There is MRT support. In this case what happens is defined in the
relevant MRT extension documentation.
None
Accepted by the <shaderType> argument of CreateShaderObjectARB and
returned by the <params> parameter of GetObjectParameter{fi}vARB:
FRAGMENT_SHADER_ARB 0x8B30
Accepted by the <pname> parameter of GetBooleanv, GetIntegerv,
GetFloatv, and GetDoublev:
MAX_FRAGMENT_UNIFORM_COMPONENTS_ARB 0x8B49
MAX_TEXTURE_COORDS_ARB 0x8871
MAX_TEXTURE_IMAGE_UNITS_ARB 0x8872
Accepted by the <target> parameter of Hint and the <pname> parameter of
GetBooleanv, GetIntegerv, GetFloatv, and GetDoublev:
FRAGMENT_SHADER_DERIVATIVE_HINT_ARB 0x8B8B
Additions to Chapter 2 of the OpenGL 1.4 Specification (OpenGL Operation)
Modify Section 2.1.1, Floating-Point Computation (p. 6)
(modify first paragraph, p. 6) ... are accurate to about 1 part in 10^5.
The maximum representable magnitude of a floating-point number used to
represent positional, normal or texture coordinates must be at least
2^32. The maximum representable magnitude for colors must be at least
2^10. The maximum representable magnitude for all other floating-point
values must be at least 2^32.
Modify Section 2.7, Vertex Specification (p. 19)
(modify second paragraph, p. 20) Implementations support more than one
set of texture coordinates. The commands
void MultiTexCoord{1234}{sifd}(enum texture, T coords)
void MultiTexCoord{1234}{sifd}v(enum texture, T coords)
take the coordinate set to be modified as the <texture> parameter.
<texture> is a symbolic constant of the form TEXTUREi, indicating that
texture coordinate set i is to be modified. The constants obey TEXTUREi
= TEXTURE0 + i (i is in the range 0 to k-1, where k is the
implementation-dependent number of texture units defined by
MAX_TEXTURE_COORDS_ARB).
Modify Section 2.8, Vertex Arrays (p. 23)
(modify first paragraph, p. 23) ... The client may specify up to 7 plus
the value of MAX_TEXTURE_COORDS_ARB arrays: one each to store vertex
coordinates...
(modify first paragraph, p. 25) The command
void ClientActiveTexture(enum texture)
is used to select the vertex array client state parameters to be
modified by the TexCoordPointer command and the array affected by
EnableClientState and DisableClientState with parameter
TEXTURE_COORD_ARRAY. This command sets the client state variable
CLIENT_ACTIVE_TEXTURE. Each texture coordinate set has a client state
vector which is selected when this command is invoked. This state vector
includes the vertex array state. This call also selects the texture
coordinate set state used for queries of client state.
(modify first paragraph, p. 30) If the number of supported texture
coordinate sets (the value of MAX_TEXTURE_COORDS_ARB) is k, ...
Modify Section 2.10.2, Matrices (p. 33)
(modify first paragraph, p. 37) For each texture coordinate set, a 4x4
matrix is applied to the corresponding texture coordinates. This matrix
is applied as...
(modify third and fourth paragraphs, p. 37) The command
void ActiveTexture(enum texture)
specifies the active texture unit selector, ACTIVE_TEXTURE. Each texture
unit contains up to two distinct sub-units: a texture coordinate
processing unit (consisting of a texture matrix stack and texture
coordinate generation state) and a texture image unit (consisting of all
the texture state defined in Section 3.8). In implementations with a
different number of supported texture coordinate sets and texture image
units, some texture units may consist of only one of the two sub-units.
The active texture unit selector specifies the texture coordinate set
accessed by commands involving texture coordinate processing. Such
commands include those accessing the current matrix stack (if
MATRIX_MODE is TEXTURE), TexGen (section 2.10.4), Enable/Disable (if any
texture coordinate generation enum is selected), as well as queries of
the current texture coordinates and current raster texture coordinates.
If the texture coordinate set number corresponding to the current value
of ACTIVE_TEXTURE is greater than or equal to the
implementation-dependent constant MAX_TEXTURE_COORDS_ARB, the error
INVALID_OPERATION is generated by any such command.
The active texture unit selector also selects the texture image unit
accessed by commands involving texture image processing (section 3.8).
Such commands include all variants of TexEnv, TexParameter, and TexImage
commands, BindTexture, Enable/Disable for any texture target (e.g.,
TEXTURE_2D), and queries of all such state. If the texture image unit
number corresponding to the current value of ACTIVE_TEXTURE is greater
than or equal to the implementation-dependent constant
MAX_TEXTURE_IMAGE_UNITS_ARB, the error INVALID_OPERATION is generated by
any such command.
ActiveTexture generates the error INVALID_ENUM if an invalid <texture>
is specified. <texture> is a symbolic constant of the form TEXTUREi,
indicating that texture unit i is to be modified. The constants obey
TEXTUREi = TEXTURE0 + i (i is in the range 0 to k-1, where k is the
larger of the MAX_TEXTURE_COORDS_ARB and MAX_TEXTURE_IMAGE_UNITS_ARB).
For compatibility with old OpenGL specifications, the
implementation-dependent constant MAX_TEXTURE_UNITS specifies the number
of conventional texture units supported by the implementation. Its value
must be no larger than the minimum of MAX_TEXTURE_COORDS_ARB and
MAX_TEXTURE_IMAGE_UNITS_ARB.
(modify third paragraph, p. 38) The state required to implement
transformations consists of a 4-valued integer indicating the current
matrix mode, one stack of at least two 4x4 matrices for each of COLOR,
PROJECTION, each texture coordinate set, and TEXTURE and a stack of at
least 32 4x4 matrices for MODELVIEW. Each matrix stack has an associated
stack pointer. Initially, there is only one matrix on each stack, and
all matrices are set to the identity. The initial matrix mode is
MODELVIEW. The initial value of ACTIVE_TEXTURE is TEXTURE0.
Additions to Chapter 3 of the OpenGL 1.4 Specification (Rasterization)
(Modify first paragraph, p. 61)... Figure 3.1 diagrams the rasterization
process. The color value assigned to a fragment is initially determined
by the rasterization operations (sections 3.3 through 3.7) and modified
by either the execution of the texturing, color sum, and fog operations
as defined in sections 3.8, 3.9, and 3.10, or of a fragment shader
defined in section 3.11. The final depth value is initially determined
by the rasterization operations and may be modified or replaced by a
fragment shader. The results from rasterizing a point, line, polygon,
pixel rectangle or bitmap can be routed through a fragment shader.
(modify Figure 3.1)
_ +---------------+ switch depending on a
/|| Point |\ fragment shader being active
/ | Rasterization | \ o-------------+
/ +---------------+ -++-++--->o |
From / +---------------+ / | || o |
Primitive ---> | Line |/ | || | |
Assembly \ | Rasterization | / || | |
\ +---------------+ / || | |
\ +---------------+/ || +-----+-----+ +----+-----+
\|| Polygon | || | Texturing | | Fragment |
- | Rasterization | / | +-----+-----+ | Shader |
+---------------+ / | | +----+-----+
+---------------+ / | +-----+-----+ |
| Pixel | / | | Color Sum | |
DrawPixels --> | Rectangle |/ / +-----+-----+ |
| Rasterization | / | V
+---------------+ / +-----+-----+
+---------------+ / | Fog |---> Fragments
Bitmap ----> | Bitmap | / +-----------+
| Rasterization |/
+---------------+
Modify Section 3.3.1, Basic Point Rasterization (p. 67)
(modify last paragraph, p. 67) All fragments produced in rasterizing a
non-antialiased point are assigned the same associated data, which are
those of the vertex corresponding to the point. If a fragment shader is
active (see section 3.11) the texture coordinates s, t, r, and q are
passed on directly. Otherwise, the texture coordinates s, t, and r are
replaced by s/q, t/q, and r/q, respectively, and if q is less than or
equal to zero, the results are undefined.
(modify second paragraph p. 68) If antialiasing is enabled, then point
rasterization produces a fragment for each fragment square that
intersects the region lying within the circle having diameter equal to
the current point width and centered at the point's (Xw, Yw) (figure
3.3). The coverage value for each fragment in the window coordinate area
of the intersection of the circular region with the corresponding
fragment square (but see section 3.2). This value is saved and used in
the final step of rasterization (section 3.12). The data associated with
each fragment are otherwise the data associated with the point being
rasterized, with the exception of the texture coordinates. If a fragment
shader is active, texture coordinates s, t, r, and q are passed on
directly. Otherwise, the texture coordinates s, t, and r are replaced by
s/q, t/q, and r/q, respectively, and if q is less than or equal to zero,
the results are undefined.
Modify Section 3.4.1, Basic Line Segment Rasterization (p. 71)
(modify last paragraph, p. 72) ... or the s, t, r, or q texture
coordinate or the clip w coordinate (the depth value, window z, must be
found using equation 3.5, below), is found as
(Equation 3.4)
where fa and fb are the data associated with the starting and ending
endpoints of the segment, respectively; wa and wb are the clip w
coordinates of the starting and ending endpoints of the segments,
respectively. When there is no fragment shader active (see section
3.11), alpha a = alpha b = 1 for all data except texture coordinates, in
which case alpha a = qa and alpha b = qb (qa and qb are the homogeneous
texture coordinates at the starting and ending endpoints of the segment;
results are undefined if either of these is less than or equal to 0).
When a fragment shader is active, alpha a = alpha b = 1 for all
components (i.e., q is interpolated along with s, t, and r). Note that
linear interpolation would use ...
... A GL implementation may choose to approximate equation 3.4 with 3.5,
but this will normally lead to unacceptable distortion effects when
interpolating texture coordinates or clip w coordinates.
Modify Section 3.5.1, Basic Polygon Rasterization (p. 77)
(modify fourth paragraph, p. 78) ... When no fragment shader is active
(section 3.11), alpha a = alpha b = alpha c = 1 except for texture s, t,
and r coordinates, for which alpha a = qa, alpha b = qb, and alpha c =
qc (if any of qa, qb, or qc are less than or equal to zero, results are
undefined). When a fragment shader is active, alpha a = alpha b = alpha
c = 1 for all components (i.e., q is interpolated along with s, t, and
r). ...
(modify first paragraph p. 79) this may yield acceptable results for
color values (it must be used for depth values), but will normally lead
to unacceptable distortion effects if used for texture coordinates or
clip w coordinates.
Modify Section 3.6.4, Rasterization of Pixel Rectangles (p. 95)
(modify third paragraph, p. 106) A fragment arising from a group
consisting of color data ...,and texture coordinates are taken from the
current raster position's associated texture coordinates. If a fragment
shader is active (see section 3.11) the texture coordinates s, t, r, and
q are passed on directly. Otherwise, the texture coordinates s, t, and r
are replaced by s/q, t/q, and r/q, respectively, and if q is less than
or equal to zero, the results are undefined. Groups arising from
DrawPixels ...
Modify Section 3.7, Bitmaps (p. 116)
(modify first paragraph, p. 118) ...The associated data for each
fragment are those associated with the current raster position. If a
fragment shader is active (see section 3.11) the texture coordinates s,
t, r, and q are passed on directly. Otherwise, the texture coordinates
s, t, and r are replaced by s/q, t/q, and r/q, respectively, and if q is
less than or equal to zero, the results are undefined. Once the
fragments have been produced,...
Modify Section 3.8, Texturing (p. 118)
(change the first full paragraph on p. 119) The GL provides two ways to
specify the details of how texturing of a primitive is effected. The
first is referred to as fixed functionality, and is described in this
section. The second is referred to as a fragment shader, and is
described in section 3.11. The specification of the image to be texture
mapped and the means by which the image is filtered when applied to the
primitive are common to both methods and are discussed in this section.
The fixed functionality method for determining what RGBA value is
produced is also described in this section. If a fragment shader is
active, the method for determining the RGBA value is specified by an
application-supplied fragment shader as described in the OpenGL Shading
Language Specification.
Modify Section 3.8.8, Texture Minification (p. 140)
(change the first paragraph of the "Scale Factor and Level of Detail"
section)
The choice is governed by a scale factor rho(x,y) and the level of
detail parameter lambda(x,y), defined as
lambda_base(x,y) = log2[rho(x,y)] 3.16a
lambda'(x,y) = lambda_base(x,y) + 3.16b
clamp(texobj_bias + texunit_bias + fragshader_bias)
|------- lod_max lambda' > lod_max
lambda(x,y) = | lambda' lod_min <= lambda' <= lod_max 3.16c
| lod_min lambda' < lod_min
|------- undefined lod_min > lod_max
texobj_bias is the value of TEXTURE_LOD_BIAS for the bound texture
object (as described in section 3.8.4), and texunit_bias is the value of
TEXTURE_LOD_BIAS for the current texture unit (as described in section
3.8.13). fragshader_bias is the value of the optional bias parameter in
the texture lookup functions available to a fragment shader. If a
fragment shader is active, but the bias parameter is not provided, or if
no fragment shader is active, then fragshader_bias is zero. The sum of
these values is clamped to the range [-max_bias, max_bias] where
max_bias is the value of the implementation defined constant
MAX_TEXTURE_LOD_BIAS.
Modify Section 3.8.15, Texture Application (p. 158)
(modify fifth paragraph, p. 158) Texturing is enabled and disabled
individually for each texture unit. If texturing is disabled for one of
the units, then the fragment resulting from the previous unit is passed
unaltered to the following unit. Individual texture units beyond those
specified by MAX_TEXTURE_UNITS are always treated as disabled.
Modify Section 3.9, Color Sum (p. 160)
(add a new sentence before first paragraph, p. 160) If no fragment
shader is active (see Section 3.11), a color sum operation is performed
involving the primary and secondary colors.
(change the last sentence of the section, p. 160) Color sum has no
effect in color index mode or if a fragment shader is active.
Modify Section 3.10, Fog (p. 160)
(Change the first sentence, p. 160) If no fragment shader is active (see
Section 3.11) and fog is enabled, an operation is performed that blends
a fog color with a rasterized fragment's ....
Modify Section 3.11, Antialiasing Application
Rename this section to Section 3.12.
Add Section 3.11, Fragment Shaders
The sequence of operations that are applied to fragments that result
from rasterizing a point, line segment, polygon, pixel rectangle or
bitmap as described in Sections 3.8 through 3.10 is a
fixed-functionality method for processing such fragments. Applications
can more generally describe the operations that occur on such fragments
by using a "fragment shader".
A fragment shader is an array of strings containing source code for the
operations that are meant to occur on each fragment that results from
rasterizing a point, line segment, polygon, pixel rectangle or bitmap.
The language used for fragment shaders is described in the OpenGL
Shading Language Specification.
A fragment shader only applies when the GL is in RGBA mode. Its
operation in color index mode is undefined.
Section 3.11.1 Creating and Using a Fragment Shader
In order to create a fragment shader, call CreateShaderObjectARB with a
<shaderType> of FRAGMENT_SHADER_ARB. The source code for the fragment
shader can be specified using the ShaderSourceARB command. A fragment
shader is compiled by calling CompileShaderARB and attached to a program
object by calling AttachObjectARB. When LinkProgramARB is issued, all of
the attached shader objects of type FRAGMENT_SHADER_ARB are linked
together to create an executable program that can be used to process
fragments that arise from rasterizing points, line segments, polygons,
pixel rectangles or bitmpas. This executable program will become part of
current state when UseProgramObjectARB is issued.
CreateShaderObjectARB will set the object specific parameter
OBJECT_SUBTYPE_ARB to FRAGMENT_SHADER_ARB.
Section 3.11.2 Uniform Variables
A fragment shader may define one or more "uniform" variables. These
values are expected to remain constant over a primitive or a sequence of
primitives. The OpenGL Shading Language Specification defines a set of
built-in uniform variables for fragment shaders that correspond to the
state that GL manages for the purpose of processing fragments that are
generated by the rasterization of points, line segments, and polygons.
The amount of storage that is available for fragment shader uniform
variables is specified by the implementation dependent constant
MAX_FRAGMENT_UNIFORM_COMPONENTS_ARB. This value represents the number of
individual floating point values, or individual integer values, or
individual Boolean values that can be held in uniform variable storage
for a fragment shader. A link error will be generated if an attempt is
made to utilize more than the space available for fragment shader
uniform variables.
Section 3.11.3 Varying Variables
A fragment shader consumes the data produced as a result of the
rasterization of points, line segments, polygons, pixel rectangles or
bitmaps. If no vertex shader is active, the data that is available to
the fragment shader at each fragment consists of the same types of data
that are normally associated with a fragment for fixed functionality
fragment processing, namely, the fragment's coordinate, color, secondary
color, texture coordinates, fog coordinate, and eyeZ. The OpenGL Shading
Language Specification defines a set of built-in varying variables that
can be used to access these values within a fragment shader.
When a vertex shader is active, it may define one or more "varying"
variables (see Section 2.15.4 and the OpenGL Shading Language
Specification). These values are expected to be interpolated across the
primitive being rendered. The results of these interpolations are
available within a fragment shader through varying variables that are
defined as varying variables in the fragment shader with the same names
as those defined in the vertex shader.
Section 3.11.4 Fragment Shader Execution Environment
If a fragment shader is active, the executable version of the fragment
shader is used to process incoming fragment values that are the result
of point, line segment, polygon, pixel rectangle or bitmap rasterization
rather than the fixed functionality fragment processing described in
Sections 3.8-3.10. In particular,
* the texture environments and texture functions described in Section
3.8.13 are not applied (pp. 152-157)
* texture application as described in Section 3.8.15 is not applied.
(pp. 158- 160)
* color sum as described in Section 3.9 is not applied (p. 160)
* fog as described in Section 3.10 is not applied (p. 160-162)
When a texture lookup is performed in a fragment shader, the GL computes
the filtered texture value ? in the manner described in sections 3.8.8
and 3.8.9, and converts it to a texture source color C_s according to
table 3.21 (section 3.8.13). The GL returns a four-component vector
(R_s, G_s, B_s, A_s) to the fragment shader. For the purposes of
level-of-detail calculations, the derivates du/dx, du/dy, dv/dx, dv/dy,
dw/dx and dw/dy may be approximated by a differencing algorithm as
detailed in section 8.8 of the OpenGL Shading Language specification.
Texture comparison requires the fragment shader to use the shadow
versions of the texture lookup functions. This in turn means that
samplers of type sampler1DShadow or sampler2DShadow or
sampler2DRectShadow need to be used to indicate the texture image unit
that has a depth texture bound to it.
The results of a texture lookup function are undefined if:
* The sampler used in a texture lookup function is of type sampler1D
or sampler2D or sampler2DRect, and the texture object's internal
format is DEPTH_COMPONENT, and the TEXTURE_COMPARE_MODE is not NONE.
* The sampler used in a texture lookup function is of type
sampler1DShadow or sampler2DShadow or sampler2DRectShadow, and the
texture object's internal format is DEPTH_COMPONENT, and the
TEXTURE_COMPARE_MODE is NONE.
* The sampler used in a texture lookup function is of type
sampler1DShadow or sampler2DShadow or sampler2DRectShadow, and the
texture object's internal format is not DEPTH_COMPONENT_ARB.
If a fragment shader uses a sampler which associated texture object is
not complete, as defined in section 3.8.10, the texture image unit will
return (R, G, B, A) = (0, 0, 0, 1).
The number of separate texture units that can be accessed from within a
fragment shader during the rendering of a single primitive is specified
by the implementation- dependent constant MAX_TEXTURE_IMAGE_UNITS_ARB.
A fragment shader has access to the read-only built-in variable
gl_FrontFacing whose value is true if the fragment belongs to a
front-facing primitive. A fragment derives its facing direction from the
primitive that generates the fragment. All fragments generated by
primitives other than polygons, triangles, or quadrilaterals are
considered to be front facing. For all other fragments (including ones
resulting from point- and line-mode polygons) the determination is made
by examining the sign of the area computed by equation 2.6 of section
2.13.1 (including the possible reversal of this sign as indicated by the
last call to FrontFace). If the sign is positive then the fragments are
front facing; otherwise, they are back facing.
When processing fragments resulting from the rasterization of a pixel
rectangle or bitmap, results are undefined if the fragment shader uses a
varying variable that is not a built-in varying variable (see Section
7.6 of the Shading Language Specification for a list).
Section 3.11.5 Fragment Shader Input
The OpenGL Shading Language specification describes the values that are
available as inputs to the fragment shader. This section is concerned
with the built-in variables gl_FragCood, gl_Color and gl_SecondaryColor.
The built-in gl_FragCoord holds the window relative coordinates x, y, z,
and 1/w for the fragment. The "z" component of gl_FragCoord undergoes an
implied conversion to floating point. This conversion must leave the
values 0 and 1 invariant. Note that this "z" component already has a
polygon offset added in, if enabled. The 1/w value is computed from the
Wc coordinate (see Section 2.10), which is the result of the product of
the projection matrix and the vertex's eye coordinates.
The built-in variables gl_Color and gl_SecondaryColor hold the "r", "g",
"b", and "a" components, respectively, of the fragment color and
secondary color. Each fixed-point color component undergoes an implied
conversion to floating point. This conversion must leave the values 0
and 1 invariant.
Section 3.11.6 Fragment Shader Output
The OpenGL Shading Language specification describes the values that may
be output by a fragment shader. These are gl_FragColor, gl_FragData[n],
and gl_FragDepth. The final fragment color values or the final fragment
data values written by a fragment shader are clamped to the range [0,1]
and then converted to fixed-point as described in section 2.13.9, Final
Color Processing. The final fragment depth written by a fragment shader
is first clamped to [0,1] and then converted to fixed-point as if it
were a window z value. See Section 2.10.1, Controlling the Viewport.
Note that the depth range computation is NOT applied here, only the
conversion to fixed-point.
The OpenGL Shading Language specification defines what happens when
color, fragment data and/or depth are not written. Those rules are
repeated here.
Writing to gl_FragColor specifies the fragment color that will be used
by the subsequent fixed functionality pipeline. If subsequent fixed
functionality consumes fragment color and an execution of a fragment
shader does not write a value to gl_FragColor then the fragment color
consumed is undefined.
The variable gl_FragData is an array. Writing to gl_FragData[n]
specifies the fragment data that will be used by the subsequent fixed
functionality pipeline for data n. If subsequent fixed functionality
consumes fragment data and an execution of a fragment shader does not
write a value to it, then the fragment data consumed is undefined.
If a shader statically assigns a value to gl_FragColor, it may not
assign a value to any element of gl_FragData. If a shader statically
writes a value to any element of gl_FragData, it may not assign a value
to gl_FragColor. That is, a shader may assign values to either
gl_FragColor or gl_FragData, but not both..
Writing to gl_FragDepth will establish the depth value for the fragment
being processed. If depth buffering is enabled, and a shader does not
write gl_FragDepth, then the fixed function value for depth will be used
as the fragment's depth value. If a shader statically assigns a value to
gl_FragDepth, and there is an execution path through the shader that
does not set gl_FragDepth, then the value of the fragment's depth may be
undefined for some executions of the shader. That is, if a shader
statically contains a write to gl_FragDepth, then it is responsible for
always writing it.
Note, a shader contains a static assignment to a variable x if, after
pre-processing, the shader contains a statement that would write to x,
whether or not run-time flow of control will cause that statement to be
executed.
Section 3.11.7 Required State
Besides the required state outlined in the ARB_shader_objects extension
document, the following state per program object is also required:
* An array of MAX_FRAGMENT_UNIFORM_COMPONENTS_ARB words that holds
uniform values.
Modify Section 3.12, Multisample Point Fade
Rename this section to Section 3.13.
Additions to Chapter 4 of the OpenGL 1.4 Specification (Per-Fragment
Operations and the Frame Buffer)
None
Additions to Chapter 5 of the OpenGL 1.4 Specification (Special Functions)
Modify Section 5.6, Hints (p. 203)
(add to the paragraph describing the hints)... the desired quality and
performance of compressing texture images;
FRAGMENT_SHADER_DERIVATIVE_HINT_ARB, indicating the desired derivative
accuracy for the fragment processing built-in functions dFdx, dFdy and
fwidth. Hint must be one of FASTEST, ...
Additions to Chapter 6 of the OpenGL 1.4 Specification (State and State Requests)
Modify Section 6.1.2, Data Conversions (p. 205)
(add to end of last paragraph, p. 206) Queries of texture state
variables corresponding to a texture coordinate processing unit (namely,
TexGen state and enables, and matrices) will produce an
INVALID_OPERATION error if the value of ACTIVE_TEXTURE is greater than
or equal to MAX_TEXTURE_COORDS_ARB. All other texture state queries will
result in an INVALID_OPERATION error if the value of ACTIVE_TEXTURE is
greater than or equal to MAX_TEXTURE_IMAGE_UNITS_ARB.
Modify section 6.1.12 Object Queries.
The commands
void GetObjectParameter{if}vARB(handleARB obj, enum pname, T params)
return object specific parameter values for object <obj> in <params>.
The parameter value to return is specified by <pname>.
If <pname> is OBJECT_TYPE_ARB, GetObjectParameter{if}vARB returns
PROGRAM_OBJECT_ARB if <obj> references a program object. It returns
SHADER_OBJECT_ARB if <obj> references any shader object. If <obj> is not
of type PROGRAM_OBJECT_ARB or SHADER_OBJECT_ARB, the error
INVALID_OPERATION is generated.
If <pname> is OBJECT_SUBTYPE_ARB, GetObjectParameter{if}vARB returns
FRAGMENT_SHADER_ARB if <obj> references a shader object. If <obj> is not
of type SHADER_OBJECT_ARB, the error INVALID_OPERATION is generated.
Additions to Appendix A of the OpenGL 1.4 Specification (Invariance)
Add to end of Section A.3 (p. 250):
The same fragment shader will produce the same result when run multiple
times with the same input. The wording 'the same shader' means a program
object that is populated with the same source strings, which are
compiled and then linked, possibly multiple times. This program object
is then executed using the same GL state vector.
All fragment shaders that either conditionally or unconditionally assign
gl_FragCoord.z to gl_FragDepth are depth-invariant with respect to each
other, for those fragments where the assignment to gl_FragDepth actually
is done.
Additions to the AGL/GLX/WGL Specifications
None
Interactions with ARB_vertex_program and ARB_fragment_program
Mixing a high level ARB_fragment_shader shader with a low level
ARB_vertex_program shader is allowed. However, a high level
ARB_fragment_shader shader and a low level ARB_fragment_program shader
cannot be active at the same time.
Interactions with ARB_fragment_program
Enabling an ARB_fragment_shader shader by issuing the command
UseProgramObjectARB(), with a handle which is not zero, results in any
low level fragment shader to be ignored and overrides the enable
FRAGMENT_PROGRAM_ARB. Note that the value for FRAGMENT_PROGRAM_ARB does
not change by installing an ARB_fragment_shader shader.
The following enumerants are borrowed from ARB_fragment_program. Their
usage and meaning has stayed the same:
MAX_TEXTURE_COORDS_ARB 0x8871
MAX_TEXTURE_IMAGE_UNITS_ARB 0x8872
Interactions with ARB_vertex_shader
If ARB_vertex_shader is present, then this extension does not also
define the new token SHADER_OBJECT_ARB.
If ARB_vertex_shader is not present, the wording of Section 3.11.3
Varying Variables needs to be modified to omit references to the vertex
shader.
Errors
The error INVALID_OPERATION is generated by any command accessing
texture coordinate processing state if the texture unit number
corresponding to the current value of ACTIVE_TEXTURE is greater than or
equal to the implementation-dependent constant MAX_TEXTURE_COORDS_ARB.
The error INVALID_OPERATION is generated by any command accessing
texture image processing state if the texture unit number corresponding
to the current value of ACTIVE_TEXTURE is greater than or equal to the
implementation-dependent constant MAX_TEXTURE_IMAGE_UNITS_ARB.
The error INVALID_VALUE is generated by any command that takes one or
more handles as input, and one or more of these handles are not an
object handle generated by OpenGL.
The error INVALID_OPERATION is generated by GetObjectParameter{if}vARB
if <pname> is OBJECT_TYPE_ARB and <obj> is not of type
PROGRAM_OBJECT_ARB or SHADER_OBJECT_ARB.
The error INVALID_OPERATION is generated by GetObjectParameter{if}vARB
if <pname> is OBJECT_SUBTYPE_ARB and <obj> is not of type
SHADER_OBJECT_ARB.
New State
Initial
Get Value Type Get Command Value Description Sec. Attribute
--------- ----- ----------------------- ------------- ----------- ---- ---------
OBJECT_TYPE_ARB Z2 GetObjectParameterivARB SHADER_OBJECT Type of object 3.11.1 -
OBJECT_SUBTYPE_ARB Z2 GetObjectParameterivARB FRAGMENT_SHADER Sub type of object 3.11.1 -
Table X Shader object state.
(Add the following hint to Table 6.26, p. 241.)
Initial
Get Value Type Get Command Value Description Sec. Attribute
--------- ----- ----------------------- ------------- ----------- ---- ---------
FRAGMENT_SHADER_DERIVATIVE_HINT fragment shader
Z3 GetIntegerv DONT_CARE derivative accuracy 5.6 hint
hint
New Implementation Dependent State
Minimum
Get Value Type Get Command Value Description Sec. Attr.
--------- ---- ----------- ------- ----------- ---- -----
MAX_FRAGMENT_UNIFORM_COMPONENTS_ARB Z+ GetIntegerv 64 Number of words 3.11.2 -
for fragment shader
uniform variables
MAX_TEXTURE_IMAGE_UNITS_ARB Z+ GetIntegerv 2 Number of separate 3.11.4 -
texture image units
MAX_TEXTURE_COORDS_ARB Z+ GetIntegerv 2 number of texture 2.7 -
coordinate sets
Sample Usage
The code below is taken from the sample section in ARB_vertex_shader and
expanded to include a fragment shader.
GLboolean init(GLcharARB *vertexShader, GLcharARB *fragmentShader)
{
const GLcharARB *pInfoLog;
GLboolean compiled = GL_FALSE;
GLboolean linked = GL_FALSE;
GLint length;
//
// Create shader and program objects.
//
ProgramObject = glCreateProgramObjectARB();
VertexShaderObject = glCreateShaderObjectARB(GL_VERTEX_SHADER_ARB);
FragmentShaderObject = glCreateShaderObjectARB(GL_FRAGMENT_SHADER_ARB);
length = strlen(vertexShader);
glShaderSourceARB(VertexShaderObject, 1, &vertexShader, &length);
glShaderSourceARB(FragmentShaderObject, 1, &fragmentShader, NULL);
//
// OpenGL made a copy of the shaders, we can free our copy
//
free(vertexShader);
free(fragmentShader);
//
// Compile the vertex and fragment shader, and print out the
// compiler log file.
//
glCompileShaderARB(VertexShaderObject);
glGetObjectParameterivARB(VertexShaderObject,
GL_OBJECT_COMPILE_STATUS_ARB, &compiled);
glGetObjectParamterivARB(VertexShaderObject,
GL_OBJECT_INFO_LOG_LENGTH_ARB, &maxLength);
pInfoLog = (GLcharARB *) malloc(maxLength * sizeof(GLcharARB));
glGetInfoLogARB(VertexShaderObject, maxLength, &length, pInfoLog);
printf("%s", pInfoLog);
free(pInfoLog);
if (!compiled) {
printf("Compile failed\n");
return GL_FALSE;
}
glCompileShaderARB(FragmentShaderObject);
glGetObjectParameterivARB(FragmentShaderObject,
GL_OBJECT_COMPILE_STATUS_ARB, &compiled);
glGetObjectParamterivARB(FragmentShaderObject,
GL_OBJECT_INFO_LOG_LENGTH_ARB, &maxLength);
pInfoLog = (GLcharARB *) malloc(maxLength * sizeof(GLcharARB));
glGetInfoLogARB(FragmentShaderObject, maxLength, NULL, pInfoLog);
printf("%s", pInfoLog);
free(pInfoLog);
if (!compiled) {
printf("Compile failed\n");
return GL_FALSE;
}
//
// Populate the program object with the compiled shadera
//
glAttachObjectARB(ProgramObject, VertexShaderObject);
glAttachObjectARB(ProgramObject, FragmentShaderObject);
//
// We want the shader objects to go away as soon as it is detached
// from the program object it is attached to. We can simply call
// delete now to achieve that. Note that calling delete on a program
// object will result in all shaders attached to that program object
// to be detached. If delete has been called for the shader objects,
// calling delete on the program object will result in the shader
// objects being deleted as well.
//
glDeleteObjectARB(VertexShaderObject);
glDeleteObjectARB(FragmentShaderObject);
//
// Link the program object and print out the linker log file
//
glLinkProgramARB(ProgramObject);
glGetObjectParameterivARB(ProgramObject,
GL_OBJECT_LINK_STATUS_ARB, &linked);
glGetObjectParamterivARB(ProgramObject,
GL_OBJECT_INFO_LOG_LENGTH_ARB, &maxLength);
pInfoLog = (GLcharARB *) malloc(maxLength * sizeof(GLcharARB));
glGetInfoLogARB(ProgramObject, maxLength, NULL, pInfoLog);
printf("%s\n", pInfoLog);
free(pInfoLog);
//
// If all went well, make the program object part of the current state
//
if (linked) {
glUseProgramObjectARB(ProgramObject);
return GL_TRUE;
} else {
return GL_FALSE;
}
}
Revision History
Revision 0.5, 6/6/2002
- First draft for circulation
Revision 0.51, 6/10/2002
- Listed all varyings that a fragment shader can access
- Clarified section 3.11.6
- Added more to the 'Interaction with GL2_vertex_shader' section
Revision 0.52, 6/12/2002
- Now references V1.0 of the OpenGL Shading Language Specification
- Fixed minor typos
- Accepted by the GL2 working group
Revision 0.52, 10/17/2002
- Removed IsObjectGL2()
- Expanded GetObjectParameter{if}GL2. Added OBJECT_SUBTYPE_GL2.
Revision 0.53, 10/18/2002
- Forgot to add _GL2 to the end of MAX_FP_TEXTURE_UNITS_GL2.
- Added language disallowing mixing GL2 high level vertex shader with
low level ARB vertex program or fragment program.
Revision 0.54, 10/24/2002
- Removed the resource limit section and move it to GL2_shader_objects
- Clarified some sections across the document
- Based on ARB_fragment_program split a texture unit into two sub
units. This resulted in expanding Section 2 significantly.
- Expanded section 6
- Expanded Errors section
- Added sample usage
Revision 0.6, 10/29/2002
- Now written against the OpenGL 1.4 specification.
- Second distribution to the GL2 working group.
Revision 0.61, 11/26/2002
- Renamed MAX_FP_TEXTURE_UNITS to MAX_FRAGMENT_TEXTURE_UNITS.
- Updated list of contributors.
- Allowed mixing of a high level GL2 fragment shader with a low level
ARB_vertex_program shader.
Revision 0.62, 12/04/2002
- Changed issue 3 wording to make the number of texture image units
and coordinates units independent from each other.
- Changed MAX_FRAGMENT_UNIFORM_FLOATS_GL2 to
MAX_FRAGMENT_UNIFORM_WORDS_GL2. Also changed language in paragraph
3.11.2 clarifying this new constant.
- Added issue number 5.
Revision 0.63, 02/13/2003
- Consistently used 'texture coordinate set'
- Changed 3.11.5, fragment shader output. Colors are clamped, and
depths are clamped then converted to fixed point.
- Added Section 3.11.4.1 Fragment Shader Texturing
Revision 0.64, 02/21/2003
- Modified section 2.10.1
- Added color conversion to fixed-point to the values written to
gl_FragColor. Section 3.11.5.
Revision 0.65, 03/06/2003
- Added a third LOD bias parameter to section 3.8.8 (comes from the
texture lookup functions).
- Added issues 6 and 7.
- Added clip w coordinate interpolation for lines and polygons.
- Upgraded colors and texture coordinates to be full floating point
citizens, section 2.1.1.
- Updated the interactions section.
- Renamed MAX_FRAGMENT_TEXTURE_UNITS_GL2 to
MAX_TEXTURE_IMAGE_UNITS_ARB
Revision 0.66, 03/26/2003
- Expanded issues 2 and 3.
- Added modification to section 3.8.15.
- Updated contributors list. Who else?
- Updated IP Status section to point to the contributors agreement.
Revision 0.67, 04/09/2003
- Added required state section.
- Renamed handle to handleGL2
Revision 0.68, 05/08/2003
- Changed MAX_FRAGMENT_UNIFORM_WORDS_GL2 to
MAX_FRAGMENT_UNIFORM_COMPONENTS_GL2
- Updated example section to reflect the latest API changes
- Changed the location of the Contributors License to a publicly
accessible place on www.3dlabs.com.
- Re-worded the introduction.
- Added OBJECT_TYPE_GL2 to the list of new tokens.
- Moved issue 3 up to be issue 1.
- Re-wrote section 3.8, introduction.
- Added issue 8.
- Added front/back facing language to section 3.11.4
- Re-wrote issue 3.
- Added language to appendix A. Invariance.
- Added section 3.11.5 Fragment Shader Input
- Added issue 9
- Fixed section 3.11.4. Texture enables are ignored.
- Added issue 10.
- Added a note about polygon offset to section 3.11.5.
- Reversed the resolution of issue 5. Changed chapter 3 to reflect
this.
- Updated sample code to reflect latest API names.
- Updated errors section.
- Numerous small fixes based on Pat's comments.
- Depth values are converted to floating point before entering the
fragment shader. Updated issue 7 to reflect this.
- Fixed up the state tables.
- Updated section 3.11.4. Clarified depth texture comparison mode when
a fragment shader is active.
- Added Jon Leech, Evan Hart, Benjamin Lipchak and Jeremy Sandmel to
the list of contributors.
Revision 0.69, 05/09/2003
- Added to issue 5. In this case fragment shader should only reference
built- in varying variables s (starting with "gl_"). Also added spec
language to section 3.11.4.
- Added one more paragraph to issue 4, invariance. If you do not write
to gl_FragDepth you're depth invariant with fixed-function.
- Explained 'statically assigned'
- Assigned enum values.
- Version approved by the ARB-GL2 working group.
Revision 0.70, 05/14/2003
- Section 3.8.15 clarified.
- Issue 8 intended to explain what happens when
VERTEX_PROGRAM_TWO_SIDE_ARB is false, not true. Fixed.
- Clarified fragment front/back facing selection when in polygon point
or line mode.
- Fixed typos.
- Renamed all GL2 occurrences to ARB.
- Added SHADER_OBJECT_ARB to the list of new tokens.
- Deleted reference to AppendShader (this call no longer exist).
Revision 0.71, 06/30/2003
- Removed section 2.13.9. It no longer applies.
- The dynamic range of colors is left at 2^10, only texture
coordinates are upgraded to 2^32 (Section 2.1.1).
- Updated Sample Usage section.
- Added fixed-point conversion rule for color and secondary color.
Section 3.11.5.
- General language cleanup.
- Version approved as ARB extension
Revision 0.72, 02/23/2004
- Fixed the last part of section 3.4.1, basic line segment
rasterization.
- Removed SHADER_OBJECT_ARB, OBJECT_TYPE_ARB and OBJECT_SUBTYPE_ARB
tokens from the New Tokens section. They are already defined in
ARB_shader_objects. Also removed references to these in Chapter 6,
GetObjectParameter{fi}v and the Errors section.
- Added the official extension number (32). Edited the Status
paragraph.
Revision 0.73, 03/11/2004
- Added language to specify when texture lookups are undefined when
mixing shadow and non shadow samplers with texture objects with or
without depth components and different texture compare modes set.
Revision 0.74, 03/12/2004
- Added sampler2DRect and sampler2DRectShadow to the previous changes.
Revision 0.75, 03/16/2004
- Fixed up the sampler language from version 0.74.
- Updated section 3.11.6, Fragment Shader Output to incorporate the
new gl_FragData[] output array. Added related issues 11 and 12.
Revision 0.76, 03/19/2004
- Added a hint DERIVATIVE_ACCURACY_HINT to section 5.6 and the New
Tokens section.
Revision 0.77, 03/31/2004
- Added language to section 3.11.4 specifying that derivatives for LOD
calculations may be approximated.
- Moved spec language related to texture operations not affected by a
fragment shader from section 3.11.4 to issue 13.
- Added language to section 3.11.4, copied from the vertex shader, how
the filtered texture value is computed. Also added language that the
LOD could be computed using derivatives computed using a
differencing algorithm.
- Renamed DERIVATIVE_ACCURACY_HINT_ARB to
FRAGMENT_SHADER_DERIVATIVE_HINT_ARB and added it to the state
tables.
- Updated issue 12. gl_FragData will be clamped to [0,1]
- Added issue 14, explaining the interaction with MRT.
- Updated the shading language version this spec references to version
100.53.
- Added clamping to [0,1] for output color and fragData back into
section 3.11.6. Also updated the language in 3.11.6 to be the same
as in the OpenGL Shading Language document.
- Version voted on and approved by the workgroup.
Revision 0.78, 04/06/2004
- Minor language changes to issues 12 and 14.
- Updated the Shading Language Version referenced to the now official
version 1.10.
Revision 0.79, 05/14/2004
- Listed that FRAGMENT_SHADER_DERIVATIVE_HINT is also accepted by the
Get* commands under the New Tokens section.
- Updated issue 14. Punted most of it to the MRT extension document.
Implementation Support
List of OpenGL implementations supporting the GL_ARB_fragment_shader extension
Original File
Original text file for the GL_ARB_fragment_shader extension
Page generated on Sun Nov 20 18:36:59 2005