conform to shader spec 1.10.59

1 files changed, 366 insertions, 354 deletions

diff --git a/src/mesa/shader/slang_fragment_builtin.gc b/src/mesa/shader/slang_fragment_builtin.gc
index 6ccf0e7c0fc..ec282924ecd 100755
--- a/src/mesa/shader/slang_fragment_builtin.gc
+++ b/src/mesa/shader/slang_fragment_builtin.gc
@@ -1,354 +1,366 @@
-

-// 

-// TODO:

-// - implement texture1D, texture2D, texture3D, textureCube,

-// - implement shadow1D, shadow2D,

-// - implement dFdx, dFdy,

-// 

-

-// 

-// From Shader Spec, ver. 1.051

-// 

-// The output of the fragment shader goes on to be processed by the fixed function operations at

-// the back end of the OpenGL pipeline. Fragment shaders interface with the back end of the OpenGL

-// pipeline using the built-in variables gl_FragColor and gl_FragDepth, or by executing the discard

-// keyword.

-// 

-// These variables may be written more than once within a fragment shader. If so, the last value

-// assigned is the one used in the subsequent fixed function pipeline. The values written to these

-// variables may be read back after writing them. Reading from these variables before writing them

-// results in an undefined value. The fixed functionality computed depth for a fragment may be

-// obtained by reading gl_FragCoord.z, described below.

-// 

-// Writing to gl_FragColor specifies the fragment color that will be used by the subsequent fixed

-// functionality pipeline. If subsequent fixed functionality consumes fragment color and an

-// execution of a fragment shader does not write a value to gl_FragColor then the fragment color

-// consumed is undefined.

-// 

-// If the frame buffer is configured as a color index buffer then behavior is undefined when using

-// a fragment shader.

-// 

-// Writing to gl_FragDepth will establish the depth value for the fragment being processed. If

-// depth buffering is enabled, and a shader does not write gl_FragDepth, then the fixed function

-// value for depth will be used as the fragment�s depth value. If a shader statically assigns

-// a value to gl_FragDepth, and there is an execution path through the shader that does not set

-// gl_FragDepth, then the value of the fragment�s depth may be undefined for some executions of

-// the shader. That is, if a shader statically writes gl_FragDepth, then it is responsible for

-// always writing it. There is also no guarantee that a shader can compute the same depth value

-// as the fixed function value; an implementation will provide invariant results within shaders

-// computing depth with the same source-level expression, but invariance is not provided between

-// shaders and fixed functionality.

-// 

-// Writes to gl_FragColor and gl_FragDepth need not be clamped within a shader. The fixed

-// functionality pipeline following the fragment shader will clamp these values.

-// 

-// If a shader executes the discard keyword, the fragment is discarded, and the values of

-// gl_FragDepth and gl_FragColor become irrelevant.

-// 

-// The variable gl_FragCoord is available as a read-only variable from within fragment shaders

-// and it holds the window relative coordinates x, y, z, and 1/w values for the fragment. This

-// value is the result of the fixed functionality that interpolates primitives after vertex

-// processing to generate fragments. The z component is the depth value that would be used for

-// the fragment�s depth if a shader contained no writes to gl_FragDepth. This is useful for

-// invariance if a shader conditionally computes gl_FragDepth but otherwise wants the fixed

-// functionality fragment depth.

-// 

-// The fragment shader has access to the read-only built-in variable gl_FrontFacing whose value

-// is true if the fragment belongs to a front-facing primitive. One use of this is to emulate

-// two-sided lighting by selecting one of two colors calculated by the vertex shader.

-// 

-// The built-in variables that are accessible from a fragment shader are intrinsically given types

-// as follows:

-// 

-

-vec4 gl_FragCoord;

-bool gl_FrontFacing;

-vec4 gl_FragColor;

-float gl_FragDepth;

-

-// 

-// However, they do not behave like variables with no qualifier; their behavior is as described

-// above. These built-in variables have global scope.

-// 

-

-// 

-// Unlike user-defined varying variables, the built-in varying variables don�t have a strict

-// one-to-one correspondence between the vertex language and the fragment language. Two sets are

-// provided, one for each language. Their relationship is described below.

-// 

-// The following varying variables are available to read from in a fragment shader. The gl_Color

-// and gl_SecondaryColor names are the same names as attributes passed to the vertex shader.

-// However, there is no name conflict, because attributes are visible only in vertex shaders

-// and the following are only visible in a fragment shader.

-// 

-

-varying vec4 gl_Color;

-varying vec4 gl_SecondaryColor;

-varying vec4 gl_TexCoord[];                             // at most will be gl_MaxTextureCoordsARB

-varying float gl_FogFragCoord;

-

-// 

-// The values in gl_Color and gl_SecondaryColor will be derived automatically by the system from

-// gl_FrontColor, gl_BackColor, gl_FrontSecondaryColor, and gl_BackSecondaryColor based on which

-// face is visible. If fixed functionality is used for vertex processing, then gl_FogFragCoord will

-// either be the z-coordinate of the fragment in eye space, or the interpolation of the fog

-// coordinate, as described in section 3.10 of the OpenGL 1.4 Specification. The gl_TexCoord[]

-// values are the interpolated gl_TexCoord[] values from a vertex shader or the texture coordinates

-// of any fixed pipeline based vertex functionality.

-// 

-// Indices to the fragment shader gl_TexCoord array are as described above in the vertex shader

-// text.

-// 

-

-// 

-// The OpenGL Shading Language defines an assortment of built-in convenience functions for scalar

-// and vector operations. Many of these built-in functions can be used in more than one type

-// of shader, but some are intended to provide a direct mapping to hardware and so are available

-// only for a specific type of shader.

-// 

-// The built-in functions basically fall into three categories:

-// 

-// � They expose some necessary hardware functionality in a convenient way such as accessing

-//   a texture map. There is no way in the language for these functions to be emulated by a shader.

-// 

-// � They represent a trivial operation (clamp, mix, etc.) that is very simple for the user

-//   to write, but they are very common and may have direct hardware support. It is a very hard

-//   problem for the compiler to map expressions to complex assembler instructions.

-// 

-// � They represent an operation graphics hardware is likely to accelerate at some point. The

-//   trigonometry functions fall into this category.

-// 

-// Many of the functions are similar to the same named ones in common C libraries, but they support

-// vector input as well as the more traditional scalar input.

-// 

-// Applications should be encouraged to use the built-in functions rather than do the equivalent

-// computations in their own shader code since the built-in functions are assumed to be optimal

-// (e.g., perhaps supported directly in hardware).

-// 

-// User code can replace built-in functions with their own if they choose, by simply re-declaring

-// and defining the same name and argument list.

-// 

-

-// 

-// Texture Lookup Functions

-// 

-// Texture lookup functions are available to both vertex and fragment shaders. However, level

-// of detail is not computed by fixed functionality for vertex shaders, so there are some

-// differences in operation between vertex and fragment texture lookups. The functions in the table

-// below provide access to textures through samplers, as set up through the OpenGL API. Texture

-// properties such as size, pixel format, number of dimensions, filtering method, number of mip-map

-// levels, depth comparison, and so on are also defined by OpenGL API calls. Such properties are

-// taken into account as the texture is accessed via the built-in functions defined below.

-// 

-// If a non-shadow texture call is made to a sampler whose texture has depth comparisons enabled,

-// then results are undefined. If a shadow texture call is made to a sampler whose texture does not

-// have depth comparisions enabled, the results are also undefined.

-// 

-// In all functions below, the bias parameter is optional for fragment shaders. The bias parameter

-// is not accepted in a vertex shader. For a fragment shader, if bias is present, it is added to

-// the calculated level of detail prior to performing the texture access operation. If the bias

-// parameter is not provided, then the implementation automatically selects level of detail:

-// For a texture that is not mip-mapped, the texture is used directly. If it is mip-mapped and

-// running in a fragment shader, the LOD computed by the implementation is used to do the texture

-// lookup. If it is mip-mapped and running on the vertex shader, then the base texture is used.

-// 

-// The built-ins suffixed with �Lod� are allowed only in a vertex shader. For the �Lod� functions,

-// lod is directly used as the level of detail.

-// 

-

-// 

-// Use the texture coordinate coord to do a texture lookup in the 1D texture currently bound

-// to sampler. For the projective (�Proj�) versions, the texture coordinate coord.s is divided by

-// the last component of coord.

-// 

-// XXX

-vec4 texture1D (sampler1D sampler, float coord, float bias) {

-    return vec4 (0.0);

-}

-vec4 texture1DProj (sampler1D sampler, vec2 coord, float bias) {

-    return texture1D (sampler, coord.s / coord.t, bias);

-}

-vec4 texture1DProj (sampler1D sampler, vec4 coord, float bias) {

-    return texture1D (sampler, coord.s / coord.q, bias);

-}

-

-// 

-// Use the texture coordinate coord to do a texture lookup in the 2D texture currently bound

-// to sampler. For the projective (�Proj�) versions, the texture coordinate (coord.s, coord.t) is

-// divided by the last component of coord. The third component of coord is ignored for the vec4

-// coord variant.

-// 

-// XXX

-vec4 texture2D (sampler2D sampler, vec2 coord, float bias) {

-    return vec4 (0.0);

-}

-vec4 texture2DProj (sampler2D sampler, vec3 coord, float bias) {

-    return texture2D (sampler, vec2 (coord.s / coord.p, coord.t / coord.p), bias);

-}

-vec4 texture2DProj (sampler2D sampler, vec4 coord, float bias) {

-    return texture2D (sampler, vec2 (coord.s / coord.q, coord.s / coord.q), bias);

-}

-

-// 

-// Use the texture coordinate coord to do a texture lookup in the 3D texture currently bound

-// to sampler. For the projective (�Proj�) versions, the texture coordinate is divided by coord.q.

-// 

-// XXX

-vec4 texture3D (sampler3D sampler, vec3 coord, float bias) {

-    return vec4 (0.0);

-}   

-vec4 texture3DProj (sampler3D sampler, vec4 coord, float bias) {

-    return texture3DProj (sampler, vec3 (coord.s / coord.q, coord.t / coord.q, coord.p / coord.q),

-        bias);

-}

-

-// 

-// Use the texture coordinate coord to do a texture lookup in the cube map texture currently bound

-// to sampler. The direction of coord is used to select which face to do a 2-dimensional texture

-// lookup in, as described in section 3.8.6 in version 1.4 of the OpenGL specification.

-// 

-// XXX

-vec4 textureCube (samplerCube sampler, vec3 coord, float bias) {

-    return vec4 (0.0);

-}

-

-// 

-// Use texture coordinate coord to do a depth comparison lookup on the depth texture bound

-// to sampler, as described in section 3.8.14 of version 1.4 of the OpenGL specification. The 3rd

-// 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. For the projective (�Proj�) version of each built-in,

-// the texture coordinate is divide by coord.q, giving a depth value R of coord.p/coord.q. The

-// second component of coord is ignored for the �1D� variants.

-// 

-// XXX

-vec4 shadow1D (sampler1DShadow sampler, vec3 coord, float bias) {

-    return vec4 (0.0);

-}

-// XXX

-vec4 shadow2D (sampler2DShadow sampler, vec3 coord, float bias) {

-    return vec4 (0.0);

-}

-vec4 shadow1DProj (sampler1DShadow sampler, vec4 coord, float bias) {

-    return shadow1D (sampler, vec3 (coord.s / coord.q, 0.0, coord.p / coord.q), bias);

-}

-vec4 shadow2DProj (sampler2DShadow sampler, vec4 coord, float bias) {

-    return shadow2D (sampler, vec3 (coord.s / coord.q, coord.t / coord.q, coord.p / coord.q), bias);

-}

-

-// 

-// Fragment processing functions are only available in shaders intended for use on the fragment

-// processor. Derivatives may be computationally expensive and/or numerically unstable. Therefore,

-// an OpenGL implementation may approximate the true derivatives by using a fast but not entirely

-// accurate derivative computation.

-// 

-// The expected behavior of a derivative is specified using forward/backward differencing.

-// 

-// Forward differencing:

-// 

-// F(x+dx) - F(x) ~ dFdx(x) * dx            1a

-// dFdx(x) ~ (F(x+dx) - F(x)) / dx          1b

-// 

-// Backward differencing:

-// 

-// F(x-dx) - F(x) ~ -dFdx(x) * dx           2a

-// dFdx(x) ~ (F(x) - F(x-dx)) / dx          2b

-// 

-// With single-sample rasterization, dx <= 1.0 in equations 1b and 2b. For multi-sample

-// rasterization, dx < 2.0 in equations 1b and 2b.

-// 

-// dFdy is approximated similarly, with y replacing x.

-// 

-// A GL implementation may use the above or other methods to perform the calculation, subject

-// to the following conditions:

-// 

-// 1) The method may use piecewise linear approximations. Such linear approximations imply that

-//    higher order derivatives, dFdx(dFdx(x)) and above, are undefined.

-// 

-// 2) The method may assume that the function evaluated is continuous. Therefore derivatives within

-//    the body of a non-uniform conditional are undefined.

-// 

-// 3) The method may differ per fragment, subject to the constraint that the method may vary by

-//    window coordinates, not screen coordinates. The invariance requirement described in section

-//    3.1 of the OpenGL 1.4 specification is relaxed for derivative calculations, because

-//    the method may be a function of fragment location.

-// 

-// Other properties that are desirable, but not required, are:

-// 

-// 4) Functions should be evaluated within the interior of a primitive (interpolated, not

-//    extrapolated).

-// 

-// 5) Functions for dFdx should be evaluated while holding y constant. Functions for dFdy should

-//    be evaluated while holding x constant. However, mixed higher order derivatives, like

-//    dFdx(dFdy(y)) and dFdy(dFdx(x)) are undefined.

-// 

-// In some implementations, varying degrees of derivative accuracy may be obtained by providing

-// GL hints (section 5.6 of the OpenGL 1.4 specification), allowing a user to make an image

-// quality versus speed tradeoff.

-// 

-

-// 

-// Returns the derivative in x using local differencing for the input argument p.

-// 

-// XXX

-float dFdx (float p) {

-    return 0.0;

-}

-// XXX

-vec2 dFdx (vec2 p) {

-    return vec2 (0.0);

-}

-// XXX

-vec3 dFdx (vec3 p) {

-    return vec3 (0.0);

-}

-// XXX

-vec4 dFdx (vec4 p) {

-    return vec4 (0.0);

-}

-

-// 

-// Returns the derivative in y using local differencing for the input argument p.

-// 

-// These two functions are commonly used to estimate the filter width used to anti-alias procedural

-// textures.We are assuming that the expression is being evaluated in parallel on a SIMD array so

-// that at any given point in time the value of the function is known at the grid points

-// represented by the SIMD array. Local differencing between SIMD array elements can therefore

-// be used to derive dFdx, dFdy, etc.

-// 

-// XXX

-float dFdy (float p) {

-    return 0.0;

-}

-// XXX

-vec2 dFdy (vec2 p) {

-    return vec2 (0.0);

-}

-// XXX

-vec3 dFdy (vec3 p) {

-    return vec3 (0.0);

-}

-// XXX

-vec4 dFdy (vec4 p) {

-    return vec4 (0.0);

-}

-

-// 

-// Returns the sum of the absolute derivative in x and y using local differencing for the input

-// argument p, i.e.:

-// 

-// return = abs (dFdx (p)) + abs (dFdy (p));

-// 

-

-float fwidth (float p) {

-    return abs (dFdx (p)) + abs (dFdy (p));

-}

-vec2 fwidth (vec2 p) {

-    return abs (dFdx (p)) + abs (dFdy (p));

-}

-vec3 fwidth (vec3 p) {

-    return abs (dFdx (p)) + abs (dFdy (p));

-}

-vec4 fwidth (vec4 p) {

-    return abs (dFdx (p)) + abs (dFdy (p));

-}

-

+
+// 
+// TODO:
+// - implement texture1D, texture2D, texture3D, textureCube,
+// - implement shadow1D, shadow2D,
+// - implement dFdx, dFdy,
+// 
+
+// 
+// From Shader Spec, ver. 1.10, rev. 59
+// 
+// The output of the fragment shader is processed by the fixed function operations at the back end
+// of the OpenGL pipeline. Fragment shaders output values to the OpenGL pipeline using the built-in
+// variables gl_FragColor, gl_FragData and gl_FragDepth, unless the discard keyword is executed.
+// 
+// These variables may be written more than once within a fragment shader. If so, the last value
+// assigned is the one used in the subsequent fixed function pipeline. The values written to these
+// variables may be read back after writing them. Reading from these variables before writing them
+// results in an undefined value. The fixed functionality computed depth for a fragment may be
+// obtained by reading gl_FragCoord.z, described below.
+// 
+// Writing to gl_FragColor specifies the fragment color that will be used by the subsequent fixed
+// functionality pipeline. If subsequent fixed functionality consumes fragment color and an
+// execution of a fragment shader does not write a value to gl_FragColor then the fragment color
+// consumed is undefined.
+// 
+// If the frame buffer is configured as a color index buffer then behavior is undefined when using
+// a fragment shader.
+// 
+// Writing to gl_FragDepth will establish the depth value for the fragment being processed. If
+// depth buffering is enabled, and a shader does not write gl_FragDepth, then the fixed function
+// value for depth will be used as the fragment�s depth value. If a shader statically assigns
+// a value to gl_FragDepth, and there is an execution path through the shader that does not set
+// gl_FragDepth, then the value of the fragment's depth may be undefined for executions of the
+// shader that take that path. That is, if a shader statically contains a write gl_FragDepth, then
+// it is responsible for always writing it.
+//
+// (A shader contains a static assignment to a variable x if, after pre-processing, the shader
+// contains statement that would write x, whether or not run-time flow of control will cause
+// that statement to be executed.)
+//
+// The variable gl_FragData is an array. Writing to gl_FragData[n] specifies the fragment data
+// that will be used by the subsequent fixed functionality pipeline for data n. If subsequent
+// fixed functionality consumes fragment data and an execution of a fragment shader does not
+// write a value to it, then the fragment data consumed is undefined.
+//
+// If a shader statically assigns a value to gl_FragColor, it may not assign a value to any element
+// of gl_FragData. If a shader statically writes a value to any element of gl_FragData, it may not
+// assign a value to gl_FragColor. That is, a shader may assign values to either gl_FragColor or
+// gl_FragData, but not both.
+// 
+// If a shader executes the discard keyword, the fragment is discarded, and the values of
+// gl_FragDepth, gl_FragColor and gl_FragData become irrelevant.
+// 
+// The variable gl_FragCoord is available as a read-only variable from within fragment shaders
+// and it holds the window relative coordinates x, y, z, and 1/w values for the fragment. This
+// value is the result of the fixed functionality that interpolates primitives after vertex
+// processing to generate fragments. The z component is the depth value that would be used for
+// the fragment�s depth if a shader contained no writes to gl_FragDepth. This is useful for
+// invariance if a shader conditionally computes gl_FragDepth but otherwise wants the fixed
+// functionality fragment depth.
+// 
+// The fragment shader has access to the read-only built-in variable gl_FrontFacing whose value
+// is true if the fragment belongs to a front-facing primitive. One use of this is to emulate
+// two-sided lighting by selecting one of two colors calculated by the vertex shader.
+// 
+// The built-in variables that are accessible from a fragment shader are intrinsically given types
+// as follows:
+// 
+
+vec4 gl_FragCoord;
+bool gl_FrontFacing;
+vec4 gl_FragColor;
+vec4 gl_FragData[gl_MaxDrawBuffers];
+float gl_FragDepth;
+
+// 
+// However, they do not behave like variables with no qualifier; their behavior is as described
+// above. These built-in variables have global scope.
+// 
+
+// 
+// Unlike user-defined varying variables, the built-in varying variables don�t have a strict
+// one-to-one correspondence between the vertex language and the fragment language. Two sets are
+// provided, one for each language. Their relationship is described below.
+// 
+// The following varying variables are available to read from in a fragment shader. The gl_Color
+// and gl_SecondaryColor names are the same names as attributes passed to the vertex shader.
+// However, there is no name conflict, because attributes are visible only in vertex shaders
+// and the following are only visible in a fragment shader.
+// 
+
+varying vec4 gl_Color;
+varying vec4 gl_SecondaryColor;
+varying vec4 gl_TexCoord[];                             // at most will be gl_MaxTextureCoords
+varying float gl_FogFragCoord;
+
+// 
+// The values in gl_Color and gl_SecondaryColor will be derived automatically by the system from
+// gl_FrontColor, gl_BackColor, gl_FrontSecondaryColor, and gl_BackSecondaryColor based on which
+// face is visible. If fixed functionality is used for vertex processing, then gl_FogFragCoord will
+// either be the z-coordinate of the fragment in eye space, or the interpolation of the fog
+// coordinate, as described in section 3.10 of the OpenGL 1.4 Specification. The gl_TexCoord[]
+// values are the interpolated gl_TexCoord[] values from a vertex shader or the texture coordinates
+// of any fixed pipeline based vertex functionality.
+// 
+// Indices to the fragment shader gl_TexCoord array are as described above in the vertex shader
+// text.
+// 
+
+// 
+// The OpenGL Shading Language defines an assortment of built-in convenience functions for scalar
+// and vector operations. Many of these built-in functions can be used in more than one type
+// of shader, but some are intended to provide a direct mapping to hardware and so are available
+// only for a specific type of shader.
+// 
+// The built-in functions basically fall into three categories:
+// 
+// � They expose some necessary hardware functionality in a convenient way such as accessing
+//   a texture map. There is no way in the language for these functions to be emulated by a shader.
+// 
+// � They represent a trivial operation (clamp, mix, etc.) that is very simple for the user
+//   to write, but they are very common and may have direct hardware support. It is a very hard
+//   problem for the compiler to map expressions to complex assembler instructions.
+// 
+// � They represent an operation graphics hardware is likely to accelerate at some point. The
+//   trigonometry functions fall into this category.
+// 
+// Many of the functions are similar to the same named ones in common C libraries, but they support
+// vector input as well as the more traditional scalar input.
+// 
+// Applications should be encouraged to use the built-in functions rather than do the equivalent
+// computations in their own shader code since the built-in functions are assumed to be optimal
+// (e.g., perhaps supported directly in hardware).
+// 
+// User code can replace built-in functions with their own if they choose, by simply re-declaring
+// and defining the same name and argument list.
+// 
+
+// 
+// 8.7 Texture Lookup Functions
+// 
+// Texture lookup functions are available to both vertex and fragment shaders. However, level
+// of detail is not computed by fixed functionality for vertex shaders, so there are some
+// differences in operation between vertex and fragment texture lookups. The functions in the table
+// below provide access to textures through samplers, as set up through the OpenGL API. Texture
+// properties such as size, pixel format, number of dimensions, filtering method, number of mip-map
+// levels, depth comparison, and so on are also defined by OpenGL API calls. Such properties are
+// taken into account as the texture is accessed via the built-in functions defined below.
+// 
+// If a non-shadow texture call is made to a sampler that represents a depth texture with depth
+// comparisons turned on, then results are undefined. If a shadow texture call is made to a sampler
+// that represents a depth texture with depth comparisions turned off, the results are undefined.
+// If a shadow texture call is made to a sampler that does not represent a depth texture, then
+// results are undefined.
+// 
+// In all functions below, the bias parameter is optional for fragment shaders. The bias parameter
+// is not accepted in a vertex shader. For a fragment shader, if bias is present, it is added to
+// the calculated level of detail prior to performing the texture access operation. If the bias
+// parameter is not provided, then the implementation automatically selects level of detail:
+// For a texture that is not mip-mapped, the texture is used directly. If it is mip-mapped and
+// running in a fragment shader, the LOD computed by the implementation is used to do the texture
+// lookup. If it is mip-mapped and running on the vertex shader, then the base texture is used.
+// 
+// The built-ins suffixed with �Lod� are allowed only in a vertex shader. For the �Lod� functions,
+// lod is directly used as the level of detail.
+// 
+
+// 
+// Use the texture coordinate coord to do a texture lookup in the 1D texture currently bound
+// to sampler. For the projective (�Proj�) versions, the texture coordinate coord.s is divided by
+// the last component of coord.
+// 
+// XXX
+vec4 texture1D (sampler1D sampler, float coord, float bias) {
+    return vec4 (0.0);
+}
+vec4 texture1DProj (sampler1D sampler, vec2 coord, float bias) {
+    return texture1D (sampler, coord.s / coord.t, bias);
+}
+vec4 texture1DProj (sampler1D sampler, vec4 coord, float bias) {
+    return texture1D (sampler, coord.s / coord.q, bias);
+}
+
+// 
+// Use the texture coordinate coord to do a texture lookup in the 2D texture currently bound
+// to sampler. For the projective (�Proj�) versions, the texture coordinate (coord.s, coord.t) is
+// divided by the last component of coord. The third component of coord is ignored for the vec4
+// coord variant.
+// 
+// XXX
+vec4 texture2D (sampler2D sampler, vec2 coord, float bias) {
+    return vec4 (0.0);
+}
+vec4 texture2DProj (sampler2D sampler, vec3 coord, float bias) {
+    return texture2D (sampler, vec2 (coord.s / coord.p, coord.t / coord.p), bias);
+}
+vec4 texture2DProj (sampler2D sampler, vec4 coord, float bias) {
+    return texture2D (sampler, vec2 (coord.s / coord.q, coord.s / coord.q), bias);
+}
+
+// 
+// Use the texture coordinate coord to do a texture lookup in the 3D texture currently bound
+// to sampler. For the projective (�Proj�) versions, the texture coordinate is divided by coord.q.
+// 
+// XXX
+vec4 texture3D (sampler3D sampler, vec3 coord, float bias) {
+    return vec4 (0.0);
+}   
+vec4 texture3DProj (sampler3D sampler, vec4 coord, float bias) {
+    return texture3DProj (sampler, vec3 (coord.s / coord.q, coord.t / coord.q, coord.p / coord.q),
+        bias);
+}
+
+// 
+// Use the texture coordinate coord to do a texture lookup in the cube map texture currently bound
+// to sampler. The direction of coord is used to select which face to do a 2-dimensional texture
+// lookup in, as described in section 3.8.6 in version 1.4 of the OpenGL specification.
+// 
+// XXX
+vec4 textureCube (samplerCube sampler, vec3 coord, float bias) {
+    return vec4 (0.0);
+}
+
+// 
+// Use texture coordinate coord to do a depth comparison lookup on the depth texture bound
+// to sampler, as described in section 3.8.14 of version 1.4 of the OpenGL specification. The 3rd
+// 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. For the projective (�Proj�) version of each built-in,
+// the texture coordinate is divide by coord.q, giving a depth value R of coord.p/coord.q. The
+// second component of coord is ignored for the �1D� variants.
+// 
+// XXX
+vec4 shadow1D (sampler1DShadow sampler, vec3 coord, float bias) {
+    return vec4 (0.0);
+}
+// XXX
+vec4 shadow2D (sampler2DShadow sampler, vec3 coord, float bias) {
+    return vec4 (0.0);
+}
+vec4 shadow1DProj (sampler1DShadow sampler, vec4 coord, float bias) {
+    return shadow1D (sampler, vec3 (coord.s / coord.q, 0.0, coord.p / coord.q), bias);
+}
+vec4 shadow2DProj (sampler2DShadow sampler, vec4 coord, float bias) {
+    return shadow2D (sampler, vec3 (coord.s / coord.q, coord.t / coord.q, coord.p / coord.q), bias);
+}
+
+//
+// 8.8 Fragment Processing Functions
+// 
+// Fragment processing functions are only available in shaders intended for use on the fragment
+// processor. Derivatives may be computationally expensive and/or numerically unstable. Therefore,
+// an OpenGL implementation may approximate the true derivatives by using a fast but not entirely
+// accurate derivative computation.
+// 
+// The expected behavior of a derivative is specified using forward/backward differencing.
+// 
+// Forward differencing:
+// 
+// F(x+dx) - F(x) ~ dFdx(x) * dx            1a
+// dFdx(x) ~ (F(x+dx) - F(x)) / dx          1b
+// 
+// Backward differencing:
+// 
+// F(x-dx) - F(x) ~ -dFdx(x) * dx           2a
+// dFdx(x) ~ (F(x) - F(x-dx)) / dx          2b
+// 
+// With single-sample rasterization, dx <= 1.0 in equations 1b and 2b. For multi-sample
+// rasterization, dx < 2.0 in equations 1b and 2b.
+// 
+// dFdy is approximated similarly, with y replacing x.
+// 
+// A GL implementation may use the above or other methods to perform the calculation, subject
+// to the following conditions:
+// 
+// 1) The method may use piecewise linear approximations. Such linear approximations imply that
+//    higher order derivatives, dFdx(dFdx(x)) and above, are undefined.
+// 
+// 2) The method may assume that the function evaluated is continuous. Therefore derivatives within
+//    the body of a non-uniform conditional are undefined.
+// 
+// 3) The method may differ per fragment, subject to the constraint that the method may vary by
+//    window coordinates, not screen coordinates. The invariance requirement described in section
+//    3.1 of the OpenGL 1.4 specification is relaxed for derivative calculations, because
+//    the method may be a function of fragment location.
+// 
+// Other properties that are desirable, but not required, are:
+// 
+// 4) Functions should be evaluated within the interior of a primitive (interpolated, not
+//    extrapolated).
+// 
+// 5) Functions for dFdx should be evaluated while holding y constant. Functions for dFdy should
+//    be evaluated while holding x constant. However, mixed higher order derivatives, like
+//    dFdx(dFdy(y)) and dFdy(dFdx(x)) are undefined.
+// 
+// In some implementations, varying degrees of derivative accuracy may be obtained by providing
+// GL hints (section 5.6 of the OpenGL 1.4 specification), allowing a user to make an image
+// quality versus speed tradeoff.
+// 
+
+// 
+// Returns the derivative in x using local differencing for the input argument p.
+// 
+// XXX
+float dFdx (float p) {
+    return 0.0;
+}
+// XXX
+vec2 dFdx (vec2 p) {
+    return vec2 (0.0);
+}
+// XXX
+vec3 dFdx (vec3 p) {
+    return vec3 (0.0);
+}
+// XXX
+vec4 dFdx (vec4 p) {
+    return vec4 (0.0);
+}
+
+// 
+// Returns the derivative in y using local differencing for the input argument p.
+// 
+// These two functions are commonly used to estimate the filter width used to anti-alias procedural
+// textures.We are assuming that the expression is being evaluated in parallel on a SIMD array so
+// that at any given point in time the value of the function is known at the grid points
+// represented by the SIMD array. Local differencing between SIMD array elements can therefore
+// be used to derive dFdx, dFdy, etc.
+// 
+// XXX
+float dFdy (float p) {
+    return 0.0;
+}
+// XXX
+vec2 dFdy (vec2 p) {
+    return vec2 (0.0);
+}
+// XXX
+vec3 dFdy (vec3 p) {
+    return vec3 (0.0);
+}
+// XXX
+vec4 dFdy (vec4 p) {
+    return vec4 (0.0);
+}
+
+// 
+// Returns the sum of the absolute derivative in x and y using local differencing for the input
+// argument p, i.e.:
+// 
+// return = abs (dFdx (p)) + abs (dFdy (p));
+// 
+
+float fwidth (float p) {
+    return abs (dFdx (p)) + abs (dFdy (p));
+}
+vec2 fwidth (vec2 p) {
+    return abs (dFdx (p)) + abs (dFdy (p));
+}
+vec3 fwidth (vec3 p) {
+    return abs (dFdx (p)) + abs (dFdy (p));
+}
+vec4 fwidth (vec4 p) {
+    return abs (dFdx (p)) + abs (dFdy (p));
+}
+