1Name 2 3 OES_texture_compression_astc 4 5Name Strings 6 7 GL_OES_texture_compression_astc 8 GL_KHR_texture_compression_astc_hdr 9 GL_KHR_texture_compression_astc_ldr 10 11Contact 12 13 Sean Ellis (sean.ellis 'at' arm.com) 14 15Contributors 16 17 Sean Ellis, ARM 18 Jorn Nystad, ARM 19 Tom Olson, ARM 20 Andy Pomianowski, AMD 21 Cass Everitt, NVIDIA 22 Walter Donovan, NVIDIA 23 Robert Simpson, Qualcomm 24 Maurice Ribble, Qualcomm 25 Larry Seiler, Intel 26 Daniel Koch, Transgaming 27 Anthony Wood, Imagination Technologies 28 Andrew Garrard, Samsung 29 30Notice 31 32 Copyright (c) 2013-2016 The Khronos Group Inc. Copyright terms at 33 http://www.khronos.org/registry/speccopyright.html 34 35Specification Update Policy 36 37 Khronos-approved extension specifications are updated in response to 38 issues and bugs prioritized by the Khronos OpenGL ES Working Group. For 39 extensions which have been promoted to a core Specification, fixes will 40 first appear in the latest version of that core Specification, and will 41 eventually be backported to the extension document. This policy is 42 described in more detail at 43 https://www.khronos.org/registry/OpenGL/docs/update_policy.php 44 45IP Status 46 47 No known issues. 48 49Status 50 51 Ratified by the Khronos Board of Promoters, 27 September 2013 52 53Version 54 55 Last Modified Date: July 20, 2016 56 57Number 58 59 OpenGL ES Extension #162 60 61Dependencies 62 63 Written based on the wording of the OpenGL ES 3.0 specification 64 65Overview 66 67 Adaptive Scalable Texture Compression (ASTC) is a new texture 68 compression technology that offers unprecendented flexibility, 69 while producing better or comparable results than existing texture 70 compressions at all bit rates. It includes support for 2D and 3D 71 textures, with low and high dynamic range, at bitrates from below 72 1 bit/pixel up to 8 bits/pixel in fine steps. 73 74 The goal of this extension is to support the full profile of the 75 ASTC texture compression specification. 76 77 ASTC-compressed textures are handled in OpenGL ES and OpenGL by 78 adding new supported formats to the existing mechanisms for handling 79 compressed textures. 80 81Issues 82 83Interactions with Other Extensions 84 85 EXT_texture_storage affects the definition of this extension. 86 87 Extends extension KHR_texture_compression_astc_ldr and 88 KHR_texture_compression_astc_hdr. 89 90Interactions with OpenGL 4.2 91 92 OpenGL 4.2 supports the feature that compressed textures can be 93 compressed online, by passing the compressed texture format enum as 94 the internal format when uploading a texture using TexImage1D, 95 TexImage2D or TexImage3D (see Section 3.9.3, Texture Image 96 Specification, subsection Encoding of Special Internal Formats). 97 98 Due to the complexity of the ASTC compression algorithm, it is not 99 usually suitable for online use, and therefore ASTC support will be 100 limited to pre-compressed textures only. Where on-device compression 101 is required, a domain-specific limited compressor will typically 102 be used, and this is therefore not suitable for implementation in 103 the driver. 104 105 In particular, the ASTC format specifiers will not be added to 106 Table 3.14, and thus will not be accepted by the TexImage*D 107 functions, and will not be returned by the (already deprecated) 108 COMPRESSED_TEXTURE_FORMATS query. 109 110New Procedures and Functions 111 112 None 113 114New Tokens 115 116 Accepted by the <format> parameter of CompressedTexSubImage2D, and 117 by the <internalformat> parameter of CompressedTexImage2D, TexStorage2D, 118 TextureStorage2D, TexStorage3D, and TextureStorage3D: 119 120 COMPRESSED_RGBA_ASTC_4x4_KHR 0x93B0 121 COMPRESSED_RGBA_ASTC_5x4_KHR 0x93B1 122 COMPRESSED_RGBA_ASTC_5x5_KHR 0x93B2 123 COMPRESSED_RGBA_ASTC_6x5_KHR 0x93B3 124 COMPRESSED_RGBA_ASTC_6x6_KHR 0x93B4 125 COMPRESSED_RGBA_ASTC_8x5_KHR 0x93B5 126 COMPRESSED_RGBA_ASTC_8x6_KHR 0x93B6 127 COMPRESSED_RGBA_ASTC_8x8_KHR 0x93B7 128 COMPRESSED_RGBA_ASTC_10x5_KHR 0x93B8 129 COMPRESSED_RGBA_ASTC_10x6_KHR 0x93B9 130 COMPRESSED_RGBA_ASTC_10x8_KHR 0x93BA 131 COMPRESSED_RGBA_ASTC_10x10_KHR 0x93BB 132 COMPRESSED_RGBA_ASTC_12x10_KHR 0x93BC 133 COMPRESSED_RGBA_ASTC_12x12_KHR 0x93BD 134 135 COMPRESSED_SRGB8_ALPHA8_ASTC_4x4_KHR 0x93D0 136 COMPRESSED_SRGB8_ALPHA8_ASTC_5x4_KHR 0x93D1 137 COMPRESSED_SRGB8_ALPHA8_ASTC_5x5_KHR 0x93D2 138 COMPRESSED_SRGB8_ALPHA8_ASTC_6x5_KHR 0x93D3 139 COMPRESSED_SRGB8_ALPHA8_ASTC_6x6_KHR 0x93D4 140 COMPRESSED_SRGB8_ALPHA8_ASTC_8x5_KHR 0x93D5 141 COMPRESSED_SRGB8_ALPHA8_ASTC_8x6_KHR 0x93D6 142 COMPRESSED_SRGB8_ALPHA8_ASTC_8x8_KHR 0x93D7 143 COMPRESSED_SRGB8_ALPHA8_ASTC_10x5_KHR 0x93D8 144 COMPRESSED_SRGB8_ALPHA8_ASTC_10x6_KHR 0x93D9 145 COMPRESSED_SRGB8_ALPHA8_ASTC_10x8_KHR 0x93DA 146 COMPRESSED_SRGB8_ALPHA8_ASTC_10x10_KHR 0x93DB 147 COMPRESSED_SRGB8_ALPHA8_ASTC_12x10_KHR 0x93DC 148 COMPRESSED_SRGB8_ALPHA8_ASTC_12x12_KHR 0x93DD 149 150 If extension "EXT_texture_storage" is supported, these tokens are also 151 accepted by TexStorage2DEXT, TextureStorage2DEXT, TexStorage3DEXT and 152 TextureStorage3DEXT. 153 154 Accepted by the <format> parameter of CompressedTexSubImage3D, and 155 by the <internalformat> parameter of CompressedTexImage3D, TexStorage3D, 156 and TextureStorage3D: 157 158 COMPRESSED_RGBA_ASTC_3x3x3_OES 0x93C0 159 COMPRESSED_RGBA_ASTC_4x3x3_OES 0x93C1 160 COMPRESSED_RGBA_ASTC_4x4x3_OES 0x93C2 161 COMPRESSED_RGBA_ASTC_4x4x4_OES 0x93C3 162 COMPRESSED_RGBA_ASTC_5x4x4_OES 0x93C4 163 COMPRESSED_RGBA_ASTC_5x5x4_OES 0x93C5 164 COMPRESSED_RGBA_ASTC_5x5x5_OES 0x93C6 165 COMPRESSED_RGBA_ASTC_6x5x5_OES 0x93C7 166 COMPRESSED_RGBA_ASTC_6x6x5_OES 0x93C8 167 COMPRESSED_RGBA_ASTC_6x6x6_OES 0x93C9 168 169 COMPRESSED_SRGB8_ALPHA8_ASTC_3x3x3_OES 0x93E0 170 COMPRESSED_SRGB8_ALPHA8_ASTC_4x3x3_OES 0x93E1 171 COMPRESSED_SRGB8_ALPHA8_ASTC_4x4x3_OES 0x93E2 172 COMPRESSED_SRGB8_ALPHA8_ASTC_4x4x4_OES 0x93E3 173 COMPRESSED_SRGB8_ALPHA8_ASTC_5x4x4_OES 0x93E4 174 COMPRESSED_SRGB8_ALPHA8_ASTC_5x5x4_OES 0x93E5 175 COMPRESSED_SRGB8_ALPHA8_ASTC_5x5x5_OES 0x93E6 176 COMPRESSED_SRGB8_ALPHA8_ASTC_6x5x5_OES 0x93E7 177 COMPRESSED_SRGB8_ALPHA8_ASTC_6x6x5_OES 0x93E8 178 COMPRESSED_SRGB8_ALPHA8_ASTC_6x6x6_OES 0x93E9 179 180 If extension "EXT_texture_storage" is supported, these tokens are also 181 accepted by TexStorage3DEXT and TextureStorage3DEXT. 182 183Additions to Chapter 2 of the OpenGL ES 3.0 Specification (OpenGL ES 184Operation) 185 186 None 187 188Additions to Chapter 3 of the OpenGL ES 3.0 Specification (Rasterization) 189 190 Added to Section 3.8.6, Compressed Texture Images 191 192 Add the tokens specified above to Table 3.16, Compressed Internal Formats. 193 In all cases, the base internal format will be RGBA. The encoding allows 194 images to be encoded with fewer channels, but this is always presented as 195 RGBA to the sampler. 196 197 After the paragraph discussing ETC2/EAC formats, add: 198 199 "If internalformat is one of the ASTC formats described in table 3.16, 200 the compressed image data is stored using one of the ASTC compressed 201 texture image encodings (see appendix C). The ASTC texture compression 202 algorithm supports both two- and three-dimensional images. If 203 internalformat is a 2D ASTC format, CompressedTexImage3D will accept an 204 array of compressed data consisting of multiple rows of compressed 205 blocks laid out as described in Section 3.8.3. If 206 internalformat is a 3D ASTC format, CompressedTexImage2D will generate 207 an INVALID_OPERATION error. If internalformat is a 3D ASTC format, 208 and only the ASTC LDR or HDR Profile is supported, then 209 CompressedTexImage3D will also generate an INVALID_OPERATION error." 210 211 At the end of the section, add: 212 213 "If internalformat is one of the ASTC formats described in table 3.16, the 214 texture is stored using one of the ASTC compressed texture image 215 encodings (see appendix C). Since ASTC images are easily edited along 216 block footprint boundaries, the limitations on subimage location and size 217 are as follows for CompressedTexSubImage2D and CompressedTexSubImage3D. 218 These commands will result in an INVALID_OPERATION error if one of the 219 following conditions occurs: 220 * width is not a multiple of the block width, and width + xoffset is not 221 equal to the width of the texture level. 222 * height is not a multiple of block height, and height+yoffset is not 223 equal to the height of the texture level. 224 * depth is not a multiple of block depth, and depth+zoffset is not 225 equal to the depth of the texture level. (If a 3D image is constructed 226 from 2D slices, the block depth is treated as 1.) 227 * xoffset, yoffset or zoffset is not a multiple of the corresponding 228 block dimension. 229 The contents of any block of texels of an ASTC compressed texture 230 image that does not intersect the area being modified are preserved 231 during valid CompressedTexSubImage* calls. 232 233 The block width, height and depth for each ASTC format are determined 234 according to Table 3.17: 235 236 -------------------------------------------------------------- 237 Block 238 Compressed Internal Format Width Height Depth 239 -------------------------------------------------------------- 240 COMPRESSED_RGBA_ASTC_4x4_KHR 4 4 241 COMPRESSED_RGBA_ASTC_5x4_KHR 5 4 242 COMPRESSED_RGBA_ASTC_5x5_KHR 5 5 243 COMPRESSED_RGBA_ASTC_6x5_KHR 6 5 244 COMPRESSED_RGBA_ASTC_6x6_KHR 6 6 245 COMPRESSED_RGBA_ASTC_8x5_KHR 8 5 246 COMPRESSED_RGBA_ASTC_8x6_KHR 8 6 247 COMPRESSED_RGBA_ASTC_8x8_KHR 8 8 248 COMPRESSED_RGBA_ASTC_10x5_KHR 10 5 249 COMPRESSED_RGBA_ASTC_10x6_KHR 10 6 250 COMPRESSED_RGBA_ASTC_10x8_KHR 10 8 251 COMPRESSED_RGBA_ASTC_10x10_KHR 10 10 252 COMPRESSED_RGBA_ASTC_12x10_KHR 12 10 253 COMPRESSED_RGBA_ASTC_12x12_KHR 12 12 254 255 COMPRESSED_SRGB8_ALPHA8_ASTC_4x4_KHR 4 4 256 COMPRESSED_SRGB8_ALPHA8_ASTC_5x4_KHR 5 4 257 COMPRESSED_SRGB8_ALPHA8_ASTC_5x5_KHR 5 5 258 COMPRESSED_SRGB8_ALPHA8_ASTC_6x5_KHR 6 5 259 COMPRESSED_SRGB8_ALPHA8_ASTC_6x6_KHR 6 6 260 COMPRESSED_SRGB8_ALPHA8_ASTC_8x5_KHR 8 5 261 COMPRESSED_SRGB8_ALPHA8_ASTC_8x6_KHR 8 6 262 COMPRESSED_SRGB8_ALPHA8_ASTC_8x8_KHR 8 8 263 COMPRESSED_SRGB8_ALPHA8_ASTC_10x5_KHR 10 5 264 COMPRESSED_SRGB8_ALPHA8_ASTC_10x6_KHR 10 6 265 COMPRESSED_SRGB8_ALPHA8_ASTC_10x8_KHR 10 8 266 COMPRESSED_SRGB8_ALPHA8_ASTC_10x10_KHR 10 10 267 COMPRESSED_SRGB8_ALPHA8_ASTC_12x10_KHR 12 10 268 COMPRESSED_SRGB8_ALPHA8_ASTC_12x12_KHR 12 12 269 270 COMPRESSED_RGBA_ASTC_3x3x3_OES 3 3 3 271 COMPRESSED_RGBA_ASTC_4x3x3_OES 4 3 3 272 COMPRESSED_RGBA_ASTC_4x4x3_OES 4 4 3 273 COMPRESSED_RGBA_ASTC_4x4x4_OES 4 4 4 274 COMPRESSED_RGBA_ASTC_5x4x4_OES 5 4 4 275 COMPRESSED_RGBA_ASTC_5x5x4_OES 5 5 4 276 COMPRESSED_RGBA_ASTC_5x5x5_OES 5 5 5 277 COMPRESSED_RGBA_ASTC_6x5x5_OES 6 5 5 278 COMPRESSED_RGBA_ASTC_6x6x5_OES 6 6 5 279 COMPRESSED_RGBA_ASTC_6x6x6_OES 6 6 6 280 281 COMPRESSED_SRGB8_ALPHA8_ASTC_3x3x3_OES 3 3 3 282 COMPRESSED_SRGB8_ALPHA8_ASTC_4x3x3_OES 4 3 3 283 COMPRESSED_SRGB8_ALPHA8_ASTC_4x4x3_OES 4 4 3 284 COMPRESSED_SRGB8_ALPHA8_ASTC_4x4x4_OES 4 4 4 285 COMPRESSED_SRGB8_ALPHA8_ASTC_5x4x4_OES 5 4 4 286 COMPRESSED_SRGB8_ALPHA8_ASTC_5x5x4_OES 5 5 4 287 COMPRESSED_SRGB8_ALPHA8_ASTC_5x5x5_OES 5 5 5 288 COMPRESSED_SRGB8_ALPHA8_ASTC_6x5x5_OES 6 5 5 289 COMPRESSED_SRGB8_ALPHA8_ASTC_6x6x5_OES 6 6 5 290 COMPRESSED_SRGB8_ALPHA8_ASTC_6x6x6_OES 6 6 6 291 -------------------------------------------------------------- 292 293 Table 3.17: Compressed ASTC Format Block Sizes" 294 295 Added to Section 3.8.15: 296 297 The list of converted internal formats at the start of this section must 298 be expanded to include all of the COMPRESSED_SRGB8_ALPHA8_ASTC_*_KHR and 299 COMPRESSED_SRGB8_ALPHA8_ASTC_*_OES formats. 300 301Additions to Chapter 4 of the OpenGL ES 3.0 Specification (Per-Fragment 302 Operations and the Framebuffer) 303 304 None 305 306Additions to Chapter 5 of the OpenGL ES 3.0 Specification (Special Functions) 307 308 None 309 310Additions to Chapter 6 of the OpenGL ES 3.0 Specification (State and 311 State Requests) 312 313 None 314 315Additions to Appendix A of the OpenGL ES 3.0 Specification (Invariance) 316 317 None 318 319Additions to Appendix B of the OpenGL ES 3.0 Specification (Corollaries) 320 321 None 322 323Additions to Appendix C of the OpenGL ES 3.0 Specification (Compressed 324 Texture Image Formats) 325 326 Add a new sub-section on ASTC image formats, as follows: 327 328 C.2 ASTC Compressed Texture Image Formats 329 ========================================= 330 331 C.2.1 What is ASTC? 332 --------------------- 333 334 ASTC stands for Adaptive Scalable Texture Compression. 335 The ASTC formats form a family of related compressed texture image 336 formats. They are all derived from a common set of definitions. 337 338 ASTC textures may be either 2D or 3D. 339 340 ASTC textures may be encoded using either high or low dynamic range. 341 Low dynamic range images may optionally be specified using the sRGB 342 color space for the RGB channels. 343 344 Two sub-profiles ("LDR Profile" and "HDR Profile") may be implemented, 345 which support only 2D images at low or high dynamic range respectively. 346 The LDR profile is indicated by the presence of only the extension 347 string "GL_KHR_texture_compression_astc_ldr". If the HDR profile is 348 implemented, both "GL_KHR_texture_compression_astc_ldr" 349 and "GL_KHR_texture_compression_astc_hdr" must be published. If the full 350 profile (including 3D textures) is implemented, then all three extension 351 strings "GL_KHR_texture_compression_astc_ldr", 352 "GL_KHR_texture_compression_astc_hdr" 353 and "GL_OES_texture_compression_astc" must be published. 354 355 ASTC textures may be encoded as 1, 2, 3 or 4 components, but they are 356 all decoded into RGBA. 357 358 ASTC has a variable block size, and this is specified as part of the 359 name of the token passed to CompressedImage2D and its related functions. 360 361 C.2.2 Design Goals 362 -------------------- 363 364 The design goals for the format are as follows: 365 366 * Random access. This is a must for any texture compression format. 367 * Bit exact decode. This is a must for conformance testing and 368 reproducibility. 369 * Suitable for mobile use. The format should be suitable for both 370 desktop and mobile GPU environments. It should be low bandwidth 371 and low in area. 372 * Flexible choice of bit rate. Current formats only offer a few bit 373 rates, leaving content developers with only coarse control over 374 the size/quality tradeoff. 375 * Scalable and long-lived. The format should support existing R, RG, 376 RGB and RGBA image types, and also have high "headroom", allowing 377 continuing use for several years and the ability to innovate in 378 encoders. Part of this is the choice to include HDR and 3D. 379 * Feature orthogonality. The choices for the various features of the 380 format are all orthogonal to each other. This has three effects: 381 first, it allows a large, flexible configuration space; second, 382 it makes that space easier to understand; and third, it makes 383 verification easier. 384 * Best in class at given bit rate. It should beat or match the current 385 best in class for peak signal-to-noise ratio (PSNR) at all bit rates. 386 * Fast decode. Texel throughput for a cached texture should be one 387 texel decode per clock cycle per decoder. Parallel decoding of several 388 texels from the same block should be possible at incremental cost. 389 * Low bandwidth. The encoding scheme should ensure that memory access 390 is kept to a minimum, cache reuse is high and memory bandwidth for 391 the format is low. 392 * Low area. It must occupy comparable die size to competing formats. 393 394 C.2.3 Basic Concepts 395 ---------------------- 396 397 ASTC is a block-based lossy compression format. The compressed image 398 is divided into a number of blocks of uniform size, which makes it 399 possible to quickly determine which block a given texel resides in. 400 401 Each block has a fixed memory footprint of 128 bits, but these bits 402 can represent varying numbers of texels (the block "footprint"). 403 404 Block footprint sizes are not confined to powers-of-two, and are 405 also not confined to be square. They may be 2D, in which case the 406 block dimensions range from 4 to 12 texels, or 3D, in which case 407 the block dimensions range from 3 to 6 texels. 408 409 Decoding one texel requires only the data from a single block. This 410 simplifies cache design, reduces bandwidth and improves encoder throughput. 411 412 C.2.4 Block Encoding 413 ---------------------- 414 415 To understand how the blocks are stored and decoded, it is useful to start 416 with a simple example, and then introduce additional features. 417 418 The simplest block encoding starts by defining two color "endpoints". The 419 endpoints define two colors, and a number of additional colors are generated 420 by interpolating between them. We can define these colors using 1, 2, 3, 421 or 4 components (usually corresponding to R, RG, RGB and RGBA textures), 422 and using low or high dynamic range. 423 424 We then store a color interpolant weight for each texel in the image, which 425 specifies how to calculate the color to use. From this, a weighted average 426 of the two endpoint colors is used to generate the intermediate color, 427 which is the returned color for this texel. 428 429 There are several different ways of specifying the endpoint colors, and the 430 weights, but once they have been defined, calculation of the texel colors 431 proceeds identically for all of them. Each block is free to choose whichever 432 encoding scheme best represents its color endpoints, within the constraint 433 that all the data fits within the 128 bit block. 434 435 For blocks which have a large number of texels (e.g. a 12x12 block), there is 436 not enough space to explicitly store a weight for every texel. In this case, 437 a sparser grid with fewer weights is stored, and interpolation is used to 438 determine the effective weight to be used for each texel position. This allows 439 very low bit rates to be used with acceptable quality. This can also be used 440 to more efficiently encode blocks with low detail, or with strong vertical 441 or horizontal features. 442 443 For blocks which have a mixture of disparate colors, a single line in the 444 color space is not a good fit to the colors of the pixels in the original 445 image. It is therefore possible to partition the texels into multiple sets, 446 the pixels within each set having similar colors. For each of these 447 "partitions", we specify separate endpoint pairs, and choose which pair of 448 endpoints to use for a particular texel by looking up the partition index 449 from a partitioning pattern table. In ASTC, this partition table is actually 450 implemented as a function. 451 452 The endpoint encoding for each partition is independent. 453 454 For blocks which have uncorrelated channels - for example an image with a 455 transparency mask, or an image used as a normal map - it may be necessary 456 to specify two weights for each texel. Interpolation between the components 457 of the endpoint colors can then proceed independently for each "plane" of 458 the image. The assignment of channels to planes is selectable. 459 460 Since each of the above options is independent, it is possible to specify any 461 combination of channels, endpoint color encoding, weight encoding, 462 interpolation, multiple partitions and single or dual planes. 463 464 Since these values are specified per block, it is important that they are 465 represented with the minimum possible number of bits. As a result, these 466 values are packed together in ways which can be difficult to read, but 467 which are nevertheless highly amenable to hardware decode. 468 469 All of the values used as weights and color endpoint values can be specified 470 with a variable number of bits. The encoding scheme used allows a fine- 471 grained tradeoff between weight bits and color endpoint bits using "integer 472 sequence encoding". This can pack adjacent values together, allowing us to 473 use fractional numbers of bits per value. 474 475 Finally, a block may be just a single color. This is a so-called "void 476 extent block" and has a special coding which also allows it to identify 477 nearby regions of single color. This may be used to short-circuit fetching of 478 what would be identical blocks, and further reduce memory bandwidth. 479 480 C.2.5 LDR and HDR Modes 481 ------------------------- 482 483 The decoding process for LDR content can be simplified if it is known in 484 advance that sRGB output is required. This selection is therefore included 485 as part of the global configuration. 486 487 The two modes differ in various ways. 488 489 ----------------------------------------------------------------------------- 490 Operation LDR Mode HDR Mode 491 ----------------------------------------------------------------------------- 492 Returned value Vector of FP16 values, Vector of FP16 values 493 or Vector of UNORM8 values. 494 495 sRGB compatible Yes No 496 497 LDR endpoint 16 bits, or 16 bits 498 decoding precision 8 bits for sRGB 499 500 HDR endpoint mode Error color As decoded 501 results 502 503 Error results Error color Vector of NaNs (0xFFFF) 504 ----------------------------------------------------------------------------- 505 Table C.2.1 - Differences Between LDR and HDR Modes 506 507 The error color is opaque fully-saturated magenta 508 (R,G,B,A = 0xFF, 0x00, 0xFF, 0xFF). This has been chosen as it is much more 509 noticeable than black or white, and occurs far less often in valid images. 510 511 For linear RGB decode, the error color may be either opaque fully-saturated 512 magenta (R,G,B,A = 1.0, 0.0, 1.0, 1.0) or a vector of four NaNs 513 (R,G,B,A = NaN, NaN, NaN, NaN). In the latter case, the recommended NaN 514 value returned is 0xFFFF. 515 516 The error color is returned as an informative response to invalid 517 conditions, including invalid block encodings or use of reserved endpoint 518 modes. 519 520 Future, forward-compatible extensions to OES_texture_compression_astc 521 may define valid interpretations of these conditions, which will decode to 522 some other color. Therefore, encoders and applications must not rely on 523 invalid encodings as a way of generating the error color. 524 525 C.2.6 Configuration Summary 526 ----------------------------- 527 528 The global configuration data for the format is as follows: 529 530 * Block dimension (2D or 3D) 531 * Block footprint size 532 * sRGB output enabled or not 533 534 The data specified per block is as follows: 535 536 * Texel weight grid size 537 * Texel weight range 538 * Texel weight values 539 * Number of partitions 540 * Partition pattern index 541 * Color endpoint modes (includes LDR or HDR selection) 542 * Color endpoint data 543 * Number of planes 544 * Plane-to-channel assignment 545 546 C.2.7 Decode Procedure 547 ------------------------ 548 549 To decode one texel: 550 (Optimization: If within known void-extent, immediately return single 551 color) 552 553 Find block containing texel 554 Read block mode 555 If void-extent block, store void extent and immediately return single 556 color 557 558 For each plane in image 559 If block mode requires infill 560 Find and decode stored weights adjacent to texel, unquantize and 561 interpolate 562 Else 563 Find and decode weight for texel, and unquantize 564 565 Read number of partitions 566 If number of partitions > 1 567 Read partition table pattern index 568 Look up partition number from pattern 569 570 Read color endpoint mode and endpoint data for selected partition 571 Unquantize color endpoints 572 Interpolate color endpoints using weight (or weights in dual-plane mode) 573 Return interpolated color 574 575 C.2.8 Block Determination and Bit Rates 576 The block footprint is a global setting for any given texture, and is 577 therefore not encoded in the individual blocks. 578 579 For 2D textures, the block footprint's width and height are selectable 580 from a number of predefined sizes, namely 4, 5, 6, 8, 10 and 12 pixels. 581 582 For square and nearly-square blocks, this gives the following bit rates: 583 584 ------------------------------------- 585 Footprint 586 Width Height Bit Rate Increment 587 ------------------------------------- 588 4 4 8.00 125% 589 5 4 6.40 125% 590 5 5 5.12 120% 591 6 5 4.27 120% 592 6 6 3.56 114% 593 8 5 3.20 120% 594 8 6 2.67 105% 595 10 5 2.56 120% 596 10 6 2.13 107% 597 8 8 2.00 125% 598 10 8 1.60 125% 599 10 10 1.28 120% 600 12 10 1.07 120% 601 12 12 0.89 602 ------------------------------------- 603 Table C.2.2 - 2D Footprint and Bit Rates 604 605 The block footprint is shown as width x height in the format enumerator, 606 so for example the enumerator COMPRESSED_RGBA_ASTC_8x6_KHR specifies an 607 image with a block width of 8 texels, and a block height of 6 texels. 608 609 The "Increment" column indicates the ratio of bit rate against the next 610 lower available rate. A consistent value in this column indicates an even 611 spread of bit rates. 612 613 For 3D textures, the block footprint's width, height and depth are 614 selectable from a number of predefined sizes, namely 3, 4, 5, and 6 pixels. 615 616 For cubic and near-cubic blocks, this gives the following bit rates: 617 618 ------------------------------------------- 619 Block Footprint 620 Width Height Depth Bit Rate Increment 621 ------------------------------------------- 622 3 3 3 4.74 133% 623 4 3 3 3.56 133% 624 4 4 3 2.67 133% 625 4 4 4 2.00 125% 626 5 4 4 1.60 125% 627 5 5 4 1.28 125% 628 5 5 5 1.02 120% 629 6 5 5 0.85 120% 630 6 6 5 0.71 120% 631 6 6 6 0.59 632 ------------------------------------------- 633 Table C.2.3 - 3D Footprint and Bit Rates 634 635 The block footprint is shown as width x height x depth in the format 636 enumerator, so for example the enumerator COMPRESSED_RGBA_ASTC_5x4x4_OES 637 specifies an image with a block width of 5 texels, a block height of 4 638 texels and a block depth of 4 texels. 639 640 The full profile supports only those block footprints listed in Tables 641 C.2.2 and C.2.3. Other block sizes are not supported. 642 643 For images which are not an integer multiple of the block size, additional 644 texels are added to the edges with maximum X and Y (and Z for 3D textures). 645 These texels may be any color, as they will not be accessed. 646 647 Although these are not all powers of two, it is possible to calculate block 648 addresses and pixel addresses within the block, for legal image sizes, 649 without undue complexity. 650 651 Given an image which is W x H x D pixels in size, with block size 652 w x h x d, the size of the image in blocks is: 653 654 Bw = ceiling(W/w) 655 Bh = ceiling(H/h) 656 Bd = ceiling(D/d) 657 658 For a 3D image built from 2D slices, each 2D slice is a single texel thick, 659 so that for an image which is W x H x D pixels in size, with block size 660 w x h, the size of the image in blocks is: 661 662 Bw = ceiling(W/w) 663 Bh = ceiling(H/h) 664 Bd = D 665 666 C.2.9 Block Layout 667 -------------------- 668 669 Each block in the image is stored as a single 128-bit block in memory. These 670 blocks are laid out in raster order, starting with the block at (0,0,0), then 671 ordered sequentially by X, Y and finally Z (if present). They are aligned to 672 128-bit boundaries in memory. 673 674 The bits in the block are labeled in little-endian order - the byte at the 675 lowest address contains bits 0..7. Bit 0 is the least significant bit in the 676 byte. 677 678 Each block has the same basic layout: 679 680 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 681 -------------------------------------------------------------- 682 | Texel Weight Data (variable width) Fill direction -> 683 -------------------------------------------------------------- 684 685 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 686 -------------------------------------------------------------- 687 Texel Weight Data 688 -------------------------------------------------------------- 689 690 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 691 -------------------------------------------------------------- 692 Texel Weight Data 693 -------------------------------------------------------------- 694 695 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 696 -------------------------------------------------------------- 697 Texel Weight Data 698 -------------------------------------------------------------- 699 700 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 701 -------------------------------------------------------------- 702 : More config data : 703 -------------------------------------------------------------- 704 705 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 706 -------------------------------------------------------------- 707 <-Fill direction Color Endpoint Data 708 -------------------------------------------------------------- 709 710 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 711 -------------------------------------------------------------- 712 : Extra configuration data 713 -------------------------------------------------------------- 714 715 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 716 -------------------------------------------------------------- 717 Extra | Part | Block mode | 718 -------------------------------------------------------------- 719 720 Table C.2.4 - Block Layout Overview 721 722 Dotted partition lines indicate that the split position is not fixed. 723 724 The "Block mode" field specifies how the Texel Weight Data is encoded. 725 726 The "Part" field specifies the number of partitions, minus one. If dual 727 plane mode is enabled, the number of partitions must be 3 or fewer. 728 If 4 partitions are specified, the error value is returned for all 729 texels in the block. 730 731 The size and layout of the extra configuration data depends on the 732 number of partitions, and the number of planes in the image, as follows 733 (only the bottom 32 bits are shown): 734 735 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 736 -------------------------------------------------------------- 737 <- Color endpoint data |CEM 738 -------------------------------------------------------------- 739 740 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 741 -------------------------------------------------------------- 742 CEM | 0 0 | Block Mode | 743 -------------------------------------------------------------- 744 745 Table C.2.5 - Single-partition Block Layout 746 747 CEM is the color endpoint mode field, which determines how the Color 748 Endpoint Data is encoded. 749 750 If dual-plane mode is active, the color component selector bits appear 751 directly below the weight bits. 752 753 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 754 -------------------------------------------------------------- 755 | CEM | Partition Index 756 -------------------------------------------------------------- 757 758 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 759 -------------------------------------------------------------- 760 Partition Index | Block Mode | 761 -------------------------------------------------------------- 762 763 Table C.2.6 - Multi-partition Block Layout 764 765 The Partition Index field specifies which partition layout to use. CEM is 766 the first 6 bits of color endpoint mode information for the various 767 partitions. For modes which require more than 6 bits of CEM data, the 768 additional bits appear at a variable position directly beneath the texel 769 weight data. 770 771 If dual-plane mode is active, the color component selector bits then appear 772 directly below the additional CEM bits. 773 774 The final special case is that if bits [8:0] of the block are "111111100", 775 then the block is a void-extent block, which has a separate encoding 776 described in section C.2.22. 777 778 C.2.10 Block Mode 779 ------------------ 780 781 The Block Mode field specifies the width, height and depth of the grid of 782 weights, what range of values they use, and whether dual weight planes are 783 present. Since some these are not represented using powers of two (there 784 are 12 possible weight widths, for example), and not all combinations are 785 allowed, this is not a simple bit packing. However, it can be unpacked 786 quickly in hardware. 787 788 The weight ranges are encoded using a 3 bit value R, which is interpreted 789 together with a precision bit H, as follows: 790 791 Low Precision Range (H=0) High Precision Range (H=1) 792R Weight Range Trits Quints Bits Weight Range Trits Quints Bits 793----------------------------------------------------------------------------- 794000 Invalid Invalid 795001 Invalid Invalid 796010 0..1 1 0..9 1 1 797011 0..2 1 0..11 1 2 798100 0..3 2 0..15 4 799101 0..4 1 0..19 1 2 800110 0..5 1 1 0..23 1 3 801111 0..7 3 0..31 5 802----------------------------------------------------------------------------- 803 Table C.2.7 - Weight Range Encodings 804 805 Each weight value is encoded using the specified number of Trits, Quints 806 and Bits. The details of this encoding can be found in Section C.3.12 - 807 Integer Sequence Encoding. 808 809 For 2D blocks, the Block Mode field is laid out as follows: 810 811 ------------------------------------------------------------------------- 812 10 9 8 7 6 5 4 3 2 1 0 Width Height Notes 813 ------------------------------------------------------------------------- 814 D H B A R0 0 0 R2 R1 B+4 A+2 815 D H B A R0 0 1 R2 R1 B+8 A+2 816 D H B A R0 1 0 R2 R1 A+2 B+8 817 D H 0 B A R0 1 1 R2 R1 A+2 B+6 818 D H 1 B A R0 1 1 R2 R1 B+2 A+2 819 D H 0 0 A R0 R2 R1 0 0 12 A+2 820 D H 0 1 A R0 R2 R1 0 0 A+2 12 821 D H 1 1 0 0 R0 R2 R1 0 0 6 10 822 D H 1 1 0 1 R0 R2 R1 0 0 10 6 823 B 1 0 A R0 R2 R1 0 0 A+6 B+6 D=0, H=0 824 x x 1 1 1 1 1 1 1 0 0 - - Void-extent 825 x x 1 1 1 x x x x 0 0 - - Reserved* 826 x x x x x x x 0 0 0 0 - - Reserved 827 ------------------------------------------------------------------------- 828 Table C.2.8 - 2D Block Mode Layout 829 830 Note that, due to the encoding of the R field, as described in the 831 previous page, bits R2 and R1 cannot both be zero, which disambiguates 832 the first five rows from the rest of the table. 833 834 Bit positions with a value of x are ignored for purposes of determining 835 if a block is a void-extent block or reserved, but may have defined 836 encodings for specific void-extent blocks. 837 838 The penultimate row of the table is reserved only if bits [5:2] are not 839 all 1, in which case it encodes a void-extent block (as shown in the 840 previous row). 841 842 For 3D blocks, the Block Mode field is laid out as follows: 843 844 ------------------------------------------------------------------------- 845 10 9 8 7 6 5 4 3 2 1 0 Width Height Depth Notes 846 ------------------------------------------------------------------------- 847 D H B A R0 C R2 R1 A+2 B+2 C+2 848 B 0 0 A R0 R2 R1 0 0 6 B+2 A+2 D=0, H=0 849 B 0 1 A R0 R2 R1 0 0 A+2 6 B+2 D=0, H=0 850 B 1 0 A R0 R2 R1 0 0 A+2 B+2 6 D=0, H=0 851 D H 1 1 0 0 R0 R2 R1 0 0 6 2 2 852 D H 1 1 0 1 R0 R2 R1 0 0 2 6 2 853 D H 1 1 1 0 R0 R2 R1 0 0 2 2 6 854 x x 1 1 1 1 1 1 1 0 0 - - - Void-extent 855 x x 1 1 1 1 x x x 0 0 - - - Reserved* 856 x x x x x x x 0 0 0 0 - - - Reserved 857 ------------------------------------------------------------------------ 858 Table C.2.9 - 3D Block Mode Layout 859 860 The D bit is set to indicate dual-plane mode. In this mode, the maximum 861 allowed number of partitions is 3. 862 863 The penultimate row of the table is reserved only if bits [4:2] are not 864 all 1, in which case it encodes a void-extent block (as shown in the 865 previous row). 866 867 The size of the grid in each dimension must be less than or equal to 868 the corresponding dimension of the block footprint. If the grid size 869 is greater than the footprint dimension in any axis, then this is an 870 illegal block encoding and all texels will decode to the error color. 871 872 C.2.11 Color Endpoint Mode 873 --------------------------- 874 875 In single-partition mode, the Color Endpoint Mode (CEM) field stores one 876 of 16 possible values. Each of these specifies how many raw data values 877 are encoded, and how to convert these raw values into two RGBA color 878 endpoints. They can be summarized as follows: 879 880 --------------------------------------------- 881 CEM Description Class 882 --------------------------------------------- 883 0 LDR Luminance, direct 0 884 1 LDR Luminance, base+offset 0 885 2 HDR Luminance, large range 0 886 3 HDR Luminance, small range 0 887 4 LDR Luminance+Alpha, direct 1 888 5 LDR Luminance+Alpha, base+offset 1 889 6 LDR RGB, base+scale 1 890 7 HDR RGB, base+scale 1 891 8 LDR RGB, direct 2 892 9 LDR RGB, base+offset 2 893 10 LDR RGB, base+scale plus two A 2 894 11 HDR RGB, direct 2 895 12 LDR RGBA, direct 3 896 13 LDR RGBA, base+offset 3 897 14 HDR RGB, direct + LDR Alpha 3 898 15 HDR RGB, direct + HDR Alpha 3 899 --------------------------------------------- 900 Table C.2.10 - Color Endpoint Modes 901 902 In multi-partition mode, the CEM field is of variable width, from 6 to 14 903 bits. The lowest 2 bits of the CEM field specify how the endpoint mode 904 for each partition is calculated: 905 906 ---------------------------------------------------- 907 Value Meaning 908 ---------------------------------------------------- 909 00 All color endpoint pairs are of the same type. 910 A full 4-bit CEM is stored in block bits [28:25] 911 and is used for all partitions. 912 01 All endpoint pairs are of class 0 or 1. 913 10 All endpoint pairs are of class 1 or 2. 914 11 All endpoint pairs are of class 2 or 3. 915 ---------------------------------------------------- 916 Table C.2.11 - Multi-Partition Color Endpoint Modes 917 918 If the CEM selector value in bits [24:23] is not 00, 919 then data layout is as follows: 920 921 Part n m l k j i h g 922 ------------------------------------------ 923 2 ... Weight : M1 : ... 924 ------------------------------------------ 925 3 ... Weight : M2 : M1 :M0 : ... 926 ------------------------------------------ 927 4 ... Weight : M3 : M2 : M1 : M0 : ... 928 ------------------------------------------ 929 930 Part 28 27 26 25 24 23 931 ---------------------- 932 2 | M0 |C1 |C0 | CEM | 933 ---------------------- 934 3 |M0 |C2 |C1 |C0 | CEM | 935 ---------------------- 936 4 |C3 |C2 |C1 |C0 | CEM | 937 ---------------------- 938 939 Table C.2.12 - Multi-Partition Color Endpoint Modes 940 941 In this view, each partition i has two fields. Ci is the class selector 942 bit, choosing between the two possible CEM classes (0 indicates the 943 lower of the two classes), and Mi is a two-bit field specifying the low 944 bits of the color endpoint mode within that class. The additional bits 945 appear at a variable bit position, immediately below the texel weight 946 data. 947 948 The ranges used for the data values are not explicitly specified. 949 Instead, they are derived from the number of available bits remaining 950 after the configuration data and weight data have been specified. 951 952 Details of the decoding procedure for Color Endpoints can be found in 953 section C.2.13. 954 955 C.2.12 Integer Sequence Encoding 956 --------------------------------- 957 958 Both the weight data and the endpoint color data are variable width, and 959 are specified using a sequence of integer values. The range of each 960 value in a sequence (e.g. a color weight) is constrained. 961 962 Since it is often the case that the most efficient range for these 963 values is not a power of two, each value sequence is encoded using a 964 technique known as "integer sequence encoding". This allows efficient, 965 hardware-friendly packing and unpacking of values with non-power-of-two 966 ranges. 967 968 In a sequence, each value has an identical range. The range is specified 969 in one of the following forms: 970 971 Value range MSB encoding LSB encoding 972 0 .. 2^n-1 - n bit value m (n <= 8) 973 0 .. (3 * 2^n)-1 Base-3 "trit" value t n bit value m (n <= 6) 974 0 .. (5 * 2^n)-1 Base-5 "quint" value q n bit value m (n <= 5) 975 976 Value range Value Block Packed block size 977 0 .. 2^n-1 m 1 n 978 0 .. (3 * 2^n)-1 t * 2^n + m 5 8 + 5*n 979 0 .. (5 * 2^n)-1 q * 2^n + m 3 7 + 3*n 980 981 Table C.2.13 -Encoding for Different Ranges 982 983 Since 3^5 is 243, it is possible to pack five trits into 8 bits(which has 984 256 possible values), so a trit can effectively be encoded as 1.6 bits. 985 Similarly, since 5^3 is 125, it is possible to pack three quints into 986 7 bits (which has 128 possible values), so a quint can be encoded as 987 2.33 bits. 988 989 The encoding scheme packs the trits or quints, and then interleaves the n 990 additional bits in positions that satisfy the requirements of an 991 arbitrary length stream. This makes it possible to correctly specify 992 lists of values whose length is not an integer multiple of 3 or 5 values. 993 It also makes it possible to easily select a value at random within the stream. 994 995 If there are insufficient bits in the stream to fill the final block, then 996 unused (higher order) bits are assumed to be 0 when decoding. 997 998 To decode the bits for value number i in a sequence of bits b, both 999 indexed from 0, perform the following: 1000 1001 If the range is encoded as n bits per value, then the value is bits 1002 b[i*n+n-1:i*n] - a simple multiplexing operation. 1003 1004 If the range is encoded using a trit, then each block contains 5 values 1005 (v0 to v4), each of which contains a trit (t0 to t4) and a corresponding 1006 LSB value (m0 to m4). The first bit of the packed block is bit 1007 floor(i/5)*(8+5*n). The bits in the block are packed as follows 1008 (in this example, n is 4): 1009 1010 27 26 25 24 23 22 21 20 19 18 17 16 1011 ----------------------------------------------- 1012 |T7 | m4 |T6 T5 | m3 |T4 | 1013 ----------------------------------------------- 1014 1015 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 1016 -------------------------------------------------------------- 1017 | m2 |T3 T2 | m1 |T1 T0 | m0 | 1018 -------------------------------------------------------------- 1019 1020 Table C.2.14 - Trit-based Packing 1021 1022 The five trits t0 to t4 are obtained by bit manipulations of the 8 bits 1023 T[7:0] as follows: 1024 1025 if T[4:2] = 111 1026 C = { T[7:5], T[1:0] }; t4 = t3 = 2 1027 else 1028 C = T[4:0] 1029 if T[6:5] = 11 1030 t4 = 2; t3 = T[7] 1031 else 1032 t4 = T[7]; t3 = T[6:5] 1033 1034 if C[1:0] = 11 1035 t2 = 2; t1 = C[4]; t0 = { C[3], C[2]&~C[3] } 1036 else if C[3:2] = 11 1037 t2 = 2; t1 = 2; t0 = C[1:0] 1038 else 1039 t2 = C[4]; t1 = C[3:2]; t0 = { C[1], C[0]&~C[1] } 1040 1041 If the range is encoded using a quint, then each block contains 3 values 1042 (v0 to v2), each of which contains a quint (q0 to q2) and a corresponding 1043 LSB value (m0 to m2). The first bit of the packed block is bit 1044 floor(i/3)*(7+3*n). 1045 1046 The bits in the block are packed as follows (in this example, n is 4): 1047 1048 18 17 16 1049 ----------- 1050 |Q6 Q5 | m2 1051 ----------- 1052 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 1053 --------------------------------------------------------------- 1054 m2 |Q4 Q3 | m1 |Q2 Q1 Q0 | m0 | 1055 --------------------------------------------------------------- 1056 1057 Table C.2.15 - Quint-based Packing 1058 1059 The three quints q0 to q2 are obtained by bit manipulations of the 7 bits 1060 Q[6:0] as follows: 1061 1062 if Q[2:1] = 11 and Q[6:5] = 00 1063 q2 = { Q[0], Q[4]&~Q[0], Q[3]&~Q[0] }; q1 = q0 = 4 1064 else 1065 if Q[2:1] = 11 1066 q2 = 4; C = { Q[4:3], ~Q[6:5], Q[0] } 1067 else 1068 q2 = Q[6:5]; C = Q[4:0] 1069 1070 if C[2:0] = 101 1071 q1 = 4; q0 = C[4:3] 1072 else 1073 q1 = C[4:3]; q0 = C[2:0] 1074 1075 Both these procedures ensure a valid decoding for all 128 possible values 1076 (even though a few are duplicates). They can also be implemented 1077 efficiently in software using small tables. 1078 1079 Encoding methods are not specified here, although table-based mechanisms 1080 work well. 1081 1082 C.2.13 Endpoint Unquantization 1083 ------------------------------- 1084 1085 Each color endpoint is specified as a sequence of integers in a given 1086 range. These values are packed using integer sequence encoding, as a 1087 stream of bits stored from just above the configuration data, and 1088 growing upwards. 1089 1090 Once unpacked, the values must be unquantized from their storage range, 1091 returning them to a standard range of 0..255. 1092 1093 For bit-only representations, this is simple bit replication from the 1094 most significant bit of the value. 1095 1096 For trit or quint-based representations, this involves a set of bit 1097 manipulations and adjustments to avoid the expense of full-width 1098 multipliers. This procedure ensures correct scaling, but scrambles 1099 the order of the decoded values relative to the encoded values. 1100 This must be compensated for using a table in the encoder. 1101 1102 The initial inputs to the procedure are denoted A (9 bits), B (9 bits), 1103 C (9 bits) and D (3 bits) and are decoded using the range as follows: 1104 1105 --------------------------------------------------------------- 1106 Range T Q B Bits A B C D 1107 --------------------------------------------------------------- 1108 0..5 1 1 a aaaaaaaaa 000000000 204 Trit value 1109 0..9 1 1 a aaaaaaaaa 000000000 113 Quint value 1110 0..11 1 2 ba aaaaaaaaa b000b0bb0 93 Trit value 1111 0..19 1 2 ba aaaaaaaaa b0000bb00 54 Quint value 1112 0..23 1 3 cba aaaaaaaaa cb000cbcb 44 Trit value 1113 0..39 1 3 cba aaaaaaaaa cb0000cbc 26 Quint value 1114 0..47 1 4 dcba aaaaaaaaa dcb000dcb 22 Trit value 1115 0..79 1 4 dcba aaaaaaaaa dcb0000dc 13 Quint value 1116 0..95 1 5 edcba aaaaaaaaa edcb000ed 11 Trit value 1117 0..159 1 5 edcba aaaaaaaaa edcb0000e 6 Quint value 1118 0..191 1 6 fedcba aaaaaaaaa fedcb000f 5 Trit value 1119 --------------------------------------------------------------- 1120 Table C.2.16 - Color Unquantization Parameters 1121 1122 These are then processed as follows: 1123 1124 T = D * C + B; 1125 T = T ^ A; 1126 T = (A & 0x80) | (T >> 2); 1127 1128 Note that the multiply in the first line is nearly trivial as it only 1129 needs to multiply by 0, 1, 2, 3 or 4. 1130 1131 C.2.14 LDR Endpoint Decoding 1132 ----------------------------- 1133 The decoding method used depends on the Color Endpoint Mode (CEM) field, 1134 which specifies how many values are used to represent the endpoint. 1135 1136 The CEM field also specifies how to take the n unquantized color endpoint 1137 values v0 to v[n-1] and convert them into two RGBA color endpoints e0 1138 and e1. 1139 1140 The HDR Modes are more complex and do not fit neatly into this section. 1141 They are documented in following section. 1142 1143 The methods can be summarized as follows. 1144 1145 ------------------------------------------------- 1146 CEM Range Description n 1147 ------------------------------------------------- 1148 0 LDR Luminance, direct 2 1149 1 LDR Luminance, base+offset 2 1150 2 HDR Luminance, large range 2 1151 3 HDR Luminance, small range 2 1152 4 LDR Luminance+Alpha, direct 4 1153 5 LDR Luminance+Alpha, base+offset 4 1154 6 LDR RGB, base+scale 4 1155 7 HDR RGB, base+scale 4 1156 8 LDR RGB, direct 6 1157 9 LDR RGB, base+offset 6 1158 10 LDR RGB, base+scale plus two A 6 1159 11 HDR RGB 6 1160 12 LDR RGBA, direct 8 1161 13 LDR RGBA, base+offset 8 1162 14 HDR RGB + LDR Alpha 8 1163 15 HDR RGB + HDR Alpha 8 1164 ------------------------------------------------- 1165 Table C.2.17 -Color Endpoint Modes 1166 1167 Mode 14 is special in that the alpha values are interpolated linearly, 1168 but the color components are interpolated logarithmically. This is the 1169 only endpoint format with mixed-mode operation, and will return the 1170 error value if encountered in LDR mode. 1171 1172 Decode the different LDR endpoint modes as follows: 1173 1174 Mode 0 LDR Luminance, direct 1175 1176 e0=(v0,v0,v0,0xFF); e1=(v1,v1,v1,0xFF); 1177 1178 Mode 1 LDR Luminance, base+offset 1179 1180 L0 = (v0>>2)|(v1&0xC0); L1=L0+(v1&0x3F); 1181 if (L1>0xFF) { L1=0xFF; } 1182 e0=(L0,L0,L0,0xFF); e1=(L1,L1,L1,0xFF); 1183 1184 Mode 4 LDR Luminance+Alpha,direct 1185 1186 e0=(v0,v0,v0,v2); 1187 e1=(v1,v1,v1,v3); 1188 1189 Mode 5 LDR Luminance+Alpha, base+offset 1190 1191 bit_transfer_signed(v1,v0); bit_transfer_signed(v3,v2); 1192 e0=(v0,v0,v0,v2); e1=(v0+v1,v0+v1,v0+v1,v2+v3); 1193 clamp_unorm8(e0); clamp_unorm8(e1); 1194 1195 Mode 6 LDR RGB, base+scale 1196 1197 e0=(v0*v3>>8,v1*v3>>8,v2*v3>>8, 0xFF); 1198 e1=(v0,v1,v2,0xFF); 1199 1200 Mode 8 LDR RGB, Direct 1201 1202 s0= v0+v2+v4; s1= v1+v3+v5; 1203 if (s1>=s0){e0=(v0,v2,v4,0xFF); 1204 e1=(v1,v3,v5,0xFF); } 1205 else { e0=blue_contract(v1,v3,v5,0xFF); 1206 e1=blue_contract(v0,v2,v4,0xFF); } 1207 1208 Mode 9 LDR RGB, base+offset 1209 1210 bit_transfer_signed(v1,v0); 1211 bit_transfer_signed(v3,v2); 1212 bit_transfer_signed(v5,v4); 1213 if(v1+v3+v5 >= 0) 1214 { e0=(v0,v2,v4,0xFF); e1=(v0+v1,v2+v3,v4+v5,0xFF); } 1215 else 1216 { e0=blue_contract(v0+v1,v2+v3,v4+v5,0xFF); 1217 e1=blue_contract(v0,v2,v4,0xFF); } 1218 clamp_unorm8(e0); clamp_unorm8(e1); 1219 1220 Mode 10 LDR RGB, base+scale plus two A 1221 1222 e0=(v0*v3>>8,v1*v3>>8,v2*v3>>8, v4); 1223 e1=(v0,v1,v2, v5); 1224 1225 Mode 12 LDR RGBA, direct 1226 1227 s0= v0+v2+v4; s1= v1+v3+v5; 1228 if (s1>=s0){e0=(v0,v2,v4,v6); 1229 e1=(v1,v3,v5,v7); } 1230 else { e0=blue_contract(v1,v3,v5,v7); 1231 e1=blue_contract(v0,v2,v4,v6); } 1232 1233 Mode 13 LDR RGBA, base+offset 1234 1235 bit_transfer_signed(v1,v0); 1236 bit_transfer_signed(v3,v2); 1237 bit_transfer_signed(v5,v4); 1238 bit_transfer_signed(v7,v6); 1239 if(v1+v3+v5>=0) { e0=(v0,v2,v4,v6); 1240 e1=(v0+v1,v2+v3,v4+v5,v6+v7); } 1241 else { e0=blue_contract(v0+v1,v2+v3,v4+v5,v6+v7); 1242 e1=blue_contract(v0,v2,v4,v6); } 1243 clamp_unorm8(e0); clamp_unorm8(e1); 1244 1245 The bit_transfer_signed procedure transfers a bit from one value (a) 1246 to another (b). Initially, both a and b are in the range 0..255. 1247 After calling this procedure, a's range becomes -32..31, and b remains 1248 in the range 0..255. Note that, as is often the case, this is easier to 1249 express in hardware than in C: 1250 1251 bit_transfer_signed(int& a, int& b) 1252 { 1253 b >>= 1; 1254 b |= a & 0x80; 1255 a >>= 1; 1256 a &= 0x3F; 1257 if( (a&0x20)!=0 ) a-=0x40; 1258 } 1259 1260 The blue_contract procedure is used to give additional precision to 1261 RGB colors near grey: 1262 1263 color blue_contract( int r, int g, int b, int a ) 1264 { 1265 color c; 1266 c.r = (r+b) >> 1; 1267 c.g = (g+b) >> 1; 1268 c.b = b; 1269 c.a = a; 1270 return c; 1271 } 1272 1273 The clamp_unorm8 procedure is used to clamp a color into the UNORM8 range: 1274 1275 void clamp_unorm8(color c) 1276 { 1277 if(c.r < 0) {c.r=0;} else if(c.r > 255) {c.r=255;} 1278 if(c.g < 0) {c.g=0;} else if(c.g > 255) {c.g=255;} 1279 if(c.b < 0) {c.b=0;} else if(c.b > 255) {c.b=255;} 1280 if(c.a < 0) {c.a=0;} else if(c.a > 255) {c.a=255;} 1281 } 1282 1283 C.2.15 HDR Endpoint Decoding 1284 ------------------------- 1285 1286 For HDR endpoint modes, color values are represented in a 12-bit 1287 pseudo-logarithmic representation. 1288 1289 HDR Endpoint Mode 2 1290 1291 Mode 2 represents luminance-only data with a large range. It encodes 1292 using two values (v0, v1). The complete decoding procedure is as follows: 1293 1294 if(v1 >= v0) 1295 { 1296 y0 = (v0 << 4); 1297 y1 = (v1 << 4); 1298 } 1299 else 1300 { 1301 y0 = (v1 << 4) + 8; 1302 y1 = (v0 << 4) - 8; 1303 } 1304 // Construct RGBA result (0x780 is 1.0f) 1305 e0 = (y0, y0, y0, 0x780); 1306 e1 = (y1, y1, y1, 0x780); 1307 1308 HDR Endpoint Mode 3 1309 1310 Mode 3 represents luminance-only data with a small range. It packs the 1311 bits for a base luminance value, together with an offset, into two values 1312 (v0, v1): 1313 1314 Value 7 6 5 4 3 2 1 0 1315 ----- ------------------------------ 1316 v0 |M | L[6:0] | 1317 ------------------------------ 1318 v1 | X[3:0] | d[3:0] | 1319 ------------------------------ 1320 1321 Table C.2.18 - HDR Mode 3 Value Layout 1322 1323 The bit field marked as X allocates different bits to L or d depending 1324 on the value of the mode bit M. 1325 1326 The complete decoding procedure is as follows: 1327 1328 // Check mode bit and extract. 1329 if((v0&0x80) !=0) 1330 { 1331 y0 = ((v1 & 0xE0) << 4) | ((v0 & 0x7F) << 2); 1332 d = (v1 & 0x1F) << 2; 1333 } 1334 else 1335 { 1336 y0 = ((v1 & 0xF0) << 4) | ((v0 & 0x7F) << 1); 1337 d = (v1 & 0x0F) << 1; 1338 } 1339 1340 // Add delta and clamp 1341 y1 = y0 + d; 1342 if(y1 > 0xFFF) { y1 = 0xFFF; } 1343 1344 // Construct RGBA result (0x780 is 1.0f) 1345 e0 = (y0, y0, y0, 0x780); 1346 e1 = (y1, y1, y1, 0x780); 1347 1348 HDR Endpoint Mode 7 1349 1350 Mode 7 packs the bits for a base RGB value, a scale factor, and some 1351 mode bits into the four values (v0, v1, v2, v3): 1352 1353 Value 7 6 5 4 3 2 1 0 1354 ----- ------------------------------ 1355 v0 |M[3:2] | R[5:0] | 1356 ----- ------------------------------ 1357 v1 |M1 |X0 |X1 | G[4:0] | 1358 ----- ------------------------------ 1359 v2 |M0 |X2 |X3 | B[4:0] | 1360 ----- ------------------------------ 1361 v3 |X4 |X5 |X6 | S[4:0] | 1362 ----- ------------------------------ 1363 Table C.2.19 - HDR Mode 7 Value Layout 1364 1365 The mode bits M0 to M3 are a packed representation of an endpoint bit 1366 mode, together with the major component index. For modes 0 to 4, the 1367 component (red, green, or blue) with the largest magnitude is identified, 1368 and the values swizzled to ensure that it is decoded from the red channel. 1369 1370 The endpoint bit mode is used to determine the number of bits assigned 1371 to each component of the endpoint, and the destination of each of the 1372 extra bits X0 to X6, as follows: 1373 1374 ------------------------------------------------------ 1375 Number of bits Destination of extra bits 1376 Mode R G B S X0 X1 X2 X3 X4 X5 X6 1377 ------------------------------------------------------ 1378 0 11 5 5 7 R9 R8 R7 R10 R6 S6 S5 1379 1 11 6 6 5 R8 G5 R7 B5 R6 R10 R9 1380 2 10 5 5 8 R9 R8 R7 R6 S7 S6 S5 1381 3 9 6 6 7 R8 G5 R7 B5 R6 S6 S5 1382 4 8 7 7 6 G6 G5 B6 B5 R6 R7 S5 1383 5 7 7 7 7 G6 G5 B6 B5 R6 S6 S5 1384 ------------------------------------------------------ 1385 Table C.2.20 - Endpoint Bit Mode 1386 1387 As noted before, this appears complex when expressed in C, but much 1388 easier to achieve in hardware - bit masking, extraction, shifting 1389 and assignment usually ends up as a single wire or multiplexer. 1390 1391 The complete decoding procedure is as follows: 1392 1393 // Extract mode bits and unpack to major component and mode. 1394 int modeval = ((v0&0xC0)>>6) | ((v1&0x80)>>5) | ((v2&0x80)>>4); 1395 1396 int majcomp; 1397 int mode; 1398 1399 if( (modeval & 0xC ) != 0xC ) 1400 { 1401 majcomp = modeval >> 2; mode = modeval & 3; 1402 } 1403 else if( modeval != 0xF ) 1404 { 1405 majcomp = modeval & 3; mode = 4; 1406 } 1407 else 1408 { 1409 majcomp = 0; mode = 5; 1410 } 1411 1412 // Extract low-order bits of r, g, b, and s. 1413 int red = v0 & 0x3f; 1414 int green = v1 & 0x1f; 1415 int blue = v2 & 0x1f; 1416 int scale = v3 & 0x1f; 1417 1418 // Extract high-order bits, which may be assigned depending on mode 1419 int x0 = (v1 >> 6) & 1; int x1 = (v1 >> 5) & 1; 1420 int x2 = (v2 >> 6) & 1; int x3 = (v2 >> 5) & 1; 1421 int x4 = (v3 >> 7) & 1; int x5 = (v3 >> 6) & 1; 1422 int x6 = (v3 >> 5) & 1; 1423 1424 // Now move the high-order xs into the right place. 1425 int ohm = 1 << mode; 1426 if( ohm & 0x30 ) green |= x0 << 6; 1427 if( ohm & 0x3A ) green |= x1 << 5; 1428 if( ohm & 0x30 ) blue |= x2 << 6; 1429 if( ohm & 0x3A ) blue |= x3 << 5; 1430 if( ohm & 0x3D ) scale |= x6 << 5; 1431 if( ohm & 0x2D ) scale |= x5 << 6; 1432 if( ohm & 0x04 ) scale |= x4 << 7; 1433 if( ohm & 0x3B ) red |= x4 << 6; 1434 if( ohm & 0x04 ) red |= x3 << 6; 1435 if( ohm & 0x10 ) red |= x5 << 7; 1436 if( ohm & 0x0F ) red |= x2 << 7; 1437 if( ohm & 0x05 ) red |= x1 << 8; 1438 if( ohm & 0x0A ) red |= x0 << 8; 1439 if( ohm & 0x05 ) red |= x0 << 9; 1440 if( ohm & 0x02 ) red |= x6 << 9; 1441 if( ohm & 0x01 ) red |= x3 << 10; 1442 if( ohm & 0x02 ) red |= x5 << 10; 1443 1444 // Shift the bits to the top of the 12-bit result. 1445 static const int shamts[6] = { 1,1,2,3,4,5 }; 1446 int shamt = shamts[mode]; 1447 red <<= shamt; green <<= shamt; blue <<= shamt; scale <<= shamt; 1448 1449 // Minor components are stored as differences 1450 if( mode != 5 ) { green = red - green; blue = red - blue; } 1451 1452 // Swizzle major component into place 1453 if( majcomp == 1 ) swap( red, green ); 1454 if( majcomp == 2 ) swap( red, blue ); 1455 1456 // Clamp output values, set alpha to 1.0 1457 e1.r = clamp( red, 0, 0xFFF ); 1458 e1.g = clamp( green, 0, 0xFFF ); 1459 e1.b = clamp( blue, 0, 0xFFF ); 1460 e1.alpha = 0x780; 1461 1462 e0.r = clamp( red - scale, 0, 0xFFF ); 1463 e0.g = clamp( green - scale, 0, 0xFFF ); 1464 e0.b = clamp( blue - scale, 0, 0xFFF ); 1465 e0.alpha = 0x780; 1466 1467 HDR Endpoint Mode 11 1468 1469 Mode 11 specifies two RGB values, which it calculates from a number of 1470 bitfields (a, b0, b1, c, d0 and d1) which are packed together with some 1471 mode bits into the six values (v0, v1, v2, v3, v4, v5): 1472 1473 Value 7 6 5 4 3 2 1 0 1474 ----- ------------------------------ 1475 v0 | a[7:0] | 1476 ----- ------------------------------ 1477 v1 |m0 |a8 | c[5:0] | 1478 ----- ------------------------------ 1479 v2 |m1 |X0 | b0[5:0] | 1480 ----- ------------------------------ 1481 v3 |m2 |X1 | b1[5:0] | 1482 ----- ------------------------------ 1483 v4 |mj0|X2 |X4 | d0[4:0] | 1484 ----- ------------------------------ 1485 v5 |mj1|X3 |X5 | d1[4:0] | 1486 ----- ------------------------------ 1487 Table C.2.21 - HDR Mode 11 Value Layout 1488 1489 If the major component bits mj[1:0 ] are both 1, then the RGB values 1490 are specified directly 1491 1492 Value 7 6 5 4 3 2 1 0 1493 ----- ------------------------------ 1494 v0 | R0[11:4] | 1495 ----- ------------------------------ 1496 v1 | R1[11:4] | 1497 ----- ------------------------------ 1498 v2 | G0[11:4] | 1499 ----- ------------------------------ 1500 v3 | G1[11:4] | 1501 ----- ------------------------------ 1502 v4 | 1 | B0[11:5] | 1503 ----- ------------------------------ 1504 v5 | 1 | B1[11:5] | 1505 ----- ------------------------------ 1506 Table C.2.22 - HDR Mode 11 Value Layout 1507 1508 The mode bits m[2:0] specify the bit allocation for the different 1509 values, and the destinations of the extra bits X0 to X5: 1510 1511 ------------------------------------------------------------------------- 1512 Number of bits Destination of extra bits 1513 Mode a b c d X0 X1 X2 X3 X4 X5 1514 ------------------------------------------------------------------------- 1515 0 9 7 6 7 b0[6] b1[6] d0[6] d1[6] d0[5] d1[5] 1516 1 9 8 6 6 b0[6] b1[6] b0[7] b1[7] d0[5] d1[5] 1517 2 10 6 7 7 a[9] c[6] d0[6] d1[6] d0[5] d1[5] 1518 3 10 7 7 6 b0[6] b1[6] a[9] c[6] d0[5] d1[5] 1519 4 11 8 6 5 b0[6] b1[6] b0[7] b1[7] a[9] a[10] 1520 5 11 6 7 6 a[9] a[10] c[7] c[6] d0[5] d1[5] 1521 6 12 7 7 5 b0[6] b1[6] a[11] c[6] a[9] a[10] 1522 7 12 6 7 6 a[9] a[10] a[11] c[6] d0[5] d1[5] 1523 ------------------------------------------------------------------------- 1524 Table C.2.23 - Endpoint Bit Mode 1525 1526 The complete decoding procedure is as follows: 1527 1528 // Find major component 1529 int majcomp = ((v4 & 0x80) >> 7) | ((v5 & 0x80) >> 6); 1530 1531 // Deal with simple case first 1532 if( majcomp == 3 ) 1533 { 1534 e0 = (v0 << 4, v2 << 4, (v4 & 0x7f) << 5, 0x780); 1535 e1 = (v1 << 4, v3 << 4, (v5 & 0x7f) << 5, 0x780); 1536 return; 1537 } 1538 1539 // Decode mode, parameters. 1540 int mode = ((v1&0x80)>>7) | ((v2&0x80)>>6) | ((v3&0x80)>>5); 1541 int va = v0 | ((v1 & 0x40) << 2); 1542 int vb0 = v2 & 0x3f; 1543 int vb1 = v3 & 0x3f; 1544 int vc = v1 & 0x3f; 1545 int vd0 = v4 & 0x7f; 1546 int vd1 = v5 & 0x7f; 1547 1548 // Assign top bits of vd0, vd1. 1549 static const int dbitstab[8] = {7,6,7,6,5,6,5,6}; 1550 vd0 = signextend( vd0, dbitstab[mode] ); 1551 vd1 = signextend( vd1, dbitstab[mode] ); 1552 1553 // Extract and place extra bits 1554 int x0 = (v2 >> 6) & 1; 1555 int x1 = (v3 >> 6) & 1; 1556 int x2 = (v4 >> 6) & 1; 1557 int x3 = (v5 >> 6) & 1; 1558 int x4 = (v4 >> 5) & 1; 1559 int x5 = (v5 >> 5) & 1; 1560 1561 int ohm = 1 << mode; 1562 if( ohm & 0xA4 ) va |= x0 << 9; 1563 if( ohm & 0x08 ) va |= x2 << 9; 1564 if( ohm & 0x50 ) va |= x4 << 9; 1565 if( ohm & 0x50 ) va |= x5 << 10; 1566 if( ohm & 0xA0 ) va |= x1 << 10; 1567 if( ohm & 0xC0 ) va |= x2 << 11; 1568 if( ohm & 0x04 ) vc |= x1 << 6; 1569 if( ohm & 0xE8 ) vc |= x3 << 6; 1570 if( ohm & 0x20 ) vc |= x2 << 7; 1571 if( ohm & 0x5B ) vb0 |= x0 << 6; 1572 if( ohm & 0x5B ) vb1 |= x1 << 6; 1573 if( ohm & 0x12 ) vb0 |= x2 << 7; 1574 if( ohm & 0x12 ) vb1 |= x3 << 7; 1575 1576 // Now shift up so that major component is at top of 12-bit value 1577 int shamt = (modeval >> 1) ^ 3; 1578 va <<= shamt; vb0 <<= shamt; vb1 <<= shamt; 1579 vc <<= shamt; vd0 <<= shamt; vd1 <<= shamt; 1580 1581 e1.r = clamp( va, 0, 0xFFF ); 1582 e1.g = clamp( va - vb0, 0, 0xFFF ); 1583 e1.b = clamp( va - vb1, 0, 0xFFF ); 1584 e1.alpha = 0x780; 1585 1586 e0.r = clamp( va - vc, 0, 0xFFF ); 1587 e0.g = clamp( va - vb0 - vc - vd0, 0, 0xFFF ); 1588 e0.b = clamp( va - vb1 - vc - vd1, 0, 0xFFF ); 1589 e0.alpha = 0x780; 1590 1591 if( majcomp == 1 ) { swap( e0.r, e0.g ); swap( e1.r, e1.g ); } 1592 else if( majcomp == 2 ) { swap( e0.r, e0.b ); swap( e1.r, e1.b ); } 1593 1594 HDR Endpoint Mode 14 1595 1596 Mode 14 specifies two RGBA values, using the eight values (v0, v1, v2, 1597 v3, v4, v5, v6, v7). First, the RGB values are decoded from (v0..v5) 1598 using the method from Mode 11, then the alpha values are filled in 1599 from v6 and v7: 1600 1601 // Decode RGB as for mode 11 1602 (e0,e1) = decode_mode_11(v0,v1,v2,v3,v4,v5) 1603 1604 // Now fill in the alphas 1605 e0.alpha = v6; 1606 e1.alpha = v7; 1607 1608 Note that in this mode, the alpha values are interpreted (and 1609 interpolated) as 8-bit unsigned normalized values, as in the LDR modes. 1610 This is the only mode that exhibits this behaviour. 1611 1612 HDR Endpoint Mode 15 1613 1614 Mode 15 specifies two RGBA values, using the eight values (v0, v1, v2, 1615 v3, v4, v5, v6, v7). First, the RGB values are decoded from (v0..v5) 1616 using the method from Mode 11. The alpha values are stored in values 1617 v6 and v7 as a mode and two values which are interpreted according 1618 to the mode: 1619 1620 Value 7 6 5 4 3 2 1 0 1621 ----- ------------------------------ 1622 v6 |M0 | A[6:0] | 1623 ----- ------------------------------ 1624 v7 |M1 | B[6:0] | 1625 ----- ------------------------------ 1626 Table C.2.24 - HDR Mode 15 Alpha Value Layout 1627 1628 The alpha values are decoded from v6 and v7 as follows: 1629 1630 // Decode RGB as for mode 11 1631 (e0,e1) = decode_mode_11(v0,v1,v2,v3,v4,v5) 1632 1633 // Extract mode bits 1634 mode = ((v6 >> 7) & 1) | ((v7 >> 6) & 2); 1635 v6 &= 0x7F; 1636 v7 &= 0x7F; 1637 1638 if(mode==3) 1639 { 1640 // Directly specify alphas 1641 e0.alpha = v6 << 5; 1642 e1.alpha = v7 << 5; 1643 } 1644 else 1645 { 1646 // Transfer bits from v7 to v6 and sign extend v7. 1647 v6 |= (v7 << (mode+1))) & 0x780; 1648 v7 &= (0x3F >> mode); 1649 v7 ^= 0x20 >> mode; 1650 v7 -= 0x20 >> mode; 1651 v6 <<= (4-mode); 1652 v7 <<= (4-mode); 1653 1654 // Add delta and clamp 1655 v7 += v6; 1656 v7 = clamp(v7, 0, 0xFFF); 1657 e0.alpha = v6; 1658 e1.alpha = v7; 1659 } 1660 1661 Note that in this mode, the alpha values are interpreted (and 1662 interpolated) as 12-bit HDR values, and are interpolated as 1663 for any other HDR component. 1664 1665 C.2.16 Weight Decoding 1666 ----------------------- 1667 The weight information is stored as a stream of bits, growing downwards 1668 from the most significant bit in the block. Bit n in the stream is thus 1669 bit 127-n in the block. 1670 1671 For each location in the weight grid, a value (in the specified range) 1672 is packed into the stream. These are ordered in a raster pattern 1673 starting from location (0,0,0), with the X dimension increasing fastest, 1674 and the Z dimension increasing slowest. If dual-plane mode is selected, 1675 both weights are emitted together for each location, plane 0 first, 1676 then plane 1. 1677 1678 C.2.17 Weight Unquantization 1679 ----------------------------- 1680 1681 Each weight plane is specified as a sequence of integers in a given 1682 range. These values are packed using integer sequence encoding. 1683 1684 Once unpacked, the values must be unquantized from their storage 1685 range, returning them to a standard range of 0..64. The procedure 1686 for doing so is similar to the color endpoint unquantization. 1687 1688 First, we unquantize the actual stored weight values to the range 0..63. 1689 1690 For bit-only representations, this is simple bit replication from the 1691 most significant bit of the value. 1692 1693 For trit or quint-based representations, this involves a set of bit 1694 manipulations and adjustments to avoid the expense of full-width 1695 multipliers. 1696 1697 For representations with no additional bits, the results are as follows: 1698 1699 Range 0 1 2 3 4 1700 -------------------------- 1701 0..2 0 32 63 - - 1702 0..4 0 16 32 47 63 1703 -------------------------- 1704 Table C.2.25 - Weight Unquantization Values 1705 1706 For other values, we calculate the initial inputs to a bit manipulation 1707 procedure. These are denoted A (7 bits), B (7 bits), C (7 bits), and 1708 D (3 bits) and are decoded using the range as follows: 1709 1710 Range T Q B Bits A B C D 1711 ------------------------------------------------------- 1712 0..5 1 1 a aaaaaaa 0000000 50 Trit value 1713 0..9 1 1 a aaaaaaa 0000000 28 Quint value 1714 0..11 1 2 ba aaaaaaa b000b0b 23 Trit value 1715 0..19 1 2 ba aaaaaaa b0000b0 13 Quint value 1716 0..23 1 3 cba aaaaaaa cb000cb 11 Trit value 1717 ------------------------------------------------------- 1718 Table C.2.26 - Weight Unquantization Parameters 1719 1720 These are then processed as follows: 1721 1722 T = D * C + B; 1723 T = T ^ A; 1724 T = (A & 0x20) | (T >> 2); 1725 1726 Note that the multiply in the first line is nearly trivial as it only 1727 needs to multiply by 0, 1, 2, 3 or 4. 1728 1729 As a final step, for all types of value, the range is expanded from 1730 0..63 up to 0..64 as follows: 1731 1732 if (T > 32) { T += 1; } 1733 1734 This allows the implementation to use 64 as a divisor during inter- 1735 polation, which is much easier than using 63. 1736 1737 C.2.18 Weight Infill 1738 --------------------- 1739 1740 After unquantization, the weights are subject to weight selection and 1741 infill. The infill method is used to calculate the weight for a texel 1742 position, based on the weights in the stored weight grid array (which 1743 may be a different size). 1744 1745 The procedure below must be followed exactly, to ensure bit exact 1746 results. 1747 1748 The block size is specified as three dimensions along the s, t and r 1749 axes (Bs, Bt, Br). Texel coordinates within the block (s,t,r) can 1750 have values from 0 to one less than the block dimension in that axis. 1751 For each block dimension, we compute scale factors (Ds, Dt, Dr) 1752 1753 Ds = floor( (1024 + floor(Bs/2)) / (Bs-1) ); 1754 Dt = floor( (1024 + floor(Bt/2)) / (Bt-1) ); 1755 Dr = floor( (1024 + floor(Br/2)) / (Br-1) ); 1756 1757 Since the block dimensions are constrained, these are easily looked up 1758 in a table. These scale factors are then used to scale the (s,t,r) 1759 coordinates to a homogeneous coordinate (cs, ct, cr): 1760 1761 cs = Ds * s; 1762 ct = Dt * t; 1763 cr = Dr * r; 1764 1765 This homogeneous coordinate (cs, ct, cr) is then scaled again to give 1766 a coordinate (gs, gt, gr) in the weight-grid space . The weight-grid is 1767 of size (N, M, Q), as specified in the block mode field: 1768 1769 gs = (cs*(N-1)+32) >> 6; 1770 gt = (ct*(M-1)+32) >> 6; 1771 gr = (cr*(Q-1)+32) >> 6; 1772 1773 The resulting coordinates may be in the range 0..176. These are inter- 1774 preted as 4:4 unsigned fixed point numbers in the range 0.0 .. 11.0. 1775 1776 If we label the integral parts of these (js, jt, jr) and the fractional 1777 parts (fs, ft, fr), then: 1778 1779 js = gs >> 4; fs = gs & 0x0F; 1780 jt = gt >> 4; ft = gt & 0x0F; 1781 jr = gr >> 4; fr = gr & 0x0F; 1782 1783 These values are then used to interpolate between the stored weights. 1784 This process differs for 2D and 3D. 1785 1786 For 2D, bilinear interpolation is used: 1787 1788 v0 = js + jt*N; 1789 p00 = decode_weight(v0); 1790 p01 = decode_weight(v0 + 1); 1791 p10 = decode_weight(v0 + N); 1792 p11 = decode_weight(v0 + N + 1); 1793 1794 The function decode_weight(n) decodes the nth weight in the stored weight 1795 stream. The values p00 to p11 are the weights at the corner of the square 1796 in which the texel position resides. These are then weighted using the 1797 fractional position to produce the effective weight i as follows: 1798 1799 w11 = (fs*ft+8) >> 4; 1800 w10 = ft - w11; 1801 w01 = fs - w11; 1802 w00 = 16 - fs - ft + w11; 1803 i = (p00*w00 + p01*w01 + p10*w10 + p11*w11 + 8) >> 4; 1804 1805 For 3D, simplex interpolation is used as it is cheaper than a naïve 1806 trilinear interpolation. First, we pick some parameters for the inter- 1807 polation based on comparisons of the fractional parts of the texel 1808 position: 1809 1810 fs>ft ft>fr fs>fr s1 s2 w0 w1 w2 w3 1811 ---------------------------------------------------------- 1812 True True True 1 N 16-fs fs-ft ft-fr fr 1813 False True True N 1 16-ft ft-fs fs-fr fr 1814 True False True 1 N*M 16-fs fs-fr fr-ft ft 1815 True False False N*M 1 16-fr fr-fs fs-ft ft 1816 False True False N N*M 16-ft ft-fr fr-fs fs 1817 False False False N*M N 16-fr fr-ft ft-fs fs 1818 ---------------------------------------------------------- 1819 Table C.2.27 -Simplex Interpolation Parameters 1820 1821 Some test results are implied by the others. The effective 1822 weight i is then calculated as: 1823 1824 v0 = js + jt*N + jr*N*M; 1825 p0 = decode_index(v0); 1826 p1 = decode_index(v0 + s1); 1827 p2 = decode_index(v0 + s1 + s2); 1828 p3 = decode_index(v0 + N*M + N + 1); 1829 i = (p0*w0 + p1*w1 + p2*w2 + p3*w3 + 8) >> 4; 1830 1831 C.2.19 Weight Application 1832 -------------------------- 1833 Once the effective weight i for the texel has been calculated, the color 1834 endpoints are interpolated and expanded. 1835 1836 For LDR endpoint modes, each color component C is calculated from the 1837 corresponding 8-bit endpoint components C0 and C1 as follows: 1838 1839 If sRGB conversion is not enabled, or for the alpha channel in any case, 1840 C0 and C1 are first expanded to 16 bits by bit replication: 1841 1842 C0 = (C0 << 8) | C0; C1 = (C1 << 8) | C1; 1843 1844 If sRGB conversion is enabled, C0 and C1 for the R, G, and B channels 1845 are expanded to 16 bits differently, as follows: 1846 1847 C0 = (C0 << 8) | 0x80; C1 = (C1 << 8) | 0x80; 1848 1849 C0 and C1 are then interpolated to produce a UNORM16 result C: 1850 1851 C = floor( (C0*(64-i) + C1*i + 32)/64 ) 1852 1853 If sRGB conversion is enabled, the top 8 bits of the interpolation 1854 result for the R, G and B channels are passed to the external sRGB 1855 conversion block. Otherwise, if C = 65535, then the final result is 1856 1.0 (0x3C00) otherwise C is divided by 65536 and the infinite-precision 1857 result of the division is converted to FP16 with round-to-zero 1858 semantics. 1859 1860 For HDR endpoint modes, color values are represented in a 12-bit 1861 pseudo-logarithmic representation, and interpolation occurs in a 1862 piecewise-approximate logarithmic manner as follows: 1863 1864 In LDR mode, the error result is returned. 1865 1866 In HDR mode, the color components from each endpoint, C0 and C1, are 1867 initially shifted left 4 bits to become 16-bit integer values and these 1868 are interpolated in the same way as LDR. The 16-bit value C is then 1869 decomposed into the top five bits, E, and the bottom 11 bits M, which 1870 are then processed and recombined with E to form the final value Cf: 1871 1872 C = floor( (C0*(64-i) + C1*i + 32)/64 ) 1873 E = (C&0xF800) >> 11; M = C&0x7FF; 1874 if (M < 512) { Mt = 3*M; } 1875 else if (M >= 1536) { Mt = 5*M - 2048; } 1876 else { Mt = 4*M - 512; } 1877 Cf = (E<<10) + (Mt>>3) 1878 1879 This interpolation is a considerably closer approximation to a 1880 logarithmic space than simple 16-bit interpolation. 1881 1882 This final value Cf is interpreted as an IEEE FP16 value. If the result 1883 is +Inf or NaN, it is converted to the bit pattern 0x7BFF, which is the 1884 largest representable finite value. 1885 1886 C.2.20 Dual-Plane Decoding 1887 --------------------------- 1888 If dual-plane mode is disabled, all of the endpoint components are inter- 1889 polated using the same weight value. 1890 1891 If dual-plane mode is enabled, two weights are stored with each texel. 1892 One component is then selected to use the second weight for interpolation, 1893 instead of the first weight. The first weight is then used for all other 1894 components. 1895 1896 The component to treat specially is indicated using the 2-bit Color 1897 Component Selector (CCS) field as follows: 1898 1899 Value Weight 0 Weight 1 1900 -------------------------- 1901 0 GBA R 1902 1 RBA G 1903 2 RGA B 1904 3 RGB A 1905 -------------------------- 1906 Table C.2.28 -Dual Plane Color Component Selector Values 1907 1908 The CCS bits are stored at a variable position directly below the weight 1909 bits and any additional CEM bits. 1910 1911 C.2.21 Partition Pattern Generation 1912 ------------------------------------ 1913 1914 When multiple partitions are active, each texel position is assigned a 1915 partition index. This partition index is calculated using a seed (the 1916 partition pattern index), the texel's x,y,z position within the block, 1917 and the number of partitions. An additional argument, small_block, is 1918 set to 1 if the number of texels in the block is less than 31, 1919 otherwise it is set to 0. 1920 1921 This function is specified in terms of x, y and z in order to support 1922 3D textures. For 2D textures and texture slices, z will always be 0. 1923 1924 The full partition selection algorithm is as follows: 1925 1926 int select_partition(int seed, int x, int y, int z, 1927 int partitioncount, int small_block) 1928 { 1929 if( small_block ){ x <<= 1; y <<= 1; z <<= 1; } 1930 seed += (partitioncount-1) * 1024; 1931 uint32_t rnum = hash52(seed); 1932 uint8_t seed1 = rnum & 0xF; 1933 uint8_t seed2 = (rnum >> 4) & 0xF; 1934 uint8_t seed3 = (rnum >> 8) & 0xF; 1935 uint8_t seed4 = (rnum >> 12) & 0xF; 1936 uint8_t seed5 = (rnum >> 16) & 0xF; 1937 uint8_t seed6 = (rnum >> 20) & 0xF; 1938 uint8_t seed7 = (rnum >> 24) & 0xF; 1939 uint8_t seed8 = (rnum >> 28) & 0xF; 1940 uint8_t seed9 = (rnum >> 18) & 0xF; 1941 uint8_t seed10 = (rnum >> 22) & 0xF; 1942 uint8_t seed11 = (rnum >> 26) & 0xF; 1943 uint8_t seed12 = ((rnum >> 30) | (rnum << 2)) & 0xF; 1944 1945 seed1 *= seed1; seed2 *= seed2; 1946 seed3 *= seed3; seed4 *= seed4; 1947 seed5 *= seed5; seed6 *= seed6; 1948 seed7 *= seed7; seed8 *= seed8; 1949 seed9 *= seed9; seed10 *= seed10; 1950 seed11 *= seed11; seed12 *= seed12; 1951 1952 int sh1, sh2, sh3; 1953 if( seed & 1 ) 1954 { sh1 = (seed&2 ? 4:5); sh2 = (partitioncount==3 ? 6:5); } 1955 else 1956 { sh1 = (partitioncount==3 ? 6:5); sh2 = (seed&2 ? 4:5); } 1957 sh3 = (seed & 0x10) ? sh1 : sh2; 1958 1959 seed1 >>= sh1; seed2 >>= sh2; seed3 >>= sh1; seed4 >>= sh2; 1960 seed5 >>= sh1; seed6 >>= sh2; seed7 >>= sh1; seed8 >>= sh2; 1961 seed9 >>= sh3; seed10 >>= sh3; seed11 >>= sh3; seed12 >>= sh3; 1962 1963 int a = seed1*x + seed2*y + seed11*z + (rnum >> 14); 1964 int b = seed3*x + seed4*y + seed12*z + (rnum >> 10); 1965 int c = seed5*x + seed6*y + seed9 *z + (rnum >> 6); 1966 int d = seed7*x + seed8*y + seed10*z + (rnum >> 2); 1967 1968 a &= 0x3F; b &= 0x3F; c &= 0x3F; d &= 0x3F; 1969 1970 if( partitioncount < 4 ) d = 0; 1971 if( partitioncount < 3 ) c = 0; 1972 1973 if( a >= b && a >= c && a >= d ) return 0; 1974 else if( b >= c && b >= d ) return 1; 1975 else if( c >= d ) return 2; 1976 else return 3; 1977 } 1978 1979 As has been observed before, the bit selections are much easier to 1980 express in hardware than in C. 1981 1982 The seed is expanded using a hash function hash52, which is defined as 1983 follows: 1984 1985 uint32_t hash52( uint32_t p ) 1986 { 1987 p ^= p >> 15; p -= p << 17; p += p << 7; p += p << 4; 1988 p ^= p >> 5; p += p << 16; p ^= p >> 7; p ^= p >> 3; 1989 p ^= p << 6; p ^= p >> 17; 1990 return p; 1991 } 1992 1993 This assumes that all operations act on 32-bit values 1994 1995 C.2.22 Data Size Determination 1996 ------------------------------- 1997 1998 The size of the data used to represent color endpoints is not 1999 explicitly specified. Instead, it is determined from the block mode and 2000 number of partitions as follows: 2001 2002 config_bits = 17; 2003 if(num_partitions>1) 2004 if(single_CEM) 2005 config_bits = 29; 2006 else 2007 config_bits = 25 + 3*num_partitions; 2008 2009 num_weights = M * N * Q; // size of weight grid 2010 2011 if(dual_plane) 2012 config_bits += 2; 2013 num_weights *= 2; 2014 2015 weight_bits = ceil(num_weights*8*trits_in_weight_range/5) + 2016 ceil(num_weights*7*quints_in_weight_range/3) + 2017 num_weights*bits_in_weight_range; 2018 2019 remaining_bits = 128 - config_bits - weight_bits; 2020 2021 num_CEM_pairs = base_CEM_class+1 + count_bits(extra_CEM_bits); 2022 2023 The CEM value range is then looked up from a table indexed by remaining 2024 bits and num_CEM_pairs. This table is initialized such that the range 2025 is as large as possible, consistent with the constraint that the number 2026 of bits required to encode num_CEM_pairs pairs of values is not more 2027 than the number of remaining bits. 2028 2029 An equivalent iterative algorithm would be: 2030 2031 num_CEM_values = num_CEM_pairs*2; 2032 2033 for(range = each possible CEM range in descending order of size) 2034 { 2035 CEM_bits = ceil(num_CEM_values*8*trits_in_CEM_range/5) + 2036 ceil(num_CEM_values*7*quints_in_CEM_range/3) + 2037 num_CEM_values*bits_in_CEM_range; 2038 2039 if(CEM_bits <= remaining_bits) 2040 break; 2041 } 2042 return range; 2043 2044 In cases where this procedure results in unallocated bits, these bits 2045 are not read by the decoding process and can have any value. 2046 2047 C.2.23 Void-Extent Blocks 2048 -------------------------- 2049 2050 A void-extent block is a block encoded with a single color. It also 2051 specifies some additional information about the extent of the single- 2052 color area beyond this block, which can optionally be used by a 2053 decoder to reduce or prevent redundant block fetches. 2054 2055 The layout of a 2D Void-Extent block is as follows: 2056 2057 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 2058 --------------------------------------------------------------- 2059 | Block color A component | 2060 --------------------------------------------------------------- 2061 2062 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 2063 --------------------------------------------------------------- 2064 | Block color B component | 2065 --------------------------------------------------------------- 2066 2067 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 2068 --------------------------------------------------------------- 2069 | Block color G component | 2070 --------------------------------------------------------------- 2071 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 2072 --------------------------------------------------------------- 2073 | Block color R component | 2074 --------------------------------------------------------------- 2075 2076 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 2077 --------------------------------------------------------------- 2078 | Void-extent maximum T coordinate | Min T 2079 --------------------------------------------------------------- 2080 2081 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 2082 --------------------------------------------------------------- 2083 Void-extent minimum T coordinate | Void-extent max S 2084 --------------------------------------------------------------- 2085 2086 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 2087 --------------------------------------------------------------- 2088 Void-extent max S coord | Void-extent minimum S coordinate 2089 --------------------------------------------------------------- 2090 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 2091 -------------------------------------------------------------- 2092 Min S coord | 1 | 1 | D | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 0 | 0 | 2093 -------------------------------------------------------------- 2094 2095 Table C.2.29 - 2D Void-Extent Block Layout Overview 2096 2097 The layout of a 3D Void-Extent block is as follows: 2098 2099 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 2100 --------------------------------------------------------------- 2101 | Block color A component | 2102 --------------------------------------------------------------- 2103 2104 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 2105 --------------------------------------------------------------- 2106 | Block color B component | 2107 --------------------------------------------------------------- 2108 2109 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 2110 --------------------------------------------------------------- 2111 | Block color G component | 2112 --------------------------------------------------------------- 2113 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 2114 --------------------------------------------------------------- 2115 | Block color R component | 2116 --------------------------------------------------------------- 2117 2118 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 2119 --------------------------------------------------------------- 2120 | Void-extent max R coordinate | Void-extent min R coord 2121 --------------------------------------------------------------- 2122 2123 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 2124 --------------------------------------------------------------- 2125 min R | Void-extent max T coordinate | Void-extent min T 2126 --------------------------------------------------------------- 2127 2128 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 2129 --------------------------------------------------------------- 2130 min T coord | Void-extent minimum S coordinate | Minimum S 2131 --------------------------------------------------------------- 2132 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 2133 -------------------------------------------------------------- 2134 Minimum S coord | D | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 0 | 0 | 2135 -------------------------------------------------------------- 2136 2137 Table C.2.30 - 3D Void-Extent Block Layout Overview 2138 2139 Bit 9 is the Dynamic Range flag, which indicates the format in which 2140 colors are stored. A 0 value indicates LDR, in which case the color 2141 components are stored as UNORM16 values. A 1 indicates HDR, in which 2142 case the color components are stored as FP16 values. 2143 2144 The reason for the storage of UNORM16 values in the LDR case is due 2145 to the possibility that the value will need to be passed on to sRGB 2146 conversion. By storing the color value in the format which comes out 2147 of the interpolator, before the conversion to FP16, we avoid having 2148 to have separate versions for sRGB and linear modes. 2149 2150 If a void-extent block with HDR values is decoded in LDR mode, then 2151 the result will be the error color, opaque magenta, for all texels 2152 within the block. 2153 2154 In the HDR case, if the color component values are infinity or NaN, this 2155 will result in undefined behavior. As usual, this must not lead to GL 2156 interruption or termination. 2157 2158 Bits 10 and 11 are reserved and must be 1. 2159 2160 The minimum and maximum coordinate values are treated as unsigned 2161 integers and then normalized into the range 0..1 (by dividing by 2^13-1 2162 or 2^9-1, for 2D and 3D respectively). The maximum values for each 2163 dimension must be greater than the corresponding minimum values, 2164 unless they are all all-1s. 2165 2166 If all the coordinates are all-1s, then the void extent is ignored, 2167 and the block is simply a constant-color block. 2168 2169 The existence of single-color blocks with void extents must not produce 2170 results different from those obtained if these single-color blocks are 2171 defined without void-extents. Any situation in which the results would 2172 differ is invalid. Results from invalid void extents are undefined. 2173 2174 If a void-extent appears in a MIPmap level other than the most detailed 2175 one, then the extent will apply to all of the more detailed levels too. 2176 This allows decoders to avoid sampling more detailed MIPmaps. 2177 2178 If the more detailed MIPmap level is not a constant color in this region, 2179 then the block may be marked as constant color, but without a void extent, 2180 as detailed above. 2181 2182 If a void-extent extends to the edge of a texture, then filtered texture 2183 colors may not be the same color as that specified in the block, due to 2184 texture border colors, wrapping, or cube face wrapping. 2185 2186 Care must be taken when updating or extracting partial image data that 2187 void-extents in the image do not become invalid. 2188 2189 C.2.24 Illegal Encodings 2190 ------------------------- 2191 2192 In ASTC, there is a variety of ways to encode an illegal block. Decoders 2193 are required to recognize all illegal blocks and emit the standard error 2194 color value upon encountering an illegal block. 2195 2196 Here is a comprehensive list of situations that represent illegal block 2197 encodings: 2198 2199 * The block mode specified is one of the modes explicitly listed 2200 as Reserved. 2201 * A 2D void-extent block that has any of the reserved bits not 2202 set to 1. 2203 * A block mode has been specified that would require more than 2204 64 weights total. 2205 * A block mode has been specified that would require more than 2206 96 bits for integer sequence encoding of the weight grid. 2207 * A block mode has been specifed that would require fewer than 2208 24 bits for integer sequence encoding of the weight grid. 2209 * The size of the weight grid exceeds the size of the block footprint 2210 in any dimension. 2211 * Color endpoint modes have been specified such that the color 2212 integer sequence encoding would require more than 18 integers. 2213 * The number of bits available for color endpoint encoding after all 2214 the other fields have been counted is less than ceil(13C/5) where C 2215 is the number of color endpoint integers (this would restrict color 2216 integers to a range smaller than 0..5, which is not supported). 2217 * Dual weight mode is enabled for a block with 4 partitions. 2218 * Void-Extent blocks where the low coordinate for some texture axis 2219 is greater than or equal to the high coordinate. 2220 2221 Note also that, in LDR mode, a block which has both HDR and LDR endpoint 2222 modes assigned to different partitions is not an error block. Only those 2223 texels which belong to the HDR partition will result in the error color. 2224 Texels belonging to a LDR partition will be decoded as normal. 2225 2226 C.2.25 LDR PROFILE SUPPORT 2227 --------------------------- 2228 In order to ease verification and accelerate adoption, an LDR-only 2229 subset of the full ASTC specification has been made available. 2230 2231 Implementations of this LDR Profile must satisfy the following requirements: 2232 * All textures with valid encodings for LDR Profile must decode 2233 identically using either a LDR Profile, HDR Profile, or Full Profile 2234 decoder. 2235 * All features included only in the HDR Profile or Full Profile must be 2236 treated as reserved in the LDR Profile, and return the error color on 2237 decoding. 2238 * Any sequence of API calls valid for the LDR Profile must also be valid 2239 for the HDR Profile or Full Profile and return identical results when 2240 given a texture encoded for the LDR Profile. 2241 2242 The feature subset for the LDR profile is: 2243 * 2D textures only. 2244 * Only those block sizes listed in Table C.2.2 are supported. 2245 * LDR operation mode only. 2246 * Only LDR endpoint formats must be supported, namely formats 2247 0, 1, 4, 5, 6, 8, 9, 10, 12, 13. 2248 * Decoding from a HDR endpoint results in the error color. 2249 * Interpolation returns UNORM8 results when used in conjunction 2250 with sRGB. 2251 * LDR void extent blocks must be supported, but void extents 2252 may not be checked. 2253 2254 C.2.26 HDR PROFILE SUPPORT 2255 --------------------------- 2256 In order to ease verification and accelerate adoption, a second subset 2257 of the full ASTC specification has been made available, known as the 2258 HDR profile. 2259 2260 Implementations of the HDR Profile must satisfy the following requirements: 2261 * The HDR profile is a sueprset of the LDR profile and therefore all 2262 valid LDR encodings must decode identically using a HDR profile 2263 decoder. 2264 * All textures with valid encodings for HDR Profile must decode 2265 identically using either a HDR Profile or Full Profile decoder. 2266 * All features included only in the Full Profile must be treated as 2267 reserved in the HDR Profile, and return the error color on decoding. 2268 * Any sequence of API calls valid for the HDR Profile must also be valid 2269 for the Full Profile and return identical results when given a texture 2270 encoded for the HDR Profile. 2271 2272 The feature subset for the HDR profile is: 2273 * 2D textures only. 2274 * Only those block sizes listed in Table C.2.2 are supported. 2275 * All endpoint formats must be supported. 2276 * 2D void extent blocks must be supported, but void extents 2277 may not be checked. 2278 2279 2280Additions to Appendix D of the OpenGL ES 3.0 Specification (Shared 2281 Objects and Multiple Contexts) 2282 2283 None 2284 2285Additions to Appendix E of the OpenGL ES 3.0 Specification (Version 3.0 2286 and before) 2287 2288 None 2289 2290Revision History 2291 2292 Revision 3, July 20, 2016 - Clarified definition of 2D void-extent 2293 blocks. 2294 2295 Revision 2, March 8, 2016 - Clarified that sRGB transform is not 2296 applied to Alpha channel. 2297