KWin-LowLatency: An Effort To Yield Less Stutter & Lower Latency With The KDE Desktop

[oiaohm]

Let me clarify. When I said "EGL isn't supported" I did not mean "EGL applications aren't supported". What I meant is that KWin-lowlatency will only work using the GLX backend (which is what almost everyone uses when using KWin on X11 since the EGL on X backend is deprecated even by KDE developers themselves).
The reason why I have not supported EGL yet (especially for Wayland) is because I haven't found any EGL extension that would allow me to explicitly wait until next VBlank (to be able to later sleep and thus reduce latency). Yes, I do need such extension, as Mesa's bugged VSync behavior requires me to. The closest I've found was the vendor-specific extension EGL_CHROMIUM_sync_control, but unless you're OK with the compositor busy-waiting (nobody is), then it is pretty much useless.
The other method is to bring the old DRM VBlank waiting code to Wayland, but then it won't work on NVIDIA......

EGL_CHROMIUM_sync_control is not required. EGL_KHR_sync + egl_swapinterval settings should do the job. Basically standard EGL. There is EGL_NV_SYNC and a few other vendor particular.

[RomuloP]

I've tested it and it is pretty big difference, the biggest show is the reduced input lag as we do not feel more like things are trying to catch the mouse, but there is still stutters in some places.

I remember there was a plan of running Kwin in real-time when it comes do Wayland, not sure how it is going as I have an NVIDIA GPU. Anyway lets see, if NVIDIA does nothing to get its GPU going well apart from games in Linux, I will move to AMD next time... Game is less than 10% of my computer time.

[skeevy420]

I've tested it and it is pretty big difference, the biggest show is the reduced input lag as we do not feel more like things are trying to catch the mouse, but there is still stutters in some places.

I remember there was a plan of running Kwin in real-time when it comes do Wayland, not sure how it is going as I have an NVIDIA GPU. Anyway lets see, if NVIDIA does nothing to get its GPU going well apart from games in Linux, I will move to AMD next time... Game is less than 10% of my computer time.

I've been running it for the past day and those are my experiences as well. ~--> suggested it to me a few weeks ago but I was just busy with other things at the time. Wish I had tried it sooner. Got the same benchmark results I normally get in Hitman 2 so I figure it's not effecting games negatively.

[oiaohm]

And adaptive sync situation is even worse, due to Wayland protocol itself missing features:

This is not in fact true,
https://gitlab.freedesktop.org/wayla...84#note_136147
You need to read above more carefully.

implement an API with which apps can ask for VRR
You missed this line. note also the "possibly Mesa" before this.

Wayland the protocol is designed to be client side rendering. Just like it started as client side decorations.

So the fact that in opengl and vulkan you can tag a surface as VRR the compositor can in fact query this. There is no need for the wayland protocol to transfer this information.

What you would want a wayland extention for is so application could request adaptive sync with min and max speeds off the compositor and the like. But these don't have to be done in wayland protocol these could be done in opengl/vulkan buffer metadata.

The features todo adaptive sync in Wayland is not missing. Features for friendliness could be classed as missing.

The adaptive sync issue on Wayland is simpler than X11 since the Wayland protocol made sure it did not include sync primitives and pushed sync primitives into opengl/vulkan/drivers.

[R41N3R]

Adding a Vulkan back-end to the compositor will be an extremely tough task as I have zero knowledge of Vulkan.

I will eventually have a look at Wayland, however.

Yes, it will be. I just think it would be the right way for kwin to go that route, but it would need support from the main devs. Probably the first step will be to run kwin via Zink.

[shmerl]

So the fact that in opengl and vulkan you can tag a surface as VRR the compositor can in fact query this. There is no need for the wayland protocol to transfer this information.

It better should, otherwise compositors will use a mess of different methods of detecting it. Wayland situation is already rather messy as it is, with compositors barely managing doing things in a similar fashion. No need to make it worse.

[oiaohm]

It better should, otherwise compositors will use a mess of different methods of detecting it. Wayland situation is already rather messy as it is, with compositors barely managing doing things in a similar fashion. No need to make it worse.

This is why I don't think it should be a wayland protocol problem. If it done standard opengl/vulkan the same sync stuff will be used on X11 and windows as well this makes applications code bases simpler for supporting VRR..

Lets just do the stuff in the drivers that should be done in the drivers. VRR is a driver thing/graphics library thing(mesa/vulkan/opengl). No need to mess up wayland protocol with this stuff.

Pays to remember Wayland is client side render. X11 is designed as server side render so it does have to provide sync primitives and this lead to mesa and x11 disagreeing at times.

You have to remember opengl and vulkan has sync primitives already and extras to support VRR. So adding VRR to wayland protcol is basically duplicating the wheel and having the wheel studs per wheel. Opengl/vulkan is really were VRR work needs to be. Why such a critical fail because you can bet some applications will use opengl/vulkan request methods in time and other applications will use wayland if you provide both. Sometimes you are better off not supporting stuff because it does not make sense.

Yes VRR is bad enough with Opengl and Vulkan we don't need third wheels.

[oiaohm]

No sense to run Xwayland when the X windowing system rules. Wayland and gnome3 will fade away in the future. More and more people realize how bad it is,see Linux news:
https://www.forbes.com/sites/jasonev...-surprise-you/

Really look closer at those benchmarks. Xfce is not that much faster than gnome 3 on X11. Mostly not saving you power either.

[oiaohm]

Small things do matter and can be a game changer. See the history of the universe.

Problem is the performance gain going across to wayland and getting out of the X11 fail crap improves stuff more than that small difference.

[oiaohm]

That is your personal opinion, not a technical fact. A fact is that wayland is not ready and popular and never will be. Time has passed by of wayland in 10 years, you can use the Xfce desktop with a pentium III computer.

Wayland is already used in embedded solutions with cpu and ram less than what you get in pentium III. Just because it not got to main stream desktop that much does not mean we don't have good performance figures from its embedded usage.

Sway currently is functional on weaker hardware than xfce can run on.