Name

    EXT_multisampled_render_to_texture2

Name Strings

    GL_EXT_multisampled_render_to_texture2

Contributors

    Jeff Leger
    Maurice Ribble
    Krzysztof Kosinski
    Craig Donner
    Tobias Hector
    Jan-Harald Fredriksen
    Nigel Williams
    Ashish Mathur

Contact

    Ashish Mathur (asmathur 'at' qti.qualcomm.com)

Status

    Complete

Version

    Last Modified Date: October 22, 2025
    Revision: 4

Number

    OpenGL ES Extension #275

Dependencies

    This requires support of EXT_multisample_render_to_texture or an equivalent
    extension.

    This interacts with OVR_multiview_multisampled_render_to_texture.

Overview

    The <attachment> parameters for FramebufferTexture2DMultisampleEXT is no
    longer required to be COLOR_ATTACHMENT0.  The attachment parameter now
    matches what is allowed in FramebufferTexture2D.  This means values like
    GL_COLOR_ATTACHMENTi, GL_DEPTH_ATTACHMENT, GL_STENCIL_ATTACHMENT, or
    GL_DEPTH_STENCIL_ATTACHMENT may be used.
    After the application has rendered into the mutisampled buffer, the application
    should be careful to not trigger an implicit flush by performing a client side
    read of the buffer (readpixels, copyteximage, blitframebuffer, etc) before any
    subsequent rendering which uses the contents of the buffer. This may cause the
    attachment to be downsampled before the following draw, which would potentially
    cause corruption.

IP Status

    No known IP claims.

New Procedures and Functions

    None

New Tokens

    None

Additions to Section 4.4.3 of the OpenGL ES 2.0 Specification
(Renderbuffer Objects)

    Remove the following wording describing FramebufferTexture2DMultisampleEXT:

        "and have the same restrictions.  attachment must be COLOR_ATTACHMENT0."

    In the description of FramebufferTexture2DMultisampleEXT, after the sentence
    "After such a resolve, the contents of the multisample buffer become undefined.",
    add the following sentence:

        "If the multisampled buffer is a depth or stencil texture, then it is discarded -
        equivalent to the application calling InvalidateFramebuffer for this attachment.
        If the multisample buffer is a depth/stencil renderbuffer then it is not discarded."

Errors

    Remove this error:
    The error INVALID_ENUM is generated if FramebufferTexture2DMultisampleEXT
    is called with an <attachment> that is not COLOR_ATTACHMENT0.

Issues

    1. How should downsampling depth/stencil surfaces be handled?

    Proposed: Ideally, when using this extension, depth/stencil attachments should
    always be discarded/invalidated by the application *before* the rendering is
    submitted.  If the application fails to do so, the implementation is not required
    to preserve the contents of those attachments.  A depth/stencil resolve is
    equivalent to InvalidateFramebuffer for those attachments.

    2. Should a multisample renderbuffer depth/stencil attachment be discarded too?

    Resolved: No. Only a multisample texture depth/stencil attachment is discarded.

Revision History

    Revision 1, 2016/9/15
      - First draft of extension
    Revision 2, 2016/12/2
      - Added interaction with OVR_multiview_multisampled_render_to_texture
      - Added issue for downsampling depth
    Revision 3, 2017/02/27
      - Final version. A depth/stencil resolve is equivalent
        to InvalidateFramebuffer
    Revision 4, 2025/10/22
      - Clarify multisample renderbuffer depth/stencil discard behavior