Just today I've used this in a Windows 11 QEMU VM to fix rekordbox (it failed to start about 4 out of 5 tries). rekordbox uses Unity with OpenGL for the UI and I guess the devs never tested it on a computer without GPU acceleration. Amazing stuff.
sylware · 1d ago
Yeah GL is really legacy. On elf/linux, I have it ONLY for the 32bits steam client which is still hardcoded for GL, x11 and 32bits (and probably a few small GL only games here and there, mistakes, which I would not mind _not_ buying if I had a clean drm/wayland/vulkan3D system).
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.
datenwolf · 1d ago
First things first: It's just "Vulkan".
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
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.
sylware · 1d ago
The issue is not with the level of testing of the API. The issue with the level of testing new implementations of the API will have. Since this API is grotestequely and absurdely complex, expect hell for new implementations to acheive a good level of compatibility with anything legacy (QA hellish nightmare).
robinei · 1d ago
XWayland is compartmentalized, and should not make life harder for anyone else in the Wayland world (except the ones spending time maintaining it). And Zink gives us a clean OpenGL implementation on top of Vulkan (so not contributing to complexity in the base stack). I'm fine with a long tail of software requiring XWayland+Zink, and I don't think of them as polluting my system.
ChocolateGod · 1d ago
I think Wayland compositors should start to remove built in Xwayland and rely on tools like xwayland-sattelite for their X compatibility.
Making it easy to run a truly X less compositor and moving X to an optional compatibility layer.
sylware · 1d ago
Last time I had a quick look, zink did seem far from being finished, I mean very far away.
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.
scq · 20h ago
You probably haven't looked at it for a while. It's a conformant OpenGL implementation. Zink is now the default for Nvidia GPUs in Mesa, replacing Nouveau.
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.
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.
Making it easy to run a truly X less compositor and moving X to an optional compatibility layer.
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...
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.