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 parameter of GetRenderbufferParameteriv: RENDERBUFFER_SAMPLES_EXT 0x8CAB Returned by CheckFramebufferStatus: FRAMEBUFFER_INCOMPLETE_MULTISAMPLE_EXT 0x8D56 Accepted by the parameter of GetBooleanv, GetIntegerv, and GetFloatv: MAX_SAMPLES_EXT 0x8D57 Accepted by the 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 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 that is not FRAMEBUFFER, DRAW_FRAMEBUFFER, or READ_FRAMEBUFFER. The error INVALID_ENUM is generated if FramebufferTexture2DMultisampleEXT is called with an that is not COLOR_ATTACHMENT0. The error INVALID_ENUM is generated if FramebufferTexture2DMultisampleEXT is called with a 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 greater than the maximum number of samples supported for 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 parameter to FramebufferTexture2DMultisampleEXT. Since this parameter is defined to correspond to - and have the same restrictions as - the 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 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)