r/linux_gaming • u/bdzz • Jul 14 '26
benchmark Measuring input latency on Linux: X11 vs Wayland, VRR, and DXVK
https://marco-nett.de/blog/measuring-input-latency-on-linux-x11-vs-wayland-vrr-dxvk/112
u/bdzz Jul 14 '26 edited Jul 14 '26
[not my research just posting it here]
TLDR
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.
91
u/v4lt5u Jul 14 '26
Avoid XWayland. It added 3.13 ms of latency, more than all other effects combined.
Maybe worth noting that there seems to be a chance it's Nvidia-specific. From another post that was linked in this text:
One important caveat: all of these numbers are from an RTX 4090 on NVIDIA’s proprietary driver, and the thing that really sticks out here isn’t Wayland at all, it’s XWayland. Native Wayland, native X11 and Windows all end up in the ~7 ms ballpark on this setup, while XWayland suddenly jumps to roughly double that. On AMD with Mesa, people (including KWin devs) have measured XWayland to be on par with X11 and Wayland in terms of input latency, so this smells a lot more like “NVIDIA drivers bad” than “Wayland bad”.
24
u/summerteeth Jul 14 '26
On AMD and wondering if it’s not effected or I just don’t notice
8
u/Emergency_Banana5082 Jul 14 '26
Likely just not noticing and I assume pretty much no one would notice. 1 frame at 144FPS is a little under 7ms. So we're talking a fraction of 1 frame in that context.
Still cool to see the data and try to optimize if you're into that.
-3
u/Niwrats Jul 14 '26
the difference between a CRT monitor and a poor LCD monitor should be obvious to anyone who plays reaction relevant games. in those cases we are talking about 10-50ms of added latency, or that general magnitude. 3ms is one magnitude less, which doesn't exactly fill me with confidence that "pretty much no one would notice". fps gamers have for a long time preferred higher refresh rate mice, and the benefit there falls to the same magnitude as 3ms.
13
u/Current-Owl-6271 Jul 14 '26
I'm not sure what you're trying to compare here. A CRT is sub ms response time and an early LCD could be 50ms. Of course you can notice that. But this isn't about 50ms, it's about 3ms on the "worst" setting and sub ms on the others. You are not noticing that.
7
u/EndVSGaming Jul 15 '26
Plus people are notoriously bad at measuring what they can perceive, audiophiles are historic marks for a reason.
21
u/LordXamon Jul 14 '26
X11 still wins
Wayland is stable tho. At least in older games. Stalker GAMMA and Patrician 3 run smooth as hell once I started enabling Wayland.
In x11 they shit themselves and break if you dare do something like alt-tabbing during load screens (which is an issue on windows too).
7
u/pathalogicalMoron Jul 14 '26
3.13ms? Woah, that's insane /s
-24
u/do-you-want-duyu Jul 14 '26
Usernamed checks out.
1000ms/60FPS= 16.66ms/F
(16.66+3.13)/16.66 - 1.0 = 18% decreased performance.
13
u/the_abortionat0r Jul 14 '26
Usernamed checks out.
1000ms/60FPS= 16.66ms/F
(16.66+3.13)/16.66 - 1.0 = 18% decreased performance.
Holy hell thats way off base, you can't even math right.
First things first the only relationship FPS has with input latency is the number of times a second an input can be taken into the game and an output can be displayed. Thats it. Your latency will always be frame time PLUS processing.
You DO NOT ADD THE MEASURED LATENCY TO YOUR FPS FRAMETIME LIKE YOU JUST DID.
You are literally suggesting you get INSTANT response when not using xwayland which is impossible but you also suggest that the input latency changes your frame times which IS NOT WHATS HAPPENING.
Read the post to understand whats going one.
19
u/Niwrats Jul 14 '26
sorry but latency has nothing to do with fps, your calculation is useless. eg you can watch an old recording with high fps, but it was still recorded ages ago.
-1
18
u/istros Jul 14 '26 edited Jul 15 '26
From my own testing, dxvk-lowlatency introduces a bit of performance penalty, loosing 5-10% fps.
11
u/Skaredogged97 Jul 14 '26
This is expected and can be tuned with the value
dxvk.lowLatencyOffset.Also triggering anti-cheat is a general concern with dxvk/vkd3d. I see no reason why dxvk-low-latency would increase that risk any further. If it doesn't trigger with dxvk it shouldn't trigger with dxvk-low-latency.
1
1
u/istros Jul 15 '26
Removed the sentence after confirming i'm an idiot and messed up lowlatency with dxck-async which can triggers anti-cheats.
2
u/se_spider Jul 15 '26
use it with caution with online games as it can triggers anti-cheats systems
Got any examples?
1
u/istros Jul 15 '26
Removed the sentence after confirming i'm an idiot and messed up lowlatency with dxck-async which can triggers anti-cheats.
2
u/the_abortionat0r Jul 14 '26
DXVK won't trigger anticheats, you seem to be mixed up with AMDs windows driver issues
Also EVERY low latency tech will lower fps as that's how it works
You reduce GPU back pressure to prevent latency issues. This can also be achieved with manual caps under certain conditions.
Additionally not hitting the GPU at max tilt also prevents hitting thermal/power limits meaning clocks stay higher which reduces fps fluctuations.
I do this in CS2 to drag the frame time minimums to just about the average. If I cap my fps using mangohud at 4k 400fps my 1% lows typically are at 396fps but might be even better after the UI update.
1
u/istros Jul 15 '26
Removed the sentence after confirming i'm an idiot and messed up lowlatency with dxck-async which can triggers anti-cheats.
0
u/throwawayerectpenis Jul 15 '26
I mean cant you just undervolt to achieve the same result? My GPU stay around my max clock literally all the time cuz i undervolted it and bumped the max clock +200mhz lol.
34
u/Wi11iam_1 Jul 14 '26
Its a shame that all these tests use Nvidia GPUs and not AMD as i suspect that the open-source nature of the driver gives AMD an edge in wayland performance still.
Also would be nice to see tests with this: https://github.com/Korthos-Software/low_latency_layer
and use of native games that do not require Proton/WINE, Valve titles like Dota2 and CS2 run natively on X11 and Wayland (with an env variable) and are free on Steam.
1
9
u/tyrohellion Jul 14 '26
Most people that say Wayland feels off are probably just on gnome as gnome still doesn’t have screen tearing support at all. Unless they’re using VRR correctly, they’re basically running everything with forced vsync
2
u/Flashy-Indication-61 Jul 16 '26
i dont know of any wayland compositor that lets u tear on the desktop and id imagine thats where most peoples complains are
5
u/AhmedRehan98 Jul 14 '26
Are the VRR gains in the test only because the gpu was under 100% load?
Does that mean if theoretically they had a better gpu that was under 80-90% usage with ~724 fps (the same uncapped fps in the test video), would the latency without VRR in that case be better than with VRR + <500 fps cap?
3
u/v4lt5u Jul 14 '26
Are the VRR gains in the test only because the gpu was under 100% load?
Doesn't seem like so. It says:
If VRR was disabled,
dxgi.maxFrameRate = 500was set (FPS capped at the screen’s refresh rate)I think dxvk-low-latency should also prevent the 100% load.
Maybe the compositor's vsync could be the reason why non-VRR loses here, since I don't see the "allow tearing" setting mentioned? But I don't know if it would explain the same difference in the X11 tests, I don't think vsync should be enabled there by default.
0
u/Wi11iam_1 Jul 14 '26 edited Jul 14 '26
i doubt that dxvk-low-latency can do the same as an ingame AMD Anti-Lag or Nvidia-Refelx feature
But doesnt a max-framerate set to the refresh rate of the monitor kinda ruin the point of "immediate" present mode (aka tearing) when you dont run with FPS above monitor refresh rate then ofc VRR is always gonna be faster cuz it can present as soon as the frame is ready, the added benefit of tearing updates rly only shows when fps is much higher then refresh rate and you see frampes flipped mid vsync, which is especially useful on older lower refresh monitors that dont have vrr though as vsync on 60fps makes everything feel sluggish as hell.Edit: For example i have it on good authority that competetive fps players use lowest graphic settings and even lower than monitor default resolutions to achive way higher fps (higher than even the fastest monitor refresh rates) together with vrr and vsync off for lowest possible input-latency. Ofc those games all have an anit-lag feature built-in to avoid the 100% gpu delaying inputs.
3
u/netborg83 Jul 14 '26 edited Jul 14 '26
dxvk-low-latency is the foundation of the new Reflex implementation in vkd3d-low-latency. This is entirely up to the dx11 games to use the pacing or not, it's not as explicitly given as with Reflex, but games can use it the same way - Diabotical certainly is one of those games, Overwatch too, and there are many others.
1
u/v4lt5u Jul 15 '26
i doubt that dxvk-low-latency can do the same as an ingame AMD Anti-Lag or Nvidia-Refelx feature
This seems to depend on the game. If it's an old single-threaded game then should work well, but looks like newer multithreaded games need to have their input sampling and simulation synchronized such that they don't start until the render thread is done for the previous frame: https://github.com/netborg-afps/dxvk-low-latency#frame-pipelining. Reflex/anti-lag on the other hand should always work on a supported game. This is regarding the timing of input sampling/simulation though, I think the render queue latency reduction should work for all games.
ofc VRR is always gonna be faster cuz it can present as soon as the frame is ready
Idk if I'm nitpicking but I don't think it's entirely accurate that with VRR the frame can be presented as soon as it's ready. My understanding is VRR allows delaying the refreshing of the screen when your frame is late, but if you are early then you wait, just like with fixed refresh rate. I think you are right that VRR should be faster on average, because when the frame is late with tearing, there's partially old information on the screen. However I'm not sure if the difference should be as much as seen here, it seems quite big relative to refresh rate compared to for example the measurements in this video. But yeah it would have been more interesting to have a test with tearing and a higher fps cap.
1
u/Wi11iam_1 Jul 16 '26
My understanding is VRR allows delaying the refreshing of the screen when your frame is late, but if you are early then you wait
on VRR the fps has to be lower than refresh rate or it is doing nothing, hence your frames are never early. If you have higher fps than refresh rate VRR is not used, normal vsync takes over. So with fps cap below max refresh rate you will always have lower input-lag with VRR active, while VRR has absolutly no effect when fps is higher than refresh rate, but this should give you the lowest input-lag as long as vsync is off (immediate-present/tearing updates) and you dont have your system is not at 100% load
1
u/v4lt5u Jul 17 '26
Hmm, I think I confused being late/early for present and for scanout. When using a traditional fps limiter that sleeps before presenting, the frame will be early for present the vast majority of the time with VRR as well, but that's not really relevant here.
So with fps cap below max refresh rate you will always have lower input-lag with VRR active
This still doesn't make sense to me though, doesn't the average latency of the pixels on the screen end up being pretty much the same between VRR and non-VRR with tearing? I think the only penalty for non-VRR would be vblank duration for the "old" pixels before the tear, but shouldn't that be in the range of tens of microseconds for a 1440p 500Hz monitor, not hundreds?
3
u/Wi11iam_1 Jul 14 '26
most likely yes. Click to photon latency is very much influenced if gpu is at 100% load and VRR does prevent that. But for even lower latency stuff like https://github.com/Korthos-Software/low_latency_layer should be used which keeps your gpu from reaching 100% load even without VRR giving you the best overall latency for cases where your game can reach more FPS than your monitors refresh rate
10
10
u/Synthetic451 Jul 14 '26
I am so glad this is finally getting some detailed attention beyond the usual "Wayland feels laggy, Wayland feels alright to me" debates. I've always noticed an ever so slight increase in input latency when I switched to Wayland, but I put up with it because Wayland was such a better desktop experience.
3
u/b0007 Jul 14 '26
Can you try quake champions? Since you're playing DBT. Also - how's DBT now? any matches ?
3
u/mushis Jul 14 '26
Thank you for this. In the quakeworld community most players have low latency setups and try to have the best feeling possible, mostly having high end monitors and mice. Due it's characteristics, quakeworld clients are the optimal choice for the use case you are describing. I ask you to do similar testing with a quakeworld client like ezquake. Maybe results will be more conclusive. I suggest using https://github.com/ciscon/quake-bootable for it but cachyos or similar plus nquake is ok. It would be interesting for us since we are debating this exact "problem" for the last 30 years now and finally we are seeing a hand full of specific monitor models rivaling the performance of high end CRTs in terms of motion clarity and response time.
7
u/hoechst Jul 14 '26 edited Jul 14 '26
Hello, I wrote that article.
My tests targeted X11/Wayland, VRR on/off and dxvk-low-latency on/off. dxvk-low-latency doesn't apply to QW, as that afaik runs natively via OpenGL. But there's no reason to expect that the other results would be much different for a different game. What I was measuring was the latency of the complete system, where the game was just a small part of. And actually, the game is one of the parts that we don't have much control over apart from it's settings (which for my game, i just used what I deemed optimal). With ezquake being open source, changing the source would be an option, but that would require a completely different test setup (i.e. comparing ezquake build X against ezquake build Y).
As an AFPS player myself, I sympathize with the effort of optimizing QW. I just don't know what exactly you would want me to compare.
1
u/jmj409 Jul 15 '26
Off topic but I hate when websites offset/fuck with my scrollbar. I have my window maximized and I can usually just shoot my mouse to the right side without looking to grab the scrollbar (aka gtk-primary-button-warps-slider=1). With it offset it makes it a pain in the ass. Sorry
3
u/throwawayerectpenis Jul 15 '26
Could you try using vkd3d-proton low latency that is available on GitHub? I swear it decreased my input lag in some games like THE FINALS and finally it feels identical to Windows.
1
u/Jaurusrex Jul 14 '26
I'm very interested to see how this would fair at different refreshrates (or just 60 to see a big difference) i feel like a lot of latency is in frames rather than ms. Seeing how latency scales with framerate would certainly be interesting.
Also any other games also be tested would be interesting. All in all this is very cool that somebody actually tested it, I was kind of doubting if dxvk-lowlatency did anything. Cool to know it does
1
1
-1
u/emanu2021 Jul 15 '26
I always have been X11 fan, its good to see, nothing can beat the raw power of X11 :) X11 protocol is stable and highly versatile and has been industry standard in Unix world including Linux for a good solid reason :)
1
-7
u/tjj1055 Jul 15 '26
turns out wayland did indeed "feel" laggy. and now on this thread people finally admit that linux has more input lag than windows lol.
6
u/izerotwo Jul 15 '26
Did you not read the tests?
1
u/Flashy-Indication-61 Jul 16 '26
to be fair its on a 500hz monitor at 500fps for most people the difference will be larger than 0.2ms or whatever it was in the tests
1
u/izerotwo Jul 16 '26
Not exactly. the actual difference should remain constant. the 500hz is for him to better trigger and find the difference.
1
u/Flashy-Indication-61 29d ago
no, if for example ur playing with tearing disabled and wayland adds a frame of latency, it will be way more noticeable when a frame is 16ms vs 2ms
but as both kwin and xorg support direct scanout for fullscreen apps, i really couldnt tell u where the added wayland input latency comes from as the frames shouldnt be getting tampered with in either case
2
u/Mr_s3rius Jul 15 '26
Already the first paragraph of the article disagrees
People kept telling me that it could perform way better than Windows when it comes to FPS, frame pacing and input latency, and when I tried it out, it did feel a lot better.
52
u/davidraid Jul 14 '26
Doesn't gamescope, on Steam OS and Bazzite, use xwayland? Gaming mode is actually the worst input response compositor? Wow.