What's probably happening is that other wayland compositors are slower than KDE Plasma wayland which he tested. And people report that experience. Some other wayland compositors might even be faster than plasma. But what is for sure is that every wayland is very different from every other wayland.
In any case the methodology in the post is sound and should be used for benchmarking in the future.
There is a native Wayland driver for Wine/Proton but it's enabled through an environment variable, not by default. This will probably be default in Wine 12/Proton 12 because Valve wants to squeeze as much performance out of SteamOS as possible. The gaming mode UI runs under Valve's own Wayland compositor (gamescope) already, but games are currently in nested XWayland windows.
Compositing requires the GPU to do some extra work to draw the frame to be presented. This typically takes very little time (much less than a full frame period). Additionally, most wayland compositors will bypass that extra step if an application is full screen (wlroots calls it "direct scanout").
Also some wayland compositors keep track of timing and delay the final composition until right before it is time to present the frame in order to reduce latency.
Only xwayland showed that result. The difference was only a couple milliseconds. That’s in the range where I start to doubt that people are feeling the latency difference. If it was 10-20ms I could believe it, but not when it’s a couple milliseconds.
The author of this post did a good job of getting all of the other confounding settings out of the way. It’s possible that the people complaining that Wayland was slow were starting from an unoptimized situation and as part of switching to some low latency variant they set all the correct settings.
Wayland is fine. People should use AMD and KDE Plasma.
I'd avoid Nvidia to begin with.
The biggest hit is Vulkan performance (~20% less than Windows iirc) but for desktop and casual gaming use, Nvidia's proprietary drivers are perfectly fine.
I have friends who are stuck on Windows not because they play games with Windows-only anticheat, but because theyve been told by GNU heads that NVIDIA drivers simply don't perform acceptably on Linux.
edit: I should also point out the mouse acceleration curve, which if you don't fix it is different between X11 and Wayland compositors. That really messes up the "feel" of things.
edit: no, this is the one I was remembering: https://farnoy.dev/posts/linux-latency
---
David Ramiro built his m2p-latency and compared X11 vs Wayland in his article Building an Input Latency Meter (Because ‘Wayland Feels Off’ Isn’t a Metric) as well, coming to similar conclusions:
Native Wayland is on par with native X11 (all tied at ~7 ms), while XWayland roughly doubled the latency in his tests.
farnoy did extensive testing with the Open-Source-LDAT in his post Linux latency measurements and compositor tuning, also concluding that XWayland should be avoided.
I switched my daily driver / gaming rig to Fedora a few months back.
Everything seems snappier compared to Windows, but not sure if it’s in my head, and I’ve been very curious about gaming input latency. This helps answer some questions.
I recently switched to hyprland and I’m very interested how that fits in these results. hyprland uses Wayland so I hope the author might revisit now that hyprland is gaining in popularity.
I’ve considered using gamescope to hopefully get in front of some of these concerns, but I’m on nvidia and there is some discussion about it not working well there.
Now the author's got me thinking about gaming-optimized kernels, which I did not realize was a thing.
I play competitive fighting games so input latency is a huge concern. Would love to hear from anyone else who’s been down this path.
I've been a fan of Hyprland for gaming so far. Much more configurable for things like VRR/tearing and other precise tweaks via Gamescope than when I was on AwesomeWM with X11. Been especially nice having Lua for configuration, which finally feels very familiar with my AwesomeWM roots.
I wonder where the XWayland's added latency comes from though, it seems suspiciously high to just be easily hand-waved as overhead.
I recently switched to Linux after years on Windows desktop, mostly because the KDE Plasma desktop feels snappier than Windows 11. Also the feeling that if something isn't working right I can probably tinker and improve it. It's been really nice. If you haven't tried Linux desktops in awhile give Bazzite a whirl: it's a Fedora customized for gaming. Even if you don't game it's an easy way to get a very functional Linux desktop in no time at all.
I bet if someone like him made enough noise, people at MS would pay attention.
It's really scary what you can do, to the point that I often asked myself 'why allow this?' - seeing as hits on certain APIs took me to blackhat forums and articles about writing exploits.
More power to Bazzite and Valve, the sooner games app run in other OS the better.
Xlibre is an actively developed and maintained X11 protocol display server.
Xfree86 is dead, long live Xorg. Xorg is dead, long live Xlibre!
Especially in competitive gaming, I often see people targeting frame rates way beyond their display’s refresh rate. I’m not sure whether this actually provides a real benefit or whether they’re chasing a placebo effect.
Am I out of touch, or is it the children with colored LEDs on their DRAM sticks who are wrong?
It would be so cool to get that to work in Linux. I know the instrument code is in hid-sony. I think I've got some tabs open somewhere with some leads from the last time I was curious about this.
Or maybe it just came out of nowhere and was never true.
>Avoid XWayland. It added 3.13 ms of latency, more than all other effects combined.
What you are reading from the readme notes that it calls into xwayland only when gamescope (wayland compositor) is nested within another compositor (say kwin or mutter).
gamescope itself is wayland only, and when run on SteamOS is has no xwayland latency...
The XWayland result is 3ms slower, which at refresh rates this high makes me wonder if it was one frame behind.
Running the tests at 120Hz or even 60Hz might be more interesting because we could start to separate out very small differences in timing from the much larger effects of being a full frame behind.
Wayland has been great for me for a few years now. I don't use Gnome or nvidia though.
You don't run GNOME on Wayland. You run GNOME's Wayland compositor, which is an entirely different implementation than Plasma's Wayland compositor.
This is pretty much optimal, and you can't really do much better than this.
Once a stray window appears on top, or something makes the compositor think it can't do this, it'll do the intermediate step of compositing your app window with others into a temp buffer, and render that.
Sometimes the unredirect breaks for some reason (I remember a case where for some inexplicable reason my app kept creating a window 1px smaller than the screen height), or you use XWayland, you get bad latency.
Since this is a fundamental constraint, other compositors on different OSes must work like this, and you can run into issues like this as well.
Another thing - Wayland afaik started exporing 'display planes' - which are a HW feature of GPUs, that allow it to composite multiple layers together - which means the game can render at full FPS and all the windows on top will be drawn into a different plane and get composited with no ill effects - not sure if this is actually used in production yet.
Also, both the input latency (usb controller, and its driver), and screen latency (input latency + processing + update delay) are supposedly also affecting all measurements, but hopefully somewhat consistent or at least filtered out.
I wonder what is considered "unnecessary programs" by the author. Is "apparmor" or sandboxing considered in this? Or just user space applications (browser, discord, …).
I wonder if input latency would be improved if you ran setup as `root`. I wouldn’t do it for security sake, but just curious
We stream OC2[1] with our mod preinstalled over WebRTC. This ensures that kids/schools don't have to try and install the mod. This is particularly important since we support running on school provided hardware. Installing a game without a mod would be hard enough. Added advantage though is kids play with a virtual (on screen) gamepad on iPads in Mobile Safari.
Game instances run in Docker containers in Kubernetes/k3s atop very outdated nVidia hardware. Given we're already going across the Internet into school networks, we've tried very hard to optimize latency across the board. Using NVidia NVEnc with DMABuf (zero copy) etc. We're unfortunately using XWayland at present so experience the documented input overhead. Trying to optimize this whole thing end to end has been a challenge. I would say that performance is currently "acceptable".
OC2 coding: https://www.youtube.com/watch?v=ITWSL5lTLig (not streamed in this case)
[1] We've bought a limited number of copies of OC2 and pods claim a license on startup. If we're at capacity, kids play something else.
The difference could be much larger on a slower monitor. However the differences between Wayland and X11 as protocols is negligible. XWayland as an implementation looks to have a limitation.
This is most obvious in places where a lot of coordination is required, for example in supporting proper color correction throughout all applications, or decent support for advanced printer functions.
There are many incremental changes, but we often get stuck in local minima for years.
Still, I personally like that one can (relatively) easily watch what happens under the hood. It's not entirely clear to me why Windows and MacOS must remain closed source.
I never really understood Bazzite's immutable fs thing. Can one install standard dev stuff (i.e. compilers, ides, etc) easily under bazzite?
This use case is the main reason why I lean towards maybe using cachyos
https://docs.bazzite.gg/Installing_and_Managing_Software/rpm...
So I'm using Nobara instead. It's a different Fedora-for-gaming but has most of the same improvements. It is a traditional system, not immutable. CachyOS is also very popular and that gets you an Arch-for-gaming. Just yesterday I learned of PikaOS, a Debian-for-gaming.
The main thing all these gaming-customized systems are doing is getting graphics drivers and proprietary codecs installed for you easily.
Could this be to reduce input lag?
> Especially in competitive gaming, I often see people targeting frame rates way beyond their display’s refresh rate. I’m not sure whether this actually provides a real benefit or whether they’re chasing a placebo effect.
A newly rendered frame can cut-in during scan out. This shows up as tearing artifacts where the frame is changed while being sent to the display, but it allows fresher pixels to hit the screen below that tearing line. So each frame on the monitor can be a mix of multiple rendered frames.
It’s not as good as having variable refresh rate display with high refresh rate, but it does reduce latency.
For less action based games it’s common to turn vsync on and pace the frames to the refresh rate to eliminate this tearing.
Sure "only 30 fps" is big news, but pretty sure "quality mode target 30 fps" is still norm.
In Xbox, many games launched at 30 fps only, then gained 60 fps mode.
Until I see majority target at least 60 fps as minimal mode, my point IMO stands.
In video games you essentially have one giant loop that runs every frame (today it's more than that, but at its core it's still that). Producing frames faster than the display’s refresh rate can still reduce input latency because the next display refresh is more likely to use a recently generated frame. It does not necessarily mean the game receives more input events, but it can process and reflect those inputs sooner.
Not placebo, but diminishing returns become significant, and the benefit depends on frame queues, VSync, VRR, whether the game is CPU- or GPU-bound, and how its input and simulation loops are designed.
If they are chasing a placebo effect, it's a really powerful one, since all the actual competitive people are often willing to sacrifice all detail and quite a lot of resolution to get those stupid high frame rates.
I can see the difference too, but the diminishing returns usually make it not worth it, since I prefer the eye candy better details and higher resolutions give me.
Also, some games can adjust the resolutions on the fly to keep a consistent frame rate. It's only become a feature on modern games, but I believe that's mostly a historical accident. PC games could often run on much worse hardware than they were actually designed for (with minimum requirements often being absolute minimums, and not 'this is what we developed for'), so people played them on low frame rates, so that kind of jank was often more culturally accepted on PC, and if you didn't want that experience, you could always upgrade. While on console, there was no upgrade path, and games were optimised for that one config, and thus never allowed to drop too far into the red (and dropping resolution is often a better option in those cases).
This is something that could be tested experimentally, but isn’t, because the subjects we would need to test this on are all sponsored by hardware vendors.
overtone1000•1h ago