NV_depth_buffer_float
GL_NV_depth_buffer_float
Pat Brown
Mike Strauss
Mike Strauss, NVIDIA Corporation (mstrauss 'at' nvidia.com)
DRAFT SPECIFICATION
NVIDIA CONFIDENTIAL -- DO NOT DISTRIBUTE
Last Modified Date: 10/11/2006
NVIDIA Revision: 7
Unassigned
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 is written against the OpenGL 2.0 specification.
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);
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_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 entry to table 6.32 (Implementation Dependent Values) p. 293
Init
Get Value Type Get Command Value Description Sec Attribute
----------------------- ---- ----------- ---- --------------------------- ---- ------------
DEPTH_BUFFER_FLOAT_MODE 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.
None.
| 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.
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.
None.
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_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].
Rev. Date Author Changes
---- -------- -------- -----------------------------------------
7 10/11/06 pbrown Rename the extension from EXT to NV.
6 Internal spec revisions.
6 Internal spec revisions.
 |  | Last update: November 14, 2006.
Cette page doit être lue avec un navigateur récent respectant le standard XHTML 1.1.
|
