able written by a vertex shader, or read by a fragment shader, will count against this limit. The transformed vertex position (gl Position) is not a varying variable and does not count against this limit. A program whose shaders access more than MAX VARYING FLOATS components worth of varying variables may fail to link, unless device-dependent optimizations are able to make the program fit within available hardware resources.

2.15.4 Shader Execution

If a successfully linked program object that contains a vertex shader is made current by calling UseProgram, the executable version of the vertex shader is used to process incoming vertex values rather than the fixed-function vertex processing described in sections 2.11 through 2.14. In particular,

•The model-view and projection matrices are not applied to vertex coordinates (section 2.11).

•The texture matrices are not applied to texture coordinates (section 2.11.2).

•Normals are not transformed to eye coordinates, and are not rescaled or normalized (section 2.11.3).

•Normalization of AUTO NORMAL evaluated normals is not performed. (section 5.1).

•Texture coordinates are not generated automatically (section 2.11.4).

•Per vertex lighting is not performed (section 2.14.1).

•Color material computations are not performed (section 2.14.3).

•Color index lighting is not performed (section 2.14.5).

•All of the above applies when setting the current raster position (section 2.13).

The following operations are applied to vertex values that are the result of executing the vertex shader:

•Color clamping or masking (section 2.14.6).

•Perspective division on clip coordinates (section 2.11).

•Viewport mapping, including depth range scaling (section 2.11.1).

Version 2.0 - October 22, 2004

•Clipping, including client-defined clip planes (section 2.12).

•Front face determination (section 2.14.1).

•Flat-shading (section 2.14.7).

•Color, texture coordinate, fog, point-size and generic attribute clipping (section 2.14.8).

•Final color processing (section 2.14.9.

There are several special considerations for vertex shader execution described in the following sections.

Texture Access

Vertex shaders have the ability to do a lookup into a texture map, if supported by the GL implementation. The maximum number of texture image units available to a vertex shader is MAX VERTEX TEXTURE IMAGE UNITS; a maximum number of zero indicates that the GL implemenation does not support texture accesses in vertex shaders. The maximum number of texture image units available to the fragment stage of the GL is MAX TEXTURE IMAGE UNITS. Both the vertex shader and fragment processing combined cannot use more than MAX COMBINED TEXTURE IMAGE UNITS texture image units. If both the vertex shader and the fragment processing stage access the same texture image unit, then that counts as using two texture image units against the

MAX COMBINED TEXTURE IMAGE UNITS limit.

When a texture lookup is performed in a vertex shader, the filtered texture value τ is computed in the manner described in sections 3.8.8 and 3.8.9, and converted it to a texture source color Cs according to table 3.21 (section 3.8.13). A fourcomponent vector (Rs, Gs, Bs, As) is returned to the vertex shader.

In a vertex shader, it is not possible to perform automatic level-of-detail calculations using partial derivatives of the texture coordinates with respect to window coordinates as described in section 3.8.8. Hence, there is no automatic selection of an image array level. Minification or magnification of a texture map is controlled by a level-of-detail value optionally passed as an argument in the texture lookup functions. If the texture lookup function supplies an explicit level-of-detail value l, then the pre-bias level-of-detail value λbase(x, y) = l (replacing equation 3.18). If the texture lookup function does not supply an explicit level-of-detail value, then λbase(x, y) = 0. The scale factor ρ(x, y) and its approximation function f(x, y) (see equation 3.21) are ignored.

Version 2.0 - October 22, 2004

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 texture coordinate used to perform the lookup, as described in section 3.8.14. The comparison operation is requested in the shader by using the shadow sampler types (sampler1DShadow or sampler2DShadow) 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 of type sampler1D or sampler2D, and the texture object’s internal format is DEPTH COMPONENT, and the TEXTURE COMPARE MODE is not NONE.

•The sampler used in a texture lookup function is of type sampler1DShadow or sampler2DShadow, and the texture object’s internal format is

DEPTH COMPONENT, and the TEXTURE COMPARE MODE is NONE.

•The sampler used in a texture lookup function is of type sampler1DShadow or sampler2DShadow, and the texture object’s internal format is not

DEPTH COMPONENT.

If a vertex shader uses a sampler where the associated texture object is not complete, as defined in section 3.8.10, the texture image unit will return (R, G, B, A)

= (0, 0, 0, 1).

Position Invariance

If a vertex shader uses the built-in function ftransform to generate a vertex position, then this generally guarantees that the transformed position will be the same whether using this vertex shader or the fixed-function pipeline. This allows for correct multi-pass rendering algorithms, where some passes use fixed-function vertex transformation and other passes use a vertex shader. If a vertex shader does not use ftransform to generate a position, transformed positions are not guaranteed to match, even if the sequence of instructions used to compute the position match the sequence of transformations described in section 2.11.

Validation

It is not always possible to determine at link time if a program object actually will execute. Therefore validation is done when the first rendering command is issued, to determine if the currently active program object can be executed. If

Version 2.0 - October 22, 2004

it cannot be executed then no fragments will be rendered, and Begin, RasterPos, or any command that performs an implicit Begin will generate the error

INVALID OPERATION.

This error is generated by Begin, RasterPos, or any command that performs an implicit Begin if:

•any two active samplers in the current program object are of different types, but refer to the same texture image unit,

•any active sampler in the current program object refers to a texture image unit where fixed-function fragment processing accesses a texture target that does not match the sampler type, or

•the sum of the number of active samplers in the program and the number of texture image units enabled for fixed-function fragment processing exceeds the combined limit on the total number of texture image units allowed.

Fixed-function fragment processing operations will be performed if the program object in use has no fragment shader.

The INVALID OPERATION error reported by these rendering commands may not provide enough information to find out why the currently active program object would not execute. No information at all is available about a program object that would still execute, but is inefficient or suboptimal given the current GL state. As a development aid, use the command

void ValidateProgram( uint program );

to validate the program object program against the current GL state. Each program object has a boolean status, VALIDATE STATUS, that is modified as a result of validation. This status can be queried with GetProgramiv (see section 6.1.14). If validation succeeded this status will be set to TRUE, otherwise it will be set to FALSE. If validation succeeded the program object is guaranteed to execute, given the current GL state. If validation failed, the program object is guaranteed to not execute, given the current GL state.

ValidateProgram will check for all the conditions that could lead to an INVALID OPERATION error when rendering commands are issued, and may check for other conditions as well. For example, it could give a hint on how to optimize some piece of shader code. The information log of program is overwritten with information on the results of the validation, which could be an empty string. The results written to the information log are typically only useful during application development; an application should not expect different GL implementations to produce identical information.

Version 2.0 - October 22, 2004