Open lexaknyazev opened 5 years ago
Hi,
Does it imply that 3D slices are supported as well?
Good question. My reading is that it can be supported, but is not required (since ASTC format requirements are only spelled out for 2D images).
VK_EXT_astc_decode_mode
defines decoding process for HDR blocks. Was it done just for future-proofing the extension (and for better alignment with OpenGL'sEXT_texture_compression_astc_decode_mode
) since there are noVkFormat
enums for ASTC HDR?
Yes.
My reading is that it can be supported, but is not required...
OK. Is it safe to assume that existing LDR VkFormat enums can be used with 3D targets (when supported)?
Maybe.. It looks it like works on our (Arm's) implementation. But AFAICT there's no conformance test coverage for this, so I can't speak for anyone else. (I'll see if we can get the CTS coverage.)
@janharaldfredriksen-arm Were you able to get the CTS coverage?
Don't forget this extension which is required for Mali/Qualcomm to treat ASTC in a sane way in the texture cache. Really unfortunate that this isn't the default.
https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VK_EXT_astc_decode_mode.html
With OpenGL, ASTC support was split into several extensions that stack functionality like this:
2D (Array),
Cube (Array)
In Vulkan,
VkPhysicalDeviceFeatures.textureCompressionASTC_LDR
and_UNORM_
in formats' names hint that only LDR blocks are supported.VK_EXT_astc_decode_mode
defines decoding process for HDR blocks. Was it done just for future-proofing the extension (and for better alignment with OpenGL'sEXT_texture_compression_astc_decode_mode
) since there are noVkFormat
enums for ASTC HDR?