1Name 2 3 EXT_texture_compression_s3tc 4 5Name Strings 6 7 GL_EXT_texture_compression_s3tc 8 9Contact 10 11 Pat Brown, NVIDIA Corporation (pbrown 'at' nvidia.com) 12 13Status 14 15 FINAL 16 17Version 18 19 1.1, 16 November 2001 (containing only clarifications relative to 20 version 1.0, dated 7 July 2000) 21 22Number 23 24 198 25 26Dependencies 27 28 OpenGL 1.1 is required. 29 30 GL_ARB_texture_compression is required. 31 32 This extension is written against the OpenGL 1.2.1 Specification. 33 34Overview 35 36 This extension provides additional texture compression functionality 37 specific to S3's S3TC format (called DXTC in Microsoft's DirectX API), 38 subject to all the requirements and limitations described by the extension 39 GL_ARB_texture_compression. 40 41 This extension supports DXT1, DXT3, and DXT5 texture compression formats. 42 For the DXT1 image format, this specification supports an RGB-only mode 43 and a special RGBA mode with single-bit "transparent" alpha. 44 45IP Status 46 47 Contact S3 Incorporated (http://www.s3.com) regarding any intellectual 48 property issues associated with implementing this extension. 49 50 WARNING: Vendors able to support S3TC texture compression in Direct3D 51 drivers do not necessarily have the right to use the same functionality in 52 OpenGL. 53 54Issues 55 56 (1) Should DXT2 and DXT4 (premultiplied alpha) formats be supported? 57 58 RESOLVED: No -- insufficient interest. Supporting DXT2 and DXT4 59 would require some rework to the TexEnv definition (maybe add a new 60 base internal format RGBA_PREMULTIPLIED_ALPHA) for these formats. 61 Note that the EXT_texture_env_combine extension (which extends normal 62 TexEnv modes) can be used to support textures with premultipled alpha. 63 64 (2) Should generic "RGB_S3TC_EXT" and "RGBA_S3TC_EXT" enums be supported 65 or should we use only the DXT<n> enums? 66 67 RESOLVED: No. A generic RGBA_S3TC_EXT is problematic because DXT3 68 and DXT5 are both nominally RGBA (and DXT1 with the 1-bit alpha is 69 also) yet one format must be chosen up front. 70 71 (3) Should TexSubImage support all block-aligned edits or just the minimal 72 functionality required by the ARB_texture_compression extension? 73 74 RESOLVED: Allow all valid block-aligned edits. 75 76 (4) A pre-compressed image with a DXT1 format can be used as either an 77 RGB_S3TC_DXT1 or an RGBA_S3TC_DXT1 image. If the image has 78 transparent texels, how are they treated in each format? 79 80 RESOLVED: The renderer has to make sure that an RGB_S3TC_DXT1 format 81 is decoded as RGB (where alpha is effectively one for all texels), 82 while RGBA_S3TC_DXT1 is decoded as RGBA (where alpha is zero for all 83 texels with "transparent" encodings). Otherwise, the formats are 84 identical. 85 86 (5) Is the encoding of the RGB components for DXT1 formats correct in this 87 spec? MSDN documentation does not specify an RGB color for the 88 "transparent" encoding. Is it really black? 89 90 RESOLVED: Yes. The specification for the DXT1 format initially 91 required black, but later changed that requirement to a 92 recommendation. All vendors involved in the definition of this 93 specification support black. In addition, specifying black has a 94 useful behavior. 95 96 When blending multiple texels (GL_LINEAR filtering), mixing opaque and 97 transparent samples is problematic. Defining a black color on 98 transparent texels achieves a sensible result that works like a 99 texture with premultiplied alpha. For example, if three opaque white 100 and one transparent sample is being averaged, the result would be a 101 75% intensity gray (with an alpha of 75%). This is the same result on 102 the color channels as would be obtained using a white color, 75% 103 alpha, and a SRC_ALPHA blend factor. 104 105 (6) Is the encoding of the RGB components for DXT3 and DXT5 formats 106 correct in this spec? MSDN documentation suggests that the RGB blocks 107 for DXT3 and DXT5 are decoded as described by the DXT1 format. 108 109 RESOLVED: Yes -- this appears to be a bug in the MSDN documentation. 110 The specification for the DXT2-DXT5 formats require decoding using the 111 opaque block encoding, regardless of the relative values of "color0" 112 and "color1". 113 114New Procedures and Functions 115 116 None. 117 118New Tokens 119 120 Accepted by the <internalformat> parameter of TexImage2D, CopyTexImage2D, 121 and CompressedTexImage2DARB and the <format> parameter of 122 CompressedTexSubImage2DARB: 123 124 COMPRESSED_RGB_S3TC_DXT1_EXT 0x83F0 125 COMPRESSED_RGBA_S3TC_DXT1_EXT 0x83F1 126 COMPRESSED_RGBA_S3TC_DXT3_EXT 0x83F2 127 COMPRESSED_RGBA_S3TC_DXT5_EXT 0x83F3 128 129Additions to Chapter 2 of the OpenGL 1.2.1 Specification (OpenGL Operation) 130 131 None. 132 133Additions to Chapter 3 of the OpenGL 1.2.1 Specification (Rasterization) 134 135 Add to Table 3.16.1: Specific Compressed Internal Formats 136 137 Compressed Internal Format Base Internal Format 138 ========================== ==================== 139 COMPRESSED_RGB_S3TC_DXT1_EXT RGB 140 COMPRESSED_RGBA_S3TC_DXT1_EXT RGBA 141 COMPRESSED_RGBA_S3TC_DXT3_EXT RGBA 142 COMPRESSED_RGBA_S3TC_DXT5_EXT RGBA 143 144 145 Modify Section 3.8.2, Alternate Image Specification 146 147 (add to end of TexSubImage discussion, p.123 -- after edit from the 148 ARB_texture_compression spec) 149 150 If the internal format of the texture image being modified is 151 COMPRESSED_RGB_S3TC_DXT1_EXT, COMPRESSED_RGBA_S3TC_DXT1_EXT, 152 COMPRESSED_RGBA_S3TC_DXT3_EXT, or COMPRESSED_RGBA_S3TC_DXT5_EXT, the 153 texture is stored using one of the several S3TC compressed texture image 154 formats. Such images are easily edited along 4x4 texel boundaries, so the 155 limitations on TexSubImage2D or CopyTexSubImage2D parameters are relaxed. 156 TexSubImage2D and CopyTexSubImage2D will result in an INVALID_OPERATION 157 error only if one of the following conditions occurs: 158 159 * <width> is not a multiple of four or equal to TEXTURE_WIDTH, 160 unless <xoffset> and <yoffset> are both zero. 161 * <height> is not a multiple of four or equal to TEXTURE_HEIGHT, 162 unless <xoffset> and <yoffset> are both zero. 163 * <xoffset> or <yoffset> is not a multiple of four. 164 165 The contents of any 4x4 block of texels of an S3TC compressed texture 166 image that does not intersect the area being modified are preserved during 167 valid TexSubImage2D and CopyTexSubImage2D calls. 168 169 170 Add to Section 3.8.2, Alternate Image Specification (adding to the end of 171 the CompressedTexImage section introduced by the ARB_texture_compression 172 spec) 173 174 If <internalformat> is COMPRESSED_RGB_S3TC_DXT1_EXT, 175 COMPRESSED_RGBA_S3TC_DXT1_EXT, COMPRESSED_RGBA_S3TC_DXT3_EXT, or 176 COMPRESSED_RGBA_S3TC_DXT5_EXT, the compressed texture is stored using one 177 of several S3TC compressed texture image formats. The S3TC texture 178 compression algorithm supports only 2D images without borders. 179 CompressedTexImage1DARB and CompressedTexImage3DARB produce an 180 INVALID_ENUM error if <internalformat> is an S3TC format. 181 CompressedTexImage2DARB will produce an INVALID_OPERATION error if 182 <border> is non-zero. 183 184 185 Add to Section 3.8.2, Alternate Image Specification (adding to the end of 186 the CompressedTexSubImage section introduced by the 187 ARB_texture_compression spec) 188 189 If the internal format of the texture image being modified is 190 COMPRESSED_RGB_S3TC_DXT1_EXT, COMPRESSED_RGBA_S3TC_DXT1_EXT, 191 COMPRESSED_RGBA_S3TC_DXT3_EXT, or COMPRESSED_RGBA_S3TC_DXT5_EXT, the 192 texture is stored using one of the several S3TC compressed texture image 193 formats. Since the S3TC texture compression algorithm supports only 2D 194 images, CompressedTexSubImage1DARB and CompressedTexSubImage3DARB produce 195 an INVALID_ENUM error if <format> is an S3TC format. Since S3TC images 196 are easily edited along 4x4 texel boundaries, the limitations on 197 CompressedTexSubImage2D are relaxed. CompressedTexSubImage2D will result 198 in an INVALID_OPERATION error only if one of the following conditions 199 occurs: 200 201 * <width> is not a multiple of four or equal to TEXTURE_WIDTH. 202 * <height> is not a multiple of four or equal to TEXTURE_HEIGHT. 203 * <xoffset> or <yoffset> is not a multiple of four. 204 205 The contents of any 4x4 block of texels of an S3TC compressed texture 206 image that does not intersect the area being modified are preserved during 207 valid TexSubImage2D and CopyTexSubImage2D calls. 208 209Additions to Chapter 4 of the OpenGL 1.2.1 Specification (Per-Fragment 210Operations and the Frame Buffer) 211 212 None. 213 214Additions to Chapter 5 of the OpenGL 1.2.1 Specification (Special Functions) 215 216 None. 217 218Additions to Chapter 6 of the OpenGL 1.2.1 Specification (State and 219State Requests) 220 221 None. 222 223Additions to Appendix A of the OpenGL 1.2.1 Specification (Invariance) 224 225 None. 226 227Additions to the AGL/GLX/WGL Specifications 228 229 None. 230 231GLX Protocol 232 233 None. 234 235Errors 236 237 INVALID_ENUM is generated by CompressedTexImage1DARB or 238 CompressedTexImage3DARB if <internalformat> is 239 COMPRESSED_RGB_S3TC_DXT1_EXT, COMPRESSED_RGBA_S3TC_DXT1_EXT, 240 COMPRESSED_RGBA_S3TC_DXT3_EXT, or COMPRESSED_RGBA_S3TC_DXT5_EXT. 241 242 INVALID_OPERATION is generated by CompressedTexImage2DARB if 243 <internalformat> is COMPRESSED_RGB_S3TC_DXT1_EXT, 244 COMPRESSED_RGBA_S3TC_DXT1_EXT, COMPRESSED_RGBA_S3TC_DXT3_EXT, or 245 COMPRESSED_RGBA_S3TC_DXT5_EXT and <border> is not equal to zero. 246 247 INVALID_ENUM is generated by CompressedTexSubImage1DARB or 248 CompressedTexSubImage3DARB if <format> is COMPRESSED_RGB_S3TC_DXT1_EXT, 249 COMPRESSED_RGBA_S3TC_DXT1_EXT, COMPRESSED_RGBA_S3TC_DXT3_EXT, or 250 COMPRESSED_RGBA_S3TC_DXT5_EXT. 251 252 INVALID_OPERATION is generated by TexSubImage2D CopyTexSubImage2D, or 253 CompressedTexSubImage2D if TEXTURE_INTERNAL_FORMAT is 254 COMPRESSED_RGB_S3TC_DXT1_EXT, COMPRESSED_RGBA_S3TC_DXT1_EXT, 255 COMPRESSED_RGBA_S3TC_DXT3_EXT, or COMPRESSED_RGBA_S3TC_DXT5_EXT and any of 256 the following apply: <width> is not a multiple of four or equal to 257 TEXTURE_WIDTH; <height> is not a multiple of four or equal to 258 TEXTURE_HEIGHT; <xoffset> or <yoffset> is not a multiple of four. 259 260 261 The following restrictions from the ARB_texture_compression specification 262 do not apply to S3TC texture formats, since subimage modification is 263 straightforward as long as the subimage is properly aligned. 264 265 DELETE: INVALID_OPERATION is generated by TexSubImage1D, TexSubImage2D, 266 DELETE: TexSubImage3D, CopyTexSubImage1D, CopyTexSubImage2D, or 267 DELETE: CopyTexSubImage3D if the internal format of the texture image is 268 DELETE: compressed and <xoffset>, <yoffset>, or <zoffset> does not equal 269 DELETE: -b, where b is value of TEXTURE_BORDER. 270 271 DELETE: INVALID_VALUE is generated by CompressedTexSubImage1DARB, 272 DELETE: CompressedTexSubImage2DARB, or CompressedTexSubImage3DARB if the 273 DELETE: entire texture image is not being edited: if <xoffset>, 274 DELETE: <yoffset>, or <zoffset> is greater than -b, <xoffset> + <width> is 275 DELETE: less than w+b, <yoffset> + <height> is less than h+b, or <zoffset> 276 DELETE: + <depth> is less than d+b, where b is the value of 277 DELETE: TEXTURE_BORDER, w is the value of TEXTURE_WIDTH, h is the value of 278 DELETE: TEXTURE_HEIGHT, and d is the value of TEXTURE_DEPTH. 279 280 See also errors in the GL_ARB_texture_compression specification. 281 282New State 283 284 In the "Textures" state table, increment the TEXTURE_INTERNAL_FORMAT 285 subscript for Z by 4 in the "Type" row. 286 287New Implementation Dependent State 288 289 None 290 291Appendix 292 293 S3TC Compressed Texture Image Formats 294 295 Compressed texture images stored using the S3TC compressed image formats 296 are represented as a collection of 4x4 texel blocks, where each block 297 contains 64 or 128 bits of texel data. The image is encoded as a normal 298 2D raster image in which each 4x4 block is treated as a single pixel. If 299 an S3TC image has a width or height less than four, the data corresponding 300 to texels outside the image are irrelevant and undefined. 301 302 When an S3TC image with a width of <w>, height of <h>, and block size of 303 <blocksize> (8 or 16 bytes) is decoded, the corresponding image size (in 304 bytes) is: 305 306 ceil(<w>/4) * ceil(<h>/4) * blocksize. 307 308 When decoding an S3TC image, the block containing the texel at offset 309 (<x>, <y>) begins at an offset (in bytes) relative to the base of the 310 image of: 311 312 blocksize * (ceil(<w>/4) * floor(<y>/4) + floor(<x>/4)). 313 314 The data corresponding to a specific texel (<x>, <y>) are extracted from a 315 4x4 texel block using a relative (x,y) value of 316 317 (<x> modulo 4, <y> modulo 4). 318 319 There are four distinct S3TC image formats: 320 321 COMPRESSED_RGB_S3TC_DXT1_EXT: Each 4x4 block of texels consists of 64 322 bits of RGB image data. 323 324 Each RGB image data block is encoded as a sequence of 8 bytes, called (in 325 order of increasing address): 326 327 c0_lo, c0_hi, c1_lo, c1_hi, bits_0, bits_1, bits_2, bits_3 328 329 The 8 bytes of the block are decoded into three quantities: 330 331 color0 = c0_lo + c0_hi * 256 332 color1 = c1_lo + c1_hi * 256 333 bits = bits_0 + 256 * (bits_1 + 256 * (bits_2 + 256 * bits_3)) 334 335 color0 and color1 are 16-bit unsigned integers that are unpacked to 336 RGB colors RGB0 and RGB1 as though they were 16-bit packed pixels with 337 a <format> of RGB and a type of UNSIGNED_SHORT_5_6_5. 338 339 bits is a 32-bit unsigned integer, from which a two-bit control code 340 is extracted for a texel at location (x,y) in the block using: 341 342 code(x,y) = bits[2*(4*y+x)+1..2*(4*y+x)+0] 343 344 where bit 31 is the most significant and bit 0 is the least 345 significant bit. 346 347 The RGB color for a texel at location (x,y) in the block is given by: 348 349 RGB0, if color0 > color1 and code(x,y) == 0 350 RGB1, if color0 > color1 and code(x,y) == 1 351 (2*RGB0+RGB1)/3, if color0 > color1 and code(x,y) == 2 352 (RGB0+2*RGB1)/3, if color0 > color1 and code(x,y) == 3 353 354 RGB0, if color0 <= color1 and code(x,y) == 0 355 RGB1, if color0 <= color1 and code(x,y) == 1 356 (RGB0+RGB1)/2, if color0 <= color1 and code(x,y) == 2 357 BLACK, if color0 <= color1 and code(x,y) == 3 358 359 Arithmetic operations are done per component, and BLACK refers to an 360 RGB color where red, green, and blue are all zero. 361 362 Since this image has an RGB format, there is no alpha component and the 363 image is considered fully opaque. 364 365 366 COMPRESSED_RGBA_S3TC_DXT1_EXT: Each 4x4 block of texels consists of 64 367 bits of RGB image data and minimal alpha information. The RGB components 368 of a texel are extracted in the same way as COMPRESSED_RGB_S3TC_DXT1_EXT. 369 370 The alpha component for a texel at location (x,y) in the block is 371 given by: 372 373 0.0, if color0 <= color1 and code(x,y) == 3 374 1.0, otherwise 375 376 IMPORTANT: When encoding an RGBA image into a format using 1-bit 377 alpha, any texels with an alpha component less than 0.5 end up with an 378 alpha of 0.0 and any texels with an alpha component greater than or 379 equal to 0.5 end up with an alpha of 1.0. When encoding an RGBA image 380 into the COMPRESSED_RGBA_S3TC_DXT1_EXT format, the resulting red, 381 green, and blue components of any texels with a final alpha of 0.0 382 will automatically be zero (black). If this behavior is not desired 383 by an application, it should not use COMPRESSED_RGBA_S3TC_DXT1_EXT. 384 This format will never be used when a generic compressed internal 385 format (Table 3.16.2) is specified, although the nearly identical 386 format COMPRESSED_RGB_S3TC_DXT1_EXT (above) may be. 387 388 389 COMPRESSED_RGBA_S3TC_DXT3_EXT: Each 4x4 block of texels consists of 64 390 bits of uncompressed alpha image data followed by 64 bits of RGB image 391 data. 392 393 Each RGB image data block is encoded according to the 394 COMPRESSED_RGB_S3TC_DXT1_EXT format, with the exception that the two code 395 bits always use the non-transparent encodings. In other words, they are 396 treated as though color0 > color1, regardless of the actual values of 397 color0 and color1. 398 399 Each alpha image data block is encoded as a sequence of 8 bytes, called 400 (in order of increasing address): 401 402 a0, a1, a2, a3, a4, a5, a6, a7 403 404 The 8 bytes of the block are decoded into one 64-bit integer: 405 406 alpha = a0 + 256 * (a1 + 256 * (a2 + 256 * (a3 + 256 * (a4 + 407 256 * (a5 + 256 * (a6 + 256 * a7)))))) 408 409 alpha is a 64-bit unsigned integer, from which a four-bit alpha value 410 is extracted for a texel at location (x,y) in the block using: 411 412 alpha(x,y) = bits[4*(4*y+x)+3..4*(4*y+x)+0] 413 414 where bit 63 is the most significant and bit 0 is the least 415 significant bit. 416 417 The alpha component for a texel at location (x,y) in the block is 418 given by alpha(x,y) / 15. 419 420 421 COMPRESSED_RGBA_S3TC_DXT5_EXT: Each 4x4 block of texels consists of 64 422 bits of compressed alpha image data followed by 64 bits of RGB image data. 423 424 Each RGB image data block is encoded according to the 425 COMPRESSED_RGB_S3TC_DXT1_EXT format, with the exception that the two code 426 bits always use the non-transparent encodings. In other words, they are 427 treated as though color0 > color1, regardless of the actual values of 428 color0 and color1. 429 430 Each alpha image data block is encoded as a sequence of 8 bytes, called 431 (in order of increasing address): 432 433 alpha0, alpha1, bits_0, bits_1, bits_2, bits_3, bits_4, bits_5 434 435 The alpha0 and alpha1 are 8-bit unsigned bytes converted to alpha 436 components by multiplying by 1/255. 437 438 The 6 "bits" bytes of the block are decoded into one 48-bit integer: 439 440 bits = bits_0 + 256 * (bits_1 + 256 * (bits_2 + 256 * (bits_3 + 441 256 * (bits_4 + 256 * bits_5)))) 442 443 bits is a 48-bit unsigned integer, from which a three-bit control code 444 is extracted for a texel at location (x,y) in the block using: 445 446 code(x,y) = bits[3*(4*y+x)+1..3*(4*y+x)+0] 447 448 where bit 47 is the most significant and bit 0 is the least 449 significant bit. 450 451 The alpha component for a texel at location (x,y) in the block is 452 given by: 453 454 alpha0, code(x,y) == 0 455 alpha1, code(x,y) == 1 456 457 (6*alpha0 + 1*alpha1)/7, alpha0 > alpha1 and code(x,y) == 2 458 (5*alpha0 + 2*alpha1)/7, alpha0 > alpha1 and code(x,y) == 3 459 (4*alpha0 + 3*alpha1)/7, alpha0 > alpha1 and code(x,y) == 4 460 (3*alpha0 + 4*alpha1)/7, alpha0 > alpha1 and code(x,y) == 5 461 (2*alpha0 + 5*alpha1)/7, alpha0 > alpha1 and code(x,y) == 6 462 (1*alpha0 + 6*alpha1)/7, alpha0 > alpha1 and code(x,y) == 7 463 464 (4*alpha0 + 1*alpha1)/5, alpha0 <= alpha1 and code(x,y) == 2 465 (3*alpha0 + 2*alpha1)/5, alpha0 <= alpha1 and code(x,y) == 3 466 (2*alpha0 + 3*alpha1)/5, alpha0 <= alpha1 and code(x,y) == 4 467 (1*alpha0 + 4*alpha1)/5, alpha0 <= alpha1 and code(x,y) == 5 468 0.0, alpha0 <= alpha1 and code(x,y) == 6 469 1.0, alpha0 <= alpha1 and code(x,y) == 7 470 471 472Revision History 473 474 1.1, 11/16/01 pbrown: Updated contact info, clarified where texels 475 fall within a single block. 476 477 1.0, 07/07/00 prbrown1: Published final version agreed to by working 478 group members. 479 480 0.9, 06/24/00 prbrown1: Documented that block-aligned TexSubImage calls 481 do not modify existing texels outside the 482 modified blocks. Added caveat to allow for a 483 (0,0)-anchored TexSubImage operation of 484 arbitrary size. 485 486 0.7, 04/11/00 prbrown1: Added issues on DXT1, DXT3, and DXT5 encodings 487 where the MSDN documentation doesn't match what 488 is really done. Added enum values from the 489 extension registry. 490 491 0.4, 03/28/00 prbrown1: Updated to reflect final version of the 492 ARB_texture_compression extension. Allowed 493 block-aligned TexSubImage calls. 494 495 0.3, 03/07/00 prbrown1: Resolved issues pertaining to the format of RGB 496 blocks in the DXT3 and DXT5 formats (they don't 497 ever use the "transparent" encoding). Fixed 498 decoding of DXT1 blocks. Pointed out issue of 499 "transparent" texels in DXT1 encodings having 500 different behaviors for RGB and RGBA internal 501 formats. 502 503 0.2, 02/23/00 prbrown1: Minor revisions; added several issues. 504 505 0.11, 02/17/00 prbrown1: Slight modification to error semantics 506 (INVALID_ENUM instead of INVALID_OPERATION). 507 508 0.1, 02/15/00 prbrown1: Initial revision. 509