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

[Awesomeness]

KWin on wayland is completely broken for the majority of users, as far as I can tell.

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

[tildearrow]

I agree with the comments of several others, ideally we need to get a low latency Kwin based on Wayland and Vulkan.

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.

[Awesomeness]

Too bad KWin on Xorg was declared legacy before it was neither finished nor fixed. Poor management of priorities of what's important.

Yeah, give X11 another 30 years. X11 surely gets finished and fixed by then.

[aufkrawall]

Yeah, give X11 another 30 years. X11 surely gets finished and fixed by then.

It's a common misunderstanding that X11 would be generally broken in terms of performance or vsync, but it's not true.
Without atomic modesetting kernel driver (which also affects Wayland...), performance is completely fine with Mesa/xf86-DDX. New experimental xrender backend in Compton works perfectly for me.
Gnome Shell/Mutter is btw. also very good since 3.32.

[shmerl]

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

Those aren't regressions, but missing features. I.e. it's not working properly. You can say it works partially, but it means it's not ready.

[tildearrow]

Really stop being clueless. IBM and Amazon don't work in the GUI field of KDE at all. Your nobody claim was bogus here counted straight by the next post.



The question about "Vulkan" is interesting. Vulkan in the windows manager allows better cpu and gpu usage over opengl path. So you want to reduce added latency by compositor Vulkan is a good path. That is even if the compositor is running on X11.

Lets follow this question forwards what do you really need with X11.

Yes you need X but do you in fact need GLX. That interesting point xwayland uses a EGL(OpenGL ES) and forwards GLX to that and allows applications using EGL to bypass.

1) EGL(OpenGL ES) can be used under X11 and Wayland.
2) GLX is only under X11.
3) No EGL support under X11 equals what.

The reality here is no EGL support under X11 equals a stack of not working programs.

Any sane developer looking at a X11 compositor patch that requires GLX and does not support EGL(OpenGL ES) applications would be saying that need to develop more before merging because who wants broken applications.

Really this is not example of developer stupidity rejecting a patch. This is just another example of your stupidity debianxfce not understanding the interrelationships and requirements.

Solutions under X11 for compositor need to support GLX and EGL applications running on X11. Wayland gets simpler even with xwayland your compositor only has to deal with EGL because all GLX is converted to EGL.

GLX in the X11 server is one of areas that there is an internal API cluster of disaster behind it that need to go away to fix a stack of performance problems.

https://www.phoronix.com/scan.php?pa...-Beta-3-Vulkan
I forgot to include this. Long term GLX will be redirected to EGL or Vulkan and EGL will be redirected to Vulkan.

So X11 running on top of Wayland long term everything could be just front end for Vulkan. Short term we are needing EGL support with wayland and xwayland glx is already redirected to EGL.

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

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

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

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

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