Name NV_float_buffer Name Strings GL_NV_float_buffer WGL_NV_float_buffer GLX_NV_float_buffer Contact Pat Brown, NVIDIA Corporation (pbrown 'at' nvidia.com) Notice Copyright NVIDIA Corporation. IP Status NVIDIA Proprietary. Status Implemented in CineFX (NV30) Emulation driver, August 2002. Shipping in Release 40 NVIDIA driver for CineFX hardware, January 2003. Superseded by the more general ARB_texture_float and ARB_color_buffer_float extensions. However, NV3x-based GPUs are not capable enough to support the generality of the ARB extensions so the NV_float_buffer extension remains available for NV3x development and backward compatibility. Version Last Modified: 2006/11/03 NVIDIA Revision: 20 Number 281 Dependencies Written based on the wording of the OpenGL 1.3 specification and the WGL_ARB_pixel_format extension specification. The following extensions are required: * NV_fragment_program * NV_texture_rectangle * WGL_ARB_pixel_format * WGL_ARB_render_texture * WGL_NV_render_texture_rectangle EXT_paletted_texture trivially affects the definition of this extension. SGIX_depth_texture trivially affects the definition of this extension. NV_texture_shader trivially affects the definition of this extension. NV_half_float trivially affects the definition of this extension. ARB_color_buffer_float and ATI_pixel_format_float affect the definition of this extension. ARB_texture_float and ATI_texture_float affect the definition of this extension. This extension modifies EXT_framebuffer_object. Overview This extension builds upon NV_fragment_program to provide a framebuffer and texture format that allows fragment programs to read and write unconstrained floating point data. In unextended OpenGL, most computations dealing with color or depth buffers are typically constrained to operate on values in the range [0,1]. Computational results are also typically clamped to the range [0,1]. Color, texture, and depth buffers themselves also hold values mapped to the range [0,1]. The NV_fragment_program extension provides a general computational model that supports floating-point numbers constrained only by the precision of the underlying data types. The quantites computed by fragment programs do not necessarily correspond in number or in range to conventional attributes such as RGBA colors or depth values. Because of the range and precision constraints imposed by conventional fixed-point color buffers, it may be difficult (if not impossible) to use them to implement certain multi-pass algorithms. To enhance the extended range and precision available through fragment programs, this extension provides floating-point RGBA color buffers that can be used instead of conventional fixed-point RGBA color buffers. A floating-point RGBA color buffer consists of one to four floating-point components stored in the 16- or 32-bit floating-point formats (fp16 or fp32) defined in the NV_half_float and NV_fragment_program extensions. When a floating-point color buffer is used, the results of fragment programs, as written to the "x", "y", "z", and "w" components of the o[COLR] or o[COLH] output registers, are written directly to the color buffer without any clamping or modification. Certain per-fragment operations are bypassed when rendering to floating-point color buffers. A floating-point color buffer can also be used as a texture map, either by reading back the contents and then using conventional TexImage calls, or by using the buffer directly via the ARB_render_texture extension or the EXT_framebuffer_object extension. This extension has many uses. Some possible uses include: (1) Multi-pass algorithms with arbitrary intermediate results that don't have to be artifically forced into the range [0,1]. In addition, intermediate results can be written without having to worry about out-of-range values. (2) Deferred shading algorithms where an expensive fragment program is executed only after depth testing is fully complete. Instead, a simple program is executed, which stores the parameters necessary to produce a final result. After the entire scene is rendered, a second pass is executed over the entire frame buffer to execute the complex fragment program using the results written to the floating-point color buffer in the first pass. This will save the cost of applying complex fragment programs to fragments that will not appear in the final image. (3) Use floating-point texture maps to evaluate functions with arbitrary ranges. Arbitrary functions with a finite domain can be approximated using a texture map holding sample results and piecewise linear approximation. There are several significant limitations on the use of floating-point color buffers. First, floating-point color buffers do not support frame buffer blending. Second, floating-point texture maps do not support mipmapping or any texture filtering other than NEAREST. Third, floating-point texture maps must be 2D, and must use the NV_texture_rectangle extension. Issues Should the extension create a separate non-RGBA pixel formats or simply extend existing RGBA formats? RESOLVED: Extend existing RGBA formats. Since fragment programs generally build on RGBA semantics, it's cleaner to avoid creating a separate "XYZW" mode. There are several special semantics that need to be added: clear color state is now not clamped, and ReadPixels will clamp to [0,1] only if the source data comes from fixed-point color buffers. Fragment programs can be written that store data completely unrelated to color into a floating-point "RGBA" buffer. Can floating-point color buffers be displayed? If so, how? RESOLVED: Not in this extension. Floating-point color buffers can be used only as pbuffers. Hardware necessary to display floating-point color buffers would be expensive and consume significant memory bandwidth. Is it possible to encode more than four distinct values in a floating-point color buffer? RESOLVED: Yes. The NV_fragment_program extension contains pack and unpack instructions (PK2H, PK2US, PK4B, PK4UB, PK4UBG, UP2H, UP2US, UP4B, UP4UB, UP4UBG) that allow fragment programs to encode multiple values into a single 32-bit component. In particular, it is possible to pack two half-precision floats, two normalized unsigned shorts, or four normalized signed or unsigned bytes into a single 32-bit component. A program can use a pack instruction to pack multiple values into a single 32-bit component and then write the resulting component to a floating-point color buffer with 32-bit components. On a subsequent rendering pass, a program can read back the stored data (using texture mapping) and use the equivalent unpack instruction to restore the original values. The only data lost in this process comes from the loss of precision or clamping in the packing operation, where the original values are converted to data types with lower precision or a smaller data range. What happens when rendering to an floating-point color buffer if fragment program mode is disabled? Or when fragment program mode is enabled, but no program is loaded? RESOLVED: Fragment programs are required to use floating-point color buffers. An INVALID_OPERATION error is generated by any GL command that generates fragments if FRAGMENT_PROGRAM_NV is disabled. The same behavior already exists for conventional frame buffers if FRAGMENT_PROGRAM_NV is enabled but the bound fragment program is invalid. Should alpha test be supported with floating-point color buffers? RESOLVED: No. It is trivial to implement an alpha test in a fragment program using the KIL instruction, which requires no dedicated frame buffer logic. Should blending be supported with floating-point color buffers? RESOLVED: Not in this extension. While blending would clearly be useful, full-precision floating-point blenders are expensive. In addition, a computational model more general than traditional blending (with its 1-x operations and clamping) is desirable. The traditional OpenGL blending model would not be the most suitable computational model for future blend-enabled floating-point color buffers. An alternative to conventional blending (operating at a coarser granularity) is to (1) render a pass into the color buffer, (2) bind the color buffer as a texture rectangle using this extension and ARB_render_texture, (3) perform texture lookups in a fragment program using the TEX instruction with f[WPOS].xy as a 2D texture coordinate, and (4) perform the necessary blending between the passes using the same fragment program. Should we provide accumulation buffers for pixel formats with floating-point color buffers? RESOLVED: No. Accumulation operations contents can be achieved using fragment programs to perform the accumulation, which requires no dedicated frame buffer logic. Should fragment program color results be converted to match the format of the frame buffer, or should an error result? For example, what if we write to o[COLR] but have a 16-bit frame buffer? RESOLVED: Conversions can be performed simply in hardware, so no error semantics are required. This mechanism also allows the same programs to be shared between contexts with different pixel formats. Applications should be aware that if color components contain packed data, a data type mismatch may result in a floating-point data conversion that corrupts the packed data. How should floating-point color buffers interact with multisampling? For normal color buffers, the multiple samples for each pixel are required to be filtered down to a single pixel in the color buffer. Similar filtering on floating-point color buffers does not necessarily make sense. Should there even be a normal color buffer in this case? RESOLVED: The initial implementation of this extension does not provide floating-point color buffers that support multisampling. Multisample fragment operations (e.g., SAMPLE_COVERAGE) are explicitly not supported by extension. This extension does not modify the portion of the spec where multiple samples are resolved to a single color value. So if floating-point color buffers were provided, the multiple samples are filtered down to a single result value, most likely by computing a per-component average value. Conventional RGBA primitive antialiasing multiplies coverage by the alpha component of the fragment's color, with the assumption that alpha blending will be performed. How does antialiasing work with floating-point color buffers? RESOLVED: It doesn't. The computed coverage is not accessible to fragment programs and is discarded. Note also that conventional antialiasing requires alpha blending, which does not work for floating-point color buffers. What are the semantics for ReadPixels when using an floating-point color buffer? RESOLVED: ReadPixels from a floating-point color buffer works like any other RGBA read, except that the final results are not clamped to the range [0,1]. This ensures that we can save and restore floating-point color buffers using ReadPixels/DrawPixels. What are the semantics for Bitmap when using an floating-point color buffer? RESOLVED: Bitmap generates fragments using the current raster attributes, which are then passed to fragment programs like any other fragments. Bitmaps will be drawn using the color of the current raster position, whose components are clamped to [0,1] when the raster position is sent. What are the semantics for DrawPixels when using a floating-point color buffer? How about CopyPixels? RESOLVED: DrawPixels generates fragments with the originally specified color values; components are not clamped to [0,1]. For fixed-point color buffers, DrawPixels will generate fragments with clamped color components. CopyPixels is defined in the spec as a ReadPixels followed by a DrawPixels, and will operate similarly. This mechanism allows applications to write floating-point data directly into a floating-point color buffer without any clamping. Since DrawPixels and CopyPixels generate fragments and fragment programs are required to render to floating-point color buffers, a fragment program is still required to load a floating-point color buffer using DrawPixels. What are the semantics for Clear when using an floating-point color buffer? RESOLVED: Clears work as normal, except that values outside the range [0,1] can be written to the color buffer. The core spec is modified so that clear color values are not clamped to [0,1]. Instead, for fixed-point color buffers, clear colors are clamped to [0,1] at clear time. For compatibility with conventional OpenGL, queries of CLEAR_COLOR_VALUE will clamp components to [0,1]. A separate FLOAT_CLEAR_COLOR_VALUE_NV query is added to query unclamped color clear values. Why don't floating-point textures support filtering? What can be done to achieve texture filtering? RESOLVED: Extended OpenGL texture filtering (including mipmapping and support for anisotropic filters) is very computationally expensive. Even simple linear filtering for floating-point textures with large components is expensive. Linear filters can be implemented in fragment programs by doing multiple lookups into the same texture. Since fragment programs allow the use of arbitrary coordinates into arbitrary texture maps, this type of operation can be easily done. A 1D linear filter can be implemented using an nx1 texture rectangle with the following (untested) fragment program, assuming the 1D coordinate is in f[TEX0].x: ADDR H2.xy, f[TEX0].x, {0.0, 1.0}; FRCH H3.x, R1.x; # compute the blend factor TEX H0, H2.x, TEX0, RECT; # lookup 1st sample TEX H1, H2.y, TEX0, RECT; # lookup 2nd sample LRPH H0, H3.x, H1, H0; # blend A 2D linear filter can be implemented similarly, assuming the 2D coordinate is in f[TEX0].xy: ADDH H2, f[TEX0].xyxy, {0.0, 0.0, 1.0, 1.0}; FRCH H3.xy, H2.xyxy; # base weights ADDH H3.zw, 1.0, -H3.xyxy; # 1-base weights MULH H3, H3.xzxz, H3.yyww; # bilinear filter weights TEX H1, R2.xyxy, TEX0, RECT; # lookup 1st sample MULH H0, H1, H3.x; # blend TEX H1, R2.zyzy, TEX0, RECT; # lookup 2nd sample MADH H0, H1, H3.y, H0; # blend TEX H0, R2.xwxw, TEX0, RECT; # lookup 3rd sample MADH H0, H1, H3.z, H0; # blend TEX H1, R2.zwzw, TEX0, RECT; # lookup 4th sample MADH H0, H1, H3.w, H0; # blend Fragment programs can be used to perform more-or-less arbitrary filtering using similar methods, and the DDX and DDY instructions can be used to refine the shape of the filter. Why must the NV_texture_rectangle extension be used in order to use floating-point texture maps? RESOLVED: On many graphics hardware platforms, texture maps are stored using a special memory encodings designed to optimize rendering performance. In current hardware, conventional texture maps usually top out at 32 bits per texel. The logic required to encode and decode 128-bit texels (and frame buffer pixels) optimally is substantially more complex. What happens if you try to use an floating-point texture without a fragment program? RESOLVED: No error is generated, but that texture is effectively disabled. This is similar to the behavior if an application tried to use a normal texture having an inconsistent set of mipmaps. How does NV_float_buffer interact with the OpenGL 1.2 imaging subset? RESOLVED: The imaging subset as specified should work properly with floating-point color buffers, but is not modified by this extension. There are imaging operations (e.g., color tables, histograms) that expect the components they operate on to be in the range [0,1], and this extension makes no attempt to extend such functionality. How does NV_float_buffer interact with SGIS_generate_mipmap? RESOLVED: Since this extension supports only texture rectangles (which have no mipmaps), this issue is moot. In the general case, mipmaps should be generated using an appropriate downsample filter, where floating-point component values are averaged. Components should not be clamped during any such mipmap generation. What is the deal with the names of the clear color query tokens? RESOLVED: The "normal" OpenGL clear color (clamped to [0,1]) is queried using the token COLOR_CLEAR_VALUE. This extension provides a new query for unclamped values, using the token FLOAT_CLEAR_COLOR_VALUE_NV. Notice that "CLEAR" and "COLOR" are reversed due to a mistake made when the spec was first written. This spec lists the core query token, and originally had "CLEAR" and "COLOR" reversed there, too. Then again, the core specification is inconsistent since the queried state is set by calling glClearColor(), with "Clear" before "Color". What performance issues exist with this functionality? See the "NV3x Implementation Issues" section of the specification. How should the texture border color (values) be handled for float textures? RESOLVED: Clamp the texture border color (values) to [0,1] when sampling a float texture's border. In core OpenGL 1.0, the texture border color components are clamped to the range [01,]. The NV_texture_shader extension added support for signed texture components. We decided to provide GL_TEXTURE_BORDER_VALUES as a way of specifying a version of the texture border color whose components were not clamped to [0,1] when set. This was to provide a way of specifying negative texture border components. In practice, that has not proven particularly useful. No real applications are known to have specified negative texture border values components. Ideally, the unclamped GL_TEXTURE_BORDER_VALUES state could provide an unclamped (unmassaged) set of floating-point color components for the texture border color. This requires an additional 96 bits of state per texture unit to support this, and based on the experience with NV_texture_shader's support for texture border values outside the [0,1] range, it is simply not worth it. For compatibility with the NV_texture_shader extension, we provide language saying that floating-point textures clamp the components of the TEXTURE_BORDER_VALUES vector [0,1] when sampling the border color. New Procedures and Functions None. New Tokens Accepted by the parameter of TexImage2D and CopyTexImage2D: FLOAT_R_NV 0x8880 FLOAT_RG_NV 0x8881 FLOAT_RGB_NV 0x8882 FLOAT_RGBA_NV 0x8883 FLOAT_R16_NV 0x8884 FLOAT_R32_NV 0x8885 FLOAT_RG16_NV 0x8886 FLOAT_RG32_NV 0x8887 FLOAT_RGB16_NV 0x8888 FLOAT_RGB32_NV 0x8889 FLOAT_RGBA16_NV 0x888A FLOAT_RGBA32_NV 0x888B Accepted by the parameter of GetTexLevelParameterfv and GetTexLevelParameteriv: TEXTURE_FLOAT_COMPONENTS_NV 0x888C Accepted by the parameter of GetBooleanv, GetIntegerv, GetFloatv, and GetDoublev: FLOAT_CLEAR_COLOR_VALUE_NV 0x888D FLOAT_RGBA_MODE_NV 0x888E Accepted in the array of wglGetPixelFormatAttribivARB and wglGetPixelFormatAttribfvARB and in the and arrays of wglChoosePixelFormatARB: WGL_FLOAT_COMPONENTS_NV 0x20B0 WGL_BIND_TO_TEXTURE_RECTANGLE_FLOAT_R_NV 0x20B1 WGL_BIND_TO_TEXTURE_RECTANGLE_FLOAT_RG_NV 0x20B2 WGL_BIND_TO_TEXTURE_RECTANGLE_FLOAT_RGB_NV 0x20B3 WGL_BIND_TO_TEXTURE_RECTANGLE_FLOAT_RGBA_NV 0x20B4 Accepted in the array of wglCreatePbufferARB and returned in the parameter of wglQueryPbufferARB when is WGL_TEXTURE_FORMAT_ARB: WGL_TEXTURE_FLOAT_R_NV 0x20B5 WGL_TEXTURE_FLOAT_RG_NV 0x20B6 WGL_TEXTURE_FLOAT_RGB_NV 0x20B7 WGL_TEXTURE_FLOAT_RGBA_NV 0x20B8 Accepted in the array of glXGetFBConfigAttrib (and glXGetFBConfigAttribSGIX): GLX_FLOAT_COMPONENTS_NV 0x20B0 Additions to Chapter 2 of the OpenGL 1.3 Specification (OpenGL Operation) None. Additions to Chapter 3 of the OpenGL 1.3 Specification (Rasterization) Modify Section 3.6.4, Rasterization of Pixel Rectangles (p. 91) (modify first paragraph of "Final Conversion", p. 102) ... For RGBA components, the final conversion depends on the format of the color buffer. If the components of the color buffer are fixed-point, each element is clamped to [0,1] and converted to fixed-point according to the rules given in section 2.13.9 (Final Color Processing). If the components of the color buffer are floating-point, the elements are not modified. Modify Section 3.8.1, Texture Image Specification (p. 116) (modify last paragaph, p. 116) The selected groups are processed exactly as for DrawPixels stopping just before final conversion. For textures with fixed-point RGBA internal formats, each R, G, B, A component is clamped to [0,1]. (modify first paragraph, p. 117) Components are then selected from the resulting pixel groups to obtain a texture with the base internal format specified by (or derived from) . Table 3.15 summarizes the mapping of pixel group values to texture components, ... (add to end of first paragraph, p. 117) Specifying a value of incompatible with produces the error INVALID_OPERATION. A pixel format and texture internal format are compatible if the pixel format can generate a pixel group of the type listed in the "Pixel Group Type" column of Table 3.15 in the row corresponding to the base internal format. (add between first and second paragraphs, p.117) Textures with a base internal format of FLOAT_R_NV, FLOAT_RG_NV, FLOAT_RGB_NV, and FLOAT_RGBA_NV are known as floating-point textures. Floating-point textures are only supported for the TEXTURE_RECTANGLE_NV target. Specifying an floating-point texture with any other target will produce an INVALID_OPERATION error. (modify last paragraph, p. 117) The internal component resolution is the number of bits allocated to each component in a texture image. If internalformat is specified as a base internal format, the GL stores the resulting texture with internal component resolutions of its own choosing. If a sized internal format is specified, the memory allocation per texture component is assigned by the GL to match the allocations listed in Table 3.16 as closely as possible. ... (modify Table 3.15, p. 118 -- Respecify this table with all extensions relevant to texture formats supported by NVIDIA. For this extension, add four base internal formats.) Base Internal Pixel Component Internal Format Group Type Values Components --------------------- ---------- --------- --------------- ALPHA RGBA A A LUMINANCE RGBA R L LUMINANCE_ALPHA RGBA R,A L,A INTENSITY RGBA R I RGB RGBA R,G,B R,G,B RGBA RGBA R,G,B,A R,G,B,A * COLOR_INDEX CI CI CI * DEPTH_COMPONENT DEPTH DEPTH DEPTH * HILO_NV HILO HI,LO HI,LO * DSDT_NV TEXOFF DS,DT DS,DT * DSDT_MAG_NV TEXOFF DS,DT,MAG DS,DT,MAG * DSDT_MAG_INTENSITY_NV TEXOFF or RGBA DS,DT,MAG,VIB DS,DT,MAG,I FLOAT_R_NV RGBA R R (float) FLOAT_RG_NV RGBA R,G R,G (float) FLOAT_RGB_NV RGBA R,G,B R,G,B (float) FLOAT_RGBA_NV RGBA R,G,B,A R,G,B,A (float) Table 3.15: Conversion from pixel groups to internal texture components. "Pixel Group Type" defines the type of pixel group required for the specified internal format. All internal components are stored as unsigned-fixed point numbers, except for DS/DT (signed fixed-point numbers) and floating-point R,G,B,A (signed floating-point numbers). See Section 3.8.12 for a description of texture components R, G, B, A, L, and I. See NV_texture_shader spec (Section 3.8.13) for a description of texture components HI, LO, DS, DT, and MAG. * - indicates formats found in other extension specs: COLOR_INDEX in EXT_paletted texture; DEPTH_COMPONENT in SGIX_depth_texture; and HILO_NV, DSDT_NV, DSDT_MAG_NV, DSDT_MAG_INTENSITY_NV in NV_texture_shader. (modify Table 3.16, p. 119 -- Respecify this table with all extensions relevant to sized texture internal formats supported by NVIDIA. For this extension, add eight sized internal formats.) Sized Base Int. Format Int. Format Component Name / Type-Size ------------------- --------------- --------------------------- ALPHA4 ALPHA A/U4 ALPHA8 ALPHA A/U8 ALPHA12 ALPHA A/U12 ALPHA16 ALPHA A/U16 LUMINANCE4 LUMINANCE L/U4 LUMINANCE8 LUMINANCE L/U8 LUMINANCE12 LUMINANCE L/U12 LUMINANCE16 LUMINANCE L/U16 LUMINANCE4_ALPHA4 LUMINANCE_ALPHA A/U4 L/U4 LUMINANCE6_ALPHA2 LUMINANCE_ALPHA A/U2 L/U6 LUMINANCE8_ALPHA8 LUMINANCE_ALPHA A/U8 L/U8 LUMINANCE12_ALPHA4 LUMINANCE_ALPHA A/U4 L/U12 LUMINANCE12_ALPHA12 LUMINANCE_ALPHA A/U12 L/U12 LUMINANCE16_ALPHA16 LUMINANCE_ALPHA A/U16 L/U16 INTENSITY4 INTENSITY I/U4 INTENSITY8 INTENSITY I/U8 INTENSITY12 INTENSITY I/U12 INTENSITY16 INTENSITY I/U16 R3_G3_B2 RGB R/U3 G/U3 B/U2 RGB4 RGB R/U4 G/U4 B/U4 RGB5 RGB R/U5 G/U5 B/U5 RGB8 RGB R/U8 G/U8 B/U8 RGB10 RGB R/U10 G/U10 B/10 RGB12 RGB R/U12 G/U12 B/U12 RGB16 RGB R/U16 G/U16 B/U16 RGBA2 RGBA R/U2 G/U2 B/U2 A/U2 RGBA4 RGBA R/U4 G/U4 B/U4 A/U4 RGB5_A1 RGBA R/U5 G/U5 B/U5 A/U1 RGBA8 RGBA R/U8 G/U8 B/U8 A/U8 RGB10_A2 RGBA R/U10 G/U10 B/U10 A/U2 RGBA12 RGBA R/U12 G/U12 B/U12 A/U12 RGBA16 RGBA R/U16 G/U16 B/U16 A/U16 * COLOR_INDEX1_EXT COLOR_INDEX CI/U1 * COLOR_INDEX2_EXT COLOR_INDEX CI/U2 * COLOR_INDEX4_EXT COLOR_INDEX CI/U4 * COLOR_INDEX8_EXT COLOR_INDEX CI/U8 * COLOR_INDEX16_EXT COLOR_INDEX CI/U16 * DEPTH_COMPONENT16_SGIX DEPTH_COMPONENT Z/U16 * DEPTH_COMPONENT24_SGIX DEPTH_COMPONENT Z/U24 * DEPTH_COMPONENT32_SGIX DEPTH_COMPONENT Z/U32 * HILO16_NV HILO HI/U16 LO/U16 * SIGNED_HILO16_NV HILO HI/S16 LO/S16 * SIGNED_RGBA8_NV RGBA R/S8 G/S8 B/S8 A/S8 * SIGNED_RGB8_ UNSIGNED_ALPHA8_NV RGBA R/S8 G/S8 B/S8 A/U8 * SIGNED_RGB8_NV RGB R/S8 G/S8 B/S8 * SIGNED_LUMINANCE8_NV LUMINANCE L/S8 * SIGNED_LUMINANCE8_ ALPHA8_NV LUMINANCE_ALPHA L/S8 A/S8 * SIGNED_ALPHA8_NV ALPHA A/S8 * SIGNED_INTENSITY8_NV INTENSITY I/S8 * DSDT8_NV DSDT_NV DS/S8 DT/S8 * DSDT8_MAG8_NV DSDT_MAG_NV DS/S8 DT/S8 MAG/U8 * DSDT8_MAG8_ DSDT_MAG_ INTENSITY8_NV INTENSITY_NV DS/S8 DT/S8 MAG/U8 I/U8 FLOAT_R16_NV FLOAT_R_NV R/F16 FLOAT_R32_NV FLOAT_R_NV R/F32 FLOAT_RG16_NV FLOAT_RG_NV R/F16 G/F16 FLOAT_RG32_NV FLOAT_RG_NV R/F32 G/F32 FLOAT_RGB16_NV FLOAT_RGB_NV R/F16 G/F16 B/F16 FLOAT_RGB32_NV FLOAT_RGB_NV R/F32 G/F32 B/F32 FLOAT_RGBA16_NV FLOAT_RGBA_NV R/F16 G/F16 B/F16 A/F16 FLOAT_RGBA32_NV FLOAT_RGBA_NV R/F32 G/F32 B/F32 A/F32 Table 3.16: Sized Internal Formats. Describes the correspondence of sized internal formats to base internal formats, and desired component resolutions. Component resolution descriptions are of the form "/", where NAME specifies the component name in Table 3.15, TYPE is "U" for unsigned fixed-point, "S" for signed fixed-point, and "F" for unsigned floating-point. is the number of requested bits per component. * - indicates formats found in other extension specs: COLOR_INDEX in EXT_paletted texture; DEPTH_COMPONENT in SGIX_depth_texture; and HILO_NV, DSDT_NV, DSDT_MAG_NV, DSDT_MAG_INTENSITY_NV in NV_texture_shader. Modify Section 3.8,7, Minification (p. 141) Change the last paragraph (as modified by the NV_texture_shader extension) to read (only the last sentence changes from the NV_texture_shader version): "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 and components of floating-point textures are clamped to [0,1]; signed components (not including floating-point textures) are clamped to [-1,1]." (Add after the last paragraph in the section) Floating-point textures (those with a base internal format of FLOAT_R_NV, FLOAT_RG_NV, FLOAT_RGB_NV, or FLOAT_RGBA_NV) do not support texture filters other than NEAREST. For such textures, NEAREST filtering is applied regardless of the setting of TEXTURE_MIN_FILTER. Modify Section 3.8.8, Magnification (p. 141) (Add after the last paragraph in the section) Floating-point textures (those with a base internal format of FLOAT_R_NV, FLOAT_RG_NV, FLOAT_RGB_NV, or FLOAT_RGBA_NV) do not support texture filters other than NEAREST. For such textures, NEAREST filtering is applied regardless of the setting of TEXTURE_MAG_FILTER. Modify Section 3.8.13, Texture Environments and Texture Functions (p. 147) (Add paragraph after discussion of all the values used in the miscellaneous tables in this section.) If the base internal format is HILO_NV, DSDT_NV, DSDT_MAG_NV, DSDT_MAG_INTENSITY_NV, FLOAT_R_NV, FLOAT_RG_NV, FLOAT_RGB_NV, or FLOAT_RGBA_NV, the texture lookup results are not supported using conventional OpenGL texture functions. In this case, the corresponding texture function is NONE (Cv = Cf, Av = Af), and it is as though texture mapping were disabled for that texture unit. Modify Section 3.11, Antialiasing Application (p. 155) Finally, if antialiasing is enabled for the primitive from which a rasterized fragment was produced, then the computed coverage value may be applied to the fragment. In RGBA mode with fixed-point frame buffers, the value is multiplied by the fragment's alpha (A) value to yield a final alpha value. In RGBA mode with floating-point frame buffers, the coverage value is simply discarded. In color index mode, the value is used to set the low order bits of the color index value as described in section 3.2. Additions to Chapter 4 of the OpenGL 1.3 Specification (Per-Fragment Operations and the Frame Buffer) Modify Chapter 4 Introduction (p. 156) (replace next-to-last paragraph) The GL provides three types of color buffers: color index, fixed-point RGBA, or floating-point RGBA. Color index buffers consist of unsigned integer color indices. Fixed-point RGBA buffers consist of R, G, B, and optionally, A unsigned integer values. Floating-point RGBA buffers consist of R, and optionally, G, B, and A floating-point component values, corresponding to the X, Y, Z, and W outputs, respectively, of a fragment program. The number of bitplanes in each of the color buffers, the depth buffer, ... Modify Section 4.1.3, Multisample Fragment Operations (p. 158) This step applies only for fixed-point RGBA color buffers. Otherwise, proceed to the next step. ... Modify Section 4.1.4, Alpha Test (p. 159) This step applies only for fixed-point RGBA color buffers. Otherwise, proceed to the next step. ... Modify Section 4.1.7, Blending (p. 161) (modify second paragraph) This blending is dependent on the incoming fragment's alpha value and that of the corresponding currently stored pixel. Blending applies only for fixed-point RGBA color buffers; otherwise, it is bypassed. ... Modify Section 4.1.8, Dithering (p. 165) Dithering selects between two color values or indices. Dithering does not apply to floating-point RGBA color buffers. ... Modify Section 4.1.9, Logical Operation (p. 165) Finally, a logical operation is applied between the incoming fragment's color or index values and the color or index values stored at the corresponding location in the frame buffer. Logical operations do not apply to floating-point color buffers. ... Modify Section 4.2.3, Clearing the Buffers (p. 171) ... void ClearColor(float r, float g, float b, float a); sets the clear value for RGBA color buffers. When a fixed-point color buffer is cleared, the effective clear color is derived by clamping each component to [0,1] and converting to fixed-point according to the rules in section 2.13.9. When a floating-point color buffer is cleared, the components of the clear value are used directly without being clamped. Modify Section 4.2.4, The Accumulation Buffer (p. 172) (modify last paragraph) ... If there is no accumulation buffer, or if color buffer is not fixed-point RGBA, Accum generates the error INVALID_OPERATION. Modify Section 4.3.2, Reading Pixels (modify "Conversion of RGBA Values", p. 176) This step applies only if the GL is in RGBA mode, and then only if format is neither STENCIL INDEX nor DEPTH COMPONENT. The R, G, B, and A values form a group of elements. If the color buffer has fixed-point format, each element is taken to be a fixed-point value in [0,1] with m bits, where m is the number of bits in the corresponding color component of the selected buffer (see section 2.13.9). (add to end of "Final Conversion", p. 177) ... For an RGBA color, components are clamped depending on the data type of the buffer being read. For fixed-point buffers, each component is clamped to [0.1]. For floating-point buffers, if is not FLOAT or HALF_FLOAT_NV, each component is clamped to [0,1] if is unsigned or [-1,1] if is signed and then converted according to Table 4.7. Modify section 4.4.4, as defined by EXT_framebuffer_object, definition of color-renderable: * An internal format is "color-renderable" if it is RGB, RGBA, FLOAT_R_NV, FLOAT_RG_NV, FLOAT_RGB_NV, FLOAT_RGBA_NV, or one of the formats from table 3.16 whose base internal format is RGB, RGBA, FLOAT_R_NV, FLOAT_RG_NV, FLOAT_RGB_NV, or FLOAT_RGBA_NV. No other formats, including compressed internal formats, are color-renderable. Additions to Chapter 5 of the OpenGL 1.3 Specification (Special Functions) None. Additions to Chapter 6 of the OpenGL 1.3 Specification (State and State Requests) Modify Section 6.1.4, Texture Queries (p. 200) Modify Table 6.1 (add new rows, corresponding to new internal formats, p. 202) Base Internal Format R G B A -------------------- --- --- --- --- FLOAT_R_NV R 0 0 1 FLOAT_RG_NV R G 0 1 FLOAT_RGB_NV R G B 1 FLOAT_RGBA_NV R G B A Additions to Appendix A of the OpenGL 1.3 Specification (Invariance) None. Additions to the WGL Specification First, close your eyes and pretend that a WGL specification actually existed. Maybe if we all concentrate hard enough, one will magically appear. Modify/add to the description of in wglGetPixelFormatAttribivARB and in wglGetPixelFormatAttribfvARB: WGL_FLOAT_COMPONENTS_NV True if the R, G, B, and A components of each color buffer are represented as (unclamped) floating-point numbers. WGL_BIND_TO_TEXTURE_RECTANGLE_FLOAT_R_NV WGL_BIND_TO_TEXTURE_RECTANGLE_FLOAT_RG_NV WGL_BIND_TO_TEXTURE_RECTANGLE_FLOAT_RGB_NV WGL_BIND_TO_TEXTURE_RECTANGLE_FLOAT_RGBA_NV True if the pixel format describes a floating-point color that can be bound to a texture rectangle with internal formats of FLOAT_R_NV, FLOAT_RG_NV, FLOAT_RGB_NV, or FLOAT_RGBA_NV, respectively. Currently only pbuffers can be bound as textures so this attribute will only be TRUE if WGL_DRAW_TO_PBUFFER is also TRUE. Additionally, floating-point color buffers can not be bound to texture targets other than TEXTURE_RECTANGLE_NV. Add new table entries for pixel format attribute matching in wglChoosePixelFormatARB. Attribute Type Match Criteria ------------------------- ------- -------------- WGL_FLOAT_COMPONENTS_NV boolean exact WGL_BIND_TO_TEXTURE_ boolean exact RECTANGLE_FLOAT_R_NV WGL_BIND_TO_TEXTURE_ boolean exact RECTANGLE_FLOAT_RG_NV WGL_BIND_TO_TEXTURE_ boolean exact RECTANGLE_FLOAT_RGB_NV WGL_BIND_TO_TEXTURE_ boolean exact RECTANGLE_FLOAT_RGBA_NV (In the wglCreatePbufferARB section, modify the attribute list) WGL_TEXTURE_FORMAT_ARB This attribute indicates the base internal format of the texture that will be created when a color buffer of a pbuffer is bound to a texture map. It can be set to WGL_TEXTURE_RGB_ARB (indicating an internal format of RGB), WGL_TEXTURE_RGBA_ARB (indicating a base internal format of RGBA), WGL_TEXTURE_FLOAT_R_NV (indicating a base internal format of FLOAT_R_NV), WGL_TEXTURE_FLOAT_RG_NV (indicating a base internal format of FLOAT_RG_NV), WGL_TEXTURE_FLOAT_RGB_NV (indicating a base internal format of FLOAT_RGB_NV), WGL_TEXTURE_FLOAT_RGBA_NV (indicating a base internal format of FLOAT_RGBA_NV), or WGL_NO_TEXTURE_ARB. The default value is WGL_NO_TEXTURE_ARB. (In the wglCreatePbufferARB section, modify the discussion of what happens to the depth/stencil/accum buffers when switching between mipmap levels or cube map faces.) For pbuffers with a texture format of WGL_TEXTURE_RGB_ARB, WGL_TEXTURE_RGBA_ARB, WGL_TEXTURE_FLOAT_R_NV, WGL_TEXTURE_FLOAT_RG_NV, WGL_TEXTURE_FLOAT_RGB_NV, or WGL_TEXTURE_FLOAT_RGBA_NV, there will be a separate set of color buffers for each mipmap level and cube map face in the pbuffer. Otherwise, the WGL implementation is free to share a single set of color, auxillary, and accumulation buffers between levels or faces. (In the wglCreatePbufferARB section, modify the error list) ERROR_INVALID_DATA WGL_TEXTURE_FORMAT_ARB is WGL_TEXTURE_FLOAT_R_NV, WGL_TEXTURE_FLOAT_RG_NV, WGL_TEXTURE_FLOAT_RGB_NV, or WGL_TEXTURE_FLOAT_RGBA_NV, and WGL_TEXTURE_TARGET_ARB is not WGL_TEXTURE_RECTANGLE_NV. ERROR_INVALID_DATA WGL_TEXTURE_FORMAT_ARB is WGL_TEXTURE_FLOAT_R_NV, WGL_TEXTURE_TARGET_ARB is WGL_TEXTURE_RECTANGLE_NV, and the WGL_BIND_TO_TEXTURE_RECTANGLE_FLOAT_R_NV attribute is not set in the pixel format. ERROR_INVALID_DATA WGL_TEXTURE_FORMAT_ARB is WGL_TEXTURE_FLOAT_RG_NV, WGL_TEXTURE_TARGET_ARB is WGL_TEXTURE_RECTANGLE_NV, and the WGL_BIND_TO_TEXTURE_RECTANGLE_FLOAT_RG_NV attribute is not set in the pixel format. ERROR_INVALID_DATA WGL_TEXTURE_FORMAT_ARB is WGL_TEXTURE_FLOAT_RGB_NV, WGL_TEXTURE_TARGET_ARB is WGL_TEXTURE_RECTANGLE_NV, and the WGL_BIND_TO_TEXTURE_RECTANGLE_FLOAT_RGB_NV attribute is not set in the pixel format. ERROR_INVALID_DATA WGL_TEXTURE_FORMAT_ARB is WGL_TEXTURE_FLOAT_RGBA_NV, WGL_TEXTURE_TARGET_ARB is WGL_TEXTURE_RECTANGLE_NV, and the WGL_BIND_TO_TEXTURE_RECTANGLE_FLOAT_RGBA_NV attribute is not set in the pixel format. Modify wglBindTexImageARB: ... The pbuffer attribute WGL_TEXTURE_FORMAT_ARB determines the base internal format of the texture. The format-specific component sizes are also determined by pbuffer attributes as shown in the table below. The component sizes are dependent on the format of the texture. Component Size Format --------- ------------------------ ---------------------------- R WGL_RED_BITS_ARB RGB, RGBA, FLOAT_R, FLOAT_RG, FLOAT_RGB, FLOAT_RGBA G WGL_GREEN_BITS_ARB RGB, RGBA, FLOAT_R, FLOAT_RG, FLOAT_RGB, FLOAT_RGBA B WGL_BLUE_BITS_ARB RGB, RGBA, FLOAT_R, FLOAT_RG, FLOAT_RGB, FLOAT_RGBA A WGL_ALPHA_BITS_ARB RGB, RGBA, FLOAT_R, FLOAT_RG, FLOAT_RGB, FLOAT_RGBA Additions to the AGL Specification None Additions to the GLX Specification The GLX_FLOAT_COMPONENTS_NV framebuffer config attribute is a boolean (or GLX_DONT_CARE) indicating if floating-point components are requested. Dependencies on EXT_paletted_texture, SGIX_depth_texture, and NV_texture_shader If any of these extensions are not supported, the rows in Tables 3.15 and 3.16 corresponding to texture formats defined by the unsupported extension should be removed. If NV_texture_shader is not supported, ignore the amended paragraph from the NV_texture_shader specificiaton describing TEXTURE_BORDER_VALUES clamping in favor of the original OpenGL specification language. Dependencies on NV_half_float If GL_NV_half_float is not supported, all references to HALF_FLOAT_NV should be deleted. Dependencies on ARB_color_buffer_float and ATI_pixel_format_float If ARB_color_buffer_float and ATI_pixel_format_float are also supported, the GL would have two different floating-point frame buffer models with different restrictions. To avoid having to carry these differences all the way down the pipeline and provide two distinct sets of frame buffer formats, the following limitations on rendering to floating-point color buffers in this extension are removed if ARB_color_buffer_float or ATI_pixel_format_float is supported: Modify Section 3.11, Antialiasing Application (p. 155) ... In RGBA mode with floating-point frame buffers, the coverage value is simply discarded. ... Modify Section 4.1.3, Multisample Fragment Operations (p. 158) This step applies only for fixed-point RGBA color buffers. Otherwise, proceed to the next step. ... Modify Section 4.1.4, Alpha Test (p. 159) This step applies only for fixed-point RGBA color buffers. Otherwise, proceed to the next step. ... Modify Section 4.1.7, Blending (p. 161) (modify second paragraph) This blending is dependent on the incoming fragment's alpha value and that of the corresponding currently stored pixel. Blending applies only for fixed-point RGBA color buffers; otherwise, it is bypassed. ... Modify Section 4.2.4, The Accumulation Buffer (p. 172) (modify last paragraph) ..., or if color buffer is not fixed-point RGBA, When blending is enabled with a floating-point color buffer, the spec language in ARB_color_buffer_float describes how blending is performed. The above restrictions remain in effect on NV3X (GeForce FX, Quadro FX) hardware, where neither ARB_color_buffer_float nor ATI_pixel_format_float is supported. Additionally, if ARB_color_buffer_float or ATI_pixel_format_float is supported, the following errors are not generated: INVALID_OPERATION is generated by Begin, DrawPixels, Bitmap, CopyPixels, or a command that performs an explicit Begin if the color buffer has a floating-point RGBA format and FRAGMENT_PROGRAM_NV is disabled. INVALID_OPERATION is generated by Accum if the color buffer has a color index or floating-point RGBA format. Dependencies on ARB_texture_float and ATI_texture_float If ARB_texture_float or ATI_texture_float is also supported, the GL would have two different sets of floating-point textures with different restrictions. To avoid having to carry these differences all the way down the pipeline, the following limitations on filtering of NV_float_buffer textures are removed if ARB_texture_float or ATI_texture_float is supported: Modify Section 3.8,7, Minification (p. 141) (Add after the last paragraph in the section) Floating-point textures (those with a base internal format of FLOAT_R_NV, FLOAT_RG_NV, FLOAT_RGB_NV, or FLOAT_RGBA_NV) do not support texture filters other than NEAREST. For such textures, NEAREST filtering is applied regardless of the setting of TEXTURE_MIN_FILTER. Modify Section 3.8.8, Magnification (p. 141) (Add after the last paragraph in the section) Floating-point textures (those with a base internal format of FLOAT_R_NV, FLOAT_RG_NV, FLOAT_RGB_NV, or FLOAT_RGBA_NV) do not support texture filters other than NEAREST. For such textures, NEAREST filtering is applied regardless of the setting of TEXTURE_MAG_FILTER. The above restrictions remain in effect on NV3X (GeForce FX, Quadro FX) hardware, where ARB_texture_float and ATI_texture_float are not supported. The following restriction requiring the use of rectangle textures does remain in effect for NV_float_buffer texture formats, even though ARB_texture_float and ATI_texture_float provides the ability to use floating-point textures with non-rectangle targets. If this capability is required, use the texture formats defined in ARB_texture_float or ATI_texture_float. (add between first and second paragraphs, p.117) Textures with a base internal format of FLOAT_R_NV, FLOAT_RG_NV, FLOAT_RGB_NV, and FLOAT_RGBA_NV are known as floating-point textures. Floating-point textures are only supported for the TEXTURE_RECTANGLE_NV target. Specifying an floating-point texture with any other target will produce an INVALID_OPERATION error. Dependencies on EXT_framebuffer_object If EXT_framebuffer_object is not supported, then ignore any reference to EXT_framebuffer_object. GLX Protocol None. Errors INVALID_OPERATION is generated by Begin, DrawPixels, Bitmap, CopyPixels, or a command that performs an explicit Begin if the color buffer has a floating-point RGBA format and FRAGMENT_PROGRAM_NV is disabled. INVALID_OPERATION is generated by TexImage3D, TexImage2D, TexImage1D, TexSubImage3D, TexSubImage2D, or TexSubImage1D if the pixel group type corresponding to is not compatible with the base internal format of the texture. INVALID_OPERATION is generated by TexImage3D, TexImage1D, or CopyTexImage1D if the base internal format corresponding to is FLOAT_R_NV, FLOAT_RG_NV, FLOAT_RGB_NV, or FLOAT_RGBA_NV. INVALID_OPERATION is generated by TexImage2D or CopyTexImage2D if the base internal format corresponding to is FLOAT_R_NV, FLOAT_RG_NV, FLOAT_RGB_NV, or FLOAT_RGBA_NV and is not TEXTURE_RECTANGLE_NV. INVALID_OPERATION is generated by Accum if the color buffer has a color index or floating-point RGBA format. ERROR_INVALID_DATA is generated by wglCreatePbufferARB if WGL_TEXTURE_FORMAT_ARB is WGL_TEXTURE_FLOAT_R_NV, WGL_TEXTURE_FLOAT_RG_NV, WGL_TEXTURE_FLOAT_RGB_NV, or WGL_TEXTURE_FLOAT_RGBA_NV, and WGL_TEXTURE_TARGET_ARB is not WGL_TEXTURE_RECTANGLE_NV. ERROR_INVALID_DATA is generated by wglCreatePbufferARB if WGL_TEXTURE_FORMAT_ARB is WGL_TEXTURE_FLOAT_R_NV, WGL_TEXTURE_TARGET_ARB is WGL_TEXTURE_RECTANGLE_NV, and the WGL_BIND_TO_TEXTURE_RECTANGLE_FLOAT_R_NV attribute is not set in the pixel format. ERROR_INVALID_DATA is generated by wglCreatePbufferARB if WGL_TEXTURE_FORMAT_ARB is WGL_TEXTURE_FLOAT_RG_NV, WGL_TEXTURE_TARGET_ARB is WGL_TEXTURE_RECTANGLE_NV, and the WGL_BIND_TO_TEXTURE_RECTANGLE_FLOAT_RG_NV attribute is not set in the pixel format. ERROR_INVALID_DATA is generated by wglCreatePbufferARB if WGL_TEXTURE_FORMAT_ARB is WGL_TEXTURE_FLOAT_RGB_NV, WGL_TEXTURE_TARGET_ARB is WGL_TEXTURE_RECTANGLE_NV, and the WGL_BIND_TO_TEXTURE_RECTANGLE_FLOAT_RGB_NV attribute is not set in the pixel format. ERROR_INVALID_DATA is generated by wglCreatePbufferARB if WGL_TEXTURE_FORMAT_ARB is WGL_TEXTURE_FLOAT_RGBA_NV, WGL_TEXTURE_TARGET_ARB is WGL_TEXTURE_RECTANGLE_NV, and the WGL_BIND_TO_TEXTURE_RECTANGLE_FLOAT_RGBA_NV attribute is not set in the pixel format. New State (Modify Table 6.15, Texture Objects (cont.), p. 223) Init. Get Value Type Get Command Value Description Sec. Attribute --------------------------- ----- ------------ ----- --------------------- ----- ------------ TEXTURE_FLOAT_COMPONENTS_NV n x B GetTexLevel- 0 True if texture holds 3.8 - unclamped floating- point values (Modify Table 6.19, Framebuffer Control, p. 227) Init. Get Value Type Get Command Value Description Sec. Attribute -------------------------- ---- ----------- ------- ------------------------ ----- ------------ COLOR_CLEAR_VALUE C GetFloatv 0,0,0,0 Color buffer clear value 4.2.3 color-buffer (RGBA mode), each value clamped to [0,1]. FLOAT_CLEAR_COLOR_VALUE_NV 4xR GetFloatv 0,0,0,0 Color buffer clear value 4.2.3 color-buffer (RGBA mode), each value unclamped. New Implementation Dependent State (Modify Table 6.28, Implementation Dependent Values, p. 236) Init. Get Value Type Get Command Value Description Sec. Attribute ------------------ ---- ----------- ----- --------------------- ---- --------- FLOAT_RGBA_MODE_NV B GetBooleanv - True if color buffers 4 - store floating-point data NV3x Implementation Details NV3x GPUs (GeForce FX, etc.) support hardware acceleration for float textures with two or more components only when the repeat mode state (S and T) is GL_CLAMP_TO_EDGE. If you use either the GL_CLAMP or GL_CLAMP_TO_BORDER repeat modes with a float texture with two or more components, the software rasterizer is used. However, if you use a single-component float texture (GL_FLOAT_R_NV, etc.), all clamping repeat modes (GL_CLAMP, GL_CLAMP_TO_EDGE, and GL_CLAMP_TO_BORDER) are available with full hardware acceleration. The two-, three-, and four-component texture formats all use the same amount of texture memory storage (128 bits per texel for the GL_FLOAT_x32 formats, and 64 bits per texel for the GL_FLOAT_x16 formats). Future GPUs will likely store two and three component float textures more efficiently. The GL_FLOAT_R32_NV and GL_FLOAT_R16_NV texture formats each use 32 bits per texel. Future GPUs will likely store GL_FLOAT_R16_NV more efficiently. NVIDIA treats the unsized internal formats GL_FLOAT_R_NV, GL_FLOAT_RGBA_NV, etc. the same as GL_FLOAT_R32_NV, GL_FLOAT_RGBA32_NV, etc. Revision History Rev. Date Author Changes ---- -------- -------- -------------------------------------------- 20 11/03/06 mjk Update Status 19 01/10/05 mjk Add very minimal GLX discussion 18 09/12/05 jjuliano Describe interaction with EXT_framebuffer_object. The GL_FLOAT_*_NV texture formats are color-renderable. 17 04/04/05 pbrown Describe interactions with ARB_texture_float and ARB_color_buffer_float (as well as the ATI equivalents), which remove some of the restrictions of this extension, when supported. 16 06/16/03 pbrown Corrected the usage of WGL_TEXTURE_FLOAT_R_NV and related enums in the list of enumerants. 15 01/23/03 mjk Document texture border color (values) behavior for float textures. See issue. 14 01/20/03 mjk Added NV3x Implementation Details section. 13 11/27/02 pbrown Fixed the name of the clear color query enum in the state table -- the core spec says COLOR_CLEAR_VALUE. The enum in this extension is FLOAT_CLEAR_COLOR_VALUE_NV. Documented this inconsistency. 12 10/09/02 pbrown Clarified that the floating-point internal format enums can not be passed TexImage1D and TexImage3D. 11 07/19/02 pbrown Cleaned up a number of items in the issues section. Removed limitation that DrawPixels and CopyPixels color components are clamped to [0,1]. Removed language modifying multisample color filtering -- if multisample buffers are supported, the color components will be filtered on a componentwise basis. 10 07/09/02 pbrown Fixed contradictory issue resolutions. 9 01/31/02 pbrown Added revision history. 8 01/29/02 pbrown Fix spec to indicate that TEXTURE_FLOAT_COMPONENTS_NV is queried by GetTexLevelParameter*() calls instead of the generic gets. 7 12/26/01 pbrown Documented limitation where DrawPixels/CopyPixels data are clamped to [0,1], even when the color buffer is floating-point. This is consistent with the fact that pixel data is supposed to go in f[COL0] (fixed-point interpolator). Changed float texture to RGBA expansion to always fill in with (0,0,0,1), not (0,0,0,0). This is more consistent with our other texture formats. 6 11/30/01 pbrown Assigned WGL enumerant values. 5 11/27/01 pbrown Modify NV_float_buffer to eliminate the dependencies on NV_render_depth_texture, now that they are no longer necessary. More pedantic fixes. 4 10/29/01 pbrown Add documentation of possible uses of floating-point color buffers. 3 10/19/01 pbrown Assign GL enumerants. Fixed some bugs in the use of #defines in the spec. Added ARB_imaging and SGIS_generate_mipmap interaction issues.