1Name 2 3 ARB_texture_compression_bptc 4 5Name Strings 6 7 GL_ARB_texture_compression_bptc 8 9Contact 10 11 Eric Werness, NVIDIA Corporation (ewerness 'at' nvidia.com) 12 Piers Daniell, NVIDIA Corporation (pdaniell 'at' nvidia.com) 13 14Contributors 15 16 Barthold Lichtenbelt, NVIDIA 17 Bill Licea-Kane, AMD 18 Graham Sellers, AMD 19 Greg Roth, NVIDIA 20 Jeannot Breton, NVIDIA 21 Jeff Bolz, NVIDIA 22 Nick Haemel, AMD 23 Pat Brown, NVIDIA 24 Pierre Boudier, AMD 25 Piers Daniell, NVIDIA 26 27Notice 28 29 Copyright (c) 2010-2013 The Khronos Group Inc. Copyright terms at 30 http://www.khronos.org/registry/speccopyright.html 31 32Specification Update Policy 33 34 Khronos-approved extension specifications are updated in response to 35 issues and bugs prioritized by the Khronos OpenGL Working Group. For 36 extensions which have been promoted to a core Specification, fixes will 37 first appear in the latest version of that core Specification, and will 38 eventually be backported to the extension document. This policy is 39 described in more detail at 40 https://www.khronos.org/registry/OpenGL/docs/update_policy.php 41 42Status 43 44 Complete. Approved by the ARB at the 2010/01/22 F2F meeting. 45 Approved by the Khronos Board of Promoters on March 10, 2010. 46 47Version 48 49 Last Modified Date: October 30, 2019 50 Revision: 9 51 52Number 53 54 ARB Extension #77 55 56Dependencies 57 58 OpenGL 1.3 or ARB_texture_compression is required. 59 60 This extension is written against the OpenGL 3.2 Specification 61 (Compatibility Profile). 62 63Overview 64 65 This extension provides additional texture compression functionality 66 specific to the BPTC and BPTC_FLOAT compressed texture formats (called BC7 67 and BC6H respectively in Microsoft's DirectX API), subject to all the 68 requirements and limitations described by the extension 69 GL_ARB_texture_compression. 70 71 Traditional block compression methods as typified by s3tc and latc 72 compress a block of pixels into indicies along a gradient. This works well 73 for smooth images, but can have quality issues along sharp edges and 74 strong chrominance transitions. To improve quality in these problematic 75 cases, the BPTC formats can divide each block into multiple partitions, 76 each of which are compressed using an independent gradient. 77 78 In addition, it is desirable to directly support high dynamic range 79 imagery in compressed formats, which is accomplished by the BPTC_FLOAT 80 formats. 81 82IP Status 83 84 No known IP claims. 85 86New Procedures and Functions 87 88 None. 89 90New Tokens 91 92 Accepted by the <internalformat> parameter of TexImage2D, TexImage3D, 93 CopyTexImage2D, CopyTexImage3D, CompressedTexImage2DARB, and 94 CompressedTexImage3DARB and the <format> parameter of 95 CompressedTexSubImage2DARB and CompressedTexSubImage3DARB: 96 97 COMPRESSED_RGBA_BPTC_UNORM_ARB 0x8E8C 98 COMPRESSED_SRGB_ALPHA_BPTC_UNORM_ARB 0x8E8D 99 COMPRESSED_RGB_BPTC_SIGNED_FLOAT_ARB 0x8E8E 100 COMPRESSED_RGB_BPTC_UNSIGNED_FLOAT_ARB 0x8E8F 101 102 103Additions to Chapter 2 of the OpenGL 3.2 Specification (OpenGL Operation) 104 105 None. 106 107Additions to Chapter 3 of the OpenGL 3.2 Specification (Rasterization) 108 109 Add to Table 3.20: Generic and specific compressed internal formats 110 111 Compressed Internal Format Base Internal Format Type 112 ========================== ==================== ======== 113 COMPRESSED_RGBA_BPTC_UNORM_ARB RGBA Specific 114 COMPRESSED_SRGB_ALPHA_BPTC_UNORM_ARB RGBA Specific 115 COMPRESSED_RGB_BPTC_SIGNED_FLOAT_ARB RGB Specific 116 COMPRESSED_RGB_BPTC_UNSIGNED_FLOAT_ARB RGB Specific 117 118 119 Modify Section 3.9.2, Alternate Texture Image Specification Commands 120 121 (add to end of TexSubImage discussion, p.231 -- after edit from the 122 ARB_texture_compression spec) 123 124 If the internal format of the texture image being modified is 125 COMPRESSED_RGBA_BPTC_UNORM_ARB, COMPRESSED_SRGB_ALPHA_BPTC_UNORM_ARB, 126 COMPRESSED_RGB_BPTC_SIGNED_FLOAT_ARB, or 127 COMPRESSED_RGB_BPTC_UNSIGNED_FLOAT_ARB the texture is stored using the 128 specified BPTC compressed texture image format. Such images are easily 129 edited along 4x4 texel boundaries, so the limitations on TexSubImage2D, 130 TexSubImage3D, CopyTexSubImage2D, and CopyTexSubImage3D parameters are 131 relaxed. TexSubImage2D, TexSubImage3D, CopyTexSubImage2D, and 132 CopyTexSubImage3D will result in an INVALID_OPERATION error only if one of 133 the following conditions occurs: 134 135 * <width> is not a multiple of four, <width> plus <xoffset> is not 136 equal to TEXTURE_WIDTH, and either <xoffset> or <yoffset> is 137 non-zero; 138 139 * <height> is not a multiple of four, <height> plus <yoffset> is not 140 equal to TEXTURE_HEIGHT, and either <xoffset> or <yoffset> is 141 non-zero; or 142 143 * <xoffset> or <yoffset> is not a multiple of four. 144 145 The contents of any 4x4 block of texels of a BPTC compressed texture image 146 that does not intersect the area being modified are preserved during valid 147 TexSubImage2D, TexSubImage3D, CopyTexSubImage2D, and CopyTexSubImage3D 148 calls. 149 150 151 Add to Section 3.9.3, Compressed Texture Images (adding to the end of the 152 CompressedTexImage section introduced by the ARB_texture_compression spec) 153 154 If <internalformat> is COMPRESSED_RGBA_BPTC_UNORM_ARB, 155 COMPRESSED_SRGB_ALPHA_BPTC_UNORM_ARB, 156 COMPRESSED_RGB_BPTC_SIGNED_FLOAT_ARB, or 157 COMPRESSED_RGB_BPTC_UNSIGNED_FLOAT_ARB the compressed texture is stored 158 using the specified BPTC compressed texture image format. The BPTC 159 texture compression algorithm supports only 2D images without borders, 160 though 3D images can be compressed as multiple slices of compressed 2D 161 images. CompressedTexImage1DARB produces an INVALID_ENUM error if 162 <internalformat> is a BPTC format. CompressedTexImage2DARB and 163 CompressedTexImage3DARB will produce an INVALID_OPERATION error if 164 <border> is non-zero. 165 166 167 Add to Section 3.9.3, Compressed Texture Images (adding to the end of the 168 CompressedTexSubImage section introduced by the ARB_texture_compression 169 spec) 170 171 If the internal format of the texture image being modified is 172 COMPRESSED_RGBA_BPTC_UNORM_ARB, COMPRESSED_SRGB_ALPHA_BPTC_UNORM_ARB, 173 COMPRESSED_RGB_BPTC_SIGNED_FLOAT_ARB, or 174 COMPRESSED_RGB_BPTC_UNSIGNED_FLOAT_ARB the texture is stored using the 175 specified BPTC compressed texture image formats. Since the BPTC texture 176 compression algorithm supports only 2D images, CompressedTexSubImage1DARB 177 produces an INVALID_ENUM error if <format> is a BPTC format. Since BPTC 178 images are easily edited along 4x4 texel boundaries, the limitations on 179 CompressedTexSubImage2D and CompressedTexSubImage3D are relaxed. 180 CompressedTexSubImage2D and CompressedTexSubImage3D will result in an 181 INVALID_OPERATION error only if one of the following conditions occurs: 182 183 * <width> is not a multiple of four, and <width> plus <xoffset> is not 184 equal to TEXTURE_WIDTH; 185 186 * <height> is not a multiple of four, and <height> plus <yoffset> is 187 not equal to TEXTURE_HEIGHT; or 188 189 * <xoffset> or <yoffset> is not a multiple of four. 190 191 The contents of any 4x4 block of texels of a BPTC compressed texture image 192 that does not intersect the area being modified are preserved during valid 193 TexSubImage2D/3D and CopyTexSubImage2D/3D calls. 194 195Additions to Chapter 4 of the OpenGL 3.2 Specification (Per-Fragment 196Operations and the Frame Buffer) 197 198 None. 199 200Additions to Chapter 5 of the OpenGL 3.2 Specification (Special Functions) 201 202 None. 203 204Additions to Chapter 6 of the OpenGL 3.2 Specification (State and 205State Requests) 206 207 None. 208 209Additions to Appendix A of the OpenGL 3.2 Specification (Invariance) 210 211 None. 212 213Additions to the AGL/GLX/WGL Specifications 214 215 None. 216 217GLX Protocol 218 219 None. 220 221Errors 222 223 INVALID_ENUM is generated by CompressedTexImage1DARB if <internalformat> 224 is COMPRESSED_RGBA_BPTC_UNORM_ARB, COMPRESSED_SRGB_ALPHA_BPTC_UNORM_ARB, 225 COMPRESSED_RGB_BPTC_SIGNED_FLOAT_ARB, or 226 COMPRESSED_RGB_BPTC_UNSIGNED_FLOAT_ARB. 227 228 INVALID_OPERATION is generated by CompressedTexImage2DARB if 229 <internalformat> is COMPRESSED_RGBA_BPTC_UNORM_ARB, 230 COMPRESSED_SRGB_ALPHA_BPTC_UNORM_ARB, 231 COMPRESSED_RGB_BPTC_SIGNED_FLOAT_ARB, or 232 COMPRESSED_RGB_BPTC_UNSIGNED_FLOAT_ARB and <border> is not equal to zero. 233 234 INVALID_ENUM is generated by CompressedTexSubImage1DARB if <format> is 235 COMPRESSED_RGBA_BPTC_UNORM_ARB, COMPRESSED_SRGB_ALPHA_BPTC_UNORM_ARB, 236 COMPRESSED_RGB_BPTC_SIGNED_FLOAT_ARB, or 237 COMPRESSED_RGB_BPTC_UNSIGNED_FLOAT_ARB. 238 239 INVALID_OPERATION is generated by TexSubImage2D or CopyTexSubImage2D if 240 TEXTURE_INTERNAL_FORMAT is COMPRESSED_RGBA_BPTC_UNORM_ARB, 241 COMPRESSED_SRGB_ALPHA_BPTC_UNORM_ARB, 242 COMPRESSED_RGB_BPTC_SIGNED_FLOAT_ARB, or 243 COMPRESSED_RGB_BPTC_UNSIGNED_FLOAT_ARB and any of the following apply: 244 245 * <width> is not a multiple of four, <width> plus <xoffset> is not 246 equal to TEXTURE_WIDTH, and either <xoffset> or <yoffset> is 247 non-zero; 248 249 * <height> is not a multiple of four, <height> plus <yoffset> is not 250 equal to TEXTURE_HEIGHT, and either <xoffset> or <yoffset> is 251 non-zero; or 252 253 * <xoffset> or <yoffset> is not a multiple of four. 254 255 INVALID_OPERATION is generated by CompressedTexSubImage2D if 256 TEXTURE_INTERNAL_FORMAT is COMPRESSED_RGBA_BPTC_UNORM_ARB, 257 COMPRESSED_SRGB_ALPHA_BPTC_UNORM_ARB, 258 COMPRESSED_RGB_BPTC_SIGNED_FLOAT_ARB, or 259 COMPRESSED_RGB_BPTC_UNSIGNED_FLOAT_ARB and any of the following apply: 260 261 * <width> is not a multiple of four, and <width> plus <xoffset> is not 262 equal to TEXTURE_WIDTH; 263 264 * <height> is not a multiple of four, and <height> plus <yoffset> is 265 not equal to TEXTURE_HEIGHT; or 266 267 * <xoffset> or <yoffset> is not a multiple of four. 268 269 The following restrictions from the ARB_texture_compression specification 270 do not apply to BPTC texture formats, since subimage modification is 271 straightforward as long as the subimage is properly aligned. 272 273 DELETE: INVALID_OPERATION is generated by TexSubImage1D, TexSubImage2D, 274 DELETE: TexSubImage3D, CopyTexSubImage1D, CopyTexSubImage2D, or 275 DELETE: CopyTexSubImage3D if the internal format of the texture image is 276 DELETE: compressed and <xoffset>, <yoffset>, or <zoffset> does not equal 277 DELETE: -b, where b is value of TEXTURE_BORDER. 278 279 DELETE: INVALID_VALUE is generated by CompressedTexSubImage1DARB, 280 DELETE: CompressedTexSubImage2DARB, or CompressedTexSubImage3DARB if the 281 DELETE: entire texture image is not being edited: if <xoffset>, 282 DELETE: <yoffset>, or <zoffset> is greater than -b, <xoffset> + <width> is 283 DELETE: less than w+b, <yoffset> + <height> is less than h+b, or <zoffset> 284 DELETE: + <depth> is less than d+b, where b is the value of 285 DELETE: TEXTURE_BORDER, w is the value of TEXTURE_WIDTH, h is the value of 286 DELETE: TEXTURE_HEIGHT, and d is the value of TEXTURE_DEPTH. 287 288 See also errors in the GL_ARB_texture_compression specification. 289 290New State 291 292 In the "Textures" state table, increment the TEXTURE_INTERNAL_FORMAT 293 subscript for Z by 4 in the "Type" row. 294 295New Implementation Dependent State 296 297 None 298 299Appendix 300 301 BPTC Compressed Texture Image Format 302 303 Compressed texture images stored using the BPTC compressed image formats 304 are represented as a collection of 4x4 texel blocks, where each block 305 contains 128 bits of texel data. The image is encoded as a normal 2D 306 raster image in which each 4x4 block is treated as a single pixel. If a 307 BPTC image has a width or height that is not a multiple of four, the data 308 corresponding to texels outside the image are irrelevant and undefined. 309 310 When a BPTC image with a width of <w>, height of <h>, and block size of 311 <blocksize> (16 bytes) is decoded, the corresponding image size (in bytes) 312 is: 313 314 ceil(<w>/4) * ceil(<h>/4) * blocksize. 315 316 When decoding a BPTC image, the block containing the texel at offset 317 (<x>, <y>) begins at an offset (in bytes) relative to the base of the 318 image of: 319 320 blocksize * (ceil(<w>/4) * floor(<y>/4) + floor(<x>/4)). 321 322 The data corresponding to a specific texel (<x>, <y>) are extracted from a 323 4x4 texel block using a relative (x,y) value of 324 325 (<x> modulo 4, <y> modulo 4). 326 327 There are two distinct BPTC image formats each of which has two 328 variants. COMPRESSED_RGBA_BPTC_UNORM_ARB and 329 COMPRESSED_SRGB_ALPHA_BPTC_UNORM_ARB compress 8-bit fixed-point 330 data. COMPRESSED_RGB_BPTC_SIGNED_FLOAT_ARB and 331 COMPRESSED_RGB_BPTC_UNSIGNED_FLOAT_ARB compress high dynamic range 332 floating point values. The formats are similar, so the description of the 333 float format will reference significant sections of the UNORM description. 334 335 COMPRESSED_RGBA_BPTC_UNORM_ARB (and the SRGB_ALPHA equivalent): Each 4x4 336 block of texels consists of 128 bits of RGBA or SRGB_ALPHA image data. 337 338 Each block contains enough information to select and decode a pair of 339 colors called endpoints, interpolate between those endpoints in a variety 340 of ways, then remap the result into the final output. 341 342 Each block can contain data in one of eight modes. The mode is identified 343 by the lowest bits of the lowest byte. It is encoded as zero or more zeros 344 followed by a one. For example, using x to indicate a bit not included in 345 the mode number, mode 0 is encoded as xxxxxxx1 in the low byte in binary, 346 mode 5 is xx100000, and mode 7 is 10000000. Encoding the low byte as zero 347 is reserved and should not be used when encoding a BPTC texture. 348 349 All further decoding is driven by the values derived from the mode listed 350 in Table.M below. The fields in the block are always in the same order for 351 all modes. Starting at the lowest bit after the mode and going up from LSB 352 to MSB in byte stream order, these fields are: partition number, rotation, 353 index selection, color, alpha, per-endpoint P-bit, shared P-bit, primary 354 indices, and secondary indices. The number of bits to be read in each 355 field is determined directly from the table. 356 357 Each block can be divided into between 1 and 3 groups of pixels with 358 independent compression parameters called subsets. A texel in a block with 359 one subset is always considered to be in subset zero. Otherwise, a number 360 determined by the number of partition bits is used to look up in the 361 partition tables Table.P2 or Table.P3 for 2 and 3 subsets 362 respectively. This partitioning is indexed by the X and Y within the block 363 to generate the subset index. 364 365 Each block has two colors for each subset, stored first by endpoint, then 366 by subset, then by color. For example, a format with two subsets and five 367 color bits would have five bits of red for endpoint 0 of the first subset, 368 then five bits of red for endpoint 1, then the two ends of the second 369 subset, then green and blue stored similarly. If a block has non-zero 370 alpha bits, the alpha data follows the color data with the same 371 organization. If not, alpha is overridden to 1.0. These bits are treated 372 as the high bits of a fixed-point value in a byte. If the format has 373 shared P-bits, there are two endpoint bits, the lower of which applies to 374 both endpoints of subset 0 and the upper of which applies to both 375 endpoints of subset 1. If the format has a per-endpoint P-bits, then there 376 are 2*subsets P-bits stored in the same order as color and alpha. Both 377 kinds of P-bits are added as a bit below the color data stored in the 378 byte. So, for a format with 5 red bits, the P-bit ends up in bit 2. For 379 final scaling, the top bits of the value are replicated into any remaining 380 bits in the byte. For the preceding example, bits 6 and 7 would be written 381 to bits 0 and 1. 382 383 The endpoint colors are interpolated using index values stored in the 384 block. The index bits are stored in x-major order. Each index has the 385 number of bits indicated by the mode except for one special index per 386 subset called the anchor index. Since the ordering of the endpoints is 387 unimportant, we can save one bit on one index per subset by ordering the 388 endpoints such that the highest bit is guaranteed to be zero. In partition 389 zero, the anchor index is always index zero. In other partitions, the 390 anchor index is specified by tables Table.A2 and Table.A3. If secondary 391 index bits are present, they are read in the same manner. The anchor index 392 information is only used to determine the number of bits each index has 393 when it's read from the block data. 394 395 The endpoint color and alpha values used for final interpolation are the 396 decoded values corresponding to the applicable subset as selected 397 above. The index value for interpolating color comes from the secondary 398 index for the texel if the format has an index selection bit and its value 399 is one and from the primary index otherwise. The alpha index comes from 400 the secondary index if the block has a secondary index and the block 401 either doesn't have an index selection bit or that bit is zero and the 402 primary index otherwise. 403 404 Interpolation is always performed using a 6-bit interpolation factor. The 405 effective interpolation factors for 2, 3, and 4 bit indices are given 406 below: 407 408 2: 0, 21, 43, 64 409 3: 0, 9, 18, 27, 37, 46, 55, 64 410 4: 0, 4, 9, 13, 17, 21, 26, 30, 34, 38, 43, 47, 51, 55, 60, 64 411 412 The interpolation results in an RGBA color. If rotation bits are present, 413 this color is remapped according to: 414 415 0: no change 416 1: swap(a,r) 417 2: swap(a,g) 418 3: swap(a,b) 419 420 These 8-bit values show up in the shader interpreted as either RGBA8 or 421 SRGB8_ALPHA8 for COMPRESSED_RGBA_BPTC_UNORM_ARB and 422 COMPRESSED_SRGB_ALPHA_BPTC_UNORM_ARB respectively. 423 424 425 Table.M 426 427 Mode NS PB RB ISB CB AB EPB SPB IB IB2 428 ---- -- -- -- --- -- -- --- --- -- --- 429 0 3 4 0 0 4 0 1 0 3 0 430 1 2 6 0 0 6 0 0 1 3 0 431 2 3 6 0 0 5 0 0 0 2 0 432 3 2 6 0 0 7 0 1 0 2 0 433 4 1 0 2 1 5 6 0 0 2 3 434 5 1 0 2 0 7 8 0 0 2 2 435 6 1 0 0 0 7 7 1 0 4 0 436 7 2 6 0 0 5 5 1 0 2 0 437 438 The columns are as as follows: 439 440 Mode: As described above 441 442 NS: Number of subsets in each partition 443 444 PB: Partition bits 445 446 RB: Rotation bits 447 448 ISB: Index selection bits 449 450 CB: Color bits 451 452 AB: Alpha bits 453 454 EPB: Endpoint P-bits 455 456 SPB: Shared P-bits 457 458 IB: Index bits per element 459 460 IB2: Secondary index bits per element 461 462 463 Table.P2 464 465 (each row is one 4x4 block) 466 467 468 0,0,1,1,0,0,1,1,0,0,1,1,0,0,1,1 469 0,0,0,1,0,0,0,1,0,0,0,1,0,0,0,1 470 0,1,1,1,0,1,1,1,0,1,1,1,0,1,1,1 471 0,0,0,1,0,0,1,1,0,0,1,1,0,1,1,1 472 0,0,0,0,0,0,0,1,0,0,0,1,0,0,1,1 473 0,0,1,1,0,1,1,1,0,1,1,1,1,1,1,1 474 0,0,0,1,0,0,1,1,0,1,1,1,1,1,1,1 475 0,0,0,0,0,0,0,1,0,0,1,1,0,1,1,1 476 0,0,0,0,0,0,0,0,0,0,0,1,0,0,1,1 477 0,0,1,1,0,1,1,1,1,1,1,1,1,1,1,1 478 0,0,0,0,0,0,0,1,0,1,1,1,1,1,1,1 479 0,0,0,0,0,0,0,0,0,0,0,1,0,1,1,1 480 0,0,0,1,0,1,1,1,1,1,1,1,1,1,1,1 481 0,0,0,0,0,0,0,0,1,1,1,1,1,1,1,1 482 0,0,0,0,1,1,1,1,1,1,1,1,1,1,1,1 483 0,0,0,0,0,0,0,0,0,0,0,0,1,1,1,1 484 0,0,0,0,1,0,0,0,1,1,1,0,1,1,1,1 485 0,1,1,1,0,0,0,1,0,0,0,0,0,0,0,0 486 0,0,0,0,0,0,0,0,1,0,0,0,1,1,1,0 487 0,1,1,1,0,0,1,1,0,0,0,1,0,0,0,0 488 0,0,1,1,0,0,0,1,0,0,0,0,0,0,0,0 489 0,0,0,0,1,0,0,0,1,1,0,0,1,1,1,0 490 0,0,0,0,0,0,0,0,1,0,0,0,1,1,0,0 491 0,1,1,1,0,0,1,1,0,0,1,1,0,0,0,1 492 0,0,1,1,0,0,0,1,0,0,0,1,0,0,0,0 493 0,0,0,0,1,0,0,0,1,0,0,0,1,1,0,0 494 0,1,1,0,0,1,1,0,0,1,1,0,0,1,1,0 495 0,0,1,1,0,1,1,0,0,1,1,0,1,1,0,0 496 0,0,0,1,0,1,1,1,1,1,1,0,1,0,0,0 497 0,0,0,0,1,1,1,1,1,1,1,1,0,0,0,0 498 0,1,1,1,0,0,0,1,1,0,0,0,1,1,1,0 499 0,0,1,1,1,0,0,1,1,0,0,1,1,1,0,0 500 0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1 501 0,0,0,0,1,1,1,1,0,0,0,0,1,1,1,1 502 0,1,0,1,1,0,1,0,0,1,0,1,1,0,1,0 503 0,0,1,1,0,0,1,1,1,1,0,0,1,1,0,0 504 0,0,1,1,1,1,0,0,0,0,1,1,1,1,0,0 505 0,1,0,1,0,1,0,1,1,0,1,0,1,0,1,0 506 0,1,1,0,1,0,0,1,0,1,1,0,1,0,0,1 507 0,1,0,1,1,0,1,0,1,0,1,0,0,1,0,1 508 0,1,1,1,0,0,1,1,1,1,0,0,1,1,1,0 509 0,0,0,1,0,0,1,1,1,1,0,0,1,0,0,0 510 0,0,1,1,0,0,1,0,0,1,0,0,1,1,0,0 511 0,0,1,1,1,0,1,1,1,1,0,1,1,1,0,0 512 0,1,1,0,1,0,0,1,1,0,0,1,0,1,1,0 513 0,0,1,1,1,1,0,0,1,1,0,0,0,0,1,1 514 0,1,1,0,0,1,1,0,1,0,0,1,1,0,0,1 515 0,0,0,0,0,1,1,0,0,1,1,0,0,0,0,0 516 0,1,0,0,1,1,1,0,0,1,0,0,0,0,0,0 517 0,0,1,0,0,1,1,1,0,0,1,0,0,0,0,0 518 0,0,0,0,0,0,1,0,0,1,1,1,0,0,1,0 519 0,0,0,0,0,1,0,0,1,1,1,0,0,1,0,0 520 0,1,1,0,1,1,0,0,1,0,0,1,0,0,1,1 521 0,0,1,1,0,1,1,0,1,1,0,0,1,0,0,1 522 0,1,1,0,0,0,1,1,1,0,0,1,1,1,0,0 523 0,0,1,1,1,0,0,1,1,1,0,0,0,1,1,0 524 0,1,1,0,1,1,0,0,1,1,0,0,1,0,0,1 525 0,1,1,0,0,0,1,1,0,0,1,1,1,0,0,1 526 0,1,1,1,1,1,1,0,1,0,0,0,0,0,0,1 527 0,0,0,1,1,0,0,0,1,1,1,0,0,1,1,1 528 0,0,0,0,1,1,1,1,0,0,1,1,0,0,1,1 529 0,0,1,1,0,0,1,1,1,1,1,1,0,0,0,0 530 0,0,1,0,0,0,1,0,1,1,1,0,1,1,1,0 531 0,1,0,0,0,1,0,0,0,1,1,1,0,1,1,1 532 533 Table.P3 534 535 0,0,1,1,0,0,1,1,0,2,2,1,2,2,2,2 536 0,0,0,1,0,0,1,1,2,2,1,1,2,2,2,1 537 0,0,0,0,2,0,0,1,2,2,1,1,2,2,1,1 538 0,2,2,2,0,0,2,2,0,0,1,1,0,1,1,1 539 0,0,0,0,0,0,0,0,1,1,2,2,1,1,2,2 540 0,0,1,1,0,0,1,1,0,0,2,2,0,0,2,2 541 0,0,2,2,0,0,2,2,1,1,1,1,1,1,1,1 542 0,0,1,1,0,0,1,1,2,2,1,1,2,2,1,1 543 0,0,0,0,0,0,0,0,1,1,1,1,2,2,2,2 544 0,0,0,0,1,1,1,1,1,1,1,1,2,2,2,2 545 0,0,0,0,1,1,1,1,2,2,2,2,2,2,2,2 546 0,0,1,2,0,0,1,2,0,0,1,2,0,0,1,2 547 0,1,1,2,0,1,1,2,0,1,1,2,0,1,1,2 548 0,1,2,2,0,1,2,2,0,1,2,2,0,1,2,2 549 0,0,1,1,0,1,1,2,1,1,2,2,1,2,2,2 550 0,0,1,1,2,0,0,1,2,2,0,0,2,2,2,0 551 0,0,0,1,0,0,1,1,0,1,1,2,1,1,2,2 552 0,1,1,1,0,0,1,1,2,0,0,1,2,2,0,0 553 0,0,0,0,1,1,2,2,1,1,2,2,1,1,2,2 554 0,0,2,2,0,0,2,2,0,0,2,2,1,1,1,1 555 0,1,1,1,0,1,1,1,0,2,2,2,0,2,2,2 556 0,0,0,1,0,0,0,1,2,2,2,1,2,2,2,1 557 0,0,0,0,0,0,1,1,0,1,2,2,0,1,2,2 558 0,0,0,0,1,1,0,0,2,2,1,0,2,2,1,0 559 0,1,2,2,0,1,2,2,0,0,1,1,0,0,0,0 560 0,0,1,2,0,0,1,2,1,1,2,2,2,2,2,2 561 0,1,1,0,1,2,2,1,1,2,2,1,0,1,1,0 562 0,0,0,0,0,1,1,0,1,2,2,1,1,2,2,1 563 0,0,2,2,1,1,0,2,1,1,0,2,0,0,2,2 564 0,1,1,0,0,1,1,0,2,0,0,2,2,2,2,2 565 0,0,1,1,0,1,2,2,0,1,2,2,0,0,1,1 566 0,0,0,0,2,0,0,0,2,2,1,1,2,2,2,1 567 0,0,0,0,0,0,0,2,1,1,2,2,1,2,2,2 568 0,2,2,2,0,0,2,2,0,0,1,2,0,0,1,1 569 0,0,1,1,0,0,1,2,0,0,2,2,0,2,2,2 570 0,1,2,0,0,1,2,0,0,1,2,0,0,1,2,0 571 0,0,0,0,1,1,1,1,2,2,2,2,0,0,0,0 572 0,1,2,0,1,2,0,1,2,0,1,2,0,1,2,0 573 0,1,2,0,2,0,1,2,1,2,0,1,0,1,2,0 574 0,0,1,1,2,2,0,0,1,1,2,2,0,0,1,1 575 0,0,1,1,1,1,2,2,2,2,0,0,0,0,1,1 576 0,1,0,1,0,1,0,1,2,2,2,2,2,2,2,2 577 0,0,0,0,0,0,0,0,2,1,2,1,2,1,2,1 578 0,0,2,2,1,1,2,2,0,0,2,2,1,1,2,2 579 0,0,2,2,0,0,1,1,0,0,2,2,0,0,1,1 580 0,2,2,0,1,2,2,1,0,2,2,0,1,2,2,1 581 0,1,0,1,2,2,2,2,2,2,2,2,0,1,0,1 582 0,0,0,0,2,1,2,1,2,1,2,1,2,1,2,1 583 0,1,0,1,0,1,0,1,0,1,0,1,2,2,2,2 584 0,2,2,2,0,1,1,1,0,2,2,2,0,1,1,1 585 0,0,0,2,1,1,1,2,0,0,0,2,1,1,1,2 586 0,0,0,0,2,1,1,2,2,1,1,2,2,1,1,2 587 0,2,2,2,0,1,1,1,0,1,1,1,0,2,2,2 588 0,0,0,2,1,1,1,2,1,1,1,2,0,0,0,2 589 0,1,1,0,0,1,1,0,0,1,1,0,2,2,2,2 590 0,0,0,0,0,0,0,0,2,1,1,2,2,1,1,2 591 0,1,1,0,0,1,1,0,2,2,2,2,2,2,2,2 592 0,0,2,2,0,0,1,1,0,0,1,1,0,0,2,2 593 0,0,2,2,1,1,2,2,1,1,2,2,0,0,2,2 594 0,0,0,0,0,0,0,0,0,0,0,0,2,1,1,2 595 0,0,0,2,0,0,0,1,0,0,0,2,0,0,0,1 596 0,2,2,2,1,2,2,2,0,2,2,2,1,2,2,2 597 0,1,0,1,2,2,2,2,2,2,2,2,2,2,2,2 598 0,1,1,1,2,0,1,1,2,2,0,1,2,2,2,0 599 600 Table.A2 (Anchor index values for the second subset of two-subset 601 partitioning) 602 603 (wrapped for readability - values run right then down) 604 605 15,15,15,15,15,15,15,15, 606 15,15,15,15,15,15,15,15, 607 15, 2, 8, 2, 2, 8, 8,15, 608 2, 8, 2, 2, 8, 8, 2, 2, 609 15,15, 6, 8, 2, 8,15,15, 610 2, 8, 2, 2, 2,15,15, 6, 611 6, 2, 6, 8,15,15, 2, 2, 612 15,15,15,15,15, 2, 2,15, 613 614 Table.A3a (Anchor index values for the second subset of three-subset 615 partitioning) 616 617 (wrapped for readability - values run right then down) 618 619 3, 3,15,15, 8, 3,15,15, 620 8, 8, 6, 6, 6, 5, 3, 3, 621 3, 3, 8,15, 3, 3, 6,10, 622 5, 8, 8, 6, 8, 5,15,15, 623 8,15, 3, 5, 6,10, 8,15, 624 15, 3,15, 5,15,15,15,15, 625 3,15, 5, 5, 5, 8, 5,10, 626 5,10, 8,13,15,12, 3, 3, 627 628 Table.A3b (Anchor index values for the third subset of three-subset 629 partitioning) 630 631 (wrapped for readability - values run right then down) 632 633 15, 8, 8, 3,15,15, 3, 8, 634 15,15,15,15,15,15,15, 8, 635 15, 8,15, 3,15, 8,15, 8, 636 3,15, 6,10,15,15,10, 8, 637 15, 3,15,10,10, 8, 9,10, 638 6,15, 8,15, 3, 6, 6, 8, 639 15, 3,15,15,15,15,15,15, 640 15,15,15,15, 3,15,15, 8, 641 642 COMPRESSED_RGB_BPTC_SIGNED_FLOAT_ARB and 643 COMPRESSED_RGB_BPTC_UNSIGNED_FLOAT_ARB: Each 4x4 block of texels consists 644 of 128 bits of RGB data. These formats are very similar and will be 645 described together. In the description and pseudocode below, <signed> will 646 be used as a condition which is true for the SIGNED format and false for 647 the UNSIGNED format. Both formats only contain RGB data, so the returned 648 alpha value is 1.0. If a block uses a reserved or invalid encoding, the 649 return value is (0,0,0,1). 650 651 Each block can contain data in one of 14 modes. The mode number is encoded 652 in either the low two bits or the low five bits. If the low two bits are 653 less than two, that is the mode number, otherwise the low five bits the 654 mode number. Mode numbers not listed in Table.MF are reserved (19, 23, 27, 655 and 31). 656 657 The data for the compressed blocks is stored in a different format for 658 each mode. The formats are specified in Table.F. The format strings are 659 intended to be read from left to right with the LSB on the left. Each 660 element is of the form v[a:b]. If a>=b, this indicates to extract b-a+1 661 bits from the block at that location and put it in the corresponding bits 662 of the variable v. If a<b, then the bits are reversed. v[a] is used as a 663 shorthand for the one bit v[a:a]. As an example, m[1:0],g2[4] would move 664 the low two bits from the block into the low two bits of m then the next 665 bit of the block into bit 4 of g2. The variable names given in the table 666 will be referred to in the language below. 667 668 Subsets and indices work in much the same way as described for the 669 fixed-point formats above. If a float block has no partition bits, then it 670 is a single-subset block. If it has partition bits, then it is a 2 subset 671 block. The partition index references the first half of Table.P2. Indices 672 are read in the same way as the fixed-point formats including obeying the 673 anchor values for index 0 and as needed by Table.A2. 674 675 In a single-subset blocks, the two endpoints are contained in r0,g0,b0 676 (hence e0) and r1,g1,b1 (hence e1). In a two-subset block, the endpoints 677 for the second subset are in r2,g2,b2 and r3,g3,b3. The value in e0 is 678 sign-extended if the format of the texture is signed. The values in e1 and 679 e2 and e3 if the block is two-subset are sign-extended if the format of 680 the texture is signed or if the block mode has transformed endpoints. If 681 the mode has transformed endpoints, the values from e0 are used as a base 682 to offset all other endpoints, wrapped at the number of endpoint bits. For 683 example, r1 = (r0+r1) & ((1<<EPB)-1). 684 685 Next, the endpoints are unquantized to maximize the usage of the bits and 686 to ensure that the negative ranges are oriented properly to interpolate as 687 a two's complement value. The following pseudocode assumes the computation 688 is being done using sufficiently large intermediate values to avoid 689 overflow. For the unsigned float format, we unquantize a value x to unq 690 by: 691 692 if (EPB >= 15) 693 unq = x; 694 else if (x == 0) 695 unq = 0; 696 else if (x == ((1<<EPB)-1)) 697 unq = 0xFFFF; 698 else 699 unq = ((x << 15) + 0x4000) >> (EPB-1); 700 701 The signed float unquantization is similar, but needs to worry about 702 orienting the negative range: 703 704 s = 0; 705 if (EPB >= 16) 706 unq = x; 707 else { 708 if (x < 0) { 709 s = 1; 710 x = -x; 711 } 712 713 if (x == 0) 714 unq = 0; 715 else if (x >= ((1<<(EPB-1))-1)) 716 unq = 0x7FFF; 717 else 718 unq = ((x << 15) + 0x4000) >> (EPB-1); 719 720 if (s) 721 unq = -unq; 722 } 723 724 After the endpoints are unquantized, interpolation proceeds as in the 725 fixed-point formats above including the interpolation weight table. 726 727 The interpolated values are passed through a final unquantization 728 step. For the unsigned format, this step simply multiplies by 31/64. The 729 signed format negates negative components, multiplies by 31/32, then or's 730 in the sign bit if the original value was negative. 731 732 The resultant value should be a legal 16-bit half float which is then 733 returned as a float to the shader. 734 735 Table.MF 736 737 MN Tr PB EPB Delta Bits 738 -- -- -- --- ---------- 739 0 1 5 10 {5, 5, 5} 740 1 1 5 7 {6, 6, 6} 741 2 1 5 11 {5, 4, 4} 742 6 1 5 11 {4, 5, 4} 743 10 1 5 11 {4, 4, 5} 744 14 1 5 9 {5, 5, 5} 745 18 1 5 8 {6, 5, 5} 746 22 1 5 8 {5, 6, 5} 747 26 1 5 8 {5, 5, 6} 748 30 0 5 6 {6, 6, 6} 749 3 0 0 10 {10, 10, 10} 750 7 1 0 11 {9, 9, 9} 751 11 1 0 12 {8, 8, 8} 752 15 1 0 16 {4, 4, 4} 753 754 MN: Mode number 755 Tr: Transformed endpoints 756 PB: Partition bits 757 EPB: Endpoint bits 758 759 760 Table.F 761 762 MN Format 763 -- ------------------------------------------------------------------------ 764 0 m[1:0],g2[4],b2[4],b3[4],r0[9:0],g0[9:0],b0[9:0],r1[4:0],g3[4],g2[3:0], 765 g1[4:0],b3[0],g3[3:0],b1[4:0],b3[1],b2[3:0],r2[4:0],b3[2],r3[4:0],b3[3] 766 767 1 m[1:0],g2[5],g3[4],g3[5],r0[6:0],b3[0],b3[1],b2[4],g0[6:0],b2[5],b3[2], 768 g2[4],b0[6:0],b3[3],b3[5],b3[4],r1[5:0],g2[3:0],g1[5:0],g3[3:0],b1[5:0], 769 b2[3:0],r2[5:0],r3[5:0] 770 771 2 m[4:0],r0[9:0],g0[9:0],b0[9:0],r1[4:0],r0[10],g2[3:0],g1[3:0],g0[10], 772 b3[0],g3[3:0],b1[3:0],b0[10],b3[1],b2[3:0],r2[4:0],b3[2],r3[4:0],b3[3] 773 774 6 m[4:0],r0[9:0],g0[9:0],b0[9:0],r1[3:0],r0[10],g3[4],g2[3:0],g1[4:0], 775 g0[10],g3[3:0],b1[3:0],b0[10],b3[1],b2[3:0],r2[3:0],b3[0],b3[2],r3[3:0], 776 g2[4],b3[3] 777 778 10 m[4:0],r0[9:0],g0[9:0],b0[9:0],r1[3:0],r0[10],b2[4],g2[3:0],g1[3:0], 779 g0[10],b3[0],g3[3:0],b1[4:0],b0[10],b2[3:0],r2[3:0],b3[1],b3[2],r3[3:0], 780 b3[4],b3[3] 781 782 14 m[4:0],r0[8:0],b2[4],g0[8:0],g2[4],b0[8:0],b3[4],r1[4:0],g3[4],g2[3:0], 783 g1[4:0],b3[0],g3[3:0],b1[4:0],b3[1],b2[3:0],r2[4:0],b3[2],r3[4:0],b3[3] 784 785 18 m[4:0],r0[7:0],g3[4],b2[4],g0[7:0],b3[2],g2[4],b0[7:0],b3[3],b3[4], 786 r1[5:0],g2[3:0],g1[4:0],b3[0],g3[3:0],b1[4:0],b3[1],b2[3:0],r2[5:0], 787 r3[5:0] 788 789 22 m[4:0],r0[7:0],b3[0],b2[4],g0[7:0],g2[5],g2[4],b0[7:0],g3[5],b3[4], 790 r1[4:0],g3[4],g2[3:0],g1[5:0],g3[3:0],b1[4:0],b3[1],b2[3:0],r2[4:0], 791 b3[2],r3[4:0],b3[3] 792 793 26 m[4:0],r0[7:0],b3[1],b2[4],g0[7:0],b2[5],g2[4],b0[7:0],b3[5],b3[4], 794 r1[4:0],g3[4],g2[3:0],g1[4:0],b3[0],g3[3:0],b1[5:0],b2[3:0],r2[4:0], 795 b3[2],r3[4:0],b3[3] 796 797 30 m[4:0],r0[5:0],g3[4],b3[0],b3[1],b2[4],g0[5:0],g2[5],b2[5],b3[2], 798 g2[4],b0[5:0],g3[5],b3[3],b3[5],b3[4],r1[5:0],g2[3:0],g1[5:0],g3[3:0], 799 b1[5:0],b2[3:0],r2[5:0],r3[5:0] 800 801 3 m[4:0],r0[9:0],g0[9:0],b0[9:0],r1[9:0],g1[9:0],b1[9:0] 802 803 7 m[4:0],r0[9:0],g0[9:0],b0[9:0],r1[8:0],r0[10],g1[8:0],g0[10],b1[8:0], 804 b0[10] 805 806 11 m[4:0],r0[9:0],g0[9:0],b0[9:0],r1[7:0],r0[10:11],g1[7:0],g0[10:11], 807 b1[7:0],b0[10:11] 808 809 15 m[4:0],r0[9:0],g0[9:0],b0[9:0],r1[3:0],r0[10:15],g1[3:0],g0[10:15], 810 b1[3:0],b0[10:15] 811 812 813Issues 814 815 (1) Are both RGB and RGBA versions interesting? 816 817 RESOLVED. Not for the unorm formats. Every BPTC mode has a defined 818 alpha, so an RGB mode isn't needed. Also, since modes are per-block, a 819 given texture can have both RGB1 and RGBA portions. 820 821 The float formats don't compress alpha at all, so they only have RGB 822 variants, not RGBA. 823 824 (2) Put both BC7 and BC6H in the same spec? 825 826 RESOLVED. Yes. They share enough that it's worthwhile to amortize the 827 "overhead". 828 829 (3) Why are there two versions of the float BPTC formats for signed and 830 unsigned? Do they pass through the GL differently? 831 832 RESOLVED. The unsigned formats are decoded distinctly from signed 833 formats, so it is necessary to distinguish between them. 834 835 The values still pass through the shader and the pixel path as signed 836 floats, but the interpretation of the compressed block changes as 837 described. 838 839 (4) Should the result of the compressed float formats be half floats or 840 single floats? 841 842 RESOLVED. The expansion from packed to half to float will be specified 843 as part of the decompression process. 844 845 (5) What should be expected for a driver compressor for these formats? 846 847 RESOLVED: The current best known compression algorithms have to 848 exhaustively test all partitionings across all modes. The compressor in 849 the GL will have to make a tradeoff between performance and 850 quality. Compressing offline is highly recommended. 851 852 (6) How should floating point specials (Inf and NaN) be handled in the 853 float formats? 854 855 RESOLVED: Decompressor will never generate them. Compressor should 856 flush to max half float. 857 858 (7) Does this spec require bit-exact decompression? 859 860 RESOLVED: Yes. 861 862 (8) Does the data format depend on the endianness of the system? 863 864 RESOLVED: No. The data is interpeted as an endian-independent 865 byte stream. 866 867 (9) What should be the internal format of the floating-point BPTC format? 868 869 RESOLVED: The format has three components, with the alpha component 870 mapped to 1.0, just like RGB textures. So we should call it RGB. 871 872 In the originally ratified version of this extension (and all versions 873 prior to January 20, 2011), such textures were treated as having a base 874 internal format of RGBA, where the alpha component was not present in 875 the texture and instead is just set to the constant 1.0. Some 876 implementations of this extension may also use a base internal format 877 of RGBA. 878 879 There are very few places where there is a difference between an RGB 880 texture and an RGBA texture where alpha is always 1.0. Two known 881 differences: 882 883 * A compressed "RGB" texture could be used for the generic 884 COMPRESSED_RGB format, but an "RGBA" texture should not be. 885 However, it seems unlikely that implementations would choose the 886 floating-point BPTC format as its generic COMPRESSED_RGB format. 887 888 * Using fixed-function fragment shading in the compatibility profile, 889 a texture environment mode of REPLACE would leave alpha unmodified 890 for RGB base formats but would replace the fragment alpha with the 891 texture alpha (constant 1.0 here) for RGBA base formats. 892 893Revision History 894 895 Rev. Date Author Changes 896 ---- -------- ----------- -------------------------------------------- 897 9 30/10/19 pdaniell Fix shared p-bits specification to match 898 DX and the Khronos Data Format spec. 899 900 8 06/06/16 Nanley Chery Reduce the requirements to the minimal set. 901 902 7 01/20/11 pbrown Change the base internal format of the floating- 903 point BPTC formats from "RGBA" to "RGB" (bug 904 7231). 905 906 6 01/19/11 Jon Leech Fix state table modification for 907 TEXTURE_INTERNAL_FORMAT (Bug 7239). 908 909 5 05/20/10 ewerness Finalize some UNRESOLVED issues 910 911 4 04/09/10 pdaniell Modify for inclusion into OpenGL 4.1. 912 913 3 12/07/09 pdaniell ARBify. 914 915 2 10/13/09 ewerness Fix errors in the anchor index tables caused 916 by incorrect conversion scripts and a couple 917 typos in the input. 918 919 1 ewerness Internal revisions. 920 921