Qt Company joins Khronos Group and promotes Vulkan

So I'm thinking Plasma 5/+ on Vulkan, my eyebrows raise.

Quoting: ElectricPrismSo I'm thinking Plasma 5/+ on Vulkan, my eyebrows raise.

And I'm thinking highly parallel rendering in KWin and avoiding all those nasty UI lags during startup. But Martin didn't seem to be impressed or interested in moving in that direction.

https://blog.martin-graesslin.com/blog/2015/08/thoughts-on-vulkan-in-kwin/

QuoteNow let’s look at the strength of Vulkan: going closer to the hardware and doing multi-threaded rendering. KWin still performs the rendering in the main GUI thread. Qt tried to do rendering in an off-thread for QtQuick’s scene-graph, in case of KWin we also do that in the main-gui thread. Reworking our compositor to use threading is a lot of work and would also probably improve the performance with OpenGL. Anyway as long as KWin doesn’t support threaded rendering this improvement by Vulkan is rather moot.

I really hope they'll redesign KWin similarly to how Servo is designed for highly parallel rendering logic. Though they'll probably need to rewrite KWin in Rust to do that ;)


Last edited by Shmerl on 16 February 2016 at 10:00 pm UTC

It's actually a matter of time KWin guys have. There is mainly Martin working on this kind of stuff, and there currently the Wayland port is still going on.

Changing the rendering structure is one thing, that is a huge refactoring, but even more, all effects/shadows etc. would have to be reimplemented.

Wayland + Vulkan would be like... writing a complete Vulkan based threaded compositing window manager for Wayland from scratch. That alone would take Martin a few years I guess, even with his experience. My bet still goes for that he'll get interested in it and he'll dabble with it once he considers Wayland-Port "stable & done"


Last edited by STiAT on 17 February 2016 at 12:12 pm UTC

Quoting: STiATWayland + Vulkan would be like... writing a complete Vulkan based threaded compositing window manager for Wayland from scratch. That alone would take Martin a few years I guess, even with his experience. My bet still goes for that he'll get interested in it and he'll dabble with it once he considers Wayland-Port "stable & done"

I definitely hope he'll get to it at some point.

Don't get your hopes up. The first step would be refactoring for threaded rendering for KWin and implementing it, which is very likely 70% of the work.

Martin correctly says, for the number of calls, I personally think threaded rendering with OGL (ye, thats possible to a certain degree) would help almost the same performance whise as a threaded implementation with Vulkan.

Thats not dissing the amount of stuff kwin does, but it is considerably less than a game engine.

Threaded rendering would help kwin most. Faxt is, this is really complicated stuff, and a lot of work.

I personally consider kwin "good enough", or rather the best composite window manager available. It would benefit in a few cases, but I really doubt you would go "whee" with a changed implementation. Huge issue is still Xorg, not Kwin actually ....

So we get dependency on hardware accelleration right into our GUI frameworks?

It was bad when windows did this and it will be bad when linux does this.

That's unavoidable. Compositing will be a requirement for Wayland for instance. You can do compositing all on the CPU - but it's expensive.

Quoting: Guest

Quoting: JazoraySo we get dependency on hardware accelleration right into our GUI frameworks?

It was bad when windows did this and it will be bad when linux does this.

We get dependency on an API that's intended for running on graphics hardware. You could still make a software renderer for it, but that's just inefficient.
Properly done, hardware accelerated user interfaces are much smoother, allow for more capabilities, and should ultimately need less CPU power to drive. User interfaces have indirectly used hardware acceleration for a long time anyway, just at the X level rather than the framework level.
So there's really no need to worry on this - quite the opposite, we should welcome it.

Using the GPU is more expensive, power wise. and i have successfully increased my laptop battery life by using a driver that doesn't use the gpu properly. i worry that i'll no longer be able to do this.