Am 14.10.2024 um 13:32 schrieb Hans Leidekker <hans@codeweavers.com>:
On Sun, 2024-10-13 at 17:16 +0200, Derek Lesho wrote:
- "Just Use Zink": this idea has been floated for a while, and would be
to use a PE build of Zink, the MESA gallium driver on top of Vulkan,
which would then automatically make use of our VK_EXT_map_memory_placed
integration in winevulkan and bypass the problem. Rémi has a branch with
a draft solution for this [1] The advantage of approach is that it
doesn't require any more extensions to any more APIs, but the
disadvantage is that Wine would have to worry about keeping a separate
version of Mesa up to date and support for building the required c++
components of mesa to its build system, as can be seen in the commits.
Do we have to include Mesa in Wine? If dropping in a PE build of Zink works then
we could also consider treating it as a Wine add-on.
I looked into Zink for Mac OS use in the past and I am not a big fan of it. It didn’t work well (even on Linux) and when it worked it was slow. We shouldn’t go down this path, comfortable as it may be. The host GL knows the hardware better, can do things like thunk out of an emulator if need be and will work on systems where Vulkan is not available.
Fwiw as far as wined3d-gl is concerned, it can play nice with slow bounce buffers too. It should do the right thing if GL_ARB_buffer_storage is not available. d3d isn't as badly affected by the performance penalty, although there are games that profit from persistent maps.
The dosemu2 dev pointed out a way to achieve something similar to macos' mach_vm_remap on Linux. I have to find my email in the archive and will forward his suggestion. It does sound somewhat hacky to me, I am not sure if we want to use it.