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

61–70 of 297 posts

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

#61

Post by hackernudes »

retatop wrote: post #42
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.

Isn't Wayland always one frame delayed compared to Xorg to avoid tearing or has that been changed? If so, his very high refresh rate would minimize that effect

I don't think there was ever a design to be one frame behind.

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.

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

#62

Post by haunter »

wing-_-nuts wrote: post #57
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…

>give Bazzite a whirl 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

Yes, rpm-ostree solves that

https://docs.bazzite.gg/Installing_and_Managing_Software/rpm...

https://coreos.github.io/rpm-ostree/

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

#63

Post by gfxfan »

I wonder though, updated pixels might not have the same latency on the whole screen, and it might even be affected by some updates mechanisms, like panel replay. I.e. it would have been interesting to also measure the screen position as a dimension.

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.

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

#64

Post by xyst »

Very interesting analysis and setup.

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

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

#65

Post by 0x457 »

Narishma wrote: post #52
0x457 wrote: post #41

Earlier quoted context omitted.

Consoles target 30fps though. Very rarely they target 60fps and even less rarely they can reach that.

That's outdated information. Most PS5 and the equivalent Xbox games target 60 fps nowadays. It's usually huge news when a game is only 30 fps.

Well, new GTA is 30 fps only. Some (most?) games have performance vs quality toggle. Quality mode being 30 fps, and performance mode looks too ugly.

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.

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

#66

Post by pbhjpbhj »

torginus wrote: post #43
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…

This kind of thing is certainly possible under Windows - you can basically patch any kernel API call, replace any COM object instantiation, install filter drivers that intercept any request to and from a device, replace userland DLLs with your own. 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…

Oh sure, but if I just need to troubleshoot why Minecraft-launcher (a first party app) won't launch ... it didn't give any output; it didn't even exist apparently, but only because MS were hiding it, had to crack out Process Explorer just to get something to troubleshoot on ... then it turns out the "turnkey" app from their first-party app store, loading the first-party app, on the same company's OS just failed with no indications to the user at all, not even a "this app crashed". Solution was to cut out as much of MS as possible ... it's just infuriating when it doesn't work, which seems to be all-the-time.

More power to Bazzite and Valve, the sooner games app run in other OS the better.

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

#67

Post by abhinavk »

wing-_-nuts wrote: post #57
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…

>give Bazzite a whirl 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

You can modify the fs using rpm-ostree. It will overlay your changes on top of the immutable image. The recommended way is to create toolbox/distrobox which uses containers to isolate stuff.

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

#69

Post by Arch-TK »

torginus wrote: post #59
Hikikomori wrote: post #50

Earlier quoted context omitted.

Not Microsoft but Battlenonsense investigations on latency did get Nvidia to create reflex.

Afaik reflex is a bit different - it times the input to frame latency in your game, and tries to start the gameloop as late as possible in the frame so that your input gets sampled at the latest possible time and the frame still makes it to the vsync period, this isn't really a compositor tech.

Why would it need to measure input to frame latency? Surely it just needs to measure how long it takes the game to go from vsync period to frame ready and delay when the game thinks vsync happened to force it to poll later in the cycle?

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

#70

Post by Benjamin_Dobell »

Been dealing with this a bit at Breaka Club. We teach kids to code with a modded version of Overcooked 2!.

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. Although our inputs are virtual devices at this point, so the overhead may be a bit different. 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.

Post reply on HN