But all these things can be trivially added to Metal (and I'm sure Apple is working on that already). Yes, it supports stuff like geometry and tesselation shaders, it has batched bindings updates, sparse ressources, command buffer reuse and atomic texture operations.
In fact, I can't imagine that many people will use Vulkan directly, instead we will see a bunch of wrapper libraries that abstract the tedious tasks like manual memory management and operation synchronisation.Īt the same time - and that is the funny thing - Vulkan does not seem that much more powerful to me. On the other side, you need to make sure that the data you use for a particular pass is in the device memory, which means juggling data around, recreating resources, breaking down yoru renderign commands and doing all kinds of weird memory dances. Of course, the nice thing is that you can optimise the resource usage very precisely in regards to the specifics of your engine, and you get quite precise performance guarantees. Its actually quite ridiculous how diffficult and detailed the API is. And man they were NOT kidding when they said that the API is explicit. Metal still does a lot of hand holding and behind-the-scenes management for you, while with Vulkan you are responsible for - literally - everything. I think it should be fairly clear that Vulkan offers higher performance potential then Metal. And I am starting to believe this might be a very reasonable move by Apple.
After reading the spec, I think I understand why. Some folks (me included) were quite dissapointed to learn that Apple is jumping the Vulkan bandwagon.
I hope that some other people here who are curious about GPUs, APIs and API design could offer their thouhgts on the matter. First of all, a disclaimer: this is mostly from an academic standpoint, I am interested to comparing the APIs, the provided fetures and their relative merits. As Vulkan spec has been released few days ago, I think it might be interesting to look at how it compares to what Apple gives us with Metal.