Name
ARB_depth_buffer_float
Name Strings
GL_ARB_depth_buffer_float
Contributors
Pierre Boudier
Contact
Pierre Boudier, AMD pierre.boudier 'at' amd.com)
Notice
Copyright (c) 2008-2013 The Khronos Group Inc. Copyright terms at
http://www.khronos.org/registry/speccopyright.html
Status
Approved by the ARB on July 11, 2008
Version
Last Modified Date: October 18, 2012
Revision: 7
Number
ARB Extension #43
Dependencies
OpenGL 2.0 is required.
ARB_color_buffer_float is required.
EXT_packed_depth_stencil is required.
ARB_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.
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].
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
None
New Tokens
Accepted by the parameter of TexImage1D, TexImage2D,
TexImage3D, CopyTexImage1D, CopyTexImage2D, and RenderbufferStorageEXT,
and returned in the parameter of GetTexLevelParameter and
GetRenderbufferParameterivEXT:
DEPTH_COMPONENT32F 0x8CAC
DEPTH32F_STENCIL8 0x8CAD
Accepted by the parameter of DrawPixels, ReadPixels, TexImage1D,
TexImage2D, TexImage3D, TexSubImage1D, TexSubImage2D, TexSubImage3D, and
GetTexImage:
FLOAT_32_UNSIGNED_INT_24_8_REV 0x8DAD
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);
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. 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 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 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 is not one of
COLOR_INDEX, STENCIL_INDEX, DEPTH_COMPONENT, or DEPTH_STENCIL_EXT,
then the error INVALID_OPERATION occurs. If is BITMAP and
is not COLOR_INDEX or STENCIL_INDEX then the error
INVALID_ENUM occurs. If is DEPTH_STENCIL_EXT and
is not UNSIGNED_INT_24_8_EXT or FLOAT_32_UNSIGNED_INT_24_8_REV,
then the error INVALID_ENUM occurs. Some additional constraints
on the combinations of and 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 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 is
FLOAT_32_UNSIGNED_INT_24_8_REV, 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 N/A 2 DEPTH_STENCIL_EXT
... ... ... ...
Add a row to table 3.11, p. 134
FLOAT_32_UNSIGNED_INT_24_8_REV:
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).
Conversion is not necessary when the depth buffer uses
a floating-point representation, but clamping is.
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 . Fixed-point and Floating-point
components are clamped to [0, 1].
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 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 DEPTH_COMPONENT f32
DEPTH32F_STENCIL8 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). Conversion is 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);
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]. 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 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 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 parameter is not
UNSIGNED_INT_24_8_EXT, or FLOAT_32_UNSIGNED_INT_24_8_REV 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 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 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 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 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
Additions to Appendix A of the OpenGL 2.0 Specification (Invariance)
None.
Additions to the AGL/GLX/WGL Specifications
None.
GLX Protocol
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);
The paramerters to DepthBoundsEXT are clamped to the range [0, 1].
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 clamped to [0, 1]. 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.
Errors
Modify the following error in the EXT_packed_depth_stencil
specification by adding mention of
FLOAT_32_UNSIGNED_INT_24_8_REV:
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.
Modify the following error in the EXT_packed_depth_stencil
specification by adding mention of
FLOAT_32_UNSIGNED_INT_24_8_REV:
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 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_EXT or DEPTH_STENCL_TO_BGRA_EXT
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: This will be a different extension
3. Should we add a new state query to determine if the depth buffer is
using a floating-point representation?
RESOLVED: No. The old EXT version of this extension had
DEPTH_BUFFER_FLOAT_MODE_EXT boolean state to see if the depth
buffer is using a floating-point representation, but in this ARB
extension we rely on the GetFramebufferAttachmentiv query
FRAMEBUFFER_ATTACHMENT_COMPONENT_TYPE query introduced with
ARB_framebuffer_object and OpenGL 3.0.
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 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 is
DEPTH_STENCIL_TO_RGBA_EXT 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].
7. Why don't the new tokens and entry points in this extension have
"ARB" suffixes like other ARB extensions?
RESOLVED: Unlike most ARB extensions, this is a strict subset of
functionality already approved in OpenGL 3.0. This extension
exists only to support that functionality on older hardware that
cannot implement a full OpenGL 3.0 driver. Since there are no
possible behavior changes between the ARB extension and core
features, source code compatibility is improved by not using
suffixes on the extension.
Revision History
Rev. Date Author Changes
---- -------- -------- -----------------------------------------
7 10/18/12 Jon Leech Restrict [0,1] clamp of D_t and R to
only occur for fixed-point depth textures,
matching actual driver behavior and the
original intent of NV_depth_buffer_float
(Bug 7975).
6 08/08/08 Jon Leech Remove DEPTH_BUFFER_FLOAT_MODE query,
update issue 3 accordingly, and
change dependency from EXT to
ARB_framebuffer_object / GL 3.0.
5 08/07/08 Jon Leech Remove ARB suffixes.
4 08/06/08 Jon Leech Fix missing _REV in some token names.
3 07/11/08 Jon Leech Change NV enum values due to incompatible
clamping behavior.
2 06/30/08 jsandmel Trivial conversion to ARB_depth_buffer_float
1 06/05/08 pboudier Forked from NV_depth_buffer_float. Restore
clamping to [0,1] and remove 'd' entry
points. Change suffix from NV to EXT.