Lately I have been asked a lot about using Vulkan in KWin: in fact almost every blog post in the last few months has questions about it and that seems to me there is something to write about it.
So the quick tldr: I don’t have any plans on adding support for Vulkan. Over the last years I ported to so many new technologies, including at least 3 incompatible OpenGL versions. I am not looking forward to another incompatible OpenGL version (whether it’s called Vulkan or OpenGL doesn’t matter to me on that).
Now 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.
Now let’s look on the closer to hardware: yesterday I did a blog post on how I want to use e.g. KMS Planes to get closer to hardware and bypass the OpenGL compositing. Vulkan will allow us to perform rendering closer to hardware, but if we don’t render at all, we don’t benefit from it. Vulkan is probably more power saving, but not using the rendering will save even more.
So Vulkan can only improve when the scene needs to be rendered: e.g. when you wobble a window or spin the desktop cube. I don’t think that those effects are what we should optimize for and spend our time on and even if: there are low-hanging fruits to optimize using OpenGL, we do not yet use OpenGL 3 or 4 features to improve these effects.
Overall Vulkan looks to me like a lot of work as once again we would have to add a new compositing backend, write a new low level interaction, rewrite all shaders, etc. etc. Going to Vulkan early would mean introducing more complexity to KWin, more different code paths our users might use. It sounds like a mood exercise to do so. But I also doubt that there will be useable Vulkan drivers any time soon.
Vulkan is a great technology which will make graphics much better. But I doubt that an application like KWin is the use-case it was developed for.
Now to something else!
KDE is currently running a fundraiser for the Randa Meetings with the topic “Bring Touch to KDE!”. I personally will not participate in the Randa Meetings, but many other KDE developers will go there and we need your support for it. Please help and make the Randa Meetings possible.
I agree with your final statement – Vulkan is not made for applications like KWin. OpenGL is not going anywhere (like OpenGL 1.x still lives)
That’s not correct. Vulkan is generic enough and can be used by any applications.
That’s not what Ivan was implying. It’s more like Vulkan is not designed for a usecase like KWin.
I don’t think Vulkan restricts your use cases in any way. It’s low level enough that you can probably even implement OpenGL itself as a layer on top of Vulkan without losing much performance. Actually I expect something like that to happen eventually.
I.e. there will be one portable FOSS implementation of OpenGL made on top of Vulkan which would perfectly benefit any applications which still use OpenGL (again like I said – uniformity of such implementation is a huge boon), and especially legacy ones which aren’t likely to switch to Vulkan itself.
Of course it’s not restricting use cases. What I said is: it’s not designed for KWin’s use case. If you have a Vulkan-hammer everything might look like a Vulkan-nail.
Vulkan is more like metal and wood. You need to make a hammer with it first 😉 So it’s not designed or “not designed” for applications like KWin. It’s a generic low level API using which you can implement KWin or anything else too.
To make things easier, there might come higher level frameworks on top of Vulkan which will implement a lot of common boilerplate code. But that won’t be OpenGL already, because Vulkan still will require new programming design. I.e. stateless approach vs. huge state machine which OpenGL is. And that’s a good thing which one should ponder already now.
And I red somewhere that Google plan to switch to Vulkan as their primary API, so I assume they view it as well suitable for their graphics stack in Android.
Let’s see whether they will change surfaceflinger to use Vulkan by default instead of OpenGL. I bet they won’t 😉
They might. I’m interested to see how that will develop too.
There’s a talk about Vulkan on Android here:
https://youtu.be/faYDPjI2zhU?t=2h3m13s
Hi, thanks for your informative blog posts. Teeny tiny bug report : “it sounds like a mood exercise”, feels like it should be “moot”
By the way, kwin rocks 🙂
I don’t believe any shaders have to be re-written, as there is an open-source GLSL->SPIR-V compiler, which is basically what you are intended to use with vulkan (unless you want to substitute your own solution.)
I agree on the other points though, being an early adopter for vulkan is probably not that interesting for something like kwin…
ah didn’t know about the compiler, but it wouldn’t change much. The shaders are generated at runtime, so a non-OpenGL backend would never hit the code path to generate them in first place.
In vulkan you will most likely have a bunch more options on how to configure the pipeline. I don’t know why kwin specifically generates the shaders at runtime, but with vulkan there might not really be a need for doing that anymore. I’d imagine things like ARB_separate_shader_objects and ARB_shader_subroutine might end up being a default way of doing things with vulkan.
One of the reasons are incompatible shader languages between different versions. We will need to wait and see whether this will become a problem with Vulkan.
Thanks for the answer 🙂
I never thought that KWin would fit the use case for Vulkan. It’s not as if KWin displays ten-thousands of object moving all the time. I don’t see KWin running in any kind of bottleneck any time soon, as the game engines certainly did with OpenGL (but they tend to render “more often” than KWin.
Faster is always better. Lower power consumption and so on.
KWin already seems optimized enough to not see any real extra performance from Vulkan. Plus, there are no drivers for it… Qt does not even have a backend for it, as far as I am aware.
Maybe in a few years, up to a decade, Vulkan will start to look interesting and feasible. That is the impression I got from Martin’s post.
As it is, Wayland provides enough performance for now. OpenGL is a old, strong flying eagle. Vulkan has not even left the nest… let alone fully hatched from the egg.
For now is the proper thing. If somebody steps up and feels like it – certainly I’m sure Martin wouldn’t turn him or her down. If he gets interested he may dabble with it a bit (I’ve only met him once, but I’m sure a bit of looking into it he’ll do given he finds the time to, it’s a new technology and he certainly likes new technologies).
But I’m sure there is a lot of other work to do Martin has in mind for KWin, and this may not be a top priority, considering how much time was spent for OpenGL ES porting, Wayland porting, I’m sure there are other things which went on the bench for that, besides ironing KWin with all the changes which went on (not saying it needs a lot ironing, it’s damn stable for that, so we can’t point out the great work he’s doing enough – but I’m sure the Wayland port will need some ironing for some time to go).
In the end, even Martin being paid for KDE deveopment – which is great, let’s not forget that we don’t pay him (not sure how his priorities are managed though), he might has other things on the list. We wouldn’t even remotely see KWin in this state if this wasn’t the case.
Overall, I’d trust in Martins judgement. If he says the benefit/work ratio does not work out, I’d accept it, since in KWin terms he’s probably the only one who really can judge it properly. If he ever gets bored (Ha-Ha, I know, bad joke) we may see it one day, because we saw it in the past: somebody with enough knowledge stepping up seems rather … unlikely.
Vulkan will work with Wayland just fine. Wayland itself (the protocol) doesn’t really care how you draw stuff.
I agree with your point about that switching to Vulkan will require significant reworking. However I don’t agree that it won’t get drivers soon. Drivers will actually arrive very soon.
And you didn’t mention another major benefit of Vulkan – uniform implementation. I.e. there will be one standard upstream, instead of having multiple barely compatible OpenGL implementations, which cause a lot of bugs and are hard to test. Vulkan allows creating automated testing tools, so deployment on different platforms becomes much less painful.
So yes, it requires work to switch things, but it improves the quality of the final result and instead of constant bugs which are hard to fix because of incompatible drivers, you could make fixes which benefit all installations.
And about threaded rendering. I hope combining Vulkan with languages like Rust will be a real boon for developers. Consider what Servo developers said, that using Rust allowed them reducing complexity of threaded rendering, and creating something that in C++ would have been monumentally more difficult (and thus avoided by other browser engine).
So I hope in the future there will be compositors written in Rust using Vulkan API for graphics 😉