Name

    EXT_framebuffer_multisample

Name Strings

    GL_EXT_framebuffer_multisample

Contributors

    Pat Brown
    Michael Gold
    Evan Hart
    Jeff Juliano
    Jon Leech
    Bill Licea-Kane
    Barthold Lichtenbelt
    Kent Lin
    Ian Romanick
    John Rosasco
    Jeremy Sandmel

Contacts

    Jeff Juliano, NVIDIA Corporation (jjuliano 'at' nvidia.com)
    Jeremy Sandmel, Apple Computer (jsandmel 'at' apple.com)

Status

    Complete
    Approved by the ARB "superbuffers" Working Group on November 8, 2005

Version

    Last Modified Date: January 10, 2007
    Revision: #7

Number

    317

Dependencies

    Requires GL_EXT_framebuffer_object.

    Requires GL_EXT_framebuffer_blit.

    Written based on the wording of the OpenGL 1.5 specification.

Overview

    This extension extends the EXT_framebuffer_object framework to
    enable multisample rendering.

    The new operation RenderbufferStorageMultisampleEXT() allocates
    storage for a renderbuffer object that can be used as a multisample
    buffer.  A multisample render buffer image differs from a
    single-sample render buffer image in that a multisample image has a
    number of SAMPLES that is greater than zero.  No method is provided
    for creating multisample texture images.

    All of the framebuffer-attachable images attached to a framebuffer
    object must have the same number of SAMPLES or else the framebuffer
    object is not "framebuffer complete".  If a framebuffer object with
    multisample attachments is "framebuffer complete", then the
    framebuffer object behaves as if SAMPLE_BUFFERS is one.

    In traditional multisample rendering, where
    DRAW_FRAMEBUFFER_BINDING_EXT is zero and SAMPLE_BUFFERS is one, the
    GL spec states that "the color sample values are resolved to a
    single, displayable color each time a pixel is updated."  There are,
    however, several modern hardware implementations that do not
    actually resolve for each sample update, but instead postpones the
    resolve operation to a later time and resolve a batch of sample
    updates at a time.  This is OK as long as the implementation behaves
    "as if" it had resolved a sample-at-a-time. Unfortunately, however,
    honoring the "as if" rule can sometimes degrade performance.

    In contrast, when DRAW_FRAMEBUFFER_BINDING_EXT is an
    application-created framebuffer object, MULTISAMPLE is enabled, and
    SAMPLE_BUFFERS is one, there is no implicit per-sample-update
    resolve.  Instead, the application explicitly controls when the
    resolve operation is performed.  The resolve operation is affected
    by calling BlitFramebufferEXT (provided by the EXT_framebuffer_blit
    extension) where the source is a multisample application-created
    framebuffer object and the destination is a single-sample
    framebuffer object (either application-created or window-system
    provided).

    This design for multisample resolve more closely matches current
    hardware, but still permits implementations which choose to resolve
    a single sample at a time.  If hardware that implementes the
    multisample resolution "one sample at a time" exposes
    EXT_framebuffer_multisample, it could perform the implicit resolve
    to a driver-managed hidden surface, then read from that surface when
    the application calls BlitFramebufferEXT.

    Another motivation for granting the application explicit control
    over the multisample resolve operation has to do with the
    flexibility afforded by EXT_framebuffer_object.  Previously, a
    drawable (window or pbuffer) had exclusive access to all of its
    buffers.  There was no mechanism for sharing a buffer across
    multiple drawables.  Under EXT_framebuffer_object, however, a
    mechanism exists for sharing a framebuffer-attachable image across
    several framebuffer objects, as well as sharing an image between a
    framebuffer object and a texture.  If we had retained the "implicit"
    resolve from traditional multisampled rendering, and allowed the
    creation of "multisample" format renderbuffers, then this type of
    sharing would have lead to two problematic situations:

      * Two contexts, which shared renderbuffers, might perform
        competing resolve operations into the same single-sample buffer
        with ambiguous results.

      * It would have introduced the unfortunate ability to use the
        single-sample buffer as a texture while MULTISAMPLE is ENABLED.

    By using the BlitFramebufferEXT from EXT_framebuffer_blit as an
    explicit resolve to serialize access to the multisampled contents
    and eliminate the implicit per-sample resolve operation, we avoid
    both of these problems.

Issues

    Breaking from past convention, the issues section has been moved to
    the end of the document.  It can be found after Examples, before
    Revision History.

New Procedures and Functions

    void RenderbufferStorageMultisampleEXT(
            enum target, sizei samples,
            enum internalformat,
            sizei width, sizei height);

New Types

    None.

New Tokens

    Accepted by the <pname> parameter of GetRenderbufferParameterivEXT:

        RENDERBUFFER_SAMPLES_EXT            0x8CAB

    Returned by CheckFramebufferStatusEXT:

        FRAMEBUFFER_INCOMPLETE_MULTISAMPLE_EXT  0x8D56

    Accepted by the <pname> parameter of GetBooleanv, GetIntegerv,
    GetFloatv, and GetDoublev:

        MAX_SAMPLES_EXT                     0x8D57

Additions to Chapter 2 of the 1.5 Specification (OpenGL Operation)

Additions to Chapter 3 of the OpenGL 1.5 Specification (Rasterization)

Additions to Chapter 4 of the OpenGL 1.5 Specification (Per-Fragment
Operations and the Framebuffer)

Add to 4.3.2 (Reading Pixels), right before the subsection titled
"Obtaining Pixels form the Framebuffer":

    "ReadPixels generates INVALID_OPERATION if READ_FRAMEBUFFER_BINDING
    (section 4.4) is non-zero, the read framebuffer is framebuffer
    complete, and the value of SAMPLE_BUFFERS for the read framebuffer
    is greater than zero."

Modify the following text to section 4.3.3, page 194, that was added to
the definition of CopyPixels by EXT_framebuffer_blit:

    "Finally, the behavior of several GL operations is specified "as if
    the arguments were passed to CopyPixels."  These operations include:
    CopyTex{Sub}Image*, CopyColor{Sub}Table, and CopyConvolutionFilter*.
    INVALID_FRAMEBUFFER_OPERATION_EXT will be generated if an attempt is
    made to execute one of these operations, or CopyPixels, while the
    object bound to READ_FRAMEBUFFER_BINDING_EXT (section 4.4) is not
    "framebuffer complete" (as defined in section 4.4.4.2).
    INVALID_OPERATION will be generated if the object bound to
    READ_FRAMEBUFFER_BINDING_EXT is "framebuffer complete" and the value
    of SAMPLE_BUFFERS is greater than zero.

    Furthermore, an attempt to execute CopyPixels will generate
    INVALID_FRAMEBUFFER_OPERATION_EXT while the object bound to
    DRAW_FRAMEBUFFER_BINDING_EXT (section 4.4) is not "framebuffer
    complete".

In 4.3.3 (Copying Pixels), add to the section describing BlitFramebuffer
that was added by EXT_framebuffer_blit.

    "If SAMPLE_BUFFERS for the read framebuffer is greater than zero and
    SAMPLE_BUFFERS for the draw framebuffer is zero, the samples
    corresponding to each pixel location in the source are converted to
    a single sample before being written to the destination.

    If SAMPLE_BUFFERS for the read framebuffer is zero and
    SAMPLE_BUFFERS for the draw framebuffer is greater than zero, the
    value of the source sample is replicated in each of the destination
    samples.

    If SAMPLE_BUFFERS for both the read and draw framebuffers are
    greater than zero, and the values of SAMPLES for the read and draw
    framebuffers are identical, the samples are copied without
    modification from the read framebuffer to the draw framebuffer.
    Otherwise, no copy is performed and an INVALID_OPERATION error is
    generated.

    Furthermore, if SAMPLE_BUFFERS for either the read framebuffer or
    draw framebuffer is greater than zero, no copy is performed and an
    INVALID_OPERATION error is generated if the dimensions of the source
    and destination rectangles provided to BlitFramebuffer are not
    identical, or if the formats of the read and draw framebuffers are
    not identical."

Modification to 4.4.2.1 (Renderbuffer Objects)

    Add, just above the definition of RenderbufferStorageEXT:

    "The command

        void RenderbufferStorageMultisampleEXT(
            enum target, sizei samples,
            enum internalformat,
            sizei width, sizei height);

    establishes the data storage, format, dimensions, and number of
    samples of a renderbuffer object's image.  <target> must be
    RENDERBUFFER_EXT.  <internalformat> must be RGB, RGBA,
    DEPTH_COMPONENT, STENCIL_INDEX, or one of the internal formats from
    table 3.16 or table 2.nnn that has a base internal format of RGB,
    RGBA, DEPTH_COMPONENT, or STENCIL_INDEX.  <width> and <height> are
    the dimensions in pixels of the renderbuffer.  If either <width> or
    <height> is greater than MAX_RENDERBUFFER_SIZE_EXT, or if <samples>
    is greater than MAX_SAMPLES_EXT, then the error INVALID_VALUE is
    generated. If the GL is unable to create a data store of the
    requested size, the error OUT_OF_MEMORY is generated.

    Upon success, RenderbufferStorageMultisampleEXT deletes any existing
    data store for the renderbuffer image and the contents of the data
    store after calling RenderbufferStorageMultisampleEXT are undefined.
    RENDERBUFFER_WIDTH_EXT is set to <width>, RENDERBUFFER_HEIGHT_EXT is
    set to <height>, and RENDERBUFFER_INTERNAL_FORMAT_EXT is set to
    <internalformat>.

    If <samples> is zero, then RENDERBUFFER_SAMPLES_EXT is set to zero.
    Otherwise <samples> represents a request for a desired minimum
    number of samples. Since different implementations may support
    different sample counts for multisampled rendering, the actual
    number of samples allocated for the renderbuffer image is
    implementation dependent.  However, the resulting value for
    RENDERBUFFER_SAMPLES_EXT is guaranteed to be greater than or equal
    to <samples> and no more than the next larger sample count supported
    by the implementation.

    Sized                 Base               S
    Internal Format       Internal format    Bits
    ---------------       ---------------    ----
    STENCIL_INDEX1_EXT    STENCIL_INDEX      1
    STENCIL_INDEX4_EXT    STENCIL_INDEX      4
    STENCIL_INDEX8_EXT    STENCIL_INDEX      8
    STENCIL_INDEX16_EXT   STENCIL_INDEX      16
    ------------------------------------------------------------------
    Table 2.nnn Desired component resolution for each sized internal
    format that can be used only with renderbuffers.

    A GL implementation may vary its allocation of internal component
    resolution based on any RenderbufferStorage parameter (except
    target), but the allocation and chosen internal format must not be a
    function of any other state and cannot be changed once they are
    established."

    Modify the definiton of RenderbufferStorageEXT as follows:

    "The command

        void RenderbufferStorageEXT(enum target, enum internalformat,
                                    sizei width, sizei height);

     is equivalent to calling RenderbufferStorageMultisampleEXT with
     <samples> equal to zero."

Modification to 4.4.4.2 (Framebuffer Completeness)

    Add an entry to the bullet list:

    * The value of RENDERBUFFER_SAMPLES_EXT is the same for all attached
      images.
      { FRAMEBUFFER_INCOMPLETE_MULTISAMPLE_EXT }

    Also add a paragraph to the end of the section:

    "The values of SAMPLE_BUFFERS and SAMPLES are derived from the
    attachments of the currently bound framebuffer object.  If the
    current DRAW_FRAMEBUFFER_BINDING_EXT is not "framebuffer complete",
    then both SAMPLE_BUFFERS and SAMPLES are undefined.  Otherwise,
    SAMPLES is equal to the value of RENDERBUFFER_SAMPLES_EXT for the
    attached images (which all must have the same value for
    RENDERBUFFER_SAMPLES_EXT).  Further, SAMPLE_BUFFERS is one if
    SAMPLES is non-zero.  Otherwise, SAMPLE_BUFFERS is zero.

Additions to Chapter 5 of the OpenGL 1.5 Specification (Special Functions)

    Added to section 5.4, as part of the discussion of which commands
    are not compiled into display lists:

    "Certain commands, when called while compiling a display list, are
    not compiled into the display list but are executed immediately.
    These are: ..., RenderbufferStorageMultisampleEXT..."

Additions to Chapter 6 of the OpenGL 1.5 Specification (State and State
Requests)

Modification to 6.1.3 (Enumerated Queries):

    In the list of state query functions, modify the definition of
    GetRenderbufferParameterivEXT as follows:

    "void GetRenderbufferParameterivEXT(enum target, enum pname,
                                       int* params);

        <target> must be RENDERBUFFER_EXT.  <pname> must be one of the
        symbolic values in table 8.nnn.

        If the renderbuffer currently bound to <target> is zero, then
        INVALID_OPERATION is generated.

        Upon successful return from GetRenderbufferParameterivEXT, if
        <pname> is RENDERBUFFER_WIDTH_EXT, RENDERBUFFER_HEIGHT_EXT,
        RENDERBUFFER_INTERNAL_FORMAT_EXT, or RENDERBUFFER_SAMPLES_EXT,
        then <params> will contain the width in pixels, height in
        pixels, internal format, or number of samples, respectively, of
        the renderbuffer currently bound to <target>.

        Otherwise, INVALID_ENUM is generated."

GLX Protocol

    RenderbufferStorageMultisampleEXT

        2       24              rendering command length
        2       4331            rendering command opcode
        4       ENUM            target
        4       CARD32          samples
        4       ENUM            internalformat
        4       CARD32          width
        4       CARD32          height

Dependencies on EXT_framebuffer_object

    EXT_framebuffer_object is required.
    
Dependencies on EXT_framebuffer_blit    

    EXT_framebuffer_blit is required.  Technically, EXT_framebuffer_blit
    would not be required to support multisampled rendering, except for
    the fact that it provides the only method of doing a multisample
    resovle from a multisample renderbuffer.

Errors

    The error INVALID_OPERATION_EXT is generated if ReadPixels,
    CopyPixels, CopyTex{Sub}Image*, CopyColor{Sub}Table, or
    CopyConvolutionFilter* is called while READ_FRAMEBUFFER_BINDING_EXT
    is non-zero, the read framebuffer is framebuffer complete, and the
    value of SAMPLE_BUFFERS for the read framebuffer is greater than
    zero.

    The error OUT_OF_MEMORY is generated when
    RenderbufferStorageMultisampleEXT cannot create storage of the
    specified size.

    If both the draw and read framebuffers are framebuffer complete and
    both have a value of SAMPLE_BUFFERS that is greater than zero, then
    the error INVALID_OPERATION is generated if BlitFramebufferEXT is
    called and the values of SAMPLES for the draw and read framebuffers
    do not match.

    If both the draw and read framebuffers are framebuffer complete and
    either has a value of SAMPLE_BUFFERS that is greater than zero, then
    the error INVALID_OPERATION is generated if BlitFramebufferEXT is
    called and the formats of the draw and read framebuffers are not
    identical.

    If either the draw or read framebuffer is framebuffer complete and
    has a value of SAMPLE_BUFFERS that is greater than zero, then the
    error INVALID_OPERATION is generated if BlitFramebufferEXT is called
    and the specified source and destination dimensions are not
    identical.

    If RenderbufferStorageMultisampleEXT is called with a value of
    <samples> that is greater than MAX_SAMPLES_EXT, then the error
    INVALID_VALUE is generated.

New State

    (add to table 8.nnn, "Renderbuffers (state per renderbuffer object)")

    Get Value                          Type    Get Command                    Initial Value  Description             Section       Attribute
    -------------------------------    ------  -------------                  -------------  --------------------    ------------  ---------
    RENDERBUFFER_SAMPLES_EXT           Z+      GetRenderbufferParameterivEXT  0              number of samples       4.4.2.1       -


To the table added by EXT_framebuffer_object called "Framebuffer
Dependent Values", table 9.nnn, add the following new framebuffer
dependent state.

    Get Value        Type  Get Command     Minimum Value    Description             Section  Attribute
    ---------        ----  -----------     -------------    -------------------     -------  ---------
    MAX_SAMPLES_EXT  Z+    GetIntegerv     1                Maximum number of       4.4.2.1  -
                                                            samples supported
                                                            for multisampling
                                                            

Usage Examples

    XXX add examples XXX

Issues

    (1)  Should this be a separate extension or should it be included in
         a revision of EXT_framebuffer_object?

         RESOLVED, separate extension
         
            Resolved by consensus, May 9, 2005
         
         This extension requires EXT_framebuffer_object but the reverse
         is not true.  In addition, the cross framebuffer copy operation
         that will be used to handle the multisample resolution
         operation may be generally useful for non-multisampled
         rendering, but is pretty much required for multisampled
         rendering to be useful.  Since we don't want
         EXT_framebuffer_object to require that functionality either, we
         split EXT_framebuffer_multisample into its own extension.
         EXT_framebuffer_multisample might include the "cross
         framebuffer copy" operation or might simply require the
         presence of that third extension.  See issue (8).

    (2)  What happens when <samples> is zero or one?

         RESOLVED, 0 = single sample, 1 = minimum multisample

            Resolved by consensus, May 9, 2005

         Zero means single sample, as if RenderbufferStorageEXT had been
         called instead of RenderbufferStorageMultisampleEXT.  One means
         minimum number of samples supported by implementation.

         There was a question if one should mean the same thing as
         single-sample (one sample), or if it should mean the minimum
         supported number of samples for multisample rendering.  The
         rules for rasterizing in "multisample" mode are different than
         "non-multisample" mode.  In the end, we decided that some
         implementations may wish to support a "one-sample" multisample
         buffer to allow for multipass multisampling where the sample
         location can be varied either by the implementation or perhaps
         explicitly by a "multisample location" extension.

    (3)  Is ReadPixels (or CopyPixels or CopyTexImage) permitted when
         bound to a multisample framebuffer object?

         RESOLVED, no
         
             Resolved by consensus, prior to May 9, 2005

         No, those operations will produce INVALID_OPERATION.  To read
         the contents of a multisample framebuffer, it must first be
         "downsampled" into a non-multisample destination, then read
         from there.  For downsample, see EXT_framebuffer_blit.

         The concern is fallback due to out of memory conditions.  Even
         if no memory is available to allocate a temporary buffer at the
         time ReadPixels is called, an implementation should be able to
         make this work by pre-allocating a small tile and doing the
         downsample in tiles, or by falling back to software to copy a
         pixel at a time.

    (4)  Does the resolution from <samples> to RENDERBUFFER_SAMPLES_EXT
         depend on any other parameters to
         RenderbufferStorageMultisampleEXT, or must a given value of
         <samples> always resolve to the same number of actual samples?

         RESOLVED, no, further, user must get at least what they asked
         for, or Storage call fails:

            Resolved by consensus, May 23, 2005

         
         Given the routine,
        
            void RenderbufferStorageMultisampleEXT(
                    enum target, uint samples,
                    enum internalformat,
                    uint width, uint height);
        
         If an implementation supports several sample counts (say, 2x,
         4x, 8x multisample), and the user requests a sample count of
         <samples>, the implementation must do one of the following:
         
            - succeed in giving the user exactly <samples>, or

            - succeed in giving the user a number of samples greater
              than <samples> but no more than the next highest number of
              samples supported by the implementation, or

            - fail the request to RenderbufferStorageMultisampleEXT with
              an OUT_OF_MEMORY error

    (5)  Is an implementation allowed to create single-sample storage
         when RenderbufferStorageMultisampleEXT is called with <samples>
         larger than one?

         RESOLVED, no

            Resolved by consensus, May 23, 2005
            
            No, by resolution of issue (4) above, the user must get at
            least what they asked for or higher, which precludes getting
            a single sampled format if they asked for a multisampled
            format.

    (6)  Should OUT_OF_MEMORY be generated when
         RenderbufferStorageMultisampleEXT cannot create storage of the
         requested size?

         RESOLVED, yes

            Resolved by consensus, May 23, 2005
    
         Yes.  Success or failure is determined by <width>, <height>,
         <internalformat>, and <samples>, and the implementation can
         always return OUT_OF_MEMORY. Note that while an implementation
         may give a different internal format with either higher or
         lower resolution per component than the internal requested, by
         issue of resolution (4), it must give at least the number of
         samples requested or it must fail the
         RenderbufferStorageMultisampleEXT call.
         
             Update from June 2006 ARB meeting:
             
             The appropriate error for the case where the number of
             samples is larger than the maximum supported by the
             implementation is INVALID_VALUE.  To allow an application
             to know the maximum legal value, we add a GetInteger query
             MAX_SAMPLES.

    (7)  Is there a query for the maximum size of <samples>?

         RESOLVED, Yes

         There was some discussion about whether it was useful to return
         a maximum sample count supported by the implementation as a
         convenenience to the developer so that the developer doesn't
         need to try increasingly smaller counts until it finds one that
         succeeds.  Originally this query was ommitted, but later it was
         added (MAX_SAMPLES_EXT).

    (8)  Does this extension require our new framebuffer-to-framebuffer
         copy extension, EXT_framebuffer_blit, or is it merely affected
         by the presence of that extension.
         
         RESOLVED, EXT_framebuffer_blit is required.
         
         EXT_framebuffer_multisample by itself enable the user to
         perform multisampled rendering.  However, you can't copy or
         read from a multisampled renderbuffer using {Read|Copy}Pixels
         or CopyTex{Sub}Image - as per issue (3).  Consequently, there
         is no way to actually use the results of multisampled rendering
         without EXT_framebuffer_blit.  That makes the
         EXT_framebuffer_multisample extension arguably kind of useless
         without the EXT_framebuffer_blit.
         
         However, the reverse is not true.  The EXT_framebuffer_blit is
         useful on its own, which is why it is a separate extension from
         this one.
         
         So we decided to state that EXT_framebuffer_multisample
         requires EXT_framebuffer_blit instead of merely stating that
         that extension affects this one.

    (9)  Is DrawPixels allowed when the draw framebuffer is multisample?

         RESOLVED, yes

         This is no different than DrawPixels to a multisample window
         (framebuffer zero).  Note that ReadPixels and CopyPixels are
         disallowed when the read framebuffer is multisample.
         
Revision History
    #7, Jan 10, 2007: jjuliano
        - add missing constraint that a multisample blit requires
          identical formats for the read and draw framebuffers
        - correct the resolution of issue 7 (MAX_SAMPLES_EXT)
        - fix typos

    #6c, November 6, 2006: jjuliano
        - changes from June #6 merged back in

    #6b, October 13, 2006: Jon Leech
        - added token values for MAX_SAMPLES_EXT and
          FRAMEBUFFER_INCOMPLETE_MULTISAMPLE_EXT.

    #6a, September 6, 2006: jsandmel
        - added language describing MAX_SAMPLES query
        - clarified that RenderbufferStorageMultisampleEXT can fail
          with INVALID_VALUE if <samples> is greater than MAX_SAMPLES

    #6, June 1, 2006: jjuliano
        - add missing errors to Errors section
        - clarify the modifications to 4.3.2 and 4.3.3.
        - add issue 9 to document that multisample DrawPixels is allowed

    #5, December 22, 2005: Jon Leech
        - added GLX protocol, assigned enumerant values

    #4, September 28, 2005: jsandmel, jjuliano
        - moved the multisample languge from GL_EXT_framebuffer_blit to 
          this spec.
        - added description of using BlitFramebufferEXT for resolving
          multisample buffer
        - added language referring to DRAW_/READ_FRAMEBUFFER_BINDING
          instead of just FRAMEBUFFER_BINDING.
        - minor updates to reflect new EXT_framebuffer_blit spec
          that provides the multisample resolve function
        - resolve issue (8)
        - rename framebuffer_object_multisample to
          framebuffer_multisample

    #3, May 26, 2005: jsandmel
        - added recent workgroup resolutions
        - resolved issues (4), (5), (6), (7) based on decisions from the
          work group on May 9 and 23, 2005
        - added issue (8), does this extension require our new
          cross-framebuffer copy extension?
        - removed MAX_RENDERBUFFER_SAMPLES_EXT enum as per work group
          decision - issue (7)
        - changed prototype for RenderbufferStorageMultisampleEXT to use
          sizei for sample count

    #2, May 16, 2005: jsandmel
        - revised to account for recent work group meeting decisions
        - removed erroneous inclusion of GenerateMipmaps as a new
          function
        - resolved issue (1), this will be a separate extension
        - resolved issue (2), zero means non-multisample, one means
          minimum number of samples

    #1, May 9, 2005: jjuliano
        - first revision