1Name 2 3 EXT_texture_compression_astc_decode_mode 4 5Name Strings 6 7 GL_EXT_texture_compression_astc_decode_mode 8 GL_EXT_texture_compression_astc_decode_mode_rgb9e5 9 10Contact 11 12 Jan-Harald Fredriksen (jan-harald.fredriksen 'at' arm.com) 13 14Contributors 15 16 Edvard Fielding 17 Jan-Harald Fredriksen 18 Jakob Fries 19 Tom Olson 20 Jorn Nystad 21 22IP Status 23 24 No known issues. 25 26Status 27 28 DRAFT 29 30Version 31 32 Version 4, January 23, 2017 33 34Number 35 36 OpenGL ES Extension #276 37 38Dependencies 39 40 OpenGL ES 3.0 is required. 41 42 GL_KHR_texture_compression_astc_hdr, GL_KHR_texture_compression_astc_ldr, 43 or GL_OES_texture_compression_astc is required. 44 45 This extension is written based on the wording of the OpenGL ES 3.2 46 specification and the GL_KHR_texture_compression_astc_hdr extension. 47 48 This extension interacts with GL_KHR_texture_compression_astc_hdr. 49 50Overview 51 52 Adaptive Scalable Texture Compression (ASTC) is a texture compression 53 technology that is exposed by existing extensions and specifications. 54 55 The existing specifications require that low dynamic range (LDR) 56 textures are decompressed to FP16 values per component. In many cases, 57 decompressing LDR textures to a lower precision intermediate result gives 58 acceptable image quality. Source material for LDR textures is typically 59 authored as 8-bit UNORM values, so decoding to FP16 values adds little 60 value. On the other hand, reducing precision of the decoded result 61 reduces the size of the decompressed data, potentially improving texture 62 cache performance and saving power. 63 64 The goal of this extension is to enable this efficiency gain on existing 65 ASTC texture data. This is achieved by giving the application the ability 66 to select the decoding precision. 67 68 Two decoding options are provided by 69 GL_EXT_texture_compression_astc_decode_mode 70 - Decode to FP16: This is the default, and matches the required behavior 71 in existing APIs. 72 - Decode to UNORM8: This is provided as an option in LDR mode. 73 74 If GL_EXT_texture_compression_astc_decode_mode_rgb9e5 is supported, then 75 a third decoding option is provided: 76 - Decode to RGB9_E5: This is provided as an option in both LDR and HDR 77 mode. In this mode, negative values cannot be represented and are 78 clamped to zero. The alpha component is ignored, and the results 79 are as if alpha was 1.0. 80 81New Procedures and Functions 82 83 None 84 85New Tokens 86 87 Accepted by the <pname> parameter of TexParameter* and GetTexParameter*: 88 89 TEXTURE_ASTC_DECODE_PRECISION_EXT 0x8F69 90 91Changes to 8.10 Texture Parameters 92 93 Add to Table 8.19: Texture parameters and their values: 94 95 ----------------------------------------------------------------------------- 96 Name Type Legal Values 97 ----------------------------------------------------------------------------- 98 TEXTURE_ASTC_DECODE_PRECISION_EXT enum GL_RGBA16F 99 GL_RGBA8 100 GL_RGB9_E5 (*) 101 ----------------------------------------------------------------------------- 102 103 (*) Note: GL_RGB9_E5 is legal if and only if the 104 GL_EXT_texture_compression_astc_decode_mode_rgb9e5 extension is supported. 105 106Changes to C.2.5 LDR and HDR Modes 107 108 In Table C.2.1 (Differences Between LDR and HDR Modes) in KHR_texture_compression_astc_hdr: 109 110 Modify the first row of the table to read: 111 112 ----------------------------------------------------------------------------- 113 Operation LDR Mode HDR Mode 114 ----------------------------------------------------------------------------- 115 Returned value Determined by the Determined by the 116 decoding mode decoding mode 117 118 <the rest of the table remains unchanged> 119 ----------------------------------------------------------------------------- 120 Table C.2.1 - Differences Between LDR and HDR Modes 121 122 123 Add the following paragraph immediately after Table C.2.1: 124 125 The type of the values returned by the decoding process is determined by API 126 state as follows: 127 128 ----------------------------------------------------------------------------- 129 Decode mode LDR Mode HDR Mode 130 ----------------------------------------------------------------------------- 131 GL_RGBA16F Vector of FP16 values Vector of FP16 values 132 GL_RGBA8 Vector of UNORM8 values <invalid> 133 GL_RGB9_E5 Vector using a shared Vector using a shared 134 exponent format exponent format 135 ----------------------------------------------------------------------------- 136 Table C.2.1.a - Decoding mode 137 138 [[ HDR profile only ]] 139 Using the GL_RGBA8 decoding mode in HDR mode gives undefined results. 140 141 For sRGB output, the decoding mode is ignored, and the decoding always returns 142 a vector of UNORM8 values. 143 144 If the texture does not have an ASTC format, the decoding mode is ignored. 145 146 147 [[ If GL_EXT_texture_compression_astc_decode_mode_rgb9e5 and HDR profile 148 is supported, then add the following paragraph after the second paragraph 149 following Table C.2.1 ]] 150 151 When using the GL_RGB9_E5 decoding mode in HDR mode, error results 152 will return the error color because NaN cannot be represented. 153 154 155Changes to C.2.19 (Weight Application) 156 157 Replace the paragraph immediately after the expression for the value C in 158 LDR mode with the following: 159 160 If sRGB conversion is not enabled and the decoding mode is GL_RGBA16F, 161 then if C = 65535, then the final result is 1.0 (0x3C00) otherwise C is divided by 162 65536 and the infinite-precision result of the division is converted to FP16 with 163 round-to-zero semantics. 164 165 If sRGB conversion is not enabled and the decoding mode is GL_RGBA8, 166 then top 8 bits of the interpolation result for the R, G, B, and A channels 167 are used as the final result. 168 169 [[ The following two paragraph applies to 170 GL_EXT_texture_compression_astc_decode_mode_rgb9e5 only. ]] 171 172 If sRGB conversion is not enabled and the decoding mode is GL_RGB9_E5, 173 then the final result is a combination of the (UNORM16) values of C for the three 174 color components (Cr, Cg, and Cb) computed as follows: 175 176 int lz = clz17( Cr | Cg | Cb | 1); 177 if (Cr == 65535 ) { Cr = 65536; lz = 0; } 178 if (Cg == 65535 ) { Cg = 65536; lz = 0; } 179 if (Cb == 65535 ) { Cb = 65536; lz = 0; } 180 Cr <<= lz; 181 Cg <<= lz; 182 Cb <<= lz; 183 Cr = (Cr >> 8) & 0x1FF; 184 Cg = (Cg >> 8) & 0x1FF; 185 Cb = (Cb >> 8) & 0x1FF; 186 uint32_t exponent = 16 - lz; 187 188 uint32_t texel = (exponent << 27) | (Cb << 18) | (Cg << 9) | Cr; 189 190 The clz17() function counts leading zeros in a 17-bit value. 191 192 193 If sRGB conversion is enabled, then the decoding mode is ignored, 194 and the top 8 bits of the interpolation result for the R, G and B 195 channels are passed to the external sRGB conversion block and used 196 as the final result. 197 198 199 [[ If GL_EXT_texture_compression_astc_decode_mode_rgb9e5 and HDR profile 200 is supported, then add the following at the end of the section. ]] 201 202 If the decoding mode is GL_RGB9_E5, then the final result 203 is a combination of the (IEEE FP16) values of Cf for the three color 204 components (Cr, Cg, and Cb) computed as follows: 205 206 if( Cr > 0x7c00 ) Cr = 0; else if( Cr == 0x7c00 ) Cr = 0x7bff; 207 if( Cg > 0x7c00 ) Cg = 0; else if( Cg == 0x7c00 ) Cg = 0x7bff; 208 if( Cb > 0x7c00 ) Cb = 0; else if( Cb == 0x7c00 ) Cb = 0x7bff; 209 int Re = (Cr >> 10) & 0x1F; 210 int Ge = (Cg >> 10) & 0x1F; 211 int Be = (Cb >> 10) & 0x1F; 212 int Rex = Re == 0 ? 1 : Re; 213 int Gex = Ge == 0 ? 1 : Ge; 214 int Bex = Be == 0 ? 1 : Be; 215 int Xm = ((Cr | Cg | Cb) & 0x200) >> 9; 216 int Xe = Re | Ge | Be; 217 uint32_t rshift, gshift, bshift, expo; 218 219 if (Xe == 0) 220 { 221 expo = rshift = gshift = bshift = Xm; 222 } 223 else if (Re >= Ge && Re >= Be) 224 { 225 expo = Rex + 1; 226 rshift = 2; 227 gshift = Rex - Gex + 2; 228 bshift = Rex - Bex + 2; 229 } 230 else if (Ge >= Be) 231 { 232 expo = Gex + 1; 233 rshift = Gex - Rex + 2; 234 gshift = 2; 235 bshift = Gex - Bex + 2; 236 } 237 else 238 { 239 expo = Bex + 1; 240 rshift = Bex - Rex + 2; 241 gshift = Bex - Gex + 2; 242 bshift = 2; 243 } 244 245 int Rm = (Cr & 0x3FF) | (Re == 0 ? 0 : 0x400); 246 int Gm = (Cg & 0x3FF) | (Ge == 0 ? 0 : 0x400); 247 int Bm = (Cb & 0x3FF) | (Be == 0 ? 0 : 0x400); 248 Rm = (Rm >> rshift) & 0x1FF; 249 Gm = (Gm >> gshift) & 0x1FF; 250 Bm = (Bm >> bshift) & 0x1FF; 251 252 uint32_t texel = (expo << 27) | (Bm << 18) | (Gm << 9) | (Rm << 0); 253 254Changes to C.2.23 (Void-Extent Blocks) 255 256 [[ If GL_EXT_texture_compression_astc_decode_mode_rgb9e5 and HDR profile 257 is supported, then add the following paragraph. ]] 258 259 In the HDR case, if the decoding mode is GL_RGB9_E5, then 260 any negative color component values are set to 0 before conversion to 261 the shared exponent format (as described in C.2.19). 262 263New State 264 265 In Table 21.10: Textures (state per texture object), add: 266 267 Get value Type Get Command Initial value Description Section 268 ---- ---- ------------- ------------- ----------- ------- 269 TEXTURE_ASTC_DECODE_- E GetTexParameter GL_RGBA16F Decode mode C.2.5 270 PRECISION_EXT 271 272 273Interactions with GL_KHR_texture_compression_astc_hdr 274 275 If GL_KHR_texture_compression_astc_hdr is not supported, then the 276 HDR profile is not supported, all references to HDR are removed. 277 278Issues 279 280 (1) Should we include the GL_RGB9_E5 mode? 281 282 Proposed: Yes. 283 284 (2) Are implementations allowed to decode at a higher precision than 285 what is requested? 286 287 Proposed: No. 288 289 If we allow this, then this extension could be exposed on all 290 implementations that support ASTC. But developers would have no 291 way of knowing what precision was actually used, and thus whether 292 image quality is sufficient at reduced precision. 293 294 (3) What happens to values in void-extent blocks that are infinity or 295 NaN when using GL_RGB9_E5? 296 297 Resolved: Undefined behavior. 298 299 KHR_texture_compression_astc_hdr already makes this undefined: 300 301 "In the HDR case, if the color component values are infinity or NaN, 302 this will result in undefined behavior. As usual, this must not lead 303 to GL interruption or termination." 304 305 (4) Should there be an error or a texture completeness rule when using 306 the GL_RGBA8 decoding mode for HDR mode blocks? 307 308 Resolved: No. There is no way for implementations to check this 309 condition short of iterating through all the blocks of the texture. 310 311 (5) Should the decode mode be texture image state and/or sampler state? 312 313 Resolved: Texture image state only. Some implementations effectively 314 treat the the different decode modes as different texture formats. 315 316Revision History 317 318 Revision 4, January 23, 2017 - Split functionality in two name strings. 319 Clarified interaction with 320 KHR_texture_compression_astc_hdr 321 Added issue 5. 322 Revision 3, January 18, 2017 - Tidy up. 323 Revision 2, December 6, 2016 - Fixed type errors in rounding operation. 324 Clarified behavior of negative values in 325 void-extent blocks when decoding to shared 326 exponent format. 327 Revision 1, November 11, 2016 - Initial draft. 328 329