You're not wrong, but at the same time KDE has to deal with a lot of legacy code from the past. Vela breaks with the past, supporting only Vulkan 1.4
You're not wrong, but at the same time KDE has to deal with a lot of legacy code from the past. Vela breaks with the past, supporting only Vulkan 1.4
Well, first full disclosure I'm an occasional KDE developer. Most of that code is useful and there isn't much code that is widely considered to be unpleasant to work on or doing badly on performance metrics. About Vulkan - the compositor is mostly blitting textures into rectangles - you are not going to increase fill rate much by using an API that allows faster state changes. Vulkan is a good choice for an entirely new compositor, but not using Vulkan is not really a problem for a compositor on Linux, where OpenGL won't be removed or crippled willy-nilly.
Thanks for your time, talking with a KDE developer is important to me. The reason for choosing Vulkan was about explicit control over synchronization, resource management and frame scheduling, without having to maintain also OpenGL; even though I don't exclude a software rendering fallback for VMs or something. It wasn't a first-minute choice, I realised it when I wanted to improve performance compared to other DE. Currently I'm developing a benchmark suite, this is not complete yet but I've already found out Vela around 40% lower input-to-display latency in one of my tests (compared to Plasma), apparently thanks to late latching.