KhronosGroup
Table 63, ASTC DFD example is wrong
It has two errors.
- It gives
sampleUpperas0x7F800000Uwhich is NaN (infinity). It should be0x3F800000Ufor 1.0f. - It shows it as signed (sign bit set and
sampleLoweris -1.0f). ASTC cannot encode values < 0.
ASTC can encode negative values but only in void-extent (solid-color) HDR blocks.
ASTC can encode negative values but only in void-extent (solid-color) HDR blocks.
Then what should the DFD show? I understand from @fluppeteer that the Vulkan spec is going to be changed to say the ASTC HDR formats are unsigned and VK_FORMAT_ASTC_*_UFLOAT aliases will be added.
UASTC HDR has just been released with sampleLower 0.0f and the channelType sign bit unset. If it needs to be changed we need to act quickly.
Regardless of the answer to the above, sampleUpper is broken.
Then what should the DFD show?
Based on the current state of the ASTC specs, solid color ASTC HDR blocks can technically represent both positive and negative infinities as well as NaNs because they simply contain raw half-float values. The spec says however:
In the HDR case, if the color component values are infinity or NaN, this will result in undefined behavior.
I'm reading this as "hardware sampling from such blocks is undefined", but there's nothing inherently wrong with data itself.
It may be that formal support for infinities, NaNs, and negative values in solid-color ASTC HDR blocks is just a spec oversight and therefore all ASTC users should assume only non-negative finite values.
Sorry for the delay in this (and everything else). I believe the consensus is that everyone's hardware actually does pass through negative void extent blocks correctly - so, while it would be kind of esoteric to do so, I don't think it's actually invalid for a user to encode negative values in ASTC, and if someone wanted to encode void extent blocks with a negative then they could. I think we leave ASTC HDR as signed (which seemed to be the consensus from the Vulkan discussions, unless I'm mis-remembering), and it's up to UASTC HDR to report that the encoding of negative void-extent blocks is unsupported. I don't think that's a problem - not all the other things that ASTC can represent are supported either (notably in terms of block sizes).
I'm assuming I can close this as "won't fix" unless there's push back?
Oh, sorry. Yes, I do have that fix applied locally, and should be in whatever I share today. "Partial fix", then. :-)