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