The extensions are just that. They are essentially proposals or hardware specific items not meant for broad adoption. Those that are get drafted into the proper specs.
And variable driver support is common across all big graphics APIs. If anything, the feature per driver coverage here is better than DX12.
And hardware vendors are and will be very eager to add hardware specific quirks, tons of it.
So there is no point to "abstract graphics API for any OS/CPU instruction set" then, when most of the work - and we are talking about graphics acceleration, where performance is everything - is and increasingly will be handling all of that quirks.
That's not how it works. Most games and apps are just fine with leaving some amount of graphics performance on the table. That's why engines like Unity are so popular: sure, you could always go a bit faster writing your own engine, but in most cases it isn't worth the trouble. Likewise, with graphics APIs, you have to weigh the significant benefits of greater compatibility against the benefits of using vendor-specific extensions. For most apps, the benefits of going wild with extensions are marginal, while the obvious drawbacks are significant.
I think a lot of people have mistaken ideas about how performance sensitive games are. They care about performance, but not so much that it trumps all other considerations. Games really aren't that different from other apps.
> I think a lot of people have mistaken ideas about how performance sensitive games are. They care about performance, but not so much that it trumps all other considerations. Games really aren't that different from other apps.
Beyond that, even where performance is the priority, a generic performance win is usually more interesting unless the IHV is buying the developer time.
It is not going wild with extensions, rather having to deal with extensions for feature X, because everyone does it differently, and when X becomes part of the core, it is just another additional path, as naturally not all GPU drivers do update to the version that has X in the core.
And even then, there are the workarounds to deal with hardware or driver specific bugs.
Meanwhile, vendors work hand-in-hand with sponsored developers to patch their in-driver Direct3D implementation flaws up for specific games before release.
There's always going to be nonsense like this but —so far— there has been very little in Vulkan. Everybody is working towards a shared good, pushing the idea that a common framework that works the same is just less work for everyone.
Raytracing is going to test that because we already have fundamental differences in approach (Nv has a published extension, AMD are pushing a userspace compute library). It'll be interesting to see what emerges at the end.
And variable driver support is common across all big graphics APIs. If anything, the feature per driver coverage here is better than DX12.