KhronosGroup / KhronosGroup/Vulkan-Docs
Unclear corner cases about newer versions
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 3.3k
- Forks
- 549
- Avg merge
- 5d 5h
- Merged PRs (30d)
- 2
Description
So, there are three sources of Vulkan version: vkEnumerateInstanceVersion::pApiVersion, VkApplicationInfo::apiVersion, and VkPhysicalDeviceProperties::apiVersion.
VkApplicationInfo::apiVersiongives bit of a weird message here:
Only the major and minor versions of the instance must match those requested in
apiVersion.
It feels bit unclear who is addressed here and what is it saying. I read it 10x and I think it is just weird wording. Probably should be:
The implementation will create an instance matching the major and minor version requested in
apiVersion, or if that is not supported then the highest version the instance does support.
- There is bit of a problem with layers:
Implicit layers must be disabled if they do not support a version at least as high as
apiVersion.
That is interesting. It feels something like that should apply to explicit layers too. Or is it like at users own risk? Then at least Note should be there.
Also it is unclear if patch version number is ignored here too, or not.
- It is ambiguous how
vkGetInstanceProcAddrworks.
Will it return NULL for 1.1 commands if VkApplicationInfo::apiVersion is 1.0?
If the instance is 1.1 but physical devices are 1.0, what will it return for 1.1 device commands?
- It is unclear how extension core version requirement works
E.g. VK_KHR_spirv_1_4 has "Requires Vulkan 1.1". It is a device extension. It is unclear which of the three Vulkan versions it references (or if all of them must be at least 1.1).
Furthemore it is not clear how it is checked. vkCreateInstance VU only covers extension-extension dependencies. Does version dependency cause VK_ERROR_EXTENSION_NOT_PRESENT or is it an undefined behavior?
- There is bit of a catch-22 with
vkGetPhysicalDeviceProperties2:
Physical-device-level functionality or behavior added by a new core version of the API must not be used unless it is supported by the physical device as determined by
VkPhysicalDeviceProperties::apiVersionand the specified version ofVkApplicationInfo::apiVersion.
It feels 1.1 instance should emulate at least this command.
vkEnumerateDeviceExtensionPropertiessays:
Implementations must not advertise any pair of extensions that cannot be enabled together due to behavioral differences, or any extension that cannot be enabled against the advertised version.
but there is VU saying:
ppEnabledExtensionNamesmust not contain bothVK_KHR_maintenance1andVK_AMD_negative_viewport_height
implying it can advertize extensions that cannot be enabled together
Also it is not clear what "advertised version" is. Can implementations filter out device extensions based on instance or application version? Can they filter out based on enabled instance extensions? That would potentially impact usefuleness of vulkaninfo and discoverability of extensions.
Implicit layers must be disabled if they do not support a version at least as high as
apiVersion.
I assume Implicit Layers add the extensions they provide into the pLayerName=NULL vkEnumerateInstanceExtensionProperties?
What should happen when they are disabled by this and an application is enabling the extension? VK_ERROR_EXTENSION_NOT_PRESENT?
Contributor 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.
Assessment
This issue has not been assessed yet.