Why doesn’t Khronos create a new standard (there are so many, what’s one more?), a new open API standard that tracks the Metal API. Can’t we all just be friends?
The nice aspects to this plan are:
The specification has already been designed.
Metal is less verbose and readable than Vulkan (SHOTS FIRED!)
Metal API costs less money to write and support than Vulkan (citation needed, but I’ll get one!)
No more cross platform fragmentation.
Actually call it “glNext”, because that’s what it really is.
No need to decide what shards of Vulkan the Portability Initiative will implement.
Metal does not have a “specification”. It has documentation. So you’d still need to write a proper spec for it.
It’s also less mappable to different classes of hardware, less capable, less extensible, and overall less useful.
Vulkan already exists, and it’s already supported. That’s money already spent; you wouldn’t magically get it back by ditching Vulkan.
How do you figure?
You’re not talking about building a time machine here; as previously stated, Vulkan already exists. So what you’re talking about is abandoning Vulkan. That creates fragmentation, since not everyone will want to do that.
A significant amount of time has been invested in Vulkan, SPIR-V, and the ecosystem around them. Time has been put into engines supporting Vulkan. Time has been put into implementations, building and testing them. Etc.
Not everyone is going to jump ship to some Apple/Metal knockoff. So this would create more fragmentation, not less.
Except that it wouldn’t be. It would be Apple’s Metal. And Apple would be fully, 100% in control of where the API goes. Apple has no external process for amending or changing Metal. They don’t have IHV conferences and talk about upcoming hardware and the like. Apple decides what hardware they want to support, and that’s what goes into Metal.
You’re basically saying that Khronos should give Apple complete authority (or at the very least, complete veto power) over how Khronos’s graphics API should evolve. I’m guessing the answer will be no.
Somehow, I rather suspect that it would be much easier to do that work than to have everyone throw away their existing Vulkan code to use this Metal imitation.
And all of that would ignore the massive loss of confidence that Khronos would incur by introducing and then abandoning their competing API just to create another one. That kind of quick shifting of technology is a sign, not just of failure, but gross mis-management. If you invested time and effort into a Vulkan port, only for the makers of the spec to turn around one day and say “sorry about that, we’re just going to do what Metal did”, would you ever trust them again? Why wouldn’t you expect them to do the same thing with their Metal-like API and say “sorry about that, we’re just going to do what D3D12 does?”
There is no upside to this suggestion; there are only downsides. This is the sort of thing that you would only do if your API was a complete and total failure in the market. And Vulkan is nowhere near that at present.
Thanks very much for the robust answer. -I can’t argue with you, I’m glad it was you in particular that responded to this topic as I particularly regard your position.
As a small business owner, I find the fragmentation of the current GPU API landscape distressing.
I’m not proposing throwing away Vulkan, not at all.
I’m looking at the job it’s positioning itself to do.
I see Vulkan as Khronos’s D3D12.
All I’m saying is that there is room for something as Khronos’s Metal (not necessarily Metal itself, for the many good reasons you covered above).
So, if we’re saying that OpenGL no longer fits the future shape of GPUs (which Vulkan offers a nudge and a wink at), then there is a serious need for a genuine successor.
-Simply, I don’t see Vulkan as a successor to OpenGL.
Finally, I’m not privy to the politics or commercial goings-on with Apple, suffice to say, the situation there is depressing too.
I guess the question is… what fragmentation are we talking about?
Before, we had OpenGL, OpenGL ES and D3D. Now, we have Vulkan, D3D12, and Metal. And technically, we solved the Metal problem (to some degree) with MoltenVK. So the amount of API fragmentation is actually less than before.
Also, how do you achieve less API fragmentation by adding more APIs?
I’d say that the problem here is that, when you make these two statements, I don’t know what you mean by them. Because to me, Metal and D3D12 are comparable APIs. Not exactly equivalent, but they’re both doing basically the same thing in broadly similar ways. They are not so obviously distinct that the term “Khronos’s Metal” has any meaning to me distinct from “Vulkan”.
Now, I don’t actually know Metal very well, because I don’t use Apple platforms. I only broadly skimmed the Metal docs at one point, but it seems to me that D3D12 and Metal are a lot more similar than they are different. The primary structural differences between these APIs seem to be:
Resource handling. Metal uses explicit binding indices (because hard-coded resource limits are a good thing?), while Vulkan and D3D12 use more flexible descriptors.
Memory handling. Vulkan and D3D12 are more explicit about memory storage and memory objects.
Framebuffer handling, with Vulkan and Metal having more direct notions of what you’re rendering to (render passes), while D3D12 is more open about rendering operations.
But other than that, the APIs all seem rather similar. They all have command buffers and places to execute them. They all require some degree of explicit synchronization. And so forth.
Now, maybe my reading of Metal is too high-level. But if that’s the case, this conversion would ultimately be more productive if you spelled out more specifically what it is you’re looking for than just “Khronos’s Metal”. Because it’s entirely possible that what you’re looking for could be adequately covered with Vulkan, simply by writing a library or two.
For example, if you are for some reason in love with the Metal resource binding model, you could easily build a wrapper around descriptors and layouts which provides an equivalent construct. If you really want less control over memory allocations and objects, you can write a library to do the management for you.
Google is working on a cross-platform graphics API called Dawn: dawn.googlesource.com/dawn
It’s a thin translation layer on top of Metal, Vulkan, and D3D12. It will be used to implement the WebGPU standard, but can just as well be used for native applications.
I just think from the point of view of the “job” the API gets done. OpenGL has a Safety Critical version, an embedded version, but no one is complaining about fragmentation there.
Simply to say Vulkan won’t run on older hardware, won’t run natively on Mac, and is considerable more expensive to implement.
Look at other jobs an API should do. Mark Kilgard did an astounding job on GLUT and a variety of other support functions (and perhaps it’s simply just early days for Vulkan in this regard), consequently OpenGL became extremely usable by experts from a huge number of backgrounds, a considerable economic contribution.
OpenGL is great for prototyping by scientists and technical staff of all stripes because the scope is tractable. Academic circles can teach OpenGL in a semester because you can get to the core 3D concepts of matrix transforms and shaders quickly.
Vulkan is so dense that it probably hinders adoption in a variety of economic areas.
That’s my two cents.
Alfonse is right though, but I’m not happy or confident about the present situation.
Can you provide evidence for these complaints about fragmentation? Of all the problem people have had with Vulkan, that it’s merely existence causes fragmentation (somehow?) is not among them.
Can you define what you mean by “fragmentation”?
When you say “expensive to implement”, are you talking about the cost of writing an implementation of the Vulkan specification? Because it is highly unlikely that Vulkan implementations are harder to write or maintain than OpenGL implementations. OpenGL requires far more work by the driver than Vulkan, since Vulkan requires you to spell everything out.
If by “implementation” you mean the difficulty of writing one, yes, it is harder to write a Vulkan application than an OpenGL one. This is just as true for Direct3D12 relative to D3D11. This is just as true for Metal relative to OpenGL ES.
Any “fragmentation” that’s happening has nothing to do with Vulkan specifically; only in the nature of APIs like Vulkan.
But it permits adoption in domains where it is intended to be used: low-level, performance-critical applications (and I daresay that this is a more “economic area” than “prototyping by scientists and technical staff”). Vulkan isn’t for everyone, and it isn’t meant to be.
For fast prototyping a graphical effect, OpenGL is probably the better tool. But if you want to write a high-performance graphical rendering system, one that can take advantage of CPU threading and the like, you need command-buffer APIs. And those will necessarily require more effort from you as a user than an immediate API like OpenGL or D3D11.
If this is the “fragmentation” you speak of, then it is a welcome fragmentation. For too long have high-performance application developers suffered under the yoke of an API that prioritizes ease-of-use rather than performance. Modern command-buffer APIs don’t do that.
One size fits all almost never actually fits everyone.