Unclear when non-core formats are allowed to be used
@gpx1000 ci sta già lavorando.
Dal 29/6/2026.
Valutazione
Questa issue non è ancora stata valutata.
Descrizione
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?
- Lingua principale
- Makefile
- Stelle
- 2.3k
- Fork
- 198
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di KhronosGroup/Vulkan-Guide
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
KhronosGroup/Vulkan-Guide#397 · 2 commenti ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 52/100
KhronosGroup/Vulkan-Guide#396 ·
-
Naming convention for semaphoresForse di nuovo libera @spencer-lunarg l’ha presa 118 giorni fa e non c’è nessuna pull request aperta. Aperta
KhronosGroup/Vulkan-Guide#343 · 2 commenti · 1 assegnatario ·
-
Add section with in-depth details on Vulkan Memory ModelForse di nuovo libera @sfricke-samsung l’ha presa 2442 giorni fa e non c’è nessuna pull request aperta. Apertadocumentation
KhronosGroup/Vulkan-Guide#28 · 1 assegnatario ·
-
documentation
Difficoltà 2/5 1-3 ore Idoneità per principianti 45/100
KhronosGroup/Vulkan-Guide#15 · 4 commenti · 4 reazioni ·