On Thu Jun 25 05:42:33 2026 +0000, Jacek Caban wrote:
What is the point of this? The Vulkan device must be synchronized by the caller, meaning you cannot use that device outside of opengl32 anyway. This splits the logic in a way that makes it both more complicated and awkward (creating and storing it in win32u, but synchronizing it in opengl32, etc.). Note that the synchronization should probably be more fine-tuned than the current global mutex (see bug 58834), and this change will not make implementing that any easier. The point was mostly to isolate the WOW64 code. Creating the device in win32u only seemed to make the code simpler to me, by removing the need for instance and physical device lookup, and allowing us to use the vulkan_driver.h interface, but the current device creation can be kept if it's considered better. Note that all the device lookup and device map isn't very useful, there's only ever going to be one device that matches the OpenGL device, which is why this was creating it on OpenGL init and kept it process-wide.
I'm then not sure what you mean by "the vulkan device must be synchronized", what needs to be synchronized? The vulkan calls? Isn't it fine to call the Vulkan functions we use concurrently? Regarding finer locking, I repurposed this MR to that end instead, as it seems more important, and I'm leaving the device changes for later. Note that however it doesn't fix #58834, because that regression doesn't originate from locking contention. The performance regression is caused by the WOW64 buffer mechanism, and should've appeared earlier. But https://gitlab.winehq.org/wine/wine/-/commit/c25a83bc67e944bdee73c0e43a22b25... fixed a missing length update, and caused an extra copy to happen when buffers are mapped, that wasn't happening before. But I think there's some possible workaround if we allow using pinned memory storage for non-persistent mapping. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11226#note_144172