Jacek Caban (@jacek) commented about dlls/winex11.drv/vulkan.c:
+ LOAD_FUNCPTR( vkCreateSwapchainKHR ); + LOAD_FUNCPTR( vkCreateXlibSurfaceKHR ); + LOAD_FUNCPTR( vkDestroyInstance ); + LOAD_FUNCPTR( vkDestroySurfaceKHR ); + LOAD_FUNCPTR( vkDestroySwapchainKHR ); + LOAD_FUNCPTR( vkEnumerateInstanceExtensionProperties ); + LOAD_FUNCPTR( vkGetDeviceProcAddr ); + LOAD_FUNCPTR( vkGetInstanceProcAddr ); + LOAD_FUNCPTR( vkGetPhysicalDeviceXlibPresentationSupportKHR ); + LOAD_FUNCPTR( vkGetSwapchainImagesKHR ); + LOAD_FUNCPTR( vkQueuePresentKHR ); +#undef LOAD_FUNCPTR + + vulkan_hwnd_context = XUniqueContext(); + *driver_funcs = vulkan_funcs; + return vulkan_handle; IMO it's not great to have the library handle being part of the interface. Perhaps we could just load the vulkan loader in win32u and pass a struct containing common functions to drivers? That wouldn't work for platform-specific functions like `vkCreateXlibSurfaceKHR`. One way to solve that would be to query it using `vkGetInstanceProcAddr` inside `X11DRV_vkCreateWin32SurfaceKHR` where we have the instance handle.
(This would also bring us a step closer to supporting Vulkan in the null driver). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5365#note_65625