Name

    NV_depth_buffer_float

Name Strings

    GL_NV_depth_buffer_float

Contributors

    Pat Brown
    Mike Strauss
    Mark Kilgard

Contact

    Mike Strauss, NVIDIA Corporation (mstrauss 'at' nvidia.com)    

Status

    Shipping for GeForce 8 Series (November 2006) 

Version

    Last Modified Date:         06/09/2016
    NVIDIA Revision:            12

Number

    334

Dependencies

    OpenGL 2.0 is required.

    ARB_color_buffer_float is required.

    EXT_packed_depth_stencil is required.

    EXT_framebuffer_object is required.
    
    This extension modifies EXT_depth_bounds_test.

    This extension modifies NV_copy_depth_to_color.

    This extension interacts with ARB_depth_buffer_float.

    This extension is written against the OpenGL 2.0 specification.

Overview

    This extension provides new texture internal formats whose depth
    components are stored as 32-bit floating-point values, rather than the
    normalized unsigned integers used in existing depth formats.
    Floating-point depth textures support all the functionality supported for
    fixed-point depth textures, including shadow mapping and rendering support
    via EXT_framebuffer_object.  Floating-point depth textures can store
    values outside the range [0,1].

    By default, OpenGL entry points taking depth values implicitly clamp the
    values to the range [0,1].  This extension provides new DepthClear,
    DepthRange, and DepthBoundsEXT entry points that allow applications to
    specify depth values that are not clamped.

    Additionally, this extension provides new packed depth/stencil pixel
    formats (see EXT_packed_depth_stencil) that have 64-bit pixels consisting
    of a 32-bit floating-point depth value, 8 bits of stencil, and 24 unused
    bites.  A packed depth/stencil texture internal format is also provided.

    This extension does not provide support for WGL or GLX pixel formats with
    floating-point depth buffers.  The existing (but not commonly used)
    WGL_EXT_depth_float extension could be used for this purpose.


New Procedures and Functions

    void DepthRangedNV(double n, double f);
    void ClearDepthdNV(double d);
    void DepthBoundsdNV(double zmin, double zmax);

New Tokens

    Accepted by the <internalformat> parameter of TexImage1D, TexImage2D,
    TexImage3D, CopyTexImage1D, CopyTexImage2D, and RenderbufferStorageEXT,
    and returned in the <data> parameter of GetTexLevelParameter and
    GetRenderbufferParameterivEXT:

        DEPTH_COMPONENT32F_NV                           0x8DAB
        DEPTH32F_STENCIL8_NV                            0x8DAC

    Accepted by the <type> parameter of DrawPixels, ReadPixels, TexImage1D,
    TexImage2D, TexImage3D, TexSubImage1D, TexSubImage2D, TexSubImage3D, and
    GetTexImage:

        FLOAT_32_UNSIGNED_INT_24_8_REV_NV               0x8DAD

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

        DEPTH_BUFFER_FLOAT_MODE_NV                      0x8DAF

Additions to Chapter 2 of the OpenGL 2.0 Specification (OpenGL Operation)

    Modify Section 2.11.1 (Controling the Viewport), p. 41

    (modify second paragraph) The factor and offset applied to z_d 
    encoded by n and f are set using

        void DepthRange(clampd n, clampd f);
        void DepthRangedNV(double n, double f);
    
    z_w is represented as either fixed-point or floating-point
    depending on whether the framebuffer's depth buffer uses
    fixed-point or floating-point representation.  If the depth buffer
    uses fixed-point representation, we assume that the representation
    used represents each value k/(2^m - 1), where k is in 
    {0,1,...,2^m-1}, as k (e.g. 1.0 is represented in binary as a 
    string of all ones).  The parameters n and f are clamped to [0, 1]
    when using DepthRange, but not when using DepthRangedNV.  When n
    and f are applied to z_d, they are clamped to the range appropriate
    given the depth buffer's representation.

Additions to Chapter 3 of the OpenGL 2.0 Specification (Rasterization)

    Modify Section 3.5.5 (Depth Offset), p. 112    

    (modify third paragraph) The minimum resolvable difference r is 
    an implementation dependent parameter that depends on the depth 
    buffer representation.  It is the smallest difference in window 
    coordinate z values that is guaranteed to remain distinct 
    throughout polygon rasterization and in the depth buffer.  All 
    pairs of fragments generated by the rasterization of two polygons 
    with otherwise identical vertices, but z_w values that differ by r,
    will have distinct depth values.

    For fixed-point depth buffer representations, r is constant
    throughout the range of the entire depth buffer.  For
    floating-point depth buffers, there is no single minimum resolvable
    difference.  In this case, the minimum resolvable difference for a 
    given polygon is dependent on the maximum exponent, e, in the range
    of z values spanned by the primitive.  If n is the number of bits 
    in the floating-point mantissa, the minimum resolvable difference, 
    r, for the given primitive is defined as

        r = 2^(e - n).                                       (3.11)

    (modify fourth paragraph) The offset value o for a polygon is

        o = m * factor + r * units.                          (3.12)

    m is computed as described above.  If the depth buffer uses a
    fixed-point representation, m is a function of depth values in the
    range [0, 1], and o is applied to depth values in the same range.
    
    (modify last paragraph) For fixed-point depth buffers, fragment 
    depth values are always limited to the range [0, 1], either by 
    clamping after offset addition is performed (preferred), or by 
    clamping the vertex values used in the rasterization of the 
    polygons.  Fragment depth values are not clamped when the depth 
    buffer uses a floating-point representation.


    Add a row to table 3.5, p. 128

    type Parameter                       GL Type    Special
    ------------------------------------------------
    ...                                  ...        ...    
    FLOAT_32_UNSIGNED_INT_24_8_REV_NV    N/A        Yes
    ...                                  ...        ...


    Modify Section 3.6.4 (Rasterization of Pixel Rectangles), p. 128

    (modify second paragraph as updated by EXT_packed_depth_stencil)
    ... If the GL is in color index mode and <format> is not one of
    COLOR_INDEX, STENCIL_INDEX, DEPTH_COMPONENT, or DEPTH_STENCIL_EXT,
    then the error INVALID_OPERATION occurs.  If <type> is BITMAP and
    <format> is not COLOR_INDEX or STENCIL_INDEX then the error
    INVALID_ENUM occurs.  If <format> is DEPTH_STENCIL_EXT and <type>
    is not UNSIGNED_INT_24_8_EXT or FLOAT_32_UNSIGNED_INT_24_8_REV_NV,
    then the error INVALID_ENUM occurs.  Some additional constraints 
    on the combinations of <format> and <type> values that are accepted
    are discussed below.

    (modify fifth paragraph of "Unpacking," p 130. as updated by
    EXT_packed_depth_stencil) Calling DrawPixels with a <type> of
    UNSIGNED_BYTE_3_3_2, ..., UNSIGNED_INT_2_10_10_10_REV, or 
    UNSIGNED_INT_24_8_EXT is a special case in which all the components 
    of each group are packed into a single unsigned byte, unsigned 
    short, or unsigned int, depending on the type.  If <type> is 
    FLOAT_32_UNSIGNED_INT_24_8_REV_NV, the components of each group
    are two 32-bit words.  The first word contains the float component.
    The second word contains packed 24-bit and 8-bit components.


    Add two rows to table 3.8, p. 132

    type Parameter                       GL Type  Components  Pixel Formats
    ------------------------------------------------------------------
    ...                                  ...      ...         ...        
    FLOAT_32_UNSIGNED_INT_24_8_REV_NV    N/A      2           DEPTH_STENCIL_EXT
    ...                                  ...      ...         ...


    Add a row to table 3.11, p. 134

    FLOAT_32_UNSIGNED_INT_24_8_REV_NV:

       31 30 29 28 ... 4 3 2 1 0    31 30 29 ... 9 8 7 6 5 ... 2 1 0
      +-------------------------+  +--------------------------------+
      |    Float Component      |  | 2nd Component  | 1st Component | 
      +-------------------------+  +--------------------------------+
    

    (modify last paragraph of "Final Conversion," p. 136) For a depth 
    component, an element is processed according to the depth buffer's 
    representation.  For fixed-point depth buffers, the element is first
    clamped to [0, 1] and then converted to fixed-point as if it were a
    window z value (see section 2.11.1, Controling the Viewport).  
    Clamping and conversion are not necessary when the depth buffer uses
    a floating-point representation.


    Modify Section 3.8.1 (Texture Image Specification), p. 150

    (modify the second paragraph, p. 151, as modified by 
    ARB_color_buffer_float) The selected groups are processed exactly 
    as for DrawPixels, stopping just before final conversion.  Each R,
    G, B, A, or depth value so generated is clamped based on the 
    component type in the <internalFormat>.  Fixed-point components 
    are clamped to [0, 1].  Floating-point components are clamped to 
    the limits of the range representable by their format.  32-bit 
    floating-point components are in the standard IEEE float format.  
    16-bit floating-point components have 1 sign bit, 5 exponent bits,
    and 10 mantissa bits.  Stencil index values are masked by 2^n-1 
    where n is the number of stencil bits in the internal format 
    resolution (see below).  If the base internal format is 
    DEPTH_STENCIL_EXT and <format> is not DEPTH_STENCIL_EXT, then the
    values of the stencil index texture components are undefined.


    Add two rows to table 3.16, p. 154

    Sized                   Base               R    G    B    A    L    I    D    S
    Internal Format         InternalFormat    bits bits bits bits bits bits bits bits
    ------------------------------------------------------------------------------
    ...                     ...               ...  ...  ...  ...  ...  ...  ...  ...
    DEPTH_COMPONENT32F_NV   DEPTH_COMPONENT                                 f32
    DEPTH32F_STENCIL8_NV    DEPTH_STENCIL_EXT                               f32  8
    ...                     ...               ...  ...  ...  ...  ...  ...  ...  ...


    Modify Section 3.8.14 (Texture Comparison Modes), p. 185

    (modify second paragraph of "Depth Texture Comparison Mode," p.
    188) Let D_t be the depth texture value, and R be the interpolated 
    texture coordinate.  If the texture's internal format indicates a 
    fixed-point depth texture, then D_t and R are clamped to [0, 1], 
    otherwise no clamping is performed.  The effective texture value 
    L_t, I_t, or A_t is computed as follows:    


    Modify Section 3.11.2 (Shader Execution), p. 194

    (modify first paragraph of "Shader Outputs," p, 196, as modified by
    ARB_color_buffer_float) The OpenGL Shading Language specification 
    describes the values that may be output by a fragment shader.  
    These are gl_FragColor, gl_FragData[n], and gl_FragDepth.  If 
    fragment clamping is enabled, the final fragment color values or 
    the final fragment data values written by a fragment shader are 
    clamped to the range [0, 1] and then may be converted to 
    fixed-point as described in section 2.14.9.  If fragment clamping
    is disabled, the final fragment color values or the final fragment
    data values are not modified.  For fixed-point depth buffers the 
    final fragment depth written by a fragment shader is first clamped
    to [0, 1] and then converted to fixed-point as if it were a window
    z value (see section 2.11.1).  Clamping and conversion are not 
    applied for floating-point depth buffers.  Note that the depth
    range computation is not applied here.


Additions to Chapter 4 of the OpenGL 2.0 Specification (Per-Fragment
Operations and the Frame Buffer)


    (modify third paragraph in the introduction, p. 198, as modified by
    ARB_color_buffer_float) Color buffers consist of either unsigned 
    integer color indices, R, G, B and optionally A unsigned integer 
    values, or R, G, B, and optionally A floating-point values.  Depth
    buffers consist of either unsigned integer values of the format 
    described in section 2.11.1, or floating-point values.  The number
    of bitplanes...    


    Modify Section 4.2.3 (Clearing the Buffers), p. 215

    (modify fourth paragraph)

    The functions

        void ClearDepth(clampd d);
        void ClearDepthdNV(double d);

    are used to set the depth value used when clearing the depth buffer.
    ClearDepth takes a floating-point value that is clamped to the range
    [0, 1].  ClearDepthdNV takes a floating-point value that is not
    clamped.  When clearing a fixed-point depth buffer, the depth clear
    value is clamped to the range [0, 1], and converted to fixed-point
    according to the rules for a window z value given in section 2.11.1.
    No clamping or conversion are applied when clearing a floating-point
    depth buffer.

    Modify Section 4.3.1 (Writing to the Stencil Buffer), p. 218

    (modify paragraph added by EXT_packed_depth_stencil, p. 219)
    If the <format> is DEPTH_STENCIL_EXT, then values are taken from
    both the depth buffer and the stencil buffer.  If there is no depth
    buffer or if there is no stencil buffer, then the error
    INVALID_OPERATION occurs.  If the <type> parameter is not
    UNSIGNED_INT_24_8_EXT, or FLOAT_32_UNSIGNED_INT_24_8_REV_NV then the
    error INVALID_ENUM occurs.


    Modify Section 4.3.2 (Reading Pixels), p. 219

    (modify "Conversion of Depth values," p. 222, as modified by 
    EXT_packed_depth_stencil) This step only applies if <format> is
    DEPTH_COMPONENT or  DEPTH_STENCIL_EXT and the depth buffer uses a
    fixed-point representation.  An element taken from the depth buffer
    is taken to be a fixed-point value in [0, 1] with m bits, where
    m is the number of bits in the depth buffer (see section 2.11.1).
    No conversion is necessary if <format> is DEPTH_COMPONENT or 
    DEPTH_STENCIL_EXT and the depth buffer uses a floating-point 
    representation.


    Add a row to table 4.6, p. 223

      type Parameter                      Index Mask
      ----------------------------------------------
      ...                                 ...      
      FLOAT_32_UNSIGNED_INT_24_8_REV_NV   2^8-1


    Add a row to table 4.7, p. 224

    type Parameter                       GL Type  Component Conversion
    ------------------------------------------------------------------
    ...                                   ...      ...
    FLOAT_32_UNSIGNED_INT_24_8_REV_NV     float    c = f (depth only)


Additions to Chapter 5 of the OpenGL 2.0 Specification (Special Functions)

    None.


Additions to Chapter 6 of the OpenGL 2.0 Specification (State and
State Requests)

    Modify DEPTH_RANGE entry in table 6.9 (Transformation State) p. 270

                                 Init
    Get Value   Type Get Command Value Description            Sec.   Attribute
    ----------- ---- ----------- ----- ---------------------- ------ ---------
    DEPTH_RANGE 2xR  GetFloatv   0,1   Depth range near & far 2.11.1 viewport


    Modify DEPTH_BOUNDS_EXT entry in table 6.19 (Pixel Operation) p. 280

                                      Init
    Get Value        Type Get Command Value Description              Sec   Attribute
    --------------------- ----------- ----- ------------------------ ----- ------------
    DEPTH_BOUNDS_EXT 2xR  GetFloatv   0,1   Depth bounds zmin & zmax 4.1.X depth-buffer


    Modify DEPTH_CLEAR_VALUE entry in table 6.21 (Framebuffer Control) p. 280

                                       Init
    Get Value         Type Get Command Value Description              Sec   Attribute
    ----------------- ---- ----------- ----  ------------------------ ----- ------------
    DEPTH_CLEAR_VALUE  R   GetFloatv    1    Depth buffer clear value 4.2.3 depth-buffer


    Add DEPTH_BUFFER_FLOAT_MODE_NV entry to table 6.32 (Implementation Dependent Values) p. 293

                                                Init
    Get Value                  Type Get Command Value Description                 Sec  Attribute
    -------------------------- ---- ----------- ----  --------------------------- ---- ------------
    DEPTH_BUFFER_FLOAT_MODE_NV B    GetBooleanv  -    True if depth buffer uses a  4     -
                                                      floating-point represnetation


Additions to Appendix A of the OpenGL 2.0 Specification (Invariance)

    None.

Additions to the AGL/GLX/WGL Specifications

    None.

GLX Protocol

    The following rendering commands are sent to the server as part of
    glXRender requests:

    DepthRangedNV

        2      20              rendering command length
        2      4283            rendering command opcode
        8      FLOAT64         n
        8      FLOAT64         f

    ClearDepthdNV

        2      12              rendering command length
        2      4284            rendering command opcode
        8      FLOAT64         d

    DepthBoundsdNV

        2      20              rendering command length
        2      4285            rendering command opcode
        8      FLOAT64         zmin
        8      FLOAT64         zmax

Dependencies on EXT_depth_bounds_test:

    Modify the definition of DepthBoundsEXT in section 4.1.x Depth
    Bounds Test.

    Modify section 4.1.x (Depth Bounds Test)

    (modify first paragraph) ...These values are set with

        void DepthBoundsEXT(clampd zmin, clampd zmax);
        void DepthBoundsdNV(double zmin, double zmax);

    The paramerters to DepthBoundsEXT are clamped to the range [0, 1].
    No clamping is applied to the parameters of DepthBoundsdNV.  Each
    of zmin and zmax are subject to clamping to the range of the depth 
    buffer at the time the depth bounds test is applied.  For 
    fixed-point depth buffers, the applied zmin and zmax are clamped to
    [0, 1].  For floating-point depth buffers, the applied zmin and 
    zmax are unmodified.  If zmin <= Zpixel <= zmax, then the depth 
    bounds test passes.  Otherwise, the test fails and the fragment is
    discarded.  The test is enabled or disabled using Enable or Disable 
    using the constant DEPTH_BOUNDS_TEST_EXT.  When disabled, it is as 
    if the depth bounds test always passes.  If zmin is greater than 
    zmax, then the error INVALID_VALUE is generated.  The state 
    required consists of two floating-point values and a bit indicating
    whether the test is enabled or disabled.  In the initial state, 
    zmin and zmax are set to 0.0 and 1.0 respectively; and the depth 
    bounds test is disabled.

Interactions with ARB_depth_buffer_float

    The ARB and NV internal formats for floating-point depth buffers
    behave identically.  This extension optionally relaxes the clamping
    behavior of ARB_depth_buffer_float when using the NV entry points.
    If an ARB internal format is used to define a depth buffer, the
    values passed to DepthRangedNV, ClearDepthdNV, and DepthBoundsdNV
    are not clamped to [0,1].

    Additionally, querying DEPTH_BUFFER_FLOAT_MODE_NV is allowed on a
    floating-point depth buffer created with an ARB internal format.

Errors

    Modify the following error in the EXT_packed_depth_stencil
    specification by adding mention of 
    FLOAT_32_UNSIGNED_INT_24_8_REV_NV:

    The error INVALID_ENUM is generated if DrawPixels or ReadPixels is
    called where format is DEPTH_STENCIL_EXT and type is not
    UNSIGNED_INT_24_8_EXT, or FLOAT_32_UNSIGNED_INT_24_8_REV_NV.


    Modify the following error in the EXT_packed_depth_stencil
    specification by adding mention of 
    FLOAT_32_UNSIGNED_INT_24_8_REV_NV:

    The error INVALID_OPERATION is generated if DrawPixels or 
    ReadPixels is called where type is UNSIGNED_INT_24_8_EXT, 
    or FLOAT_32_UNSIGNED_INT_24_8_REV_NV and format is not 
    DEPTH_STENCIL_EXT.


    Add the following error to the NV_copy_depth_to_color
    specification:

    The error INVALID_OPERATION is generated if CopyPixels is called
    where type is DEPTH_STENCIL_TO_RGBA_NV or DEPTH_STENCL_TO_BGRA_NV
    and the depth buffer uses a floating point representation.

New State

    None.

Issues

    1.  Should this extension expose floating-point depth buffers through
        WGL/GLX "pixel formats?"

        RESOLVED:  No.  The WGL_EXT_depth_float extension already provides a
        mechanism for requesting a floating-point depth buffer.

    2.  How does an application access the full range of a floating-point
        depth buffer?

        RESOLVED:  New functions have been introduced that set existing GL
        state without clamping to the range [0, 1].  These functions are
        DepthRangedNV, ClearDepthdNV, and DepthBoundsdNV.

    3.  Should we add a new state query to determine if the depth buffer is
        using a floating-point representation?

        RESOLVED: Yes.  An application can query DEPTH_FLOAT_MODE_NV to see
        if the depth buffer is using a floating-point representation.

    4.  How does polygon offset work with floating-point depth buffers?

        RESOLVED:  The third paragraph of section 3.5.5 (Depth Offset)
        describes the minimum resolvable difference r as "the smallest
        difference in window coordinate z values that is guaranteed to remain
        distinct throughout polygon rasterization and in the depth buffer."
        The polygon offset value o is computed as a function of r.  The
        minimum resolvable difference r makes sense for fixed-point depth
        values, and even floating-point depth values in the range [-1, 1].
        For unclamped floating-point depth values, there is no constant
        minimum resolvable difference -- the minimum difference necessary to
        change the mantissa of a floating-point value by one bit depends on
        the exponent of the value being offset.  To remedy this problem, the
        minimum resolvable difference is defined to be relative to the range
        of depth values for the given primitive when the depth buffer is
        floating-point.

    5. How does NV_copy_depth_to_color work with floating-point depth values?

        RESOLVED:  It isn't clear that there is any usefulness to copying the
        data for 32-bit floating-point depth values to a fixed-point color
        buffer.  It is even less clear how copying packed data from a
        FLOAT_32_UNSIGNED_24_8_REV_NV depth/stencil buffer to a fixed-point color
        buffer would be useful or even how it should be implemented.  An error
        should be generated if CopyPixels is called where <type> is
        DEPTH_STENCIL_TO_RGBA_NV or DEPTH_STENCIL_TO_BGRA and the depth buffer
        uses a floating-point representation.

    6. Other OpenGL hardware implementations may be capable of supporting
       floating-point depth buffers.  Why is this an NV extension?

        RESOLVED:  When rendering to floating-point depth buffers, we expect
        that other implementations may only be capable of supporting Z values
        in the range [0,1].  For such implementations, floating-point Z
        buffers do not improve the range of Z values supported, but do offer
        increased precision than conventional 24-bit fixed-point Z buffers,
        particularly around zero.

        This extension was initially proposed as an EXT, but we have changed
        it to an NV extension in the expectation that an EXT may be offered at
        some point in the not-too-distant future.  We expect that the EXT
        could be supported by a larger range of vendors.  NVIDIA would
        continue to support both extensions, where the NV extension could be
        thought of as taking the capability of the EXT version and extending
        it to support Z values outside the range [0,1].

Revision History

    Rev.    Date    Author       Changes
    ----  --------  --------     -----------------------------------------
    12    06/09/16  mjk          Added missing _NV suffixing

    11    07/27/10  srahman      GLX protocol added. 

    10    01/30/09  rsrinivasiah Define interaction with ARB_depth_buffer_float

     9    08/06/08  jleech       Fix missing _REV in some token names.

     8    02/09/07  pbrown       Updated status section (now released).

     7    10/11/06  pbrown       Rename the extension from EXT to NV.

     6                           Internal spec revisions.