| Name |
| |
| EXT_YUV_target |
| |
| Name Strings |
| |
| GL_EXT_YUV_target |
| |
| Contributors |
| |
| Amit Bansal |
| Arshad Bebal |
| Jeff Leger |
| Jing Zhou |
| Maurice Ribble |
| Prabindh Sundareson |
| Jan-Harald Fredriksen |
| Daniel Koch |
| Jamie Gennis |
| Mark Callow |
| Pat Brown |
| Andrew Garrard |
| Etay Meiri |
| Weifeng Zhang |
| |
| Contacts |
| |
| Jeff Leger <jleger@qti.qualcomm.com> |
| |
| Status |
| |
| Complete. |
| |
| Version |
| |
| April 6, 2018 (version 17) |
| |
| Number |
| |
| OpenGL ES Extension #222 |
| |
| Dependencies |
| |
| Requires OpenGL ES 3.0 and ESSL 3.0. |
| Requires EGL 1.4 and following EGL extension: |
| |
| EGL_KHR_image_base |
| OES_EGL_image_external |
| |
| This extension is written based on the wording of the OpenGL ES 3.0 |
| Specification and OpenGL ES Shading Language 3.0. |
| |
| This extension interacts with OpenGL ES 3.1. See issue 1 and 13 for |
| more details. |
| |
| This extension interacts with OES_tessellation_shader & |
| OES_geometry shader see first issue for more details. |
| |
| This extension borrows texture function names from the |
| OES_EGL_image_external_essl3. This extension is compatible with |
| OES_EGL_image_external_essl3 and can coexist but does not require it. |
| |
| This extension interacts with EXT_shader_framebuffer_fetch. see |
| issue 7 for more details. |
| |
| Overview |
| |
| This extension adds support for three new YUV related items: first |
| rendering to YUV images, second sampling from YUV images while keeping the |
| data in YUV space, third it defines a new built in function that does |
| conversion from RGB to YUV with controls to choose ITU-R BT.601-7, |
| ITU-R BT.601-7 Full range (JFIF images), or ITU-R BT.709-5 standard. |
| |
| This new functionality is layered on top of the OES_EGL_image_external |
| extension. |
| |
| To perform the YUV rendering capability in this extension an application |
| will attach a texture to the framebuffer object as the color attachment. |
| If the texture has a target type of TEXTURE_EXTERNAL_OES with YUV color |
| format then the GL driver can use this framebuffer object as the render |
| target, TEXTURE_EXTERNAL_OES target with RGB color format are not allowed |
| with this extension. |
| |
| New Types & Keywords |
| |
| A new OpenGL GLSL extension flag is added: |
| |
| #extension GL_EXT_YUV_target |
| |
| When the above GLSL extension is specified, one new sampler type |
| will be available for sampling the 2D texture: |
| |
| __samplerExternal2DY2YEXT |
| |
| The "__samplerExternal2DY2YEXT" is used to sample a YUV texture image and |
| output color value without any color conversion. |
| |
| Whenever a YUV sample is output from the sampler, the format of the YUV |
| will be as if YUV 4:4:4 format is output. This also means that the Y |
| sample maps to component R, the U sample maps to component G, the V sample |
| maps to component B, and the component A will be 1.0f. |
| |
| The RGB sample output will be the same as in OpenGL ES specification. |
| |
| Here is one example: |
| |
| uniform __samplerExternal2DY2YEXT u_sTexture; |
| |
| When the above GLSL extension is specified, one new additional type will be |
| available to specify color space standard formula for yuv to rgb transformation. |
| |
| yuvCscStandardEXT |
| |
| The value of new type can be specified using one of three new keywords |
| itu_601, itu_601_full_range and itu_709. |
| |
| For example: |
| |
| yuvCscStandardEXT conv_standard = itu_601; |
| yuvCscStandardEXT conv_standard = itu_601_full_range; |
| yuvCscStandardEXT conv_standard = itu_709; |
| |
| Keyword itu_601 means color conversion is required using the formula |
| specified in the ITU-R BT.601. Similarly keyword itu_601_full_range |
| means conversion is done using ITU BT.601 full range formula as specified |
| in JFIF standard while keyword itu_709 specify ITU-R BT.709 standard. Note |
| that new yuvCscStandardEXT type can't be use for any other purpose apart |
| from specifying color standard value to newly introduced color conversion |
| built in functions mentioned below. |
| |
| New Built-in function |
| |
| When the new GLSL extension is specified, two new built in functions |
| will be available for rgb to yuv or yuv to rgb color space conversion. |
| |
| vec3 rgb_2_yuv(vec3 color, yuvCscStandardEXT conv_standard); |
| |
| The function rgb_2_yuv will apply rgb to yuv color conversion |
| transformation on "color" value using the formula specified as per new type |
| yuvCscStandardEXT variable. The first input parameter supposed to specify |
| rgb value using x, y & z channels of a vec3 variable, correspondingly |
| return value of this function will have transformed y, u and v value in its |
| x, y and z channel. Precision of the input color will define the precision |
| used for color space conversion and for output yuv color value. |
| |
| vec3 yuv_2_rgb (vec3 color, yuvCscStandardEXT conv_standard); |
| |
| The function yuv_2_rgb will apply yuv to rgb color conversion |
| transformation on "color" value using the formula specified as per new type |
| yuvCscStandardEXT variable. The first input parameter supposed to specify |
| yuv value using x, y & z channels of a vec3 variable, correspondingly |
| return value of this function will have transformed r, g and b value in its |
| x, y and z channel. Precision of the input color will define the precision |
| used for color space conversion and for output yuv color value. |
| |
| New layout qualifier |
| |
| A shader which produces yuv format color output must qualify the fragment |
| shader output variable with new yuv layout qualifier as described below. |
| |
| layout (yuv) out vec4 color; |
| |
| The new yuv layout qualifier can't be combined with any other layout qualifier, |
| can only be used with fragment shader outputs and would be available only when |
| the new GLSL extension is specified. Additionally if the shader qualifies |
| fragment shader output with the new yuv qualifier and write depth or multiple |
| color output, it would cause compilation failure. |
| |
| New Tokens |
| |
| Returned in the <type> parameter of GetActiveUniform: |
| |
| SAMPLER_EXTERNAL_2D_Y2Y_EXT 0x8BE7 |
| |
| Reuse tokens as in extension "OES_EGL_image_external." |
| |
| Accepted as a target in the <target> parameter of BindTexture, |
| EGLImageTargetTexture2DOES, and FramebufferTexture2D: |
| |
| TEXTURE_EXTERNAL_OES 0x8D65 |
| |
| Accepted as <value> in GetIntegerv() and GetFloatv() queries: |
| |
| TEXTURE_BINDING_EXTERNAL_OES 0x8D67 |
| |
| Accepted as <value> in GetTexParameter*() queries: |
| |
| REQUIRED_TEXTURE_IMAGE_UNITS_OES 0x8D68 |
| |
| Addition to Chapter 3 of the OpenGL ES 3.0 specification |
| |
| Add a new section: "3.8.18 External Textures," which follows section |
| "3.8.17 Shader Exponent Texture Color Conversion." The wording will |
| be the same as in extension "OES_EGL_image_external." |
| |
| Changes to Section 4.4.2 "Attaching Images to Framebuffer Objects" |
| |
| At the end of subsection "Attaching Texture Images to a Framebuffer," add |
| the following paragraphs: |
| |
| from |
| "If texture is not zero, then texture must either name an existing |
| two dimensional texture object and textarget must be TEXTURE_2D or |
| texture must name an existing cube map...." |
| |
| to |
| "If texture is not zero, then texture must either name an existing |
| two dimensional texture object and textarget must be TEXTURE_2D or |
| TEXTURE_EXTERNAL_OES or texture must name an existing cube map...." |
| |
| from |
| "If textarget is TEXTURE_2D, level must be greater than or equal to |
| zero and no larger than log2 of the value of MAX_TEXTURE_SIZE. |
| Otherwise, an INVALID_VALUE error is generated. |
| The command..." |
| to |
| "If textarget is TEXTURE_2D, level must be greater than or equal to |
| zero and no larger than log2 of the value of MAX_TEXTURE_SIZE. |
| Otherwise, an INVALID_VALUE error is generated. If textarget is |
| TEXTURE_EXTERNAL_OES and attachment is other than COLOR_ATTACHMENT0, |
| an INVALID_OPERATION error is generated. |
| The command..." |
| |
| Add an additional sentence at the end of above paragraph: |
| |
| "Since TEXTURE_EXTERNAL_OES texture target can only be specified |
| using an EGLImage, yuv formats can be rendered by attaching |
| TEXTURE_EXTERNAL_OES textarget via EGLImage." |
| |
| Changes to Section 4.2.3 "Clearing the Buffers" |
| from |
| "Unsigned normalized fixed-point RGBA color buffers are cleared to color |
| values derived by clamping each component of the clear color to the range |
| [0; 1], then converting the (possibly sRGB converted and/or dithered) color |
| to fixed-point using equations 2.3 or 2.4, respectively. The result of |
| clearing integer color buffers with Clear is undefined." |
| |
| to |
| "Unsigned normalized fixed-point RGBA color buffers are cleared to color |
| values derived by clamping each component of the clear color to the range |
| [0; 1], then converting the (possibly sRGB converted and/or dithered) color |
| to fixed-point using equations 2.3 or 2.4, respectively. When clearing YUV |
| Color Buffers, clear color should be defined in yuv color space and so |
| floating point r, g, and b value will be mapped to corresponding y, u and v |
| value and alpha channel will be ignored. The result of clearing integer |
| color buffers with Clear is undefined." |
| |
| Changes to Section 4.4.3 "Fine Control of Buffer Updates" |
| |
| from |
| "ColorMask is used to mask the writing of R, G, B and A values to all active |
| draw buffers. r, g, b, and a indicate whether R, G, B, or A values, respectively, |
| are written or not (a value of TRUE means that the corresponding value is written). |
| In the initial state, all color values are enabled for writing for all draw |
| buffers..." |
| |
| to |
| "ColorMask is used to mask the writing of R, G, B and A values to all active |
| draw buffers. r, g, b, and a indicate whether R, G, B, or A values, respectively, |
| are written or not (a value of TRUE means that the corresponding value is written) |
| except when the color buffer is in YUV color space, in that case setting any one |
| of the r, g, b, and a values as false would generate draw time INVALID_OPERATION error. |
| In the initial state, all color values are enabled for writing for all draw |
| buffers..." |
| |
| Changes to Section 4.1.7 "Blending" |
| |
| from |
| "Blending applies only if the color buffer has a fixed-point format. If the color |
| buffer has an integer format, proceed to the next operation." |
| |
| to |
| "Blending applies only if the color buffer has a fixed-point format and non YUV space |
| format color buffer. If the color buffer has an integer, proceed to the next |
| operation. If color buffer format is YUV color space, it will generate |
| draw time INVALID_OPERATION error." |
| |
| Changes to 4.2.1 "Selecting Buffers for Writing" |
| from |
| "If some, but not all user-defined output variables are written, the values of |
| fragment colors corresponding to unwritten variables are similarly undefined. |
| The order of writes..." |
| |
| to |
| "If some, but not all user-defined output variables are written, the values of |
| fragment colors corresponding to unwritten variables are similarly undefined unless |
| any of the fragment output is qualified with yuv format qualifier. In later case |
| compiler would restrict usage of yuv format qualifier up to a single color output. |
| The order of writes..." |
| |
| Changes to section 4.4.4 ("Framebuffer Completeness") |
| from |
| "An internal format is color-renderable if it is one of the formats from table |
| 3.12 noted as color-renderable or if it is unsized format RGBA or RGB. No |
| other formats," |
| |
| to |
| "An internal format is color-renderable if it is one of the formats from table |
| 3.12 noted as color-renderable or if it is unsized format RGBA or RGB or if it is |
| YUV color space format supported by implementation. No other formats," |
| |
| Changes to section 3.7 ("Keywords") of the OpenGL ES Shading Language |
| specification |
| |
| - Add to the list of keywords: |
| |
| __samplerExternal2DY2YEXT |
| yuvCscStandardExt |
| itu_601 |
| itu_601_full_range |
| itu_709 |
| |
| |
| |
| Changes to section 4.1 ("Basic Types") of the OpenGL ES Shading Language |
| specification |
| - Add to the list of Transparent types: |
| "yuvCscStandardExt a value type to specify color space standard formula for |
| transformation between yuv and rgb, taking values of itu_601, itu_601_full_range, |
| itu_709" |
| |
| - Add to the list of Floating Point Sampler Types (opaque): |
| |
| "__samplerExternal2DY2YEXT a handle for accessing an external 2D texture |
| whose underneath format is YUV" |
| |
| - Add a paragraph at the end of the section: |
| |
| "The __samplerExternal2DY2YEXT and yuvCscStandardExt types are optional and must |
| be enabled by |
| |
| #extension GL_EXT_YUV_target : enable |
| |
| No type constructor or type conversion is allowed on yuvCscStandardExt. A value |
| of itu_601, itu_601_full_range, itu_709, or a variable typed as yuvCscStandardExt |
| can be used as an argument to user-defined functions and the built-in functions yuv_2_rgb and |
| rgb_2_yuv. Other than the assignment operator, any other operations on this type |
| of values or variables will be treated as a compilation error." |
| |
| Changes to section 4.5.4 ("Default Precision Qualifiers") of the OpenGL ES |
| Shading Language specification |
| |
| - Add to the list of "vertex language has the following predeclared |
| globally scoped default precision statements:" |
| |
| "precision lowp __samplerExternal2DY2YEXT;" |
| |
| - Add to the list of "fragment language has the following predeclared |
| globally scoped default precision statements:" |
| |
| "precision lowp __samplerExternal2DY2YEXT;" |
| |
| Changes to section 8.8 ("Texture Lookup Functions") of the OpenGL ES Shading |
| Language specification |
| |
| - Add to the table the following sampler functions: |
| |
| "highp ivec2 textureSize(__samplerExternal2DY2YEXT sampler, int lod) |
| vec4 texture(__samplerExternal2DY2YEXT sampler, vec2 P [, float bias] ) |
| vec4 textureProj(__samplerExternal2DY2YEXT sampler, vec3 P [, float bias] ) |
| vec4 textureProj(__samplerExternal2DY2YEXT sampler, vec4 P [, float bias]) |
| vec4 texelFetch(__samplerExternal2DY2YEXT sampler, ivec2 P, int lod)" |
| |
| Add a new section 8.10 "Conversion Functions between YUV and RGB" |
| |
| - Add a new table containing 2 entries: |
| |
| vec3 rgb_2_yuv(vec3 color, yuvCscStandardEXT conv_standard); |
| apply rgb to yuv color conversion transformation on "color" value |
| using the formula specified by conv_standard. |
| |
| vec3 yuv_2_rgb(vec3 color, yuvCscStandardEXT conv_standard); |
| apply yuv to rgb color conversion transformation on "color" value |
| using the formula specified by conv_standard. |
| |
| Compatibility with OpenGL ES 3.1 and ESSL 3.10 |
| |
| This extension is expected to work without modification with OpenGL ES 3.1 |
| and ESSL 3.10. Some further clarification in issue 1, 9 and 13. |
| |
| Issues |
| |
| 1. Do we want to explicitly disallow "__samplerExternal2DY2YEXT" from use in other |
| shader apart from fragment shader e.g. vertex, compute, geometry and tessellation |
| shaders? |
| |
| RESOLVED: No, modern unified shader hardware supports YUV texture sampling in all |
| of the shader stages, we should keep this enable irrespective of shader stage. |
| |
| 2. What happens if the input source isn't in the expected color space for built in |
| functions or lets say there is cross conversion between different color space |
| conversion standards e.g. 601 RGB to 709 YUV etc or yuv layout qualified color |
| output is actually written with in rgb color space? |
| |
| RESOLVED: Implementation can't determine how the input pixel has been |
| manipulated before producing the shader outputs, so results would be |
| undefined in this case. |
| |
| 3. What happens if the source formats aren't the expected format for sampler? |
| |
| RESOLVED: Non-YUV format will generate a draw time INVALID_OPERATION error. |
| |
| 4. Is the depth or stencil behaviour changed when rendering to yuv surfaces. |
| |
| RESOLVED: The depth and stencil buffers will work the same when rendering |
| to RGB or YUV surfaces, however when shader output is qualified with yuv |
| layout qualifier, writing out gl_FragDepth would cause compilation failure. |
| |
| 5. Should this extension include support for renderbuffers or just |
| renderable textures? |
| |
| RESOLVED: Renderbuffers doesn't add any functionality so it will not be |
| included. |
| |
| 6. Is BlitFramebuffer or CopyTex[Sub]Image supported with YUV renderable |
| surfaces? |
| |
| RESOLVED: No. There is a lot of driver complexity in supporting and |
| testing case. Using these calls with a YUV source or destination |
| will cause an INVALID_OPERATION error. |
| |
| 7. Does EXT_shader_framebuffer_fetch work with YUV renderable surfaces? |
| |
| RESOLVED: Yes. The next question is the result before or after |
| sub-sampling? To give maximum flexibility to hardware either of these |
| options is acceptable. |
| |
| 8. Should we add support for BT.2020? |
| |
| RESOLVED: Currently No, If require BT.2020 functionality can be achieved |
| using __samplerExternal2DY2YEXT and user defined matrix. To keep the spec |
| simple, we just want to have only three currently. |
| |
| 9. Should sampling return samples converted in to linear space or raw |
| samples? |
| |
| RESOLVED: This extension will return raw samples. If the YUV data is |
| encoded in a non-linear space, as is common, the returned samples will be |
| in the non-linear space. If the data is encoded linearly, the returned |
| samples will be linear. |
| |
| 10. Are there specific requirements on how a lower resolution UV plane must |
| be sampled during rendering? |
| |
| RESOLVED: To allow maximum flexibility in hardware at this time this |
| extension does not define how this sampling must be performed. Even if we |
| decide to define this behaviour in future, it would be more appropriate to |
| do it via a separate EGL extension. |
| |
| 11. How goes gl_FragCoord work with a lower resolution UV plane? |
| |
| RESOLVED: It is expected to work as if that plane was rendered at full |
| resolution. The exception to this is talked about in issue #11 where |
| there is some flexibility in subpixel sampling. |
| |
| 12. Should we add YUV format support for image load store in this extension or |
| is it valid to use new yuv format layout qualifier with image load store ? |
| |
| RESOLVED: No, Since that would require major changes, we should do this with |
| a separate extension, currently using new yuv format qualifier with image load |
| store would cause compilation failure. |
| |
| 13. How can we defines color standard matrix other than provided via built-in |
| functions e.g. full range BT.709 or adding compensation for the different colour |
| primaries of the different standards ? |
| |
| RESOLVED: This extension defines built in utility functions for some of the |
| common color conversion standard, however its no way limit an app to certain |
| standard of output data. App can define own color matrix for such purpose |
| and use with either __samplerExternal2DY2YEXT or sampler2D. |
| |
| 14. What happens if shader produce a color output qualified with yuv layout |
| qualifier and current draw FBO format isn't YUV or draw FBO format is in |
| YUV color space but shader output isn't qualified with yuv layout qualifier. |
| |
| RESOLVED: In order to write YUV color output, shader color output must be |
| qualified with yuv layout qualifier and draw FBO format needs to be in YUV |
| color space otherwise lack of any of these would cause INVALID_OPERATION |
| error. |
| |
| 15. What happens if shader produce yuv color output which is out of range |
| as per definition of color space format of rendering surface e.g. full range |
| output when the output color space is limited or similarly input to one of |
| built in color conversion functions or to the new __samplerExternal2DY2YEXT |
| is out of range. |
| |
| RESOLVED: If shader yuv color output or input values to one of the built in |
| color conversion functions or to the new __samplerExternal2DY2YEXT are not |
| within the specified range of the format, results would be undefined values. |
| |
| 16. How ReadPixels operate for YUV render target? |
| |
| RESOLVED: ReadPixels will convert YUV to RGBA under the current spec |
| requirement to support format RGBA and type UNSIGNED_BYTE combination for |
| the normalized fixed point surfaces depending upon format and color space |
| standard of currently bound rendering surface. |
| |
| Known Quality Issues |
| |
| Since YUV is a lossy compressed format and UV values represent sampling at |
| even locations, there may be minor quality issues along the primitive edges |
| or for scissor when its X or Y set to an odd value. In case of YUV |
| primitive rendering if geometry is animated, there may be more artifacts as |
| edges might flicker and sparkle frame to frame. Another way to explain |
| this corruption is that sometimes the different planes are stored at |
| different resolutions so the different interpolation for different planes |
| causes these artifacts. |
| |
| Due to nature of CbCr subsampling, there might be artifacts along the primitive |
| edges if there are partially covered pixels. Since commonly used 4:2:0 YUV |
| formats writes out 1 pixel for a block of 2x2 pixels, depending upon how |
| subsampled pixel output is calculated, there may always be artifacts around the |
| primitive edges for partially covered pixels e.g. implementation might always |
| decide to choose CbCr subsample cosited with top left pixel 2x2 Y plane block |
| based on this single pixel coverage. This could help to avoid artifacts in more |
| key cases e.g. along the diagonal of quad when its drawn using triangle strip |
| but it may cause artifacts in other cases when we have partially covered |
| pixels around the primitive edges visible after using very high zoom factor. |
| |
| Dependencies on EGL_KHR_image, EGL_KHR_image_base, and EGL 1.4 |
| |
| If EGL 1.2 is not supported, or if neither the EGL_OES_image nor |
| EGL_OES_image_base extensions is supported, all discussion of |
| EGLImages should be ignored, and any calls to either |
| EGLImageTargetTexture2DOES or FramebufferTexture2D with |
| TEXTURE_EXTERNAL_OES textarget should generate the error |
| INVALID_OPERATION. |
| |
| Dependencies on OES_EGL_image_external |
| |
| This extension is built on top of the OES_EGL_image_external extension. |
| It can coexist with the OES_EGL_image_external extension. |
| |
| Revision History |
| #17 (April 6, 2018, H1Gdev) |
| - Fix typo. |
| #16 (June 8, 2016, Jeff Leger) |
| - Add yuvCscStandardExt itu_* to the list of keywords |
| - Add yuvCscStandardExt as a basic type and clarify that this type |
| can only be used in assignments or as a function argument. |
| - Add rgb_2_yuv and yuv_2_rgb as built-in functions |
| (Bug 15704). |
| |
| #15 (April 23, 2015, Jon Leech) |
| - Fix typo EGLImageTargetTexImage2DOES -> EGLImageTargetTexture2DOES |
| (Bug 8114). |
| |
| #14 (February 10, 2015, Amit Bansal) |
| - Removed YUV_EXT and Y_EXT tokens hard requirement for ReadPixels, |
| current plan is to propose it later as separate extension once we |
| have more corresponding compelling use cases. |
| - Adding interaction wording with EXT_shader_framebuffer_fetch |
| - Removed duplicated image load store issue. |
| - Further clarification about usage of yuv layout qualifier |
| |
| #13 (January 23, 2015, Amit Bansal) |
| - added texture built in functions from OES_EGL_image_external_essl3 |
| - Added explicit clarification in overview section about RGB external images |
| - Interaction with geometry & tessellation shaders w.r.t. issue 1 |
| |
| #12 (December 12, 2014, Amit Bansal) |
| - Added new yuv qualifiers and corresponding draw time checks |
| requirement issues |
| - Clarification regarding yuvCscStandardEXT type usage |
| - Output clamping requirement issue |
| - New YUV_EXT and Y_EXT tokens for ReadPixels |
| - Changed blending & color mask behaviour to draw time error. |
| - Some language clean up |
| |
| #11 (September 30, 2014, Amit Bansal) |
| - Changed couple of issues to spec language |
| - Reworded some issues after recent spec updates |
| |
| #10 (August 12, 2013, Maurice Ribble) |
| - Changed from QCOM to EXT extension |
| - Reworded issue 16 based on Mark Callow's suggestion |
| - Updated names of SAMPLER_EXTERNAL_2D_Y2Y_EXT, |
| __samplerExternal2DY2YEXT, and yuvCscStandardEXT |
| |
| #9 (August 6, 2013, Maurice Ribble) |
| - Added issues 15-18 |
| |
| #8 (July 12, 2013, Maurice Ribble) |
| - Some language cleanup |
| - Changed some edge case errors to be more consistent |
| - Updates based on feedback from other khronos members |
| - Added issues 10-14 |
| |
| #7 (June 27, 2013, Maurice Ribble) |
| - Some language cleanup |
| |
| #6 (May 16, 2013, Amit Bansal) |
| - Correcting spacing |
| - Modified overview to keep only one sampler and add new built-in |
| - Defined new types for built in and removed previous layouts |
| - Removed the separate GL functions for external attachment |
| - Modified description of sections meant for spec |
| - Modified issues to reflect layout and built in function update |
| - Changed proposed to resolved for finalized issues |
| - Move precision issue to the description of built in function |
| |
| #5 (March 14, 2013, Jing zhou) |
| - Minor rewording on same of proposals for the Issues |
| - Assign new token IDs from reserved QCOM ID block |
| |
| #4 (March 4, 2013, Maurice Ribble) |
| - First round of cleanup and todos |
| |
| #3 (February 19, 2013, Amit Bansal) |
| - Modified glReadPixels()issue section |
| |
| #2 (January 9, 2013, Amit Bansal) |
| - Changed the OES suffix to QCOM as extension is still pending to be |
| approved. |
| - Removed EGLImageTargetTexture2DOES from New Procedures and Functions |
| category |
| - Corrected error in FramebufferRenderbuffer2DExternalQCOM name at line |
| 167. |
| - Modified description of FramebufferTexture2DExternalQCOM to reflect |
| argument changes correctly |
| - Corrected typo extension to extension |
| - Finished the documentation of final proposal for issue 2 & 3. |
| - Added a new Known Quality Issue section and text corresponding to it |
| |
| #1 - (Oct 1, 2012) Original Draft |
