Wednesday, 17 Feb 2016
Yay, it is Christmas ! Vulkan is out ! Woo hooo… better late than never
I haven’t spent too much time on it yet, only an hour or two browsing the API docs, samples, and simply getting a “feel” for what this new API looks like. Here are my initial thoughts ( which may very well be wrong, you know, those are just first impressions ).
- The concepts look pretty much identical to DX12’s. The total lack of surprise is a surprise in itself
- No, seriously. At this point I’m wondering why the trouble of coming up with a different API. They’re so similar. The only difference is that Vulkan is not MS-proprietary, but other than that, if you simply renamed a bunch of functions from DX12 you’d end up with an API that looks pretty close…
- It feels like DX12 and Vulkan are little brothers to each other… I won’t go as far as to say twins, because there are still some differences, but conceptually… yeah…
Now the positives/negatives that I could spot:
- The API seems to have been designed with future expansions in mind. Lots of parameters are currently left unused for future use. That’s both a plus and minus, a plus because it should theorically make future expansions easier; a minus because it makes it look more complex than DX12.
- The API is awfully verbose. By that I mean that they chose to pass function call arguments as structs, and sometimes structs-into-structs. This means that every VK call requires a ton of lines, a lot more than DX12. Sometimes it gets to ridiculous levels, I’ve seen an example with a single function call requiring as much as 60 lines of setup, just to pass parameters. Look at that one for instance: 2800 lines for a… cube ? Wtf ?
- At first glance, synchronization through events or fences seem easier. I’m not sure I’ve understood the difference with mutexes just yet.
- Resources creation / allocation also seems easier than in DX12 at first glance.
- Vulkan introduced the concept of a Render Pass, which I think wasn’t present in DX12 unless I missed it ? Not sure how useful it will be, but it might potentially be interesting.
- Extensions crap, please, nooooo. Release day and already a dozen extensions. You know that OGL got annoying because of its extension hell, right ? With hundreds of often vendor-specific extensions and multiple ways of doing the same thing. It was a jungle. Do not repeat the same mistake. The fact that we need an extension to create a swap chain ( one of the most basic things in creating a rendering surface ), day #1, already makes me angry. I get it, you did that because it’s OS dependent, but don’t tell me there was no way to make that part of the core, I won’t believe you.
So in the end, are we going to switch to Vulkan or DX12 ? The fact that Vulkan is cross platform is a big advantage. The fact that it will be available on Windows 7 ( whereas DX12 is Win 10 only ) is another big one. So even if the flaws mentionned above end up being very real, I think the good outweights the bad. That doesn’t mean we’re jumping in adding Vulkan support to the engine any time soon though. First of all, we currently lack the resources to do so. This will be a major technical challenge. The entire renderer will have to be remade, which is man-months of work. This might have significant implications on to the rest of the engine too, maybe the scene graph. So the first step is simply to wait for the API to become more mature, to gain more experience with it ( we’ll probably run some experiments with it first ), and once we gain confidence, assuming ressources permit, we’ll switch to Vulkan. That definitely won’t happen until at least next year, if ever.