Mesa 22.3.4 Brings Fix For RADV RT Build Performance To Match AMDVLK/AMDGPU-PRO

[phoronix]

Phoronix: Mesa 22.3.4 Brings Fix For RADV RT Build Performance To Match AMDVLK/AMDGPU-PRO

While Mesa 23.0 will hopefully be out next week, Mesa 22.3.4 was released today as the newest bi-weekly stable bug-fix release for the open-source Mesa 3D drivers...

https://www.phoronix.com/news/Mesa-22.3.4-Released

[Danny3]

Nice to see bug fixes for KDE/Wayland!
I wish they would help KDE developers fix also KDE/Wayland being generally slow on Intel GPUs.
They did a workaround for KDE Plasma by changing the compositor latency from "Balance of latency of smoothness" to "Force smoothest animations" to be used by default now in future Plasma 5.27, but that's not a proper fix.

[shmerl]

Nice to see bug fixes for KDE/Wayland!
I wish they would help KDE developers fix also KDE/Wayland being generally slow on Intel GPUs.
They did a workaround for KDE Plasma by changing the compositor latency from "Balance of latency of smoothness" to "Force smoothest animations" to be used by default now in future Plasma 5.27, but that's not a proper fix.

I think being stuck with OpenGL is part of the issue. KWin developers should look into starting to use Vulkan and rewriting compositor more with the explicit synchronization model in mind.

[schmidtbag]

I wish they would help KDE developers fix also KDE/Wayland being generally slow on Intel GPUs.
They did a workaround for KDE Plasma by changing the compositor latency from "Balance of latency of smoothness" to "Force smoothest animations" to be used by default now in future Plasma 5.27, but that's not a proper fix.

I write this on a system with KDE + Intel iGPU and have used that combo for years - it's pretty smooth for me and I've only ever had mobile i3s and i5s. I've got my compositor set to accurate and balanced. The only animation that I'd say isn't always smooth is alt+tabbing and even then, only sometimes.

I think being stuck with OpenGL is part of the issue. KWin developers should look into starting to use Vulkan and rewriting compositor more with the explicit synchronization model in mind.

I really don't think OGL is the problem. These are relatively basic functions for a GPU where I'm sure Vulkan would have a negligible improvement. However, you did mention rewriting the compositor, where perhaps the way the compositor is developed is a problem, regardless of the API. In other words, in a parallel universe where the compositor was already written for Vulkan, I don't know if it'd be that much better of an experience.
Anyway, if a rewrite were to be done, might as well do it in Vulkan.