skia / external / github.com / KhronosGroup / OpenGL-Registry / refs/heads/310-issue / . / extensions / EXT / EXT_gpu_shader4.txt

Name | |

EXT_gpu_shader4 | |

Name Strings | |

GL_EXT_gpu_shader4 | |

Contact | |

Barthold Lichtenbelt, NVIDIA (blichtenbelt 'at' nvidia.com) | |

Pat Brown, NVIDIA (pbrown 'at' nvidia.com) | |

Status | |

Multi vendor extension | |

Shipping for GeForce 8 Series (November 2006) | |

Version | |

Last Modified Date: 12/14/2009 | |

Author revision: 16 | |

Number | |

326 | |

Dependencies | |

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. | |

Overview | |

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); | |

New Tokens | |

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 count 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. | |

Delete Section 3.8.7, Texture Wrap Modes. (The language in this section | |

is folded into updates to the following section, and is no longer needed | |

here.) | |

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) + offsetu_shader, | |

v(x,y) = h_t * t(x,y) + offsetv_shader, | |

w(x,y) = d_t * r(x,y) + offsetw_shader, and | |

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. (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. For | |

fixed-function texture accesses, all three shader offsets are taken to be | |

zero. For a one-dimensional texture, define v(x,y) == 0 and w(x,y) === 0; | |

for two-dimensional textures, define w(x,y) == 0. | |

After u(x,y), v(x,y), and w(x,y) are generated, they are clamped if the | |

corresponding texture wrap modes are CLAMP or MIRROR_CLAMP_EXT. Let | |

u'(x,y) = clamp(u(x,y), 0, w_t), if TEXTURE_WRAP_S is CLAMP | |

clamp(u(x,y), -w_t, w_t), if TEXTURE_WRAP_S is | |

MIRROR_CLAMP_EXT, or | |

u(x,y), otherwise | |

v'(x,y) = clamp(v(x,y), 0, w_t), if TEXTURE_WRAP_T is CLAMP | |

clamp(v(x,y), -w_t, w_t), if TEXTURE_WRAP_T is | |

MIRROR_CLAMP_EXT, or | |

v(x,y), otherwise | |

w'(x,y) = clamp(w(x,y), 0, w_t), if TEXTURE_WRAP_R is CLAMP | |

clamp(w(x,y), -w_t, w_t), if TEXTURE_WRAP_R is | |

MIRROR_CLAMP_EXT, or | |

w(x,y), otherwise, | |

where clamp(<a>,<b>,<c>) returns <b> if <a> is less than <b>, <c> if a is | |

greater than <c>, and <a> otherwise. | |

(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) | |

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 that specified by | |

(s,t,r) is obtained. Let i, j, and k be integers such that: | |

i = apply_wrap(floor(u'(x,y))), | |

j = apply_wrap(floor(v'(x,y))), and | |

k = apply_wrap(floor(w'(x,y))), | |

where the coordinate returned by apply_wrap() is as defined by Table X.19. | |

The values of i, j, and k are then modified according to the texture wrap | |

modes, as described in Table 3.19, to produce new values (i', j', and k'). | |

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. | |

Wrap mode Result | |

-------------------------- ------------------------------------------ | |

CLAMP_TO_EDGE clamp(coord, 0, size-1) | |

CLAMP_TO_BORDER clamp(coord, -1, size) | |

CLAMP { clamp(coord, 0, size-1), | |

{ for NEAREST filtering | |

{ clamp(coord, -1, size), | |

{ for LINEAR filtering | |

REPEAT mod(coord, size) | |

MIRROR_CLAMP_TO_EDGE_EXT clamp(mirror(coord), 0, size-1) | |

MIRROR_CLAMP_TO_BORDER_EXT clamp(mirror(size), 0, size) | |

MIRROR_CLAMP_EXT { clamp(mirror(coord), 0, size-1), | |

{ for NEAREST filtering | |

{ clamp(mirror(size), 0, size), | |

{ for LINEAR filtering | |

MIRRORED_REPEAT (size-1) - mirror(mod(coord, 2*size)-size) | |

Table X.19: Texel location wrap mode application. mod(<a>,<b>) is | |

defined to return <a>-<b>*floor(<a>/<b>), and mirror(<a>) is defined to | |

return <a> if <a> is greater than or equal to zero or -(1+<a>) | |

otherwise. The values of "wrap mode" and size are TEXTURE_WRAP_S and | |

w_t, TEXTURE_WRAP_T and h_t, and TEXTURE_WRAP_R and d_t, for i, j, and k | |

coordinates, respectively. The coordinate clamp and MIRROR_CLAMP_EXT | |

depends on the filtering mode (NEAREST or LINEAR). | |

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_t + b_s, | |

j >= h_t + b_s, or | |

j >= d_t + 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 = apply_wrap(floor(u' - 0.5)), | |

j_0 = apply_wrap(floor(v' - 0.5)), | |

k_0 = apply_wrap(floor(w' - 0.5)), | |

i_1 = apply_wrap(floor(u' - 0.5) + 1), | |

j_1 = apply_wrap(floor(v' - 0.5) + 1), | |

k_1 = apply_wrap(floor(w' - 0.5) + 1), | |

alpha = frac(u' - 0.5), | |

beta = frac(v' - 0.5), | |

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. | |

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 the first paragraph of section 3.8.9 "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 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. | |

GLX Protocol | |

The following rendering commands are sent to the server as part of a | |

glXRender request: | |

Uniform1uiEXT | |

2 12 rendering command length | |

2 269 rendering command opcode | |

4 INT32 location | |

4 CARD32 v0 | |

Uniform2uiEXT | |

2 16 rendering command length | |

2 270 rendering command opcode | |

4 INT32 location | |

4 CARD32 v0 | |

4 CARD32 v1 | |

Uniform3uiEXT | |

2 20 rendering command length | |

2 271 rendering command opcode | |

4 INT32 location | |

4 CARD32 v0 | |

4 CARD32 v1 | |

4 CARD32 v2 | |

Uniform4uiEXT | |

2 24 rendering command length | |

2 272 rendering command opcode | |

4 INT32 location | |

4 CARD32 v0 | |

4 CARD32 v1 | |

4 CARD32 v2 | |

4 CARD32 v3 | |

BindFragDataLocationEXT | |

2 12+n+p rendering command length | |

2 273 rendering command opcode | |

4 CARD32 program | |

4 CARD32 color | |

n LISTofBYTE name, n = strlen(name) + 1 | |

p padding, p=pad(n) | |

The following rendering commands are sent sent to the server as part | |

of a glXRender request or as a glXRenderLarge request. | |

Uniform1uivEXT | |

2 12+count*4 rendering command length | |

2 274 rendering command opcode | |

4 INT32 location | |

4 CARD32 count | |

4*count LISTofCARD32 value | |

If the command is encoded in a glXRenderLarge request, the | |

command opcode and command length fields above are expanded to | |

4 bytes each: | |

4 16+count*4 rendering command length | |

4 274 rendering command opcode | |

Uniform2uivEXT | |

2 12+count*4*2 rendering command length | |

2 275 rendering command opcode | |

4 INT32 location | |

4 CARD32 count | |

2*4*count LISTofCARD32 value | |

If the command is encoded in a glXRenderLarge request, the | |

command opcode and command length fields above are expanded to | |

4 bytes each: | |

4 16+count*4*2 rendering command length | |

4 275 rendering command opcode | |

Uniform3uivEXT | |

2 12+count*4*3 rendering command length | |

2 276 rendering command opcode | |

4 INT32 location | |

4 CARD32 count | |

3*4*count LISTofCARD32 value | |

If the command is encoded in a glXRenderLarge request, the | |

command opcode and command length fields above are expanded to | |

4 bytes each: | |

4 16+count*4 rendering command length | |

4 276 rendering command opcode | |

Uniform4uivEXT | |

2 12+count*4*4 rendering command length | |

2 277 rendering command opcode | |

4 INT32 location | |

4 CARD32 count | |

4*4*count LISTofCARD32 value | |

If the command is encoded in a glXRenderLarge request, the | |

command opcode and command length fields above are expanded to | |

4 bytes each: | |

4 16+count*4*4 rendering command length | |

4 277 rendering command opcode | |

The following non-rendering commands are added. | |

GetUniformuivEXT | |

1 CARD8 opcode (X assigned) | |

1 182 GLX opcode | |

2 4 request length | |

4 GLX_CONTEXT_TAG context tag | |

4 CARD32 program | |

4 INT32 location | |

=> | |

1 1 reply | |

1 unused | |

2 CARD16 sequence number | |

4 m reply length, m = (n == 1 ? 0 : n) | |

4 CARD32 unused | |

4 CARD32 n | |

if (n = 1) this follows: | |

4 CARD32 params | |

12 unused | |

otherwise this follows: | |

16 CARD32 unused | |

4*n CARD32 params | |

Note that n may be zero, indicating that a GL error occured. | |

GetFragDataLocationEXT | |

1 CARD8 opcode (X assigned) | |

1 183 GLX opcode | |

2 3+(n+p)/4 request length | |

4 GLX_CONTEXT_TAG context tag | |

4 CARD32 program | |

n LISTofBYTE name, n = strlen(name) + 1 | |

p padding, p=pad(n) | |

=> | |

1 1 reply | |

1 unused | |

2 CARD16 sequence number | |

4 0 reply length | |

4 CARD32 retval | |

20 unused | |

GLX protocol for following commands is defined in the | |

NV_vertex_program4 extension: | |

VertexAttribI1iEXT, VertexAttribI2iEXT, VertexAttribI3iEXT, | |

VertexAttribI4iEXT, VertexAttribI1uiEXT, VertexAttribI2uiEXT, | |

VertexAttribI3uiEXT, VertexAttribI4uiEXT, VertexAttribI1ivEXT, | |

VertexAttribI2ivEXT, VertexAttribI3ivEXT, VertexAttribI4ivEXT, | |

VertexAttribI1uivEXT, VertexAttribI2uivEXT, VertexAttribI3uivEXT, | |

VertexAttribI4uivEXT, VertexAttribI4bvEXT, VertexAttribI4svEXT, | |

VertexAttribI4ubvEXT, VertexAttribI4usvEXT, GetVertexAttribIivEXT, | |

GetVertexAttribIuivEXT | |

VertexAttribIPointerEXT is an entirely client-side command. | |

Errors | |

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_OPERATION 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. | |

New State | |

(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 | |

Issues | |

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. | |

13. How does this extension interact with ARB_shader_texture_lod? | |

DISCUSSION: This extension adds "Grad" functions which are functionally | |

equivalent to those defined by ARB_shader_texture_lod, but do not have | |

an ARB suffix. | |

RESOLUTION: There is no interaction. If both extensions are supported, | |

both sets of functions are available and can be controlled independently | |

via the #extension mechanism. | |

Revision History | |

Rev. Date Author Changes | |

---- -------- -------- ----------------------------------------- | |

16 12/14/09 mgodse Added GLX protocol. | |

15 04/09/09 pbrown Fixed a typo in the texture size query spec | |

language - returns a layer count, not "index". | |

14 07/29/08 pbrown Discovered additional issues with texture wrap | |

handling, replaced with logic that applies wrap | |

modes per sample. | |

13 04/04/08 pbrown Added issue 13, concerning the (non-)interaction | |

with ARB_shader_texture_lod. | |

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. | |