3 ms·
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
by viraptor 10mo ago
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 10mo agoThe 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 10mo agoYou 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 10mo agoNvidia 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 10mo agoThere are Xorg and XLibre for pre-2016 hardware.