FYI, all the tests use Nvidia GPUS.
On the topic of why people still say Wayland is slow, it probably was much much slower and only years of successive improvement in both the DE and base library got it up there in speed.
Personally I joined Linux recently and don’t understand all the beef with Wayland, but it does seem to work very well for me, so I’m happy enough with it.
Without dxvk-low-latency, XWayland adds 3.13 ms of latency to the measurement.
Can 3ms actually be noticed? Like if you randomly select one mode and did a “blind” test to see if you can tell the difference which mode is on? This honestly sounds impossible to me.
If you’re familiar with the setup and play something where latency matters (competitive FPS and rhythm games cone top mind) I guess it might be enough to their you off your game.
But on an unknown system, where you have no comparison, I’m not so sure.3ms by itself prolly not. But it adds up, if you add input lag, monitor lagetc.
I understand unplugging a second monitor to try and get the cleanest data possible, but Id be super interested in the data with the other monitor plugged in and even playing a video in the background.
It is super neat to have numbers on this.
Avoid XWayland
It added 3.13 ms of latency, more than all other effects combined. Wayland is close, but X11 still wins
Though only by 0.14 to 0.22 ms. Given there are efforts to optimize KWin, this gap will likely close sooner rather than later. And who knows, other Wayland compositors might already be better. VRR has the biggest effect
VRR was faster in every pairing (0.26 to 0.45 ms) and also flattened the latency distribution. dxvk-low-latency is a win across the board
0.10 to 0.29 ms in capped scenarios is a nice boost, but the real strength of the fork shows in the uncapped test case, where it gained 0.84 ms over default dxvk.
Additionally, in scenarios where XWayland can’t be avoided, it recovered a full 2.1 ms. Conclusion
Not factoring in XWayland, applying every optimization (X11, VRR, low-latency) compared to a default setup (which, on a modern Linux system, I assume is plain Wayland) moved the median down by 0.72 ms.
That does not sound like a lot, but the raw latency does not tell the whole story as VRR additionally reduces latency jitter, and dxvk-low-latency’s pacer is great at smoothing out real-world scenarios where frame time dips and GPU-bound situations occur.
Interesting read!
It would’ve been interesting too see how it compares to recent Windows versions as well.
Wish the VRR on my 180hz monitor wasn’t flickery :(
VRR on every monitor/TV I’ve tried is flickery, outside of games.
And even with games its best to be mindful of the VRR range.
Cool shit, thanks.
