Hi all,
On DLL_PROCESS_ATTACH, winevulkan’s DllMain() calls wine_vk_init(), which initializes the Vulkan driver and then returns whether that succeeded or failed.
Now that winevulkan implements DllRegisterServer() (to create a JSON manifest and registry key to register with the official Vulkan loader), this has led to some undesirable behavior:
- if the prefix is created in an environment where no Vulkan library is available (such as Proton’s build VM), DllMain() returns FALSE and the DLL registration fails. The manifest and registry key are not created, and if the official Vulkan loader is installed, Vulkan won't work until the prefix is updated (with Vulkan available).
- on platforms (like older macOS) where Vulkan is available for 64-bit but not 32-bit, a “Failed to load Wine graphics driver supporting Vulkan” message is logged during prefix creation, which could be confusing for users.
- prefix creation/update is unnecessarily slowed by having to load Vulkan.
The fix I’m thinking of is that DllMain() shouldn’t call wine_vk_init(), and should always return TRUE. wine_vk_init() should be called (with an InitOnce) at the top of the five global Vulkan functions (vkGetInstanceProcAddr, vkEnumerateInstanceVersion, vkEnumerateInstanceExtensionProperties, vkEnumerateInstanceLayerProperties, vkCreateInstance), and also the two ICD entry points (vk_icdGetInstanceProcAddr, vk_icdNegotiateLoaderICDInterfaceVersion). All of those functions will need to correctly handle the case where wine_vk_init() has failed and vk_funcs is NULL.
I think this behavior change will also match the official Vulkan loader better: on a Windows machine with no Vulkan hardware, vulkan-1.dll loads successfully, but vkCreateInstance() returns VK_ERROR_INITIALIZATION_FAILED.
Any feedback or thoughts are appreciated.
Thanks, Brendan