Zink (OpenGL over Vulkan) allocator improves performance in 1000% in some games

Yes, and Mantle is a vendor-specific (AMD only) API which only supported one platform (Windows). There were plans to port it to Linux, but there were never any plans to support other GPUs.

That, and Mantle ran on desktop GPUs. Metal was initially targeted at where the gap between API and hardware was the largest, which was mobile GPUs. At least with desktop OpenGL you had the "AZDO" techniques, but on mobile, you had OpenGL ES. Mobile GPUs aren't just smaller versions of desktop GPUs, they use radically different ways of drawing on the screen (although this gap is narrowing, as desktop GPUs are becoming more like mobile GPUs... basically, expect to see tiled rendering on desktops in the future).

If you were living in 2013, would you say, "Gee, I hope someone else forms a committee to adapt Mantle into something which, in the future, maybe in 2016, I could theoretically use?" Or is it faster to make your own API? Or perhaps you like working with cross-platform steering committees that were, at the time, falling behind and failing to address problems with their APIs?

> "we already had this, so we can't join the collaborative effort" doesn't really make sense

But the argument "we already have this, so why spend money on that other thing" makes sense, especially if they profit from it and don't pay the bill for it (the companies of non MS devs which have to handle that mess do).

> For huge monsters like MS and Apple the argument of "we already had this, so we can't join the collaborative effort" doesn't really make sense.

It sounds like there’s a misunderstanding here about what Mantle was. Mantle was not a collaborative effort that different vendors could join in on. Mantle was AMD’s pet project. AMD saying “Hey, why doesn’t everyone use Mantle?” was a non-starter, because as it was, Mantle reflected the architecture of current AMD GPUs. Nvidia or other GPUs would be at a massive disadvantage trying to implement a low-level API that just didn’t fit their architecture right.

However, there was indeed a collaborative effort that Apple and Microsoft were a part of. It was the OpenGL steering committee. In 2013, the steering committee was not busy making Vulkan reality. They were instead trying to fix the problems with OpenGL. The more serious problems—the reasons why Vulkan exists—never actually got fixed.

This was not a massive surprise. The issues were complicated, and most people thought that OpenGL was falling behind DirectX further each year.

> Which indeed resulted in Vulkan eventually.

Yeah, in 2016. By that point, developers had been using Metal for almost TWO YEARS and shipping games with it. Some of those games had shipped sequels or spinoffs.

The project which eventually resulted in Vulkan, called “OpenGL Next,” hadn’t even BEGUN by the time Metal was released to developers. DirectX 12, I assume, was under heavy development at the time.

The story I’ve heard was that the release of Metal was a real kick in the pants for what became the Vulkan effort. If you were to go back in time and rewrite history, and wipe Metal off the face of the planet, who knows what would happen to Vulkan? History is messy.

They have more than enough resources to support anything. Such as lower level API (Vulkan) for those who need it and higher level one built on top of it for those who need something simpler but more limited.

Do you believe Apple are somehow resource strained in not being able to do that many times over?

OpenGL on M1 devices is just a pass through for Metal at this point - and doesn't support newer OpenGL features - so it's not really worth counting IMO. Just feels like it's there for backwards compatibility and nothing more.

Apple should ideally have supported Vulkan once it became clear that was the way the wind was blowing, and released Metal over Vulkan as a separate runtime that worked on any Vulkan card supporting their blessed feature set. It's a much nicer API, which is good for developers, and it's also in their own interests to expose a widely supported API like Vulkan if they care at all about the videogame market (which I suspect they don't): as it is, many games will just avoid Apple rather than bother to port their work to Metal, especially since Metal often has a more limited featureset than Vulkan or DX12.

This would have been a best-case scenario for everyone, basically. I'm sure many people would have been very happy to use Metal on other platforms, and in exchange Apple devices would actually have support from most modern videogames. However, that ship has probably sailed now, and WebGPU is pretty much "Metal over <X>" where X = Vulkan/Dx11/Dx12/Metal/GLES/WebGL.

I personally think it's feasible to support a Vulkan->Metal translation layer. Khronos already supports a project that does this, so Apple could take ownership of that responsibility. This would encourage developers to bring their graphics applications to Apple platforms.

The idea isn't to support multiple APIs, but to translate Vulkan into your API since it's a well-documented standard. The main issue would be API incompatibilities, which is the main place Apple could add value.