[viraptor]

It was always an option, but "just" needed someone to dedicate all their time to it and pull in a group of long term maintainers. The real question is what will happen with the project in 2 years and will it be stable for day to day use.

[bsder]

The fact that you can "assume Vulkan exists" helps a lot (both hardware and software renderers exist). Do remember--Wayland predates Vulkan by almost a full decade.

In addition, you can offload OpenGL compatibility to Zink (again leaning into Vulkan).

> pull in a group of long term maintainers.

"Use new cool language" seems to be a prerequisite for this nowadays ...

At least Zig is very compatible with C.

[throwaway92841]

You can't "assume Vulkan exists". Any pre-2016 hardware won't have proper hardware support for Vulkan and that's a lot of hardware still in use. Software renderers are unworthy of any serious consideration due to the perfomance drawbacks.

Just use OpenGL. I don't know when this trend to overcomplicate everything using Vulkan began, but I hate it.

[MindSpunk]

Nvidia had a driver for Vulkan for Kepler which launched in 2012, AMD had support all the way back to GCN 1.0 (also 2012). Intel did have issues supporting it, I can't recall if it was for hardware reasons or just lack of desire for a driver.

Vulkan has substantial advantages for multi-threaded code, as well as exposing the underlying asynchronous nature of running code on the GPU. The kind of thing you want to be able to control with a desktop compositor where controlling vsync and present timing is very important.

[bmacho]

There are Xorg and XLibre for pre-2016 hardware.