| 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) |