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.
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.
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.
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.
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.
There are Xorg and XLibre for pre-2016 hardware.