EXT_gpu_shader4
GL_EXT_gpu_shader4
Barthold Lichtenbelt, NVIDIA (blichtenbelt 'at' nvidia.com)
Pat Brown, NVIDIA (pbrown 'at' nvidia.com)
Multi vendor extension
Shipping for GeForce 8 Series (November 2006)
Last Modified Date: 02/04/2008
Author revision: 12
326
OpenGL 2.0 is required.
This extension is written against the OpenGL 2.0 specification and version
1.10.59 of the OpenGL Shading Language specification.
This extension trivially interacts with ARB_texture_rectangle.
This extension trivially interacts with GL_EXT_texture_array.
This extension trivially interacts with GL_EXT_texture_integer.
This extension trivially interacts with GL_EXT_geometry_shader4
This extension trivially interacts with GL_EXT_texture_buffer_object.
NV_primitive_restart trivially affects the definition of this extension.
ARB_color_buffer_float affects the definition of this extension.
EXT_draw_instanced affects the definition of this extension.
This extension provides a set of new features to the OpenGL Shading
Language and related APIs to support capabilities of new hardware. In
particular, this extension provides the following functionality:
* New texture lookup functions are provided that allow shaders to
access individual texels using integer coordinates referring to the
texel location and level of detail. No filtering is performed. These
functions allow applications to use textures as one-, two-, and
three-dimensional arrays.
* New texture lookup functions are provided that allow shaders to query
the dimensions of a specific level-of-detail image of a texture
object.
* New texture lookup functions variants are provided that allow shaders
to pass a constant integer vector used to offset the texel locations
used during the lookup to assist in custom texture filtering
operations.
* New texture lookup functions are provided that allow shaders to
access one- and two-dimensional array textures. The second, or third,
coordinate is used to select the layer of the array to access.
* New "Grad" texture lookup functions are provided that allow shaders
to explicitely pass in derivative values which are used by the GL to
compute the level-of-detail when performing a texture lookup.
* A new texture lookup function is provided to access a buffer texture.
* The existing absolute LOD texture lookup functions are no longer
restricted to the vertex shader only.
* The ability to specify and use cubemap textures with a
DEPTH_COMPONENT internal format. This also enables shadow mapping on
cubemaps. The 'q' coordinate is used as the reference value for
comparisons. A set of new texture lookup functions is provided to
lookup into shadow cubemaps.
* The ability to specify if varying variables are interpolated in a
non-perspective correct manner, if they are flat shaded or, if
multi-sampling, if centroid sampling should be performed.
* Full signed integer and unsigned integer support in the OpenGL
Shading Language:
- Integers are defined as 32 bit values using two's complement.
- Unsigned integers and vectors thereof are added.
- New texture lookup functions are provided that return integer
values. These functions are to be used in conjunction with new
texture formats whose components are actual integers, rather
than integers that encode a floating-point value. To support
these lookup functions, new integer and unsigned-integer
sampler types are introduced.
- Integer bitwise operators are now enabled.
- Several built-in functions and operators now operate on
integers or vectors of integers.
- New vertex attribute functions are added that load integer
attribute data and can be referenced in a vertex shader as
integer data.
- New uniform loading commands are added to load unsigned integer
data.
- Varying variables can now be (unsigned) integers. If declared
as such, they have to be flat shaded.
- Fragment shaders can define their own output variables, and
declare them to be of type floating-point, integer or unsigned
integer. These variables are bound to a fragment color index
with the new API command BindFragDataLocationEXT(), and directed
to buffers using the existing DrawBuffer or DrawBuffers API
commands.
* Added new built-in functions truncate() and round() to the shading
language.
* A new built-in variable accessible from within vertex shaders that
holds the index <i> implicitly passed to ArrayElement to specify the
vertex. This is called the vertex ID.
* A new built-in variable accessible from within fragment and geometry
shaders that hold the index of the currently processed
primitive. This is called the primitive ID.
This extension also briefly mentions a new shader type, called a geometry
shader. A geometry shader is run after vertices are transformed, but
before clipping. A geometry shader begins with a single primitive (point,
line, triangle. It can read the attributes of any of the vertices in the
primitive and use them to generate new primitives. A geometry shader has a
fixed output primitive type (point, line strip, or triangle strip) and
emits vertices to define a new primitive. Geometry shaders are discussed
in detail in the GL_EXT_geometry_shader4 specification.
   New Procedures and Functions |
void VertexAttribI1iEXT(uint index, int x);
void VertexAttribI2iEXT(uint index, int x, int y);
void VertexAttribI3iEXT(uint index, int x, int y, int z);
void VertexAttribI4iEXT(uint index, int x, int y, int z, int w);
void VertexAttribI1uiEXT(uint index, uint x);
void VertexAttribI2uiEXT(uint index, uint x, uint y);
void VertexAttribI3uiEXT(uint index, uint x, uint y, uint z);
void VertexAttribI4uiEXT(uint index, uint x, uint y, uint z,
uint w);
void VertexAttribI1ivEXT(uint index, const int *v);
void VertexAttribI2ivEXT(uint index, const int *v);
void VertexAttribI3ivEXT(uint index, const int *v);
void VertexAttribI4ivEXT(uint index, const int *v);
void VertexAttribI1uivEXT(uint index, const uint *v);
void VertexAttribI2uivEXT(uint index, const uint *v);
void VertexAttribI3uivEXT(uint index, const uint *v);
void VertexAttribI4uivEXT(uint index, const uint *v);
void VertexAttribI4bvEXT(uint index, const byte *v);
void VertexAttribI4svEXT(uint index, const short *v);
void VertexAttribI4ubvEXT(uint index, const ubyte *v);
void VertexAttribI4usvEXT(uint index, const ushort *v);
void VertexAttribIPointerEXT(uint index, int size, enum type,
sizei stride, const void *pointer);
void GetVertexAttribIivEXT(uint index, enum pname, int *params);
void GetVertexAttribIuivEXT(uint index, enum pname,
uint *params);
void Uniform1uiEXT(int location, uint v0);
void Uniform2uiEXT(int location, uint v0, uint v1);
void Uniform3uiEXT(int location, uint v0, uint v1, uint v2);
void Uniform4uiEXT(int location, uint v0, uint v1, uint v2,
uint v3);
void Uniform1uivEXT(int location, sizei count, const uint *value);
void Uniform2uivEXT(int location, sizei count, const uint *value);
void Uniform3uivEXT(int location, sizei count, const uint *value);
void Uniform4uivEXT(int location, sizei count, const uint *value);
void GetUniformuivEXT(uint program, int location, uint *params);
void BindFragDataLocationEXT(uint program, uint colorNumber,
const char *name);
int GetFragDataLocationEXT(uint program, const char *name);
Accepted by the <pname> parameters of GetVertexAttribdv,
GetVertexAttribfv, GetVertexAttribiv, GetVertexAttribIuivEXT and
GetVertexAttribIivEXT:
VERTEX_ATTRIB_ARRAY_INTEGER_EXT 0x88FD
Returned by the <type> parameter of GetActiveUniform:
SAMPLER_1D_ARRAY_EXT 0x8DC0
SAMPLER_2D_ARRAY_EXT 0x8DC1
SAMPLER_BUFFER_EXT 0x8DC2
SAMPLER_1D_ARRAY_SHADOW_EXT 0x8DC3
SAMPLER_2D_ARRAY_SHADOW_EXT 0x8DC4
SAMPLER_CUBE_SHADOW_EXT 0x8DC5
UNSIGNED_INT 0x1405
UNSIGNED_INT_VEC2_EXT 0x8DC6
UNSIGNED_INT_VEC3_EXT 0x8DC7
UNSIGNED_INT_VEC4_EXT 0x8DC8
INT_SAMPLER_1D_EXT 0x8DC9
INT_SAMPLER_2D_EXT 0x8DCA
INT_SAMPLER_3D_EXT 0x8DCB
INT_SAMPLER_CUBE_EXT 0x8DCC
INT_SAMPLER_2D_RECT_EXT 0x8DCD
INT_SAMPLER_1D_ARRAY_EXT 0x8DCE
INT_SAMPLER_2D_ARRAY_EXT 0x8DCF
INT_SAMPLER_BUFFER_EXT 0x8DD0
UNSIGNED_INT_SAMPLER_1D_EXT 0x8DD1
UNSIGNED_INT_SAMPLER_2D_EXT 0x8DD2
UNSIGNED_INT_SAMPLER_3D_EXT 0x8DD3
UNSIGNED_INT_SAMPLER_CUBE_EXT 0x8DD4
UNSIGNED_INT_SAMPLER_2D_RECT_EXT 0x8DD5
UNSIGNED_INT_SAMPLER_1D_ARRAY_EXT 0x8DD6
UNSIGNED_INT_SAMPLER_2D_ARRAY_EXT 0x8DD7
UNSIGNED_INT_SAMPLER_BUFFER_EXT 0x8DD8
Accepted by the <pname> parameter of GetBooleanv, GetIntegerv, GetFloatv,
and GetDoublev:
MIN_PROGRAM_TEXEL_OFFSET_EXT 0x8904
MAX_PROGRAM_TEXEL_OFFSET_EXT 0x8905
| Additions to Chapter 2 of the OpenGL 2.0 Specification (OpenGL Operation) |
Modify Section 2.7 "Vertex Specification", p.20
Insert before last paragraph, p.22:
The VertexAttrib* commands described so far should not be used to load
data for vertex attributes declared as signed or unsigned integers or
vectors thereof in a vertex shader. If they are used to load signed or
unsigned integer vertex attributes, the value in those attributes are
undefined. Instead use the commands
void VertexAttribI[1234]{i,ui}EXT(uint index, T values);
void VertexAttribI[1234]{i,ui}vEXT(uint index, T values);
void VertexAttribI4{b,s,ub,us}vEXT(uint index, T values);
to specify fixed-point attributes that are not converted to
floating-point. These attributes can be accessed in vertex shaders that
declare attributes as signed or unsigned integers or vectors. The
VertexAttribI4* commands extend the data passed in to a full signed or
unsigned integer. If a VertexAttribI* command is used that does not match
the type of the attribute declared in a vertex shader, the values in the
attributes are undefined. This means that the unsigned versions of the
VertexAttribI* commands need to be used to load data for unsigned integer
vertex attributes or vectors, and the signed versions of the
VertexAttribI* commands for signed integer vertex attributes or
vectors. Note that this also means that the VertexAttribI* commands should
not be used to load data for a vertex attribute declared as a float, float
vector or matrix, otherwise their values are undefined.
Insert at end of function list, p.24:
void VertexAttribIPointerEXT(uint index, int size, enum type,
sizei stride, const void *pointer);
(modify last paragraph, p.24) The <index> parameter in the
VertexAttribPointer and VertexAttribIPointerEXT commands identify the
generic vertex attribute array being described. The error INVALID_VALUE is
generated if <index> is greater than or equal to
MAX_VERTEX_ATTRIBS. Generic attribute arrays with integer <type> arguments
can be handled in one of three ways: converted to float by normalizing to
[0,1] or [-1,1] as specified in table 2.9, converted directly to float, or
left as integers. Data for an array specified by VertexAttribPointer will
be converted to floating-point by normalizing if the <normalized>
parameter is TRUE, and converted directly to floating-point
otherwise. Data for an array specified by VertexAttribIPointerEXT will
always be left as integer values.
(modify Table 2.4, p. 25)
Integer
Command Sizes Handling Types
---------------------- ------- --------- -----------------
VertexPointer 2,3,4 cast ...
NormalPointer 3 normalize ...
ColorPointer 3,4 normalize ...
SecondaryColorPointer 3 normalize ...
IndexPointer 1 cast ...
FogCoordPointer 1 n/a ...
TexCoordPointer 1,2,3,4 cast ...
EdgeFlagPointer 1 integer ...
VertexAttribPointer 1,2,3,4 flag ...
VertexAttribIPointerEXT 1,2,3,4 integer byte, ubyte,
short, ushort,
int, uint
Table 2.4: Vertex array sizes (values per vertex) and data types. The
"integer handling" column indicates how fixed-point data types are
handled: "cast" means that they converted to floating-point directly,
"normalize" means that they are converted to floating-point by normalizing
to [0,1] (for unsigned types) or [-1,1] (for signed types), "integer"
means that they remain as integer values, and "flag" means that either
"cast" or "normalized" applies, depending on the setting of the
<normalized> flag in VertexAttribPointer.
(modify end of pseudo-code, pp. 27-28)
for (j = 1; j < genericAttributes; j++) {
if (generic vertex attribute j array enabled) {
if (generic vertex attribute j array is a pure integer array)
{
VertexAttribI[size][type]vEXT(j, generic vertex attribute j
array element i);
} else if (generic vertex attribute j array normalization
flag is set and <type> is not FLOAT or DOUBLE) {
VertexAttrib[size]N[type]v(j, generic verex attribute j
array element i);
} else {
VertexAttrib[size][type]v(j, generic verex attribute j
array element i);
}
}
}
if (generic vertex attribute 0 array enabled) {
if (generic vertex attribute 0 array is a pure integer array) {
VertexAttribI[size][type]vEXT(0, generic verex attribute 0
array element i);
} else if (generic vertex attribute 0 array normalization flag
is set and <type> is not FLOAT or DOUBLE) {
VertexAttrib[size]N[type]v(0, generic verex attribute 0
array element i);
} else {
VertexAttrib[size][type]v(0, generic verex attribute 0
array element i);
}
}
Modify section 2.14.7, "Flatshading", p. 69
Add a new paragraph at the end of the section on p. 70 as follows:
If a vertex or geometry shader is active, the flat shading control
described so far applies to the built-in varying variables gl_FrontColor,
gl_BackColor, gl_FrontSecondaryColor and gl_BackSecondaryColor. Through
the OpenGL Shading Language varying qualifier flat any vertex attribute
can be flagged to be flat-shaded. See the OpenGL Shading Language
Specification section 4.3.6 for more information.
Modify section 2.14.8, "Color and Associated Data Clipping", p. 71
Add to the end of this section:
For vertex shader varying variables specified to be interpolated without
perspective correction (using the noperspective keyword), the value of t
used to obtain the varying value associated with P will be adjusted to
produce results that vary linearly in screen space.
Modify section 2.15.3, "Shader Variables", page 75
Add the following new return types to the description of GetActiveUniform
on p. 81.
SAMPLER_1D_ARRAY_EXT,
SAMPLER_2D_ARRAY_EXT,
SAMPLER_1D_ARRAY_SHADOW_EXT,
SAMPLER_2D_ARRAY_SHADOW_EXT,
SAMPLER_CUBE_SHADOW_EXT,
SAMPLER_BUFFER_EXT,
INT_SAMPLER_1D_EXT,
INT_SAMPLER_2D_EXT,
INT_SAMPLER_3D_EXT,
INT_SAMPLER_CUBE_EXT,
INT_SAMPLER_2D_RECT_EXT,
INT_SAMPLER_1D_ARRAY_EXT,
INT_SAMPLER_2D_ARRAY_EXT,
INT_SAMPLER_BUFFER_EXT,
UNSIGNED_INT,
UNSIGNED_INT_VEC2_EXT,
UNSIGNED_INT_VEC3_EXT,
UNSIGNED_INT_VEC4_EXT,
UNSIGNED_INT_SAMPLER_1D_EXT,
UNSIGNED_INT_SAMPLER_2D_EXT,
UNSIGNED_INT_SAMPLER_3D_EXT,
UNSIGNED_INT_SAMPLER_CUBE_EXT,
UNSIGNED_INT_SAMPLER_2D_RECT_EXT,
UNSIGNED_INT_SAMPLER_1D_ARRAY_EXT,
UNSIGNED_INT_SAMPLER_2D_ARRAY_EXT,
UNSIGNED_INT_SAMPLER_BUFFER_EXT.
Add the following uniform loading command prototypes on p. 81 as follows:
void Uniform{1234}uiEXT(int location, T value);
void Uniform{1234}uivEXT(int location, sizei count, T value);
(add the following paragraph to the description of the above
commands)
The Uniform*ui{v} commands will load count sets of one to four unsigned
integer values into a uniform location defined as a unsigned integer, an
unsigned integer vector, an array of unsigned integers or an array of
unsigned integer vectors.
(change the first sentence of the last paragraph as follows)
When loading values for a uniform declared as a Boolean, the Uniform*i{v},
Uniform*ui{v} and Uniform*f{v} set of commands can be used to load boolean
values.
Modify section 2.15.4 Shader execution, p. 84.
Add a new section "2.15.4.1 Shader Only Texturing" before the sub-
section "Texture Access" on p. 85
This section describes texture functionality that is only accessible
through vertex, geometry or fragment shaders. Also refer to the OpenGL
Shading Language Specification, section 8.7 and Section 3.8 of the OpenGL
2.0 specification.
Note: For unextended OpenGL 2.0 and the OpenGL Shading Language version
1.20, all supported texture internal formats store unsigned integer values
but return floating-point results in the range [0, 1] and are considered
unsigned "normalized" integers. The ARB_texture_float extension
introduces floating-point internal format where components are both stored
and returned as floating-point values, and are not clamped. The
EXT_texture_integer extension introduces formats that store either signed
or unsigned integer values.
This extension defines additional OpenGL Shading Language texture lookup
functions, see section 8.7 of the OpenGL Shading Language, that return
either signed or unsigned integer values if the internal format of the
texture is signed or unsigned, respectively.
Texel Fetches
The OpenGL Shading Language texel fetch functions provide the ability to
extract a single texel from a specified texture image. The integer
coordinates passed to the texel fetch functions are used directly as the
texel coordinates (i, j, k) into the texture image. This in turn means the
texture image is point-sampled (no filtering is performed).
The level of detail accessed is computed by adding the specified
level-of-detail parameter <lod> to the base level of the texture,
level_base.
The texel fetch functions can not perform depth comparisons or access cube
maps. Unlike filtered texel accesses, texel fetches do not support LOD
clamping or any texture wrap mode, and require a mipmapped minification
filter to access any level of detail other than the base level.
The results of the texel fetch are undefined:
* if the computed LOD is less than the texture's base level
(level_base) or greater than the maximum level (level_max),
* if the computed LOD is not the texture's base level and the texture's
minification filter is NEAREST or LINEAR,
* if the layer specified for array textures is negative or greater than
the number of layers in the array texture,
* if the texel at (i,j,k) coordinates refer to a border texel outside
the defined extents of the specified LOD, where
i < -b_s, j < -b_s, k < -b_s,
i >= w_s - b_s, j >= h_s - b_s, or k >= d_s - b_s,
where the size parameters (w_s, h_s, d_s, and b_s) refer to the
width, height, depth, and border size of the image, as in equations
3.15, 3.16, and 3.17, or
. if the texture being accessed is not complete (or cube complete for
cubemaps).
Texture Size Query
The OpenGL Shading Language texture size functions provide the ability to
query the size of a texture image. The LOD value <lod> passed in as an
argument to the texture size functions is added to the level_base of the
texture to determine a texture image level. The dimensions of that image
level, excluding a possible border, are then returned. If the computed
texture image level is outside the range [level_base, level_max], the
results are undefined. When querying the size of an array texture, both
the dimensions and the layer index are returned. Note that buffer textures
do not support mipmapping, therefore the previous lod discussion does not
apply to buffer textures
Make the section "Texture Access" a subsection of 2.15.4.1
Modify the first paragraph on p. 86 as follows:
Texture lookups involving textures with depth component data can either
return the depth data directly or return the results of a comparison with
the R value (see section 3.8.14) used to perform the lookup. The
comparison operation is requested in the shader by using any of the shadow
sampler and in the texture using the TEXTURE COMPARE MODE parameter. These
requests must be consistent; the results of a texture lookup are undefined
if:
* The sampler used in a texture lookup function is not one of the
shadow sampler types, 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 one of the shadow
sampler types, 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 one of the shadow
sampler types, and the texture object's internal format is not DEPTH
COMPONENT.
Add a new section "2.15.4.2 Shader Inputs" before "Position
Invariance" on p. 86
Besides having access to vertex attributes and uniform variables,
vertex shaders can access the read-only built-in variables
gl_VertexID and gl_InstanceID. The gl_VertexID variable holds the
integer index <i> implicitly passed to ArrayElement() to specify
the vertex. The variable gl_InstanceID holds the integer index of
the current primitive in an instanced draw call. See also section
7.1 of the OpenGL Shading Language Specification.
Add a new section "2.15.4.3 Shader Outputs"
A vertex shader can write to built-in as well as user-defined varying
variables. These values are expected to be interpolated across the
primitive it outputs, unless they are specified to be flat shaded. Refer
to section 2.15.3 and the OpenGL Shading Language specification sections
4.3.6, 7.1 and 7.6 for more detail.
The built-in output variables gl_FrontColor, gl_BackColor,
gl_FrontSecondaryColor, and gl_BackSecondaryColor hold the front and back
colors for the primary and secondary colors for the current vertex.
The built-in output variable gl_TexCoord[] is an array and holds the set
of texture coordinates for the current vertex.
The built-in output variable gl_FogFragCoord is used as the "c" value, as
described in section 3.10 "Fog" of the OpenGL 2.0 specification.
The built-in special variable gl_Position is intended to hold the
homogeneous vertex position. Writing gl_Position is optional.
The built-in special variable gl_ClipVertex holds the vertex coordinate
used in the clipping stage, as described in section 2.12 "Clipping" of the
OpenGL 2.0 specification.
The built in special variable gl_PointSize, if written, holds the size of
the point to be rasterized, measured in pixels.
Number section "Position Invariance", "Validation" and "Undefined
Behavior" as sections 2.15.4.4, 2.15.4.5, and 2.15.4.6 respectively.
| Additions to Chapter 3 of the OpenGL 2.0 Specification (Rasterization) |
Modify Section 3.8.1, Texture Image Specification, p. 150
(modify 4th paragraph, p. 151 -- add cubemaps to the list of texture
targets that can be used with DEPTH_COMPONENT textures)
Textures with a base internal format of DEPTH_COMPONENT are supported by
texture image specification commands only if <target> is TEXTURE_1D,
TEXTURE_2D, TEXTURE_CUBE_MAP, TEXTURE_RECTANGLE_ARB, PROXY_TEXTURE_1D,
PROXY_TEXTURE_2D, PROXY_TEXTURE_CUBE_MAP, or
PROXY_TEXTURE_RECTANGLE_ARB. Using this format in conjunction with any
other target will result in an INVALID_OPERATION error.
Modify Section 3.8.8, Texture Minification:
(replace the last paragraph, p. 171): Let s(x,y) be the function that
associates an s texture coordinate with each set of window coordinates
(x,y) that lie within a primitive; define t(x,y) and r(x,y) analogously.
Let
u(x,y) = w_t * s(x,y)
v(x,y) = h_t * t(x,y) (3.20a)
w(x,y) = d_t * r(x,y)
where w_t, h_t, and d_t are as defined by equations 3.15, 3.16, and 3.17
with w_s, h_s, and d_s equal to the width, height, and depth of the image
array whose level is level_base. For a one-dimensional texture, define
v(x,y) == 0 and w(x,y) == 0; for two-dimensional textures, define w(x,y)
== 0.
(start a new paragraph with "For a polygon, rho is given at a fragment
with window coordinates...", and then continue with the original spec
text.)
(replace text starting with the last paragraph on p. 172,
continuing to the end of p. 174)
The (u,v,w) coordinates are then modified, as follows:
u'(x,y) = u(x,y) + offsetu_shader,
v'(x,y) = v(x,y) + offsetv_shader,
w'(x,y) = w(x,y) + offsetw_shader
where (offsetu_shader, offsetv_shader, offsetw_shader) is the texel offset
specified in the OpenGL Shading Language texture lookup functions that
support offsets. If the texture function used does not support offsets, or
for fixed-function texture accesses, all three shader offsets are taken to
be zero.
The (u',v',w') coordinates are then further modified according the texture
wrap modes, as specified in Table X.19, to generate a new set of
coordinates (u'',v'',w'').
TEXTURE_WRAP_S Coordinate Transformation
-------------------------- ---------------------------------------
CLAMP u'' = clamp(u', 0, w_t-0.5),
if NEAREST filtering,
clamp(u', 0, w_t),
otherwise
CLAMP_TO_EDGE u'' = clamp(u', 0.5, w_t-0.5)
CLAMP_TO_BORDER u'' = clamp(u', -0.5, w_t+0.5)
REPEAT u'' = clamp(fmod(u', w_t), 0.5, w_t-0.5)
MIRROR_CLAMP_EXT u'' = clamp(fabs(u'), 0.5, w_t-0.5),
if NEAREST filtering, or
= clamp(fabs(u'), 0.5, w_t),
otherwise
MIRROR_CLAMP_TO_EDGE_EXT u'' = clamp(fabs(u'), 0.5, w_t-0.5)
MIRROR_CLAMP_TO_BORDER_EXT u'' = clamp(fabs(u'), 0.5, w_t+0.5)
MIRRORED_REPEAT u'' = w_t -
clamp(fabs(w_t - fmod(u', 2*w_t)),
0.5, w_t-0.5)
Table X.19: Texel coordinate wrap mode application. clamp(a,b,c)
returns b if a<b, c if a>c, and a otherwise. fmod(a,b) returns a-
b*floor(a/b), and fabs(a) returns the absolute value of a. For the v
and w coordinates, TEXTURE_WRAP_T and h_t, and TEXTURE_WRAP_R and d_t,
respectively, are used.
When lambda indicates minification, the value assigned to
TEXTURE_MIN_FILTER is used to determine how the texture value for a
fragment is selected.
When TEXTURE_MIN_FILTER is NEAREST the texel in the image array of level
level_base that is nearest (in Manhattan distance) to (u'',v'',w'') is
obtained. The coordinate (i,j,k) is then computed as (floor(u''),
floor(v''), floor(w'')).
For a three-dimensional texture, the texel at location (i,j,k) becomes the
texture value. For a two-dimensional texture, k is irrelevant, and the
texel at location (i,j) becomes the texture value. For a one-dimensional
texture, j and k are irrelevant, and the texel at location i becomes the
texture value.
If the selected (i,j,k), (i,j), or i location refers to a border texel
that satisfies any of the following conditions:
i < -b_s,
j < -b_s,
k < -b_s,
i >= w_l + b_s,
j >= h_l + b_s, or
j >= d_l + b_s,
then the border values defined by TEXTURE_BORDER_COLOR are used in place
of the non-existent texel. If the texture contains color components, the
values of TEXTURE_BORDER_COLOR are interpreted as an RGBA color to match
the texture's internal format in a manner consistent with table 3.15. If
the texture contains depth components, the first component of
TEXTURE_BORDER_COLOR is interpreted as a depth value.
When TEXTURE_MIN_FILTER is LINEAR, a 2x2x2 cube of texels in the image
array of level level_base is selected. Let:
i_0 = floor(u'' - 0.5),
j_0 = floor(v'' - 0.5),
k_0 = floor(w'' - 0.5),
i_1 = i_0 + 1,
j_1 = j_0 + 1,
k_1 = k_0 + 1,
alpha = frac(u'' - 0.5),
beta = frac(v'' - 0.5), and
gamma = frac(w'' - 0.5),
where frac(<x>) denotes the fractional part of <x>.
For a three-dimensional texture, the texture value tau is found as...
(replace last paragraph, p.174) For any texel in the equation above that
refers to a border texel outside the defined range of the image, the texel
value is taken from the texture border color as with NEAREST filtering.
Rename section 3.8.9 "Texture Magnification" to section 3.8.8
modify the first paragraph of section 3.8.8 "Texture
Magnification" as follows:
When lambda indicates magnification, the value assigned to
TEXTURE_MAG_FILTER determines how the texture value is obtained. There are
two possible values for TEXTURE_MAG_FILTER: NEAREST and LINEAR. NEAREST
behaves exactly as NEAREST for TEXTURE_MIN_FILTER and LINEAR behaves
exactly as LINEAR for TEXTURE_MIN_FILTER, as described in the previous
section, including the wrapping calculations. The level-of-detail
level_base texture array is always used for magnification.
modify the last paragraph of section 3.8.8, p. 175, as follows:
The rules for NEAREST or LINEAR filtering are then applied to the selected
array. Specifically, the coordinate (u,v,w) is computed as in equation
3.20a, with w_s, h_s, and d_s equal to the width, height, and depth of the
image array whose level is 'd'.
Modify the second paragraph on p. 176
The rules for NEAREST or LINEAR filtering are then applied to each of the
selected arrays, yielding two corresponding texture valutes Tau1 and
Tau2. Specifically, for level d1, the coordinate (u,v,w) is computed as in
equation 3.20a, with w_s, h_s, and d_s equal to the width, height, and
depth of the image array whose level is 'd1'. For level d2 the coordinate
(u', v', w') is computed as in equation 3.20a, with w_s, h_s, and d_s
equal to the width, height, and depth of the image array whose level is
'd2'.
Modify Section 3.8.14, Texture Comparison Modes (p. 185)
(modify 2nd paragraph, p. 188, indicating that the Q texture coordinate is
used for depth comparisons on cubemap textures)
Let D_t be the depth texture value, in the range [0, 1]. For
fixed-function texture lookups, let R be the interpolated <r> texture
coordinate, clamped to the range [0, 1]. For texture lookups generated by
an OpenGL Shading Language lookup function, let R be the reference value
for depth comparisons provided in the lookup function, also clamped to [0,
1]. Then the effective texture value L_t, I_t, or A_t is computed as
follows:
Modify section 3.11, Fragment Shaders, p. 193
Modify the third paragraph on p. 194 as follows:
Additionally, when a vertex shader is active, it may define one or more
varying variables (see section 2.15.3 and the OpenGL Shading Language
Specification). These values are, if not flat shaded, interpolated across
the primitive being rendered. The results of these interpolations are
available when varying variables of the same name are defined in the
fragment shader.
Add the following paragraph to the end of section 3.11.1, p. 194
A fragment shader can also write to varying out variables. Values written
to these variables are used in the subsequent per-fragment operations.
Varying out variables can be used to write floating-point, integer or
unsigned integer values destined for buffers attached to a framebuffer
object, or destined for color buffers attached to the default
framebuffer. The subsection 'Shader Outputs' of the next section describes
API how to direct these values to buffers.
Add a new paragraph at the beginning of the section "Texture
Access", p. 194
Section 2.15.4.1 describes texture lookup functionality accessible to a
vertex shader. The texel fetch and texture size query functionality
described there also applies to fragment shaders.
Modify the second paragraph on p. 195 as follows:
Texture lookups involving textures with depth component data can either
return the depth data directly or return the results of a comparison with
the R value (see section 3.8.14) used to perform the lookup. The
comparison operation is requested in the shader by using any of the shadow
sampler and in the texture using the TEXTURE COMPARE MODE parameter. These
requests must be consistent; the results of a texture lookup are undefined
if:
* The sampler used in a texture lookup function is not one of the
shadow sampler types, 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 one of the shadow
sampler types, 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 one of the shadow
sampler types, and the texture object's internal format is not DEPTH
COMPONENT.
Add the following paragraph to the section Shader Inputs, p. 196
If a geometry shader is active, the built-in variable gl_PrimitiveID
contains the ID value emitted by the geometry shader for the provoking
vertex. If no geometry shader is active, gl_PrimitiveID is filled with the
number of primitives processed by the rasterizer since the last time Begin
was called (directly or indirectly via vertex array functions). The first
primitive generated after a Begin is numbered zero, and the primitive ID
counter is incremented after every individual point, line, or polygon
primitive is processed. For polygons drawn in point or line mode, the
primitive ID counter is incremented only once, even though multiple points
or lines may be drawn. For QUADS and QUAD_STRIP primitives that are
decomposed into triangles, the primitive ID is incremented after each
complete quad is processed. For POLYGON primitives, the primitive ID
counter is undefined. The primitive ID is undefined for fragments
generated by DrawPixels or Bitmap. Restarting a primitive topology using
the primitive restart index has no effect on the primitive ID counter.
Modify the first paragraph of the section Shader Outputs, p. 196 as
follows
The OpenGL Shading Language specification describes the values that may be
output by a fragment shader. These outputs are split into two
categories. User-defined varying out variables and built-in variables. The
built-in variables are gl_FragColor, gl_FragData[n], and gl_FragDepth. If
fragment clamping is enabled, the final fragment color values or the final
fragment data values or the final varying out variable values written by a
fragment shader are clamped to the range [0,1] and then may be converted
to fixed-point as described in section 2.14.9. Only user-defined varying
out variables declared as a floating-point type are clamped and may be
converted. If fragment clamping is disabled, the final fragment color
values or the final fragment data values or the final varying output
variable values are not modified. The final fragment depth written...
Modify the second paragraph of the section Shader Outputs, p. 196
as follows
...A fragment shader may not statically assign values to more than one of
gl_FragColor, gl_FragData or any user-defined varying output variable. In
this case, a compile or link error will result. A shader statically...
Add the following to the end of the section Shader Outputs, p. 197
The values of user-defined varying out variables are directed to a color
buffer in a two step process. First the varying out variable is bound to a
fragment color by using its number. The GL will assign a number to each
varying out variable, unless overridden by the command
BindFragDataLocationEXT(). The number of the fragment color assigned for
each user-defined varying out variable can be queried with
GetFragDataLocationEXT(). Next, the DrawBuffer or DrawBuffers commands (see
section 4.2.1) direct each fragment color to a particular buffer.
The binding of a user-defined varying out variable to a fragment color
number can be specified explicitly. The command
void BindFragDataLocationEXT(uint program, uint colorNumber,
const char *name);
specifies that the varying out variable name in program should be bound to
fragment color colorNumber when the program is next linked. If name was
bound previously, its assigned binding is replaced with colorNumber. name
must be a null terminated string. The error INVALID_VALUE is generated if
colorNumber is equal or greater than MAX_DRAW_BUFFERS.
BindFragDataLocationEXT has no effect until the program is linked. In
particular, it doesn't modify the bindings of varying out variables in a
program that has already been linked. The error INVALID OPERATION is
generated if name starts with the reserved "gl_" prefix.
When a program is linked, any varying out variables without a binding
specified through BindFragDataLocationEXT will automatically be bound to
fragment colors by the GL. Such bindings can be queried using the command
GetFragDataLocationEXT. LinkProgram will fail if the assigned binding of a
varying out variable would cause the GL to reference a non-existant
fragment color number (one greater than or equal to MAX DRAW_BUFFERS).
LinkProgram will also fail if more than one varying out variable is bound
to the same number. This type of aliasing is not allowed.
BindFragDataLocationEXT may be issued before any shader objects are
attached to a program object. Hence it is allowed to bind any name (except
a name starting with "gl_") to a color number, including a name that is
never used as a varying out variable in any fragment shader
object. Assigned bindings for variables that do not exist are ignored.
After a program object has been linked successfully, the bindings of
varying out variable names to color numbers can be queried. The command
int GetFragDataLocationEXT(uint program, const char *name);
returns the number of the fragment color that the varying out variable
name was bound to when the program object program was last linked. name
must be a null terminated string. If program has not been successfully
linked, the error INVALID OPERATION is generated. If name is not a varying
out variable, or if an error occurs, -1 will be returned.
| Additions to Chapter 4 of the OpenGL 2.0 Specification (Per-Fragment Operations and the Frame Buffer) |
Modify Section 4.2.1, Selecting a Buffer for Writing (p. 212)
(modify next-to-last paragraph, p. 213) If a fragment shader writes to
gl_FragColor, DrawBuffers specifies a set of draw buffers into which the
single fragment color defined by gl_FragColor is written. If a fragment
shader writes to gl_FragData or a user-defined varying out variable,
DrawBuffers specifies a set of draw buffers into which each of the
multiple output colors defined by these variables are separately written.
If a fragment shader writes to neither gl_FragColor, nor gl FragData, nor
any user-defined varying out variables, the values of the fragment colors
following shader execution are undefined, and may differ for each fragment
color.
| Additions to Chapter 5 of the OpenGL 2.0 Specification (Special Functions) |
Change section 5.4 Display Lists, p. 237
Add the commands VertexAttribIPointerEXT and BindFragDataLocationEXT to
the list of commands that are not compiled into a display list, but
executed immediately, under "Program and Shader Objects", p. 241
| Additions to Chapter 6 of the OpenGL 2.0 Specification (State and State Requests) |
Modify section 6.1.14 "Shader and Program Queries", p. 256
Modify 2nd paragraph, p.259:
Add the following to the list of GetVertexAttrib* commands:
void GetVertexAttribIivEXT(uint index, enum pname, int *params);
void GetVertexAttribIuivEXT(uint index, enum pname, uint *params);
obtain the... <pname> must be one of VERTEX_ATTRIB_ARRAY_ENABLED ,.,
VERTEX_ATTRIB_ARRAY_NORMALIZED, VERTEX_ATTRIB_ARRAY_INTEGER_EXT, or
CURRENT_VERTEX_ATTRIB. ...
Split 3rd paragraph, p.259
... The size, stride, type, normalized flag, and unconverted integer flag
are set by the commands VertexAttribPointer and VertexAttribIPointerEXT.
The normalized flag is always set to FALSE by by VertexAttribIPointerEXT.
The unconverted integer flag is always set to FALSE by VertexAttribPointer
and TRUE by VertexAttribIPointerEXT.
The query CURRENT_VERTEX_ATTRIB returns the current value for the generic
attribute <index>. GetVertexAttribdv and GetVertexAttribfv read and
return the current attribute values as floating-point values;
GetVertexAttribiv reads them as floating-point values and converts them
to integer values; GetVertexAttribIivEXT reads and returns them as
integers; GetVertexAttribIuivEXT reads and returns them as unsigned
integers. The results of the query are undefined if the current attribute
values are read using one data type but were specified using a different
one. The error INVALID_OPERATION is generated if <index> is zero.
Change the prototypes in the first paragraph on page 260 as
follows:
void GetUniformfv(uint program, int location, float *params);
void GetUniformiv(uint program, int location, int *params);
void GetUniformuivEXT(uint program, int location, uint *params);
| Additions to Appendix A of the OpenGL 2.0 Specification (Invariance) |
None.
| Additions to the AGL/GLX/WGL Specifications |
None.
| Interactions with GL_ARB_color_buffer_float |
If the GL_ARB_color_buffer_float extension is not supported then any
reference to fragment clamping in section 3.11.2 "Shader Execution" needs
to be deleted.
| Interactions with GL_ARB_texture_rectangle |
If the GL_ARB_texture_rectangle extension is not supported then all
references to texture lookup functions with 'Rect' in the name need to be
deleted.
| Interactions with GL_EXT_texture_array |
If the GL_EXT_texture_array extension is not supported, all references to
one- and two-dimensional array texture sampler types (e.g.,
sampler1DArray, sampler2DArray) and the texture lookup functions that use
them need to be deleted.
| Interactions with GL_EXT_geometry_shader4 |
If the GL_EXT_geometry_shader4 extension is not supported, all references
to a geometry shader need to be deleted.
| Interactions with GL_NV_primitive_restart |
The spec describes the behavior that primitive restart does not affect the
primitive ID counter, including for POLYGON primitives (where one could
argue that the restart index starts a new primitive without a new Begin to
reset the count). If NV_primitive_restart is not supported, references to
that extension in the discussion of the primitive ID counter should be
removed.
If NV_primitive_restart is supported, index values causing a primitive
restart are not considered as specifying an End command, followed by
another Begin. Primitive restart is therefore not guaranteed to
immediately update material properties when a vertex shader is active. The
spec language on p.64 of the OpenGL 2.0 specification says "changes are
not guaranteed to update material parameters, defined in table 2.11, until
the following End command."
| Interactions with EXT_texture_integer |
If the EXT_texture_integer spec is not supported, the discussion about
this spec in section 2.15.4.1 needs to be removed. All texture lookup
functions that return integers or unsigned integers, as discussed in
section 8.7 of the OpenGL Shading Language specification, also need to be
removed.
| Interactions with EXT_texture_buffer_object |
If EXT_texture_buffer_object is not supported, references to buffer
textures, as well as the texelFetchBuffer and texelSizeBuffer lookup
functions and samplerBuffer types, need to be removed.
| Interactions with EXT_draw_instanced |
If EXT_draw_instanced is not supported, the value of gl_InstanceID
is always zero.
The error INVALID_VALUE is generated by BindFragDataLocationEXT() if
colorNumber is equal or greater than MAX_DRAW_BUFFERS.
The error INVALID OPERATION is generated by BindFragDataLocationEXT() if
name starts with the reserved "gl_" prefix.
The error INVALID_OPERATOIN is generated by BindFragDataLocationEXT() or
GetFragDataLocationEXT if program is not the name of a program object.
The error INVALID_OPERATION is generated by GetFragDataLocationEXT() if
program has not been successfully linked.
(add to table 6.7, p. 268)
Initial
Get Value Type Get Command Value Description Sec. Attribute
--------- ---- --------------- ------- -------------------- ---- ---------
VERTEX_ATTRIB_ARRAY 16+xB GetVertexAttrib FALSE vertex attrib array 2.8 vertex-array
INTEGER_EXT has unconverted ints
| New Implementation Dependent State |
Minimum
Get Value Type Get Command Value Description Sec. Attrib
-------------------------------- ---- --------------- ------- --------------------- ------ ------
MIN_PROGRAM_TEXEL_OFFSET_EXT Z GetIntegerv -8 minimum texel offset 2.x.4.4 -
allowed in lookup
MAX_PROGRAM_TEXEL_OFFSET_EXT Z GetIntegerv +7 maximum texel offset 2.x.4.4 -
allowed in lookup
| Modifications to The OpenGL Shading Language Specification, Version 1.10.59 |
Including the following line in a shader can be used to control the
language features described in this extension:
#extension GL_EXT_gpu_shader4 : <behavior>
where <behavior> is as specified in section 3.3.
A new preprocessor #define is added to the OpenGL Shading Language:
#define GL_EXT_gpu_shader4 1
Add to section 3.6 "Keywords"
Add the following keywords:
noperspective, flat, centroid
Remove the unsigned keyword from the list of keywords reserved for future
use, and add it to the list of keywords.
The following new vector types are added:
uvec2, uvec3, uvec4
The following new sampler types are added:
sampler1DArray, sampler2DArray, sampler1DArrayShadow,
sampler2DArrayShadow, samplerCubeShadow
isampler1D, isampler2D, isampler3D, isamplerCube, isampler2DRect,
isampler1DArray, isampler2DArray
usampler1D, usampler2D, usampler3D, usamplerCube, usampler2DRect,
usampler1DArray, usampler2DArray
samplerBuffer, isamplerBuffer, usamplerBuffer
Add to section 4.1 "Basic Types"
Break the table in this section up in several tables. The first table
4.1.1 is named "scalar, vector and matrix data types". It includes the
first row through the 'mat4" row.
Add the following to the first section of this table:
unsigned int An unsigned integer
uvec2 A two-component unsigned integer vector
uvec3 A three-component unsigned integer vector
uvec4 A four-component unsigned integer vector
Break out the sampler types in a separate table, and name that table 4.1.2
"default sampler types". Add the following sampler types to this new
table:
sampler1DArray handle for accessing a 1D array texture
sampler2DArray handle for accessing a 2D array texture
sampler1DArrayShadow handle for accessing a 1D array depth texture
with comparison
sampler2DArrayShadow handle for accessing a 2D array depth texture
with comparison
samplerBuffer handle for accessing a buffer texture
Add a table 4.1.3 called "integer sampler types":
isampler1D handle for accessing an integer 1D texture
isampler2D handle for accessing an integer 2D texture
isampler3D handle for accessing an integer 3D texture
isamplerCube handle for accessing an integer cube map texture
isampler2DRect handle for accessing an integer rectangle texture
isampler1DArray handle for accessing an integer 1D array texture
isampler2DArray handle for accessing an integer 2D array texture
isamplerBuffer handle for accessing an integer buffer texture
Add a table 4.1.4 called "unsigned integer sampler types":
usampler1D handle for accessing an unsigned integer
1D texture
usampler2D handle for accessing an unsigned integer
2D texture
usampler3D handle for accessing an unsigned integer
3D texture
usamplerCube handle for accessing an unsigned integer
cube map texture
usampler2DRect handle for accessing an unsigned integer
rectangle texture
usampler1DArray handle for accessing an unsigned integer 1D
array texture
usampler2DArray handle for accessing an unsigned integer 2D
array texture
usamplerBuffer handle for accessing an unsigned integer
buffer texture
Change section 4.1.3 "Integers"
Remove the first two paragraphs and replace with the following:
Signed, as well as unsigned integers, are fully supported. Integers hold
whole numbers. Integers have at least 32 bits of precision, including a
sign bit. Signed integers are stored using a two's complement
representation.
Integers are declared and optionally initialized with integer expressions
as in the following example:
int i, j = 42;
unsigned int k = 3u;
Literal integer constants can be expressed in decimal (base 10), octal
(base 8), or hexadecimal (base 16) as follows.
integer-constant:
decimal-constant integer-suffix_opt
octal-constant integer-suffix_opt
hexadecimal-constant integer-suffix_opt
integer-suffix: one of
u U
Change section 4.3 "Type Qualifiers"
Change the "varying" and "out" qualifier as follows:
varying - linkage between a vertex shader and fragment shader, or between
a fragment shader and the back end of the OpenGL pipeline.
out - for function parameters passed back out of a function, but not
initialized for use when passed in. Also for output varying variables
(fragment only).
In the qualifier table, add the following sub-qualifiers under the varying
qualifier:
flat varying
noperspective varying
centroid varying
Change section 4.3.4 "Attribute"
Change the sentence:
The attribute qualifier can be used only with the data types float, vec2,
vec3, vec4, mat2, mat3, and mat4.
To:
The attribute qualifier can be used only with the data types int, ivec2,
ivec3, ivec4, unsigned int, uvec2, uvec3, uvec4, float, vec2, vec3, vec4,
mat2, mat3, and mat4.
Change the fourth paragraph to:
It is expected that graphics hardware will have a small number of fixed
locations for passing vertex attributes. Therefore, the OpenGL Shading
language defines each non-matrix attribute variable as having space for up
to four integer or floating-point values (i.e., a vec4, ivec4 or
uvec4). There is an implementation dependent limit on the number of
attribute variables that can be used and if this is exceeded it will cause
a link error. (Declared attribute variables that are not used do not count
against this limit.) A scalar attribute counts the same amount against
this limit as a vector of size four, so applications may want to consider
packing groups of four unrelated scalar attributes together into a vector
to better utilize the capabilities of the underlying hardware. A mat4
attribute will...
Change section 4.3.6 "Varying"
Change the first paragraph to:
Varying variables provide the interface between the vertex shader, the
fragment shader, and the fixed functionality between the vertex and
fragment shader, as well as the interface from the fragment shader to the
back-end of the OpenGL pipeline.
The vertex shader will compute values per vertex (such as color, texture
coordinates, etc.) and write them to variables declared with the varying
qualifier. A vertex shader may also read varying variables, getting back
the same values it has written. Reading a varying variable in a vertex
shader returns undefined values if it is read before being written.
The fragment shader will compute values per fragment and write them to
variables declared with the varying out qualifier. A fragment shader may
also read varying variables, getting back the same result it has
written. Reading a varying variable in a fragment shader returns undefined
values if it is read before being written.
Varying variables may be written more than once. If so, the last value
assigned is the one used.
Change the second paragraph to:
Varying variables that are set per vertex are interpolated by default in a
perspective-correct manner over the primitive being rendered, unless the
varying is further qualified with noperspective. Interpolation in a
perspective correct manner is specified in equations 3.6 and 3.8 in the
OpenGL 2.0 specification. When noperspective is specified, interpolation
must be linear in screen space, as described in equation 3.7 and the
approximation that follows equation 3.8.
If single-sampling, the value is interpolated to the pixel's center, and
the centroid qualifier, if present, is ignored. If multi-sampling, and the
varying is not qualified with centroid, then the value must be
interpolated to the pixel's center, or anywhere within the pixel, or to
one of the pixel's samples. If multi-sampling and the varying is qualified
with centroid, then the value must be interpolated to a point that lies in
both the pixel and in the primitive being rendered, or to one of the
pixel's samples that falls within the primitive.
[NOTE: Language for centroid sampling taken from the GLSL 1.20.4
specification]
Varying variables, set per vertex, can be computed on a per-primitive
basis (flat shading), or interpolated over a line or polygon primitive
(smooth shading). By default, a varying variable is smooth shaded, unless
the varying is further qualified with flat. When smooth shading, the
varying is interpolated over the primitive. When flat shading, the varying
is constant over the primitive, and is taken from the single provoking
vertex of the primitive, as described in Section 2.14.7 of the OpenGL 2.0
specification.
Change the fourth paragraph to:
The type and any qualifications (flat, noperspective, centroid) of varying
variables with the same name declared in both the vertex and fragment
shaders must match, otherwise the link command will fail. Note that
built-in varying variables, which have names starting with "gl_", can not
be further qualified with flat, noperspective or centroid. The flat
keyword cannot be used together with either the noperspective or centroid
keywords to further qualify a single varying variable, otherwise a compile
error will occur. When using the keywords centroid, flat or noperspective,
it must immediately precede the varying keyword. When using both centroid
and noperspective keywords, either one can be specified first. Only those
varying variables used (i.e. read) in the fragment shader must be written
to by the vertex shader; declaring superfluous varying variables in the
vertex shader is permissible. Varying out variables, set per fragment, can
not be further qualified with flat, noperspective or centroid.
Fragment shaders output values to the back-end of the OpenGL pipeline
using either user-defined varying out variables or built-in variables, as
described in section 7.2, unless the discard keyword is executed. If the
back-end of the OpenGL pipeline consumes a user-defined varying out
variable and an execution of a fragment shader does not write a value to
that variable, then the value consumed is undefined. If the back-end of
the OpenGL pipeline consumes a varying out variable and a fragment shader
either writes values into less components of the variable, or if the
variable is declared to have less components, than needed, the values of
the missing component(s) are undefined. The OpenGL specification, section
3.x.x, describes API to route varying output variables to color buffers.
Add the following examples:
noperspective varying float temperature;
flat varying vec3 myColor;
centroid varying vec2 myTexCoord;
centroid noperspective varying vec2 myTexCoord;
varying out ivec3 foo;
Change the third paragraph on p. 25 as follows:
The "varying" qualifier can be used only with the data types float, vec2,
vec3, vec4, mat2, mat3, and mat4, int, ivec2, ivec3, ivec4, unsigned int,
uvec2, uvec3, uvec4 or arrays of these. Structures cannot be varying. If
the varying is declared as one of the integer or unsigned integer data
type variants, then it has to also be qualified as being flat shaded,
otherwise a compile error will occur.
The "varying out" qualifier can be used only with the data types float,
vec2, vec3, vec4, int, ivec2, ivec3, ivec4, unsigned int, uvec2, uvec3 or
uvec4. Structures or arrays cannot be declared as varying out.
Change section 5.1 "Operators"
Remove the "reserved" qualifications from the following operator
precedence table entries:
Precedence Operator class
---------- -----------------------------------
3 (tilde is reserved)
4 (modulus reserved)
6 bit-wise shift (reserved)
9 bit-wise and (reserved)
10 bit-wise exclusive or (reserved)
11 bit-wise inclusive or (reserved)
16 (modulus, shift, and bit-wise are reserved)
Change section 5.8 "Assignments"
Change the first bullet from:
* The arithmetic assignments add into (+=)..
To:
* The arithmetic assignments add into (+=), subtract from (-
=), multiply into (*=), and divide into (/=) as well as the
assignments modulus into (%=), left shift by (<<=), right
shift by (>>=), and into (&=), inclusive or into (|=),
exclusive or into (^=). The expression
Delete the last bullet in this paragraph.
Remove the second bullet in the section starting with: The assignments
modulus into..
Change section 5.9 "Expressions"
Change the bullet: The operator modulus (%) is reserved for future
use to:
* The arithmetic operator % that operates on signed or unsigned integer
typed expressions (including vectors). The two operands must be of the
same type, or one can be a signed or unsigned integer scalar and the
other a signed or unsigned integer vector. If the second operand is
zero, results are undefined. If one operand is scalar and the other is a
vector, the scalar is applied component-wise to the vector, resulting in
the same type as the vector. If both operands are non-negative, then the
remainder is non-negative. Results are undefined if one, or both,
operands are negative.
Change the last bullet: "Operators and (&), or (|), exclusive or (^), not
(~), right-shift (>>), left shift (<<). These operators are reserved for
future use." To the following bullets:
* The one's complement operator ~. The operand must be of type signed or
unsigned integer (including vectors), and the result is the one's
complement of its operand. If the operand is a vector, the operator is
applied component-wise to the vector. If the operand is unsigned, the
result is computed by subtracting the value from the largest unsigned
integer value. If the operand is signed, the result is computed by
converting the operand to an unsigned integer, applying ~, and
converting back to a signed integer.
* The shift operators << and >>. For both operators, the operands must be
of type signed or unsigned integer (including vectors). If the first
operand is a scalar, the second operand has to be a scalar as well. The
result is undefined if the right operand is negative, or greater than or
equal to the number of bits in the left expression's type. The value of
E1 << E2 is E1 (interpreted as a bit pattern) left-shifted by E2
bits. The value of E1 >> E2 is E1 right-shifted by E2 bit positions. If
E1 is a signed integer, the right-shift will extend the sign bit. If E1
is an unsigned integer, the right-shift will zero-extend.
* The bitwise AND operator &. The operands must be of type signed or
unsigned integer (including vectors). The two operands must be of the
same type, or one can be a signed or unsigned integer scalar and the
other a signed or unsigned integer vector. If one operand is a scalar
and the other a vector, the scalar is applied component-wise to the
vector, resulting in the same type as the vector. The result is the
bitwise AND function of the operands.
* The bitwise exclusive OR operator ^. The operands must be of type signed
or unsigned integer (including vectors). The two operands must be of the
same type, or one can be a signed or unsigned integer scalar and the
other a signed or unsigned integer vector. If one operand is a scalar
and the other a vector, the scalar is applied component-wise to the
vector, resulting in the same type as the vector. The result is the
bitwise exclusive OR function of the operands.
* The bitwise inclusive OR operator |. The operands must be of type signed
or unsigned integer (including vectors). The two operands must be of the
same type, or one can be a signed or unsigned integer scalar and the
other a signed or unsigned integer vector. If one operand is a scalar
and the other a vector, the scalar is applied component-wise to the
vector, resulting in the same type as the vector. The result is the
bitwise inclusive OR function of the operands.
Change Section 7.1 "Vertex Shader Special Variables"
Add the following definition to the list of built-in variable definitions:
int gl_VertexID // read-only
int gl_InstanceID // read-only
Add the following paragraph at the end of the section:
The variable gl_VertexID is available as a read-only variable from within
vertex shaders and holds the integer index <i> implicitly passed to
ArrayElement() to specify the vertex. The value of gl_VertexID is defined
if and only if:
* the vertex comes from a vertex array command that specifies a complete
primitive (e.g. DrawArrays, DrawElements),
* all enabled vertex arrays have non-zero buffer object bindings, and
* the vertex does not come from a display list, even if the display list
was compiled using DrawArrays / DrawElements with data sourced from
buffer objects.
The variable gl_InstanceID is availale as a read-only variable from within
vertex shaders and holds holds the integer index of the current primitive
in an instanced draw call (DrawArraysInstancedEXT,
DrawElementsInstancedEXT). If the current primitive does not come from an
instanced draw call, the value of gl_InstanceID is zero.
Change Section 7.2 "Fragment Shader Special Variables"
Change the 8th and 9th paragraphs on p. 43 as follows:
If a shader statically assigns a value to gl_FragColor, it may not assign
a value to any element of gl_FragData nor to any user-defined varying
output variable (section 4.3.6). If a shader statically writes a value to
any element of gl_FragData, it may not assign a value to gl_FragColor nor
to any user-defined varying output variable. That is, a shader may assign
values to either gl_FragColor, gl_FragData, or any user-defined varying
output variable, but not to a combination of the three options.
If a shader executes the discard keyword, the fragment is discarded, and
the values of gl_FragDepth, gl_FragColor, gl_FragData and any user-defined
varying output variables become irrelevant.
Add the following paragraph to the top of p. 44:
The variable gl_PrimitiveID is available as a read-only variable from
within fragment shaders and holds the id of the currently processed
primitive. Section 3.11, subsection "Shader Inputs" of the OpenGL 2.0
specification describes what value it holds based on the primitive type.
Add the following prototype to the list of built-in variables accessible
from a fragment shader:
int gl_PrimitiveID;
Change Chapter 8, sixth paragraph on page 50:
Change the sentence:
When the built-in functions are specified below, where the input arguments
(and corresponding output)can be float, vec2, vec3, or vec4, genType is
used as the argument.
To:
When the built-in functions are specified below, where the input arguments
(and corresponding output) can be float, vec2, vec3, or vec4, genType is
used as the argument. Where the input arguments (and corresponding output)
can be int, ivec2, ivec3 or ivec4, genIType is used as the argument. Where
the input arguments (and corresponding output) can be unsigned int, uvec2,
uvec3, or uvec4, genUType is used as the argument.
Add to section 8.3 "Common functions"
Add integer versions of the abs, sign, min, max and clamp functions, as
follows:
Syntax:
genIType abs(genIType x)
genIType sign(genIType x)
genIType min(genIType x, genIType y)
genIType min(genIType x, int y)
genUType min(genUType x, genUType y)
genUType min(genUType x, unsigned int y)
genIType max(genIType x, genIType y)
genIType max(genIType x, int y)
genUType max(genUType x, genUType y)
genUType max(genUType x, unsigned int y)
genIType clamp(genIType x, genIType minval, genIType maxval)
genIType clamp(genIType x, int minval, int maxval)
genUType clamp(genUType x, genUType minval, genUType maxval)
genUType clamp(genUType x, unsigned int minval,
unsigned int maxval)
Add the following new functions:
Syntax:
genType truncate(genType x)
Description:
Returns a value equal to the integer closest to x whose absolute value
is not larger than the absolute value of x.
Syntax:
genType round(genType x)
Description:
Returns a value equal to the closest integer to x. If the fractional
portion of the operand is 0.5, the nearest even integer is returned. For
example, round (1.0) returns 1.0. round(-1.5) returns -2.0. round(3.5)
and round (4.5) both return 4.0.
Add to section 8.6 "Vector Relational Functions"
Change the sentence:
Below, "bvec" is a placeholder for one of bvec2, bvec3, or bvec4, "ivec"
is a placeholder for one of ivec2, ivec3, or ivec4, and "vec" is a
placeholder for vec2, vec3, or vec4.
To:
Below, "bvec" is a placeholder for one of bvec2, bvec3, or bvec4, "ivec"
is a placeholder for one of ivec2, ivec3, or ivec4, "uvec" is a
placeholder for one of uvec2, uvec3 or uvec4 and "vec" is a placeholder
for vec2, vec3, or vec4.
Add uvec versions of all but the any, all and not functions to the table
in this section, as follows:
bvec lessThan(uvec x, uvec y)
bvec lessThanEqual(uvec x, uvec y)
bvec greaterThan(uvec x, uvec y)
bvec greaterThanEqual(uvec x, uvec y)
bvec equal(uvec x, uvec y)
bvec notEqual(uvec x, uvec y)
Add to section 8.7 "Texture Lookup Functions"
Remove the first sentence in the last paragraph:
"The built-ins suffixed with "Lod" are allowed only in a vertex shader.".
Add to this section:
Texture data can be stored by the GL as floating point, unsigned
normalized integer, unsigned integer or signed integer data. This is
determined by the type of the internal format of the texture. Texture
lookups on unsigned normalized integer and floating point data return
floating point values in the range [0, 1]. See also section 2.15.4.1 of
the OpenGL specification.
Texture lookup functions are provided that can return their result as
floating point, unsigned integer or signed integer, depending on the
sampler type passed to the lookup function. Care must be taken to use the
right sampler type for texture access. Table 8.xxx lists the supported
combinations of sampler types and texture internal formats.
texture
internal default (float) integer unsigned integer
format sampler sampler sampler
float vec4 n/a n/a
normalized vec4 n/a n/a
signed int n/a ivec4 n/a
unsigned int n/a n/a uvec4
Table 8.xxx Valid combinations of the type of the internal format of a
texture and the type of the sampler used to access the texture. Each cell
in the table indicates the type of the return value of a texture
lookup. N/a means this combination is not supported. A texture lookup
using a n/a combination will return undefined values. The exceptions to
this table are the "textureSize" lookup functions, which will return an
integer or integer vector, regardless of the sampler type.
If a texture with a signed integer internal format is accessed, one of the
signed integer sampler types must be used. If a texture with an unsigned
integer internal format is accessed, one of the unsigned integer sampler
types must be used. Otherwise, one of the default (float) sampler types
must be used. If the types of a sampler and the corresponding texture
internal format do not match, the result of a texture lookup is undefined.
If an integer sampler type is used, the result of a texture lookup is an
ivec4. If an unsigned integer sampler type is used, the result of a
texture lookup is a uvec4. If a default sampler type is used, the result
of a texture lookup is a vec4, where each component is in the range [0,
1].
Integer and unsigned integer functions of all the texture lookup functions
described in this section are also provided, except for the "shadow"
versions, using function overloading. Their prototypes, however, are not
listed separately. These overloaded functions use the integer or
unsigned-integer versions of the sampler types and will return an ivec4 or
an uvec4 respectively, except for the "textureSize" functions, which will
always return an integer, or integer vector. Refer also to table 8.xxxx
for valid combinations of texture internal formats and sampler types. For
example, for the texture1D function, the complete set of prototypes is:
vec4 texture1D(sampler1D sampler, float coord
[, float bias])
ivec4 texture1D(isampler1D sampler, float coord
[, float bias])
uvec4 texture1D(usampler1D sampler, float coord
[, float bias])
Add the following new texture lookup functions:
Syntax:
vec4 texelFetch1D(sampler1D sampler, int coord, int lod)
vec4 texelFetch2D(sampler2D sampler, ivec2 coord, int lod)
vec4 texelFetch3D(sampler3D sampler, ivec3 coord, int lod)
vec4 texelFetch2DRect(sampler2DRect sampler, ivec2 coord)
vec4 texelFetch1DArray(sampler1DArray sampler, ivec2 coord, int lod)
vec4 texelFetch2DArray(sampler2DArray sampler, ivec3 coord, int lod)
Description:
Use integer texture coordinate <coord> to lookup a single texel from the
level-of-detail <lod> on the texture bound to <sampler> as described in
section 2.15.4.1 of the OpenGL specification "Texel Fetches". For the
"array" versions, the layer of the texture array to access is either
coord.t or coord.p, depending on the use of the 1D or 2D texel fetch
lookup, respectively. Note that texelFetch2DRect does not take a
level-of-detail input.
Syntax:
vec4 texelFetchBuffer(samplerBuffer sampler, int coord)
Description:
Use integer texture coordinate <coord> to lookup into the buffer texture
bound to <sampler>.
Syntax:
int textureSizeBuffer(samplerBuffer sampler)
int textureSize1D(sampler1D sampler, int lod)
ivec2 textureSize2D(sampler2D sampler, int lod)
ivec3 textureSize3D(sampler3D sampler, int lod)
ivec2 textureSizeCube(samplerCube sampler, int lod)
ivec2 textureSize2DRect(sampler2DRect sampler, int lod)
ivec2 textureSize1DArray(sampler1DArray sampler, int lod)
ivec3 textureSize2DArray(sampler2DArray sampler, int lod)
Description:
Returns the dimensions, width, height, depth, and number of layers, of
level <lod> for the texture bound to <sampler>, as described in section
2.15.4.1 of the OpenGL specification section "Texture Size Query". For the
textureSize1DArray function, the first (".x") component of the returned
vector is filled with the width of the texture image and the second
component with the number of layers in the texture array. For the
textureSize2DArray function, the first two components (".x" and ".y") of
the returned vector are filled with the width and height of the texture
image respectively. The third component (".z") is filled with the number
of layers in the texture array.
Syntax:
vec4 texture1DArray(sampler1DArray sampler, vec2 coord
[, float bias])
vec4 texture1DArrayLod(sampler1DArray sampler, vec2 coord,
float lod)
Description:
Use the first element (coord.s) of texture coordinate coord to do a
texture lookup in the layer indicated by the second coordinate coord.t of
the 1D texture array currently bound to sampler. The layer to access is
computed by layer = max (0, min(d - 1, floor (coord.t + 0.5)) where 'd' is
the depth of the texture array.
Syntax:
vec4 texture2DArray(sampler2DArray sampler, vec3 coord
[, float bias])
vec4 texture2DArrayLod(sampler2DArray sampler, vec3 coord,
float lod)
Description:
Use the first two elements (coord.s, coord.t) of texture coordinate coord
to do a texture lookup in the layer indicated by the third coordinate
coord.p of the 2D texture array currently bound to sampler. The layer to
access is computed by layer = max (0, min(d - 1, floor (coord.p + 0.5))
where 'd' is the depth of the texture array.
Syntax:
vec4 shadow1DArray(sampler1DArrayShadow sampler, vec3 coord,
[float bias])
vec4 shadow1DArrayLod(sampler1DArrayShadow sampler,
vec3 coord, float lod)
Description:
Use texture coordinate coord.s to do a depth comparison lookup on an array
layer of the depth texture bound to sampler, as described in section
3.8.14 of version 2.0 of the OpenGL specification. The layer to access is
indicated by the second coordinate coord.t and is computed by layer = max
(0, min(d - 1, floor (coord.t + 0.5)) where 'd' is the depth of the
texture array. The third component of coord (coord.p) is used as the R
value. The texture bound to sampler must be a depth texture, or results
are undefined.
Syntax:
vec4 shadow2DArray(sampler2DArrayShadow sampler, vec4 coord)
Description:
Use texture coordinate (coord.s, coord.t) to do a depth comparison lookup
on an array layer of the depth texture bound to sampler, as described in
section 3.8.14 of version 2.0 of the OpenGL specification. The layer to
access is indicated by the third coordinate coord.p and is computed by
layer = max (0, min(d - 1, floor (coord.p + 0.5)) where 'd' is the depth
of the texture array. The fourth component of coord (coord.q) is used as
the R value. The texture bound to sampler must be a depth texture, or
results are undefined.
Syntax:
vec4 shadowCube(samplerCubeShadow sampler, vec4 coord)
Description:
Use texture coordinate (coord.s, coord.t, coord.p) to do a depth
comparison lookup on the depth cubemap bound to sampler, as described in
section 3.8.14. The direction of the vector (coord.s, coord.t, coord.p) is
used to select which face to do a two-dimensional texture lookup in, as
described in section 3.8.6 of the OpenGL 2.0 specification. The fourth
component of coord (coord.q) is used as the R value. The texture bound to
sampler must be a depth cubemap, otherwise results are undefined.
Syntax:
vec4 texture1DGrad(sampler1D sampler, float coord,
float ddx, float ddy);
vec4 texture1DProjGrad(sampler1D sampler, vec2 coord,
float ddx, float ddy);
vec4 texture1DProjGrad(sampler1D sampler, vec4 coord,
float ddx, float ddy);
vec4 texture1DArrayGrad(sampler1DArray sampler, vec2 coord,
float ddx, float ddy);
vec4 texture2DGrad(sampler2D sampler, vec2 coord,
vec2 ddx, vec2 ddy);
vec4 texture2DProjGrad(sampler2D sampler, vec3 coord,
vec2 ddx, vec2 ddy);
vec4 texture2DProjGrad(sampler2D sampler, vec4 coord,
vec2 ddx, vec2 ddy);
vec4 texture2DArrayGrad(sampler2DArray sampler, vec3 coord,
vec2 ddx, vec2 ddy);
vec4 texture3DGrad(sampler3D sampler, vec3 coord,
vec3 ddx, vec3 ddy);
vec4 texture3DProjGrad(sampler3D sampler, vec4 coord,
vec3 ddx, vec3 ddy);
vec4 textureCubeGrad(samplerCube sampler, vec3 coord,
vec3 ddx, vec3 ddy);
vec4 shadow1DGrad(sampler1DShadow sampler, vec3 coord,
float ddx, float ddy);
vec4 shadow1DProjGrad(sampler1DShadow sampler, vec4 coord,
float ddx, float ddy);
vec4 shadow1DArrayGrad(sampler1DArrayShadow sampler, vec3 coord,
float ddx, float ddy);
vec4 shadow2DGrad(sampler2DShadow sampler, vec3 coord,
vec2 ddx, vec2 ddy);
vec4 shadow2DProjGrad(sampler2DShadow sampler, vec4 coord,
vec2 ddx, vec2 ddy);
vec4 shadow2DArrayGrad(sampler2DArrayShadow sampler, vec4 coord,
vec2 ddx, vec2 ddy);
vec4 texture2DRectGrad(sampler2DRect sampler, vec2 coord,
vec2 ddx, vec2 ddy);
vec4 texture2DRectProjGrad(sampler2DRect sampler, vec3 coord,
vec2 ddx, vec2 ddy);
vec4 texture2DRectProjGrad(sampler2DRect sampler, vec4 coord,
vec2 ddx, vec2 ddy);
vec4 shadow2DRectGrad(sampler2DRectShadow sampler, vec3 coord,
vec2 ddx, vec2 ddy);
vec4 shadow2DRectProjGrad(sampler2DRectShadow sampler, vec4 coord,
vec2 ddx, vec2 ddy);
vec4 shadowCubeGrad(samplerCubeShadow sampler, vec4 coord,
vec3 ddx, vec3 ddy);
Description:
The "Grad" functions map the partial derivatives ddx and ddy to ds/dx,
dt/dx, dr/dx, and ds/dy, dt/dy, dr/dy respectively and use texture
coordinate "coord" to do a texture lookup as described for their non
"Grad" counterparts. The derivatives ddx and ddy are used as the explicit
derivate of "coord" with respect to window x and window y respectively and
are used to compute lambda_base(x,y) as in equation 3.18 in the OpenGL 2.0
specification. For the "Proj" versions, it is assumed that the partial
derivatives ddx and ddy are already projected. I.e. the GL assumes that
ddx and ddy represent d(s/q)/dx, d(t/q)/dx, d(r/q)/dx and d(s/q)/dy,
d(t/q)/dy, d(r/q)/dy respectively. For the "Cube" versions, the partial
derivatives ddx and ddy are assumed to be in the coordinate system used
before texture coordinates are projected onto the appropriate cube
face. The partial derivatives of the post-projection texture coordinates,
which are used for level-of-detail and anisotropic filtering
calculations, are derived from coord, ddx and ddy in an
implementation-dependent manner.
NOTE: Except for the "array" and shadowCubeGrad() functions, these
functions are taken from the ARB_shader_texture_lod spec and are
functionally equivalent.
Syntax:
vec4 texture1DOffset(sampler1D sampler, float coord,
int offset [,float bias])
vec4 texture1DProjOffset(sampler1D sampler, vec2 coord,
int offset [,float bias])
vec4 texture1DProjOffset(sampler1D sampler, vec4 coord,
int offset [,float bias])
vec4 texture1DLodOffset(sampler1D sampler, float coord,
float lod, int offset)
vec4 texture1DProjLodOffset(sampler1D sampler, vec2 coord,
float lod, int offset)
vec4 texture1DProjLodOffset(sampler1D sampler, vec4 coord,
float lod, int offset)
vec4 texture2DOffset(sampler2D sampler, vec2 coord,
ivec2 offset [,float bias])
vec4 texture2DProjOffset(sampler2D sampler, vec3 coord,
ivec2 offset [,float bias])
vec4 texture2DProjOffset(sampler2D sampler, vec4 coord,
ivec2 offset [,float bias])
vec4 texture2DLodOffset(sampler2D sampler, vec2 coord,
float lod, ivec2 offset)
vec4 texture2DProjLodOffset(sampler2D sampler, vec3 coord,
float lod, ivec2 offset)
vec4 texture2DProjLodOffset(sampler2D sampler, vec4 coord,
float lod, ivec2 offset)
vec4 texture3DOffset(sampler3D sampler, vec3 coord,
ivec3 offset [,float bias])
vec4 texture3DProjOffset(sampler3D sampler, vec4 coord,
ivec3 offset [,float bias])
vec4 texture3DLodOffset(sampler3D sampler, vec3 coord,
float lod, ivec3 offset)
vec4 texture3DProjLodOffset(sampler3D sampler, vec4 coord,
float lod, ivec3 offset)
vec4 shadow1DOffset(sampler1DShadow sampler, vec3 coord,
int offset [,float bias])
vec4 shadow2DOffset(sampler2DShadow sampler, vec3 coord,
ivec2 offset [,float bias])
vec4 shadow1DProjOffset(sampler1DShadow sampler, vec4 coord,
int offset [,float bias])
vec4 shadow2DProjOffset(sampler2DShadow sampler, vec4 coord,
ivec2 offset [,float bias])
vec4 shadow1DLodOffset(sampler1DShadow sampler, vec3 coord,
float lod, int offset)
vec4 shadow2DLodOffset(sampler2DShadow sampler, vec3 coord,
float lod, ivec2 offset)
vec4 shadow1DProjLodOffset(sampler1DShadow sampler, vec4 coord,
float lod, int offset)
vec4 shadow2DProjLodOffset(sampler2DShadow sampler, vec4 coord,
float lod, ivec2 offset)
vec4 texture2DRectOffset(sampler2DRect sampler, vec2 coord,
ivec2 offset)
vec4 texture2DRectProjOffset(sampler2DRect sampler, vec3 coord,
ivec2 offset)
vec4 texture2DRectProjOffset(sampler2DRect sampler, vec4 coord,
ivec2 offset)
vec4 shadow2DRectOffset(sampler2DRectShadow sampler, vec3 coord,
ivec2 offset)
vec4 shadow2DRectProjOffset(sampler2DRectShadow sampler, vec4 coord,
ivec2 offset)
vec4 texelFetch1DOffset(sampler1D sampler, int coord, int lod,
int offset)
vec4 texelFetch2DOffset(sampler2D sampler, ivec2 coord, int lod,
ivec2 offset)
vec4 texelFetch3DOffset(sampler3D sampler, ivec3 coord, int lod,
ivec3 offset)
vec4 texelFetch2DRectOffset(sampler2DRect sampler, ivec2 coord,
ivec2 offset)
vec4 texelFetch1DArrayOffset(sampler1DArray sampler, ivec2 coord,
int lod, int offset)
vec4 texelFetch2DArrayOffset(sampler2DArray sampler, ivec3 coord,
int lod, ivec2 offset)
vec4 texture1DArrayOffset(sampler1DArray sampler, vec2 coord,
int offset [, float bias])
vec4 texture1DArrayLodOffset(sampler1DArray sampler, vec2 coord,
float lod, int offset)
vec4 texture2DArrayOffset(sampler2DArray sampler, vec3 coord,
ivec2 offset [, float bias])
vec4 texture2DArrayLodOffset(sampler2DArray sampler, vec3 coord,
float lod, ivec2 offset)
vec4 shadow1DArrayOffset(sampler1DArrayShadow sampler, vec3 coord,
int offset, [float bias])
vec4 shadow1DArrayLodOffset(sampler1DArrayShadow sampler, vec3 coord,
float lod, int offset)
vec4 shadow2DArrayOffset(sampler2DArrayShadow sampler,
vec4 coord, ivec2 offset)
vec4 texture1DGradOffset(sampler1D sampler, float coord,
float ddx, float ddy, int offset);
vec4 texture1DProjGradOffset(sampler1D sampler, vec2 coord,
float ddx, float ddy, int offset);
vec4 texture1DProjGradOffset(sampler1D sampler, vec4 coord,
float ddx, float ddy, int offset);
vec4 texture1DArrayGradOffset(sampler1DArray sampler, vec2 coord,
float ddx, float ddy, int offset);
vec4 texture2DGradOffset(sampler2D sampler, vec2 coord,
vec2 ddx, vec2 ddy, ivec2 offset);
vec4 texture2DProjGradOffset(sampler2D sampler, vec3 coord,
vec2 ddx, vec2 ddy, ivec2 offset);
vec4 texture2DProjGradOffset(sampler2D sampler, vec4 coord,
vec2 ddx, vec2 ddy, ivec2 offset);
vec4 texture2DArrayGradOffset(sampler2DArray sampler, vec3 coord,
vec2 ddx, vec2 ddy, ivec2 offset);
vec4 texture3DGradOffset(sampler3D sampler, vec3 coord,
vec3 ddx, vec3 ddy, ivec3 offset);
vec4 texture3DProjGradOffset(sampler3D sampler, vec4 coord,
vec3 ddx, vec3 ddy, ivec3 offset);
vec4 shadow1DGradOffset(sampler1DShadow sampler, vec3 coord,
float ddx, float ddy, int offset);
vec4 shadow1DProjGradOffset(sampler1DShadow sampler,
vec4 coord, float ddx, float ddy,
int offset);
vec4 shadow1DArrayGradOffset(sampler1DArrayShadow sampler,
vec3 coord, float ddx, float ddy,
int offset);
vec4 shadow2DGradOffset(sampler2DShadow sampler, vec3 coord,
vec2 ddx, vec2 ddy, ivec2 offset);
vec4 shadow2DProjGradOffset(sampler2DShadow sampler, vec4 coord,
vec2 ddx, vec2 ddy, ivec2 offset);
vec4 shadow2DArrayGradOffset(sampler2DArrayShadow sampler,
vec4 coord, vec2 ddx, vec2 ddy,
ivec2 offset);
vec4 texture2DRectGradOffset(sampler2DRect sampler, vec2 coord,
vec2 ddx, vec2 ddy, ivec2 offset);
vec4 texture2DRectProjGradOffset(sampler2DRect sampler, vec3 coord,
vec2 ddx, vec2 ddy, ivec2 offset);
vec4 texture2DRectProjGradOffset(sampler2DRect sampler, vec4 coord,
vec2 ddx, vec2 ddy, ivec2 offset);
vec4 shadow2DRectGradOffset(sampler2DRectShadow sampler,
vec3 coord, vec2 ddx, vec2 ddy,
ivec2 offset);
vec4 shadow2DRectProjGradOffset(sampler2DRectShadow sampler,
vec4 coord, vec2 ddx, vec2 ddy,
ivec2 offset);
Description:
The "offset" version of each function provides an extra parameter <offset>
which is added to the (u,v,w) texel coordinates before looking up each
texel. The offset value must be a constant expression. A limited range
of offset values are supported; the minimum and maximum offset values are
implementation-dependent and given by MIN_PROGRAM_TEXEL_OFFSET_EXT and
MAX_PROGRAM_TEXEL_OFFSET_EXT, respectively. Note that <offset> does not
apply to the layer coordinate for texture arrays. This is explained in
detail in section 3.8.7 of the OpenGL Specification. Note that texel
offsets are also not supported for cubemaps or buffer textures.
Add to section 9 "Grammar"
type_qualifer:
CONST
ATTRIBUTE // Vertex only
varying-modifier_opt VARYING
UNIFORM
varying-modifier:
FLAT
CENTROID
NOPERSPECTIVE
type_specifier:
VOID
FLOAT
INT
UNSIGNED_INT
BOOL
1. Should we support shorts in GLSL?
DISCUSSION:
RESOLUTION: UNRESOLVED
2. Do bitwise shifts, AND, exclusive OR and inclusive OR support all
combinations of scalars and vectors for each operand?
DISCUSSION: It seems sense to support scalar OP scalar, vector OP scalar
and vector OP vector. But what about scalar OP vector? Should the scalar
be promoted to a vector first?
RESOLUTION: RESOLVED. Yes, this should work essentially as the '+'
operator. The scalar is applied to each component of the vector.
3. Which built-in functions should also operate on integers?
DISCUSSION: There are several that don't make sense to define to operate
on integers at all, but the following can be debated: pow, sqrt, dot (and
the functions that use dot), cross.
RESOLUTION: RESOLVED. Integer versions of the abs, sign, min, max and
clamp functions are defined. Note that the modulus operator % has been
defined for integer operands.
4. Do we need to support integer matrices?
DISCUSSION:
RESOLUTION: RESOLVED No, not at the moment.
5. Which texture array lookup functions do we need to support?
DISCUSSION: We don't want to support lookup functions that need more than
four components passed as parameters. Components can be used for texture
coordinates, layer selection, 'R' depth compare and the 'q' coordinate
for projection. However, texture projection might be relatively easy to
support through code-generation, thus we might be able to support
functions that need five components, as long as one of them is 'q' for
projective texturing. Specifically, should we support:
vec4 texture2DArrayProjLod(sampler2DArray sampler, vec4 coord,
float lod)
vec4 shadow1DArray(sampler1DArrayShadow sampler, vec3 coord,
[float bias])
vec4 shadow1DArrayProj(sampler1DArrayShadow sampler, vec4 coord,
[float bias])
vec4 shadow1DArrayLod(sampler1DArrayShadow sampler, vec3 coord,
float lod)
vec4 shadow1DArrayProjLod(sampler1DArrayShadow sampler,
vec4 coord, float lod)
vec4 shadow2DArray(sampler2DArrayShadow sampler, vec4 coord)
vec4 shadow2DArrayProj(sampler2DArrayShadow sampler, vec4 coord,
float refValue)
RESOLUTION: RESOLVED, We'll support all but the "Proj" versions. The
assembly spec (NV_gpu_program4) doesn't support the equivalent
functionality, either.
6. How do we handle conversions between integer and unsigned
integers?
DISCUSSION: Do we allow automatic type conversions between signed and
unsigned integers?
RESOLUTION: RESOLVED. We will not add this until GLSL version 1.20 has
been defined, and the implicit conversion rules have been established
there. If we do this, we would likely only support implicit conversion
from int to unsigned int, just like C does.
7. Should varying modifiers (flat, noperspective) apply to built-in
varying variables also?
DISCUSSION: There is API to control flat vs smooth shading for colors
through glShadeModel(). There is also API to hint if colors should be
interpolated perspective correct, or not, through glHint(). These API
commands apply to the built-in color varying variables (gl_FrontColor
etc). If the varying modifiers in a shader also apply to the color
built-ins, which has precedence?
RESOLUTION: RESOLVED. It is simplest and cleanest to only allow the
varying modifiers to apply to user-defined varying variables. The
behavior of the built-in color varying variables can still be controlled
through the API.
8. How should perspective-incorrect interpolation (linear in screen space)
and clipping interact?
RESOLVED: Primitives with attributes specified to be perspective-
incorrect should be clipped so that the vertices introduced by clipping
should have attribute values consistent with the interpolation mode. We
do not want to have large color shifts introduced by clipping a
perspective-incorrect attribute. For example, a primitive that
approaches, but doesn't cross, a frustum clip plane should look pretty
much identical to a similar primitive that just barely crosses the clip
plane.
Clipping perspective-incorrect interpolants that cross the W==0 plane is
very challenging. The attribute clipping equation provided in the spec
effectively projects all the original vertices to screen space while
ignoring the X and Y frustum clip plane. As W approaches zero, the
projected X/Y window coordinates become extremely large. When clipping
an edge with one vertex inside the frustum and the other out near
infinity (after projection, due to W approaching zero), the interpolated
attribute for the entire visible portion of the edge should almost
exactly match the attribute value of the visible vertex.
If an outlying vertex approaches and then goes past W==0, it can be said
to go "to infinity and beyond" in screen space. The correct answer for
screen-linear interpolation is no longer obvious, at least to the author
of this specification. Rather than trying to figure out what the
"right" answer is or if one even exists, the results of clipping such
edges is specified as undefined.
9. Do we need to support a non-MRT fragment shader writing to (unsigned)
integer outputs?
DISCUSSION: Fragment shaders with only one fragment output are
considered non-MRT shaders. This means that the output of the shader
gets smeared across all color buffers attached to the
framebuffer. Fragment shaders with multiple fragment outputs are MRT
shaders. Each output is directed to a color buffer using the DrawBuffers
API (for gl_FragData) and a combination of the BindFragDataLocationEXT
and DrawBuffers API (for varying out variables). Before this extension,
a non-MRT shader would write to gl_Color only. A shader writing to
gl_FragData[] is a MRT shader. With the addition of varying out
variables in this extension, any shader writing to a variable out
variable is a MRT shader. It is not possible to construct a non-MRT
shader writing to varying out variables. Varying out variables can be
declared to be of type integer or unsigned integer. In order to support
a non-MRT shader that can write to (unsigned) integer outputs, we could
define two new built-in variables:
ivec4 gl_FragColorInt;
uvec4 gl_FragColorUInt;
Or we could add a special rule stating that if the program object writes
to exactly one varying out variable, it is considered to be non-MRT.
RESOLUTION: NO. We don't care enough to support this.
10. Is section 2.14.8, "Color and Associated Data Clipping" in the core
specification still correct?
DISCUSSION: This section is in need of some updating, now that varying
variables can be interpolated without perspective correction. Some (not
so precise) language has been added in the spec body, suggesting that
the interpolation needs to be performed in such a way as to produce
results that vary linearly in screen space. However, we could define the
exact interpolation method required to achieve this. A suggested updated
paragraph follows, but we'll leave updating section 2.14.8 to a future
edit of the core specification, not this extension.
Replace Section 2.14.8, and rename it to "Vertex Attribute Clipping"
After lighting, clamping or masking and possible flatshading, vertex
attributes, including colors, texture and fog coordinates, shader
varying variables, and point sizes computed on a per vertex basis, are
clipped. Those attributes associated with a vertex that lies within the
clip volume are unaffected by clipping. If a primitive is clipped,
however, the attributes assigned to vertices produced by clipping are
produced by interpolating attributes along the clipped edge.
Let the attributes assigned to the two vertices P_1 and P_2 of an
unclipped edge be a_1 and a_2. The value of t (section 2.12) for a
clipped point P is used to obtain the attribute associated with P as
a = t * a_1 + (1-t) * a_2
unless the attribute is specified to be interpolated without perspective
correction in a shader (using the noperspective keyword). In that case,
the attribute associated with P is
a = t' * a_1 + (1-t') * a_2
where
t' = (t * w_1) / (t * w_1 + (1-t) * w_2)
and w_1 and w_2 are the w clip coordinates of P_1 and P_2,
respectively. If w_1 or w_2 is either zero or negative, the value of the
associated attribute is undefined.
For a color index color, multiplying a color by a scalar means
multiplying the index by the scalar. For a vector attribute, it means
multiplying each vector component by the scalar. Polygon clipping may
create a clipped vertex along an edge of the clip volume's
boundary. This situation is handled by noting that polygon clipping
proceeds by clipping against one plane of the clip volume's boundary at
a time. Attribute clipping is done in the same way, so that clipped
points always occur at the intersection of polygon edges (possibly
already clipped) with the clip volume's boundary.
11. When and where in the texture filtering process are texel offsets
applied?
DISCUSSION: Texel offsets are applied to the (u,v,w) coordinates of the
base level of the texture if the texture filter mode does not indicate
mipmapping. Otherwise, texel offsets are applied to the (u,v,w)
coordinates of the mipmap level 'd', as found by equation 3.27 or to
mipmap levels 'd1' and 'd2' as found by equation 3.28 in the OpenGL 2.0
specification. In other words, texel offsets are applied to the
(u,v,w) coordinate of whatever mipmap level is accessed.
12. Why is writing to the built-in output variable "gl_Position" in a vertex
shader now optional?
DISCUSSION: Before this specification, writing to gl_Position in a
vertex shader was mandatory. The GL pipeline required a vertex position
to be written in order to produce well-defined output. This is still the
case if the GL pipeline indeed needs a vertex position. However, with
fourth-generation programmable hardware there are now cases where the GL
pipeline no longer requires a vertex position in order to produce
well-defined results. If a geometry shader is present, the vertex shader
does not need to write to gl_Position anymore. Instead, the geometry
shader can compute a vertex position and write to its gl_Position
output. In case of transform-feedback, where the output of a vertex or
geometry shader is streamed to one or more buffer objects, perfectly
valid results can be obtained without either the vertex shader nor
geometry shader writing to gl_Position. The transform-feedback
specification adds a new enable to discard primitives right before
rasterization, making it potentially unnecessary to write to
gl_Position.
Rev. Date Author Changes
---- -------- -------- -----------------------------------------
12 02/04/08 pbrown Fix errors in texture wrap mode handling.
Added a missing clamp to avoid sampling border
in REPEAT mode. Fixed incorrectly specified
weights for LINEAR filtering.
11 05/08/07 pbrown Add VertexAttribIPointerEXT to the list of
commands that can't go in display lists.
10 01/23/07 pbrown Fix prototypes for a variety of functions
that were specified with an incorrect sampler
type.
9 12/15/06 pbrown Documented that the '#extension' token
for this extension should begin with "GL_",
as apparently called for per convention.
8 -- Pre-release revisions.
8 -- Pre-release revisions.
 |  | Last update: November 14, 2006.
Cette page doit être lue avec un navigateur récent respectant le standard XHTML 1.1.
|
