• Home
  • Line#
  • Scopes#
  • Navigate#
  • Raw
  • Download
1Name
2
3    EXT_multisampled_render_to_texture2
4
5Name Strings
6
7    GL_EXT_multisampled_render_to_texture2
8
9Contributors
10
11    Jeff Leger
12    Maurice Ribble
13    Krzysztof Kosinski
14    Craig Donner
15    Tobias Hector
16    Jan-Harald Fredriksen
17    Nigel Williams
18
19Contact
20
21    Jeff Leger (jleger 'at' qti.qualcomm.com)
22
23Status
24
25    Complete
26
27Version
28
29    Last Modified Date: February 27, 2017
30    Revision: 3
31
32Number
33
34    OpenGL ES Extension #275
35
36Dependencies
37
38    This requires support of EXT_multisample_render_to_texture or an equivalent
39    extension.
40
41    This interacts with OVR_multiview_multisampled_render_to_texture.
42
43Overview
44
45    The <attachment> parameters for FramebufferTexture2DMultisampleEXT is no
46    longer required to be COLOR_ATTACHMENT0.  The attachment parameter now
47    matches what is allowed in FramebufferTexture2D.  This means values like
48    GL_COLOR_ATTACHMENTi, GL_DEPTH_ATTACHMENT, GL_STENCIL_ATTACHMENT, or
49    GL_DEPTH_STENCIL_ATTACHMENT may be used.
50    After the application has rendered into the mutisampled buffer, the application
51    should be careful to not trigger an implicit flush by performing a client side
52    read of the buffer (readpixels, copyteximage, blitframebuffer, etc) before any
53    subsequent rendering which uses the contents of the buffer. This may cause the
54    attachment to be downsampled before the following draw, which would potentially
55    cause corruption.
56
57IP Status
58
59    No known IP claims.
60
61New Procedures and Functions
62
63    None
64
65New Tokens
66
67    None
68
69Additions to Section 4.4.3 of the OpenGL ES 2.0 Specification
70(Renderbuffer Objects)
71
72    Remove the following wording describing FramebufferTexture2DMultisampleEXT:
73
74        "and have the same restrictions.  attachment must be COLOR_ATTACHMENT0."
75
76    In the description of FramebufferTexture2DMultisampleEXT, after the sentence
77    "After such a resolve, the contents of the multisample buffer become undefined.",
78    add the following sentence:
79
80        "If texture is a depth or stencil texture, the contents of the multisample
81        buffer is discarded rather than resolved - equivalent to the application
82        calling InvalidateFramebuffer for this attachment."
83
84Errors
85
86    Remove this error:
87    The error INVALID_ENUM is generated if FramebufferTexture2DMultisampleEXT
88    is called with an <attachment> that is not COLOR_ATTACHMENT0.
89
90Issues
91
92    1. How should downsampling depth/stencil surfaces be handled?
93
94    Proposed: Ideally, when using this extension, depth/stencil attachments should
95    always be discarded/invalidated by the application *before* the rendering is
96    submitted.  If the application fails to do so, the implementation is not required
97    to preserve the contents of those attachments.  A depth/stencil resolve is
98    equivalent to InvalidateFramebuffer for those attachments.
99
100    Revision History
101
102    Revision 1, 2016/9/15
103      - First draft of extension
104    Revision 2, 2016/12/2
105      - Added interaction with OVR_multiview_multisampled_render_to_texture
106      - Added issue for downsampling depth
107    Revision 3, 2017/02/27
108      - Final version. A depth/stencil resolve is equivalent
109        to InvalidateFramebuffer
110