Why Did Apple Create Their Half-baked Metal Insead Of Using Vulkan?

Brian Lovin/Hacker NewsAsk HN: Why did Apple create their half-baked Metal insead of using Vulkan?

Why did they decide to create something that only works on Apple instead of using an open standard like Vulkan?Daily Digest email

Get the top HN stories in your inbox every day.

Email addressFrom:BrianTo:[email protected]Daily DigestSaturday, March 14npm install -g @brianlovin/hn-cli

Jasper_

Metal is not half-baked, it's actually quite good! It was started as a project before Vulkan as a whole, and it released a year before Vulkan.

Strategically, why would Apple do their own thing and not pay attention to Khronoscor contribute to the standard? Quite a few reasons, most of it having to do with Khronos politics. The details are not public and might never be. I can imagine Apple was tired of Khronos after the mess that was OpenGL. And in many ways, Vulkan isn't a whole lot better...

criddell

I wish somebody would do a port of Metal to Windows.

Jasper_

There might not be a port of Metal to Windows, but there are libraries that give a Metal-like API on top of Vulkan and D3D12. One of those is wgpu, which I think is a great API. It's native to Rust, but there are ways of using it from C and C++ too. https://github.com/gfx-rs/wgpu/

bradhe

Recently ditched my shitty home-grown abstraction layer for wgpu and it’s a breath of fresh air.

criddell

Thanks for the link! I looked around last year and didn't find anything.

fathyb

It's easier for them to only have one API, they still have to write and maintain drivers, and Metal predates Vulkan. Microsoft also requires all graphics drivers to support DirectX, and it's up to the GPU maker to support OpenGL or Vulkan.

Metal is far from half-baked. After working with OpenGL for years, the stability of Metal is a breath of fresh air. No GPU-specific workarounds, great performance with unified memory, and easy interop between compute and graphics.

db48x

You mean aside from the fact that Vulkan was announced a year after Metal was first released? Probably just because Apple never cooperates with anybody.

roytries

I don't believe that Apple did not know about these initiatives before committing to building Metal. Apple was using the OpenGL graphics API (governed by the Khronos group) and AMD GPUs exclusively around this time period.

Note also that Apple is also in the highest tiers of members of the Khronos group. (see: https://www.khronos.org/members/list).

Vulkan was created from the Mantle API that AMD donated to the Khronos group. Mantle exist 2 years prior to any mentions of Metal. As a member of the Khronos group and a very important partner of AMD they would surely have information on what these groups thought the future would be of graphics-APIs.

I believe that Apple had other reasons for choosing to build Metal. But I'm afraid it will be hard to figure out what they were.

darklion

Your timeline is wrong.

Development of Mantle was announced at the end of September 2013 [1]. Metal was announced and released to developers in preview form in June 2014 [2]. Talk of integrating Mantle into OpenGL happened around August, 2014 [3].

The actual timeline is: Apple spends months-to-years developing a proprietary graphics API (Metal) for their A-series chips. About nine months prior to Metal's release to developers, AMD announces they're going to _start_ developing their own proprietary graphics API. And two months after Apple announces Metal's existence and gives developers access to the software, AMD floats the idea of donating its API to Kronos.

In other words, Metal v1 was pretty much complete by the time the AMD and Kronos even considered a partnership, and "Mantle going to Kronos" may have even been a reaction to the announcement of Apple transitioning to their own graphics API, rather than the reverse.

-- [1] https://www.forbes.com/sites/davealtavilla/2013/09/30/amd-an... [2] https://arstechnica.com/apple/2014/06/apple-gets-heavy-with-... [3] https://www.guru3d.com/news-story/amd-mantle-might-end-up-in...

roytries

I guess the debate then comes down to if Apple, as an insider, had already committed to development of Metal before they knew AMD was up to something.

With the public announcement of Mantle in Q3 2013, and the first release of Metal in Q2 2014. (With the first release of Mantle in Q4 2014 afaik). I still think there is enough slack in the timelines given that Apple must have had inside information. But I could be very wrong of course.

Apocryphon

I had originally assumed that Vulkan was an open-source response to Metal just by the name alone- Vulkan resembles Vulcan, a metalworker god. But I suppose these naming conventions would be common when you're writing code that's "close to the metal."

darklion

> Probably just because Apple never cooperates with anybody.

Apple cooperates plenty; they manage a variety of non-trivial open source projects and are a member of numerous industry organizations (both OSS and proprietary, both software and hardware) and standards bodies.

Apple just never lets "cooperate with people" be a permanent restraint to providing a proprietary but (in their opinion) better experience.

GeekyBear

> Apple cooperates plenty

Apple created, open sourced, and donated OpenCL to Khronos as an open alternative to Nvidia's proprietary CUDA, for example.

smoldesu

And how did that little experiment go?

db48x

Yea, I admit I was being slightly hyperbolic. Historically they have been better at cooperation than Microsoft.

grahamlee

There's a lot of "Apple business model" answers in other threads, but I think that's at best a partial answer if it's an answer at all. To the extent that you can draw a line to "move the revenue numbers by tens of billions of dollars per quarter" from "choose whether to support this open standard API or create our own", which I think is a large extent, I think that line goes through performance. Apple now sell 120fps as a marketing feature. OpenGL ES was holding back performance of the graphics stack by not really being what people wanted to do with the GPUs and also not really what the GPUs were good at. Apple design the GPUs and the image/video frameworks, they know what APIs they can provide to get high-performance access to the types of task they need to be able to do.

bitwize

Metal is a fantastic API for the Apple ecosystem. Apple likes to call their own shots and not depend on anybody else when it comes to implementing cutting edge functionality in their devices and exposing it to developers.

As an Apple developer, this means you have to suck it up and do things the Apple way, or gtfo. The MoltenVK library, however, wraps Metal calls in a Vulkan API, so you still have options.

Tagbert

Do you have any basis or specifics about what makes Metal “half-baked” or was that just an assumption?

sto_hristo

/rant The disparity between platforms and platforms within the same family is pretty (ipados and ios) much at its most extreme. I really hate the state of things we're at. I compare it to having different html and css for different screen sizes and browsers. And the wrappers that attempt to bridge that gap simply don't cut it.

The first company that delivers a truly open (i.e. users own their own devices) and unified experience across all form factors is going to conquer the whole market and current companies and their tech will find themselves in the junkyard.

Shadonototra

Metal is preferred over Vulkan by game developers, it says a lot about how Vulkan is the one that is half baked

Apple was once a supporter of Vulkan, then they abandoned the bloated ship and they made their own tech

Roblox: https://blog.roblox.com/2020/05/3-years-metal/

Koiwai

Any citation to back these claims?

I'd like to think this is mainly determined by platform, if you want Windows, you use DX, iOS/Mac - Metal, Android - OpenGL/Vulkan.

You can use Vulkan on Windows or proton or moltenvk, but those are minorities.

Shadonototra

> One other important aspect is Metal implementation is much simpler than a Vulkan one — more on that later — so in some sense I’d prefer a Metal -> Vulkan wrapper instead of a Vulkan -> Metal.

smoldesu

Jasper_

This is a very inaccurate summary of the space. There aren't that many studios doing Vulkan ports, unless you want to target Linux, but even Valve prefers Proton and are telling people not to port. Or Android/Stadia, but nobody gives a shit about that to do that.

The big engines have support for both Vulkan and D3D12, and use the D3D12 backend on Windows.

Studios are porting to D3D12, by comparison, somewhat because of Xbox, but also because it's a somewhat standard upgrade from D3D11. The developer experience of the D3D12 debug layer is much better than Vulkan.

Disclaimer: I lead the Vulkan and D3D12 ports of the engine at the last game studio I worked at.

roytries

I'm purely a hobbyist. But I was under the impression that D3D12 is so different compared to D3D11 that this would be a good time to consider both D3D12 and Vulkan. Is the choice for D3D12 standard because it 'sounds' familiar. Or is there more overlap with D3D11 than I was aware of?

Jasper_

D3D12 is very different from D3D11, but still has a lot in common. We started our port by reusing most of the same DXGI code and getting what we called our "sprites" rendering correctly (2D quads, used by the loading screen, and our debug UI). We were able to reuse a lot of code, including all of our existing HLSL shaders. None of that would work with Vulkan, at least without a lot more work (which we eventually did).

The parts that were D3D12-specific were definitely the parts that would overlap more with Vulkan: the work to switch to PSO (Pipeline State Objects), the addition of all the barriers all over the rendering code, the synchronization work, all of that work could be shared between D3D12 and Vulkan.

joe91

You do need a very different design to efficiently target D3D12 and Vulkan. You need to think in terms of pipelines, root signatures/descriptor layouts, tables of descriptors and resource transitions. But its quite easy to also target D3D11 in this way:

Pipeline state -> struct of the 3 or 4 state objects + a few values (this actually makes redundancy checking easier and can actually be a win :)

Root signature -> fixed pre allocation of binding slots (this can even be done statically with templates if your root signature is known statically)

Tables of descriptors -> arrays of handles

(edit: you obviously cannot do the kinds of bindless things with D3D11 that you can do with D3D12 and Vulkan. But its common to have both bindless and non-bindless code paths with D3D12 and Vulkan anyway)

Resource transitions -> nothing

Koiwai

> but even Valve prefers Proton and are telling people not to port.

Citations?

https://www.phoronix.com/scan.php?page=news_item&px=DXVK-Nat...

zibzab

Is this an official Steam recommendation?

BTW, it hurts me to see GP being flagged. Please discuss your arguments instead of flagging comments you don't agree with.

mikestew

Please discuss your arguments instead of flagging...

When a comment starts with "walled garden", there usually isn't anything to discuss. Just like the assumption-filled title of this post, the commenter has already established their position with a tiresome, and probably not even accurate, assessment of the situation. I don't know if that warrants flagging, but it sure doesn't warrant much discussion.

Koiwai

Let's just say it tells how many apple fanboys are here.Daily Digest email

Get the top HN stories in your inbox every day.

Email addressFrom:BrianTo:[email protected]Daily DigestSaturday, March 14npm install -g @brianlovin/hn-cli