Roderick Colenbrander thunderbird2k@gmail.com writes:
The role of the Vulkan loader is to manage all the different ICDs on the system and inject the layers at the correct points. My fear is that if we add our own 'winevulkan' library in between it will become another loader. For APIs such as vkEnumeratePhysicalDevices or vkEnumerateInstanceExtensionProperties we would need to aggregate the values across winex11, winewayland, etc, which is what the loader does for us. This is painful and we need to figure ways ourselves to load said driver.
On the contrary, you don't want to aggregate the values. It wouldn't make sense to load both winex11 and winewayland, you can only use the one that corresponds to what user32 is currently using for that process. So a separate winevulkan would simply query the driver corresponding to the desktop window, and rely on user32 to load it. And for the offscreen rendering case, it wouldn't even have to go through the graphics driver at all.
Your approach would require all the Wine graphics drivers to support being loaded behind user32's back, and refuse to work if they aren't the active driver for the current desktop. That's a lot of complication, for no benefit that I can see. Trying to force a 1:1 mapping between the Vulkan ICD loader and the user32 graphics drivers would be a mistake IMO.