EXT_multisampled_render_to_texture
Name
EXT_multisampled_render_to_texture
Name Strings
GL_EXT_multisampled_render_to_texture
Contributors
Georg Kolling, Imagination Technologies (georg.kolling 'at' imgtec.com)
Ben Bowman, Imagination Technologies (benji.bowman 'at' imgtec.com)
Contact
Jan-Harald Fredriksen (jan-harald.fredriksen 'at' arm.com)
Status
Complete
Version
Last Modified Date: June 28, 2016
Revision: 7
Number
OpenGL ES Extension #106
Dependencies
OpenGL ES 2.0 or OES_framebuffer_object are required. This
extension is written against the OpenGL ES 2.0 Specification.
This extension interacts with OpenGL ES 3.0 and later versions.
Overview
This extension introduces functionality to perform multisampled
rendering to a color renderable texture, without requiring an
explicit resolve of multisample data.
Some GPU architectures - such as tile-based renderers - are
capable of performing multisampled rendering by storing
multisample data in internal high-speed memory and downsampling the
data when writing out to external memory after rendering has
finished. Since per-sample data is never written out to external
memory, this approach saves bandwidth and storage space. In this
case multisample data gets discarded, however this is acceptable
in most cases.
The extension provides a new command, FramebufferTexture2DMultisampleEXT,
which attaches a texture level to a framebuffer and enables
multisampled rendering to that texture level.
When the texture level is flushed or used as a source or destination
for any operation other than drawing to it, an implicit resolve of
multisampled color data may be performed. After such a resolve, the
multisampled color data is discarded.
In order to allow the use of multisampled depth and stencil buffers
when performing multisampled rendering to a texture, the extension
also adds the command RenderbufferStorageMultisampleEXT.
IP Status
No known IP claims.
New Procedures and Functions
void RenderbufferStorageMultisampleEXT(
enum target, sizei samples,
enum internalformat,
sizei width, sizei height);
void FramebufferTexture2DMultisampleEXT(
enum target, enum attachment,
enum textarget, uint texture,
int level, sizei samples);
New Tokens
Accepted by the <pname> parameter of GetRenderbufferParameteriv:
RENDERBUFFER_SAMPLES_EXT 0x8CAB
Returned by CheckFramebufferStatus:
FRAMEBUFFER_INCOMPLETE_MULTISAMPLE_EXT 0x8D56
Accepted by the <pname> parameter of GetBooleanv, GetIntegerv,
and GetFloatv:
MAX_SAMPLES_EXT 0x8D57
Accepted by the <pname> parameter of GetFramebufferAttachmentParameteriv:
FRAMEBUFFER_ATTACHMENT_TEXTURE_SAMPLES_EXT 0x8D6C
Additions to Section 4.4.3 of the OpenGL ES 2.0 Specification (Renderbuffer Objects)
Replace the paragraph describing the command RenderbufferStorage
with the following:
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.
internalformat must be one of the color-renderable, depth-renderable,
or stencil-renderable formats described in table 4.5. width and height
are the dimensions in pixels of the renderbuffer. If either width or
height is greater than the value of MAX_RENDERBUFFER_SIZE, or if
samples is greater than the value of MAX_SAMPLES_EXT, then the error
INVALID_VALUE is generated. If OpenGL ES 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 is set to width, RENDERBUFFER_HEIGHT is set to
height, and RENDERBUFFER_INTERNAL_FORMAT 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.
When the renderbuffer is used as a source or destination for any
operation, when the attachment is flushed, or when the attachment is
broken, an implicit resolve of the multisample data may be performed.
After such a resolve, the contents of the multisample buffer become
undefined. The operations that may cause an implicit resolve are the
same as for FramebufferTexture2DMultisampleEXT.
An OpenGL ES implementation may vary its allocation of internal
component resolution based on any RenderbufferStorageMultisampleEXT
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.
The command
void RenderbufferStorage( enum target, enum internalformat,
sizei width, sizei height );
is equivalent to calling RenderbufferStorageMultisampleEXT with
samples equal to zero.
Add the following after the paragraph describing FramebufferTexture2D:
The command
void FramebufferTexture2DMultisampleEXT( enum target,
enum attachment, enum textarget, uint texture,
int level, sizei samples );
enables multisampled rendering into the images of a texture object.
target, textarget, texture, and level correspond to the same
parameters for FramebufferTexture2D and have the same restrictions.
attachment must be COLOR_ATTACHMENT0. If samples is greater than the
value of MAX_SAMPLES_EXT, then the error INVALID_VALUE is generated.
An INVALID_OPERATION error is generated if samples is greater than
the maximum number of samples supported for target and its
internalformat. If samples is zero, then TEXTURE_SAMPLES_EXT is set
to zero, and FramebufferTexture2DMultisampleEXT behaves like
FramebufferTexture2D.
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 image is implementation-dependent. However, the
resulting value for TEXTURE_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.
The implementation allocates an implicit multisample buffer with
TEXTURE_SAMPLES_EXT samples and the same internalformat, width, and
height as the specified texture level. This buffer is used as the
target for rendering instead of the specified texture level. The
buffer is associated with the attachment and gets deleted after the
attachment is broken.
While the implicit multisample buffer is attached, color sample values
are automatically resolved to a single color in the texture level each
time a pixel is updated. This has the effect of making the antialiasing
appear to be automatic at the application level.
When the texture level is used as a source or destination for any
operation, the attachment is flushed, or when the attachment is broken,
the GL implementation may discard the contents of the implicit multisample
buffer. If the contents are discarded, the subsequent operations on the
multisample buffer will behave as if all samples within a pixel have the
value most recently written to the color buffer for that pixel.
The operations which may cause the contents of the implicit multisample
buffer to be discarded include:
- Drawing with the texture bound to an active texture unit
- ReadPixels or CopyTex[Sub]Image* while the texture is
attached to the framebuffer
- CopyTex[Sub]Image*, Tex[Sub]Image*,
CompressedTex[Sub]Image* with the specified level as
destination
- GenerateMipmap
- Flush or Finish while the texture is attached to the
framebuffer
- BindFramebuffer while the texture is attached to the currently
bound framebuffer.
Additions to section 4.4.5 of the OpenGL ES 2.0 Specification (Framebuffer Completeness)
Add the following bullet point to the list of conditions for
Framebuffer Attachment Completeness:
* The number of texture samples (as set by FramebufferTexture2DMultisampleEXT)
must be less than or equal to the maximum number of samples supported for
the internal format of _image_.
Add the following bullet point after
* All attached images have the same width and height.
FRAMEBUFFER_INCOMPLETE_DIMENSIONS
on page 116:
* The value of RENDERBUFFER_SAMPLES_EXT is the same for all
attached renderbuffers; the value of TEXTURE_SAMPLES_EXT
is the same for all texture attachments; and, if the attached
images are a mix of renderbuffers and textures, the value of
RENDERBUFFER_SAMPLES_EXT matches the value of TEXTURE_-
SAMPLES_EXT.
FRAMEBUFFER_INCOMPLETE_MULTISAMPLE
Dependencies on GL and ES profiles, versions, and other extensions
Interactions with OpenGL ES 3.0 and later versions:
If OpenGL ES 3.0 or later is not supported, ignore all references
to DRAW_FRAMEBUFFER and READ_FRAMEBUFFER.
The OpenGL ES 3.1 specification states that:
"An INVALID_OPERATION error is generated by CopyTexSubImage3D,
CopyTexImage2D, or CopyTexSubImage2D if
...
* the value of READ_FRAMEBUFFER_BINDING is non-zero, and
- the read buffer selects an attachment that has no image attached,
or
- the value of SAMPLE_BUFFERS for the read framebuffer is one."
Similarly, for ReadPixels:
"An INVALID_OPERATION error is generated if the value of READ_-
FRAMEBUFFER_BINDING (see section 9) is non-zero, the read framebuffer
is framebuffer complete, and the value of SAMPLE_BUFFERS for the read
framebuffer is one."
These errors do not apply to textures and renderbuffers that have
associated multisample data specified by the mechanisms described in
this extension, i.e., the above operations are allowed even when
SAMPLE_BUFFERS is non-zero for renderbuffers created via Renderbuffer-
StorageMultisampleEXT or textures attached via FramebufferTexture2D-
MultisampleEXT.
Also, FBOs cannot combine attachments that have associated multisample
data specified by the mechanisms described in this extension with
attachments allocated using the core OpenGL ES 3.1 mechanisms, such as
TexStorage2DMultisample. Add to section 9.4.2 "Whole Framebuffer
Completeness":
"* If the value of RENDERBUFFER_SAMPLES is non-zero, all or none of the
attached renderbuffers have been allocated using RenderbufferStorage-
MultisampleEXT; if the value of TEXTURES_SAMPLES is non-zero, all or
none of the attached textures have been attached using Framebuffer-
Texture2DMultisampleEXT.
{ GL_FRAMEBUFFER_INCOMPLETE_MULTISAMPLE_EXT }"
Add to the description of FramebufferTexture2DMultisampleEXT (first
paragraph):
"The maximum number of samples supported can be determined by calling
GetInternalformativ with a pname of SAMPLES."
Errors
The error OUT_OF_MEMORY is generated when
RenderbufferStorageMultisampleEXT cannot create storage of the
specified size.
If RenderbufferStorageMultisampleEXT is called with a value of
<samples> that is greater than MAX_SAMPLES_EXT, then the error
INVALID_VALUE is generated.
The error INVALID_ENUM is generated if FramebufferTexture2DMultisampleEXT
is called with a <target> that is not FRAMEBUFFER, DRAW_FRAMEBUFFER, or
READ_FRAMEBUFFER.
The error INVALID_ENUM is generated if FramebufferTexture2DMultisampleEXT
is called with an <attachment> that is not COLOR_ATTACHMENT0.
The error INVALID_ENUM is generated if FramebufferTexture2DMultisampleEXT
is called with a <textarget> that is not TEXTURE_2D,
TEXTURE_CUBE_MAP_POSITIVE_X, TEXTURE_CUBE_MAP_POSITIVE_Y,
TEXTURE_CUBE_MAP_POSITIVE_Z, TEXTURE_CUBE_MAP_NEGATIVE_X,
TEXTURE_CUBE_MAP_NEGATIVE_Y, or TEXTURE_CUBE_MAP_NEGATIVE_Z.
The error INVALID_OPERATION is generated if FramebufferTexture2DMultisampleEXT
is called with <samples> greater than the maximum number of samples supported
for <target> and its internalformat.
New State
Changes to table 6.22, p. 154 (Renderbuffer State)
Initial
Get Value Type Get Command Value Description Sec.
--------- ---- ---------------- ------- ------------ -----
RENDERBUFFER_SAMPLES_EXT Z+ GetRenderbuffer- 0 Renderbuffer 4.4.3
Parameteriv samples
Changes to table 6.23, p. 155 (Framebuffer State)
Initial
Get Value Type Get Command Value Description Sec.
--------- ------ --------------------- ------- --------------- ----
TEXTURE_SAMPLES_EXT n * Z+ GetFramebuffer- 0 Framebuffer 4.4
AttachmentParameteriv texture samples
New Implementation Dependent State
Changes to table 6.17, p. 149 (Implementation Dependent Values)
Minimum
Get Value Type Get Command Value Description Sec.
--------- ---- ----------- ------- ----------- ----
MAX_SAMPLES_EXT Z+ GetIntegerv 2 Max. # of 4.4
samples.
Sample Code
GLsizei width = ...;
GLsizei height = ...;
GLint samples;
glGetIntegerv(GL_MAX_SAMPLES_EXT, &samples);
/* Create multisampled depth renderbuffer */
GLuint depthbuffer;
glGenRenderbuffers(1, &depthbuffer);
glBindRenderbuffer(GL_RENDERBUFFER, depthbuffer);
glRenderbufferStorageMultisampleEXT(GL_RENDERBUFFER, samples,
GL_DEPTH_COMPONENT16, width, height);
glBindRenderbuffer(GL_RENDERBUFFER, 0);
/* Create RGBA texture with single mipmap level */
GLuint texture;
glGenTextures(1, &texture);
glBindTexture(GL_TEXTURE_2D, texture);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, width, height, 0, GL_RGBA,
GL_UNSIGNED_SHORT_4_4_4_4, NULL);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
glBindTexture(GL_TEXTURE_2D, 0);
/* Create framebuffer object, attach texture and depth renderbuffer */
GLuint framebuffer;
glGenFramebuffers(1, &framebuffer);
glBindFramebuffer(GL_FRAMEBUFFER, framebuffer);
glFramebufferRenderbuffer(GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT,
GL_RENDERBUFFER, depthbuffer);
glFramebufferTexture2DMultisampleEXT(GL_FRAMEBUFFER,
GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, texture, 0, samples);
/* handle unsupported cases */
if (glCheckFramebufferStatus(GL_FRAMEBUFFER) !=
GL_FRAMEBUFFER_COMPLETE)
{
...
}
/* draw to the texture */
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
...
/* Discard the depth renderbuffer contents if possible */
if (extension_supported("GL_EXT_discard_framebuffer"))
{
GLenum discard_attachments[] = { GL_DEPTH_ATTACHMENT };
glDiscardFramebufferEXT(GL_FRAMEBUFFER, 1,
discard_attachments);
}
/* Draw to the default framebuffer using the antialiased texture */
/* Color data is implicitly resolved before the texture gets used */
glBindFramebuffer(GL_FRAMEBUFFER, 0);
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT |
GL_STENCIL_BUFFER_BIT);
glBindTexture(GL_TEXTURE_2D, texture);
...
Conformance Tests
No conformance test has been defined yet
Issues
1. Which operations can cause a resolve?
The IMG_multisampled_render_to_texture includes this list:
- Drawing with the texture bound to an active texture unit
- ReadPixels or CopyTex[Sub]Image* while the texture is
attached to the framebuffer
- CopyTex[Sub]Image*, Tex[Sub]Image*,
CompressedTex[Sub]Image* with the specified level as
destination
- GenerateMipmap
An implementation may also want to resolve the multisample buffer on
operations such as:
- Flush and Finish when a multisampled texture or render-
buffer is attached to the current framebuffer.
- BindFramebuffer when the currently bound framebuffer has a
multisampled texture or renderbuffer attachment.
RESOLVED: Allow, but don't require, all of the above to cause a resolve.
2. Should there be a way for applications to query if the multisample
buffer has been resolved - and therefore is undefined?
This may be useful if the operations that cause the multisample
buffer to be resolved is allowed to vary between implementations.
RESOLVED: No, for two reasons: 1) This extension aims to be backwards
compatible with the IMG_multisampled_render_to_texture extension, which
did not include such a query, and 2) Given the resolution of issue 3 this
is not very useful as the application cannot control whether multisample
information is preserved or not.
3. Should there be a way for applications to preserve the multisample
buffer after a resolve?
This would be similar in spirit to the EGL_BUFFER_PRESERVED options in
EGL 1.4. Applications could - at a performance and memory cost - choose
to make the multisample buffer _not_ undefined after a resolve.
RESOLVED: No. The purpose of this extension is to support multisampled
rendering in a lightway manner. Preserving the multisample buffer goes
against this intent.
4. Should TEXTURE_SAMPLES_EXT rather be called FRAMEBUFFER_ATTACHMENT_-
TEXTURE_SAMPLES_EXT?
TEXTURE_SAMPLES is used in desktop GL to refer to the number of samples in
a multisampled texture. This extension does not introduce multisampled
textures, but rather allows multisampled rendering to non-multisampled
textures. For the purposes of this extension, the texture sample count
should be considered framebuffer attachment state rather than texture
state, thus FRAMEBUFFER_ATTACHMENT_TEXTURE_SAMPLES_EXT is a more
appropriate name.
RESOLVED: Use FRAMEBUFFER_ATTACHMENT_TEXTURE_SAMPLES_EXT.
5. Is CopyTex[Sub]Image2D allowed if the texture has implicit multisamples?
And is ReadPixels allowed if the texture or renderbuffer has implicit
multisamples?
RESOLVED: Yes.
This extension is written against OpenGL ES 2.0, which did not have multi-
sampled textures or renderbuffers. With this extension, an application can
use FramebufferTexture2DMultisampleEXT to associate multisample data with
an existing texture, or use RenderbufferStorageMultisampleEXT to allocate
a renderbuffer with associated multisample data. This does not add any
restrictions on the usage of such texture and renderbuffers beyond what
ES 2.0 defines, but any operations (such as CopyTexImage2D and ReadPixels)
may cause the multisample data to be resolved and lost. That is, the intent
of this extension is that implementations do not have to allocate multi-
sample data in system memory, but can store these data in internal high-
speed memory only, and implicitly downsample whenever those data need to
by visible is system memory.
6. What are the interactions with OpenGL ES 3.0 and later?
RESOLVED.
If this extension is supported in OpenGL ES 3.0 or later then
DRAW_FRAMEBUFFER and READ_FRAMEBUFFER are valid values for the <target>
parameter to FramebufferTexture2DMultisampleEXT. Since this parameter is
defined to correspond to - and have the same restrictions as - the <target>
parameter to FramebufferTexture2D, this also implies that FRAMEBUFFER is
equivalent to DRAW_FRAMEBUFFER for this command.
Note that this behavior was first described in revision 6 of this extension,
and was undefined in earlier revisions of this spec. Drivers written against
these earlier versions may generate errors if DRAW_FRAMEBUFFER and READ_-
FRAMEBUFFER are used for the <target> parameter to
FramebufferTexture2DMultisampleEXT.
7. What is the language about automatic resolves about?
RESOLVED.
The GL specification is written as if the multisample buffer is a separate
buffer from the color buffer. This is not quite how modern GPUs work, but
was true for some historic systems. This extension builds on the existing
specification wording and uses the existing terminology.
In the Multisampling section, the GL specification says that:
"The color sample values are resolved to a single, displayable color. For
window system-provided framebuffers, this occurs each time a pixel is
updated, so the antialiasing appears to be automatic at the application
level."
In practice, most GPUs will only resolve the color sample values once
(e.g. at the end of a frame), but from the application's point of view that
does not make any observable difference.
This extension inherits this behavor. The application does not (and cannot)
do anything to resolve the multisamples - this is always done automatically.
Further, this extension does not change any of the semantics around how
resources are synchronized. E.g. an attachment will always see the most
recent change made to the attached texture, whether that was done by
rendering into an attachment or by a texture update operation.
This implies that the multisample buffer and the color buffer are always
"in sync". The only behavior that is implementation-defined in this
extension is when the implicit multisample buffer is discarded. After the
operations that may (or may not) cause such a discard, an application can
observe either 1 or n distinct values in the multisample buffer depending
on whether the discard happened or not. As described in Issue 2, there's
no way for the application to query whether the discard happened.
Revision History
Revision 8, 2018/04/11
- Clarified wording around implicit resolves, and added Issue 7.
Revision 7, 2016/06/28
- Clarified that it is an error to call FramebufferTexture2DMultisampleEXT
with a sample count higher than what is supported for the given internalformat.
- Added Framebuffer Attachment Completeness rule.
Revision 6, 2016/04/06
- Updating interactions with OpenGL ES 3.0 and added the related
Issue 6.
Revision 5, 2015/01/05
- Clarified that multisampled data is also implictly resolved for render-
buffers.
- Clarified interactions with multisampled textures in OpenGL ES 3.x.
- Added interaction with OpenGL ES 3.1.
- Added Issue 5.
Revision 4, 2012/07/04
- Fixing bug where enum names clashed with enums in the GL extension
EXT_framebuffer_multisample, but with different values defined.
This causes obvious problems. As a consequence, values have been
updated for the following enums:
* RENDERBUFFER_SAMPLES_EXT
* FRAMEBUFFER_INCOMPLETE_MULTISAMPLE_EXT
* MAX_SAMPLES_EXT
The values now match the values in EXT_framebuffer_multisample.
Revision 3, 2011/11/21
- Fixing a bug in Sample Code where GL_DEPTH_EXT was used instead of
GL_DEPTH_ATTACHMENT.
Revision 2, 2011/10/30
- Renaming to EXT extension. Resolving issues 1-4.
Revision 1, 2011/10/02
- First draft of XXX extension (based on IMG extension with the same name)