1Name 2 3 NV_depth_buffer_float 4 5Name Strings 6 7 GL_NV_depth_buffer_float 8 9Contributors 10 11 Pat Brown 12 Mike Strauss 13 Mark Kilgard 14 15Contact 16 17 Mike Strauss, NVIDIA Corporation (mstrauss 'at' nvidia.com) 18 19Status 20 21 Shipping for GeForce 8 Series (November 2006) 22 23Version 24 25 Last Modified Date: 06/09/2016 26 NVIDIA Revision: 12 27 28Number 29 30 334 31 32Dependencies 33 34 OpenGL 2.0 is required. 35 36 ARB_color_buffer_float is required. 37 38 EXT_packed_depth_stencil is required. 39 40 EXT_framebuffer_object is required. 41 42 This extension modifies EXT_depth_bounds_test. 43 44 This extension modifies NV_copy_depth_to_color. 45 46 This extension interacts with ARB_depth_buffer_float. 47 48 This extension is written against the OpenGL 2.0 specification. 49 50Overview 51 52 This extension provides new texture internal formats whose depth 53 components are stored as 32-bit floating-point values, rather than the 54 normalized unsigned integers used in existing depth formats. 55 Floating-point depth textures support all the functionality supported for 56 fixed-point depth textures, including shadow mapping and rendering support 57 via EXT_framebuffer_object. Floating-point depth textures can store 58 values outside the range [0,1]. 59 60 By default, OpenGL entry points taking depth values implicitly clamp the 61 values to the range [0,1]. This extension provides new DepthClear, 62 DepthRange, and DepthBoundsEXT entry points that allow applications to 63 specify depth values that are not clamped. 64 65 Additionally, this extension provides new packed depth/stencil pixel 66 formats (see EXT_packed_depth_stencil) that have 64-bit pixels consisting 67 of a 32-bit floating-point depth value, 8 bits of stencil, and 24 unused 68 bites. A packed depth/stencil texture internal format is also provided. 69 70 This extension does not provide support for WGL or GLX pixel formats with 71 floating-point depth buffers. The existing (but not commonly used) 72 WGL_EXT_depth_float extension could be used for this purpose. 73 74 75New Procedures and Functions 76 77 void DepthRangedNV(double n, double f); 78 void ClearDepthdNV(double d); 79 void DepthBoundsdNV(double zmin, double zmax); 80 81New Tokens 82 83 Accepted by the <internalformat> parameter of TexImage1D, TexImage2D, 84 TexImage3D, CopyTexImage1D, CopyTexImage2D, and RenderbufferStorageEXT, 85 and returned in the <data> parameter of GetTexLevelParameter and 86 GetRenderbufferParameterivEXT: 87 88 DEPTH_COMPONENT32F_NV 0x8DAB 89 DEPTH32F_STENCIL8_NV 0x8DAC 90 91 Accepted by the <type> parameter of DrawPixels, ReadPixels, TexImage1D, 92 TexImage2D, TexImage3D, TexSubImage1D, TexSubImage2D, TexSubImage3D, and 93 GetTexImage: 94 95 FLOAT_32_UNSIGNED_INT_24_8_REV_NV 0x8DAD 96 97 Accepted by the <pname> parameters of GetBooleanv, GetIntegerv, 98 GetFloatv, and GetDoublev: 99 100 DEPTH_BUFFER_FLOAT_MODE_NV 0x8DAF 101 102Additions to Chapter 2 of the OpenGL 2.0 Specification (OpenGL Operation) 103 104 Modify Section 2.11.1 (Controling the Viewport), p. 41 105 106 (modify second paragraph) The factor and offset applied to z_d 107 encoded by n and f are set using 108 109 void DepthRange(clampd n, clampd f); 110 void DepthRangedNV(double n, double f); 111 112 z_w is represented as either fixed-point or floating-point 113 depending on whether the framebuffer's depth buffer uses 114 fixed-point or floating-point representation. If the depth buffer 115 uses fixed-point representation, we assume that the representation 116 used represents each value k/(2^m - 1), where k is in 117 {0,1,...,2^m-1}, as k (e.g. 1.0 is represented in binary as a 118 string of all ones). The parameters n and f are clamped to [0, 1] 119 when using DepthRange, but not when using DepthRangedNV. When n 120 and f are applied to z_d, they are clamped to the range appropriate 121 given the depth buffer's representation. 122 123Additions to Chapter 3 of the OpenGL 2.0 Specification (Rasterization) 124 125 Modify Section 3.5.5 (Depth Offset), p. 112 126 127 (modify third paragraph) The minimum resolvable difference r is 128 an implementation dependent parameter that depends on the depth 129 buffer representation. It is the smallest difference in window 130 coordinate z values that is guaranteed to remain distinct 131 throughout polygon rasterization and in the depth buffer. All 132 pairs of fragments generated by the rasterization of two polygons 133 with otherwise identical vertices, but z_w values that differ by r, 134 will have distinct depth values. 135 136 For fixed-point depth buffer representations, r is constant 137 throughout the range of the entire depth buffer. For 138 floating-point depth buffers, there is no single minimum resolvable 139 difference. In this case, the minimum resolvable difference for a 140 given polygon is dependent on the maximum exponent, e, in the range 141 of z values spanned by the primitive. If n is the number of bits 142 in the floating-point mantissa, the minimum resolvable difference, 143 r, for the given primitive is defined as 144 145 r = 2^(e - n). (3.11) 146 147 (modify fourth paragraph) The offset value o for a polygon is 148 149 o = m * factor + r * units. (3.12) 150 151 m is computed as described above. If the depth buffer uses a 152 fixed-point representation, m is a function of depth values in the 153 range [0, 1], and o is applied to depth values in the same range. 154 155 (modify last paragraph) For fixed-point depth buffers, fragment 156 depth values are always limited to the range [0, 1], either by 157 clamping after offset addition is performed (preferred), or by 158 clamping the vertex values used in the rasterization of the 159 polygons. Fragment depth values are not clamped when the depth 160 buffer uses a floating-point representation. 161 162 163 Add a row to table 3.5, p. 128 164 165 type Parameter GL Type Special 166 ------------------------------------------------ 167 ... ... ... 168 FLOAT_32_UNSIGNED_INT_24_8_REV_NV N/A Yes 169 ... ... ... 170 171 172 Modify Section 3.6.4 (Rasterization of Pixel Rectangles), p. 128 173 174 (modify second paragraph as updated by EXT_packed_depth_stencil) 175 ... If the GL is in color index mode and <format> is not one of 176 COLOR_INDEX, STENCIL_INDEX, DEPTH_COMPONENT, or DEPTH_STENCIL_EXT, 177 then the error INVALID_OPERATION occurs. If <type> is BITMAP and 178 <format> is not COLOR_INDEX or STENCIL_INDEX then the error 179 INVALID_ENUM occurs. If <format> is DEPTH_STENCIL_EXT and <type> 180 is not UNSIGNED_INT_24_8_EXT or FLOAT_32_UNSIGNED_INT_24_8_REV_NV, 181 then the error INVALID_ENUM occurs. Some additional constraints 182 on the combinations of <format> and <type> values that are accepted 183 are discussed below. 184 185 (modify fifth paragraph of "Unpacking," p 130. as updated by 186 EXT_packed_depth_stencil) Calling DrawPixels with a <type> of 187 UNSIGNED_BYTE_3_3_2, ..., UNSIGNED_INT_2_10_10_10_REV, or 188 UNSIGNED_INT_24_8_EXT is a special case in which all the components 189 of each group are packed into a single unsigned byte, unsigned 190 short, or unsigned int, depending on the type. If <type> is 191 FLOAT_32_UNSIGNED_INT_24_8_REV_NV, the components of each group 192 are two 32-bit words. The first word contains the float component. 193 The second word contains packed 24-bit and 8-bit components. 194 195 196 Add two rows to table 3.8, p. 132 197 198 type Parameter GL Type Components Pixel Formats 199 ------------------------------------------------------------------ 200 ... ... ... ... 201 FLOAT_32_UNSIGNED_INT_24_8_REV_NV N/A 2 DEPTH_STENCIL_EXT 202 ... ... ... ... 203 204 205 Add a row to table 3.11, p. 134 206 207 FLOAT_32_UNSIGNED_INT_24_8_REV_NV: 208 209 31 30 29 28 ... 4 3 2 1 0 31 30 29 ... 9 8 7 6 5 ... 2 1 0 210 +-------------------------+ +--------------------------------+ 211 | Float Component | | 2nd Component | 1st Component | 212 +-------------------------+ +--------------------------------+ 213 214 215 (modify last paragraph of "Final Conversion," p. 136) For a depth 216 component, an element is processed according to the depth buffer's 217 representation. For fixed-point depth buffers, the element is first 218 clamped to [0, 1] and then converted to fixed-point as if it were a 219 window z value (see section 2.11.1, Controling the Viewport). 220 Clamping and conversion are not necessary when the depth buffer uses 221 a floating-point representation. 222 223 224 Modify Section 3.8.1 (Texture Image Specification), p. 150 225 226 (modify the second paragraph, p. 151, as modified by 227 ARB_color_buffer_float) The selected groups are processed exactly 228 as for DrawPixels, stopping just before final conversion. Each R, 229 G, B, A, or depth value so generated is clamped based on the 230 component type in the <internalFormat>. Fixed-point components 231 are clamped to [0, 1]. Floating-point components are clamped to 232 the limits of the range representable by their format. 32-bit 233 floating-point components are in the standard IEEE float format. 234 16-bit floating-point components have 1 sign bit, 5 exponent bits, 235 and 10 mantissa bits. Stencil index values are masked by 2^n-1 236 where n is the number of stencil bits in the internal format 237 resolution (see below). If the base internal format is 238 DEPTH_STENCIL_EXT and <format> is not DEPTH_STENCIL_EXT, then the 239 values of the stencil index texture components are undefined. 240 241 242 Add two rows to table 3.16, p. 154 243 244 Sized Base R G B A L I D S 245 Internal Format InternalFormat bits bits bits bits bits bits bits bits 246 ------------------------------------------------------------------------------ 247 ... ... ... ... ... ... ... ... ... ... 248 DEPTH_COMPONENT32F_NV DEPTH_COMPONENT f32 249 DEPTH32F_STENCIL8_NV DEPTH_STENCIL_EXT f32 8 250 ... ... ... ... ... ... ... ... ... ... 251 252 253 Modify Section 3.8.14 (Texture Comparison Modes), p. 185 254 255 (modify second paragraph of "Depth Texture Comparison Mode," p. 256 188) Let D_t be the depth texture value, and R be the interpolated 257 texture coordinate. If the texture's internal format indicates a 258 fixed-point depth texture, then D_t and R are clamped to [0, 1], 259 otherwise no clamping is performed. The effective texture value 260 L_t, I_t, or A_t is computed as follows: 261 262 263 Modify Section 3.11.2 (Shader Execution), p. 194 264 265 (modify first paragraph of "Shader Outputs," p, 196, as modified by 266 ARB_color_buffer_float) The OpenGL Shading Language specification 267 describes the values that may be output by a fragment shader. 268 These are gl_FragColor, gl_FragData[n], and gl_FragDepth. If 269 fragment clamping is enabled, the final fragment color values or 270 the final fragment data values written by a fragment shader are 271 clamped to the range [0, 1] and then may be converted to 272 fixed-point as described in section 2.14.9. If fragment clamping 273 is disabled, the final fragment color values or the final fragment 274 data values are not modified. For fixed-point depth buffers the 275 final fragment depth written by a fragment shader is first clamped 276 to [0, 1] and then converted to fixed-point as if it were a window 277 z value (see section 2.11.1). Clamping and conversion are not 278 applied for floating-point depth buffers. Note that the depth 279 range computation is not applied here. 280 281 282Additions to Chapter 4 of the OpenGL 2.0 Specification (Per-Fragment 283Operations and the Frame Buffer) 284 285 286 (modify third paragraph in the introduction, p. 198, as modified by 287 ARB_color_buffer_float) Color buffers consist of either unsigned 288 integer color indices, R, G, B and optionally A unsigned integer 289 values, or R, G, B, and optionally A floating-point values. Depth 290 buffers consist of either unsigned integer values of the format 291 described in section 2.11.1, or floating-point values. The number 292 of bitplanes... 293 294 295 Modify Section 4.2.3 (Clearing the Buffers), p. 215 296 297 (modify fourth paragraph) 298 299 The functions 300 301 void ClearDepth(clampd d); 302 void ClearDepthdNV(double d); 303 304 are used to set the depth value used when clearing the depth buffer. 305 ClearDepth takes a floating-point value that is clamped to the range 306 [0, 1]. ClearDepthdNV takes a floating-point value that is not 307 clamped. When clearing a fixed-point depth buffer, the depth clear 308 value is clamped to the range [0, 1], and converted to fixed-point 309 according to the rules for a window z value given in section 2.11.1. 310 No clamping or conversion are applied when clearing a floating-point 311 depth buffer. 312 313 Modify Section 4.3.1 (Writing to the Stencil Buffer), p. 218 314 315 (modify paragraph added by EXT_packed_depth_stencil, p. 219) 316 If the <format> is DEPTH_STENCIL_EXT, then values are taken from 317 both the depth buffer and the stencil buffer. If there is no depth 318 buffer or if there is no stencil buffer, then the error 319 INVALID_OPERATION occurs. If the <type> parameter is not 320 UNSIGNED_INT_24_8_EXT, or FLOAT_32_UNSIGNED_INT_24_8_REV_NV then the 321 error INVALID_ENUM occurs. 322 323 324 Modify Section 4.3.2 (Reading Pixels), p. 219 325 326 (modify "Conversion of Depth values," p. 222, as modified by 327 EXT_packed_depth_stencil) This step only applies if <format> is 328 DEPTH_COMPONENT or DEPTH_STENCIL_EXT and the depth buffer uses a 329 fixed-point representation. An element taken from the depth buffer 330 is taken to be a fixed-point value in [0, 1] with m bits, where 331 m is the number of bits in the depth buffer (see section 2.11.1). 332 No conversion is necessary if <format> is DEPTH_COMPONENT or 333 DEPTH_STENCIL_EXT and the depth buffer uses a floating-point 334 representation. 335 336 337 Add a row to table 4.6, p. 223 338 339 type Parameter Index Mask 340 ---------------------------------------------- 341 ... ... 342 FLOAT_32_UNSIGNED_INT_24_8_REV_NV 2^8-1 343 344 345 Add a row to table 4.7, p. 224 346 347 type Parameter GL Type Component Conversion 348 ------------------------------------------------------------------ 349 ... ... ... 350 FLOAT_32_UNSIGNED_INT_24_8_REV_NV float c = f (depth only) 351 352 353Additions to Chapter 5 of the OpenGL 2.0 Specification (Special Functions) 354 355 None. 356 357 358Additions to Chapter 6 of the OpenGL 2.0 Specification (State and 359State Requests) 360 361 Modify DEPTH_RANGE entry in table 6.9 (Transformation State) p. 270 362 363 Init 364 Get Value Type Get Command Value Description Sec. Attribute 365 ----------- ---- ----------- ----- ---------------------- ------ --------- 366 DEPTH_RANGE 2xR GetFloatv 0,1 Depth range near & far 2.11.1 viewport 367 368 369 Modify DEPTH_BOUNDS_EXT entry in table 6.19 (Pixel Operation) p. 280 370 371 Init 372 Get Value Type Get Command Value Description Sec Attribute 373 --------------------- ----------- ----- ------------------------ ----- ------------ 374 DEPTH_BOUNDS_EXT 2xR GetFloatv 0,1 Depth bounds zmin & zmax 4.1.X depth-buffer 375 376 377 Modify DEPTH_CLEAR_VALUE entry in table 6.21 (Framebuffer Control) p. 280 378 379 Init 380 Get Value Type Get Command Value Description Sec Attribute 381 ----------------- ---- ----------- ---- ------------------------ ----- ------------ 382 DEPTH_CLEAR_VALUE R GetFloatv 1 Depth buffer clear value 4.2.3 depth-buffer 383 384 385 Add DEPTH_BUFFER_FLOAT_MODE_NV entry to table 6.32 (Implementation Dependent Values) p. 293 386 387 Init 388 Get Value Type Get Command Value Description Sec Attribute 389 -------------------------- ---- ----------- ---- --------------------------- ---- ------------ 390 DEPTH_BUFFER_FLOAT_MODE_NV B GetBooleanv - True if depth buffer uses a 4 - 391 floating-point represnetation 392 393 394Additions to Appendix A of the OpenGL 2.0 Specification (Invariance) 395 396 None. 397 398Additions to the AGL/GLX/WGL Specifications 399 400 None. 401 402GLX Protocol 403 404 The following rendering commands are sent to the server as part of 405 glXRender requests: 406 407 DepthRangedNV 408 409 2 20 rendering command length 410 2 4283 rendering command opcode 411 8 FLOAT64 n 412 8 FLOAT64 f 413 414 ClearDepthdNV 415 416 2 12 rendering command length 417 2 4284 rendering command opcode 418 8 FLOAT64 d 419 420 DepthBoundsdNV 421 422 2 20 rendering command length 423 2 4285 rendering command opcode 424 8 FLOAT64 zmin 425 8 FLOAT64 zmax 426 427Dependencies on EXT_depth_bounds_test: 428 429 Modify the definition of DepthBoundsEXT in section 4.1.x Depth 430 Bounds Test. 431 432 Modify section 4.1.x (Depth Bounds Test) 433 434 (modify first paragraph) ...These values are set with 435 436 void DepthBoundsEXT(clampd zmin, clampd zmax); 437 void DepthBoundsdNV(double zmin, double zmax); 438 439 The paramerters to DepthBoundsEXT are clamped to the range [0, 1]. 440 No clamping is applied to the parameters of DepthBoundsdNV. Each 441 of zmin and zmax are subject to clamping to the range of the depth 442 buffer at the time the depth bounds test is applied. For 443 fixed-point depth buffers, the applied zmin and zmax are clamped to 444 [0, 1]. For floating-point depth buffers, the applied zmin and 445 zmax are unmodified. If zmin <= Zpixel <= zmax, then the depth 446 bounds test passes. Otherwise, the test fails and the fragment is 447 discarded. The test is enabled or disabled using Enable or Disable 448 using the constant DEPTH_BOUNDS_TEST_EXT. When disabled, it is as 449 if the depth bounds test always passes. If zmin is greater than 450 zmax, then the error INVALID_VALUE is generated. The state 451 required consists of two floating-point values and a bit indicating 452 whether the test is enabled or disabled. In the initial state, 453 zmin and zmax are set to 0.0 and 1.0 respectively; and the depth 454 bounds test is disabled. 455 456Interactions with ARB_depth_buffer_float 457 458 The ARB and NV internal formats for floating-point depth buffers 459 behave identically. This extension optionally relaxes the clamping 460 behavior of ARB_depth_buffer_float when using the NV entry points. 461 If an ARB internal format is used to define a depth buffer, the 462 values passed to DepthRangedNV, ClearDepthdNV, and DepthBoundsdNV 463 are not clamped to [0,1]. 464 465 Additionally, querying DEPTH_BUFFER_FLOAT_MODE_NV is allowed on a 466 floating-point depth buffer created with an ARB internal format. 467 468Errors 469 470 Modify the following error in the EXT_packed_depth_stencil 471 specification by adding mention of 472 FLOAT_32_UNSIGNED_INT_24_8_REV_NV: 473 474 The error INVALID_ENUM is generated if DrawPixels or ReadPixels is 475 called where format is DEPTH_STENCIL_EXT and type is not 476 UNSIGNED_INT_24_8_EXT, or FLOAT_32_UNSIGNED_INT_24_8_REV_NV. 477 478 479 Modify the following error in the EXT_packed_depth_stencil 480 specification by adding mention of 481 FLOAT_32_UNSIGNED_INT_24_8_REV_NV: 482 483 The error INVALID_OPERATION is generated if DrawPixels or 484 ReadPixels is called where type is UNSIGNED_INT_24_8_EXT, 485 or FLOAT_32_UNSIGNED_INT_24_8_REV_NV and format is not 486 DEPTH_STENCIL_EXT. 487 488 489 Add the following error to the NV_copy_depth_to_color 490 specification: 491 492 The error INVALID_OPERATION is generated if CopyPixels is called 493 where type is DEPTH_STENCIL_TO_RGBA_NV or DEPTH_STENCL_TO_BGRA_NV 494 and the depth buffer uses a floating point representation. 495 496New State 497 498 None. 499 500Issues 501 502 1. Should this extension expose floating-point depth buffers through 503 WGL/GLX "pixel formats?" 504 505 RESOLVED: No. The WGL_EXT_depth_float extension already provides a 506 mechanism for requesting a floating-point depth buffer. 507 508 2. How does an application access the full range of a floating-point 509 depth buffer? 510 511 RESOLVED: New functions have been introduced that set existing GL 512 state without clamping to the range [0, 1]. These functions are 513 DepthRangedNV, ClearDepthdNV, and DepthBoundsdNV. 514 515 3. Should we add a new state query to determine if the depth buffer is 516 using a floating-point representation? 517 518 RESOLVED: Yes. An application can query DEPTH_FLOAT_MODE_NV to see 519 if the depth buffer is using a floating-point representation. 520 521 4. How does polygon offset work with floating-point depth buffers? 522 523 RESOLVED: The third paragraph of section 3.5.5 (Depth Offset) 524 describes the minimum resolvable difference r as "the smallest 525 difference in window coordinate z values that is guaranteed to remain 526 distinct throughout polygon rasterization and in the depth buffer." 527 The polygon offset value o is computed as a function of r. The 528 minimum resolvable difference r makes sense for fixed-point depth 529 values, and even floating-point depth values in the range [-1, 1]. 530 For unclamped floating-point depth values, there is no constant 531 minimum resolvable difference -- the minimum difference necessary to 532 change the mantissa of a floating-point value by one bit depends on 533 the exponent of the value being offset. To remedy this problem, the 534 minimum resolvable difference is defined to be relative to the range 535 of depth values for the given primitive when the depth buffer is 536 floating-point. 537 538 5. How does NV_copy_depth_to_color work with floating-point depth values? 539 540 RESOLVED: It isn't clear that there is any usefulness to copying the 541 data for 32-bit floating-point depth values to a fixed-point color 542 buffer. It is even less clear how copying packed data from a 543 FLOAT_32_UNSIGNED_24_8_REV_NV depth/stencil buffer to a fixed-point color 544 buffer would be useful or even how it should be implemented. An error 545 should be generated if CopyPixels is called where <type> is 546 DEPTH_STENCIL_TO_RGBA_NV or DEPTH_STENCIL_TO_BGRA and the depth buffer 547 uses a floating-point representation. 548 549 6. Other OpenGL hardware implementations may be capable of supporting 550 floating-point depth buffers. Why is this an NV extension? 551 552 RESOLVED: When rendering to floating-point depth buffers, we expect 553 that other implementations may only be capable of supporting Z values 554 in the range [0,1]. For such implementations, floating-point Z 555 buffers do not improve the range of Z values supported, but do offer 556 increased precision than conventional 24-bit fixed-point Z buffers, 557 particularly around zero. 558 559 This extension was initially proposed as an EXT, but we have changed 560 it to an NV extension in the expectation that an EXT may be offered at 561 some point in the not-too-distant future. We expect that the EXT 562 could be supported by a larger range of vendors. NVIDIA would 563 continue to support both extensions, where the NV extension could be 564 thought of as taking the capability of the EXT version and extending 565 it to support Z values outside the range [0,1]. 566 567Revision History 568 569 Rev. Date Author Changes 570 ---- -------- -------- ----------------------------------------- 571 12 06/09/16 mjk Added missing _NV suffixing 572 573 11 07/27/10 srahman GLX protocol added. 574 575 10 01/30/09 rsrinivasiah Define interaction with ARB_depth_buffer_float 576 577 9 08/06/08 jleech Fix missing _REV in some token names. 578 579 8 02/09/07 pbrown Updated status section (now released). 580 581 7 10/11/06 pbrown Rename the extension from EXT to NV. 582 583 6 Internal spec revisions. 584