Unclear when non-core formats are allowed to be used

[spnda]

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?

[sjfricke]

My personal opinion/inference is that when 1.0 came out, there were formats (ASTC/ETC/BC) that not everyone would support, but wanted to be part of "core Vulkan" and so the original feature bits were created. Over time, new formats (VK_KHR_sampler_ycbcr_conversion, VK_IMG_format_pvrtc, VK_EXT_4444_formats, etc) were added and there wasn't a precedent for adding new formats to the spec and each new format extension was added to solve a different issue.

Yet vkGetPhysicalDeviceImageFormatProperties is a physical device function, which means that it cannot know which extensions or which features we have enabled.

That is why there is a VK_ERROR_FORMAT_NOT_SUPPORTED return code, for the case you use a format not supported

or if the feature is not enabled

A lot of extensions, even if trivial, will (now) have a feature bit to prevent future cases if/when the extension is promoted to core (some extensions didn't have a feature and now have an alias bit which is more confusing)

what effect does enabling

For these exact features, there is a good chance most driver won't change, but some features (ex. robustBufferAccess) will make an impact on performance. Having these an enabled, opt-in features, gives drivers a choice to potentially do something different.

Finally, why does this not follow the common extension/feature paradigm

These are all added the VkFormat enum and there is no difference using VK_FORMAT_PVRTC2_4BPP_UNORM_BLOCK_IMG without VK_IMG_format_pvrtc as there would be to trying and use VK_PIPELINE_BIND_POINT_RAY_TRACING_KHR without first enabling VK_KHR_ray_tracing_pipeline

There should still be proper validation coverage such that if you don't follow the common paradigm you will get validation errors when using non-enabled formats, if not, that is a validation layer bug and should be fixed.

[r-potter]

The rules of the images formats and their related features are as follows:

• Physical-device level functionality can be used without enabling an extension
  or core version, as long as the extension/core version is supported for the
  physical device.

  For example, in order to use VK_FORMAT_PVRTC1_2BPP_SRGB_BLOCK_IMG as an
  argument to vkGetPhysicalDeviceImageFormatProperties you must have first
  verified that the device supports VK_IMG_format_pvrtc.

• Device-level functionality requires enabling the relevant extension

  For example, you cannot create an image with format VK_FORMAT_PVRTC1_2BPP_SRGB_BLOCK_IMG
  without first enabling the VK_IMG_format_pvrtc extension.

  This falls out of the overarching valid usage for extensions rules:

  Device functionality or behavior added by a device extension to the API must: not be used unless that extension is supported by the device as determined by vkEnumerateDeviceExtensionProperties, and that extension is enabled in VkDeviceCreateInfo.

• The various image format features (textureCompressionBC,
  textureCompressionETC2, textureCompressionASTC_LDR, formatA4R4G4B4)
  guarantee a minimum level of functionality, often for an entire family of
  formats. The definition of textureCompressionBC illustrates this idea.

* [[features-textureCompressionBC]] pname:textureCompressionBC specifies
  whether all of the BC compressed texture formats are supported.
  If this feature is enabled, then the
  ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT,
  ename:VK_FORMAT_FEATURE_BLIT_SRC_BIT and
  ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT features must:
  be supported in pname:optimalTilingFeatures for the following formats:

  ** ename:VK_FORMAT_BC1_RGB_UNORM_BLOCK
  ** ename:VK_FORMAT_BC1_RGB_SRGB_BLOCK
  ** ename:VK_FORMAT_BC1_RGBA_UNORM_BLOCK
  ** ename:VK_FORMAT_BC1_RGBA_SRGB_BLOCK
  ** ename:VK_FORMAT_BC2_UNORM_BLOCK
  ** ename:VK_FORMAT_BC2_SRGB_BLOCK
  ** ename:VK_FORMAT_BC3_UNORM_BLOCK
  ** ename:VK_FORMAT_BC3_SRGB_BLOCK
  ** ename:VK_FORMAT_BC4_UNORM_BLOCK
  ** ename:VK_FORMAT_BC4_SNORM_BLOCK
  ** ename:VK_FORMAT_BC5_UNORM_BLOCK
  ** ename:VK_FORMAT_BC5_SNORM_BLOCK
  ** ename:VK_FORMAT_BC6H_UFLOAT_BLOCK
  ** ename:VK_FORMAT_BC6H_SFLOAT_BLOCK
  ** ename:VK_FORMAT_BC7_UNORM_BLOCK
  ** ename:VK_FORMAT_BC7_SRGB_BLOCK

To query for additional properties, or if the feature is not enabled,
flink:vkGetPhysicalDeviceFormatProperties and
flink:vkGetPhysicalDeviceImageFormatProperties can: be used to check for
supported properties of individual formats as normal.

• If an image format feature is enabled, then the described functionality is
  guaranteed to be supported, and applications can operate on that assumption
  without making more fine grained queries on the individual formats described (i.e. per-format vkGetPhysicalDeviceFormatProperties/vkGetPhysicalDeviceImageFormatProperties calls can be omitted).

  Similarly, if the feature is requested at device creation, and the full set of
  guarantees cannot be satisfied, then device creation will fail.

• As illustrated in the text for textureCompressionBC, it is valid to query
  for, and make use of, individual texture formats without enabling the feature.
  The features are largely a convenient route to testing for, and requiring, a
  fairly coarse level of functionality. They are not required in order to use individual formats.

As far as I can tell, this usage pattern is consistent across all of the
extensions/core versions where we added image formats. However, we could be
clearer about the overarching behaviour, and we will look at where we can better
document that.

Hopefully that addresses most of the questions, but please feel free to ask for further clarification if I missed anything.

[krOoze]

The spec also doesn't have any VUID which says anything about format extensions or format features to be enabled.

https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#fundamentals-validusage-extensions

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?

"or if the feature is not enabled" means that you can query the implementation whether a specific Format is supported despite its Feature being unsupported\disabled.

So, what effect does enabling textureCompressionBC, textureCompressionETC2, or textureCompressionASTC_LDR have?

Gives a guarantee a specific set of format usages for specific set of formats will be supported for optimal tiling Images.

[oddhack]

@r-potter suggested we take this up as an addition to the Vulkan Guide, so reassigning this issue over there.