Eh, I can't blame them terribly for introducing it. It was pre-Vulkan so they didn't have any open options when it came to a DX12/Vulkan-level graphics API.
There's a Vulkan-on-Metal implementation[1], and I'd have absolutely no complaints about the platform if there was simply an open source equivalent (well, maybe geometry shaders).
Given Vulkan is in some ways lower-level than Metal, AIUI, surely there's a significant cost that would make targetting Metal directly a better solution for things performance-critical?
Most of the critical low level of components of Vulkan are there: multiple command queues with manual synchronization, resource heaps (although they are optional for Metal), mixed compute/render support. Mostly Metal simplifies some of the distinctions Vulkan drivers may dump on the user: for example, Metal has only one command queue type while a Vulkan driver may force the user to manage several.
The biggest hurdle I can think of is geometry/tesselation shaders. Newer versions of Metal support tesselation shaders, but they work rather differently than Vulkan's (they're based on a compute shader, instead of the Hull/Domain split other APIs use). Geometry shaders aren't supported at all.
Oh, yes, lets do it!
Having worked in OpenGL-DirectX for decades we suffered immensely from "standard by committee" and lack of competition in OpenGL. When I was young I was naive and thought things would improve, but it was so painful.
Most people doing graphics have to implement an abstraction layer anyway for handling DirectX, vulkan or old OpenGL.
Once you have it, it is not so much work adding one additional back end.
I now believe competition is great and one of the things that made Europe for example to prosper while China stagnated for 5 centuries.
If you say for example: "We only support text shaders because it is simple and works well enough" and someone else uses and API or DOM and it goes 200 times faster, I want the option to let the first guys down and pick the 200X improvement version, not having to stand the original "because it is the standard and we don't care".
> Once you have it, it is not so much work adding one additional back end.
Yes, it is. I would have been able to develop Pathfinder a lot faster if I didn't have to write and debug the "compute-shader" abstraction.
> If you say for example: "We only support text shaders because it is simple and works well enough" and someone else uses and API or DOM and it goes 200 times faster, I want the option to let the first guys down and pick the 200X improvement version, not having to stand the original "because it is the standard and we don't care".
Vulkan exposes more of the hardware than Metal does. Having separate tessellation evaluation/tessellation control shaders is important to the way that Pathfinder works.
It's one thing to have a vendor-specific API that's better than the standard. It's quite another to have a vendor-specific API that's worse...
Android with Vulkan support means Android 7, currently available on 1.2% of worldwide devices, hardly a market worth spending resources on. Also it is an optional API, Android 7 compliant devices aren't required to actually provide it, apps are supposed to check it.
Windows support is done by GPU vendors, not Microsoft and is only supported on Win32, not UWP applications.
Sony doesn't plan to support Vulkan, PS* APIs are much better.
Nintendo did introduce support for the Switch, but they are so confident on it, that they also have NVN, which offers much better control over the hardware.
"NVIDIA additionally created new gaming APIs to fully harness this performance. The newest API, NVN, was built specifically to bring lightweight, fast gaming to the masses."
I couldn't tell you how much impact this actually has, but Vulkan/D3D12/Metal have to be conservative with pipeline state changes, and have to manage the layout of various hardware data structures for you.
They've gotten partway there with things like D3D12 descriptor heaps, but hardware-specific APIs just don't have those limitations.
An afterthought is pretty strong word. It has direct equivalents to most of Vulkan's concepts (resource heaps, command buffers and queues, etc.). It's definitely miles ahead of OpenGL on any platform. What Vulkan features do you think can't be added into Metal without effectively trashing the whole thing?
No, you're correct, afterthought is not the word I want to use. Apples actions certainly show forethought and planning. I meant instead that the graphics support overall has felt like an afterthought: radar bugs open without meaningful response for months, outdated graphics hardware and drivers, no option for choice between brands when that means you can't run CUDA on "pro" computers, no support for vulkan (though I think there's an official mapping Vulkan into Metal that hasn't materialized yet)... the list gets tiring to read after 15 years of waiting for apple to actively support their software/hardware combos to their equivalent capacities on windows, let alone supporting recent hardware or novel apis.
However, I can't help but seeing it modeled on the Direct X vendor lock-in model that starved Apple of games (and users because of those games). While it may not be a sign of change in Apple, it is a sign to me I shouldn't depend on them to provide products that meet my needs as a cross-platform developer. All those years I invested in a neglected OpenGL I should have devoted instead to directx; perhaps I would be less bitter now.
For what it's worth, during the development of Pathfinder, I have spent more time working around OpenGL driver bugs on Apple systems (at least 4 or 5) than any other system (zero).
I don't own a Mac, so I haven't actually tried Metal.
But from the documentation, it looks like quite a nice and simple API that also exposes the modern capabilities of shaders. It would probably make a great base for a new webgpu API.
This existence of Metal isn't really an issue. The real issue is that apple has silently shifted to a mode of only supporting Metal, not implementing vulkan and neglecting opengl.
