With Vulkan 1.1 It's Technically Possible To Write A Pure Wayland Compositor

[sarmad]

So, if a Wayland compositor was implemented over Vulkan, and some OpenGL-over-Vulkan was implemented, does this mean we can let the GBM vs EGLStream discussions rest in peace?

[Michael]

So, if a Wayland compositor was implemented over Vulkan, and some OpenGL-over-Vulkan was implemented, does this mean we can let the GBM vs EGLStream discussions rest in peace?

You mean Vulkan-over-OpenGL? That is the only way you could get Vulkan everywhere... But Vulkan is too low-level to effectively map properly to OpenGL.

[pal666]

forgot C# in that list, too.

i'm not sure what c# has to do with apple

[duby229]

Rust has no future. One would be better off using Swift if they really felt the need to use modern programming methods. This is due mainly to the rapid adoption of Swift and thus the large community of developers that is becoming available. It is the difference between a language that will burn out in a couple of years and one that will be here decades from now. Sort of like what happened to Perl and Python - one died and the other has become a go to language.

Well, I'll just say this for Perl, if you find yourself using sed a lot then you should probably try perl.

[shmerl]

Rust has no future. One would be better off using Swift if they really felt the need to use modern programming methods.

Swift is worse than Rust. And it's being pushed by Apple, so no, thanks.

[indepe]

So, if a Wayland compositor was implemented over Vulkan, and some OpenGL-over-Vulkan was implemented, does this mean we can let the GBM vs EGLStream discussions rest in peace?

In principle, that's how I understood it so far....except that Vulkan drivers aren't implemented for older GPUs. That discussion would become a question of the Vulkan GPU driver's internal implementation, and its communication with the kernel/OS. Buffers would still need to be allocated in a way that allows each driver to work optimally on its hardware, and it appears there innovation is still desirable.

I think Daniel Stone's remarks related to a specific transition phase that he had in mind, as otherwise I would have difficulties reconciling the two statements.

However, it doesn't look like OpenGL-over-Vulkan will be a thing in real life, even though a lot of other-things-over-Vulkan are being worked on.

You mean Vulkan-over-OpenGL? That is the only way you could get Vulkan everywhere... But Vulkan is too low-level to effectively map properly to OpenGL.

What keeps Vulkan from getting implemented on older GPUs ? Perhaps that would be worthwhile after all. Not as a general solution for OpenGL applications with their long-grown requirements on implementation details, but perhaps as a general solution for Wayland compositors and applications/games wanting to use Vulkan in the first place, including UI toolkits transitioning to Vulkan as the primary underlying API.

[pedropereira]

Unfortunately that will not put an end in the GBM vs EGLstreams debate, because the Nvidia doesn't even support Vulkan in all of their GPUs that still receives update.

[R41N3R]

In that context it is great that there is already some activity to add Vulkan support to Kwin :-)

I don't think that the older graphic cards are important at all for a compositor starting to support Vulkan. There would always be the fallback to a normal OpenGL compositor on Wayland or X11 if Vulkan is not supported by the graphic driver (if technically enough there is even the Kazan Vulkan-CPU driver). Vulkan driver support is already now quite broad.

[jacob]

And it shall be written in rust

If the current trend is anything to go by, I'm afraid it's much more likely to be written in Electron :-(

[jacob]

Rust has no future. One would be better off using Swift if they really felt the need to use modern programming methods. This is due mainly to the rapid adoption of Swift and thus the large community of developers that is becoming available. It is the difference between a language that will burn out in a couple of years and one that will be here decades from now. Sort of like what happened to Perl and Python - one died and the other has become a go to language.

Swift is the new Objective C. It has seen rapid adoption within the Apple ecosystem and essentially zero adoption anywhere else (not that Apple cult zealots usually even know that anything else exists, mind you). It baffles me a little bit, because it certainly is a good language for what it does (nicer than Go, IMHO), but in the open source community, it is as ignored as Objective C itself was.

Your point is ridiculous anyway because Swift, being a high-level, gargbage-collected language that requires a runtime environment, is not suitable for drivers or low level components of a graphics stack. Rust has been designed for that, is already used for that job and is pretty damn good at it. It also offers security guarantees that Swift can't. I would without doubt use Swift to write an iOS app, but for core OS components, Rust is the go-to language.