X.Org vs. (X)Wayland Gaming Performance For NVIDIA GeForce & AMD Radeon On Ubuntu 22.04

[yump]

Unless I'm missing something, it doesn't seem like they were against fixing the problem. Some of the push back was because they felt the commit messaging wasn't properly explaining what the patch would do but most of it had to do with performance issues introduced with how the patch fixed the problem. Daniel even acknowledged that CPU usage would increase but felt that patch should be merged first and then CPU usage should be reduced later. Carlos Garnacho, the person who maintains Gnome's drawing tablet input support, felt that any future fixes to CPU usage from that patch would likely result in the patch being completely reverted.

I've been on the receiving end of that kind of bikeshedding before, and it's not personally upsetting for me. Email is asynchronous after all, I don't care, and if they want my contribution, it will get in when it gets in. But if you care about, "time to fixed code on end user systems", that metric suffers heavily.

The proposals for reducing CPU usage later all amounted to delaying/coalescing input events again, somehow. It's an unavoidable tradeoff between latency and CPU usage. Either plugging a 1000 Hz mouse in causes the input code path to run 8x as often, or it doesn't.

And most of the cost is often on the application side. Firefox, which is especially bad, will burn up half a CPU core on my machine if you wave a 1000 Hz mouse over it. Now, you can and should argue that Firefox is poorly programmed in that respect, but every application would have to have its input stack fixed independently, and even if you could get the overhead down to the lower bound (which I think is 6 context switches per event, maybe 4 with io_uring), CPU wakeups have an irreducible cost due to charging up capacitances with energy you can't get back.

Most good 1000 Hz mice have a programmable button that can be assigned to switch the sampling rate, or even a physical switch. I found that 500 Hz was good enough for me most of the time. 1 ms average input lag and position jitter, rather than 0.5 ms, at half the CPU cost.

[Myownfriend]

I believe I was remembering MR 168, mainly.

Unless I'm missing something, it doesn't seem like they were against fixing the problem. Some of the push back was because they felt the commit messaging wasn't properly explaining what the patch would do but most of it had to do with performance issues introduced with how the patch fixed the problem. Daniel even acknowledged that CPU usage would increase but felt that patch should be merged first and then CPU usage should be reduced later. Carlos Garnacho, the person who maintains Gnome's drawing tablet input support, felt that any future fixes to CPU usage from that patch would likely result in the patch being completely reverted.

[yump]

That MR doesn't reference any specific issues it closed and I can't find any open or closed issues that would have any discussion about it.

I believe I was remembering MR 168, mainly.

[kozman]

I know the defacto testing on here is nearly always Ubuntu and 1.20.x series xorg-server versus Wayland, but FFS can't we for once see a test against Wayland using something like Endeavor that's actually using modern xorg 21.x and not ancient 1.20.x series?

[Myownfriend]

Right, but as I recall, convincing them that was the right approach was a massive slog.

That MR doesn't reference any specific issues it closed and I can't find any open or closed issues that would have any discussion about it.

[yump]

They already merged the code to receive mouse events at the full rate. https://gitlab.gnome.org/GNOME/mutte..._requests/1915

Right, but as I recall, convincing them that was the right approach was a massive slog.

[Myownfriend]

I'm not the one that said it, but IMO a focus on gaming would mean it would be super easy to convince the Gnome project not to coalesce, delay, or otherwise interfere with mouse events by default, leave that for a special battery saver mode, and instead focus on lifting all boats by reducing the cost of processing mouse events.

They already merged the code to receive mouse events at the full rate. https://gitlab.gnome.org/GNOME/mutte..._requests/1915

[yump]

What does "focus on gaming" mean here? And again, do you have any newer, more relevant benchmarks that back up your stance or are you just working on hunches and taste?

I'm not the one that said it, but IMO a focus on gaming would mean it would be super easy to convince the Gnome project not to coalesce, delay, or otherwise interfere with mouse events by default, leave that for a special battery saver mode, and instead focus on lifting all boats by reducing the cost of processing mouse events.

[mdedetrich]

Just a small correction. I think you meant to say Wayland/Pipewire.

Yes indeed

[mdedetrich]

What a dumb troll. Gnome and KDE work out of the box. Better tell us how many hours gamer waste after broken winblows update.

I have been gaming for a decade and a half with windows on dozens of machines and never had this happen to me.

Also had plenty of broken Linux installations after doing updates so top with the FUD and exaggeration.