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

51–60 of 297 posts

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

#51

Post by smokel »

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…

Some things do indeed improve, but some other things require a massive effort that no hobbyist or small company can make happen.

This is most obvious in places where a lot of coordination is required, for example in supporting proper color correction throughout all applications, or decent support for advanced printer functions.

There are many incremental changes, but we often get stuck in local minima for years.

Still, I personally like that one can (relatively) easily watch what happens under the hood. It's not entirely clear to me why Windows and MacOS must remain closed source.

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

#52

Post by Narishma »

0x457 wrote: post #41
Aurornis wrote: post #36

Earlier quoted context omitted.

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…

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.

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

#53

Post by AlienRobot »

haunter wrote: post #37

SteamOS and Bazzite both use Xwayland through gamescope which is the worst option as it seems https://github.com/ValveSoftware/gamescope >Avoid XWayland. It added 3.13 ms of latency, more than all other effects combined.

I'm not sure I understand. If X11 software requires a X11 server and you have a Wayland compositor, how do you "avoid" XWayland?

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

#54

Post by Cieric »

colechristensen wrote: post #33
Cieric wrote: post #26

Earlier quoted context omitted.

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.

Yes, thanks for saying it more concisely/clearly than I did. Just cause I understand something doesn't mean I'm good at explaining it.

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

#55

Post by doubled112 »

boomskats wrote: post #49

A lot of people conflate Wayland being worse than X11 with Gnome on Wayland being worse than Gnome on X11. Wayland has been great for me for a few years now. I don't use Gnome or nvidia though.

If I understand the semantics of it all correctly, in that sense, there is no such thing as "Wayland". It is all a little bit confusing compared to the X11 ecosystem.

You don't run GNOME on Wayland. You run GNOME's Wayland compositor, which is an entirely different implementation than Plasma's Wayland compositor.

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

#56

Post by torginus »

I am not super familiar with Wayland, but basically how composited rendering under X11 works, is if you have a fullscreen window, you can give an 'unredirect' hint to the compositor, in which case when nothing else is drawing your screen, it will stop compositing, and pass your app's swapchain directly to the screen.

This is pretty much optimal, and you can't really do much better than this.

Once a stray window appears on top, or something makes the compositor think it can't do this, it'll do the intermediate step of compositing your app window with others into a temp buffer, and render that.

Sometimes the unredirect breaks for some reason (I remember a case where for some inexplicable reason my app kept creating a window 1px smaller than the screen height), or you use XWayland, you get bad latency.

Since this is a fundamental constraint, other compositors on different OSes must work like this, and you can run into issues like this as well.

Another thing - Wayland afaik started exporing 'display planes' - which are a HW feature of GPUs, that allow it to composite multiple layers together - which means the game can render at full FPS and all the windows on top will be drawn into a different plane and get composited with no ill effects - not sure if this is actually used in production yet.

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

#57

Post by wing-_-nuts »

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

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

#58

Post by upboundspiral »

haunter wrote: post #37

SteamOS and Bazzite both use Xwayland through gamescope which is the worst option as it seems https://github.com/ValveSoftware/gamescope >Avoid XWayland. It added 3.13 ms of latency, more than all other effects combined.

gamescope is a custom wayland compositor that Valve built for gaming... In steam big picture mode there is no xwayland or anything, just gamescope.

What you are reading from the readme notes that it calls into xwayland only when gamescope (wayland compositor) is nested within another compositor (say kwin or mutter).

gamescope itself is wayland only, and when run on SteamOS is has no xwayland latency...

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

#59

Post by torginus »

Hikikomori wrote: post #50
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…

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.
Post reply on HN