back  Return to list

GL_NV_copy_depth_to_color
homeprevnext Name
  
    NV_copy_depth_to_color  
  
homeprevnext Name Strings
  
    GL_NV_copy_depth_to_color  
  
homeprevnext Contact
  
    Matt Craighead, NVIDIA Corporation (mcraighead 'at' nvidia.com)  
  
homeprevnext Notice
  
    Copyright NVIDIA Corporation, 2001.  
  
homeprevnext IP Status
  
    NVIDIA Proprietary.  
  
homeprevnext Status
  
    Shipping (version 1.0)  
  
homeprevnext Version
  
    NVIDIA Date: October 17, 2001 (version 1.0)  
    $Date$ $Revision$  
    $Id: //sw/main/docs/OpenGL/specs/GL_NV_copy_depth_to_color.txt#3 $  
  
homeprevnext Number
  
    243  
  
homeprevnext Dependencies
  
    Written based on the wording of the OpenGL 1.2.1 specification.  
  
    Requires support for the NV_packed_depth_stencil extension.  
  
homeprevnext 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.  
  
homeprevnext 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.  
  
homeprevnext New Procedures and Functions
  
    None.  
  
homeprevnext New Tokens
  
    Accepted by the <type> parameter of CopyPixels:  
  
        DEPTH_STENCIL_TO_RGBA_NV                       0x886E  
        DEPTH_STENCIL_TO_BGRA_NV                       0x886F  
  
homeprevnext Additions to Chapter 2 of the OpenGL 1.2.1 Specification (OpenGL Operation)
  
    None.  
  
homeprevnext Additions to Chapter 3 of the OpenGL 1.2.1 Specification (Rasterization)
  
    None.  
  
homeprevnext 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."  
  
homeprevnext Additions to Chapter 5 of the OpenGL 1.2.1 Specification (Special Functions)
  
    None.  
  
homeprevnext Additions to Chapter 6 of the OpenGL 1.2.1 Specification (State and State Requests)
  
    None.  
  
homeprevnext GLX Protocol
  
    None.  
  
homeprevnext 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.  
  
homeprevnext New State
  
    None.  
  
homeprevnext Revision History
  
    none yet  
    none yet  
Valid XHTML 1.1! Valid CSS! Last update: November 14, 2006.
Cette page doit être lue avec un navigateur récent respectant le standard XHTML 1.1.