Unclear when non-core formats are allowed to be used
@gpx1000 is already working on this.
Since Jun 29, 2026.
Assessment
This issue has not been assessed yet.
Description
VkPhysicalDeviceFeatures has the textureCompressionBC, textureCompressionETC2, and textureCompressionASTC_LDR feature flags, giving us information about the relevant formats and whether they are supported with optimal tiling. There's also many more extensions and Vulkan versions providing new formats.
Yet vkGetPhysicalDeviceImageFormatProperties is a physical device function, which means that it cannot know which extensions or which features we have enabled. And we seem to also be able to freely use any format that is reported as supported by the aforementioned function, even if the corresponding extension is not enabled. The spec also doesn't have any VUID which says anything about format extensions or format features to be enabled. The docs for vkGetPhysicalDeviceImageFormatProperties reports:
To query for additional properties, or if the feature is not enabled, vkGetPhysicalDeviceFormatProperties and vkGetPhysicalDeviceImageFormatProperties can be used to check for supported properties of individual formats as normal.
So, based on "or if the feature is not enabled", are the features just to quickly guarantee many formats to be usable in specific use-cases?
Reading through VkPhysicalDevice4444FormatsFeaturesEXT:
VkPhysicalDevice4444FormatsFeaturesEXT can also be used in the pNext chain of VkDeviceCreateInfo to selectively enable these features.
How else would they be enabled? Does this mean enabling format features is entirely optional?
Now, VkDeviceCreateInfo requires us to provide a VkPhysicalDeviceFeatures struct with all features we want to have enabled. So, what effect does enabling textureCompressionBC, textureCompressionETC2, or textureCompressionASTC_LDR have? What's the point of enabling e.g. VK_IMG_format_pvrtc if we can just query the format properties anyway to determine if we can use it? Are these just meta-extensions? Does the device even have to report VK_IMG_format_pvrtc` if the extensions are supported? Finally, why does this not follow the common extension/feature paradigm where we need to keep track of which features/extensions are available and were enabled, and determine our Vulkan usage based on that?
- Dominant language
- Makefile
- Stars
- 2.3k
- Forks
- 198
- PR merge metrics
- No merged PRs in 30d
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from KhronosGroup/Vulkan-Guide
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
KhronosGroup/Vulkan-Guide#397 · 2 comments ·
-
Difficulty 4/5 3-5 days Newbie friendliness 52/100
KhronosGroup/Vulkan-Guide#396 ·
-
Naming convention for semaphoresMay be free again @spencer-lunarg claimed this 118 days ago, and no pull request is open. Open
KhronosGroup/Vulkan-Guide#343 · 2 comments · 1 assignee ·
-
Add section with in-depth details on Vulkan Memory ModelMay be free again @sfricke-samsung claimed this 2441 days ago, and no pull request is open. Opendocumentation
KhronosGroup/Vulkan-Guide#28 · 1 assignee ·
-
documentation
Difficulty 2/5 1-3 hours Newbie friendliness 45/100
KhronosGroup/Vulkan-Guide#15 · 4 comments · 4 reactions ·