1Name 2 3 EXT_YUV_target 4 5Name Strings 6 7 GL_EXT_YUV_target 8 9Contributors 10 11 Amit Bansal 12 Arshad Bebal 13 Jeff Leger 14 Jing Zhou 15 Maurice Ribble 16 Prabindh Sundareson 17 Jan-Harald Fredriksen 18 Daniel Koch 19 Jamie Gennis 20 Mark Callow 21 Pat Brown 22 Andrew Garrard 23 Etay Meiri 24 Weifeng Zhang 25 26Contacts 27 28 Jeff Leger <jleger@qti.qualcomm.com> 29 30Status 31 32 Complete. 33 34Version 35 36 April 6, 2018 (version 17) 37 38Number 39 40 OpenGL ES Extension #222 41 42Dependencies 43 44 Requires OpenGL ES 3.0 and ESSL 3.0. 45 Requires EGL 1.4 and following EGL extension: 46 47 EGL_KHR_image_base 48 OES_EGL_image_external 49 50 This extension is written based on the wording of the OpenGL ES 3.0 51 Specification and OpenGL ES Shading Language 3.0. 52 53 This extension interacts with OpenGL ES 3.1. See issue 1 and 13 for 54 more details. 55 56 This extension interacts with OES_tessellation_shader & 57 OES_geometry shader see first issue for more details. 58 59 This extension borrows texture function names from the 60 OES_EGL_image_external_essl3. This extension is compatible with 61 OES_EGL_image_external_essl3 and can coexist but does not require it. 62 63 This extension interacts with EXT_shader_framebuffer_fetch. see 64 issue 7 for more details. 65 66Overview 67 68 This extension adds support for three new YUV related items: first 69 rendering to YUV images, second sampling from YUV images while keeping the 70 data in YUV space, third it defines a new built in function that does 71 conversion from RGB to YUV with controls to choose ITU-R BT.601-7, 72 ITU-R BT.601-7 Full range (JFIF images), or ITU-R BT.709-5 standard. 73 74 This new functionality is layered on top of the OES_EGL_image_external 75 extension. 76 77 To perform the YUV rendering capability in this extension an application 78 will attach a texture to the framebuffer object as the color attachment. 79 If the texture has a target type of TEXTURE_EXTERNAL_OES with YUV color 80 format then the GL driver can use this framebuffer object as the render 81 target, TEXTURE_EXTERNAL_OES target with RGB color format are not allowed 82 with this extension. 83 84New Types & Keywords 85 86 A new OpenGL GLSL extension flag is added: 87 88 #extension GL_EXT_YUV_target 89 90 When the above GLSL extension is specified, one new sampler type 91 will be available for sampling the 2D texture: 92 93 __samplerExternal2DY2YEXT 94 95 The "__samplerExternal2DY2YEXT" is used to sample a YUV texture image and 96 output color value without any color conversion. 97 98 Whenever a YUV sample is output from the sampler, the format of the YUV 99 will be as if YUV 4:4:4 format is output. This also means that the Y 100 sample maps to component R, the U sample maps to component G, the V sample 101 maps to component B, and the component A will be 1.0f. 102 103 The RGB sample output will be the same as in OpenGL ES specification. 104 105 Here is one example: 106 107 uniform __samplerExternal2DY2YEXT u_sTexture; 108 109 When the above GLSL extension is specified, one new additional type will be 110 available to specify color space standard formula for yuv to rgb transformation. 111 112 yuvCscStandardEXT 113 114 The value of new type can be specified using one of three new keywords 115 itu_601, itu_601_full_range and itu_709. 116 117 For example: 118 119 yuvCscStandardEXT conv_standard = itu_601; 120 yuvCscStandardEXT conv_standard = itu_601_full_range; 121 yuvCscStandardEXT conv_standard = itu_709; 122 123 Keyword itu_601 means color conversion is required using the formula 124 specified in the ITU-R BT.601. Similarly keyword itu_601_full_range 125 means conversion is done using ITU BT.601 full range formula as specified 126 in JFIF standard while keyword itu_709 specify ITU-R BT.709 standard. Note 127 that new yuvCscStandardEXT type can't be use for any other purpose apart 128 from specifying color standard value to newly introduced color conversion 129 built in functions mentioned below. 130 131New Built-in function 132 133 When the new GLSL extension is specified, two new built in functions 134 will be available for rgb to yuv or yuv to rgb color space conversion. 135 136 vec3 rgb_2_yuv(vec3 color, yuvCscStandardEXT conv_standard); 137 138 The function rgb_2_yuv will apply rgb to yuv color conversion 139 transformation on "color" value using the formula specified as per new type 140 yuvCscStandardEXT variable. The first input parameter supposed to specify 141 rgb value using x, y & z channels of a vec3 variable, correspondingly 142 return value of this function will have transformed y, u and v value in its 143 x, y and z channel. Precision of the input color will define the precision 144 used for color space conversion and for output yuv color value. 145 146 vec3 yuv_2_rgb (vec3 color, yuvCscStandardEXT conv_standard); 147 148 The function yuv_2_rgb will apply yuv to rgb color conversion 149 transformation on "color" value using the formula specified as per new type 150 yuvCscStandardEXT variable. The first input parameter supposed to specify 151 yuv value using x, y & z channels of a vec3 variable, correspondingly 152 return value of this function will have transformed r, g and b value in its 153 x, y and z channel. Precision of the input color will define the precision 154 used for color space conversion and for output yuv color value. 155 156New layout qualifier 157 158 A shader which produces yuv format color output must qualify the fragment 159 shader output variable with new yuv layout qualifier as described below. 160 161 layout (yuv) out vec4 color; 162 163 The new yuv layout qualifier can't be combined with any other layout qualifier, 164 can only be used with fragment shader outputs and would be available only when 165 the new GLSL extension is specified. Additionally if the shader qualifies 166 fragment shader output with the new yuv qualifier and write depth or multiple 167 color output, it would cause compilation failure. 168 169New Tokens 170 171 Returned in the <type> parameter of GetActiveUniform: 172 173 SAMPLER_EXTERNAL_2D_Y2Y_EXT 0x8BE7 174 175Reuse tokens as in extension "OES_EGL_image_external." 176 177 Accepted as a target in the <target> parameter of BindTexture, 178 EGLImageTargetTexture2DOES, and FramebufferTexture2D: 179 180 TEXTURE_EXTERNAL_OES 0x8D65 181 182 Accepted as <value> in GetIntegerv() and GetFloatv() queries: 183 184 TEXTURE_BINDING_EXTERNAL_OES 0x8D67 185 186 Accepted as <value> in GetTexParameter*() queries: 187 188 REQUIRED_TEXTURE_IMAGE_UNITS_OES 0x8D68 189 190Addition to Chapter 3 of the OpenGL ES 3.0 specification 191 192 Add a new section: "3.8.18 External Textures," which follows section 193 "3.8.17 Shader Exponent Texture Color Conversion." The wording will 194 be the same as in extension "OES_EGL_image_external." 195 196Changes to Section 4.4.2 "Attaching Images to Framebuffer Objects" 197 198 At the end of subsection "Attaching Texture Images to a Framebuffer," add 199 the following paragraphs: 200 201 from 202 "If texture is not zero, then texture must either name an existing 203 two dimensional texture object and textarget must be TEXTURE_2D or 204 texture must name an existing cube map...." 205 206 to 207 "If texture is not zero, then texture must either name an existing 208 two dimensional texture object and textarget must be TEXTURE_2D or 209 TEXTURE_EXTERNAL_OES or texture must name an existing cube map...." 210 211 from 212 "If textarget is TEXTURE_2D, level must be greater than or equal to 213 zero and no larger than log2 of the value of MAX_TEXTURE_SIZE. 214 Otherwise, an INVALID_VALUE error is generated. 215 The command..." 216 to 217 "If textarget is TEXTURE_2D, level must be greater than or equal to 218 zero and no larger than log2 of the value of MAX_TEXTURE_SIZE. 219 Otherwise, an INVALID_VALUE error is generated. If textarget is 220 TEXTURE_EXTERNAL_OES and attachment is other than COLOR_ATTACHMENT0, 221 an INVALID_OPERATION error is generated. 222 The command..." 223 224 Add an additional sentence at the end of above paragraph: 225 226 "Since TEXTURE_EXTERNAL_OES texture target can only be specified 227 using an EGLImage, yuv formats can be rendered by attaching 228 TEXTURE_EXTERNAL_OES textarget via EGLImage." 229 230Changes to Section 4.2.3 "Clearing the Buffers" 231 from 232 "Unsigned normalized fixed-point RGBA color buffers are cleared to color 233 values derived by clamping each component of the clear color to the range 234 [0; 1], then converting the (possibly sRGB converted and/or dithered) color 235 to fixed-point using equations 2.3 or 2.4, respectively. The result of 236 clearing integer color buffers with Clear is undefined." 237 238 to 239 "Unsigned normalized fixed-point RGBA color buffers are cleared to color 240 values derived by clamping each component of the clear color to the range 241 [0; 1], then converting the (possibly sRGB converted and/or dithered) color 242 to fixed-point using equations 2.3 or 2.4, respectively. When clearing YUV 243 Color Buffers, clear color should be defined in yuv color space and so 244 floating point r, g, and b value will be mapped to corresponding y, u and v 245 value and alpha channel will be ignored. The result of clearing integer 246 color buffers with Clear is undefined." 247 248Changes to Section 4.4.3 "Fine Control of Buffer Updates" 249 250 from 251 "ColorMask is used to mask the writing of R, G, B and A values to all active 252 draw buffers. r, g, b, and a indicate whether R, G, B, or A values, respectively, 253 are written or not (a value of TRUE means that the corresponding value is written). 254 In the initial state, all color values are enabled for writing for all draw 255 buffers..." 256 257 to 258 "ColorMask is used to mask the writing of R, G, B and A values to all active 259 draw buffers. r, g, b, and a indicate whether R, G, B, or A values, respectively, 260 are written or not (a value of TRUE means that the corresponding value is written) 261 except when the color buffer is in YUV color space, in that case setting any one 262 of the r, g, b, and a values as false would generate draw time INVALID_OPERATION error. 263 In the initial state, all color values are enabled for writing for all draw 264 buffers..." 265 266Changes to Section 4.1.7 "Blending" 267 268 from 269 "Blending applies only if the color buffer has a fixed-point format. If the color 270 buffer has an integer format, proceed to the next operation." 271 272 to 273 "Blending applies only if the color buffer has a fixed-point format and non YUV space 274 format color buffer. If the color buffer has an integer, proceed to the next 275 operation. If color buffer format is YUV color space, it will generate 276 draw time INVALID_OPERATION error." 277 278Changes to 4.2.1 "Selecting Buffers for Writing" 279 from 280 "If some, but not all user-defined output variables are written, the values of 281 fragment colors corresponding to unwritten variables are similarly undefined. 282 The order of writes..." 283 284 to 285 "If some, but not all user-defined output variables are written, the values of 286 fragment colors corresponding to unwritten variables are similarly undefined unless 287 any of the fragment output is qualified with yuv format qualifier. In later case 288 compiler would restrict usage of yuv format qualifier up to a single color output. 289 The order of writes..." 290 291Changes to section 4.4.4 ("Framebuffer Completeness") 292 from 293 "An internal format is color-renderable if it is one of the formats from table 294 3.12 noted as color-renderable or if it is unsized format RGBA or RGB. No 295 other formats," 296 297 to 298 "An internal format is color-renderable if it is one of the formats from table 299 3.12 noted as color-renderable or if it is unsized format RGBA or RGB or if it is 300 YUV color space format supported by implementation. No other formats," 301 302Changes to section 3.7 ("Keywords") of the OpenGL ES Shading Language 303specification 304 305 - Add to the list of keywords: 306 307 __samplerExternal2DY2YEXT 308 yuvCscStandardExt 309 itu_601 310 itu_601_full_range 311 itu_709 312 313 314 315Changes to section 4.1 ("Basic Types") of the OpenGL ES Shading Language 316specification 317 - Add to the list of Transparent types: 318 "yuvCscStandardExt a value type to specify color space standard formula for 319 transformation between yuv and rgb, taking values of itu_601, itu_601_full_range, 320 itu_709" 321 322 - Add to the list of Floating Point Sampler Types (opaque): 323 324 "__samplerExternal2DY2YEXT a handle for accessing an external 2D texture 325 whose underneath format is YUV" 326 327 - Add a paragraph at the end of the section: 328 329 "The __samplerExternal2DY2YEXT and yuvCscStandardExt types are optional and must 330 be enabled by 331 332 #extension GL_EXT_YUV_target : enable 333 334 No type constructor or type conversion is allowed on yuvCscStandardExt. A value 335 of itu_601, itu_601_full_range, itu_709, or a variable typed as yuvCscStandardExt 336 can be used as an argument to user-defined functions and the built-in functions yuv_2_rgb and 337 rgb_2_yuv. Other than the assignment operator, any other operations on this type 338 of values or variables will be treated as a compilation error." 339 340Changes to section 4.5.4 ("Default Precision Qualifiers") of the OpenGL ES 341Shading Language specification 342 343 - Add to the list of "vertex language has the following predeclared 344 globally scoped default precision statements:" 345 346 "precision lowp __samplerExternal2DY2YEXT;" 347 348 - Add to the list of "fragment language has the following predeclared 349 globally scoped default precision statements:" 350 351 "precision lowp __samplerExternal2DY2YEXT;" 352 353Changes to section 8.8 ("Texture Lookup Functions") of the OpenGL ES Shading 354Language specification 355 356 - Add to the table the following sampler functions: 357 358 "highp ivec2 textureSize(__samplerExternal2DY2YEXT sampler, int lod) 359 vec4 texture(__samplerExternal2DY2YEXT sampler, vec2 P [, float bias] ) 360 vec4 textureProj(__samplerExternal2DY2YEXT sampler, vec3 P [, float bias] ) 361 vec4 textureProj(__samplerExternal2DY2YEXT sampler, vec4 P [, float bias]) 362 vec4 texelFetch(__samplerExternal2DY2YEXT sampler, ivec2 P, int lod)" 363 364Add a new section 8.10 "Conversion Functions between YUV and RGB" 365 366 - Add a new table containing 2 entries: 367 368 vec3 rgb_2_yuv(vec3 color, yuvCscStandardEXT conv_standard); 369 apply rgb to yuv color conversion transformation on "color" value 370 using the formula specified by conv_standard. 371 372 vec3 yuv_2_rgb(vec3 color, yuvCscStandardEXT conv_standard); 373 apply yuv to rgb color conversion transformation on "color" value 374 using the formula specified by conv_standard. 375 376Compatibility with OpenGL ES 3.1 and ESSL 3.10 377 378 This extension is expected to work without modification with OpenGL ES 3.1 379 and ESSL 3.10. Some further clarification in issue 1, 9 and 13. 380 381Issues 382 383 1. Do we want to explicitly disallow "__samplerExternal2DY2YEXT" from use in other 384 shader apart from fragment shader e.g. vertex, compute, geometry and tessellation 385 shaders? 386 387 RESOLVED: No, modern unified shader hardware supports YUV texture sampling in all 388 of the shader stages, we should keep this enable irrespective of shader stage. 389 390 2. What happens if the input source isn't in the expected color space for built in 391 functions or lets say there is cross conversion between different color space 392 conversion standards e.g. 601 RGB to 709 YUV etc or yuv layout qualified color 393 output is actually written with in rgb color space? 394 395 RESOLVED: Implementation can't determine how the input pixel has been 396 manipulated before producing the shader outputs, so results would be 397 undefined in this case. 398 399 3. What happens if the source formats aren't the expected format for sampler? 400 401 RESOLVED: Non-YUV format will generate a draw time INVALID_OPERATION error. 402 403 4. Is the depth or stencil behaviour changed when rendering to yuv surfaces. 404 405 RESOLVED: The depth and stencil buffers will work the same when rendering 406 to RGB or YUV surfaces, however when shader output is qualified with yuv 407 layout qualifier, writing out gl_FragDepth would cause compilation failure. 408 409 5. Should this extension include support for renderbuffers or just 410 renderable textures? 411 412 RESOLVED: Renderbuffers doesn't add any functionality so it will not be 413 included. 414 415 6. Is BlitFramebuffer or CopyTex[Sub]Image supported with YUV renderable 416 surfaces? 417 418 RESOLVED: No. There is a lot of driver complexity in supporting and 419 testing case. Using these calls with a YUV source or destination 420 will cause an INVALID_OPERATION error. 421 422 7. Does EXT_shader_framebuffer_fetch work with YUV renderable surfaces? 423 424 RESOLVED: Yes. The next question is the result before or after 425 sub-sampling? To give maximum flexibility to hardware either of these 426 options is acceptable. 427 428 8. Should we add support for BT.2020? 429 430 RESOLVED: Currently No, If require BT.2020 functionality can be achieved 431 using __samplerExternal2DY2YEXT and user defined matrix. To keep the spec 432 simple, we just want to have only three currently. 433 434 9. Should sampling return samples converted in to linear space or raw 435 samples? 436 437 RESOLVED: This extension will return raw samples. If the YUV data is 438 encoded in a non-linear space, as is common, the returned samples will be 439 in the non-linear space. If the data is encoded linearly, the returned 440 samples will be linear. 441 442 10. Are there specific requirements on how a lower resolution UV plane must 443 be sampled during rendering? 444 445 RESOLVED: To allow maximum flexibility in hardware at this time this 446 extension does not define how this sampling must be performed. Even if we 447 decide to define this behaviour in future, it would be more appropriate to 448 do it via a separate EGL extension. 449 450 11. How goes gl_FragCoord work with a lower resolution UV plane? 451 452 RESOLVED: It is expected to work as if that plane was rendered at full 453 resolution. The exception to this is talked about in issue #11 where 454 there is some flexibility in subpixel sampling. 455 456 12. Should we add YUV format support for image load store in this extension or 457 is it valid to use new yuv format layout qualifier with image load store ? 458 459 RESOLVED: No, Since that would require major changes, we should do this with 460 a separate extension, currently using new yuv format qualifier with image load 461 store would cause compilation failure. 462 463 13. How can we defines color standard matrix other than provided via built-in 464 functions e.g. full range BT.709 or adding compensation for the different colour 465 primaries of the different standards ? 466 467 RESOLVED: This extension defines built in utility functions for some of the 468 common color conversion standard, however its no way limit an app to certain 469 standard of output data. App can define own color matrix for such purpose 470 and use with either __samplerExternal2DY2YEXT or sampler2D. 471 472 14. What happens if shader produce a color output qualified with yuv layout 473 qualifier and current draw FBO format isn't YUV or draw FBO format is in 474 YUV color space but shader output isn't qualified with yuv layout qualifier. 475 476 RESOLVED: In order to write YUV color output, shader color output must be 477 qualified with yuv layout qualifier and draw FBO format needs to be in YUV 478 color space otherwise lack of any of these would cause INVALID_OPERATION 479 error. 480 481 15. What happens if shader produce yuv color output which is out of range 482 as per definition of color space format of rendering surface e.g. full range 483 output when the output color space is limited or similarly input to one of 484 built in color conversion functions or to the new __samplerExternal2DY2YEXT 485 is out of range. 486 487 RESOLVED: If shader yuv color output or input values to one of the built in 488 color conversion functions or to the new __samplerExternal2DY2YEXT are not 489 within the specified range of the format, results would be undefined values. 490 491 16. How ReadPixels operate for YUV render target? 492 493 RESOLVED: ReadPixels will convert YUV to RGBA under the current spec 494 requirement to support format RGBA and type UNSIGNED_BYTE combination for 495 the normalized fixed point surfaces depending upon format and color space 496 standard of currently bound rendering surface. 497 498Known Quality Issues 499 500 Since YUV is a lossy compressed format and UV values represent sampling at 501 even locations, there may be minor quality issues along the primitive edges 502 or for scissor when its X or Y set to an odd value. In case of YUV 503 primitive rendering if geometry is animated, there may be more artifacts as 504 edges might flicker and sparkle frame to frame. Another way to explain 505 this corruption is that sometimes the different planes are stored at 506 different resolutions so the different interpolation for different planes 507 causes these artifacts. 508 509 Due to nature of CbCr subsampling, there might be artifacts along the primitive 510 edges if there are partially covered pixels. Since commonly used 4:2:0 YUV 511 formats writes out 1 pixel for a block of 2x2 pixels, depending upon how 512 subsampled pixel output is calculated, there may always be artifacts around the 513 primitive edges for partially covered pixels e.g. implementation might always 514 decide to choose CbCr subsample cosited with top left pixel 2x2 Y plane block 515 based on this single pixel coverage. This could help to avoid artifacts in more 516 key cases e.g. along the diagonal of quad when its drawn using triangle strip 517 but it may cause artifacts in other cases when we have partially covered 518 pixels around the primitive edges visible after using very high zoom factor. 519 520Dependencies on EGL_KHR_image, EGL_KHR_image_base, and EGL 1.4 521 522 If EGL 1.2 is not supported, or if neither the EGL_OES_image nor 523 EGL_OES_image_base extensions is supported, all discussion of 524 EGLImages should be ignored, and any calls to either 525 EGLImageTargetTexture2DOES or FramebufferTexture2D with 526 TEXTURE_EXTERNAL_OES textarget should generate the error 527 INVALID_OPERATION. 528 529Dependencies on OES_EGL_image_external 530 531 This extension is built on top of the OES_EGL_image_external extension. 532 It can coexist with the OES_EGL_image_external extension. 533 534Revision History 535 #17 (April 6, 2018, H1Gdev) 536 - Fix typo. 537 #16 (June 8, 2016, Jeff Leger) 538 - Add yuvCscStandardExt itu_* to the list of keywords 539 - Add yuvCscStandardExt as a basic type and clarify that this type 540 can only be used in assignments or as a function argument. 541 - Add rgb_2_yuv and yuv_2_rgb as built-in functions 542 (Bug 15704). 543 544 #15 (April 23, 2015, Jon Leech) 545 - Fix typo EGLImageTargetTexImage2DOES -> EGLImageTargetTexture2DOES 546 (Bug 8114). 547 548 #14 (February 10, 2015, Amit Bansal) 549 - Removed YUV_EXT and Y_EXT tokens hard requirement for ReadPixels, 550 current plan is to propose it later as separate extension once we 551 have more corresponding compelling use cases. 552 - Adding interaction wording with EXT_shader_framebuffer_fetch 553 - Removed duplicated image load store issue. 554 - Further clarification about usage of yuv layout qualifier 555 556 #13 (January 23, 2015, Amit Bansal) 557 - added texture built in functions from OES_EGL_image_external_essl3 558 - Added explicit clarification in overview section about RGB external images 559 - Interaction with geometry & tessellation shaders w.r.t. issue 1 560 561 #12 (December 12, 2014, Amit Bansal) 562 - Added new yuv qualifiers and corresponding draw time checks 563 requirement issues 564 - Clarification regarding yuvCscStandardEXT type usage 565 - Output clamping requirement issue 566 - New YUV_EXT and Y_EXT tokens for ReadPixels 567 - Changed blending & color mask behaviour to draw time error. 568 - Some language clean up 569 570 #11 (September 30, 2014, Amit Bansal) 571 - Changed couple of issues to spec language 572 - Reworded some issues after recent spec updates 573 574 #10 (August 12, 2013, Maurice Ribble) 575 - Changed from QCOM to EXT extension 576 - Reworded issue 16 based on Mark Callow's suggestion 577 - Updated names of SAMPLER_EXTERNAL_2D_Y2Y_EXT, 578 __samplerExternal2DY2YEXT, and yuvCscStandardEXT 579 580 #9 (August 6, 2013, Maurice Ribble) 581 - Added issues 15-18 582 583 #8 (July 12, 2013, Maurice Ribble) 584 - Some language cleanup 585 - Changed some edge case errors to be more consistent 586 - Updates based on feedback from other khronos members 587 - Added issues 10-14 588 589 #7 (June 27, 2013, Maurice Ribble) 590 - Some language cleanup 591 592 #6 (May 16, 2013, Amit Bansal) 593 - Correcting spacing 594 - Modified overview to keep only one sampler and add new built-in 595 - Defined new types for built in and removed previous layouts 596 - Removed the separate GL functions for external attachment 597 - Modified description of sections meant for spec 598 - Modified issues to reflect layout and built in function update 599 - Changed proposed to resolved for finalized issues 600 - Move precision issue to the description of built in function 601 602 #5 (March 14, 2013, Jing zhou) 603 - Minor rewording on same of proposals for the Issues 604 - Assign new token IDs from reserved QCOM ID block 605 606 #4 (March 4, 2013, Maurice Ribble) 607 - First round of cleanup and todos 608 609 #3 (February 19, 2013, Amit Bansal) 610 - Modified glReadPixels()issue section 611 612 #2 (January 9, 2013, Amit Bansal) 613 - Changed the OES suffix to QCOM as extension is still pending to be 614 approved. 615 - Removed EGLImageTargetTexture2DOES from New Procedures and Functions 616 category 617 - Corrected error in FramebufferRenderbuffer2DExternalQCOM name at line 618 167. 619 - Modified description of FramebufferTexture2DExternalQCOM to reflect 620 argument changes correctly 621 - Corrected typo extension to extension 622 - Finished the documentation of final proposal for issue 2 & 3. 623 - Added a new Known Quality Issue section and text corresponding to it 624 625 #1 - (Oct 1, 2012) Original Draft 626