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: 1. NONE - Always generates a (0,0,0,0) texture unit RGBA result. Equivalent to disabling all texture targets in conventional OpenGL. 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). 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". 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. 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. 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. 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 parameter of Enable, Disable, and IsEnabled, and by the parameter of GetBooleanv, GetIntegerv, GetFloatv, and GetDoublev, and by the parameter of TexEnvf, TexEnvfv, TexEnvi, TexEnviv, GetTexEnvfv, and GetTexEnviv: TEXTURE_SHADER_NV 0x86DE When the parameter of TexEnvf, TexEnvfv, TexEnvi, TexEnviv, GetTexEnvfv, and GetTexEnviv is TEXTURE_SHADER_NV, then the value of 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 parameter of TexEnvfv, TexEnviv, GetTexEnvfv, and GetTexEnviv is TEXTURE_SHADER_NV, then the value of 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 parameter GetTexEnvfv and GetTexEnviv is TEXTURE_SHADER_NV, then the value of may be: SHADER_CONSISTENT_NV 0x86DD When the and parameters of TexEnvf, TexEnvfv, TexEnvi, and TexEnviv are TEXTURE_ENV and TEXTURE_ENV_MODE respectively, then the value of or the value pointed to by may be: NONE When the and parameters of TexEnvf, TexEnvfv, TexEnvi, and TexEnviv are TEXTURE_SHADER_NV and SHADER_OPERATION_NV respectively, then the value of or the value pointed to by 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 and parameters of TexEnvfv and TexEnviv are TEXTURE_SHADER_NV and CULL_MODES_NV respectively, then the value of or the value pointed to by may be: LESS GEQUAL When the and parameters of TexEnvf, TexEnvfv, TexEnvi, and TexEnviv are TEXTURE_SHADER_NV and RGBA_UNSIGNED_DOT_PRODUCT_MAPPING_NV respectively, then the value of or the value pointed to by may be: UNSIGNED_IDENTITY_NV (see NV_register_combiners) EXPAND_NORMAL_NV (see NV_register_combiners) When the and parameters of TexEnvf, TexEnvfv, TexEnvi, and TexEnviv are TEXTURE_SHADER_NV and PREVIOUS_TEXTURE_INPUT_NV respectively, then the value of or the value pointed to by may be: TEXTURE0_ARB TEXTURE1_ARB TEXTURE2_ARB TEXTURE3_ARB TEXTURE4_ARB TEXTURE5_ARB TEXTURE6_ARB TEXTURE7_ARB Accepted by the 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 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 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 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 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 parameter of TexParameteriv, TexParameterfv, GetTexParameterfv and GetTexParameteriv: TEXTURE_BORDER_VALUES_NV 0x871A Accepted by the 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_ARB entries apply only if NV_texture_env_combine4 is supported): SOURCE_RGB_EXT OPERAND_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_ARB 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)) Table 3.21: Arguments for COMBINE_RGB_ARB (or COMBINE_RGB_EXT) functions SOURCE_ALPHA_EXT OPERAND_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_ARB SRC_ALPHA max(0,At) ONE_MINUS_SRC_ALPHA (1-max(0,At)) 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.