Hacker News

> results will get reported back

Even better, most of the tech stack is open source and contributions are welcome!

>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

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.

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

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.

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

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.

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.

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.

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.

> and noticed that significant lag

Only xwayland showed that result. The difference was only a couple milliseconds. That’s in the range where I start to doubt that people are feeling the latency difference. If it was 10-20ms I could believe it, but not when it’s a couple milliseconds.

The author of this post did a good job of getting all of the other confounding settings out of the way. It’s possible that the people complaining that Wayland was slow were starting from an unoptimized situation and as part of switching to some low latency variant they set all the correct settings.

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

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 wayland compositors are slower than KDE Plasma wayland which he tested. And people report that experience. Some other wayland compositors might even be faster than plasma. But what is for sure is that every wayland is very different from every other wayland.

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)

This is an annoying style of argument from Wayland fans.

Wayland fan: You need to switch to Wayland. X is deprecated and has been for years! Wayland is the future.

User: Okay, I tried, and it's broken/worse.

Wayland fan: No, you don't understand, Wayland is just a protocol. It's your implementation of Wayland that is at fault, not Wayland itself! Wayland is still great!

User: But X was working fine...

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.

Consoles are more and more supporting VRR, as are televisions.

But yes, given the limitations of the hardware, they often offer two modes - a high framerate but lower quality mode and a high quality but lower framerate mode.

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

Pixel refresh is only one part of latency. A higher framerate will lower several other parts of the overall latency. Monitors Unboxed has charts that visualize the amount of latency for each step.

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

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.

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.

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

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.

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

Could this be to reduce input lag?

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

Depends on the engine. Anyone remember Quake 3's multiple of 3 frame rate speed hack?

Question, does your monitor have a KVM? Cause I definitely notice this behavior, even on windows and os x with my monitor. I believe it was the same way on linux as well but it's been a minute since I used linux on my desktop

I guess you'd feel the same in i3 or Xmonad as well.

That’s interesting. Hyprland, spartan? It’s the fancy everything-and-the-kitchen-sink tiling WM, isn’t it?

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

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

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.

Clicks and mouse movement do have different latency, but it doesn't matter for this test. The click is the constant part to show relative positioning of X11/wayland/low latency/vrr/etc. The relative performance should be the same ranking for mouse movement, just with different exact values.

It's defective by design, in a DRM kind of way. It's designed to lack features and make them difficult to implement.

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.

AMD's Mesa drivers are better, but if you already have an Nvidia card then you can still use it just fine with Wayland.

The biggest hit is Vulkan performance (~20% less than Windows iirc) but for desktop and casual gaming use, Nvidia's proprietary drivers are perfectly fine.