mirror of
https://github.com/status-im/Vulkan-Docs.git
synced 2025-02-25 12:35:11 +00:00
521e98405f
* Update release number to 120.
Github Issues:
* Add slink:VkAccelerationStructureTypeNV explicitly to extension XML for
`<<VK_NV_ray_tracing>>` (public issue 848).
* Add missing valid usage statements for feature flags in
slink:VkCommandBufferInheritanceInfo (public pull request 1017).
Internal Issues:
* Clarify behavior of non-premultiplied destination colors for
`<<VK_EXT_blend_operation_advanced>>` prior to the definition of
slink:VkBlendOverlapEXT (internal issue 1766).
* Fix the confusing phrasing "`no other queue must: be (doing something)`"
for flink:vkQueuePresentKHR, flink:vkQueueSubmit, and
flink:vkQueueBindSparse (internal issue 1774).
* Add `<<VK_EXT_validation_features>>` flag to enable best practices
checks, which will soon be available in the validation layer (internal
issue 1779).
* Specify allowed characters for VUID tag name components in the style
guide (internal issue 1788).
* Update links to SPIR-V extension specifications, and parameterize their
markup in case the URLs change in the future (internal issue 1797).
* Fix an off-by-one error in the valid usage statement for
slink:VkPipelineExecutableInfoKHR (internal merge request 3303).
* Clean up markup indentation not matching the style guide (internal merge
request 3314).
* Minor script updates to allow refpage aliases, generate a dynamic TOC
for refpages, generate Apache rewrite rules for aliases, open external
links from refpages in a new window, and synchronize with the OpenCL
scripts. This will shortly enable a paned navigation setup for refpages,
similar to the OpenCL 2.2 refpages (internal merge request 3322).
* Script updates to add tests to the checker, refactor and reformat code,
generate better text for some valid usage statements, use more Pythonic
idioms, and synchronize with the OpenXR scripts (internal merge request
3239).
* Script updates and minor fixes in spec language to not raise checker
errors for refpage markup of pages not existing in the API, such as
VKAPI_NO_STDINT_H. Remove corresponding suppression of some
check_spec_links.py tests from .gitlab-ci.yml and 'allchecks' target
(internal merge request 3315).
88 lines
2.6 KiB
Plaintext
88 lines
2.6 KiB
Plaintext
include::meta/VK_EXT_texture_compression_astc_hdr.txt[]
|
|
|
|
*Last Modified Date*::
|
|
2019-05-28
|
|
*IP Status*::
|
|
No known issues.
|
|
*Contributors*::
|
|
- Jan-Harald Fredriksen, Arm
|
|
|
|
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 <<appendix-compressedtex-astc, ASTC Compressed Image
|
|
Formats>>.
|
|
|
|
=== New Object Types
|
|
|
|
None.
|
|
|
|
=== New Enum Constants
|
|
|
|
* Extending elink:VkStructureType:
|
|
** ename:VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TEXTURE_COMPRESSION_ASTC_HDR_FEATURES_EXT
|
|
|
|
* Extending elink:VkFormat:
|
|
** ename:VK_FORMAT_ASTC_4x4_SFLOAT_BLOCK_EXT
|
|
** ename:VK_FORMAT_ASTC_5x4_SFLOAT_BLOCK_EXT
|
|
** ename:VK_FORMAT_ASTC_5x5_SFLOAT_BLOCK_EXT
|
|
** ename:VK_FORMAT_ASTC_6x5_SFLOAT_BLOCK_EXT
|
|
** ename:VK_FORMAT_ASTC_6x6_SFLOAT_BLOCK_EXT
|
|
** ename:VK_FORMAT_ASTC_8x5_SFLOAT_BLOCK_EXT
|
|
** ename:VK_FORMAT_ASTC_8x6_SFLOAT_BLOCK_EXT
|
|
** ename:VK_FORMAT_ASTC_8x8_SFLOAT_BLOCK_EXT
|
|
** ename:VK_FORMAT_ASTC_10x5_SFLOAT_BLOCK_EXT
|
|
** ename:VK_FORMAT_ASTC_10x6_SFLOAT_BLOCK_EXT
|
|
** ename:VK_FORMAT_ASTC_10x8_SFLOAT_BLOCK_EXT
|
|
** ename:VK_FORMAT_ASTC_10x10_SFLOAT_BLOCK_EXT
|
|
** ename:VK_FORMAT_ASTC_12x10_SFLOAT_BLOCK_EXT
|
|
** ename:VK_FORMAT_ASTC_12x12_SFLOAT_BLOCK_EXT
|
|
|
|
=== New Enums
|
|
|
|
None.
|
|
|
|
=== New Structures
|
|
|
|
* slink:VkPhysicalDeviceTextureCompressionASTCHDRFeaturesEXT
|
|
|
|
=== New Functions
|
|
|
|
None.
|
|
|
|
=== 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 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.
|
|
VK_FORMAT_ASTC_4x4_UNORM_BLOCK, so it's 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 an
|
|
ename:VK_FORMAT_ASTC_4x4_UNORM_BLOCK image format may: return HDR results.
|
|
Applications can: get predictable results by using the appropriate image
|
|
format.
|
|
|
|
|
|
=== Version History
|
|
|
|
* Revision 1, 2019-05-28 (Jan-Harald Fredriksen)
|
|
- Initial version
|
|
|