Vulkan-Loader
Vulkan-Loader copied to clipboard
Vulkan loader/layer interface makes it difficult to query what extensions an ICD supports
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 callingvkGetInstanceProcAddr
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