Name

    QCOM_tiled_rendering

Name Strings

    GL_QCOM_tiled_rendering

Contributors

    Colin Sharp
    Jeff Leger

Contacts

    Chuck Smith, Qualcomm (chucks 'at' qualcomm.com)
    Maurice Ribble, Qualcomm (mribble 'at' qualcomm.com)

Notice

    Copyright Qualcomm 2009.

IP Status

    Qualcomm Proprietary.

Status

    Complete.

Version

    Last Modified Date: August 20, 2009
    Revision: #1.6

Number

    OpenGL ES Extension #70

Dependencies

    OpenGL ES 1.0 or higher is required.

    This extension interacts with QCOM_write_only_rendering.

    This extension is written based on the wording of the OpenGL ES 2.0
    specification.

Overview

    In the handheld graphics space, a typical challenge is achieving efficient
    rendering performance given the different characteristics of the various
    types of graphics memory.  Some types of memory ("slow" memory) are less
    expensive but have low bandwidth, higher latency, and/or higher power
    consumption, while other types ("fast" memory) are more expensive but have
    higher bandwidth, lower latency, and/or lower power consumption.  In many
    cases, it is more efficient for a graphics processing unit (GPU) to render
    directly to fast memory, but at most common display resolutions it is not
    practical for a device to contain enough fast memory to accommodate both the
    full color and depth/stencil buffers (the frame buffer).  In some devices,
    this problem can be addressed by providing both types of memory; a large
    amount of slow memory that is sufficient to store the entire frame buffer,
    and a small, dedicated amount of fast memory that allows the GPU to render
    with optimal performance.  The challenge lies in finding a way for the GPU
    to render to fast memory when it is not large enough to contain the actual
    frame buffer.

    One approach to solving this problem is to design the GPU and/or driver
    using a tiled rendering architecture.  With this approach the render target
    is subdivided into a number of individual tiles, which are sized to fit
    within the available amount of fast memory.  Under normal operation, the
    entire scene will be rendered to each individual tile using a multi-pass
    technique, in which primitives that lie entirely outside of the tile being
    rendered are trivially discarded.  After each tile has been rendered, its
    contents are saved out to the actual frame buffer in slow memory (a process
    referred to as the "resolve").  The resolve introduces significant overhead,
    both for the CPU and the GPU.  However, even with this additional overhead,
    rendering using this method is usually more efficient than rendering
    directly to slow memory.

    This extension allows the application to specify a rectangular tile
    rendering area and have full control over the resolves for that area.  The
    information given to the driver through this API can be used to perform
    various optimizations in the driver and hardware.  One example optimization
    is being able to reduce the size or number of the resolves.  Another
    optimization might be to reduce the number of passes needed in the tiling
    approach mentioned above.  Even traditional rendering GPUs that don't use
    tiles may benefit from this extension depending on their implemention of
    certain common GPU operations.

    One typical use case could involve an application only rendering to select
    portions of the render target using this technique (which shall be referred
    to as "application tiling"), leaving all other portions of the render target
    untouched.  Therefore, in order to preserve the contents of the untouched
    portions of the render target, the application must request an EGL (or other
    context management API) configuration with a non-destructive swap. A
    destructive swap may only be used safely if the application renders to the
    entire area of the render target during each frame (otherwise the contents
    of the untouched portions of the frame buffer will be undefined).

    Additionally, care must be taken to avoid the cost of mixing rendering with
    and without application tiling within a single frame.  Rendering without
    application tiling ("normal" rendering) is most efficient when all of the
    rendering for the entire scene can be encompassed within a single resolve.
    If any portions of the scene are rendered prior to that resolve (such as via
    a prior resolve, or via application tiling), then that resolve becomes much
    more heavyweight.  When this occurs, prior to rendering each tile the fast
    memory must be populated with the existing contents of the frame buffer
    region corresponding to that tile.  This operation can double the cost of
    resolves, so it is recommended that applications avoid mixing application
    tiling and normal rendering within a single frame.  If both rendering
    methods must be used in the same frame, then the most efficient approach is
    to perform all normal rendering first, followed by rendering done with
    application tiling.  An implicit resolve will occur (if needed) at the start
    of application tiling, so any pending normal rendering operations will be
    flushed at the time application tiling is initiated.  This extension
    provides interfaces for the application to communicate to the driver whether
    or not rendering done with application tiling depends on the existing
    contents of the specified tile, and whether or not the rendered contents of
    the specified tile need to be preserved upon completion.  This mechanism can
    be used to obtain optimal performance, e.g. when the application knows that
    every pixel in a tile will be completely rendered or when the resulting
    contents of the depth/stencil buffers do not need to be preserved.

Issues

    (1)  How do Viewport and Scissor interact with this extension?

    RESOLVED:  They don't.  When application tiling is used, the viewport and
    scissor retain their existing values, relative to the render target, not the
    specified tile.  Therefore, all rendering commands issued between
    StartTilingQCOM and EndTilingQCOM will be subject to the same scissor, and
    will undergo the same viewport transformation, as normal rendering commands.

    (2)  How do Flush and Finish interact with this extension?

    RESOLVED:  When Flush or Finish is called while application tiling is
    active, the behavior will be as if EndTilingQCOM was called, except that the
    application tiling state will remain unchanged (meaning the active tile will
    not be reset).  This means that any pending rendering commands will be
    performed to the active tile, and application tiling will continue to be
    active for any following rendering commands.

    (3)  How does SwapBuffers interact with this extension?

    RESOLVED:  It doesn't.  If SwapBuffers is called while application tiling is
    active, the contents of the entire back buffer will be copied to the visible
    window, ignoring the active tile.  SwapBuffers will have no effect on the
    application tiling state.

    (4)  What happens if the render target is changed while application tiling
         is active?

    RESOLVED:  If the current render target is changed, either by binding a new
    framebuffer object or changing the write surface of the active framebuffer
    (either explicitly or by deleting the currently bound framebuffer or write
    surface), an implicit EndTilingQCOM will occur.  The active tile will be
    reset and application tiling will be deactivated.  This is necessary because
    the active tile may not be valid for the new render target.

    (5)  Should this extension provide a query mechanism for determining things
         such as tile offset, alignment, and size requirements so a developer
         can intelligently choose tile regions?

    RESOLVED:  No.  This information is very device-dependent and difficult to
    present in an easily understood manner.  Instead, this extension will let
    developers specify an arbitrary rectangular tile region and all these
    requirements, including subdividing the given tile into multiple tiles if
    necessary, will be handled by the driver and hardware.

    (6)  Should this extension allow multiple tiles?

    RESOLVED:  No.  While earlier versions of this extension allowed for this,
    after support for arbitrary tile sizes was added the benefit of multiple
    tiles became negligible.  Allowing multiple tiles complicated the API and
    made it much more difficult for traditional rendering and some tile-based
    rendering GPUs to support this extension.

    (7)  Should multiple render targets be supported?  They are not supported
         by either the OpenGL ES core specification or any existing OpenGL ES
         extensions.  Support could be added with some new bitmasks for the
         <preserveMask> parameter.  Should this be added now, or deferred for
         inclusion in any possible future MRT extension?

    RESOLVED:  Yes.  It is not difficult to add now and doing it now makes 
    supporting MRTs in the future easier.

New Procedures and Functions

    void StartTilingQCOM(uint x, uint y, uint width, uint height,
                         bitfield preserveMask);

    void EndTilingQCOM(bitfield preserveMask);

New Tokens

    Accepted by the <preserveMask> parameter of StartTilingQCOM and
    EndTilingQCOM

        GL_COLOR_BUFFER_BIT0_QCOM                     0x00000001
        GL_COLOR_BUFFER_BIT1_QCOM                     0x00000002
        GL_COLOR_BUFFER_BIT2_QCOM                     0x00000004
        GL_COLOR_BUFFER_BIT3_QCOM                     0x00000008
        GL_COLOR_BUFFER_BIT4_QCOM                     0x00000010
        GL_COLOR_BUFFER_BIT5_QCOM                     0x00000020
        GL_COLOR_BUFFER_BIT6_QCOM                     0x00000040
        GL_COLOR_BUFFER_BIT7_QCOM                     0x00000080
        GL_DEPTH_BUFFER_BIT0_QCOM                     0x00000100
        GL_DEPTH_BUFFER_BIT1_QCOM                     0x00000200
        GL_DEPTH_BUFFER_BIT2_QCOM                     0x00000400
        GL_DEPTH_BUFFER_BIT3_QCOM                     0x00000800
        GL_DEPTH_BUFFER_BIT4_QCOM                     0x00001000
        GL_DEPTH_BUFFER_BIT5_QCOM                     0x00002000
        GL_DEPTH_BUFFER_BIT6_QCOM                     0x00004000
        GL_DEPTH_BUFFER_BIT7_QCOM                     0x00008000
        GL_STENCIL_BUFFER_BIT0_QCOM                   0x00010000
        GL_STENCIL_BUFFER_BIT1_QCOM                   0x00020000
        GL_STENCIL_BUFFER_BIT2_QCOM                   0x00040000
        GL_STENCIL_BUFFER_BIT3_QCOM                   0x00080000
        GL_STENCIL_BUFFER_BIT4_QCOM                   0x00100000
        GL_STENCIL_BUFFER_BIT5_QCOM                   0x00200000
        GL_STENCIL_BUFFER_BIT6_QCOM                   0x00400000
        GL_STENCIL_BUFFER_BIT7_QCOM                   0x00800000
        GL_MULTISAMPLE_BUFFER_BIT0_QCOM               0x01000000
        GL_MULTISAMPLE_BUFFER_BIT1_QCOM               0x02000000
        GL_MULTISAMPLE_BUFFER_BIT2_QCOM               0x04000000
        GL_MULTISAMPLE_BUFFER_BIT3_QCOM               0x08000000
        GL_MULTISAMPLE_BUFFER_BIT4_QCOM               0x10000000
        GL_MULTISAMPLE_BUFFER_BIT5_QCOM               0x20000000
        GL_MULTISAMPLE_BUFFER_BIT6_QCOM               0x40000000
        GL_MULTISAMPLE_BUFFER_BIT7_QCOM               0x80000000

Additions to Chapter 2 of the OpenGL ES 2.0 Specification (OpenGL Operation)

    Add a new section "Rendering with Application Tiling" after section 2.13:

    "2.14 Rendering with Application Tiling

    The application may specify an arbitrary rectangular region (a 'tile') to
    which rendering commands should be restricted.

    The command

        void StartTilingQCOM(uint x, uint y, uint width, uint height,
                             bitfield preserveMask);

    specifies the tile described by <x>, <y>, <width>, <height>.  Until the next
    call to EndTilingQCOM, all rendering commands (including clears) will only
    update the contents of the render target defined by the extents of this
    tile.  The parameters <x> and <y> specify the screen-space origin of the
    tile, and <width> and <height> specify the screen-space width and height of
    the tile.  The tile origin is located at the lower left corner of the tile.
    If the size of the tile is too large for the fast memory on the device then
    it will be internally subdivided into multiple tiles.  The parameter
    <preserveMask> is the bitwise OR of a number of values indicating which
    buffers need to be initialized with the existing contents of the frame
    buffer region corresponding to the specified tile prior to rendering, or the
    single value NONE.  The values allowed are COLOR_BUFFER_BIT*_QCOM,
    DEPTH_BUFFER_BIT*_QCOM, STENCIL_BUFFER_BIT*_QCOM, and
    MULTISAMPLE_BUFFER_BIT*_QCOM.  These indicate the color buffer, the depth
    buffer, the stencil buffer, and a multisample buffer modifier, respectively.
    The multisample bits are different since they modify the meaning of the
    color, depth, and stencil bits if the active surface is a multisample
    surface.  If a multisample bit is set then the corresponding color, depth,
    and/or stencil bit will cause all the samples to be copied across the memory
    bus in devices that are using fast tiled memory, but if the multisample bit
    is not set then only a single resolved sample is copied across the bus.  In
    practice, not setting the multisample bit when rendering to a multisample
    buffer can greatly improve performance, but could cause small rendering
    artifacts in some multiple-pass rendering algorithms.  The 0-7 number is to
    specify which render target is being used.  If multiple render targets are
    not being used then 0 should be specified.  Any buffers specifed in
    <preserveMask> that do not exist in the current rendering state will be
    silently ignored (simlilar to the behavior of Clear).  If NONE is specified,
    then no buffers will be initialized.  For any buffers not initialized in
    this manner, the initial contents will be undefined.

    The values of <x>, <y>, <width> and <height> are silently clamped to the 
    extents of the render target.

    The command

        void EndTilingQCOM(bitfield preserveMask);

    notifies the driver that the application has completed all desired rendering
    to the tile specified by StartTilingQCOM.  This allows the driver to flush
    the contents of the specified tile to the corresponding region of the render
    target, and disables application tiling (resuming normal rendering).  The
    parameter <preserveMask> is specified using the same values as the
    equivalent argument of StartTilingQCOM, but indicates which buffers need to
    be preserved upon completion of all rendering commands issued with
    application tiling.  For any buffers not preserved in this manner, the
    resulting contents of the buffer regions corresponding to the active tile
    will be undefined.

GLX Protocol

    None.

Errors

    INVALID_OPERATION error is generated if StartTilingQCOM is called while
    WRITEONLY_RENDERING_QCOM is enabled or the current framebuffer is not
    framebuffer complete

    INVALID_OPERATION error is generated if EndTilingQCOM is called without a
    corresponding call to StartTilingQCOM

    INVALID_OPERATION error is generated if StartTilingQCOM is called after
    calling StartTilingQCOM without a corresponding call to EndTilingQCOM

    INVALID_OPERATION error is generated if Enable(WRITEONLY_RENDERING_QCOM)
    is called between StartTilingQCOM and EndTilingQCOM

New State

    None.

Sample Usage

    GLboolean renderTiledTriangle(GLuint x, GLuint y, GLuint width, GLuint height)
    {
        // set the active tile and initialize the color and depth buffers with
        // the existing contents
        glStartTilingQCOM(x, y, width, height,
                          GL_COLOR_BUFFER_BIT0_QCOM | GL_DEPTH_BUFFER_BIT0_QCOM);
      
        // draw the triangle
        glDrawArrays(GL_TRIANGLES, 0, 3);

        // finished with this tile -- preserve the color buffer
        glEndTilingQCOM(GL_COLOR_BUFFER_BIT0_QCOM);

        // return success
        return GL_TRUE;
    }

Revision History

    #09    08/20/2009    Chuck Smith     Cosmetic changes
    #08    08/19/2009    Maurice Ribble  Add support for multiple render targets
    #07    07/28/2009    Maurice Ribble  Clean up spec
                                         Remove multiple tile support
    #06    07/23/2009    Maurice Ribble  Updated overview to match latest spec
    #05    07/15/2009    Maurice Ribble  Changed from spec to subdivide tiles
                                         instead of returning out of memory
    #04    07/06/2009    Maurice Ribble  Update due to the AMD->Qualcomm move;
                                         general extension cleanup.
    #03    11/17/2008    Chuck Smith     Clarified the results of EndTilingQCOM
                                         for unpreserved buffers.
    #02    11/10/2008    Chuck Smith     Updates to clarify behavior; additions
                                         to the Issues section.
    #01    11/04/2008    Chuck Smith     First draft.