Support us on Patreon to keep GamingOnLinux alive. This ensures we have no timed articles and no paywalls. Just good, fresh content! Alternatively, you can donate through Paypal, Flattr and Liberapay!

Qt Company joins Khronos Group and promotes Vulkan

Posted by , | Views: 6,335
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.
0 Likes
We do often include affiliate links to earn us some pennies. We are currently affiliated with GOG, Humble Store and Paradox Interactive. See more information here.
About the author -
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.
See more from me
The comments on this article are closed.
11 comments
Page: 1/2»
  Go to:

mirv 16 February 2016 at 8:25 pm UTC
View PC info
  • Supporter
  • Top Supporter
With all the other news surrounding Vulkan, this one interests me as much as any others. We don't just need drivers - we need toolkit support as well. So I'm glad they're working on this.
ElectricPrism 16 February 2016 at 9:04 pm UTC
So I'm thinking Plasma 5/+ on Vulkan, my eyebrows raise.
Shmerl 16 February 2016 at 9:52 pm UTC
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 17 February 2016 at 12:09 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
Shmerl 17 February 2016 at 3:37 pm UTC
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 18 February 2016 at 12:34 am UTC
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 6 March 2016 at 8:07 pm UTC
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 6 March 2016 at 8:09 pm UTC
That's unavoidable. Compositing will be a requirement for Wayland for instance. You can do compositing all on the CPU - but it's expensive.
mirv 6 March 2016 at 8:41 pm UTC
View PC info
  • Supporter
  • Top Supporter
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.
Jazoray 6 March 2016 at 8:44 pm UTC
mirv
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.
  Go to:
While you're here, please consider supporting GamingOnLinux on Patreon, Liberapay or Paypal. We have no adverts, no paywalls, no timed exclusive articles. Just 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!
Livestreams & Videos
None currently, submit yours here!
See more!
Popular this week
View by Category
Contact
Latest Comments
Latest Forum Posts