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.
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.
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.
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."
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.
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.
> had already committed to development of Metal before they knew AMD was up to something.
They might have, but it's sort of a moot question. In 2012-2014, Apple was supporting four different graphics processors across their various product lines: Intel, Nvidia, AMD, and Apple A-series chips. Even if AMD had announced Mantle the day before Apple started working on Metal, it would've been a solution that only covered the AMD category, whereas the first version of Metal was capable of running on all of those architectures. [1]
The only alternative to Apple rolling their own would've been Apple working in conjunction with Kronos to develop a next-gen OpenGL. I can't find anything that indicates Apple approached Kronos, so it's hard to say whether Apple decided against it for technical reasons (Apple may have felt it would have been too long a time frame to reach a final form, or the design-by-committee approach would not have resulted in a satisfactory-to-Apple result) or political ones (perhaps there was insufficient appetite for that scope of change until Apple announced it was abandoning OpenGL for Metal).
> 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.
Apple developed most of it internally, proposing collaboration with Kronos in 2008, and released their implementation in 2009 with Snow Leopard. Apple supported it in their software for nearly a decade, only discontinuing it with Mojave and iOS 12 in 2018, a year after they introduced Metal v2.
It's still an open standard managed by Kronos and according to Wikipedia, has conforming implementations by Altera, AMD, ARM, Creative, IBM, Imagination, Intel, Nvidia, Qualcomm, Samsung, Vivante, Xilinx, and ZiiLABS. Kronos released a new major version of the specification, OpenCL 3.0, in September 2020, so the standard has clearly not suffered from the departure of Apple's implementation.
While Apple no longer supports OpenGL and OpenCL in their operating systems, Apple continues to be a "promoter" level member of the Kronos Group, and they continue to be involved in supporting Kronos' specifications and implementations through some of their other open source projects (e.g. Clang and LLVM).
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...
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/
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.
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?
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)
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.
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.
If Apple offered Metal alongside third-party APIs like Vulkan, I wouldn't be so quick to draw conclusions. However, they made the move to muscle out open graphics APIs from their desktop OS, and the only assumption I'm left to make is that they're directing people onto their own proprietary API in an attempt to lock down their developers and users. Again, if Metal were available on other platforms, or had actual competitors in the space, I wouldn't be so harsh. Until that is the case, it's the same as Apple's App Store: an undeniable walled garden. You can disagree with me, you can cite dissenting opinions if you want, but it's no different than the rest of Apple's product strategy.
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.
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.
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.
/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.
> 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.
35 comments
[ 2.8 ms ] story [ 86.4 ms ] threadNote 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.
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...
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.
They might have, but it's sort of a moot question. In 2012-2014, Apple was supporting four different graphics processors across their various product lines: Intel, Nvidia, AMD, and Apple A-series chips. Even if AMD had announced Mantle the day before Apple started working on Metal, it would've been a solution that only covered the AMD category, whereas the first version of Metal was capable of running on all of those architectures. [1]
The only alternative to Apple rolling their own would've been Apple working in conjunction with Kronos to develop a next-gen OpenGL. I can't find anything that indicates Apple approached Kronos, so it's hard to say whether Apple decided against it for technical reasons (Apple may have felt it would have been too long a time frame to reach a final form, or the design-by-committee approach would not have resulted in a satisfactory-to-Apple result) or political ones (perhaps there was insufficient appetite for that scope of change until Apple announced it was abandoning OpenGL for Metal).
--
[1] https://en.wikipedia.org/wiki/Metal_(API)#Supported_GPUs
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.
Apple created, open sourced, and donated OpenCL to Khronos as an open alternative to Nvidia's proprietary CUDA, for example.
Apple developed most of it internally, proposing collaboration with Kronos in 2008, and released their implementation in 2009 with Snow Leopard. Apple supported it in their software for nearly a decade, only discontinuing it with Mojave and iOS 12 in 2018, a year after they introduced Metal v2.
It's still an open standard managed by Kronos and according to Wikipedia, has conforming implementations by Altera, AMD, ARM, Creative, IBM, Imagination, Intel, Nvidia, Qualcomm, Samsung, Vivante, Xilinx, and ZiiLABS. Kronos released a new major version of the specification, OpenCL 3.0, in September 2020, so the standard has clearly not suffered from the departure of Apple's implementation.
While Apple no longer supports OpenGL and OpenCL in their operating systems, Apple continues to be a "promoter" level member of the Kronos Group, and they continue to be involved in supporting Kronos' specifications and implementations through some of their other open source projects (e.g. Clang and LLVM).
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...
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.
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
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.
BTW, it hurts me to see GP being flagged. Please discuss your arguments instead of flagging comments you don't agree with.
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.
It is not an impossibility, we simply don't know. Just flagging comments _you_ find tiresome is not good for the discussion.
Citations?
https://www.phoronix.com/scan.php?page=news_item&px=DXVK-Nat...
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.
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.
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.
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/
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.