xref: /third_party/openGLES/extensions/NV/NV_float_buffer.txt

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 a 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 a 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 a 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 a 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 a 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 <internalformat> 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 <pname> parameter of GetTexLevelParameterfv and
    GetTexLevelParameteriv:

        TEXTURE_FLOAT_COMPONENTS_NV                     0x888C

    Accepted by the <pname> parameter of GetBooleanv, GetIntegerv, GetFloatv,
    and GetDoublev:

        FLOAT_CLEAR_COLOR_VALUE_NV                      0x888D
        FLOAT_RGBA_MODE_NV                              0x888E

    Accepted in the <piAttributes> array of wglGetPixelFormatAttribivARB and
    wglGetPixelFormatAttribfvARB and in the <piAttribIList> and
    <pfAttribFList> 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 <piAttribIList> array of wglCreatePbufferARB and returned
    in the <value> parameter of wglQueryPbufferARB when <iAttribute> 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 <value> 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) <internalformat>.  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 <format>
    incompatible with <internalformat> 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 a 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
        "<NAME>/<TYPE><SIZE>", 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.  <SIZE> 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 <type> is not FLOAT or HALF_FLOAT_NV, each
    component is clamped to [0,1] if <type> is unsigned or [-1,1] if <type> 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 <piAttributes> in
    wglGetPixelFormatAttribivARB and <pfAttributes> 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

    <very incomplete>

    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 a 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 <format> 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
    <internalformat> 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 <internalformat> is FLOAT_R_NV,
    FLOAT_RG_NV, FLOAT_RGB_NV, or FLOAT_RGBA_NV and <target> 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.