KhronosGroup / KhronosGroup/Vulkan-Docs

Unclear corner cases about newer versions

Open
#1,097 4 comments 0 reactions 2 assignees View on GitHub

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.

  1. VkApplicationInfo::apiVersion gives 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.


  1. 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.


  1. It is ambiguous how vkGetInstanceProcAddr works.

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?


  1. 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?


  1. 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::apiVersion and the specified version of VkApplicationInfo::apiVersion.

It feels 1.1 instance should emulate at least this command.


  1. vkEnumerateDeviceExtensionProperties says:

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:

ppEnabledExtensionNames must not contain both VK_KHR_maintenance1 and VK_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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.