blob: cacd620051d22a8d6771b6977a0bd5cf3a2fe2df [file] [log] [blame]
Name
NV_copy_depth_to_color
Name Strings
GL_NV_copy_depth_to_color
Contact
Matt Craighead, NVIDIA Corporation (mcraighead 'at' nvidia.com)
Notice
Copyright NVIDIA Corporation, 2001.
IP Status
NVIDIA Proprietary.
Status
Shipping (version 1.0)
Version
Date: October 17, 2001
Version: 1.0
Number
243
Dependencies
Written based on the wording of the OpenGL 1.2.1 specification.
Requires support for the NV_packed_depth_stencil extension.
Overview
Some applications, especially systems for distributed OpenGL
rendering, would like to have a fast way of copying their depth
buffer into a color buffer; for example, this allows the depth buffer
to be scanned out, allowing downstream compositing operations.
To do this operation in unextended OpenGL, the app must use
glReadPixels of GL_DEPTH_COMPONENT data, followed by glDrawPixels of
RGBA data. However, this typically will not provide adequate
performance.
This extension provides a way to copy the depth data directly into
the color buffer, by adding two new options for the "type" parameter
of glCopyPixels: GL_DEPTH_STENCIL_TO_RGBA_NV and
GL_DEPTH_STENCIL_TO_BGRA_NV.
Typically, OpenGL implementations support many more bits of depth
precision than color precision per channel. On many PC platforms, it
is common, for example, to have 24 bits of depth, 8 bits of stencil,
and 8 bits of red, green, blue, and alpha.
In such a framebuffer configuration, the most effective way to copy
the data without this extension would be to perform a glReadPixels of
GL_UNSIGNED_INT_24_8_NV/GL_DEPTH_STENCIL_NV (using the existing
NV_packed_depth_stencil extension), followed by a glDrawPixels of
GL_UNSIGNED_INT_8_8_8_8/GL_RGBA or GL_BGRA data. This places the
depth data in the color channels and the stencil data in the alpha
channel.
This extension's new operations concatenates these two operations,
providing a CopyPixels command that does both of these steps in one.
This provides a large performance speedup, since no pixel data must
be transfered across the bus.
Issues
* Does this spec need a dependency on NV_packed_depth_stencil?
RESOLVED: It doesn't need it, but it does. It makes the spec a
whole lot easier to write. In theory, this extension can be
supported without support for NV_packed_depth_stencil; in
practice, it is very unlikely that any implementation will ever
support this extension, but not NV_packed_depth_stencil.
* Should we support copies to both RGBA and BGRA?
RESOLVED: Yes. We support this, so there is no reason not to
allow users to choose.
* Should pixel transfer operations, fragment operations, and
PixelZoom be applied on the new CopyPixels operations?
RESOLVED: Yes. This is really just a different source data type
for a CopyPixels of COLOR data, so, even though the typical usage
case of this extension differs, there is little reason to cripple
the spec with a nonorthogonality here.
* What is the interaction with depth testing and stencil testing?
RESOLVED: They are allowed. This means that there are
read-modify-write hazards with overlapping CopyPixels, but they
are no worse than with other forms of overlapping CopyPixels; the
rule remains that (effectively) all source data must be read
before any fragments are generated.
That having been said, it is anticipated that applications would
turn these off before performing the copy, because they would
likely impact performance on many implementations, especially if
the source and destination regions overlapped.
* Should a mode useful for 16-bit depth buffers be supported?
RESOLVED: No, that seems fairly uninteresting.
* What restrictions should apply to the use of this extension, both
in terms of the current color buffer format and the current depth
buffer format?
RESOLVED: None beyond the requirement that the drawable must have
both a depth buffer and a stencil buffer. This is similar to the
behavior chosen in NV_packed_depth_stencil. For example, a
ReadPixels of DEPTH_STENCIL_NV data is supported, even if the
drawable does not have 24 bits of depth and 8 bits of stencil.
Although it is not anticipated that this extension will be useful
in other modes, it is specified to work nonetheless.
* What useful things can be done with the stencil in the alpha?
Although it is mostly meaningless to try to blend using the
stencil, one useful way of using this feature is to use the alpha
test. This allows the app to kill certain pixels based on the
stencil during this operation. The app could clear the color
buffer first, creating a "background" depth value, and then the
CopyPixels pass could overwrite that on selected pixels.
New Procedures and Functions
None.
New Tokens
Accepted by the <type> parameter of CopyPixels:
DEPTH_STENCIL_TO_RGBA_NV 0x886E
DEPTH_STENCIL_TO_BGRA_NV 0x886F
Additions to Chapter 2 of the OpenGL 1.2.1 Specification (OpenGL Operation)
None.
Additions to Chapter 3 of the OpenGL 1.2.1 Specification (Rasterization)
None.
Additions to Chapter 4 of the OpenGL 1.2.1 Specification (Per-Fragment
Operations and the Frame Buffer)
Update the second, third, and fourth paragraphs of section 4.3.3
(page 162) to say:
"<type> is a symbolic constant that must be one of COLOR, STENCIL,
DEPTH, or DEPTH_STENCIL_NV, indicating that the values to be
transfered are colors, stencil values, depth values, or depth/stencil
pairs, respectively. The first four arguments have the same
interpretation as the corresponding arguments to ReadPixels.
Values are obtained from the framebuffer, converted (if appropriate),
then subjected to the pixel transfer operations described in section
3.6.5, just as if ReadPixels were called with the corresponding
arguments. If the <type> is STENCIL or DEPTH, then it is as if the
<format> for ReadPixels were STENCIL_INDEX or DEPTH_COMPONENT,
respectively. If the <type> is COLOR, then if the GL is in RGBA
mode, it is as if the <format> were RGBA, while if the GL is in color
index mode, it is as if the <format> were COLOR_INDEX. If the <type>
is any of DEPTH_STENCIL_NV, DEPTH_STENCIL_TO_RGBA_NV, or
DEPTH_STENCIL_TO_BGRA_NV, it is as if the <format> were
DEPTH_STENCIL_NV.
The groups of elements so obtained are then written to the
framebuffer just as if DrawPixels had been given <width> and
<height>, beginning with final conversion of elements. The effective
<format> is the same as that already described, unless <type> is
DEPTH_STENCIL_TO_RGBA_NV or DEPTH_STENCIL_TO_BGRA_NV. In that case,
first, the groups of elements are packed into pixel groups of type
UNSIGNED_INT_24_8_NV. Then, if <type> is DEPTH_STENCIL_TO_RGBA_NV,
they are unpacked as if their type was UNSIGNED_INT_8_8_8_8 and
their format was RGBA, and if <type> is DEPTH_STENCIL_TO_BGRA_NV,
they are unpacked as if their type was UNSIGNED_INT_8_8_8_8 and
their format was BGRA. In either case, the effective <format> of the
pixels to be written to the framebuffer is RGBA."
Additions to Chapter 5 of the OpenGL 1.2.1 Specification (Special Functions)
None.
Additions to Chapter 6 of the OpenGL 1.2.1 Specification (State and
State Requests)
None.
GLX Protocol
None.
Errors
The error INVALID_OPERATION is generated if CopyPixels is called
where type is DEPTH_STENCIL_TO_RGBA_NV or DEPTH_STENCIL_TO_BGRA_NV
and there is not both a depth buffer and a stencil buffer.
The error INVALID_OPERATION is generated if CopyPixels is called
where type is DEPTH_STENCIL_TO_RGBA_NV or DEPTH_STENCIL_TO_BGRA_NV
and the GL is in color index mode.
New State
None.
Revision History
none yet