,
6 tweets,
2 min read
Read on Twitter
It's easy to see @VulkanAPI as a glass half full or half empty. If you look at it from the negative side, it's a very complex API due to the very large amount of hardware supported, and many hardware "limits" can range from 4/16 to 1<<32 make it very challenging for portability.
The low level nature of it makes it difficult to deal with because it's not immediately obvious how limitations can be overcome. It appears to be an incredibly flexible API, but the more you use it the more you find there really is one "real" way to do things.
Still, so far, I think the positive aspects definitely outweigh the negative ones. Having something so low level ensures that drivers are simpler and less bug ridden (compared to how it used to be in the OpenGL era). I still found bugs, but nothing serious.
And, the fact it's designed to run on so many platforms with wildly different hardware is amazing. With OpenGL, writing high performance portable code was more or less unpredictable. With Vulkan, it's easy to know when something will be fast, so the extra complexity is worth it.
I still wish some things could be changed (updating descriptor sets as a command, even if outside the render pass, would be super useful. Having to rotate them is a crappy hack with many shortcomings IMO).
I'm confident that, eventually, there will be a 2.0 API refresh that will simplify the API and remove many of the limits and shortcomings which are considerations for older hardware.
