Safe Haskell	Safe-Inferred
Language	Haskell2010

Vulkan.Extensions.VK_EXT_texture_compression_astc_hdr

Description

Name

VK_EXT_texture_compression_astc_hdr - device extension

VK_EXT_texture_compression_astc_hdr

Name String: VK_EXT_texture_compression_astc_hdr

Extension Type

Device extension

Registered Extension Number

67

Revision

1

Extension and Version Dependencies

Requires support for Vulkan 1.0
Requires VK_KHR_get_physical_device_properties2 to be enabled for any device-level functionality

Deprecation state

Promoted to Vulkan 1.3

Contact

Jan-Harald Fredriksen @janharaldfredriksen-arm%0A*Here describe the issue or question you have about the VK_EXT_texture_compression_astc_hdr extension*

Other Extension Metadata

Last Modified Date: 2019-05-28

Interactions and External Dependencies

Promoted to Vulkan 1.3 Core

IP Status

No known issues.

Contributors

Jan-Harald Fredriksen, Arm

Description

This extension adds support for textures compressed using the Adaptive Scalable Texture Compression (ASTC) High Dynamic Range (HDR) profile.

When this extension is enabled, the HDR profile is supported for all ASTC formats listed in ASTC Compressed Image Formats.

New Structures

Extending PhysicalDeviceFeatures2, DeviceCreateInfo:
- PhysicalDeviceTextureCompressionASTCHDRFeaturesEXT

New Enum Constants

EXT_TEXTURE_COMPRESSION_ASTC_HDR_EXTENSION_NAME

Promotion to Vulkan 1.3

This extension has been partially promoted. Functionality in this extension is included in core Vulkan 1.3, with the EXT suffix omitted. However, the feature is made optional in Vulkan 1.3. The original type, enum and command names are still available as aliases of the core functionality.

Issues

1) Should we add a feature or limit for this functionality?

Yes. It is consistent with the ASTC LDR support to add a feature like textureCompressionASTC_HDR.

The feature is strictly speaking redundant as long as this is just an extension; it would be sufficient to just enable the extension. But adding the feature is more forward-looking if wanted to make this an optional core feature in the future.

2) Should we introduce new format enums for HDR?

Yes. Vulkan 1.0 describes the ASTC format enums as UNORM, e.g. FORMAT_ASTC_4x4_UNORM_BLOCK, so it is confusing to make these contain HDR data. Note that the OpenGL (ES) extensions did not make this distinction because a single ASTC HDR texture may contain both unorm and float blocks. Implementations may not be able to distinguish between LDR and HDR ASTC textures internally and just treat them as the same format, i.e. if this extension is supported then sampling from a FORMAT_ASTC_4x4_UNORM_BLOCK image format may return HDR results. Applications can get predictable results by using the appropriate image format.