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 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: " 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 is STENCIL or DEPTH, then it is as if the for ReadPixels were STENCIL_INDEX or DEPTH_COMPONENT, respectively. If the is COLOR, then if the GL is in RGBA mode, it is as if the were RGBA, while if the GL is in color index mode, it is as if the were COLOR_INDEX. If the is any of DEPTH_STENCIL_NV, DEPTH_STENCIL_TO_RGBA_NV, or DEPTH_STENCIL_TO_BGRA_NV, it is as if the were DEPTH_STENCIL_NV. The groups of elements so obtained are then written to the framebuffer just as if DrawPixels had been given and , beginning with final conversion of elements. The effective is the same as that already described, unless 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 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 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 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