Google Git
Sign in
skia / external / github.com / KhronosGroup / OpenGL-Registry / bc93187978b46e0baae0b8556071d6b292b0bb97 / . / extensions / NV / NV_texture_shader.txt
blob: 478a144ca70741896eefe8d544bb770d65c5cd0c [file] [log] [blame]
Name
NV_texture_shader
Name Strings
GL_NV_texture_shader
Contact
Mark J. Kilgard, NVIDIA Corporation (mjk 'at' nvidia.com)
Notice
Copyright NVIDIA Corporation, 1999, 2000, 2001, 2002, 2004.
IP Status
NVIDIA Proprietary.
Status
Shipping (since GeForce3)
Version
NVIDIA Date: March 13, 2007
Version: 30
Number
230
Dependencies
Written based on the wording of the OpenGL 1.2.1 specification.
Requires support for the ARB_multitexture extension.
Requires support for the ARB_texture_cube_map extension.
NV_register_combiners affects the definition of this extension.
EXT_texture_lod_bias trivially affects the definition of this
extension.
ARB_texture_env_combine and/or EXT_texture_env_combine affect the
definition of this extension.
NV_texture_env_combine4 affects the definition of this extension.
ARB_texture_env_add and/or EXT_texture_env_add affect the definition
of this extension.
NV_texture_rectangle affects the definition of this extension.
NV_texture_shader2 depends on the definition of this extension.
ARB_color_buffer_float affects the definiton of this extension.
Overview
Standard OpenGL and the ARB_multitexture extension define a
straightforward direct mechanism for mapping sets of texture
coordinates to filtered colors. This extension provides a more
functional mechanism.
OpenGL's standard texturing mechanism defines a set of texture
targets. Each texture target defines how the texture image
is specified and accessed via a set of texture coordinates.
OpenGL 1.0 defines the 1D and 2D texture targets. OpenGL 1.2
(and/or the EXT_texture3D extension) defines the 3D texture target.
The ARB_texture_cube_map extension defines the cube map texture
target. Each texture unit's texture coordinate set is mapped to a
color using the unit's highest priority enabled texture target.
This extension introduces texture shader stages. A sequence of
texture shader stages provides a more flexible mechanism for mapping
sets of texture coordinates to texture unit RGBA results than standard
OpenGL.
When the texture shader enable is on, the extension replaces the
conventional OpenGL mechanism for mapping sets of texture coordinates
to filtered colors with this extension's sequence of texture shader
stages.
Each texture shader stage runs one of 21 canned texture shader
programs. These programs support conventional OpenGL texture
mapping but also support dependent texture accesses, dot product
texture programs, and special modes. (3D texture mapping
texture shader operations are NOT provided by this extension;
3D texture mapping texture shader operations are added by the
NV_texture_shader2 extension that is layered on this extension.
See the NV_texture_shader2 specification.)
To facilitate the new texture shader programs, this extension
introduces several new texture formats and variations on existing
formats. Existing color texture formats are extended by introducing
new signed variants. Two new types of texture formats (beyond colors)
are also introduced. Texture offset groups encode two signed offsets,
and optionally a magnitude or a magnitude and an intensity. The new
HILO (pronounced high-low) formats provide possibly signed, high
precision (16-bit) two-component textures.
Each program takes as input the stage's interpolated texture
coordinate set (s,t,r,q). Each program generates two results:
a shader stage result that may be used as an input to subsequent
shader stage programs, and a texture unit RGBA result that becomes the
texture color used by the texture unit's texture environment function
or becomes the initial value for the corresponding texture register
for register combiners. The texture unit RGBA result is always
an RGBA color, but the shader stage result may be one of an RGBA
color, a HILO value, a texture offset group, a floating-point value,
or an invalid result. When both results are RGBA colors, the shader
stage result and the texture unit RGBA result are usually identical
(though not in all cases).
Additionally, certain programs have a side-effect such as culling
the fragment or replacing the fragment's depth value.
The twenty-one programs are briefly described:
<none>
1. NONE - Always generates a (0,0,0,0) texture unit RGBA result.
Equivalent to disabling all texture targets in conventional
OpenGL.
<conventional textures>
2. TEXTURE_1D - Accesses a 1D texture via (s/q).
3. TEXTURE_2D - Accesses a 2D texture via (s/q,t/q).
4. TEXTURE_RECTANGLE_NV - Accesses a rectangular texture via (s/q,t/q).
5. TEXTURE_CUBE_MAP_ARB - Accesses a cube map texture via (s,t,r).
<special modes>
6. PASS_THROUGH_NV - Converts a texture coordinate (s,t,r,q)
directly to a [0,1] clamped (r,g,b,a) texture unit RGBA result.
7. CULL_FRAGMENT_NV - Culls the fragment based on the whether each
(s,t,r,q) is "greater than or equal to zero" or "less than zero".
<offset textures>
8. OFFSET_TEXTURE_2D_NV - Transforms the signed (ds,dt) components
of a previous texture unit by a 2x2 floating-point matrix and
then uses the result to offset the stage's texture coordinates
for a 2D non-projective texture.
9. OFFSET_TEXTURE_2D_SCALE_NV - Same as above except the magnitude
component of the previous texture unit result scales the red,
green, and blue components of the unsigned RGBA texture 2D
access.
10. OFFSET_TEXTURE_RECTANGLE_NV - Similar to OFFSET_TEXTURE_2D_NV
except that the texture access is into a rectangular
non-projective texture.
11. OFFSET_TEXTURE_RECTANGLE_SCALE_NV - Similar to
OFFSET_TEXTURE_2D_SCALE_NV except that the texture access is
into a rectangular non-projective texture.
<dependent textures>
12. DEPENDENT_AR_TEXTURE_2D_NV - Converts the alpha and red
components of a previous shader result into an (s,t) texture
coordinate set to access a 2D non-projective texture.
13. DEPENDENT_GB_TEXTURE_2D_NV - Converts the green and blue
components of a previous shader result into an (s,t) texture
coordinate set to access a 2D non-projective texture.
<dot product textures>
14. DOT_PRODUCT_NV - Computes the dot product of the texture
shader's texture coordinate set (s,t,r) with some mapping of the
components of a previous texture shader result. The component
mapping depends on the type (RGBA or HILO) and signedness of
the stage's previous texture input. Other dot product texture
programs use the result of this program to compose a texture
coordinate set for a dependent texture access. The color result
is undefined.
15. DOT_PRODUCT_TEXTURE_2D_NV - When preceded by a DOT_PRODUCT_NV
program in the previous texture shader stage, computes a second
similar dot product and composes the two dot products into (s,t)
texture coordinate set to access a 2D non-projective texture.
16. DOT_PRODUCT_TEXTURE_RECTANGLE_NV - Similar to
DOT_PRODUCT_TEXTURE_2D_NV except that the texture acces is into
a rectangular non-projective texture.
17. DOT_PRODUCT_TEXTURE_CUBE_MAP_NV - When preceded by two
DOT_PRODUCT_NV programs in the previous two texture shader
stages, computes a third similar dot product and composes the
three dot products into (s,t,r) texture coordinate set to access
a cube map texture.
18. DOT_PRODUCT_REFLECT_CUBE_MAP_NV - When preceded by two
DOT_PRODUCT_NV programs in the previous two texture shader
stages, computes a third similar dot product and composes the
three dot products into a normal vector (Nx,Ny,Nz). An eye
vector (Ex,Ey,Ez) is composed from the q texture coordinates of
the three stages. A reflection vector (Rx,Ry,Rz) is computed
based on the normal and eye vectors. The reflection vector
forms an (s,t,r) texture coordinate set to access a cube map
texture.
19. DOT_PRODUCT_CONST_EYE_REFLECT_CUBE_MAP_NV - Operates like
DOT_PRODUCT_REFLECT_CUBE_MAP_NV except that the eye vector
(Ex,Ey,Ez) is a user-defined constant rather than composed from
the q coordinates of the three stages.
20. DOT_PRODUCT_DIFFUSE_CUBE_MAP_NV - When used instead of the second
DOT_PRODUCT_NV program preceding
a DOT_PRODUCT_REFLECT_CUBE_MAP_NV or
DOT_PRODUCT_CONST_EYE_REFLECT_CUBE_MAP_NV stage, the normal
vector forms an (s,t,r) texture coordinate set to access a
cube map texture.
<dot product depth replace>
21. DOT_PRODUCT_DEPTH_REPLACE_NV - When preceded by a DOT_PRODUCT_NV
program in the previous texture shader stage, computes a second
similar dot product and replaces the fragment's window-space
depth value with the first dot product results divided by
the second. The texture unit RGBA result is (0,0,0,0).
Issues
What should this extension be called? How does the functionality
compare with DirectX 8's pixel shaders?
RESOLUTION: This extension is called NV_texture_shader.
DirectX 8 refers to its similar functionality as "pixel shaders".
However, DirectX 8 lumps both the functionality described in this
extension and additional functionality similar to the functionality
in the NV_register_combiners extension together into what DirectX
8 calls pixel shaders. This is confusing in two ways.
1) Pixels are not being shaded. In fact, the DirectX 8 pixel
shaders functionality is, taken as a whole, shading only
fragments (though Direct3D tends not to make the same
clear distinction between fragments and pixels that OpenGL
consistently makes).
2) There are two very distinct tasks being performed.
First, there is the task of interpolated texture coordinate
mapping. This per-fragment task maps from interpolated
floating-point texture coordinate sets to (typically
fixed-point) texture unit RGBA results. In conventional OpenGL,
this mapping is performed by accessing the highest priority
enabled texture target using the fragment's corresponding
interpolated texture coordinate set. This NV_texture_shader
extension provides a significantly more powerful mechanism
for performing this mapping.
Second, there is the task of fragment coloring. Fragment
coloring is process of combining (typically fixed-point) RGBA
colors to generate a final fragment color that, assuming the
fragment is not discarded by subsequent per-fragment tests,
is used to update the fragment's corresponding pixel in the
frame buffer. In conventional OpenGL, fragment coloring is
performed by the enabled texture environment functions, fog, and
color sum operations. NVIDIA's register combiners functionality
(see the NV_register_combiners and NV_register_combiners2
extensions) provides a substantially more powerful alternative
to conventional OpenGL fragment coloring.
DirectX 8 has two types of opcodes for pixel shaders. Texture
address opcodes correspond to the first task listed above. Texture
register opcodes correspond to the second task listed above.
NVIDIA OpenGL extensions maintain a clear distinction between
these two tasks. The texture shaders functionality described in
this specification corresponds to the first task listed above.
Here is the conceptual framework that NVIDIA OpenGL extensions use
to describe shading: Shading is the process of assigning colors
to pixels, fragments, or texels. The texture shaders functionality
assigns colors to texture unit results (essentially texture
shading). These texture unit RGBA results can be used by fragment
coloring (fragment shading). The resulting fragments are used to
update pixels (pixel shading) possibly via blending and/or multiple
rendering passes.
The goal of these individual shading operations is per-pixel
shading. Per-pixel shading is accomplished by combining the
texture shading, fragment shading, and pixel shading operations,
possibly with multiple rendering passes.
Programmable shading is a style of per-pixel shading where the
shading operations are expressed in a higher level of abstraction
than "raw" OpenGL texture, fragment, and pixel shading operations.
In our view, programmable shading does not necessarily require a
"pixel program" to be downloaded and executed per-pixel by graphics
hardware. Indeed, there are many disadvantages to such an approach
in practice. An alternative view of programmable shading (the
one that we are promoting) treats the OpenGL primitive shading
operations as a SIMD machine and decomposes per-pixel shading
programs into one or more OpenGL rendering passes that map to "raw"
OpenGL shading operations. We believe that conventional OpenGL
combined with NV_register_combiners and NV_texture_shader (and
further augmented by programmable geometry via NV_vertex_program
and higher-order surfaces via NV_evaluators) can become the hardware
basis for a powerful programmable shading system.
The roughly equivalent functionality to DirectX 8's pixel
shaders in OpenGL is the combination of NV_texture_shader with
NV_register_combiners.
Is anyone working on programmable shading using the NV_texture_shader
functionality?
Yes. The Stanford Shading Group is actively working on
support for programmable shading using NV_texture_shader,
NV_register_combiners, and other extensions as the hardware basis
for such a system.
What terms are important to this specification?
texture shaders - A series of texture shader stages that map texture
coordinate sets to texture unit RGBA results. An alternative to
conventional OpenGL texturing.
texture coordinate set - The interpolated (s,t,r,q) value for a
particular texture unit of a particular fragment.
conventional OpenGL texturing - The conventional mechanism used by
OpenGL to map texture coordinate sets to texture unit RGBA results
whereby a given texture unit's texture coordinate set is used to
access the highest priority enabled texture target to generate
the texture unit's RGBA result. Conventional OpenGL texturing
supports 1D, 2D, 3D, and cube map texture targets. In conventional
OpenGL texturing each texture unit operates independently.
texture target type - One of the four texture target types: 1D, 2D,
3D, and cube map. (Note that NV_texture_shader does NOT provide
support for 3D textures; the NV_texture_shader2 extension adds
texture shader operations for 3D texture targets.)
texture internal format - The internal format of a particular
texture object. For example, GL_RGBA8, GL_SIGNED_RGBA8, or
GL_SIGNED_HILO16_NV.
texture format type - One of the three texture format types: RGBA,
HILO, or texture offset group.
texture component signedness - Whether or not a given component
of a texture's texture internal format is signed or not.
Signed components are clamped to the range [-1,1] while unsigned
components are clamped to the range [0,1].
texture shader enable - The OpenGL enable that determines whether
the texture shader functionality (if enabled) or conventional
OpenGL texturing functionality (if disabled) is used to map texture
coordinate sets to texture unit RGBA results. The enable's initial
state is disabled.
texture shader stage - Each texture unit has a corresponding texture
shader stage that can be loaded with one of 21 texture shader
operations. Depending on the stage's texture shader operation,
a texture shader stage uses the texture unit's corresponding
texture coordinate set and other state including the texture shader
results of previous texture shader stages to generate the stage's
particular texture shader result and texture unit RGBA result.
texture unit RGBA result - A (typically fixed-point) color result
generated by either a texture shader or conventional OpenGL
texturing. This is the color that becomes the texture unit's
texture environment function texture input or the initial value
of the texture unit's corresponding texture register in the case
of register combiners.
texture shader result - The result of a texture shader stage that
may be used as an input to a subsequent texture shader stage.
This result is distinct from the texture unit RGBA result.
The texture shader result may be one of four types: an RGBA
color value, a HILO value, a texture offset group value, or a
floating-point value. A few texture shader operations are defined
to always generate an invalid texture shader result.
texture shader result type - One of the four texture shader result
types: RGBA color, HILO, texture offset group, or floating-point.
texture shader operation - One of 21 fixed programs that maps a
texture unit's texture coordinate set to a texture shader result
and a texture unit RGBA result.
texture consistency - Whether or not the texture object for a
given texture target is consistent. The rules for determining
consistency depend on the texture target and the texture object's
filtering state. For example, a mipmapped texture is inconsistent
if its texture levels do not form a consistent mipmap pyramid.
Also, a cube map texture is inconsistent if its (filterable)
matching cube map faces do not have matching dimensions.
texture shader stage consistency - Whether or not a texture
shader stage is consistent or not. The rules for determining
texture shader stage consistency depend on the texture shader
stage operation and the inputs upon which the texture shader
operation depends. For example, texture shader operations that
depend on accessing a given texture target are not consistent
if the given texture target is not consistent. Also, a texture
shader operation that depends on a particular texture shader
result type for a previous texture shader result is not consistent
if the previous texture shader result type is not appropriate
or the previous texture shader stage itself is not consistent.
If a texture shader stage is not consistent, it operates as if
the operation is the GL_NONE operation.
previous texture input - Some texture shader operations depend
on a texture shader result from a specific previous texture input
designated by the GL_PREVIOUS_TEXTURE_INPUT_NV state.
What should the default state be?
RESOLUTION: Texture shaders disabled with all stages set to GL_NONE.
How is the mipmap lambda parameter computed for dependent texture fetches?
RESOLUTION: Very carefully. NVIDIA's implementation details are
NVIDIA proprietary, but mipmapping of dependent texture fetches
is supported.
Does this extension support so-called "bump environment mapping"?
Something similar to DirectX 6 so-called bump environment mapping
can be emulated with the GL_OFFSET_TEXTURE_2D_NV texture shader.
A more correct form of bump environment mapping can be implemented
by using the following texture shaders:
texture unit 0: GL_TEXTURE_2D
texture unit 1: GL_DOT_PRODUCT_NV
texture unit 2: GL_DOT_PRODUCT_DIFFUSE_CUBE_MAP_NV
texture unit 3: GL_DOT_PRODUCT_REFLECT_CUBE_MAP_NV
Texture unit 0 should use a normal map for its 2D texture.
A GL_SIGNED_RGB texture can encode signed tangent-space normal
perturbations. Or for more precision, a GL_SIGNED_HILO_NV texture
can encode the normal perturbations in hemisphere fashion.
The tangent (Tx,Ty,Tz), binormal (Bx,By,Bz), and normal (Nx,Ny,Nz)
that together map tangent-space normals to cube map-space normals
should be sent as texture coordinates s1, t1, r1, s2, t2, r2, s3,
t3, and r3 respectively. Typically, cube map space is aligned to
match world space.
The (unnormalized) cube map-space eye vector (Ex,Ey,Ez) should be
sent as texture coordinates q1, q2, and q3 respectively.
A vertex programs (using the NV_vertex_program extension) can
compute and assign the required tangent, binormal, normal, and
eye vectors to the appropriate texture coordinates. Conventional
OpenGL evaluators (or the NV_evaluators extension) can be used to
evaluate the tangent and normal automatically for Bezier patches.
The binormal is the cross product of the normal and tangent.
Texture units 1, 2, and 3, should also all specify GL_TEXTURE0_ARB
(the texture unit accessing the normal map) for their
GL_PREVIOUS_TEXTURE_INPUT_NV parameter.
The three dot product texture shader operations performed by the
texture shaders for texture units 1, 2, and 3 form a 3x3 matrix
that transforms the tangent-space normal (the result of the texture
shader for texture unit 0). This rotates the tangent-space normal
into a cube map-space.
Texture unit 2's cube map texture should encode a pre-computed
diffuse lighting solution. Texture unit 3's cube map texture should
encode a pre-computed specular lighting solution. The specular
lighting solution can be an environment map.
Texture unit 2 is accessed using the cube map-space normal
vector resulting from the three dot product results
of the texture shaders for texture units 1, 2, and 3.
(While normally texture shader operations are executed
in order, preceding GL_DOT_PRODUCT_REFLECT_CUBE_MAP_NV by
GL_DOT_PRODUCT_DIFFUSE_CUBE_MAP_NV is a special case where a dot
product result from texture unit 3 influences the cube map access
of texture unit 2.)
Texture unit 3 is accessed using the cube map-space reflection
vector computed using the cube map-space normal vector from the
three dot product results of the texture shaders for texture units
1, 2, and 3 and the cube-map space eye-vector (q1,q2,q3).
Note that using cube maps to access the diffuse and specular
illumination obviates the need for an explicit normalization of
the typically unnormalized cube map-space normal and reflection
vectors.
The register combiners (using the NV_register_combiners extension)
can combine the diffuse and specular contribution available in
the GL_TEXTURE2_ARB and GL_TEXTURE3_ARB registers respectively.
A constant ambient contribution can be stored in a register combiner
constant. The ambient contribution could also be folded into the
diffuse cube map.
If desired, the diffuse and ambient contribution can be modulated
by a diffuse material parameter encoded in the RGB components of
the primary color.
If desired, the specular contribution can be modulated by a specular
material parameter encoded in the RGB components of the secondary
color.
Yes, this is all quite complicated, but the result is a true
bump environment mapping technique with excellent accounting for
normalization and per-vertex interpolated diffuse and specular
materials. An environment and/or an arbitrary number of distant
or infinite lights can be encoded into the diffuse and specular
cube maps.
Why must GL_DOT_PRODUCT_DIFFUSE_CUBE_MAP_NV be used only in
conjunction with GL_DOT_PRODUCT_REFLECT_CUBE_MAP_NV? Why does the
GL_DOT_PRODUCT_DIFFUSE_CUBE_MAP_NV stage rely on a result computed
in the following stage?
Think of the GL_DOT_PRODUCT_DIFFUSE_CUBE_MAP_NV and
GL_DOT_PRODUCT_REFLECT_CUBE_MAP_NV operations as forming a compound
operation. The idea is to generate two cube map accesses based
on a perturbed normal and reflection vector where the reflection
vector is a function of the perturbed normal vector. To minimize
the number of stages (three stages only) and reuse the internal
computations involved, this is treated as a compound operation.
Note that the GL_DOT_PRODUCT_REFLECT_CUBE_MAP_NV
vector can be preceded by two GL_DOT_PRODUCT_NV
operations instead of a GL_DOT_PRODUCT_NV operation then a
GL_DOT_PRODUCT_DIFFUSE_CUBE_MAP_NV operation. This may be more
efficient when only the cube map access using the reflection vector
is required (a shiny object without any diffuse reflectance).
Also note that if only the diffuse reflectance cube map
access is required, this can be accomplished by simply using
the GL_DOT_PRODUCT_CUBE_MAP_NV operation preceded by two
GL_DOT_PRODUCT_NV operations.
How do texture shader stages map to register combiner texture registers?
RESOLUTION: If GL_TEXTURE_SHADER_NV is enabled, the texture unit
RGBA result for a each texture stage is used to initialize the
respective texture register in the register combiners.
So if a texture shader generates a texture unit RGBA result for
texture unit 2, use GL_TEXTURE2_ARB for the name of the register
value in register combiners.
Should the number of shader stages be settable?
RESOLUTION: No, unused stages can be set to GL_NONE.
How do signed RGBA texture components show up in the register
combiners texture registers?
RESOLUTION: As signed values. You can use GL_SIGNED_IDENTITY_NV
and get to the signed value directly.
How does the texture unit RGBA result of a
GL_NONE, GL_CULL_FRAGMENT_NV, DOT_PRODUCT_NV, or
GL_DOT_PRODUCT_DEPTH_REPLACE_NV texture shader operation show up in
the register combiners texture registers?
RESOLUTION: Always as the value (0,0,0,0).
How the texture RGBA result of the GL_NONE, GL_CULL_FRAGMENT_NV,
GL_DOT_PRODUCT_NV, and GL_DOT_PRODUCT_DEPTH_REPLACE_NV texture
shader operations shows up in the texture environment is not
an issue, because the texture environment operation is always
assumed to be GL_NONE when the corresponding texture shader
is one of GL_NONE, GL_CULL_FRAGMENT_NV, GL_DOT_PRODUCT_NV, or
GL_DOT_PRODUCT_DEPTH_REPLACE_NV when GL_TEXTURE_SHADER_NV is
enabled.
Why introduce new pixel groups (the HILO and texture offset groups)?
RESOLUTION: In core OpenGL, texture image data is transferred and
stored as sets of color components. Such color data can always
be promoted to RGBA data.
In addition to color components, there are other types of image
data in OpenGL including depth components, stencil components,
and color indices. Depth and stencil components can be used by
glReadPixels, glDrawPixels, and glCopyPixels, but are not useful
for storing texture data in core OpenGL. The EXT_paletted_texture
and EXT_index_texture extensions extend the contents of textures to
include indices (even though in the case of EXT_paletted_texture,
texel fetches are always eventually expanded into color components
by the texture palette).
However this these existing pixel groups are not sufficient for
all the texture shader operations introduced by this extension.
Certain texture shader operations require texture data that
is not merely a set of color components. The dot product
(GL_DOT_PRODUCT_NV, etc) operations both can
utilize high-precision hi and lo components. The
offset texture operations (GL_OFFSET_TEXTURE_2D_NV,
GL_OFFSET_TEXTURE_2D_SCALE_NV, GL_OFFSET_TEXTURE_RECTANGLE_NV,
and GL_OFFSET_TEXTURE_RECTANGLE_SCALE_NV) require
textures containing signed offsets used to displace
texture coordinates. The GL_OFFSET_TEXTURE_2D_SCALE_NV and
GL_OFFSET_TEXTURE_RECTANGLE_SCALE_NV also require an unsigned
magnitude for the scaling operation.
To facilitate these new texture representations, this extension
introduces several new (external) formats, pixel groups, and
internal texture formats. An (external) format is the external
representation used by an application to specify pixel data
for use by OpenGL. A pixel group is a grouping of components
that are transformed by OpenGL's pixel transfer mechanism is a
particular manner. For example, RGBA components for colors are
transformed differently than stencil components when passed through
OpenGL's pixel transfer mechanism. An internal texture format is
the representation of texture data within OpenGL. Note that the
(external) format used to specify the data by the application may
be different than the internal texture format used to store the
texture data internally to OpenGL. For example, core OpenGL permits
an application to specify data for a texture as GL_LUMINANCE_ALPHA
data stored in GLfloats even though the data is to be store in
a GL_RGBA8 texture. OpenGL's pixel unpacking and pixel transfer
operations perform an appropriate transformation of the data when
such a texture download is performed. Also note that data from
one pixel group (say stencil components) cannot be supplied as
data for a different pixel group (say RGBA components).
This extension introduces four new (external) formats for
texture data: GL_HILO_NV, GL_DSDT_NV, GL_DSDT_MAG_NV, and
GL_DSDT_MAG_VIB_NV.
GL_HILO_NV is for specifying high-precision hi and lo components.
The other three formats are used to specify texture offset groups.
These new formats can only be used for specifying textures (not
copying, reading, or writing pixels).
Each of these four pixel formats belong to one of two pixel groups.
Pixels specified with the GL_HILO_NV format are transformed as HILO
components. Pixels specified with the DSDT_NV, DSDT_MAG_NV, and
DSDT_MAG_VIB_NV formats are transformed as texture offset groups.
The HILO component and texture offset group pixel groups have
independent scale and bias operations for each component type.
Various pixel transfer operations that are performed on the RGBA
components pixel group are NOT performed on these two new pixel
groups. OpenGL's pixel map, color table, convolution, color matrix,
histogram, and min/max are NOT performed on the HILO components
or texture offset group pixel groups.
There are four internal texture formats for texture data specified
as HILO components: GL_HILO_NV, GL_HILO16_NV, GL_SIGNED_HILO_NV,
and GL_SIGNED_HILO16_NV. The HILO data can be stored as either
unsigned [0,1] value or [-1,1] signed values. There are also
enumerants for both explicitly sized component precision (16-bit
components) and unsized component precision. OpenGL implementations
are expected to keep HILO components are high precision even if
an unsized internal texture format is used.
The expectation with HILO textures is that applications will
specify HILO data using a type of GL_UNSIGNED_SHORT or GL_SHORT or
larger data types. Specifying HILO data with GL_UNSIGNED_BYTE or
GL_BYTE works but does not exploit the full available precision
of the HILO internal texture formats.
There are six internal texture formats for texture data
specified as texture offset groups: GL_DSDT_NV, GL_DSDT8_NV,
GL_DSDT_MAG_NV, GL_DSDT8_MAG8_NV, GL_DSDT_MAG_INTENSITY_NV and
GL_DSDT8_MAG8_INTENSITY8_NV. The GL_DSDT_NV formats specify two
signed [-1,1] components, ds and dt, used to offset s and t texture
coordinates. The GL_DSDT_MAG_NV formats specify an additional
third unsigned [0,1] component that is a magnitude to scale an
unsigned RGBA texture fetch by. The GL_DSDT_MAG_INTENSITY_NV
formats specify an additional fourth [0,1] unsigned component,
intensity, that becomes the intensity of the fetched texture for
use in the texture environment or register combiners. There are
also enumerants for both explicitly sized (8-bit components)
and unsized component precision.
Note that the vibrance (VIB) component of the
GL_DSDT_MAG_VIB_NV format becomes the intensity component of
the GL_DSDT_MAG_INTENSITY_NV internal texture format. Vibrance
becomes intensity in the GL_DSDT_MAG_INTENSITY_NV texture format.
The introduction of vibrance is because core OpenGL has no notion
of an intensity component in the pixel transfer mechanism or as
an external format (instead the red component of an RGBA value
becomes the intensity component of intensity textures).
How does the texture unit RGBA result of a texture shader that fetches
a texture with a base internal format of GL_HILO_NV, GL_DSDT_NV, or
GL_DSDT_MAG_NV show up in the register combiners texture registers?
RESOLUTION: Always as the value (0,0,0,0).
How the texture RGBA result of a texture shader that fetches a
texture with a base internal format of GL_HILO_NV, GL_DSDT_NV,
or GL_DSDT_MAG_NV the GL_DOT_PRODUCT_NV texture shader shows up
in the texture environment is not an issue, because the texture
environment operation is always assumed to be GL_NONE in this case
when GL_TEXTURE_SHADER_NV is enabled.
Does the GL_DOT_PRODUCT_DEPTH_REPLACE_NV program replace the
eye-distance Z or window-space depth?
RESOLUTION: Window-space depth. And if the window-space depth
value is outside of the near and far depth range values, the
fragment is rejected.
The GL_CULL_FRAGMENT_NV operation always compares against all four
texture coordinates. What if I want only one, two, or three
comparisons?
RESOLUTION: To compare against a single value, replicate that value
in all the coordinates and set the comparison for all components to
be identical. Or you can set uninteresting coordinates to zero and
use the GL_GEQUAL comparison which will never cull for the value zero.
What is GL_CULL_FRAGMENT_NV good for?
The GL_CULL_FRAGMENT_NV operation provides a mechanism to implement
per-fragment clip planes. If a texture coordinate is assigned a
signed distance to a plane, the cull fragment test can discard
fragments on the wrong side of the plane. Each texture shader
stage provides up to four such clip planes. An eye-space clip
plane can be established using the GL_EYE_LINEAR texture coordinate
generation mode where the clip plane equation is specified via
the GL_EYE_PLANE state.
Clip planes are one application for GL_CULL_FRAGMENT_NV, but
other clipping approaches are possible too. For example, by
computing and assigning appropriate texture coordinates (perhaps
with NV_vertex_program), fragments beyond a certain distance from
a point can be culled (assuming that it is acceptable to linearly
interpolate a distance between vertices).
The texture border color is supposed to be an RGBA value clamped to
the range [0,1]. How does the texture border color work in conjunction
with signed RGBA color components, HILO components, and texture offset
component groups?
RESOLUTION: The per-texture object GL_TEXTURE_BORDER_COLOR
is superceded by a GL_TEXTURE_BORDER_VALUES symbolic token.
The texture border values are four floats (not clamped to
[0,1] when specified). When a texture border is required for
a texture, the components for the border texel are determined
by the GL_TEXTURE_BORDER_VALUES state. For color components,
the GL_TEXTURE_BORDER_VALUES state is treated as a set of RGBA
color components. For HILO components, the first value is treated
as hi and the second value is treated as lo. For texture offset
components, the ds, dt, mag, and vib values correspond to the first,
second, third, and fourth texture border values respectively.
The particular texture border components are clamped to the range
of the component determined by the texture's internal format. So a
signed component is clamped to the [-1,1] range and an unsigned
component is clamped to the [0,1] range.
For backward compatibility, the GL_TEXTURE_BORDER_COLOR can
still be specified and queried. When specified, the values are
clamped to [0,1] and used to update the texture border values.
When GL_TEXTURE_BORDER_COLOR is queried, there is no clamping of
the returned values.
With signed texture components, does the texture environment function
discussion need to be amended?
RESOLUTION: Yes. We do not want texture environment results to
exceed the range [-1,1].
The GL_DECAL and GL_BLEND operations perform linear interpolations
of various components of the form
A * B + (1-A) * C
The value of A should not be allowed to be negative otherwise,
the value of (1-A) may exceed 1.0. These linear interpolations
should be written in the form
max(0,A) * B + (1-max(0,A)) * C
The GL_ADD operation clamps its result to 1.0, but if negative
components are permitted, the result should be clamped to the range
[-1,1].
The GL_COMBINE_ARB (and GL_COMBINE_EXT) and GL_COMBINE4_NV
operations do explicit clamping of all result to [0,1].
In addition, NV_texture_shader adds requirements to clamp
inputs to [0,1] too. This is because the GL_ONE_MINUS_SRC_COLOR
and GL_ONE_MINUS_SRC_ALPHA operands should really be computing
1-max(0,C). For completeness, GL_SRC_COLOR and GL_SRC_ALPHA should
be computing max(0,C).
With signed texture components, does the color sum discussion need
to be amended?
RESOLUTION: Yes. The primary and secondary color should both be
clamped to the range [0,1] before they are summed.
The unextended OpenGL 1.2 description of color sum does not
require a clamp of the primary and secondary colors to the [0,1]
range before they are summed. Before signed texture components,
the standard texture environment modes either could not generate
results outside the [0,1] range or explicitly clamped their
results to this range (as in the case of GL_ADD, GL_COMBINE_EXT,
and GL_COMBINE4_NV). Now with signed texture components, negative
values can be generated by texture environment functions.
We do not want to clamp the intermediate results of texture
environment stages since negative results may be useful in
subsequent stages, but clamping should be applied to the primary
color immediately before the color sum. For symmetry, clamping of
the secondary color is specified as well (though there is currently
no way to generate a negative secondary color).
Why vibrance?
Vibrance is the fourth component of the external representation of a
texture offset group. During pixel transfer, vibrance is scaled and
biased based on the GL_VIBRANCE_SCALE and GL_VIBRANCE_BIAS state.
Once transformed, the vibrance component becomes the intensity
component for textures with a DSDT_MAG_INTENSITY base internal
format. Vibrance is meaningful only when specifying texture images
with the DS_DT_MAG_VIB_NV external format (and is not supported
when reading, drawing, or copying pixels).
There are lots of reasons that a texture shader stage is inconsistent,
and in which case, the stage operates as if the operation is NONE.
For debugging sanity, is there a way to determine whether a particular
texture shader stage is consistent?
RESOLUTION: Yes. Query the shader consistency of a particular
texture unit with:
GLint consistent;
glActiveTextureARB(stage_to_check);
glGetTexEnviv(GL_TEXTURE_SHADER_NV, GL_SHADER_CONSISTENT_NV,
&consistent);
consistent is one or zero depending on whether the shader stage
is consistent or not.
Should there be signed components with sub 8-bit precision?
RESOLUTION: No.
Should packed pixel formats for texture offset groups be supported?
RESOLUTION: Yes, but they are limited to UNSIGNED_INT_S8_S8_8_8_NV
and UNSIGNED_INT_8_8_S8_S8_REV_NV for use with the DSDT_MAG_VIB_NV
format.
Note that these two new packed pixel formats are only for the
DSDT_MAG_VIB_NV and cannot be used with RGBA or BGRA formats.
Likewise, the RGBA and BGRA formats cannot be used with the new
UNSIGNED_INT_S8_S8_8_8_NV and UNSIGNED_INT_8_8_S8_S8_REV_NV types.
What should be said about signed fixed-point precision and range of
actual implementations?
RESOLUTION: The core OpenGL specification typically specifies
fixed-point numerical computations without regard to the specific
precision of the computations. This practice is intentional because
it permits implementations to vary in the degree of precision used
for internal OpenGL computations. When mapping unsigned fixed-point
values to a [0,1] range, the mapping is straightforward.
However, this extension supports signed texture components in
the range [-1,1]. This presents some awkward choices for how to
map [-1,1] to a fixed-point representation. Assuming a binary
fixed-point representation with an even distribution of precision,
there is no way to exactly represent -1, 0, and 1 and avoid
representing values outside the [-1,1] range.
This is not a unique issue for this extension. In core OpenGL,
table 2.6 describes mappings from unsigned integer types (GLbyte,
GLshort, and GLint) that preclude the exact specification of 0.0.
NV_register_combiners supports signed fixed-point values that have
similar representation issues.
NVIDIA's solution to this representation problem is to use 8-, 9-,
and 16-bit fixed-point representations for signed values in the
[-1,1] range such that
floating-point 8-bit fixed-point 9-bit fixed-point 16 bit fixed-point
-------------- ----------------- ----------------- ------------------
1.0 n/a 255 n/a
0.99996... n/a n/a 32767
0.99218... 127 n/a n/a
0.0 0 0 0
-1.0 -128 -255 -32768
-1.00392... n/a -256 n/a
The 8-bit and 16-bit signed fixed-point types are used for signed
internal texture formats, while the 9-bit signed fixed-point type
is used for register combiners computations.
The 9-bit signed fixed-point type has the disadvantage that a
number slightly more negative than -1 can be represented and this
particular value is different dependent on the number of bits of
fixed-point precision. The advantage of this approach is that 1,
0, and -1 can all be represented exactly.
The 8-bit and 16-bit signed fixed-point types have the disadvantage
that 1.0 cannot be exactly represented (though -1.0 and zero can
be exactly represented).
The specification however is written using the conventional
OpenGL practice (table 2.6) of mapping signed values evenly over
the range [-1,1] so that zero cannot be precisely represented.
This is done to keep this specification consistent with OpenGL's
existing conventions and to avoid the ugliness of specifying
a precision-dependent range. We expect leeway in how signed
fixed-point values are represented.
The spirit of this extension is that an implicit allowance is
made for signed fixed-point representations that cannot exactly
represent 1.0.
How should NV_texture_rectangle interact with NV_texture_shader?
NV_texture_rectangle introduces a new texture target similar
to GL_TEXTURE_2D but that supports non-power-of-two texture
dimensions and several usage restrictions (no mipmapping, etc).
Also the imaged texture coordinate range for rectangular textures
is [0,width]x[0,height] rather than [0,1]x[0,1].
Four texture shader operations will operate like their 2D texture
counter-parts, but will access the rectangular texture
target rather than the 2D texture target. These are:
GL_TEXTURE_RECTANGLE_NV
GL_OFFSET_TEXTURE_RECTANGLE_NV
GL_OFFSET_TEXTURE_RECTANGLE_SCALE_NV
GL_DOT_PRODUCT_TEXTURE_RECTANGLE_NV
A few 2D texture shader operations, namely
GL_DEPENDENT_AR_TEXTURE_2D_NV and GL_DEPENDENT_GB_TEXTURE_2D_NV,
do not support rectangular textures because turning colors in the
[0,1] range into texture coordinates would only access a single
corner texel in a rectangular texture. The offset and dot product
rectangular texture shader operations support scaling of the
dependent texture coordinates so these operations can access the
entire image of a rectangular texture. Note however that it is the
responsibility of the application to perform the proper scaling.
Note that the 2D and rectangular "offset texture" shaders both
use the same matrix, scale, and bias state.
Does the GL_DOT_PRODUCT_DEPTH_REPLACE_NV operation happen before or
after polygon offset?
RESOLUTION: After. The window Z (w_z) is computed during
rasterization and polygon offset occurs at this point. The depth
replace operation occurs after rasterization (at the point that
conventional OpenGL calls "texturing") so when the depth value
is replaced, the effect of polygon offset (and normal depth
interpolation) is lost when using the depth replace operation.
How does the GL_DOT_PRODUCT_DEPTH_REPLACE_NV operation interact with
ARB_multisample?
RESOLUTION: The depth value for all covered samples of a
multisampled fragment are replaced with the _same_ single depth
value computed by the depth replace operation. Without depth
replace, the depth values of each sample of a fragment may have
slightly different depth values because of the polygon's depth
gradient.
How should the clamping work for GL_OFFSET_TEXTURE_2D_SCALE?
RESOLUTION: The scale factor should be clamped to [0,1] prior
to scaling red, green, and blue.
Red, green, and blue are guaranteed to be unsigned RGB values
so the [0,1] scale factor times the [0,1] RGB values results in
[0,1] values so no output clamping need be specified.
New Procedures and Functions
None.
New Tokens
Accepted by the <cap> parameter of Enable, Disable, and IsEnabled,
and by the <pname> parameter of GetBooleanv, GetIntegerv, GetFloatv,
and GetDoublev, and by the <target> parameter of TexEnvf, TexEnvfv,
TexEnvi, TexEnviv, GetTexEnvfv, and GetTexEnviv:
TEXTURE_SHADER_NV 0x86DE
When the <target> parameter of TexEnvf, TexEnvfv, TexEnvi, TexEnviv,
GetTexEnvfv, and GetTexEnviv is TEXTURE_SHADER_NV, then the value
of <pname> may be:
RGBA_UNSIGNED_DOT_PRODUCT_MAPPING_NV 0x86D9
SHADER_OPERATION_NV 0x86DF
OFFSET_TEXTURE_SCALE_NV 0x86E2
OFFSET_TEXTURE_BIAS_NV 0x86E3
OFFSET_TEXTURE_2D_SCALE_NV alias for OFFSET_TEXTURE_SCALE_NV
OFFSET_TEXTURE_2D_BIAS_NV deprecated alias for OFFSET_TEXTURE_BIAS_NV
PREVIOUS_TEXTURE_INPUT_NV 0x86E4
When the <target> parameter of TexEnvfv, TexEnviv, GetTexEnvfv, and
GetTexEnviv is TEXTURE_SHADER_NV, then the value of <pname> may be:
CULL_MODES_NV 0x86E0
OFFSET_TEXTURE_MATRIX_NV 0x86E1
OFFSET_TEXTURE_2D_MATRIX_NV deprecated alias for OFFSET_TEXTURE_MATRIX_NV
CONST_EYE_NV 0x86E5
When the <target> parameter GetTexEnvfv and GetTexEnviv is
TEXTURE_SHADER_NV, then the value of <pname> may be:
SHADER_CONSISTENT_NV 0x86DD
When the <target> and <pname> parameters of TexEnvf, TexEnvfv,
TexEnvi, and TexEnviv are TEXTURE_ENV and TEXTURE_ENV_MODE
respectively, then the value of <param> or the value pointed to by
<params> may be:
NONE
When the <target> and <pname> parameters of TexEnvf, TexEnvfv,
TexEnvi, and TexEnviv are TEXTURE_SHADER_NV and SHADER_OPERATION_NV
respectively, then the value of <param> or the value pointed to by
<params> may be:
NONE
TEXTURE_1D
TEXTURE_2D
TEXTURE_RECTANGLE_NV (see NV_texture_rectangle)
TEXTURE_CUBE_MAP_ARB (see ARB_texture_cube_map)
PASS_THROUGH_NV 0x86E6
CULL_FRAGMENT_NV 0x86E7
OFFSET_TEXTURE_2D_NV 0x86E8
OFFSET_TEXTURE_2D_SCALE_NV see above, note aliasing
OFFSET_TEXTURE_RECTANGLE_NV 0x864C
OFFSET_TEXTURE_RECTANGLE_SCALE_NV 0x864D
DEPENDENT_AR_TEXTURE_2D_NV 0x86E9
DEPENDENT_GB_TEXTURE_2D_NV 0x86EA
DOT_PRODUCT_NV 0x86EC
DOT_PRODUCT_DEPTH_REPLACE_NV 0x86ED
DOT_PRODUCT_TEXTURE_2D_NV 0x86EE
DOT_PRODUCT_TEXTURE_RECTANGLE_NV 0x864E
DOT_PRODUCT_TEXTURE_CUBE_MAP_NV 0x86F0
DOT_PRODUCT_DIFFUSE_CUBE_MAP_NV 0x86F1
DOT_PRODUCT_REFLECT_CUBE_MAP_NV 0x86F2
DOT_PRODUCT_CONST_EYE_REFLECT_CUBE_MAP_NV 0x86F3
When the <target> and <pname> parameters of TexEnvfv and TexEnviv
are TEXTURE_SHADER_NV and CULL_MODES_NV respectively, then the value
of <param> or the value pointed to by <params> may be:
LESS
GEQUAL
When the <target> and <pname> parameters of TexEnvf,
TexEnvfv, TexEnvi, and TexEnviv are TEXTURE_SHADER_NV and
RGBA_UNSIGNED_DOT_PRODUCT_MAPPING_NV respectively, then the value
of <param> or the value pointed to by <params> may be:
UNSIGNED_IDENTITY_NV (see NV_register_combiners)
EXPAND_NORMAL_NV (see NV_register_combiners)
When the <target> and <pname> parameters of TexEnvf,
TexEnvfv, TexEnvi, and TexEnviv are TEXTURE_SHADER_NV and
PREVIOUS_TEXTURE_INPUT_NV respectively, then the value of <param>
or the value pointed to by <params> may be:
TEXTURE0_ARB
TEXTURE1_ARB
TEXTURE2_ARB
TEXTURE3_ARB
TEXTURE4_ARB
TEXTURE5_ARB
TEXTURE6_ARB
TEXTURE7_ARB
Accepted by the <format> parameter of GetTexImage, TexImage1D,
TexImage2D, TexSubImage1D, and TexSubImage2D:
HILO_NV 0x86F4
DSDT_NV 0x86F5
DSDT_MAG_NV 0x86F6
DSDT_MAG_VIB_NV 0x86F7
Accepted by the <type> parameter of GetTexImage, TexImage1D,
TexImage2D, TexSubImage1D, and TexSubImage2D:
UNSIGNED_INT_S8_S8_8_8_NV 0x86DA
UNSIGNED_INT_8_8_S8_S8_REV_NV 0x86DB
Accepted by the <internalformat> parameter of CopyTexImage1D,
CopyTexImage2D, TexImage1D, and TexImage2D:
SIGNED_RGBA_NV 0x86FB
SIGNED_RGBA8_NV 0x86FC
SIGNED_RGB_NV 0x86FE
SIGNED_RGB8_NV 0x86FF
SIGNED_LUMINANCE_NV 0x8701
SIGNED_LUMINANCE8_NV 0x8702
SIGNED_LUMINANCE_ALPHA_NV 0x8703
SIGNED_LUMINANCE8_ALPHA8_NV 0x8704
SIGNED_ALPHA_NV 0x8705
SIGNED_ALPHA8_NV 0x8706
SIGNED_INTENSITY_NV 0x8707
SIGNED_INTENSITY8_NV 0x8708
SIGNED_RGB_UNSIGNED_ALPHA_NV 0x870C
SIGNED_RGB8_UNSIGNED_ALPHA8_NV 0x870D
Accepted by the <internalformat> parameter of TexImage1D and
TexImage2D:
HILO_NV
HILO16_NV 0x86F8
SIGNED_HILO_NV 0x86F9
SIGNED_HILO16_NV 0x86FA
DSDT_NV
DSDT8_NV 0x8709
DSDT_MAG_NV
DSDT8_MAG8_NV 0x870A
DSDT_MAG_INTENSITY_NV 0x86DC
DSDT8_MAG8_INTENSITY8_NV 0x870B
Accepted by the <pname> parameter of GetBooleanv, GetIntegerv,
GetFloatv, GetDoublev, PixelTransferf, and PixelTransferi:
HI_SCALE_NV 0x870E
LO_SCALE_NV 0x870F
DS_SCALE_NV 0x8710
DT_SCALE_NV 0x8711
MAGNITUDE_SCALE_NV 0x8712
VIBRANCE_SCALE_NV 0x8713
HI_BIAS_NV 0x8714
LO_BIAS_NV 0x8715
DS_BIAS_NV 0x8716
DT_BIAS_NV 0x8717
MAGNITUDE_BIAS_NV 0x8718
VIBRANCE_BIAS_NV 0x8719
Accepted by the <pname> parameter of TexParameteriv, TexParameterfv,
GetTexParameterfv and GetTexParameteriv:
TEXTURE_BORDER_VALUES_NV 0x871A
Accepted by the <pname> parameter of GetTexLevelParameterfv and
GetTexLevelParameteriv:
TEXTURE_HI_SIZE_NV 0x871B
TEXTURE_LO_SIZE_NV 0x871C
TEXTURE_DS_SIZE_NV 0x871D
TEXTURE_DT_SIZE_NV 0x871E
TEXTURE_MAG_SIZE_NV 0x871F
Additions to Chapter 2 of the 1.2 Specification (OpenGL Operation)
None
Additions to Chapter 3 of the 1.2 Specification (Rasterization)
-- Section 3.6 "Pixel Rectangles"
Add four new rows to table 3.2:
Parameter Name Type Initial Value Valid Range
------------------ ----- ------------- -----------
HI_SCALE_NV float 1.0 (-Inf,+Inf)
LO_SCALE_NV float 1.0 (-Inf,+Inf)
DS_SCALE_NV float 1.0 (-Inf,+Inf)
DT_SCALE_NV float 1.0 (-Inf,+Inf)
MAGNITUDE_SCALE_NV float 1.0 (-Inf,+Inf)
VIBRANCE_SCALE_NV float 1.0 (-Inf,+Inf)
HI_BIAS_NV float 0.0 (-Inf,+Inf)
LO_BIAS_NV float 0.0 (-Inf,+Inf)
DS_BIAS_NV float 0.0 (-Inf,+Inf)
DT_BIAS_NV float 0.0 (-Inf,+Inf)
MAGNITUDE_BIAS_NV float 0.0 (-Inf,+Inf)
VIBRANCE_BIAS_NV float 0.0 (-Inf,+Inf)
-- Section 3.6.4 "Rasterization of Pixel Rectangles"
Add before the subsection titled "Unpacking":
"The HILO_NV, DSDT_NV, DSDT_MAG_NV, and DSDT_MAG_VIB_NV formats
are described in this section and section 3.6.5 even though these
formats are supported only for texture images. Textures with
the HILO_NV format are intended for use with certain dot product
texture and dependent texture shader operations (see section 3.8.13).
Textures with the DSDT_NV, DSDT_MAG_NV, and DSDT_MAG_VIB_NV format
are intended for use with certain offset texture 2D texture shader
operations (see section 3.8.13).
The error INVALID_ENUM occurs if HILO_NV, DSDT_NV, DSDT_MAG_NV, or
DSDT_MAG_VIB_NV is used as the format for DrawPixels, ReadPixels,
or other commands that specify or query an image with a format and
type parameter though the image is not a texture image. The HILO_NV,
DSDT_NV, DSDT_MAG_NV, or DSDT_MAG_VIB_NV formats are intended for
use with the TexImage and TexSubImage commands.
The HILO_NV format consists of two components, hi and lo, in the hi
then lo order. The hi and lo components maintain at least 16 bits
of storage per component (at least 16 bits of magnitude for unsigned
components and at least 15 bits of magnitude for signed components).
The DSDT_NV format consists of two signed components ds and dt,
in the ds then dt order. The DSDT_MAG_NV format consists of
three components: the signed ds and dt components and an unsigned
magnitude component (mag for short), in the ds, then dt, then mag
order. The DSDT_MAG_VIB_NV format consists of four components:
the signed ds and dt components, an unsigned magnitude component
(mag for short), and an unsigned vibrance component (vib for short),
in the ds, then dt, then mag, then vib order."
Add a new row to table 3.8:
type Parameter GL Data Number of Matching
Token Name Type Components Pixel Formats
----------------------------- ------- ---------- ----------------
UNSIGNED_INT_S8_S8_8_8_NV uint 4 DSDT_MAG_VIB_NV
UNSIGNED_INT_8_8_S8_S8_REV_NV uint 4 DSDT_MAG_VIB_NV
Add to table 3.11:
UNSIGNED_INT_S8_S8_8_8_NV:
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| 1st component | 2nd | 3rd | 4th |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
UNSIGNED_INT_8_8_S8_S8_REV_NV:
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| 4th | 3rd | 2nd | 1st component |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Replace the fifth paragraph in the subsection titled "Unpacking"
with the following:
"Calling DrawPixels with a type of UNSIGNED_BYTE_3_3_2,
UNSIGNED_BYTE_2_3_3_REV, UNSIGNED_SHORT_5_6_5,
UNSIGNED_SHORT_5_6_5_REV, UNSIGNED_SHORT_4_4_4_4,
UNSIGNED_SHORT_4_4_4_4_REV, UNSIGNED_SHORT_5_5_5_1,
UNSIGNED_SHORT_1_5_5_5_REV, UNSIGNED_INT_8_8_8_8,
UNSIGNED_INT_8_8_8_8_REV, UNSIGNED_INT_10_10_10_2, or
UNSIGNED_INT_2_10_10_10_REV is a special case in which all
the components of each group are packed into a single unsigned
byte, unsigned short, or unsigned int, depending on the type.
When packing or unpacking texture images (for example, using
TexImage2D or GetTexImage), the type parameter may also be either
UNSIGNED_INT_S8_S8_8_8_NV or UNSIGNED_INT_8_8_S8_S8_REV though
neither symbolic token is permitted for DrawPixels, ReadPixels,
or other commands that specify or query an image with a format
and type parameter though the image is not a texture image.
The error INVALID_ENUM occurs when UNSIGNED_INT_S8_S8_8_8_NV is
used when it is not permitted. When UNSIGNED_INT_S8_S8_8_8_NV
or UNSIGNED_INT_8_8_S8_S8_REV_NV is used, the first and second
components are treated as signed components. The number of
components per packed pixel is fixed by the type, and must match the
number of components per group indicated by the format parameter,
as listed in table 3.8. The format must also be one of the formats
listed in the Matching Pixel Formats column of table 3.8 for the
specified packed type. The error INVALID_OPERATION is generated
if a mismatch occurs. This constraint also holds for all other
functions that accept or return pixel data using type and format
parameters to define the type and format of the data."
Amend the second sentence in the sixth paragraph in the subsection
titled "Unpacking" to read:
"Each bitfield is interpreted as an unsigned integer value unless
it has been explicitly been stated that the bitfield contains a
signed component. Signed bitfields are treated as two's complement
numbers."
Add a new row to table 3.12:
First Second Third Fourth
Format Component Component Component Component
--------------- --------- --------- ---------- ---------
DSDT_MAG_VIB_NV ds dt magnitude vibrance
Change the last sentence in the first paragraph in the subsection
titled "Conversion to floating-point" to read:
"For packed pixel types, each unsigned element in the group is
converted by computing c / (2^N-1), where c is the unsigned integer
value of the bitfield containing the element and N is the number of
bits in the bitfield. In the case of signed elements of a packed
pixel type, the signed element is converted by computing 2*c+1 /
(2^N-1), where c is the signed integer value of the bitfield
containing the element and N is the number of bits in the bitfield."
Change the first sentence in the subsection "Final Expansion to RGBA"
to read:
"This step is performed only for groups other than HILO component,
depth component, and texture offset groups."
Add the following additional enumeration to the kind of pixel groups
in section 3.6.5:
"5. HILO component: Each group comprises two components: hi and lo.
6. Texture offset group: Each group comprises four components:
a ds and dt pair, a magnitude, and a vibrance."
Change the subsection "Arithmetic on Components" in section 3.6.5
to read:
"This step applies only to RGBA component, depth component, and HILO
component, and texture offset groups. Each component is multiplied
by an appropriate signed scale factor: RED_SCALE for an R component,
GREEN_SCALE for a G component, BLUE_SCALE for a B component,
ALPHA_SCALE, for an A component, HI_SCALE_NV for a HI component,
LO_SCALE_NV for a LO component, DS_SCALE_NV for a DS component,
DT_SCALE_NV for a DT component, MAGNITUDE_SCALE_NV for a MAG
component, VIBRANCE_SCALE_NV for a VIB component, or DEPTH_SCALE
for a depth component.
Then the result is added to the appropriate signed bias: RED_BIAS,
GREEN_BIAS, BLUE_BIAS, ALPHA_BIAS, HI_BIAS_NV, LO_BIAS_NV,
DS_BIAS_NV, DT_BIAS_NV, MAGNITUDE_BIAS_NV, VIBRANCE_BIAS_NV, or
DEPTH_BIAS."
-- Section 3.8 "Texturing"
Replace the first paragraph with the following:
"The GL provides two mechanisms for mapping sets of (s,t,r,q)
texture coordinates to RGBA colors: conventional texturing and
texture shaders.
Conventional texturing maps a portion of a specified image onto
each primitive for each enabled texture unit. Conventional
texture mapping is accomplished by using the color of an image
at the location indicated by a fragment's non-homogeneous (s,t,r)
coordinates for a given texture unit.
The alternative to conventional texturing is the texture shaders
mechanism. When texture shaders are enabled, each texture unit
uses one of twenty-one texture shader operations. Eighteen of the
twenty-one shader operations map an (s,t,r,q) texture coordinate
set to an RGBA color. Of these, three texture shader operations
directly correspond to the 1D, 2D, and cube map conventional
texturing operations. Depending on the texture shader operation,
the mapping from the (s,t,r,q) texture coordinate set to an RGBA
color may depend on the given texture unit's currently bound
texture object state and/or the results of previous texture
shader operations. The three remaining texture shader operations
respectively provide a fragment culling mechanism based on texture
coordinates, a means to replace the fragment depth value, and a dot
product operation that computes a floating-point value for use by
subsequent texture shaders. The specifics of each texture shader
operation are described in section 3.8.12.
Texture shading is enabled or disabled using the generic Enable
and Disable commands, respectively, with the symbolic constant
TEXTURE_SHADER_NV. When texture shading is disabled, conventional
texturing generates an RGBA color for each enabled textures unit
as described in Sections 3.8.10.
After RGBA colors are assigned to each texture unit, either by
conventional texturing or texture shaders, the GL proceeds with
fragment coloring, either using the texture environment, fog,
and color sum operations, or using register combiners extension if
supported.
Neither conventional texturing nor texture shaders affects the
secondary color."
-- Section 3.8.1 "Texture Image Specification"
Add the following sentence to the first paragraph:
"The formats HILO_NV, DSDT_NV, DSDT_MAG_NV, and DSDT_MAG_VIB_NV
are allowed for specifying texture images."
Replace the fourth paragraph with:
"The selected groups are processed exactly as for DrawPixels,
stopping just before conversion. Each R, G, B, A, HI, LO, DS, DT,
and MAG value so generated is clamped to [0,1] if the corresponding
component is unsigned, or if the corresponding component is signed,
is clamped to [-1,1]. The signedness of components depends on the
internal format (see table 3.16). The signedness of components
for unsized internal formats matches the signedness of components
for any respective sized version of the internal format."
Replace table 3.15 with the following table:
Base Internal Format Component Values Internal Components Format Type
--------------------- ------------------- ------------------- -------------------------
ALPHA A A RGBA
LUMINANCE R L RGBA
LUMINANCE_ALPHA R,A L,A RGBA
INTENSITY R I RGBA
RGB R,G,B R,G,B RGBA
RGBA R,G,B,A R,G,B,A RGBA
HILO_NV HI,LO HI,LO HILO
DSDT_NV DS,DT DS,DT texture offset group
DSDT_MAG_NV DS,DT,MAG DS,DT,MAG texture offset group
DSDT_MAG_INTENSITY_NV DS,DT,MAG,VIB DS,DT,MAG,I RGBA/texture offset group
Re-caption table 3.15 as:
"Conversion from RGBA, HILO, and texture offset pixel components to
internal texture table, or filter components. See section 3.8.9
for a description of the texture components R, G, B, A, L, and I.
See section 3.8.13 for an explanation of the handling of the texture
components HI, LO, DS, DT, MAG, and VIB."
Add five more columns to table 3.16 labeled "HI bits", "LO bits", "DS
bits", "DT bits", and "MAG bits". Existing table rows should have
these column entries blank. Add the following rows to the table:
Sized Base R G B A L I HI LO DS DT MAG
Internal Format Internal Format bits bits bits bits bits bits bits bits bits bits bits
------------------------------ --------------------- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
HILO16_NV HILO 16 16
SIGNED_HILO16_NV HILO 16* 16*
SIGNED_RGBA8_NV RGBA 8* 8* 8* 8*
SIGNED_RGB8_UNSIGNED_ALPHA8_NV RGBA 8* 8* 8* 8
SIGNED_RGB8_NV RGB 8* 8* 8*
SIGNED_LUMINANCE8_NV LUMINANCE 8*
SIGNED_LUMINANCE8_ALPHA8_NV LUMINANCE_ALPHA 8* 8*
SIGNED_ALPHA8_NV ALPHA 8*
SIGNED_INTENSITY8_NV INTENSITY 8*
DSDT8_NV DSDT_NV 8* 8*
DSDT8_MAG8_NV DSDT_MAG_NV 8* 8* 8
DSDT8_MAG8_INTENSITY8_NV DSDT_MAG_INTENSITY_NV 8 8* 8* 8
Add to the caption for table 3.16:
"An asterisk (*) following a component size indicates that the
corresponding component is signed (the sign bit is included in
specified component resolution size)."
Change the first sentences of the fifth paragraph to read:
"Components are then selected from the resulting R, G, B, A, HI, LO,
DS, DT, and MAG values to obtain a texture with the base internal
format specified by (or derived from) internalformat. Table 3.15
summarizes the mapping of R, G, B, A, HI, LO, DS, DT, and MAG values
to texture components, as a function of the base internal format of
the texture image. internalformat may be specified as one of the
ten base internal format symbolic constants listed in table 3.15,
or as one of the sized internal format symbolic constants listed
in table 3.16."
Add these sentences before the last sentence in the fifth paragraph:
"The error INVALID_OPERATION is generated if the format is
HILO_NV and the internalformat is not one of HILO_NV, HILO16_NV,
SIGNED_HILO_NV, SIGNED_HILO16_NV; or if the internalformat is one
of HILO_NV, HILO16_NV, SIGNED_HILO_NV, or SIGNED_HILO16_NV and the
format is not HILO_NV.
The error INVALID_OPERATION is generated if the format is DSDT_NV
and the internalformat is not either DSDT_NV or DSDT8_NV; or if
the internal format is either DSDT_NV or DSDT8_NV and the format
is not DSDT_NV.
The error INVALID_OPERATION is generated if the format is DSDT_MAG_NV
and the internalformat is not either DSDT_MAG_NV or DSDT8_MAG8_NV;
or if the internal format is either DSDT_MAG_NV or DSDT8_MAG8_NV
and the format is not DSDT_MAG_NV.
The error INVALID_OPERATION is generated if the format
is DSDT_MAG_VIB_NV and the internalformat is not either
DSDT_MAG_INTENSITY_NV or DSDT8_MAG8_INTENSITY8_NV; or if the internal
format is either DSDT_MAG_INTENSITY_NV or DSDT8_MAG8_INTENSITY8_NV
and the format is not DSDT_MAG_VIB_NV."
Change the first sentence of the sixth paragraph to read:
"The internal component resolution is the number of bits allocated
to each value in a texture image (and includes the sign bit if the
component is signed)."
Change the third sentence of the sixth paragraph to read:
"If a sized internal format is specified, the mapping of the R,
G, B, A, HI, LO, DS, DT, and MAG values to texture components
is equivalent to the mapping of the corresponding base internal
format's components, as specified in table 3.15, and the memory
allocations per texture component is assigned by the GL to match
the allocations listed in table 3.16 as closely as possible."
-- Section 3.8.2 "Alternate Texture Image Specification Commands"
In the second paragraph (describing CopyTexImage2D), change the
third to the last sentence to:
"Parameters level, internalformat, and border are specified using the
same values, with the same meanings, as the equivalent arguments of
TexImage2D, except that internalformat may not be specified as 1, 2,
3, 4, HILO_NV, HILO16_NV, SIGNED_HILO_NV, SIGNED_HILO16_NV, DSDT_NV,
DSDT8_NV, DSDT_MAG_NV, DSDT8_MAG8_NV, DSDT_MAG_INTENSITY_NV, or
DSDT8_MAG8_INTENSITY8_NV."
In the third paragraph (describing CopyTexImage1D), change the
second to the last sentence to:
"level, internalformat, and border are specified using the same
values, with the same meanings, as the equivalent arguments of
TexImage1D, except that internalformat may not be specified as 1, 2,
3, 4, HILO_NV, HILO16_NV, SIGNED_HILO_NV, SIGNED_HILO16_NV, DSDT_NV,
DSDT8_NV, DSDT_MAG_NV, DSDT8_MAG8_NV, DSDT_MAG_INTENSITY_NV, or
DSDT8_MAG8_INTENSITY8_NV."
Insert the following text after the six paragraph reading:
"CopyTexSubImage2D and CopyTexSubImage1D generate the error
INVALID_OPERATION if the internal format of the texture array to
which the pixels are to be copied is one of HILO_NV, HILO16_NV,
SIGNED_HILO_NV, SIGNED_HILO16_NV, DSDT_NV, DSDT8_NV, DSDT_MAG_NV,
DSDT8_MAG8_NV, DSDT_MAG_INTENSITY_NV, or DSDT8_MAG8_INTENSITY8_NV.
TexSubImage2D and TexSubImage1D generate the error INVALID_OPERATION
if the internal format of the texture array to which the texels are
to be copied has a different format type (according to table 3.15)
than the format type of the texels being specified. Specifically, if
the base internal format is not one of HILO_NV, DSDT_NV, DSDT_MAG_NV,
or DSDT_INTENSITY_NV, then the format parameter must be one of
COLOR_INDEX, RED, GREEN, BLUE, ALPHA, RGB, RGBA, LUMINANCE, or
LUMINANCE_ALPHA; if the base internal format is HILO_NV, then the
format parameter must be HILO_NV; if the base internal format is
DSDT_NV, then the format parameter must be DSDT_NV; if the base
internal format is DSDT_MAG_NV, then the format parameter must be
DSDT_MAG_NV; if the base internal format is DSDT_MAG_INTENSITY_NV,
the format parameter must be DSDT_MAG_VIB_NV."
-- Section 3.8.3 "Texture Parameters"
Change the TEXTURE_BORDER_COLOR line in table 3.17 to read:
Name Type Legal Values
------------------------ -------- ------------
TEXTURE_BORDER_VALUES 4 floats any value
Add the last two sentences to read:
"The TEXTURE_BORDER_VALUES state can also be specified with the
TEXTURE_BORDER_COLOR symbolic constant. When the state is specified
via TEXTURE_BORDER_COLOR, each of the four values specified are
first clamped to lie in [0,1]. However, if the texture border
values state is specified using TEXTURE_BORDER_VALUES, no clamping
occurs. In either case, if the values are specified as integers,
the conversion for signed integers from table 2.6 is applied to
convert the values to floating-point."
-- Section 3.8.5 "Texture Minification"
Change the last paragraph to read:
"If any of the selected tauijk, tauij, or taui in the above equations
refer to a border texel with i < -bs, j < bs, k < -bs, i >= ws-bs, j
>= hs-bs, or k >= ds-bs, then the border values given by the current
setting of TEXTURE_BORDER_VALUES is used instead of the unspecified
value or values. If the texture contains color components, the
components of the TEXTURE_BORDER_VALUES vector 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 HILO components,
the first and second components of the TEXTURE_BORDER_VALUES vector
are interpreted as the hi and lo components respectively. If the
texture contains texture offset group components, the first, second,
third, and fourth components of the TEXTURE_BORDER_VALUES vector
are interpreted as ds, dt, mag, and vib components respectively.
Additionally, the texture border values are clamped appropriately
depending on the signedness of each particular component. Unsigned
components are clamped to [0,1]; signed components are clamped to
[-1,1]."
-- Section 3.8.9 "Texture Environment and Texture Functions"
Augment the list of supported texture functions in the first
paragraph to read:
"TEXTURE_ENV_MODE may be set to one of REPLACE, MODULATE, DECAL,
BLEND, ADD, COMBINE_ARB (or COMBINE_EXT), COMBINE4_NV, or NONE;"
Insert this paragraph between the first and second paragraphs:
"When texture shaders are enabled (see section 3.8.13), a given
texture unit's texture shader result may be intended for use as
an input to another texture shader stage rather than generating
a texture unit RGBA result for use in the given texture unit's
texture environment function. Additionally, several texture shader
operations and texture format types are intended only to generate
texture shader results for subsequent texture shaders or perform a
side effect (such as culling the fragment or replacing the fragment's
depth value) rather than supplying a useful texture unit RGBA result
for use in the texture environment function. For this reason,
the NONE texture environment ignores the texture unit RGBA result
and passes through its input fragment color unchanged."
Change the third sentence of the second paragraph to read:
"If the TEXTURE_SHADER_NV mode is disabled, the precise form of
the texture environment function depends on the base internal
format of the texture object bound to the given texture unit's
highest-precedence enabled texture target. Otherwise if the
TEXTURE_SHADER_NV mode is enabled, then the form of the function
depends on the texture unit's texture shader operation.
If a texture shader operation requires fetching a filtered
texture color value (though not a HILO or texture offset value;
see the subsequent HILO and texture offset discussion), the texture
environment function depends on the base internal format of the
texture shader operation's respective texture target used for
fetching by the texture shader operation.
The PASS_THROUGH_NV texture shader operation does not fetch from any
texture target, but it generates an RGBA color and therefore always
operates as if the base internal format is RGBA for determining
what texture environment function to apply.
If the TEXTURE_SHADER_NV mode is enabled and the texture shader
operation for a given texture unit is one of NONE, CULL_FRAGMENT_NV,
DOT_PRODUCT_NV, or DOT_PRODUCT_DEPTH_REPLACE_NV, then the given
texture unit's texture function always operates as if the texture
function is NONE.
If the base internal format of the texture is HILO_NV, DSDT_NV,
or DSDT_MAG_NV (independent of whether or not the TEXTURE_SHADER_NV
mode is enabled or disabled), then corresponding the texture function
always operates as if the texture function is NONE.
If the base internal format of the texture is DSDT_MAG_INTENSITY_NV
(independent of whether or not the TEXTURE_SHADER_NV mode is enabled
or disabled), then the corresponding texture function operates
as if the base internal format is INTENSITY for the purposes of
determining the appropriate function using the vibrance component
as the intensity value."
Change the phrase in the fourth sentence of the second paragraph
describing how Rt, Gt, Bt, At, Lt, and It are assigned to:
"when TEXTURE_SHADER_NV is disabled, Rt, Gt, Bt, At, Lt, and It are
the filtered texture values; when TEXTURE_SHADER_NV is enabled, Rt,
Gt, Bt, and At are the respective components of the texture unit
RGBA result of the texture unit's texture shader stage, and Lt and
It are any red, green, or blue component of the texture unit RGBA
result (the three components should be the same);"
Change the second to last sentence of the second paragraph to read:
"The initial primary color and texture environment color component
values are in the range [0,1]. The filtered texture color and
texture function result color component values are in the range
[-1,1]. Negative filtered texture color component values are
generated by texture internal formats with signed components such
as SIGNED_RGBA."
Also amend tables 3.18 and 3.19 based on the following updated columns:
Base DECAL BLEND ADD
Internal Format Texture Function Texture Function Texture Function
================= ===================================== ===================================== ==========================
ALPHA Rv = Rf (no longer undefined) Rv = Rf Rv = Rf
Gv = Gf Gv = Gf Gv = Gf
Bv = Bf Bv = Bf Bv = Rf
Av = Af Av = Af*At Av = Af*Av = At
----------------- ------------------------------------- ------------------------------------- --------------------------
LUMINANCE Rv = Rf (no longer undefined) Rv = Rf*(1-max(0,Lt)) + Rc*max(0,Lt) Rv = max(-1,min(1,Rf+Lt))
(or 1) Gv = Gf Gv = Gf*(1-max(0,Lt)) + Gc*max(0,Lt) Gv = max(-1,min(1,Gf+Lt))
Bv = Bf Bv = Bf*(1-max(0,Lt)) + Bc*max(0,Lt) Bv = max(-1,min(1,Bf+Lt))
Av = Af Av = Af Av = Af
----------------- ------------------------------------- ------------------------------------- --------------------------
LUMINANCE_ALPHA Rv = Rf (no longer undefined) Rv = Rf*(1-max(0,Lt)) + Rc*max(0,Lt) Rv = max(-1,min(1,Rf+Lt))
(or 2) Gv = Gf Gv = Gf*(1-max(0,Lt)) + Gc*max(0,Lt) Gv = max(-1,min(1,Gf+Lt))
Bv = Bf Bv = Bf*(1-max(0,Lt)) + Bc*max(0,Lt) Bv = max(-1,min(1,Bf+Lt))
Av = Af Av = Af*At Av = Af*At
----------------- ------------------------------------- ------------------------------------- --------------------------
INTENSITY Rv = Rf (no longer undefined) Rv = Rf*(1-max(0,It)) + Rc*max(0,It) Rv = max(-1,min(1,Rf+It))
Gv = Gf Gv = Gf*(1-max(0,It)) + Gc*max(0,It) Gv = max(-1,min(1,Gf+It))
Bv = Bf Bv = Bf*(1-max(0,It)) + Bc*max(0,It) Bv = max(-1,min(1,Bf+It))
Av = Af Av = Af*(1-max(0,It)) + Ac*max(0,It) Av = max(-1,min(1,Af+It))
----------------- ------------------------------------- ------------------------------------- --------------------------
RGB Rv = Rt Rv = Rf*(1-max(0,Rt)) + Rc*max(0,Rt) Rv = max(-1,min(1,Rf+Rt))
(or 3) Gv = Gt Gv = Gf*(1-max(0,Gt)) + Gc*max(0,Gt) Gv = max(-1,min(1,Gf+Gt))
Bv = Bt Bv = Bf*(1-max(0,Bt)) + Bc*max(0,Bt) Bv = max(-1,min(1,Bf+Bt))
Av = Af Av = Af Av = Af
----------------- ------------------------------------- ------------------------------------- --------------------------
RGBA Rv = Rf*(1-max(0,At)) + Rt*max(0,At) Rv = Rf*(1-max(0,Rt)) + Rc*max(0,Rt) Rv = max(-1,min(1,Rf+Rt))
(or 4) Gv = Gf*(1-max(0,At)) + Gt*max(0,At) Gv = Gf*(1-max(0,Gt)) + Gc*max(0,Gt) Gv = max(-1,min(1,Gf+Gt))
Bv = Bf*(1-max(0,At)) + Bt*max(0,At) Bv = Bf*(1-max(0,Bt)) + Bc*max(0,Bt) Bv = max(-1,min(1,Bf+Bt))
Av = Af Av = Af*At Av = Af*At
----------------- ------------------------------------- ------------------------------------- --------------------------
Also augment table 3.18 or 3.19 with the following column:
Base NONE
Internal Format Texture Function
================= ================
ALPHA Rv = Rf
Gv = Gf
Bv = Bf
Av = Af
----------------- ----------------
LUMINANCE Rv = Rf
(or 1) Gv = Gf
Bv = Bf
Av = Af
----------------- ----------------
LUMINANCE_ALPHA Rv = Rf
(or 2) Gv = Gf
Bv = Bf
Av = Af
----------------- ----------------
INTENSITY Rv = Rf
Gv = Gf
Bv = Bf
Av = Af
----------------- ----------------
RGB Rv = Rf
(or 3) Gv = Gf
Bv = Bf
Av = Af
----------------- ----------------
RGBA Rv = Rf
(or 4) Gv = Gf
Bv = Bf
Av = Af
----------------- ----------------
Amend tables 3.21 and 3.22 in the ARB_texture_env_combine
specification (or EXT_texture_env_combine specification) to require
inputs to be clamped positive (the TEXTURE<n>_ARB entries apply
only if NV_texture_env_combine4 is supported):
SOURCE<n>_RGB_EXT OPERAND<n>_RGB_EXT Argument
----------------- -------------- --------
TEXTURE SRC_COLOR max(0,Ct)
ONE_MINUS_SRC_COLOR (1-max(0,Ct))
SRC_ALPHA max(0,At)
ONE_MINUS_SRC_ALPHA (1-max(0,At))
CONSTANT_EXT SRC_COLOR max(0,Cc
ONE_MINUS_SRC_COLOR (1-max(0,Cc)
SRC_ALPHA max(0,Ac
ONE_MINUS_SRC_ALPHA (1-max(0,Ac)
PRIMARY_COLOR_EXT SRC_COLOR max(0,Cf
ONE_MINUS_SRC_COLOR (1-max(0,Cf)
SRC_ALPHA max(0,Af
ONE_MINUS_SRC_ALPHA (1-max(0,Af)
PREVIOUS_EXT SRC_COLOR max(0,Cp
ONE_MINUS_SRC_COLOR (1-max(0,Cp)
SRC_ALPHA max(0,Ap
ONE_MINUS_SRC_ALPHA (1-max(0,Ap)
TEXTURE<n>_ARB SRC_COLOR max(0,Ct<n>)
ONE_MINUS_SRC_COLOR (1-max(0,Ct<n>))
SRC_ALPHA max(0,At<n>)
ONE_MINUS_SRC_ALPHA (1-max(0,At<n>))
Table 3.21: Arguments for COMBINE_RGB_ARB (or COMBINE_RGB_EXT)
functions
SOURCE<n>_ALPHA_EXT OPERAND<n>_ALPHA_EXT Argument
----------------- -------------- --------
TEXTURE SRC_ALPHA max(0,At)
ONE_MINUS_SRC_ALPHA (1-max(0,At))
CONSTANT_EXT SRC_ALPHA max(0,Ac)
ONE_MINUS_SRC_ALPHA (1-max(0,Ac))
PRIMARY_COLOR_EXT SRC_ALPHA max(0,Af)
ONE_MINUS_SRC_ALPHA (1-max(0,Af))
PREVIOUS_EXT SRC_ALPHA max(0,Ap)
ONE_MINUS_SRC_ALPHA (1-max(0,Ap))
TEXTURE<n>_ARB SRC_ALPHA max(0,At<n>)
ONE_MINUS_SRC_ALPHA (1-max(0,At<n>))
Table 3.22: Arguments for COMBINE_ALPHA_ARB (or COMBINE_ALPHA_EXT)
functions
-- Section 3.9 "Color Sum"
Update the first paragraph to read:
"At the beginning of color sum, a fragment has two RGBA colors: a
primary color cpri (which texturing, if enabled, may have modified)
and a secondary color csec. The components of these two colors are
clamped to [0,1] and then summed to produce a single post-texturing
RGBA color c. The components of c are then clamped to the range
[0,1]."
-- NEW Section 3.8.13 "Texture Shaders"
"Each texture unit is configured with one of twenty-one
texture shader operations. Several texture shader operations
require additional state. All per-texture shader stage state
is specified using the TexEnv commands with the target specified
as TEXTURE_SHADER_NV. The per-texture shader state is replicated
per texture unit so the texture unit selected by ActiveTextureARB
determines which texture unit's environment is modified by TexEnv
calls.
When calling TexEnv with a target of TEXTURE_SHADER_NV,
pname must be one of SHADER_OPERATION_NV, CULL_MODES_NV,
OFFSET_TEXTURE_MATRIX_NV, OFFSET_TEXTURE_SCALE_NV,
OFFSET_TEXTURE_BIAS_NV, PREVIOUS_TEXTURE_INPUT_NV, or CONST_EYE_NV.
When TexEnv is called with the target of TEXTURE_SHADER_NV,
SHADER_OPERATION_NV may be set to one of NONE,
TEXTURE_1D, TEXTURE_2D, TEXTURE_CUBE_MAP_ARB,
PASS_THROUGH_NV, CULL_FRAGMENT_NV, OFFSET_TEXTURE_2D_NV,
OFFSET_TEXTURE_2D_SCALE_NV, OFFSET_TEXTURE_RECTANGLE_NV,
OFFSET_TEXTURE_RECTANGLE_SCALE_NV, DEPENDENT_AR_TEXTURE_2D_NV,
DEPENDENT_GB_TEXTURE_2D_NV, DOT_PRODUCT_NV,
DOT_PRODUCT_DEPTH_REPLACE_NV, DOT_PRODUCT_TEXTURE_2D_NV,
DOT_PRODUCT_TEXTURE_RECTANGLE_NV, DOT_PRODUCT_TEXTURE_CUBE_MAP_NV,
DOT_PRODUCT_DIFFUSE_CUBE_MAP_NV, DOT_PRODUCT_REFLECT_CUBE_MAP_NV, or
DOT_PRODUCT_CONST_EYE_REFLECT_CUBE_MAP_NV. The semantics of each of
these shader operations is described in section 3.8.13.1. Not every
operation is supported in every texture unit. The restrictions for
how these shader operations can be configured in various texture
units are described in section 3.8.13.2.
When TexEnv is called with the target of TEXTURE_SHADER_NV,
CULL_MODES_NV is set to a vector of four cull comparisons by
providing four symbolic tokens, each being either LESS or GEQUAL.
These cull modes are used by the CULL_FRAGMENT_NV operation (see
section 3.8.13.1.7).
When TexEnv is called with the target of TEXTURE_SHADER_NV,
RGBA_UNSIGNED_DOT_PRODUCT_MAPPING_NV may be set to either
UNSIGNED_IDENTITY_NV or EXPAND_NORMAL_NV. This RGBA unsigned dot
product mapping mode is used by the DOT_PRODUCT_NV operation (see
section 3.8.13.1.14) and other operations that compute dot products.
When TexEnv is called with the target of TEXTURE_SHADER_NV,
PREVIOUS_TEXTURE_INPUT_NV may be set to TEXTUREi_ARB where i is
between 0 and n-1 where n is the implementation-dependent number of
texture units supported. The INVALID_OPERATION error is generated
if i is greater than or equal to the current active texture unit.
When TexEnv is called with the target of TEXTURE_SHADER_NV,
OFFSET_TEXTURE_MATRIX_NV may be set to a 2x2 matrix of floating-point
values stored in column-major order as 4 consecutive floating-point
values, i.e. as:
[ a1 a3 ]
[ a2 a4 ]
This matrix is used by the OFFSET_TEXTURE_2D_NV,
OFFSET_TEXTURE_2D_SCALE_NV, OFFSET_TEXTURE_RECTANGLE_NV, and
OFFSET_TEXTURE_RECTANGLE_SCALE_NV operations (see sections 3.8.13.1.8
through 3.8.13.1.11).
When TexEnv is called with the target of TEXTURE_SHADER_NV,
OFFSET_TEXTURE_SCALE_NV may be set to a floating-point value.
When TexEnv is called with the target of TEXTURE_SHADER_NV,
OFFSET_TEXTURE_BIAS_NV may be set to a floating-point value. These
scale and bias values are used by the OFFSET_TEXTURE_2D_SCALE_NV
and OFFSET_TEXTURE_RECTANGLE_SCALE_NV operations (see section
3.8.13.1.9 and 3.8.13.1.11).
When TexEnv is called with the target of TEXTURE_SHADER_NV,
CONST_EYE_NV is set to a vector of three floating-point
values used as the constant eye vector in the
DOT_PRODUCT_CONST_EYE_REFLECT_CUBE_MAP_NV texture shader (see
section 3.8.13.1.19).
3.8.13.1 Texture Shader Operations
The texture enables described in section 3.8.10 only affect
conventional texturing mode; these enables are ignored when
TEXTURE_SHADER_NV is enabled. Instead, the texture shader operation
determines how texture coordinates are mapped to filtered texture
values.
Tables 3.A, 3.B, 3.C, and 3.D specify inter-stage dependencies,
texture target dependencies, relevant inputs, and result types and
values respectively for each texture shader operation. Table 3.E
specifies how the components of an accessed texture are mapped to
the components of the texture unit RGBA result based on the base
internal format of the accessed texture. The following discussion
describes each possible texture shader operation in detail.
texture shader
texture shader operation i previous texture input texture shader operation i-1 operation i-2 texture shader operation i+1
================================= ========================= =============================== ================ ================================
NONE - - - -
--------------------------------- ------------------------- ------------------------------- ---------------- --------------------------------
TEXTURE_1D - - - -
TEXTURE_2D - - - -
TEXTURE_RECTANGLE_NV - - - -
TEXTURE_CUBE_MAP_ARB - - - -
--------------------------------- ------------------------- ------------------------------- ---------------- --------------------------------
PASS_THROUGH_NV - - - -
CULL_FRAGMENT_NV - - - -
--------------------------------- ------------------------- ------------------------------- ---------------- --------------------------------
OFFSET_TEXTURE_2D_NV base internal texture - - -
format must be one of
DSDT_NV, DSDT_MAG_NV, or
DSDT_MAG_INTENSITY_NV
OFFSET_TEXTURE_2D_SCALE_NV base internal texture - - -
format must be either
DSDT_MAG_NV or
DSDT_MAG_INTENSITY_NV
OFFSET_TEXTURE_RECTANGLE_NV base internal texture - - -
format must be one of
DSDT_NV, DSDT_MAG_NV, or
DSDT_MAG_INTENSITY_NV
OFFSET_TEXTURE_RECTANGLE_SCALE_NV base internal texture - - -
format must be either
DSDT_MAG_NV or
DSDT_MAG_INTENSITY_NV
--------------------------------- ------------------------- ------------------------------- ---------------- --------------------------------
DEPENDENT_AR_TEXTURE_2D_NV shader result type must - - -
all be unsigned RGBA
DEPENDENT_GB_TEXTURE_2D_NV shader result type must - - -
all be unsigned RGBA
--------------------------------- ------------------------- ------------------------------- ---------------- --------------------------------
DOT_PRODUCT_NV shader result type must - - -
be one of signed HILO,
unsigned HILO, all
signed RGBA, or all
unsigned RGBA
DOT_PRODUCT_TEXTURE_2D_NV shader result type must shader operation must be - -
be one of signed HILO, DOT_PRODUCT_NV
unsigned HILO, all
signed RGBA, or all
unsigned RGBA
DOT_PRODUCT_TEXTURE_RECTANGLE_NV shader result type must shader operation must be - -
be one of signed HILO, DOT_PRODUCT_NV
unsigned HILO, all
signed RGBA, all
unsigned RGBA
DOT_PRODUCT_TEXTURE_CUBE_MAP_NV shader result type must shader operation shader operation -
be one of signed HILO, must be must be
unsigned HILO, all DOT_PRODUCT_NV DOT_PRODUCT_NV
signed RGBA, or all
unsigned RGBA
DOT_PRODUCT_REFLECT_CUBE_MAP_NV shader result type must shader operation must be shader operation -
be one of signed HILO, DOT_PRODUCT_NV or must be
unsigned HILO, all DOT_PRODUCT_DIFFUSE_CUBE_MAP_NV DOT_PRODUCT_NV
signed RGBA, or all
unsigned RGBA; previous
texture input must not
be unit i-1
DOT_PRODUCT_CONST_EYE_- shader result type must shader operation shader operation -
REFLECT_CUBE_MAP_NV be one of signed HILO, must be must be
unsigned HILO, all DOT_PRODUCT_NV or DOT_PRODUCT_NV
signed RGBA, or all DOT_PRODUCT_DIFFUSE_CUBE_MAP_NV
unsigned RGBA
DOT_PRODUCT_DIFFUSE_CUBE_MAP_NV shader result type must shader operation must be - shader operation must be
be one of signed HILO, DOT_PRODUCT_NV DOT_PRODUCT_REFLECT_CUBE_MAP_NV
unsigned HILO, all or DOT_PRODUCT_CONST_EYE_-
signed RGBA, or all REFLECT_CUBE_MAP_NV
unsigned RGBA
--------------------------------- ------------------------- ------------------------------- ---------------- --------------------------------
DOT_PRODUCT_DEPTH_REPLACE_NV shader result type must shader operation - -
be one of signed HILO, must be
unsigned HILO, all DOT_PRODUCT_NV
signed RGBA, or all
unsigned RGBA
--------------------------------- ------------------------- ------------------------------- ---------------- --------------------------------
Table 3.A: Texture shader inter-stage dependencies for each operation.
If any one of the dependencies listed above is not met, the texture
shader stage is considered inconsistent. Further texture shader target
dependencies are listed in table X.Y. Additionally, if any one of the
texture shader stages that a particular texture shader stage depends on is
inconsistent, then the dependent texture shader stage is also considered
inconsistent. When a texture shader stage is considered inconsistent,
the inconsistent stage operates as if the stage's operation is NONE.
texture shader operation i texture unit i
================================= =======================================
NONE -
--------------------------------- ---------------------------------------
TEXTURE_1D 1D target must be consistent
TEXTURE_2D 2D target must be consistent
TEXTURE_RECTANGLE_NV rectangle target must be consistent
TEXTURE_CUBE_MAP_ARB cube map target must be consistent
--------------------------------- ---------------------------------------
PASS_THROUGH_NV -
CULL_FRAGMENT_NV -
--------------------------------- ---------------------------------------
OFFSET_TEXTURE_2D_NV 2D target must be consistent
OFFSET_TEXTURE_2D_SCALE_NV 2D target must be consistent
and 2D texture target type must
be unsigned RGBA
OFFSET_TEXTURE_RECTANGLE_NV rectangle target must be consistent
OFFSET_TEXTURE_RECTANGLE_SCALE_NV rectangle target must be consistent
and rectangle texture target type must
be unsigned RGBA
--------------------------------- ---------------------------------------
DEPENDENT_AR_TEXTURE_2D_NV 2D target must be consistent
DEPENDENT_GB_TEXTURE_2D_NV 2D target must be consistent
--------------------------------- ---------------------------------------
DOT_PRODUCT_NV -
DOT_PRODUCT_TEXTURE_2D_NV 2D target must be consistent
DOT_PRODUCT_TEXTURE_RECTANGLE_NV rectangle target must be consistent
DOT_PRODUCT_TEXTURE_CUBE_MAP_NV cube map target must be consistent
DOT_PRODUCT_REFLECT_CUBE_MAP_NV cube map target must be consistent
DOT_PRODUCT_CONST_EYE_- cube map target must be consistent
REFLECT_CUBE_MAP_NV
DOT_PRODUCT_DIFFUSE_CUBE_MAP_NV cube map target must be consistent
--------------------------------- ---------------------------------------
DOT_PRODUCT_DEPTH_REPLACE_NV -
--------------------------------- ---------------------------------------
Table 3.B: Texture shader target dependencies for each operation.
If the dependency listed above is not met, the texture shader stage is
considered inconsistent.
uses uses uses uses uses offset uses
texture stage stage stage previous uses offset texture const
coordinate texture result result result texture cull texture 2D scale eye
texture shader operation i set usage target i-1 i-2 i+1 input modes 2D matrix and bias vector
================================= ========== ========= ====== ====== ====== ======== ===== ========= ======== ======
NONE - - - - - - - - - -
--------------------------------- ---------- --------- ------ ------ ------ -------- ----- --------- -------- ------
TEXTURE_1D s,q 1D - - - - - - - -
TEXTURE_2D s,t,q 2D - - - - - - - -
TEXTURE_RECTANGLE_NV s,t,q rectangle - - - - - - - -
TEXTURE_CUBE_MAP_ARB s,t,r cube map - - - - - - - -
--------------------------------- ---------- --------- ------ ------ ------ -------- ----- --------- -------- ------
PASS_THROUGH_NV s,t,r,q - - - - - - - - -
CULL_FRAGMENT_NV s,t,r,q - - - - - y - - -
--------------------------------- ---------- --------- ------ ------ ------ -------- ----- --------- -------- ------
OFFSET_TEXTURE_2D_NV s,t 2D - - - y - y - -
OFFSET_TEXTURE_2D_SCALE_NV s,t 2D - - - y - y y -
OFFSET_TEXTURE_RECTANGLE_NV s,t rectangle - - - y - y - -
OFFSET_TEXTURE_RECTANGLE_SCALE_NV s,t rectangle - - - y - y y -
--------------------------------- ---------- --------- ------ ------ ------ -------- ----- --------- -------- ------
DEPENDENT_AR_TEXTURE_2D_NV - 2D - - - y - - - -
DEPENDENT_GB_TEXTURE_2D_NV - 2D - - - y - - - -
--------------------------------- ---------- --------- ------ ------ ------ -------- ----- --------- -------- ------
DOT_PRODUCT_NV s,t,r (q*) - - - - y - - - -
DOT_PRODUCT_TEXTURE_2D_NV s,t,r 2D y - - y - - - -
DOT_PRODUCT_TEXTURE_RECTANGLE_NV s,t,r rectangle y - - y - - - -
DOT_PRODUCT_TEXTURE_CUBE_MAP_NV s,t,r cube map y y - y - - - -
DOT_PRODUCT_REFLECT_CUBE_MAP_NV s,t,r,q cube map y y - y - - - -
DOT_PRODUCT_CONST_EYE_- s,t,r cube map y y - y - - - y
REFLECT_CUBE_MAP_NV
DOT_PRODUCT_DIFFUSE_CUBE_MAP_NV s,t,r (q*) cube map y y y y - - - -
--------------------------------- ---------- --------- ------ ------ ------ -------- ----- --------- -------- ------
DOT_PRODUCT_DEPTH_REPLACE_NV s,t,r - y - - y - - - -
--------------------------------- ---------- --------- ------ ------ ------ -------- ----- --------- -------- ------
Table 3.C: Relevant texture shader computation inputs for each
operation. The (q*) for the texture coordinate set usage indicates
that the q texture coordinate is used only when the DOT_PRODUCT_NV and
DOT_PRODUCT_DIFFUSE_CUBE_MAP_NV operations are used in conjunction with
DOT_PRODUCT_REFLECT_CUBE_MAP_NV.
texture shader operation i shader stage result type shader stage result texture unit RGBA color result
================================= ============================= =================================== ======================================
NONE unsigned RGBA invalid (0,0,0,0)
--------------------------------- ----------------------------- ----------------------------------- --------------------------------------
TEXTURE_1D matches 1D target type filtered 1D target texel if 1D target texture type is RGBA,
filtered 1D target texel,
else (0,0,0,0)
TEXTURE_2D matches 2D target type filtered 2D target texel if 2D target texture type is RGBA,
filtered 2D target texel,
else (0,0,0,0)
TEXTURE_RECTANGLE_NV matches rectangle target type filtered rectangle target texel if rectangle target texture type is
RGBA, filtered rectangle target
texel, else (0,0,0,0)
TEXTURE_CUBE_MAP_ARB matches cube map target type filtered cube map target texel if cube map target texture type is
RGBA, filtered cube map target
texel, else (0,0,0,0)
--------------------------------- ----------------------------- ----------------------------------- --------------------------------------
PASS_THROUGH_NV unsigned RGBA (max(0,min(1,s)), max(0,min(1,t)), (max(0,min(1,s)), max(0,min(1,t)),
max(0,min(1,r)), max(0,min(1,q))) max(0,min(1,r)), max(0,min(1,q)))
CULL_FRAGMENT_NV unsigned RGBA invalid (0,0,0,0)
--------------------------------- ----------------------------- ----------------------------------- --------------------------------------
OFFSET_TEXTURE_2D_NV matches 2D target type filtered 2D target texel if 2D target texture type is RGBA,
filtered 2D target texel,
else (0,0,0,0)
OFFSET_TEXTURE_2D_SCALE_NV unsigned RGBA filtered 2D target texel scaled filtered 2D target texel
OFFSET_TEXTURE_RECTANGLE_NV matches rectangle target type filtered rectangle target texel if rectangle target texture type is
RGBA, filtered rectangle target
texel, else (0,0,0,0)
OFFSET_TEXTURE_RECTANGLE_SCALE_NV unsigned RGBA filtered rectangle target texel scaled filtered rectangle target texel
--------------------------------- ----------------------------- ----------------------------------- --------------------------------------
DEPENDENT_AR_TEXTURE_2D_NV matches 2D target type filtered 2D target texel if 2D target texture type is RGBA,
filtered 2D target texel,
else (0,0,0,0)
DEPENDENT_GB_TEXTURE_2D_NV matches 2D target type filtered 2D target texel if 2D target texture type is RGBA,
filtered 2D target texel,
else (0,0,0,0)
--------------------------------- ----------------------------- ----------------------------------- --------------------------------------
DOT_PRODUCT_NV float dot product (0,0,0,0)
DOT_PRODUCT_TEXTURE_2D_NV matches 2D target type filtered 2D target texel if 2D target texture type is RGBA,
filtered 2D target texel,
else (0,0,0,0)
DOT_PRODUCT_TEXTURE_RECTANGLE_NV matches rectangle target type filtered rectangle target texel if rectangle target texture type is
RGBA, filtered rectangle target
texel, else (0,0,0,0)
DOT_PRODUCT_TEXTURE_CUBE_MAP_NV matches cube map target type filtered cube map target texel if cube map target texture type is
RGBA, filtered cube map target
texel, else (0,0,0,0)
DOT_PRODUCT_REFLECT_CUBE_MAP_NV matches cube map target type filtered cube map target texel if cube map target texture type is
RGBA, filtered cube map target
texel, else (0,0,0,0)
DOT_PRODUCT_CONST_EYE_- matches cube map target type filtered cube map target texel if cube map target texture type is
REFLECT_CUBE_MAP_NV RGBA, filtered cube map target
texel, else (0,0,0,0)
DOT_PRODUCT_DIFFUSE_CUBE_MAP_NV matches cube map target type filtered cube map target texel if cube map target texture type is
RGBA, filtered cube map target
texel, else (0,0,0,0)
------------------------------- ----------------------------- ----------------------------------- --------------------------------------
DOT_PRODUCT_DEPTH_REPLACE_NV unsigned RGBA invalid (0,0,0,0)
------------------------------- ----------------------------- ----------------------------------- --------------------------------------
Table 3.D: Texture shader stage results for each operation.
Base internal format Red Green Blue Alpha
-------------------- --- ----- ---- -----
ALPHA 1 1 1 At
LUMINANCE Lt Lt Lt 1
INTENSITY It It It It
LUMINANCE_ALPHA Lt Lt Lt At
RGB Rt Gt Bt 1
RGBA Rt Gt Bt At
Table 3.E: How base internal formats components are mapped to RGBA values
for texture shaders (note that the mapping for ALPHA is different from
the mapping in Table 3.23 in the EXT_texture_env_combine extension).
3.8.13.1.1 None
The NONE texture shader operation ignores the texture unit's texture
coordinate set and always generates the texture unit RGBA result
(0,0,0,0) for its filtered texel value. The texture shader result
is invalid. This texture shader stage is always consistent.
When a texture unit is not needed while texture shaders are enabled,
it is most efficient to set the texture unit's texture shader
operation to NONE.
3.8.13.1.2 1D Projective Texturing
The TEXTURE_1D texture shader operation accesses the texture unit's
1D texture object (as described in sections 3.8.4, 3.8.5, and 3.8.6)
using (s/q) for the 1D texture coordinate where s and q are the
homogeneous texture coordinates for the texture unit. The result
of the texture access becomes both the shader result and texture
unit RGBA result (see table 3.E). The type of the shader result
depends on the format type of the accessed texture. This mode is
equivalent to conventional texturing's 1D texture target.
If the texture unit's 1D texture object is not consistent, then
this texture shader stage is not consistent.
If this texture shader stage is not consistent, it operates as if
it is the NONE operation.
3.8.13.1.3 2D Projective Texturing
The TEXTURE_2D texture shader operation accesses the texture unit's
2D texture object (as described in sections 3.8.4, 3.8.5, and
3.8.6) using (s/q,t/q) for the 2D texture coordinates where s, t,
and q are the homogeneous texture coordinates for the texture unit.
The result of the texture access becomes both the shader result and
texture unit RGBA result (see table 3.E). The type of the shader
result depends on the format type of the accessed texture. This mode
is equivalent to conventional texturing's 2D texture target.
If the texture unit's 2D texture object is not consistent, then
this texture shader stage is not consistent.
If this texture shader stage is not consistent, it operates as if
it is the NONE operation.
3.8.13.1.4 Rectangle Projective Texturing
The TEXTURE_RECTANGLE_NV texture shader operation accesses
the texture unit's rectangle texture object (as described in
sections 3.8.4, 3.8.5, and 3.8.6) using (s/q,t/q) for the 2D texture
coordinates where s, t, and q are the homogeneous texture coordinates
for the texture unit. The result of the texture access becomes both
the shader result and texture unit RGBA result (see table 3.E).
The type of the shader result depends on the format type of the
accessed texture. This mode is equivalent to NV_texture_rectangle's
rectangle texture target.
If the texture unit's rectangle texture object is not consistent,
then this texture shader stage is not consistent.
If this texture shader stage is not consistent, it operates as if
it is the NONE operation.
3.8.13.1.5 Cube Map Texturing
The TEXTURE_CUBE_MAP_ARB texture shader operation accesses
the texture unit's cube map texture object (as described in the
ARB_texture_cube_map specification) using (s,t,r) for the 3D texture
coordinate where s, t, and r are the homogeneous texture coordinates
for the texture unit. The result of the texture access becomes
both the shader result and texture unit RGBA result (see table
3.E). The type of the shader result depends on the format type
of the accessed texture. This mode is equivalent to conventional
texturing's cube map texture target.
If the texture unit's cube map texture object is not consistent, then
this texture shader stage is not consistent.
If this texture shader stage is not consistent, it operates as if
it is the NONE operation.
3.8.13.1.6 Pass Through
The PASS_THROUGH_NV texture shader operation converts an (s,t,r,q)
texture coordinate set into an RGBA color result (r,g,b,a).
Each texture coordinate is first clamped to [0,1] before being
mapped to its corresponding color component. The texture shader
result and texture unit RGBA result of this operation are both
assigned the clamped RGBA color result.
This operation in no way depends on any of the texture unit's
texture objects.
3.8.13.1.7 Cull Fragment
The CULL_FRAGMENT_NV texture shader operation compares each
component of the texture coordinate set (s,t,r,q) to zero based
on the texture shader's corresponding cull mode. For the LESS
cull mode to succeed, the corresponding component must be less
than zero; otherwise the comparison fails. For the GEQUAL cull
mode to succeed, the corresponding component must be greater or
equal to zero; otherwise the comparison fails. If any of the four
comparisons fails, the fragment is discarded.
The texture unit RGBA result generated is always (0,0,0,0).
The texture shader result is invalid. This texture shader stage
is always consistent.
This operation in no way depends on any of the texture unit's
texture objects.
3.8.13.1.8 Offset Texture 2D
The OFFSET_TEXTURE_2D_NV texture shader operation uses the
transformed result of a previous texture shader stage to perturb
the current texture shader stage's (s,t) texture coordinates
(without a projective division by q). The resulting perturbed
texture coordinates (s',t') are used to access the texture unit's 2D
texture object (as described in sections 3.8.4, 3.8.5, and 3.8.6).
The result of the texture access becomes both the shader result and
texture unit RGBA result (see table 3.E). The type of the shader
result depends on the format type of the accessed texture.
The perturbed texture coordinates s' and t' are computed with
floating-point math as follows:
s' = s + a1 * DSprev + a3 * DTprev
t' = t + a2 * DSprev + a4 * DTprev
where a1, a2, a3, and a4 are the texture shader stage's
OFFSET_TEXTURE_MATRIX_NV values, and DSprev and DTprev are the
(signed) DS and DT components of a previous texture shader unit's
texture shader result specified by the current texture shader
stage's PREVIOUS_TEXTURE_INPUT_NV value.
If the texture unit's 2D texture object is not consistent, then
this texture shader stage is not consistent.
If the previous texture input texture object specified by the
current texture shader stage's PREVIOUS_TEXTURE_INPUT_NV value
has a base internalformat that is not one of DSDT_NV, DSDT_MAG_NV
or DSDT_MAG_INTENSITY_NV, then this texture shader stage is not
consistent.
If the previous texture input texture shader operation specified by
the current texture shader stage's PREVIOUS_TEXTURE_INPUT_NV value
is DOT_PRODUCT_NV, then this texture shader stage is not consistent.
If the previous texture input texture shader result specified by
the current texture shader stage's PREVIOUS_TEXTURE_INPUT_NV value
is invalid, then this texture shader stage is not consistent.
If the previous texture input shader stage specified by the current
texture shader stage's PREVIOUS_TEXTURE_INPUT_NV value is not
consistent, then this texture shader stage is not consistent.
If this texture shader stage is not consistent, it operates as if
it is the NONE operation.
3.8.13.1.9 Offset Texture 2D and Scale
The OFFSET_TEXTURE_2D_SCALE_NV texture shader operation extends the
functionality of the OFFSET_TEXTURE_2D_NV texture shader operation.
The texture unit's 2D texture object is accessed by the same
perturbed s' and t' coordinates used by the OFFSET_TEXTURE_2D_NV
operation. The red, green, and blue components (but not alpha)
of the RGBA result of the texture access are further scaled by
the value Scale and clamped to the range [0,1]. This RGBA result
is this shader's texture unit RGBA result. This shader's texture
shader result is the RGBA result of the texture access prior to
scaling and clamping.
Scale is computed with floating-point math as follows:
Scale = max(0.0, min(1.0, textureOffsetBias + textureOffsetScale * MAGprev))
where textureOffsetBias is the texture shader stage's
OFFSET_TEXTURE_BIAS_NV value, textureOffsetScale is the texture
shader stage's OFFSET_TEXTURE_SCALE_NV value, and MAGprev
is the magnitude component of the a previous texture shader
unit's result specified by the current texture shader stage's
PREVIOUS_TEXTURE_INPUT_NV value.
The texture unit RGBA result (red',green',blue',alpha') is computed
as follows:
red' = Scale * red
green' = Scale * green
blue' = Scale * blue
alpha' = alpha
where red, green, blue, and alpha are the texture access components.
If the unit's 2D texture object has any signed components, then this
texture shader stage is not consistent.
If the texture unit's 2D texture object is has a format type other
than RGBA (the DSDT_MAG_INTENSITY_NV base internal format does not
count as an RGBA format type in this context), then this texture
shader stage is not consistent.
If the texture unit's 2D texture object is not consistent, then
this texture shader stage is not consistent.
If the previous texture input texture object specified by the
current texture shader stage's PREVIOUS_TEXTURE_INPUT_NV value
has a base internalformat that is not either DSDT_MAG_NV
or DSDT_MAG_INTENSITY_NV, then this texture shader stage is not
consistent.
If the previous texture input texture shader operation specified by
the current texture shader stage's PREVIOUS_TEXTURE_INPUT_NV value
is DOT_PRODUCT_NV, then this texture shader stage is not consistent.
If the previous texture input texture shader result specified by
the current texture shader stage's PREVIOUS_TEXTURE_INPUT_NV value
is invalid, then this texture shader stage is not consistent.
If the previous texture input shader stage specified by the current
texture shader stage's PREVIOUS_TEXTURE_INPUT_NV value is not
consistent, then this texture shader stage is not consistent.
If this texture shader stage is not consistent, it operates as if
it is the NONE operation.
3.8.13.1.10 Offset Texture Rectangle
The OFFSET_TEXTURE_RECTANGLE_NV shader operation operates
identically to the OFFSET_TEXTURE_2D_NV shader operation except
that the rectangle texture target is accessed rather than the 2D
texture target.
If the texture unit's rectangle texture object (rather than the 2D
texture object) is not consistent, then this texture shader stage
is not consistent.
3.8.13.1.11 Offset Texture Rectangle Scale
The OFFSET_TEXTURE_RECTANGLE_SCALE_NV shader operation operates
identically to the OFFSET_TEXTURE_2D_SCALE_NV shader operation
except that the rectangle texture target is accessed rather than
the 2D texture target.
If the texture unit's rectangle texture object (rather than the 2D
texture object) is not consistent, then this texture shader stage
is not consistent.
3.8.13.1.12 Dependent Alpha-Red Texturing
The DEPENDENT_AR_TEXTURE_2D_NV texture shader operation accesses
the texture unit's 2D texture object (as described in section 3.8.4,
3.8.5, and 3.8.6) using (Aprev, Rprev) for the 2D texture coordinates
where Aprev and Rprev are the are the alpha and red components of
a previous texture input's RGBA texture shader result specified by
the current texture shader stage's PREVIOUS_TEXTURE_INPUT_NV value.
The result of the texture access becomes both the shader result and
texture unit RGBA result (see table 3.E). The type of the shader
result depends on the format type of the accessed texture.
If the texture unit's 2D texture object is not consistent, then
this texture shader stage is not consistent.
If the previous texture input's texture shader result specified
by the current texture shader stage's PREVIOUS_TEXTURE_INPUT_NV
value has a texture shader result type other than RGBA (the
DSDT_MAG_INTENSITY_NV base internal format does not count as an
RGBA format type in this context), then this texture shader stage
is not consistent.
If the previous texture input's texture shader result specified
by the current texture shader stage's PREVIOUS_TEXTURE_INPUT_NV
value has a texture shader result type of RGBA but any of the
RGBA components are signed, then this texture shader stage is not
consistent.
If the previous texture input texture shader operation specified by
the current texture shader stage's PREVIOUS_TEXTURE_INPUT_NV value
is DOT_PRODUCT_NV, then this texture shader stage is not consistent.
If the previous texture input texture shader result specified by
the current texture shader stage's PREVIOUS_TEXTURE_INPUT_NV value
is invalid, then this texture shader stage is not consistent.
If the previous texture input shader stage specified by the current
texture shader stage's PREVIOUS_TEXTURE_INPUT_NV value is not
consistent, then this texture shader stage is not consistent.
If this texture shader stage is not consistent, it operates as if
it is the NONE operation.
3.8.13.1.13 Dependent Green-Blue Texturing
The DEPENDENT_GB_TEXTURE_2D_NV texture shader operation accesses
the texture unit's 2D texture object (as described in section 3.8.4,
3.8.5, and 3.8.6) using (Gprev, Bprev) for the 2D texture coordinates
where Gprev and Bprev are the are the green and blue components
of a previous texture input's RGBA texture shader result specified by the
current texture shader stage's PREVIOUS_TEXTURE_INPUT_NV value.
The result of the texture access becomes both the shader result and
texture unit RGBA result (see table 3.E). The type of the shader
result depends on the format type of the accessed texture.
If the texture unit's 2D texture object is not consistent, then
this texture shader stage is not consistent.
If the previous texture input's texture shader result specified
by the current texture shader stage's PREVIOUS_TEXTURE_INPUT_NV
value has a texture shader result type other than RGBA (the
DSDT_MAG_INTENSITY_NV base internal format does not count as an
RGBA format type in this context), then this texture shader stage
is not consistent.
If the previous texture input's texture shader result specified
by the current texture shader stage's PREVIOUS_TEXTURE_INPUT_NV
value has a texture shader result type of RGBA but any of the
RGBA components are signed, then this texture shader stage is not
consistent.
If the previous texture input texture shader operation specified by
the current texture shader stage's PREVIOUS_TEXTURE_INPUT_NV value
is DOT_PRODUCT_NV, then this texture shader stage is not consistent.
If the previous texture input texture shader result specified by
the current texture shader stage's PREVIOUS_TEXTURE_INPUT_NV value
is invalid, then this texture shader stage is not consistent.
If the previous texture input shader stage specified by the current
texture shader stage's PREVIOUS_TEXTURE_INPUT_NV value is not
consistent, then this texture shader stage is not consistent.
If this texture shader stage is not consistent, it operates as if
it is the NONE operation.
3.8.13.1.14 Dot Product
The DOT_PRODUCT_NV texture shader operation computes a
floating-point texture shader result. The texture shader result
is the floating-point dot product of the texture unit's (s,t,r)
texture coordinates and a remapped version of the RGBA or HILO
texture shader result from a specified previous texture shader stage.
The RGBA color result of this shader is always (0,0,0,0).
The re-mapping depends on the specified previous texture shader
stage's texture shader result type. Specifically, the re-mapping
depends on whether this texture shader result type has all signed
components or all unsigned components, and whether it has RGBA
components or HILO components, and, in the case of unsigned RGBA
texture shader results, the RGBA_UNSIGNED_DOT_PRODUCT_MAPPING_NV
state.
If the specified previous texture unit's texture shader result
type is HILO and all the type components are unsigned, then the
floating-point result is computed by
result = s * HI + t * LO + r
where HI and LO are the (unsigned) hi and lo components respectively
of the previous texture unit's HILO texture shader result.
If the specified previous texture unit's texture shader result
type is HILO and all the type components are signed, then the
floating-point result is computed by
result = s * HI + t * LO + r * sqrt(max(0, 1.0 - HI*HI - LO*LO))
where HI and LO are the (signed) hi and lo components respectively
of the previous texture unit's texture shader result.
If the specified previous texture unit's texture shader result
contains only signed RGBA components, then the floating-point result
is computed by
result = s * Rprev + t * Gprev + r * Bprev
where Rprev, Gprev, and Bprev are the (signed) red, green, and blue
components respectively of the previous texture unit's RGBA texture
shader result.
If the specified previous texture unit's texture shader result
contains only unsigned RGBA components, then the dot product
computation depends on the RGBA_UNSIGNED_DOT_PRODUCT_MAPPING_NV
state. When the RGBA_UNSIGNED_DOT_PRODUCT_MAPPING_NV is
UNSIGNED_IDENTITY_NV, then the floating-point result for unsigned
RGBA components is computed by
result = s * Rprev + t * Gprev + r * Bprev
where Rprev, Gprev, and Bprev are the (unsigned) red, green, and
blue components respectively of the previous texture unit's RGBA
texture shader result.
When the RGBA_UNSIGNED_DOT_PRODUCT_MAPPING_NV is EXPAND_NORMAL_NV,
then the floating-point result for unsigned RGBA components is
computed by
result = s * (2.0*Rprev-1.0) + t * (2.0*Gprev-1.0) + r * (2.0*Bprev-1.0)
where Rprev, Gprev, and Bprev are the (unsigned) red, green, and
blue components respectively of the previous texture unit's RGBA
texture shader result.
If the previous texture input texture object specified by the
current texture shader stage's PREVIOUS_TEXTURE_INPUT_NV value has
a format type other than RGBA or HILO (the DSDT_MAG_INTENSITY_NV
base internal format does not count as an RGBA format type in this
context), then this texture shader stage is not consistent.
If the components of the previous texture input texture
object specified by the current texture shader stage's
PREVIOUS_TEXTURE_INPUT_NV value have mixed signedness, then
this texture shader stage is not consistent. For example,
the SIGNED_RGB_UNSIGNED_ALPHA_NV base internal format has mixed
signedness.
If the previous texture input texture shader operation specified by
the current texture shader stage's PREVIOUS_TEXTURE_INPUT_NV value
is DOT_PRODUCT_NV, then this texture shader stage is not consistent.
If the previous texture input texture shader result specified by
the current texture shader stage's PREVIOUS_TEXTURE_INPUT_NV value
is invalid, then this texture shader stage is not consistent.
If the previous texture input shader stage specified by the current
texture shader stage's PREVIOUS_TEXTURE_INPUT_NV value is not
consistent, then this texture shader stage is not consistent.
If this texture shader stage is not consistent, it operates as if
it is the NONE operation.
This operation in no way depends on any of the texture unit's
texture objects.
3.8.13.1.15 Dot Product Texture 2D
The DOT_PRODUCT_TEXTURE_2D_NV texture shader operation accesses the
texture unit's 2D texture object (as described in sections 3.8.4,
3.8.5, and 3.8.6) using (dotP,dotC) for the 2D texture coordinates.
The result of the texture access becomes both the shader result and
texture unit RGBA result (see table 3.E). The type of the shader
result depends on the format type of the accessed texture.
Assuming that i is the current texture shader stage, dotP is the
floating-point dot product result from the i-1 texture shader stage,
assuming the i-1 texture shader stage's operation is DOT_PRODUCT_NV.
dotC is the floating-point dot product result from the current
texture shader stage. dotC is computed in the identical manner
used to compute the floating-point result of the DOT_PRODUCT_NV
texture shader described in section 3.8.13.1.14.
If the previous texture input texture object specified by the
current texture shader stage's PREVIOUS_TEXTURE_INPUT_NV value has
a format type other than RGBA or HILO (the DSDT_MAG_INTENSITY_NV
base internal format does not count as an RGBA format type in this
context), then this texture shader stage is not consistent.
If the previous texture input texture shader operation specified by
the current texture shader stage's PREVIOUS_TEXTURE_INPUT_NV value
is DOT_PRODUCT_NV, then this texture shader stage is not consistent.
If the previous texture input texture shader result specified by
the current texture shader stage's PREVIOUS_TEXTURE_INPUT_NV value
is invalid, then this texture shader stage is not consistent.
If the previous texture input shader stage specified by the current
texture shader stage's PREVIOUS_TEXTURE_INPUT_NV value is not
consistent, then this texture shader stage is not consistent.
If the i-1 texture shader stage operation is not DOT_PRODUCT_NV,
then this texture shader stage is not consistent.
If the i-1 texture shader stage is not consistent, then
this texture shader stage is not consistent.
If the texture unit's 2D texture object is not consistent, then
this texture shader stage is not consistent.
If this texture shader stage is not consistent, it operates as if
it is the NONE operation.
3.8.13.1.16 Dot Product Texture Rectangle
The DOT_PRODUCT_TEXTURE_RECTANGLE_NV shader operation operates
identically to the DOT_PRODUCT_TEXTURE_2D_NV shader operation except
that the rectangle texture target is accessed rather than the 2D
texture target.
If the texture unit's rectangle texture object (rather than the 2D
texture object) is not consistent, then this texture shader stage
is not consistent.
3.8.13.1.17 Dot Product Texture Cube Map
The DOT_PRODUCT_TEXTURE_CUBE_MAP_NV texture shader operation
accesses the texture unit's cube map texture object (as described
in the ARB_texture_cube_map specification) using (dotPP,dotP,dotC)
for the 3D texture coordinates. The result of the texture access
becomes both the shader result and texture unit RGBA result (see
table 3.E). The type of the shader result depends on the format
type of the accessed texture.
Assuming that i is the current texture shader stage, dotPP is the
floating-point dot product texture shader result from the i-2
texture shader stage, assuming the i-2 texture shader stage's
operation is DOT_PRODUCT_NV. dotP is the floating-point dot
product texture shader result from the i-1 texture shader stage,
assuming the i-1 texture shader stage's operation is DOT_PRODUCT_NV.
dotC is the floating-point dot product result from the current
texture shader stage. dotC is computed in the identical manner
used to compute the floating-point result of the DOT_PRODUCT_NV
texture shader described in section 3.8.13.1.14.
If the previous texture input texture object specified by the
current texture shader stage's PREVIOUS_TEXTURE_INPUT_NV value has
a format type other than RGBA or HILO (the DSDT_MAG_INTENSITY_NV
base internal format does not count as an RGBA format type in this
context), then this texture shader stage is not consistent.
If the previous texture input texture shader operation specified by
the current texture shader stage's PREVIOUS_TEXTURE_INPUT_NV value
is DOT_PRODUCT_NV, then this texture shader stage is not consistent.
If the previous texture input texture shader result specified by
the current texture shader stage's PREVIOUS_TEXTURE_INPUT_NV value
is invalid, then this texture shader stage is not consistent.
If the previous texture input shader stage specified by the current
texture shader stage's PREVIOUS_TEXTURE_INPUT_NV value is not
consistent, then this texture shader stage is not consistent.
If either the i-1 or i-2 texture shader stage operation is not
DOT_PRODUCT_NV, then this texture shader stage is not consistent.
If either the i-1 or i-2 texture shader stage is not consistent, then
this texture shader stage is not consistent.
If the texture unit's cube map texture object is not consistent,
then this texture shader stage is not consistent.
If this texture shader stage is not consistent, it operates as if
it is the NONE operation.
3.8.13.1.18 Dot Product Reflect Cube Map
The DOT_PRODUCT_REFLECT_CUBE_MAP_NV and
DOT_PRODUCT_DIFFUSE_CUBE_MAP_NV (described in the section
3.8.13.1.20) texture shader operations are typically used together.
The DOT_PRODUCT_REFLECT_CUBE_MAP_NV texture shader operation
accesses the texture unit's cube map texture object (as described
in the ARB_texture_cube_map specification) using (rx,ry,rz) for
the 3D texture coordinates. The result of the texture access becomes
both the shader result and texture unit RGBA result (see table 3.E).
The type of the shader result depends on the format type of the
accessed texture.
Let R = (rx,ry,rz), N = (dotPP,dotP,dotC), and E = (qPP,qP,qC),
then
R = 2 * (N dot E) / (N dot N) * N - E
Assuming that i is the current texture shader stage, dotPP is
the floating-point dot product texture shader result from the
i-2 texture shader stage, assuming the i-2 texture shader stage's
operation is DOT_PRODUCT_NV. dotP is the floating-point dot product
texture shader result from the i-1 texture shader stage, assuming
the i-1 texture shader stage's operation is either DOT_PRODUCT_NV
or DOT_PRODUCT_DIFFUSE_NV. dotC is the floating-point dot product
result from the current texture shader stage. dotC is computed in
the identical manner used to compute the floating-point result of
the DOT_PRODUCT_NV texture shader described in section 3.8.13.1.14.
qPP is the q component of the i-2 texture shader stage's texture
coordinate set. qP is the q component of the i-1 texture shader
stage's texture coordinate set. qC is the q component of the
current texture shader stage's texture coordinate set.
If the previous texture input texture object specified by the
current texture shader stage's PREVIOUS_TEXTURE_INPUT_NV value has
a format type other than RGBA or HILO (the DSDT_MAG_INTENSITY_NV
base internal format does not count as an RGBA format type in this
context), then this texture shader stage is not consistent.
If the previous texture input texture shader operation specified by
the current texture shader stage's PREVIOUS_TEXTURE_INPUT_NV value
is DOT_PRODUCT_NV, then this texture shader stage is not consistent.
If the previous texture input texture shader result specified by
the current texture shader stage's PREVIOUS_TEXTURE_INPUT_NV value
is invalid, then this texture shader stage is not consistent.
If this texture shader stage's PREVIOUS_TEXTURE_INPUT_NV value
refers to texture unit i-2 or i-1, then this texture shader stage
is not consistent.
If the previous texture input shader stage specified by the current
texture shader stage's PREVIOUS_TEXTURE_INPUT_NV value is not
consistent, then this texture shader stage is not consistent.
If the i-2 texture shader stage operation is not
DOT_PRODUCT_NV, then this texture shader stage is not consistent.
If the i-1 texture shader stage operation is not DOT_PRODUCT_NV or
DOT_PRODUCT_DIFFUSE_CUBE_MAP_NV, then this texture shader stage is
not consistent.
If either the i-1 or i-2 texture shader stage is not consistent, then
this texture shader stage is not consistent.
If the texture unit's cube map texture object is not consistent,
then this texture shader stage is not consistent.
If this texture shader stage is not consistent, it operates as if
it is the NONE operation.
3.8.13.1.19 Dot Product Constant Eye Reflect Cube Map
The DOT_PRODUCT_CONST_EYE_REFLECT_CUBE_MAP_NV texture shader
operation operates the same as the DOT_PRODUCT_REFLECT_CUBE_MAP_NV
operation except that the eye vector E is equal to the three
floating-point values assigned to the texture shader's eye
constant (rather than the three q components of the given texture
unit and the previous two texture units).
The DOT_PRODUCT_CONST_EYE_REFLECT_CUBE_MAP_NV operation
has the same texture shader consistency rules as the
DOT_PRODUCT_REFLECT_CUBE_MAP_NV operation.
3.8.13.1.20 Dot Product Diffuse Cube Map
The DOT_PRODUCT_DIFFUSE_CUBE_MAP_NV texture shader operation
accesses the texture unit's cube map texture object (as described
in the ARB_texture_cube_map specification) using (dotP,dotC,dotN)
for the 3D texture coordinates. The result of the texture access
becomes both the shader result and texture unit RGBA result (see
table 3.E). The type of the shader result depends on the format
type of the accessed texture.
Assuming that i is the current texture shader stage, dotP is the
floating-point dot product texture shader result from the i-1 texture
shader stage, assuming the i-1 texture shader stage's operation
is DOT_PRODUCT_NV. dotC is the floating-point dot product result
from the current texture shader stage. dotC is computed in the
identical manner used to compute the floating-point result of the
DOT_PRODUCT_NV texture shader described in section 3.8.13.1.14.
dotN is the floating-point dot product texture shader result from
the i+1 texture shader stage, assuming the next texture shader
stage's operation is either DOT_PRODUCT_REFLECT_CUBE_MAP_NV or
DOT_PRODUCT_CONST_EYE_REFLECT_CUBE_MAP_NV.
If the texture unit's cube map texture object is not consistent,
then this operation operates as if it is the NONE operation.
If the previous texture unit's texture shader operation is
not DOT_PRODUCT_NV, then this operation operates as if it
is the NONE operation. If the next texture unit's texture
shader operation is neither DOT_PRODUCT_REFLECT_CUBE_MAP_NV nor
DOT_PRODUCT_CONST_EYE_REFLECT_CUBE_MAP_NV, then this operation
operates as if it is the NONE operation. If the next texture unit's
texture shader operation is either DOT_PRODUCT_REFLECT_CUBE_MAP_NV
or DOT_PRODUCT_CONST_EYE_REFLECT_CUBE_MAP_NV, but the next texture
unit operation is operating as if it is the NONE operation, then
this operation operates as if it is the NONE operation. If the
specified previous input texture unit is inconsistent or uses
the DOT_PRODUCT_NV texture shader operation, then this operation
operates as if it is the NONE operation.
If the previous texture input texture object specified by the
current texture shader stage's PREVIOUS_TEXTURE_INPUT_NV value has
a format type other than RGBA or HILO (the DSDT_MAG_INTENSITY_NV
base internal format does not count as an RGBA format type in this
context), then this texture shader stage is not consistent.
If the previous texture input texture shader operation specified by
the current texture shader stage's PREVIOUS_TEXTURE_INPUT_NV value
is DOT_PRODUCT_NV, then this texture shader stage is not consistent.
If the previous texture input texture shader result specified by
the current texture shader stage's PREVIOUS_TEXTURE_INPUT_NV value
is invalid, then this texture shader stage is not consistent.
If the previous texture input shader stage specified by the current
texture shader stage's PREVIOUS_TEXTURE_INPUT_NV value is not
consistent, then this texture shader stage is not consistent.
If the i-1 texture shader stage operation is not
DOT_PRODUCT_NV, then this texture shader stage is not consistent.
If the i+1 texture shader stage operation
is not DOT_PRODUCT_REFLECT_CUBE_MAP_NV or
DOT_PRODUCT_CONST_EYE_REFLECT_CUBE_MAP_NV, then this texture shader
stage is not consistent.
If either the i-1 or i+1 texture shader stage is not consistent,
then this texture shader stage is not consistent.
If the texture unit's cube map texture object is not consistent,
then this texture shader stage is not consistent.
If this texture shader stage is not consistent, it operates as if
it is the NONE operation.
3.8.13.1.21 Dot Product Depth Replace
The DOT_PRODUCT_DEPTH_REPLACE_NV texture shader operation replaces
the incoming fragments depth (in window coordinates, after polygon
offset and before conversion to fixed-point, i.e. in the [0,1]
range) with a new depth value. The new depth is computed as follows:
depth = dotP / dotC
Assuming that i is the current texture shader stage, dotP is the
floating-point dot product texture shader result from the i-1 texture
shader stage, assuming the i-1 texture shader stage's operation
is DOT_PRODUCT_NV. dotC is the floating-point dot product result
from the current texture shader stage. dotC is computed in the
identical manner used to compute the floating-point result of the
DOT_PRODUCT_NV texture shader described in section 3.8.13.1.14.
If the new depth value is outside of the range of the near and far
depth range values, the fragment is rejected.
The texture unit RGBA result generated is always (0,0,0,0).
The texture shader result is invalid.
If the previous texture input texture object specified by the
current texture shader stage's PREVIOUS_TEXTURE_INPUT_NV value has
a format type other than RGBA or HILO (the DSDT_MAG_INTENSITY_NV
base internal format does not count as an RGBA format type in this
context), then this texture shader stage is not consistent.
If the previous texture input texture shader operation specified by
the current texture shader stage's PREVIOUS_TEXTURE_INPUT_NV value
is DOT_PRODUCT_NV, then this texture shader stage is not consistent.
If the previous texture input texture shader result specified by
the current texture shader stage's PREVIOUS_TEXTURE_INPUT_NV value
is invalid, then this texture shader stage is not consistent.
If the previous texture input shader stage specified by the current
texture shader stage's PREVIOUS_TEXTURE_INPUT_NV value is not
consistent, then this texture shader stage is not consistent.
If the i-1 texture shader stage operation is not DOT_PRODUCT_NV,
then this texture shader stage is not consistent.
If the i-1 texture shader stage is not consistent, then
this texture shader stage is not consistent.
If any previous texture shader stage operation is
DOT_PRODUCT_DEPTH_REPLACE_NV and that previous stage is consistent,
then this texture shader stage is not consistent. (This eliminates
the potential for two stages to each be performing a depth replace
operation.)
If this texture shader stage is not consistent, it operates as if
it is the NONE operation.
This operation in no way depends on any of the texture unit's
texture objects.
3.8.13.2 Texture Shader Restrictions
There are various restrictions on possible texture shader
configurations. These restrictions are described in this section.
The error INVALID_OPERATION occurs if the SHADER_OPERATION_NV
parameter for texture unit 0 is assigned one of OFFSET_TEXTURE_2D_NV,
OFFSET_TEXTURE_2D_SCALE_NV, OFFSET_TEXTURE_RECTANGLE_NV,
OFFSET_TEXTURE_RECTANGLE_SCALE_NV, DEPENDENT_AR_TEXTURE_2D_NV,
DEPENDENT_GB_TEXTURE_2D_NV, DOT_PRODUCT_NV,
DOT_PRODUCT_DEPTH_REPLACE_NV, DOT_PRODUCT_TEXTURE_2D_NV,
DOT_PRODUCT_TEXTURE_RECTANGLE_NV, DOT_PRODUCT_TEXTURE_CUBE_MAP_NV,
DOT_PRODUCT_DIFFUSE_CUBE_MAP_NV, DOT_PRODUCT_REFLECT_CUBE_MAP_NV,
or DOT_PRODUCT_CONST_EYE_REFLECT_CUBE_MAP_NV. Each of these
texture shaders requires a previous texture shader result that
is not possible for texture unit 0. Therefore these shaders are
disallowed for texture unit 0.
The error INVALID_OPERATION occurs if the SHADER_OPERATION_NV
parameter for texture unit 1 is assigned one of
DOT_PRODUCT_DEPTH_REPLACE_NV, DOT_PRODUCT_TEXTURE_2D_NV,
DOT_PRODUCT_TEXTURE_RECTANGLE_NV, DOT_PRODUCT_TEXTURE_CUBE_MAP_NV,
DOT_PRODUCT_DIFFUSE_CUBE_MAP_NV, DOT_PRODUCT_REFLECT_CUBE_MAP_NV,
or DOT_PRODUCT_CONST_EYE_REFLECT_CUBE_MAP_NV. Each of these texture
shaders requires either two previous texture shader results or
a dot product result that cannot be generated by texture unit 0.
Therefore these shaders are disallowed for texture unit 1.
The error INVALID_OPERATION occurs if the SHADER_OPERATION_NV
parameter for texture unit 2 is assigned one of
DOT_PRODUCT_TEXTURE_CUBE_MAP_NV, DOT_PRODUCT_REFLECT_CUBE_MAP_NV,
DOT_PRODUCT_CONST_EYE_REFLECT_CUBE_MAP_NV. Each of these texture
shaders requires three previous texture shader results. Therefore
these shaders are disallowed for texture unit 2.
The error INVALID_OPERATION occurs if the SHADER_OPERATION_NV
parameter for texture unit n-1 (where n is the number of
supported texture units) is assigned either DOT_PRODUCT_NV or
DOT_PRODUCT_DIFFUSE_CUBE_MAP_NV. DOT_PRODUCT_NV is invalid for the
final texture shader stage because it is only useful as an input to
a successive texture shader stage. DOT_PRODUCT_DIFFUSE_CUBE_MAP_NV
is invalid for the final texture shader stage because it must be
followed by the DOT_PRODUCT_REFLECT_CUBE_MAP_NV operation in the
immediately successive stage. Therefore these shaders are disallowed
for texture unit n-1.
3.8.13.3 Required State
The state required for texture shaders consists of a single bit to
indicate whether or not texture shaders are enabled, a vector of
three floating-point values for the constant eye vector, and n sets
of per-texture unit state where n is the implementation-dependent
number of supported texture units. The set of per-texture unit
texture shader state consists of the twenty-one-valued integer
indicating the texture shader operation, four two-valued integers
indicating the cull modes, an integer indicating the previous texture
unit input, a two-valued integer indicating the RGBA unsigned dot
product mapping mode, a 2x2 floating-point matrix indicating the
texture offset transform, a floating-point value indicating the
texture offset scale, a floating-point value indicating the texture
offset bias, and a bit to indicate whether or not the texture shader
stage is consistent.
In the initial state, the texture shaders state is set as follows:
the texture shaders enable is disabled; the constant eye vector
is (0,0,-1); all the texture shader operations are NONE; the RGBA
unsigned dot product mapping mode is UNSIGNED_IDENTITY_NV; all the
cull mode values are GEQUAL; all the previous texture units are
TEXTURE0_ARB; each texture offset matrix is an identity matrix;
all texture offset scales are 1.0; and all texture offset biases
are 0.0."
Additions to Chapter 4 of the 1.2 Specification (Per-Fragment Operations
and the Frame Buffer)
None
Additions to Chapter 5 of the 1.2 Specification (Special Functions)
None
Additions to Chapter 6 of the 1.2 Specification (State and State Requests)
-- Section 6.1.3 "Texture Environments and Texture Functions"
Change the third sentence of the third paragraph to read:
"The env argument to GetTexEnv must be one of TEXTURE_ENV,
TEXTURE_FILTER_CONTROL_EXT, or TEXTURE_SHADER_NV."
Add to the end of the third paragraph:
"For GetTexEnv, when the target is TEXTURE_SHADER_NV, the texture
shader stage consistency can be queried with SHADER_CONSISTENT_NV."
Change the following sentence in the fouth paragraph to include
sizes for the newly introduced component:
"Queries of TEXTURE_RED_SIZE, TEXTURE_GREEN_SIZE, TEXTURE_BLUE_SIZE,
TEXTURE_ALPHA_SIZE, TEXTURE_LUMINANCE_SIZE, TEXTURE_DS_SIZE_EXT,
TEXTURE_DT_SIZE_EXT, TEXTURE_HI_SIZE_EXT, TEXTURE_LO_SIZE_EXT,
TEXTURE_MAG_SIZE_EXT, and TEXTURE_INTENSITY_SIZE return the actual
resolutions of the stored image array components, not the resolutions
specified when the image array was defined."
Add the following to the end of the fourth paragraph:
"Queries of TEXTURE_BORDER_COLOR return the same values as the
TEXTURE_BORDER_VALUES query."
-- Section 6.1.4 "Texture Queries"
Add the following to the end of the fourth paragraph:
"Calling GetTexImage with a color format (one of RED, GREEN,
BLUE, ALPHA, RGB, RGBA, BGR, BGRA, LUMINANCE, or LUMINANCE_ALPHA)
when the texture image is of a format type (see table 3.15)
other than RGBA (the DSDT_MAG_INTENSITY_NV base internal format
does not count as an RGBA format type in this context) causes the
error INVALID_OPERATION. Calling GetTexImage with a format of
HILO_NV when the texture image is of a format type (see table
3.15) other than HILO_NV causes the error INVALID_OPERATION.
Calling GetTexImage with a format of DSDT_NV when the texture image
is of a base internal format other than DSDT_NV causes the error
INVALID_OPERATION. Calling GetTexImage with a format of DSDT_MAG_NV
when the texture image is of a base internal format other than
DSDT_MAG_NV causes the error INVALID_OPERATION. Calling GetTexImage
with a format of DSDT_MAG_VIB_NV when the texture image is of a
base internal format other than DSDT_MAG_INTENSITY_NV causes the
error INVALID_OPERATION."
Additions to the GLX Specification
None
Dependencies on ARB_texture_env_add or EXT_texture_env_add
If neither ARB_texture_env_add nor EXT_texture_env_add are
implemented, then the references to ADD are invalid and should be
ignored.
Dependencies on ARB_texture_env_combine or EXT_texture_env_combine
If neither ARB_texture_env_combine nor EXT_texture_env_combine are
implemented, then the references to COMBINE_ARB and COMBINE_EXT
are invalid and should be ignored.
Dependencies on EXT_texture_lod_bias
If EXT_texture_lod_bias is not implemented, then the references to
TEXTURE_FILTER_CONTROL_EXT are invalid and should be ignored.
Dependencies on NV_texture_env_combine4
If NV_texture_env_combine4 is not implemented, then the references
to COMBINE4_NV are invalid and should be ignored.
Dependencies on NV_texture_rectangle
If NV_texture_rectangle is not implemented, then the references
to TEXTURE_RECTANGLE_NV, OFFSET_TEXTURE_RECTANGLE_NV,
OFFSET_TEXTURE_RECTANGLE_SCALE_NV, and
DOT_PRODUCT_TEXTURE_RECTANGLE_NV are invalid and should be ignored.
Dependencies on ARB_color_buffer_float
If ARB_color_buffer_float is also implemented, then the "max(0,x)",
"max(-1,x)" and "min(1,x)" functions for clamping in tables 3.18
and 3.19 simply return "x" without applying the maximum or minimum
function when CLAMP_FRAGMENT_COLOR_ARB is either FIXED_ONLY_ARB
when rendering to a floating-point color framebuffer or FALSE.
However clamping operations for texture shader operations
(specifically PASS_THROUGH_NV and OFFSET_TEXTURE_2D_SCALE_NV)
are performed independent of the CLAMP_FRAGMENT_COLOR_ARB state.
The intent of these interactions is to eliminate the specified
clamping behavior of texture environment functions when
CLAMP_FRAGMENT_COLOR_ARB indicates clamping should not be performed.
Errors
INVALID_ENUM is generated if one of HILO_NV, DSDT_NV, DSDT_MAG_NV,
or DSDT_MAG_VIBRANCE_NV is used as the format for DrawPixels,
ReadPixels, ColorTable, ColorSubTable, ConvolutionFilter1D,
ConvolutionFilter2D, SeparableFilter2D, GetColorTable,
GetConvolutionFilter, GetSeparableFilter, GetHistogram, or
GetMinmax.
INVALID_ENUM is generated if either UNSIGNED_INT_S8_S8_8_8_NV or
UNSIGNED_INT_8_8_S8_S8_REV is used as the type for DrawPixels,
ReadPixels, ColorTable, ColorSubTable, ConvolutionFilter1D,
ConvolutionFilter2D, SeparableFilter2D, GetColorTable,
GetConvolutionFilter, GetSeparableFilter, GetHistogram, or
GetMinmax.
INVALID_OPERATION is generated if a packed pixel format type listed
in table 3.8 is used with DrawPixels, ReadPixels, ColorTable,
ColorSubTable, ConvolutionFilter1D, ConvolutionFilter2D,
SeparableFilter2D, GetColorTable, GetConvolutionFilter,
GetSeparableFilter, GetHistogram, GetMinmax, TexImage1D, TexImage2D,
TexSubImage1D, TexSubImage2D, TexSubImage3d, or
GetTexImage but the format parameter does not match on of the allowed
Matching Pixel Formats listed in table 3.8 for the specified packed
type parameter.
INVALID_OPERATION is generated when TexImage1D or TexImage2D are
called and the format is HILO_NV and the internalformat is not
one of HILO_NV, HILO16_NV, SIGNED_HILO_NV, SIGNED_HILO16_NV; or if
the internalformat is one of HILO_NV, HILO16_NV, SIGNED_HILO_NV,
or SIGNED_HILO16_NV and the format is not HILO_NV.
INVALID_OPERATION is generated when TexImage2D, or TexImage1D is
called and if the format is DSDT_NV and the internalformat is not
either DSDT_NV or DSDT8_NV; or if the internal format is either
DSDT_NV or DSDT8_NV and the format is not DSDT_NV.
INVALID_OPERATION is generated when TexImage2D, or TexImage1D is
called and if the format is DSDT_MAG_NV and the internalformat
is not either DSDT_MAG_NV or DSDT8_MAG8_NV; or if the internal
format is either DSDT_MAG_NV or DSDT8_MAG8_NV and the format is
not DSDT_MAG_NV.
INVALID_OPERATION is generated when TexImage2D or TexImage1D is
called and if the format is DSDT_MAG_VIB_NV and the internalformat
is not either DSDT_MAG_INTENSITY_NV or DSDT8_MAG8_INTENSITY8_NV;
or if the internal format is either DSDT_MAG_INTENSITY_NV or
DSDT8_MAG8_INTENSITY8_NV and the format is not DSDT_MAG_VIB_NV.
INVALID_OPERATION is generated when CopyTexImage2D, CopyTexImage1D,
CopyTexSubImage2D, or CopyTexSubImage1D is called and the internal
format of the texture array to which the pixels are to be copied
is one of HILO_NV, HILO16_NV, SIGNED_HILO_NV, SIGNED_HILO16_NV,
DSDT_NV, DSDT8_NV, DSDT_MAG_NV, DSDT8_MAG8_NV, DSDT_MAG_INTENSITY_NV,
or DSDT8_MAG8_INTENSITY8_NV.
INVALID_OPERATION is generated when TexSubImage2D or
TexSubImage1D is called and the texture array's base internal format
is not one of HILO_NV, DSDT_NV, DSDT_MAG_NV, or DSDT_INTENSITY_NV,
and the format parameter is not one of COLOR_INDEX, RED,
GREEN, BLUE, ALPHA, RGB, RGBA, LUMINANCE, or
LUMINANCE_ALPHA
INVALID_OPERATION is generated when TexSubImage2D or
TexSubImage1D is called and the texture array's base internal format
is HILO_NV and the format parameter is not HILO_NV.
INVALID_OPERATION is generated when TexSubImage2D or
TexSubImage1D is called and the texture array's base internal format
is DSDT_NV and the format parameter is not DSDT_NV.
INVALID_OPERATION is generated when TexSubImage2D or
TexSubImage1D is called and the texture array's base internal format
is DSDT_MAG_NV and the format parameter is not DSDT_MAG_NV.
INVALID_OPERATION is generated when TexSubImage2D
or TexSubImage1D is called and the texture array's base internal
format is DSDT_MAG_INTENSITY_NV and the format parameter is not
DSDT_MAG_VIRBANCE_NV.
INVALID_OPERATION is generated when TexEnv is called and the
PREVIOUS_TEXTURE_INPUT_NV parameter for texture unit i is assigned
the value TEXTUREi_ARB where f i is greater than or equal to the
current active texture unit.
INVALID_OPERATION is generated when TexEnv is called and the
SHADER_OPERATION_NV parameter for texture unit 0 is assigned
one of OFFSET_TEXTURE_2D_NV, OFFSET_TEXTURE_2D_SCALE_NV,
OFFSET_TEXTURE_RECTANGLE_NV, OFFSET_TEXTURE_RECTANGLE_SCALE_NV,
DEPENDENT_AR_TEXTURE_2D_NV, DEPENDENT_GB_TEXTURE_2D_NV,
DOT_PRODUCT_NV, DOT_PRODUCT_DEPTH_REPLACE_NV,
DOT_PRODUCT_TEXTURE_2D_NV, DOT_PRODUCT_TEXTURE_RECTANGLE_NV,
DOT_PRODUCT_TEXTURE_CUBE_MAP_NV,
DOT_PRODUCT_DIFFUSE_CUBE_MAP_NV, DOT_PRODUCT_REFLECT_CUBE_MAP_NV.
or DOT_PRODUCT_CONST_EYE_REFLECT_CUBE_MAP_NV.
INVALID_OPERATION is generated when TexEnv is called
and the SHADER_OPERATION_NV parameter for texture
unit 1 is assigned one of DOT_PRODUCT_DEPTH_REPLACE_NV,
DOT_PRODUCT_TEXTURE_2D_NV, DOT_PRODUCT_TEXTURE_RECTANGLE_NV,
DOT_PRODUCT_TEXTURE_CUBE_MAP_NV,
DOT_PRODUCT_DIFFUSE_CUBE_MAP_NV, DOT_PRODUCT_REFLECT_CUBE_MAP_NV,
or DOT_PRODUCT_CONST_EYE_REFLECT_CUBE_MAP_NV.
INVALID_OPERATION is generated when TexEnv is called
and the SHADER_OPERATION_NV parameter for texture
unit 2 is assigned one of
DOT_PRODUCT_TEXTURE_CUBE_MAP_NV, DOT_PRODUCT_REFLECT_CUBE_MAP_NV,
or DOT_PRODUCT_CONST_EYE_REFLECT_CUBE_MAP_NV.
INVALID_OPERATION is generated when TexEnv is called and the
SHADER_OPERATION_NV parameter for texture unit n-1 (where n is the
number of supported texture units) is assigned either DOT_PRODUCT_NV
or DOT_PRODUCT_DIFFUSE_CUBE_MAP_NV.
INVALID_OPERATION is generated when GetTexImage is called with a
color format (one of RED, GREEN, BLUE, ALPHA, RGB, RGBA, BGR, BGRA,
LUMINANCE, or LUMINANCE_ALPHA) when the texture image is of a format
type (see table 3.15) other than RGBA (the DSDT_MAG_INTENSITY_NV
base internal format does not count as an RGBA format type in this
context).
INVALID_OPERATION is generated when GetTexImage is called with a
format of HILO_NV when the texture image is of a format type (see
table 3.15) other than HILO_NV.
INVALID_OPERATION is generated when GetTexImage is called with a
format of DSDT_NV when the texture image is of a base internal
format other than DSDT_NV.
INVALID_OPERATION is generated when GetTexImage is called with a
format of DSDT_MAG_NV when the texture image is of a base internal
format other than DSDT_MAG_NV.
INVALID_OPERATION is generated when GetTexImage is called with a
format of DSDT_MAG_VIBRANCE_NV when the texture image is of a base
internal format other than DSDT_MAG_INTENSITY_NV causes the error
INVALID_OPERATION."
New State
Add the following entries to table 6.12:
Get Value Type Get Command Initial Value Description Sec Attribute
-------------------- ------ -------------------- ------------- --------------------- --- ---------
TEXTURE_HI_SIZE_NV nxZ+ GetTexLevelParameter 0 xD texture image i's 3.8 texture
hi resolution
TEXTURE_LO_SIZE_NV nxZ+ GetTexLevelParameter 0 xD texture image i's 3.8 texture
lo resolution
TEXTURE_DS_SIZE_NV nxZ+ GetTexLevelParameter 0 xD texture image i's 3.8 texture
ds resolution
TEXTURE_DT_SIZE_NV nxZ+ GetTexLevelParameter 0 xD texture image i's 3.8 texture
dt resolution
TEXTURE_MAG_SIZE_NV nxZ+ GetTexLevelParameter 0 xD texture image i's 3.8 texture
mag resolution
Change the TEXTURE_BORDER_COLOR line in table 6.13 to read:
Get Value Type Get Command Initial Value Description Sec Attribute
------------------------ ------ --------------- ------------- --------------------- --- ---------
TEXTURE_BORDER_VALUES_NV 4xR GetTexParameter (0,0,0,0) Texture border values 3.8 texture
(TEXTURE_BORDER_COLOR)
Table 6.TextureShaders. Texture Shaders.
Get Value Type Get Command Initial Value Description Sec Attribute
--------------------------- ------ ----------- -------------------- ------------------- ------ --------------
HI_BIAS_NV R GetFloatv 0.0 Hi bias for HILO 3.6.3 pixel
LO_BIAS_NV R GetFloatv 0.0 Lo bias for HILO 3.6.3 pixel
DS_BIAS_NV R GetFloatv 0.0 Ds bias 3.6.3 pixel
DT_BIAS_NV R GetFloatv 0.0 Dt bias 3.6.3 pixel
MAGNITUDE_BIAS_NV R GetFloatv 0.0 Magnitude bias 3.6.3 pixel
VIBRANCE_BIAS_NV R GetFloatv 0.0 Vibrance bias 3.6.3 pixel
HI_SCALE_NV R GetFloatv 1.0 Hi scale 3.6.3 pixel
LO_SCALE_NV R GetFloatv 1.0 Lo scale 3.6.3 pixel
DS_SCALE_NV R GetFloatv 1.0 Ds scale 3.6.3 pixel
DT_SCALE_NV R GetFloatv 1.0 Dt scale 3.6.3 pixel
MAGNITUDE_SCALE_NV R GetFloatv 1.0 Magnitude scale 3.6.3 pixel
VIBRANCE_SCALE_NV R GetFloatv 1.0 Vibrance scale 3.6.3 pixel
TEXTURE_SHADER_NV B IsEnabled False Texture shaders 3.8 texture/enable
enable
SHADER_OPERATION_NV TxZ21 GetTexEnviv NONE Texture shader 3.8.13 texture
operation
CULL_MODES_NV Tx4xZ2 GetTexEnviv GEQUAL,GEQUAL, Texture shader 3.8.13 texture
GEQUAL,GEQUAL cull fragment modes
RGBA_UNSIGNED_- TxZ2 GetTexEnviv UNSIGNED_IDENTITY_NV Texture shader RGBA 3.8.13 texture
DOT_PRODUCT_MAPPING_NV dot product mapping
PREVIOUS_TEXTURE_INPUT_NV TxZn GetTexEnviv TEXTURE0_ARB Texture shader 3.8.13 texture
previous tex input
CONST_EYE_NV TxRx3 GetTexEnvfv (0,0,-1) Shader constant 3.8.13 texture
eye vector
OFFSET_TEXTURE_MATRIX_NV TxM2 GetTexEnvfv (1,0,0,1) 2x2 texture offset 3.8.13 texture
matrix
OFFSET_TEXTURE_SCALE_NV TxR GetTexEnvfv 1 Texture offset 3.8.13 texture
scale
OFFSET_TEXTURE_BIAS_NV TxR GetTexEnvfv 0 Texture offset 3.8.13 texture
bias
SHADER_CONSISTENT_NV TxB GetTexEnviv True Texture shader 3.8.13 texture
stage consistency
[ The "Tx" type prefix means that the state is per-texture unit. ]
[ The "Zn" type is an n-valued integer where n is the
implementation-dependent number of texture units supported.]
New Implementation State
None
Revision History
March 29, 2001 - document that using signed HILO with a dot product
shader forces the square root to zero if the 1.0-HI*HI-LO*LO value
is negative.
November 15, 2001 - document that depth replace is after polygon
offset; add polygon offset issue and multisample issue.
November 26, 2001 - Properly document the various TEXTURE_*_SIZE_NV
texture resolution query tokens. Add table 6.12 entries.
June 5, 2002 - Driver implementations before this date
incorrectly swap the HI and LO components when specifying
GL_TEXTURE_BORDER_VALUES_NV when rendering via hardware. Drivers
after this date have fixed the problem and match the specified
behavior.
July 2, 2003 - CULL_MODES_NV, OFFSET_TEXTURE_MATRIX_NV,
OFFSET_TEXTURE_2D_MATRIX_NV, and CONST_EYE_NV should not be specified
to work with glTexEnvi & glTexEnvf (they can only be used with
glTexEnviv & glTexEnvfv).
October 19, 2006 - Add interaction with ARB_color_buffer_float to
document how ths extension behaves when ARB_color_buffer_float is
also supported and when its CLAMP_FRAGMENT_COLOR_ARB state is either
FIXED_ONLY_ARB when rendering to a floating-point color framebuffer
or FALSE.
March 13, 2007 - Fix OFFSET_TEXTURE_2D_SCALE_NV operation to clamp
the scale factor to [0,1] before multiplying it by red, green,
and blue to match the hardware's actual behavior.