Confused on Steam Play and Proton? Be sure to check out our guide.
We do often include affiliate links to earn us some pennies. See more here.

Qt Company joins Khronos Group and promotes Vulkan

By - | Views: 10,355
This is a pretty nice boost for Vulkan, as the Qt Company has officially joined the ranks of high profile groups now in the Khronos Group.

QuoteToday Khronos has announced a new API called Vulkan which is a low-overhead, cross-platform 3D graphics and compute API for modern GPUs. As we expect that Vulkan will quickly gain strong foothold and driver support we are actively working on implementing the Qt support for Vulkan together with the Qt community, our partners and other members of the Khronos Group.


Really great to see them get in on it right away, hope to see more following.

See the full blog post here. Article taken from GamingOnLinux.com.
Tags: Editorial, Vulkan
0 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly. Find me on Mastodon.
See more from me
The comments on this article are closed.
8 comments

ElectricPrism Feb 16, 2016
So I'm thinking Plasma 5/+ on Vulkan, my eyebrows raise.
Shmerl Feb 16, 2016
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
STiAT Feb 17, 2016
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
Shmerl Feb 17, 2016
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.
STiAT Feb 18, 2016
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 ....
Jazoray Mar 6, 2016
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.
Shmerl Mar 6, 2016
That's unavoidable. Compositing will be a requirement for Wayland for instance. You can do compositing all on the CPU - but it's expensive.
Jazoray Mar 6, 2016
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.
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.