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

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

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

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

[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/wayland/wayland/issues/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.

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

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

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

[fuzz]

Wrong. The majority uses Mesa drivers and KWin on Wayland works just fine with them. There are a few regressions but far from "completely broken".

I suppose you could argue anything and be right, to a point. So yeah, it's not completely broken on my system. There is a regression in that the entire UI loses fonts and one monitor is blank, and sometimes I'm able to see windows if I'm lucky enough to have them displayed on the correct monitor at the appropriate DPI setting. But yeah, you're right. It works just fine.

[royce]

Wrong. The majority uses Mesa drivers and KWin on Wayland works just fine with them. There are a few regressions but far from "completely broken".

I have stability issues when plugging and unplugging monitors. Namely the shell freezes completely whenever I remove displays.

Looking forward to the issues being ironed out though. Performance is good, and the mixed dpi support is second to none (better even than mac os) even on xwayland apps. I absolutely need this having a 4k display on my laptop and 1080p externals wherever I go with it.

[shmerl]

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.

It's probably a good investment of time though to learn it for this use case. Looks like wlroots developers are working through this, but the main issue is not simply Vulkan familiarity (it's pretty new for everyone), but lot's of parts that need to be put together to make it work.

The way I see it, there are good reasons for developers to focus on Vulkan/WSI instead of legacy OpenGL/EGL. Bringing Vulkan support up on new hardware (or rather hardware yet without drivers) is a lot easier than bringing up the whole legacy OpenGL (or GLES) stack there. Imagine this happening for example for Vivante GPU (like for Librem 5). If KWin and other compositors could use Vulkan, it could take less time to develop full open solution than if GLES was required and developers had to chisel all the GL support first.

So I don't buy the argument of some KWin developers, that using Vulkan is pointless.