1Name 2 3 OES_required_internalformat 4 5Name Strings 6 7 GL_OES_required_internalformat 8 9Contributors 10 11 Aaftab Munshi 12 Jeremy Sandmel 13 Members of the Khronos OpenGL ES working group 14 15Contact 16 17 Benj Lipchak, Apple, Inc. (lipchak 'at' apple.com) 18 19Notice 20 21 Copyright (c) 2007-2013 The Khronos Group Inc. Copyright terms at 22 http://www.khronos.org/registry/speccopyright.html 23 24Specification Update Policy 25 26 Khronos-approved extension specifications are updated in response to 27 issues and bugs prioritized by the Khronos OpenGL ES Working Group. For 28 extensions which have been promoted to a core Specification, fixes will 29 first appear in the latest version of that core Specification, and will 30 eventually be backported to the extension document. This policy is 31 described in more detail at 32 https://www.khronos.org/registry/OpenGL/docs/update_policy.php 33 34Status 35 36 Complete. 37 Approved by the Khronos Promoters on April 26, 2012. 38 39Version 40 41 Last Modified Date: January 29, 2010 42 Author Revision: 0.19 43 44Number 45 46 XXX TBD 47 48Dependencies 49 50 OpenGL ES 1.0 is required. 51 52 This extension is written against the OpenGL ES 1.1 specification. 53 54 OpenGL ES 2.0 affects the definition of this extension. 55 56 OES_framebuffer_object affects the definition of this extension. 57 58 OES_depth_texture affects the definition of this extension. 59 60 OES_depth24 and OES_depth32 affect the definition of this extension. 61 62 OES_packed_depth_stencil affects the definition of this extension. 63 64 OES_rgb8_rgba8 affects the definition of this extension. 65 66 OES_stencil1, OES_stencil4, and OES_stencil8 affect the definition of this 67 extension. 68 69 OES_texture_3D affects the definition of this extension. 70 71 EXT_texture_type_2_10_10_10_REV affects the definition of this extension. 72 73Overview 74 75 The ES 1.1 API allows an implementation to store texture data internally 76 with arbitrary precision, regardless of the format and type of the data 77 supplied by the application. Similarly, ES allows an implementation to 78 choose an arbitrary precision for the internal storage of image data 79 allocated by glRenderbufferStorageOES. 80 81 While this allows flexibility for implementations, it does mean that an 82 application does not have a reliable means to request the implementation 83 maintain a specific precision or to find out what precision the 84 implementation will maintain for a given texture or renderbuffer image. 85 86 For reference, "Desktop" OpenGL uses the <internalformat> argument to 87 glTexImage*, glCopyTexImage* and glRenderbufferStorageEXT as a hint, 88 defining the particular base format and precision that the application wants 89 the implementation to maintain when storing the image data. Further, the 90 application can choose an <internalformat> with a different base internal 91 format than the source format specified by <format>. The implementation is 92 not required to exactly match the precision specified by <internalformat> 93 when choosing an internal storage precision, but it is required to match the 94 base internal format of <internalformat>. 95 96 In addition, ES 1.1 does not allow an implementation to fail a request to 97 glTexImage2D for any of the legal <format> and <type> combinations listed in 98 Table 3.4, even if the implementation does not natively support data stored 99 in that external <format> and <type>. However, there are no additional 100 requirements placed on the implementation. The ES implementation is free to 101 store the texture data with lower precision than originally specified, for 102 instance. Further, since ES removes the ability to query the texture object 103 to find out what internal format it chose, there is no way for the 104 application to find out that this has happened. 105 106 This extension addresses the situation in two ways: 107 108 1) This extension introduces the ability for an application to specify 109 the desired "sized" internal formats for texture image allocation. 110 111 2) This extension guarantees to maintain at least the specified 112 precision of all available sized internal formats. 113 114 An implementation that exports this extension is committing to support all 115 of the legal values for <internalformat> in Tables 3.4, 3.4.x, and 3.4.y, 116 subject to the extension dependencies described herein. That is to say, the 117 implementation is guaranteeing that choosing an <internalformat> argument 118 with a value from these tables will not cause an image allocation request to 119 fail. Furthermore, it is guaranteeing that for any sized internal format, 120 the renderbuffer or texture data will be stored with at least the precision 121 prescribed by the sized internal format. 122 123Issues 124 125 1. What API should we use to allow an application to indicate it wants 126 storage of at least a certain precision for a particular source format/ 127 type combination? 128 129 RESOLVED 130 131 We use the "sized" <internalformat> enums to indicate that an 132 application desires some minimum precision for internal storage and 133 that the GL should not use less than the specified precision. 134 135 We originally had considered using a new "UNPACK" parameter for 136 glPixelStorei that indicated the external <format> and <type> arguments 137 must be supported with no "downsampling" of the precision. 138 139 However, this latter approach ran into the problem that glCopyTexImage2D 140 and glRenderbufferStorageOES don't use the pixel store "UNPACK" state 141 nor do they have external <format> or <type> arguments to indicate the 142 application's requested precision. 143 144 Another option was to create a new set of glTexImage*, glCopyTexImage*, 145 and glRenderbufferStorageOES entry points that implied a minimum 146 required precision. 147 148 However, it seems the simplest thing to do is to just use the 149 <internalformat> argument for this purpose and keep the existing entry 150 points. It's also the most compatible with desktop OpenGL code. 151 152 2. Should this specification make any mention of "optionally supported" 153 <internalformat> values at all? Or should we just move all of those to 154 separate defined extensions? 155 156 RESOLVED, all the values for <internalformat> in Tables 3.4, 3.4.x, and 157 3.4.y in this extension must be accepted by their respective commands. 158 All sized formats in these tables must be stored with at least the 159 corresponding minimum precision. 160 161 Other extensions may introduce new values for <internalformat>. If they 162 do, they should modify Tables 3.4, 3.4.x, and 3.4.y. If an 163 implementation can support the new <internalformat> values, it will 164 export the extension. 165 166 The primary motivation for moving "optionally supported" formats to 167 their own extensions is so that a well-behaved application never gets 168 the idea that it is supposed to check for errors in order to query for 169 available functionality. Well-behaved applications should always query 170 for extension strings and other implementation-dependent state to check 171 for available functionality on a particular implementation. 172 173 3. What should be the recommended way to add new formats in the future? 174 175 RESOLVED 176 177 Just like before, new extensions can add new values for <internalformat> 178 for *TexImage* and RenderbufferStorageOES. Unless otherwise stated by 179 future extensions, new sized internal formats will provide the same kind 180 of minimum precision guarantees as the formats described herein. 181 182 4. How should we handle render vs. texture buffers? 183 184 RESOLVED 185 186 We have three tables in the spec, one for textures specified with 187 TexImage*, one for textures specified with CopyTexImage2D, and one for 188 renderbuffers allocated with RenderbufferStorageOES. 189 190 5. Should this extension require RGBA8? For both texture and render? 191 192 RESOLVED 193 194 Yes, for both. OpenGL ES 2.0 implementations are very likely to have 195 this support anyway, and OpenGL ES 1.x implementations can choose to 196 export this extension or not, depending on whether they support 8 bit/ 197 component for textures and renderbuffers. 198 199 Note, this extension does not require RGB8 for renderbuffers. 200 Availability of RGB8 renderbuffers is still based on presence of the 201 OES_rgb8_rgba8 extension. 202 203 6. What should this extension say, if anything, about depth and stencil 204 internal formats for RenderbufferStorageOES? 205 206 RESOLVED 207 208 Stencil and depth formats are listed in the Table 3.4.x. If an 209 implementation that supports this extension doesn't support one or more 210 of the stencil/depth format extensions then this extension behaves as if 211 those enums are NOT listed in Table 3.4.x. 212 213 7. Should we allow every combination of <format>, <type>, and 214 <internalformat>? 215 216 RESOLVED 217 218 No, we specifically disallow conversions between "base" formats (between 219 RGBA and LUMINANCE_ALPHA, for instance). Further, we also disallow 220 requested "expansions" to larger data types. That is, Table 3.4.x 221 allows the user to request that the GL use a lower precision than the 222 external <type> would require, but that table does not include any 223 entries that would require the GL to use more precision than the 224 external <type> would require. 225 226 We intentionally don't include this feature here because the 227 <internalformat> represents a required minimum precision for the GL. We 228 don't want to allow an application to require more precision internally 229 than they provide externally because it would necessitate a format 230 conversion. If some implementation really wants to add this 231 functionality, it would need to create an additional extension, say 232 FOO_expanded_internalformat. 233 234 Note that in the opposite situation where an application provides higher 235 precision source data and asks it to be stored at lower precision, an 236 implementation is still free to store at the higher precision, thereby 237 avoiding format conversion. 238 239 8. Should we split this extension into multiple extensions? 240 241 RESOLVED 242 243 No. No vendor has expressed interest in subsetting these 3 features: 244 245 Feature 1: This extension allows an application to specify sized 246 <internalformats> enums for texture and render buffer image 247 allocation. 248 249 Feature 2: This extension allows the implementation to export a 250 list of sized <internalformats> for which it will guarantee to 251 maintain the specified minimum precision when those formats are used 252 for texture or renderbuffer image allocation. 253 254 Feature 3: This extension defines a minimum set of sized 255 <internalformat> enums that are required to be exported by the query 256 mechanism in #2 above. 257 258 9. Should we add a query that lets the implementation advertise which 259 sized internal formats it supports with minimum precision? 260 261 RESOLVED 262 263 No, we'll leave it to a future extension to add this mechanism if 264 necessary. Today all sized internal formats have guaranteed minimum 265 precision. For posterity, we were close to choosing query mechanism 'c' 266 from the list below before we dropped the query entirely: 267 268 a) a query for a single format's support like this: 269 270 boolean QuerySupportOES(enum param, int count, const enum* list); 271 272 which takes a <list> of <count> sized internal format enums and 273 returns GL_FALSE if any of them, when used as a sized internal 274 format with the currently bound context, would result in an internal 275 format of lower precision than requested. The <param> could be 276 GL_SUPPORTED_TEXTURE_INTERNALFORMAT for querying supported texture 277 precisions and GL_SUPPORTED_RENDERBUFFER_INTERNALFORMAT for querying 278 supported renderbuffer precisions. 279 280 b) a query for all supported formats that the implementation can 281 guarantee minimum precision, like this: 282 283 void GetSupportedInternalFormatsOES(enum param, 284 int* count, 285 enum* list); 286 287 where <param> must be TEXTURE_INTERNALFORMAT or 288 RENDERBUFFER_INTERNALFORMAT. On input <count> is the maximum 289 number of internal formats to return, and on output <count> 290 is the number of internal formats in <list>. On output, <list> 291 contains all the values of <internalformat> for which the 292 implementation will guarantee specified precision. <list> will 293 contain <count> entries. 294 295 c) a query of a single internalformat providing a yes/no answer: 296 297 boolean IsPreciseInternalformatOES(enum param, enum internalformat); 298 299 where <param> must be TEXTURE or RENDERBUFFER_OES, and 300 <internalformat> is the internal format for which the app is 301 checking the minimum precision storage guarantee. 302 303 10. What is the OES_framebuffer_object interaction? Are FBOs a 304 prerequisite (even on ES 1.1), or should we strike mention of 305 renderbuffers if FBOs aren't available? 306 307 RESOLVED 308 309 Sized format hints and minimum precision guarantees for textures are 310 useful even on implementations where FBOs aren't supported. We won't 311 make FBOs a prerequisite. 312 313 11. Should we add retroactive support for EXT_texture_type_2_10_10_10_REV? 314 315 RESOLVED 316 317 Yes. We introduced two new sized internal formats, RGB10_A2_EXT and 318 RGB10_EXT. This format continues to be unrenderable, consistent with 319 the EXT_texture_type_2_10_10_10_REV spec. These formats join the rest 320 of existing sized internal formats on the required list of formats for 321 which precision is guaranteed. 322 323 12. Do we need different token values from OpenGL? 324 325 RESOLVED 326 327 No. Initially some new tokens (such as ALPHA8_OES) were given new 328 values, which was due to a difference in the meaning relative to 329 OpenGL: in OpenGL 2.1, sized internal formats were purely hints, 330 whereas in this extension they are lower bounds. However, OpenGL 331 now specifies a number of formats as being "required" in the 332 same sense of a lower bound on precision, and the token values 333 are not changed. 334 335New Procedures and Functions 336 337 None. 338 339New Types 340 341 None. 342 343New Tokens 344 345 Accepted by the <internalformat> argument of TexImage2D, TexImage3DOES, and 346 CopyTexImage2D: 347 348 ALPHA8_OES 0x803C 349 LUMINANCE8_OES 0x8040 350 LUMINANCE8_ALPHA8_OES 0x8045 351 LUMINANCE4_ALPHA4_OES 0x8043 352 RGB565_OES 0x8D62 353 RGB8_OES 0x8051 354 RGBA4_OES 0x8056 355 RGB5_A1_OES 0x8057 356 RGBA8_OES 0x8058 357 DEPTH_COMPONENT16_OES 0x81A5 358 DEPTH_COMPONENT24_OES 0x81A6 359 DEPTH_COMPONENT32_OES 0x81A7 360 DEPTH24_STENCIL8_OES 0x88F0 361 RGB10_EXT 0x8052 362 RGB10_A2_EXT 0x8059 363 364 Accepted by the <internalformat> argument of RenderbufferStorageOES: 365 366 RGBA8_OES 0x8058 367 368Additions to Chapter 2 of the OpenGL ES 1.1 Specification (OpenGL ES Operation) 369 370 None. 371 372Additions to Chapter 3 of the OpenGL ES 1.1 Specification (Rasterization) 373 374 In section 3.6.2 ("Unpacking"), p.69 (p. 60/61 of ES 2.0 spec), modify 375 Table 3.4 and replace the preceding paragraph as follows: 376 377 378 Format Type External Bytes per Pixel Internal format 379 ------ ---- ------------------------ --------------- 380 RGBA UNSIGNED_INT_2_10_10_10_REV_EXT 4 RGBA, RGB10_A2_EXT, RGB5_A1 381 RGBA UNSIGNED_BYTE 4 RGBA, RGBA8, RGB5_A1, RGBA4 382 RGB UNSIGNED_INT_2_10_10_10_REV_EXT 4 RGB, RGB10_EXT, RGB8, RGB565 383 RGB UNSIGNED_BYTE 3 RGB, RGB8, RGB565 384 RGBA UNSIGNED_SHORT_4_4_4_4 2 RGBA, RGBA4 385 RGBA UNSIGNED_SHORT_5_5_5_1 2 RGBA, RGB5_A1 386 RGB UNSIGNED_SHORT_5_6_5 2 RGB, RGB565 387 LUMINANCE_ALPHA UNSIGNED_BYTE 2 LUMINANCE_ALPHA, LUMINANCE8_ALPHA8, LUMINANCE4_ALPHA4 388 LUMINANCE UNSIGNED_BYTE 1 LUMINANCE, LUMINANCE8 389 ALPHA UNSIGNED_BYTE 1 ALPHA, ALPHA8 390 DEPTH_COMPONENT UNSIGNED_SHORT 2 DEPTH_COMPONENT, DEPTH_COMPONENT16_OES 391 DEPTH_COMPONENT UNSIGNED_INT 4 DEPTH_COMPONENT, DEPTH_COMPONENT32_OES, DEPTH_COMPONENT24_OES, DEPTH_COMPONENT16_OES 392 DEPTH_STENCIL_OES UNSIGNED_INT_24_8_OES 4 DEPTH_STENCIL_OES, DEPTH24_STENCIL8_OES 393 394 Table 3.4: Valid combinations of <format>, <type>, and 395 <internalformat> for TexImage2D and TexImage3DOES 396 397 When calling TexImage2D or TexImage3DOES, not all combinations of 398 <format>, <type>, and <internalformat> are valid. The valid 399 combinations accepted by the GL are defined in Table 3.4. If TexImage2D 400 or TexImage3DOES is called with a combination of <format>, <type>, and 401 <internalformat> not listed in Table 3.4, then INVALID_OPERATION is 402 generated. 403 404 In addition, only certain values for <internalformat> are valid when 405 calling RenderbufferStorageOES and CopyTexImage2D. The valid values of 406 <internalformat> are listed in Tables 3.4.x and 3.4.y. If 407 RenderbufferStorageOES is called with a value of <internalformat> not 408 listed in Table 3.4.x then INVALID_ENUM is generated. Similarly, if 409 CopyTexImage2D is called with a value of <internalformat> not listed in 410 Table 3.4.y, then INVALID_ENUM is generated. 411 412 Internal format 413 --------------- 414 RGBA4_OES 415 RGB5_A1_OES 416 RGBA8_OES 417 RGB565_OES 418 RGB8_OES 419 STENCIL_INDEX1_OES 420 STENCIL_INDEX4_OES 421 STENCIL_INDEX8_OES 422 DEPTH_COMPONENT16_OES 423 DEPTH_COMPONENT24_OES 424 DEPTH_COMPONENT32_OES 425 DEPTH24_STENCIL8_OES 426 427 Table 3.4.x: Legal values of <internalformat> for 428 RenderbufferStorageOES 429 430 Internal format 431 --------------- 432 RGBA 433 RGBA4_OES 434 RGB5_A1_OES 435 RGBA8_OES 436 RGB10_A2_EXT 437 RGB 438 RGB565_OES 439 RGB8_OES 440 RGB10_EXT 441 LUMINANCE_ALPHA 442 LUMINANCE4_ALPHA4_OES 443 LUMINANCE8_ALPHA8_OES 444 LUMINANCE 445 LUMINANCE8_OES 446 ALPHA 447 ALPHA8_OES 448 449 Table 3.4.y: Legal values of <internalformat> for CopyTexImage2D 450 451 An implementation must accept all of the values for <internalformat> 452 specified in Tables 3.4, 3.4.x, 3.4.y. Furthermore, an implementation 453 must respect the minimum precision requirements of sized internal 454 formats -- those with explicit component resolutions -- by storing each 455 component with at least the number of bits prescribed. 456 457 If one of the base "unsized" formats (RGBA, RGB, LUMINANCE_ALPHA, 458 LUMINANCE, ALPHA, DEPTH_COMPONENT, or DEPTH_STENCIL_OES) is specified 459 for <internalformat> to TexImage2D, TexImage3DOES, or CopyTexImage2D, 460 the GL is free to choose the precision that it will maintain for the 461 texture. ES implementations are still encouraged, however, to maintain 462 as much precision as possible, given the source arguments to those 463 commands. 464 465 In section 3.7.9 (3.7.10 for ES 2.0), update the definition of texture 466 completeness (and cube completeness for ES 2.0 or in the presence of 467 OES_texture_cube_map) to read: 468 469 "... were each specified with the same format, type, and internal 470 format." 471 472Additions to Chapter 4 of the OpenGL ES 1.1 Specification (Per-Fragment 473Operations and the Frame Buffer) 474 475 None. 476 477Additions to Chapter 5 of the OpenGL ES 1.1 Specification (Special Functions) 478 479 None. 480 481Additions to Chapter 6 of the OpenGL ES 1.1 Specification (State and State 482Requests) 483 484 None. 485 486Additions to Appendix A of the OpenGL ES 1.1 Specification (Invariance) 487 488 None. 489 490Additions to the AGL/EGL/GLX/WGL Specifications 491 492 None. 493 494GLX Protocol 495 496 XXX TBD 497 498Errors 499 500 If TexImage2D or TexImage3DOES is called with a combination of <format>, 501 <type>, and <internalformat> not listed in Table 3.4, then INVALID_OPERATION 502 is generated. 503 504 If RenderbufferStorageOES or CopyTexImage2D is called with a value of 505 <internalformat> not listed in Table 3.4.x or 3.4.y, respectively, then 506 INVALID_ENUM is generated. 507 508New State 509 510 None. 511 512New Implementation Dependent State 513 514 None. 515 516Dependencies on OpenGL ES 2.0 517 518 If OpenGL ES 2.0 is supported, the following tokens do not have the 519 "_OES" suffix: RGB565, RGBA4, RGB5_A1, DEPTH_COMPONENT16, STENCIL_INDEX8, 520 and RENDERBUFFER. Also, RenderbufferStorage does not have the "OES" suffix. 521 522Dependencies on OES_depth_texture 523 524 If OES_depth_texture is not supported, then all references to 525 DEPTH_COMPONENT as a legal value for <format> when calling TexImage2D and 526 TexImage3DOES should be deleted. 527 528Dependencies on OES_depth24 and OES_depth32 529 530 If OES_depth24 is not supported, then all references to 531 DEPTH_COMPONENT24_OES should be deleted. 532 533 If OES_depth32 is not supported, then all references to 534 DEPTH_COMPONENT32_OES should be deleted. 535 536Dependencies on OES_framebuffer_object 537 538 If OES_framebuffer_object is not supported and OpenGL ES 2.0 is not 539 supported, then all references to RENDERBUFFER_OES and renderbuffers should 540 be deleted, including Table 3.4.x. 541 542Dependencies on OES_packed_depth_stencil 543 544 If OES_packed_depth_stencil is not supported, then all references to 545 DEPTH_STENCIL_OES, DEPTH24_STENCIL8_OES, and UNSIGNED_INT_24_8_OES should be 546 deleted. 547 548Dependencies on OES_rgb8_rgba8 549 550 If OES_rgb8_rgba8 is not supported, then references to RGB8_OES as a 551 renderbuffer format in Table 3.4.x should be deleted. 552 553Dependencies on OES_stencil1, OES_stencil4, and OES_stencil8 554 555 If OES_stencil1 is not supported, then all references to STENCIL_INDEX1_OES 556 should be deleted. 557 558 If OES_stencil4 is not supported, then all references to STENCIL_INDEX4_OES 559 should be deleted. 560 561 If OES_stencil8 is not supported and OpenGL ES 2.0 is not supported, then 562 all references to STENCIL_INDEX8_OES should be deleted. 563 564Dependencies on OES_texture_3D 565 566 If OES_texture_3D is not supported, then all references to TexImage3DOES 567 should be deleted. 568 569Dependencies on EXT_texture_type_2_10_10_10_REV 570 571 If EXT_texture_type_2_10_10_10_REV is not supported, then all references to 572 RGB10_A2_EXT, RGB10_EXT, and UNSIGNED_INT_2_10_10_10_REV_EXT should be 573 deleted. 574 575Sample Code 576 577 // ==================================================================== 578 // Example 1: 579 // An application that requires support for RGBA with >= 8888 storage 580 // can indicate so by simply checking for the OES_required_internalformat 581 // extension string, since RGBA8_OES availability is a prerequisite. 582 // ==================================================================== 583 584 // First, check for presence of this extension. 585 bool reqSupportAvailable = 586 MyExtensionQuery("GL_OES_required_internalformat"); 587 if (!reqSupportAvailable) 588 { 589 printf("No support for GL_OES_required_internalformat!\n"); 590 exit(1); 591 } 592 593 // This texture is guaranteed to be stored with at least 8-bit per component 594 glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA8_OES, 32, 32, 0, 595 GL_RGBA, GL_UNSIGNED_BYTE, myTexelData); 596 597 // ==================================================================== 598 // Example 2: 599 // An application that requires support for DEPTH_COMPONENT with >= 32 bit 600 // storage can indicate so by checking for both OES_required_internalformat 601 // and OES_depth32 extension strings. That will guarantee minimum precision 602 // for 32-bit depth values stored in renderbuffers. If the application also 603 // needs 32-bit depth stored in textures, it can check for the 604 // OES_depth_texture extension, too. 605 // ==================================================================== 606 607 // First, check for presence of this extension. 608 bool reqSupportAvailable = CheckExtension("GL_OES_required_internalformat"); 609 if (!reqSupportAvailable) 610 { 611 printf("No support for GL_OES_required_internalformat.\n"); 612 printf("Minimum precision guarantees cannot be made!\n"); 613 exit(1); 614 } 615 616 // Now check for the presence of the depth32 extension. 617 bool depth32_available = CheckExtension("GL_OES_depth32"); 618 if (!depth32_available) 619 { 620 printf("No support for OES_depth32.\n"); 621 printf("32-bit depth renderbuffers not available!\n"); 622 exit(1); 623 } 624 625 // We're now guaranteed minimum 32-bit depth renderbuffers 626 glRenderbufferStorageOES(GL_RENDERBUFFER_OES, GL_DEPTH_COMPONENT32_OES, 627 32, 32); 628 629 // Now check for the presence of the depth texture extension. 630 bool depth_texture_available = CheckExtension("GL_OES_depth_texture"); 631 if (!depth_texture_available) 632 { 633 printf("No support for OES_depth_texture.\n"); 634 printf("32-bit depth textures not available!\n"); 635 exit(1); 636 } 637 638 // We're now guaranteed minimum 32-bit depth textures 639 glTexImage2D(GL_TEXTURE_2D, 0, GL_DEPTH_COMPONENT32_OES, 32, 32, 0, 640 GL_DEPTH_COMPONENT, GL_UNSIGNED_INT, myD32TexelData); 641 642Revision History 643 644 0.19, 01/29/2010, bmerry 645 - changed token values for six formats where they were different 646 from equivalent OpenGL tokens, and added issue 12 647 648 0.18, 11/26/2008, benj 649 - RGBA8 is mandated as a renderbuffer format, while RGB8 is only available 650 if OES_rgb8_rgba8 is present. 651 652 0.17, 11/19/2008, benj 653 - treat OES_rgb8_rgba8 as optional like other renderbuffer format extensions 654 - update Dependencies section 655 - assign enum values for new tokens 656 - fix minor typos 657 658 0.16, 11/03/2008, benj 659 - remove query mechanism since all sized internal formats have guaranteed 660 minimum precision today 661 - mention OES_rgb8_rgba8 requirement under Dependencies section 662 - remove more tokens introduced by other extensions from New Tokens 663 - update overview, issues list, and sample code 664 665 0.15, 10/29/2008, benj 666 - fix sample code bugs reported by Acorn 667 - firm up the definition of texture completeness, requested by Acorn 668 669 0.14, 10/29/2008, benj 670 - fix spec bug reported by Ben in New Tokens section: split up token list 671 - remove unrenderable RGB10_A2_EXT and RGB10_EXT formats from Table 3.4.x 672 - get rid of gl, GL, and GL_ prefixes 673 - switch query mechanism to new glIsRespectedInternalFormat 674 - update issues list and sample code 675 676 0.13, 10/28/2008, benj 677 - major overhaul 678 - remove double pointer from query command 679 - fix extension names for depth and stencil extensions 680 - sync up with latest 10/10/10/2 texture and depth texture extensions 681 - don't allow RGBA8 or RGBA4 internal formats for 10/10/10/2 textures 682 since that would require expanding the alpha channel 683 - add OES suffix to most tokens, EXT for 10/10/10/2 tokens 684 - remove tokens that aren't introduced by this extension from New Tokens 685 - add missing ALPHA8_OES and DEPTH_COMPONENT16_OES to New Tokens 686 - remove unsized formats from Table 3.4.x, add missing DEPTH_COMPONENT16 687 - remove L, A, and LA formats from Table 3.4.x and Table 3.6.x 688 RENDERBUFFER_OES section 689 - add interactions with ES 2.0 and OES_framebuffer_object 690 - change error for invalid combination of format/type/internalformat from 691 INVALID_ENUM to INVALID_OPERATION 692 - reformat for 80 columns 693 - update issues list and sample code 694 695 0.12, 02/27/2008, jsandmel 696 - added glGetSupportedInternalFormatsOES to new procedures section 697 - fixed typo in argument name for <internalformatlist> 698 699 0.11, 02/05/2008, jsandmel 700 - reworked API after the Portland F2F 701 - added query for supported internal formats 702 - updated section 3.6.2.1 on how the required list works 703 - added table 3.6.x for the list of required <internalformats> 704 - added a sample code example of the query for supported <internalformats> 705 - added dependency on packed depth stencil 706 707 0.10, 10/16/2007, jsandmel 708 - fixed several typos and non-ascii characters, no functional changes 709 710 0.9, 10/15/2007, jsandmel 711 - added issues 12 and 13 712 - included Acorn's suggestion for a query for supported formats that 713 respect the minimum precision guarantee 714 715 0.8, 05/27/2007, jsandmel 716 - added contributors section 717 - updated spec with recent group decisions 718 - added explicit dependencies on OES_stencil, OES_depth extensions 719 - split table 3.4.x into two tables: one for RenderbufferStorageOES 720 and one for CopyTexImage since you can create a depth/stencil 721 renderbuffer but not texture. 722 723 0.7, 05/21/2007, jsandmel 724 - updated spec with recent group decisions 725 - removed concept of "optionally supported" extensions 726 - added second table for RenderBuffer storage 727 728 0.6, 05/03/2007, jsandmel 729 - fixed some typos refering to OpenGL 1.5 spec that should be ES 1.1 spec 730 731 0.5, 4/28/2007, jsandmel 732 - changed a few more references to LUMINANCE/ALPHA instead of L/A 733 - also clarified overview wrt to required <internalformat> semantics 734 735 0.4, 4/25/2007, jsandmel 736 - corrected table 3.4 and 3.4x to use LUMINANCE/ALPHA instead of L/A 737 738 0.3, 4/24/2007, jsandmel 739 - added issue 5 to discuss whether we should move all the "optionally 740 supported" <internalformat> values to their own extensions 741 742 0.2, 4/24/2007, jsandmel 743 - fixed up a few typos and lingering references to UNPACK state 744 745 0.1, 4/23/2007, jsandmel 746 - switch to start using <internalformat> instead of adding a new 747 UNPACK parameter. 748 749 0.0, 4/17/2007, jsandmel 750 - initial revision 751