Mesa3D Drivers for Windows
github.com
github.com
I think I can run dota2 on clean wayland/vulkan3D stack (they are using libSDL3), and basically all roughly recent unity games (and probably UE5.x games which are carefull to build the wayland backend in their binaries). I am sure there is some hick-ups here and there though.
The work for "clean" legacy and dying apps is huge: Xwayland with a clean GLX/GL implementation on top of drm/wayland/vulkan3D. When you compare with the technical cost of wayland on drm/vulkan3D (well, there is a still some dependency on c++ abominations in vulkan mesa), motivation is a goner... and who is going to debug and maintain (actually make it work) that ultra-heavy and complex Xwayland/GLX/GL stack on top of drm/wayland/vulkan3D? It is hell.
I said all that but I am still running xorg... at least I am writing my own wayland compositor (something that suits me) to move away from native x11.
The main issues for xwayland+zink are the middle ground applications: those which are x11/vulkan3D without wayland support, if I am not mistaken, like shadow of the tombraider, metro exodus games, etc (even though I would not play anymore those games).
ohohoh... I am going to ask if valheim has a working/tested wayland backend while I am thinking about it.
https://www.collabora.com/news-and-blog/news-and-events/good...
Making it easy to run a truly X less compositor and moving X to an optional compatibility layer.
With respect to OpenGL with the current de-facto standard toolkits Qt and GTK you can't really get away from them for the time being, since at the moment they pull in some implementation of OpenGL as a runtime dependency; crossing fingers for that going away soon.
Also for that matter, although OpenGL is a legacy API, it's a well understood, well documented, and well tested environment. And as much as Vulkan makes certain things – well – not easier, but more straightforward, it isn't without issues. Heck, only recently Matías N. Goldberg found a long standing issue with swapchain reuse that got finally resolved with VK_EXT_swapchain_maintenance1
https://docs.vulkan.org/guide/latest/swapchain_semaphore_reu...
With respect to "technical costs" in the context of Wayland: IMHO it's mostly pushing around responsibilities and moving goalposts. Granted, setting up an on-screen frame buffer to draw on incurs a lot less moving parts in Wayland compared to X11. However, it comes at the cost of multiplying rather basic graphics machinery that's required for drawing the most simple things into each and every client. Of course shared libraries will somewhat ease the requirements on .text and .rodata segments, which can be shared; but all the dynamic state that's generated on initialization ending up in .bss and .data is redundantly kept around. And then there's the issue that Wayland also forgoes things like efficient use of screen frame buffer memory that cuts all windows from the same region of memory and managing pixel ownership. The "every window gets its own wholly sized framebuffer" only worked well for that small time window (pun intended) in which screen resolutions weren't as big as they now are becoming commonplace.
"4k", i.e. 3840×2160 @ 10R10G10B2A resolution takes up about 64MiB in a double buffered configuration (256MiB in an 8k format), if there's only a single window on screen. And every additional full screen application (even if minimized) will add another 32 MiB (128 MiB) to that. Those gigabytes of GPU VRAM don't look as plenty from that view.
The old and dusted (but not busted) way of using a single frame buffer and cutting windows from that doesn't look as outdated anymore.
Microsoft made their own Mesa builds for this once, but they don't appear to be updating them? https://apps.microsoft.com/detail/9nqpsl29bfff
Like Apple, I think Microsoft see OpenGL as a legacy compatibility thing only.