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

31–40 of 297 posts

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

#31

Post by seanw444 »

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…

As far as I'm aware, you get marginal FPS gains switching kernels. It helps some. It's just a matter of whether the effort is worth it to you. The main change is the scheduler: rather than trying to evenly distribute CPU time to processes, it will prioritize bursty processes.

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.

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

#32

Post by redox99 »

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…

Running above the display refresh rate is only decent when you are wayyyy above it, at least double. If you have a 120hz display and run something variable around 150fps, its much worse. But 500fps does help, you're basically seeing more recent frames as it scans the screen.

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

#33

Post by colechristensen »

Cieric wrote: post #26
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 inform…

As the frame rate goes up the lag between the game state and display state goes down. It doesn't matter that the "extra" frames aren't displayed, the frame that is being displayed needs to be as up to date as possible.

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

#34

Post by markasoftware »

seba_dos1 wrote: post #12

There's no such thing as "Wayland input latency". It's just a word salad, akin to "HTTP animation smoothness". The post is measuring Xorg vs. KWin (and also XWayland), other implementations of either X11 or Wayland will have different characteristics. I wonder where the XWayland's added latency comes from though, it seems suspiciously high to just be easily hand-waved as overhead.

Yep, OP should certainly retest under gnome. Im not in the weeds myself but I get the vibe that gnome's wayland compositor is somewhat faster and more carefully designed than kwin (at least, Emacs in pgtk mode does substantially better under gnome, whereas on Kwin it uses substantial cpu when scrolling and even lags a bit at high resolutions)

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

#35

Post by mikepurvis »

NelsonMinar wrote: post #15

One thing that's lovely about Linux is this kind of analysis is not only possible, but meaningful. These results will get reported back to the graphics software authors and the distribution packagers and the ecosystem will improve. There's no sense with Microsoft that kind of improvement is possible. I recently switched to Linux after years on Windows desktop, mostly because the KDE Plasma desktop feels snappier than…

I think it depends who it is making noise. There are some famous Oculus-era stories about John Carmack tracing display latency issues and then writing lengthy screeds to Samsung engineers to get them to give him lower level access.

I bet if someone like him made enough noise, people at MS would pay attention.

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

#36

Post by Aurornis »

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…

Many PC games have dynamic resolution, too. The reason consoles target 60fps is because that’s the frame rate you get with most TVs and everyone playing the game has the same hardware (or couple variants).

> 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.

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

#38

Post by 0x457 »

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…

> 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.

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.

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

#39

Post by Telaneo »

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. I’m not sure whether this actually provides a real benefit or whether they’re chasing a placebo effect.

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).

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

#40

Post by Aurornis »

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…

With the exception of XWayland, all of the tests had input latencies within a very small range. No human could tell them apart by those latency differences alone. I would be amazed if someone could notice the 3ms difference jump to XWayland.

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.

Post reply on HN