Vulkan-Loader icon indicating copy to clipboard operation
Vulkan-Loader copied to clipboard

Vulkan loader/layer interface makes it difficult to query what extensions an ICD supports

Open mfncharm opened this issue 2 years ago • 10 comments

The Vulkan loader architecture and implementation shield Vulkan applications as well as the Vulkan ICDs from the complexity of having multiple drivers accessible via a single Vulkan API.

Unfortunately, Vulkan layers can find themselves handling some of this complexity themselves. In particular, a Vulkan layer wanting to implement a Vulkan extension has to intercept a number of instance and device commands. In some circumstances, it is not straightforward for the layer to decide whether it should handle the call itself or it should rather hand it over to the loader and the ICDs.

For example, if the layer implements an instance extension, then it cannot easily find out whether the same instance extension is supported by the ICDs in the system. In particular,

  • Unlike Vulkan applications, Vulkan layers cannot assume that a non-NULL pointer returned by vkGetInstanceProcAddr is callable. The Vulkan loader may enable instance trampolines for extensions that the layer implements, even when there are no ICDs that implement that extension. In that case, by calling vkGetInstanceProcAddr the layer obtains pointers to the loader trampolines. When called, these trampolines abort as they are unable to find any ICD implementation for the corresponding Vulkan commands.
  • The loader aggregates instance extensions and it is difficult for the layer to tell which extensions each ICD supports, especially when the extensions are also being implemented by the layer itself.

Another problem encountered by layers is enabling additional extensions that they need in order to operate. See for example #51. I understand, the conclusion is that enabling device extensions may be fine, but enabling instance extensions may be problematic. The boundary of what a layer is or is not able to do is not very well defined / documented. Also - I suspect - layers enabling additional extensions behind the application's back (e.g. by intercepting vkCreateDevice and adding more extensions to ppEnabledExtensionNames) should take care to intercept vkGet*ProcAddr and return NULL for commands that the applications is not expecting to be enabled. It'd help to have some of this complexity, that all layers have to deal with, moved to the loader.

See also: https://gitlab.freedesktop.org/mesa/vulkan-wsi-layer/-/issues/18 where this discussion started

mfncharm avatar Mar 01 '22 18:03 mfncharm