On 10/14/24 21:38, Derek Lesho wrote:
Am 14.10.24 um 12:32 schrieb Hans Leidekker:
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.
Yeah I don't see any reason this wouldn't work, and from everything I know would probably be the better solution if we go the Zink route, it just leaves open the question how we distribute it, maybe something like wine-mono? Also, maybe Rémi knows something I don't that caused him to write the integrated version.
MESA WGL implementation is far from complete, and it lacks various things like wgl*Font functions that Wine has implemented already.
Then it's not clear whether it's possible to implement the missing bits with only the public gdi32/user32 exports, and embedding it into Wine would instead give us much more control over the WSI implementation.
Some other WGL details are also simply not possible to correctly implement using the host GL implementation [1] and would require access to the GL driver internals. Embedding would also solve this, as we can then plug into or tweak its WSI code to fit our needs.
[1] ie: wglShareLists which we have various heuristics and workarounds for to handle most but not all cases, wglCopyContext which has a GLX equivalent but cannot be implemented with EGL for Wayland, probably others I'm missing.