Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Measuring Input Latency on Linux: X11 vs. Wayland, VRR, and DXVK

marco-nett.de

Post reply on HN
Print view View original

21–30 of 297 posts

Re: Measuring Input Latency on Linux: X11 vs. Wayland, VRR, and DXVK

#21

Post by BearOso »

shmerl wrote: post #5

> A lot of people still use X11 over Wayland because Wayland is said to have much worse input lag Wayland is fine. People should use AMD and KDE Plasma. I'd avoid Nvidia to begin with.

Yeah, this particular experiment doesn't reveal much because the Nvidia driver is a black box. We know in the past it used its "composition pipeline" in Wayland situations, and that was a particularly noticeable increase in latency. Plus, for a while the Nvidia driver also was stuck on software cursors. And even on the DRM path the big two compositors only updated input once every frame, which was the reason for it "to have much worse input lag."

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.

Re: Measuring Input Latency on Linux: X11 vs. Wayland, VRR, and DXVK

#22

Post by hs86 »

It looks like consoles and PCs have settled on somewhat different gaming configurations. Consoles usually try to target a fixed output frame rate, while the resolution is often dynamic. On PCs, by contrast, the resolution stays static, while the frame rate and frame-time pacing are dynamic. How does this fit into the latency discussion?

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?

Re: Measuring Input Latency on Linux: X11 vs. Wayland, VRR, and DXVK

#23

Post by tapoxi »

datakan wrote: post #13
cgyvbunji wrote: post #3

He seems confused at the end why people think wayland is so slow, but don't you think it's because of his xwayland result? People were probably running x11 games on wayland and noticed that significant lag. Just a wild guess. Very nice article, wish people did actual measurements like this more often, of all sorts of things.

I've been using Linux since the mid 1990's. I'm no newbie to any of this. I literally can't tell the different between X11 and Wayland when using either of them and I don't care about all the arguing. This is just Vim vs Emacs and Gnome vs KDE all over again. At this point when I see people complaining about it I just click off the page. It's all stupid and pointless.

I mean normally this type of discussion is silly, but in playing competitive shooters latency does make a huge difference, and it shows that XWayland is adding ~4ms of latency.

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.

Re: Measuring Input Latency on Linux: X11 vs. Wayland, VRR, and DXVK

#24

Post by marinhero »

prhn wrote: post #11

Awesome article. 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…

I moved to OpenSuse and have the same experience/opinion. The only caveat I had in Wayland is Game Streaming. Sunshine/Moonlight work but the input lag is noticeable and there are artifacts in the game. I go back and forth between X11 and Wayland just because X11 better for game streaming but in time I'm sure I'll go full-time into Wayland.

Re: Measuring Input Latency on Linux: X11 vs. Wayland, VRR, and DXVK

#25

Post by zamalek »

superkuh wrote: post #6
cgyvbunji wrote: post #3

He seems confused at the end why people think wayland is so slow, but don't you think it's because of his xwayland result? People were probably running x11 games on wayland and noticed that significant lag. Just a wild guess. Very nice article, wish people did actual measurements like this more often, of all sorts of things.

You can't just test one wayland compositor and talk about the performance of all wayland compositors. They're vastly different, especially when it comes to the extensions to wayland needed to handle input devices (ref: https://wayland.app/protocols/ ). It's not like how xorg is the standard strong reference implementation for X11 everywhere that works the same everywhere. What's probably happening is that other wayla…

And FWIW, KDE probably make the most effort with their compositor. They have historically been well ahead of the curve for things that might affect this (e.g. VRR).

Re: Measuring Input Latency on Linux: X11 vs. Wayland, VRR, and DXVK

#26

Post by Cieric »

hs86 wrote: post #22

It looks like consoles and PCs have settled on somewhat different gaming configurations. Consoles usually try to target a fixed output frame rate, while the resolution is often dynamic. On PCs, by contrast, the resolution stays static, while the frame rate and frame-time pacing are dynamic. How does this fit into the latency discussion? Especially in competitive gaming, I often see people targeting frame rates way be…

As someone who is in the rendering space for work. Having a higher framerate does help, but in a weird way. Basically the start of the frame rendering is what mostly dictates where objects are rendered. By getting a higher framerate the position of objects that you see in game are much closer to their "real" position. So it's less about seeing more frames at that point and more about seeing the most up to date information possible. Technically it could be possible to render the frame in sync with the framerate and just offset the rendering so it finishes right before it's pushed to the screen, but if you're slightly wrong you'll get really bad stuttering and the execution time of gpus and the cpu submitting the work isn't really deterministic.

Re: Measuring Input Latency on Linux: X11 vs. Wayland, VRR, and DXVK

#27

Post by bsimpson »

The Rock Band guitars have a photoresistor for precisely this purpose: the screen flashes and the guitar responds when the light hits it. It helps make the otherwise very painful calibration process transparent.

It would be so cool to get that to work in Linux. I know the instrument code is in hid-sony. Here are some open tabs I've got in case anyone's curious:

- https://pascal.giard.info/techreports/nguyen-daniel-autocali...

- https://www.niangames.com/articles/reverse-engineering-rockb...

- https://github.com/torvalds/linux/blob/master/drivers/hid/hi...

Re: Measuring Input Latency on Linux: X11 vs. Wayland, VRR, and DXVK

#28

Post by rcxdude »

hs86 wrote: post #22

It looks like consoles and PCs have settled on somewhat different gaming configurations. Consoles usually try to target a fixed output frame rate, while the resolution is often dynamic. On PCs, by contrast, the resolution stays static, while the frame rate and frame-time pacing are dynamic. How does this fit into the latency discussion? Especially in competitive gaming, I often see people targeting frame rates way be…

Framerates beyond your display's refresh rate are not completely pointless, though a bit wasteful: they do mean that each frame as it is displayed shows a more up-to-date representation of the game state than if your framerate is matched to your refresh rate. In principle you don't need to render the excess frames: ideally your frame time is predictable enough you can kick off the render just before the display refresh, but the penalty is that if you miss the deadline you get some pretty jarring jankiness.

Re: Measuring Input Latency on Linux: X11 vs. Wayland, VRR, and DXVK

#29

Post by Telaneo »

I have a vague memory of (X?)Wayland being much worse than X11 before, and some patch or protocol making it out to all the relevant implementations, but I might have imagined that, since these result show virtually no difference, and only XWayland shows a marginal difference.

Or maybe it just came out of nowhere and was never true.

Re: Measuring Input Latency on Linux: X11 vs. Wayland, VRR, and DXVK

#30

Post by shakow »

hs86 wrote: post #22

It looks like consoles and PCs have settled on somewhat different gaming configurations. Consoles usually try to target a fixed output frame rate, while the resolution is often dynamic. On PCs, by contrast, the resolution stays static, while the frame rate and frame-time pacing are dynamic. How does this fit into the latency discussion? Especially in competitive gaming, I often see people targeting frame rates way be…

> I often see people targeting frame rates way beyond their display’s refresh rate

Could this be to reduce input lag?

Post reply on HN