8 ms·

It's very disappointing that Apple hasn't adopted Vulkan. It's not like they are completely against standards either. I believe they even joined the FIDO Allian

by mtgx 7y ago

It's very disappointing that Apple hasn't adopted Vulkan. It's not like they are completely against standards either. I believe they even joined the FIDO Alliance recently. With Apple adopting Vulkan, it may actually stand a chance against DirectX and the majority of game developers might start developing for Vulkan first. And Apple would benefit greatly from that, just like every other Vulkan supporter would.

tomxor 7y ago
Yes, I find it difficult to imagine developers that are enthusiastic about "metal", I mean who wants another platform specific API for graphics cards. If Apple really think we need something other than "vulkan" then they should push to make "metal" a competing open standard- But I doubt they think that, and It's quite easy to imagine ulterior motives, M$ had exactly the same motives.
- frou_dh 7y ago
  > If Apple really think we need something other than "vulkan" then they should push to make "metal" a competing open standard Metal predates Vulkan by years. They were already using Metal in shipping products before Vulkan existed.
  - tomxor 7y ago
    Why does that mean they shouldn't make it an open standard?
    - frou_dh 7y ago
      cos randomers don't get to dictate the scope of the project after-the-fact
      - tomxor 7y ago
        If "randomers" are developers who are repelled by the proprietary nature of their graphics API "randomers" may well dictate the scope of the project.
    - derefr 7y ago
      "Metal" is a vertically-integrated software stack that goes up into Objective-C runtime land. An open standard based upon it would require that there be an open-standard Objective-C runtime and toolchain to use in working with it. Unlike Vulkan, the lowest-level, C-ABI, non-type-safe parts of Metal aren't exposed as public APIs, AFAIK. You could maybe standardize those, but Apple presumably wants to reserve the right to change them while just keeping the higher-level ObjC ABI stable.
      - astrange 7y ago
        > Unlike Vulkan, the lowest-level, C-ABI, non-type-safe parts of Metal aren't exposed as public APIs, AFAIK. They don't even really exist. Most Metal APIs are defined as protocols (id<MTL...>) for a reason; if you look at the objects you get back, they're directly implemented by the GPU driver.
- pjmlp 7y ago
  All of us that rather use productive SDKs, with higher level languages, instead of a C API that only knows about drawing pixels. The same devs that rather use DirectX, libGCM, libGNM, GX, GX2, NVN.
  - tomxor 7y ago
    I am talking about principles of openness vs lockin, I am not personally interested in technical merits until I can depend on it existing beyond Apple's back garden. My point was I am surprised others do not care about this aspect, you are obviously one example - So my question to you (as someone who values it technically) is: does this not bother you?
    - pjmlp 7y ago
      APIs win on technical merits and market tooling, not on feels good kind of thing. Not at all, as someone that learned to program graphics when demoscene was all the rage, it is all about taking advantage of the hardware. Professional game studios are more than used to have a thin layer to abstract each 3D API, which is a very small codebase from any game engine/middleware.
      - tomxor 7y ago
        > APIs win on technical merits and market tooling, not on feels good kind of thing. Ok, but the technical merits for metal stop at Apple, you can abstract away differences in your translation layer if you care about your game existing outside, but you have to leave any merits of metal behind. Doesn't this dull your enthusiasm over improvements and features specific to metal? I get that the original demoscene you were using unique hardware, and unportable demos that squeezed everything they could out of that specific piece of hardware felt natural, but Apple computers use the same GPUs everyone else is using... doesn't that make a proprietary low level graphics API seem more artificial.
        frou_dh 7y ago
        Their most important platform uses in-house GPUs these days.
- flohofwoe 7y ago
  I'm quite enthusiastic about Metal, and I'm not even much of an Apple fan. Compared to Vulkan or even OpenGL, Metal's API design is much more elegant and developer-friendly. It can be used just fine without a "sanity layer", which can't be said about Vulkan.
auggierose 7y ago
Given they make their own hardware, it makes sense to push their own standard, especially with the kind of market penetration they have. Now if it would only be possible to run Metal in the cloud ...
mbroncano 7y ago
Although not an ideal solution, MoltenVK [1] does a great job at bridging that gap [1] https://github.com/KhronosGroup/MoltenVK https://github.com/KhronosGroup/MoltenVK
vondur 7y ago
Does any OS natively support Vulcan? Or do you get the drivers from a third party?
- Avamander 7y ago
  Pretty sure AMD on Linux can do Vulkan with just second-party stuff.
  - ken 7y ago
    The "second party" is the user. I don't think any users are writing their own Vulkan drivers.
    - Avamander 7y ago
      My mistake, thought about from the user perspective.
  - shmerl 7y ago
    AMD hardware has two drivers on Linux, radv by Mesa and amdvlk by AMD themselves. Not sure what you call "second party", but both are very competitive today.
- syjer 7y ago
  If you consider that window, normally use third party drivers (by amd, intel, nvidia) which bundle by default vulkan. Linux distributions and the more recent android versions?
- pjmlp 7y ago
  Only Android, and on Nintendo Swift as 2nd tier API (1st tier is NVN). Even on Windows, you need from get the drivers from OEMs, and they only work in old Win32 desktop mode, not on store/UWP. It remains to be seen if Windows sandbox will allow for anything else other than DirectX.
- shmerl 7y ago
  Pretty much every OS, except heavy lock-in oriented ones, where OS is controlled by some entity which prevents providing graphics drivers. In such case it's up to that entity to produce them, and in most cases their lock-in idea is against it.
klum 7y ago
As someone pointed out, it probably has to do with controlling the stack all the way from hardware to userspace. Increasingly, Apples UIs run on top of Metal and I get the impression they want complete control, not just "good enough". Which makes sense, it's what makes Apple worth it for many people. I totally get the inconvenience from a developers (or gamers) perspective, though.
leoc 7y ago
FWIW there have been one or two (apparent) Apple employees on here who seemed sincerely convinced that Vulkan was a mess compared to Metal. I have no idea how true that is or how much difference it actually makes, but there it is.
- pjmlp 7y ago
  Metal, nice OOP based tooling with several frameworks to support handling textures, fonts, materials, GPU live shader debugging, code completion on Xcode with static analysis, C++14 based shaders. Vulkan, plain old C style API, full of extensions just like OpenGL, leading to several code paths, just the bare bones pixel drawing, go fish for random libraries for anything else, try your luck with RenderDoc or GPU specific debuggers, enjoy Notepad++ + UNIX shell style tooling support.
  - bilbo0s 7y ago
    I believe this is a deliberate misrepresentation of the current state of affairs on Vulkan. Likely for the purposes of spreading disinformation about a specification that legions of smart, dedicated, hardworking engineers came up with after countless hours of debate and consensus. I mean be real... there is no way that any programmer who actually used Vulkan would find it as pleasant to work with as you imply in your comment.
    - pjmlp 7y ago
      Here is the list of Vulkan extensions with device coverage. https://vulkan.gpuinfo.org/listextensions.php https://vulkan.gpuinfo.org/listextensions.php Clicking a bit around, gives the Vulkan support version per device, which on Android is a mess, unless one only cares about flagship devices. https://vulkan.gpuinfo.org/listdevices.php?platform=android https://vulkan.gpuinfo.org/listdevices.php?platform=android Now regarding the tooling, since I am spreading disinformation, can you please provide us with the SDK tooling that matches the offerings from Apple, Sony, Nintendo and Microsoft, regarding their own APIs? Because what LunarG offers is pretty bare bones, and the OEM SDKs pretty much just provide the basic stuff as well, with C samples. I guess that someone that rather goes hunting for glm, uses sbt for textures, writes their own font rendering engine, compiles shaders from the command line, only knows about RenderDoc is capable of,... will feel very uncomfortable with the available set of Metal tooling and Frameworks. And this is one of the best tutorials available for Vulkan beginners, https://vulkan-tutorial.com https://vulkan-tutorial.com
whywhywhywhy 7y ago
sorry at this point we need to stop wishing Apple would adopt standards or wishing Apple would stop reinventing the wheel in their own bespoke stacks and just support what we believe in elsewhere.
ksec 7y ago
Vulkan is on Android, Direct X is on Windows, Metal is on macOS and iOS. I don't see anything wrong with it. Just like Windows did't adopt Vulkan. And that is assuming Vulkan is good in the first place. And most of the gaming development are now done with Middlewares like Unity and Unreal. The way I see it, more and more people will develop with Middlewares in mind, those API won't be touched by a shrinking amount of developers.
- leddt 7y ago
  Vulkan runs on Windows.
  - tambre 7y ago
    And Linux.
    - bronxbomber92 7y ago
      And macOS. And iOS.
      - thrower123 7y ago
        And anybody who is not a masochist and cares about compatibility across all those platforms will use Unity or Unreal or one of the lesser-known others. DirectX 12 is the easiest of these APIs to use, and it's not exactly fun.
      - master-litty 7y ago
        Exclusively with the use of MoltenVK, which uses Metal under the hood...
        grovesNL 7y ago
        Not exclusively -- gfx-portability (https://github.com/gfx-rs/portability https://github.com/gfx-rs/portability) is another option.
morio 7y ago
Why would Apple care about how DirectX is doing? They support 'Standards' and 'Open Source' to the extent that it benefits them and that's it. Vulkan is not designed to be used by game developers directly but rather as a basis for games engines like Unreal or Unity. So I don't see how game developers would benefit from its widespread support as the majority of game developers will never have to deal with it directly. That said Vulkan is an unmitigated disaster, though less so than classic OpenGL. Any API which fiddles with void* in 2019 should be put right back in a box. Security is mentioned exactly twice in the entire spec. Type-safety is mentioned twice also. And that is in a spec which is 900 pages long and incredibly complex.
- johncolanduoni 7y ago
  > Vulkan is not designed to be used by game developers directly but rather as a basis for games engines like Unreal or Unity. So I don't see how game developers would benefit from its widespread support as the majority of game developers will never have to deal with it directly. Vulkan has significant benefits even if you're not writing Unreal or Unity. One of the biggest is that it removes a lot of the heuristics and guesswork that OpenGL drivers do (e.g. with regards to when to move things in and out of GPU memory) that cause a lot of the bugs and incompatibilities on different IHVs/cards/platforms. Its validation layers also leave the halfhearted, vendor specific debugging extensions in the dust. > That said Vulkan is an unmitigated disaster, though less so than classic OpenGL. Any API which fiddles with void* in 2019 should be put right back in a box. Security is mentioned exactly twice in the entire spec. Type-safety is mentioned twice also. And that is in a spec which is 900 pages long and incredibly complex. Metal overtly has statically checked memory safety via ARC, but the reality is that the IHV libraries will segfault in response to semantic mistakes, just like Vulkan. A big difference is that Vulkan has cross-IHV validation layers that catch most of these mistakes during development, and they're only getting more comprehensive. It's totally trivial to write a wrapper over Vulkan that fixes the type/memory safety of the C interface; it's not trivial to create a validation system of anywhere near the quality of Vulkan's for Metal.
  - flohofwoe 7y ago
    From what I've seen so far, Metal's own validation layer also does very thorough checks, to a point where it almost replaces the documentation (as far as the quality of the validation error messages goes).
atq2119 7y ago
Pretty much all of the major game studios already have Vulkan implementations for their engines because of Stadia, Google's game streaming platform. Obviously we've yet to see how much staying power that will have.
Const-me 7y ago
You can't adopt stuff which doesn't exist. Apple was the first to release next-gen 3D API, Metal was released in 2014. Then came MS, DX12 was launched with Win10 in 2015. Vulkan was too late, initial release in 2016.
- knolan 7y ago
  What about AMD’s Mantle?
  - dmitriid 7y ago
    Created by AMD and supported in only a subset of AMD's cards. Appeared in 2013 (so, a year before Metal, and by that time Apple had probably already invested millions in Metal), and abandoned in 2015. So. What about Mantle?
    - knolan 7y ago
      Mantle lead to Vulkan. Your point about Vulkan simply arriving too late for Apple is not as clear cut as you make it.
      - dmitriid 7y ago
        Someone else answered about Mantle/Vulkan/Metal timeline in a different thread: https://news.ycombinator.com/item?id=20200116 https://news.ycombinator.com/item?id=20200116 (Note: I in no way imply that you spread false narrative etc. It just happens that this linked comment is such a reply)
  - Const-me 7y ago
    I don’t think Apple could adopt Mantle. They needed a GPU API to spawn across PCs and phones/tablels. Phones & tablets earn them most profits i.e. more important for them, but mantle was a PC-only tech.
- vetinari 7y ago
  Metal 1.0 was ultra-limited; it was more MVP than anything else. It was done exactly for the Apple to be "first". The initial Vulkan release was more comprehensive than Metal 2 in 2017.
Someone 7y ago
Ignoring both technical merit and politics, both of which I’m not qualified to judge on, one reason they didn’t adopt it may be that it didn’t exist when they switched away from OpenGL. https://en.wikipedia.org/wiki/Metal_(API) https://en.wikipedia.org/wiki/Metal_(API): ”Metal has been available since June 2, 2014 on iOS devices powered by Apple A7 or later” https://en.wikipedia.org/wiki/Vulkan_(API) https://en.wikipedia.org/wiki/Vulkan_(API): ”The Khronos Group began a project to create a next generation graphics API in July 2014” Of course, Apple could have changed direction later on, but they must have had a large investment in Metal by the time it became clear Vulkan would become a long term thing.
- bangonkeyboard 7y ago
  Johan Andersson (then of DICE) was a presenter at Metal's unveiling. Andersson was one of the prime movers for Vulkan and Mantle before it, dating to 2013. Apple was very aware of Mantle/Vulkan while designing Metal, just as Apple was very familiar with CUDA when it released its own ill-fated OpenCL alternative.
  - Someone 7y ago
    ”its own ill-fated OpenCL alternative.” https://en.wikipedia.org/wiki/OpenCL https://en.wikipedia.org/wiki/OpenCL: ”OpenCL is an open standard maintained by the non-profit technology consortium Khronos Group.” And yes, it started life that way. https://en.wikipedia.org/wiki/OpenCL#History https://en.wikipedia.org/wiki/OpenCL#History: ”OpenCL was initially developed by Apple Inc., which holds trademark rights, and refined into an initial proposal in collaboration with technical teams at AMD, IBM, Qualcomm, Intel, and Nvidia. Apple submitted this initial proposal to the Khronos Group. On June 16, 2008, the Khronos Compute Working Group was formed with representatives from CPU, GPU, embedded-processor, and software companies. This group worked for five months to finish the technical details of the specification for OpenCL 1.0 by November 18, 2008. This technical specification was reviewed by the Khronos members and approved for public release on December 8, 2008.” Apple first shipped OpenCL in August, 2009. So, OpenCL may be ill-fated, but I don’t see why Apple would have to have gone with CUDA, which is Nvidia-exclusive, both in actual hardware, and, AFAIK, license-wise.

by mtgx 7y ago

tomxor 7y ago

Yes, I find it difficult to imagine developers that are enthusiastic about "metal", I mean who wants another platform specific API for graphics cards. If Apple really think we need something other than "vulkan" then they should push to make "metal" a competing open standard- But I doubt they think that, and It's quite easy to imagine ulterior motives, M$ had exactly the same motives.

frou_dh 7y ago
> If Apple really think we need something other than "vulkan" then they should push to make "metal" a competing open standard Metal predates Vulkan by years. They were already using Metal in shipping products before Vulkan existed.
- tomxor 7y ago
  Why does that mean they shouldn't make it an open standard?
  - frou_dh 7y ago
    cos randomers don't get to dictate the scope of the project after-the-fact
    - tomxor 7y ago
      If "randomers" are developers who are repelled by the proprietary nature of their graphics API "randomers" may well dictate the scope of the project.
  - derefr 7y ago
    "Metal" is a vertically-integrated software stack that goes up into Objective-C runtime land. An open standard based upon it would require that there be an open-standard Objective-C runtime and toolchain to use in working with it. Unlike Vulkan, the lowest-level, C-ABI, non-type-safe parts of Metal aren't exposed as public APIs, AFAIK. You could maybe standardize those, but Apple presumably wants to reserve the right to change them while just keeping the higher-level ObjC ABI stable.
    - astrange 7y ago
      > Unlike Vulkan, the lowest-level, C-ABI, non-type-safe parts of Metal aren't exposed as public APIs, AFAIK. They don't even really exist. Most Metal APIs are defined as protocols (id<MTL...>) for a reason; if you look at the objects you get back, they're directly implemented by the GPU driver.
pjmlp 7y ago
All of us that rather use productive SDKs, with higher level languages, instead of a C API that only knows about drawing pixels. The same devs that rather use DirectX, libGCM, libGNM, GX, GX2, NVN.
- tomxor 7y ago
  I am talking about principles of openness vs lockin, I am not personally interested in technical merits until I can depend on it existing beyond Apple's back garden. My point was I am surprised others do not care about this aspect, you are obviously one example - So my question to you (as someone who values it technically) is: does this not bother you?
  - pjmlp 7y ago
    APIs win on technical merits and market tooling, not on feels good kind of thing. Not at all, as someone that learned to program graphics when demoscene was all the rage, it is all about taking advantage of the hardware. Professional game studios are more than used to have a thin layer to abstract each 3D API, which is a very small codebase from any game engine/middleware.
    - tomxor 7y ago
      > APIs win on technical merits and market tooling, not on feels good kind of thing. Ok, but the technical merits for metal stop at Apple, you can abstract away differences in your translation layer if you care about your game existing outside, but you have to leave any merits of metal behind. Doesn't this dull your enthusiasm over improvements and features specific to metal? I get that the original demoscene you were using unique hardware, and unportable demos that squeezed everything they could out of that specific piece of hardware felt natural, but Apple computers use the same GPUs everyone else is using... doesn't that make a proprietary low level graphics API seem more artificial.
      - frou_dh 7y ago
        Their most important platform uses in-house GPUs these days.
flohofwoe 7y ago
I'm quite enthusiastic about Metal, and I'm not even much of an Apple fan. Compared to Vulkan or even OpenGL, Metal's API design is much more elegant and developer-friendly. It can be used just fine without a "sanity layer", which can't be said about Vulkan.

auggierose 7y ago

Given they make their own hardware, it makes sense to push their own standard, especially with the kind of market penetration they have. Now if it would only be possible to run Metal in the cloud ...

mbroncano 7y ago

Although not an ideal solution, MoltenVK [1] does a great job at bridging that gap [1] https://github.com/KhronosGroup/MoltenVK https://github.com/KhronosGroup/MoltenVK

vondur 7y ago

Does any OS natively support Vulcan? Or do you get the drivers from a third party?

Avamander 7y ago
Pretty sure AMD on Linux can do Vulkan with just second-party stuff.
- ken 7y ago
  The "second party" is the user. I don't think any users are writing their own Vulkan drivers.
  - Avamander 7y ago
    My mistake, thought about from the user perspective.
- shmerl 7y ago
  AMD hardware has two drivers on Linux, radv by Mesa and amdvlk by AMD themselves. Not sure what you call "second party", but both are very competitive today.
syjer 7y ago
If you consider that window, normally use third party drivers (by amd, intel, nvidia) which bundle by default vulkan. Linux distributions and the more recent android versions?
pjmlp 7y ago
Only Android, and on Nintendo Swift as 2nd tier API (1st tier is NVN). Even on Windows, you need from get the drivers from OEMs, and they only work in old Win32 desktop mode, not on store/UWP. It remains to be seen if Windows sandbox will allow for anything else other than DirectX.
shmerl 7y ago
Pretty much every OS, except heavy lock-in oriented ones, where OS is controlled by some entity which prevents providing graphics drivers. In such case it's up to that entity to produce them, and in most cases their lock-in idea is against it.

klum 7y ago

As someone pointed out, it probably has to do with controlling the stack all the way from hardware to userspace. Increasingly, Apples UIs run on top of Metal and I get the impression they want complete control, not just "good enough". Which makes sense, it's what makes Apple worth it for many people. I totally get the inconvenience from a developers (or gamers) perspective, though.

leoc 7y ago

FWIW there have been one or two (apparent) Apple employees on here who seemed sincerely convinced that Vulkan was a mess compared to Metal. I have no idea how true that is or how much difference it actually makes, but there it is.

pjmlp 7y ago
Metal, nice OOP based tooling with several frameworks to support handling textures, fonts, materials, GPU live shader debugging, code completion on Xcode with static analysis, C++14 based shaders. Vulkan, plain old C style API, full of extensions just like OpenGL, leading to several code paths, just the bare bones pixel drawing, go fish for random libraries for anything else, try your luck with RenderDoc or GPU specific debuggers, enjoy Notepad++ + UNIX shell style tooling support.
- bilbo0s 7y ago
  I believe this is a deliberate misrepresentation of the current state of affairs on Vulkan. Likely for the purposes of spreading disinformation about a specification that legions of smart, dedicated, hardworking engineers came up with after countless hours of debate and consensus. I mean be real... there is no way that any programmer who actually used Vulkan would find it as pleasant to work with as you imply in your comment.
  - pjmlp 7y ago
    Here is the list of Vulkan extensions with device coverage. https://vulkan.gpuinfo.org/listextensions.php https://vulkan.gpuinfo.org/listextensions.php Clicking a bit around, gives the Vulkan support version per device, which on Android is a mess, unless one only cares about flagship devices. https://vulkan.gpuinfo.org/listdevices.php?platform=android https://vulkan.gpuinfo.org/listdevices.php?platform=android Now regarding the tooling, since I am spreading disinformation, can you please provide us with the SDK tooling that matches the offerings from Apple, Sony, Nintendo and Microsoft, regarding their own APIs? Because what LunarG offers is pretty bare bones, and the OEM SDKs pretty much just provide the basic stuff as well, with C samples. I guess that someone that rather goes hunting for glm, uses sbt for textures, writes their own font rendering engine, compiles shaders from the command line, only knows about RenderDoc is capable of,... will feel very uncomfortable with the available set of Metal tooling and Frameworks. And this is one of the best tutorials available for Vulkan beginners, https://vulkan-tutorial.com https://vulkan-tutorial.com

whywhywhywhy 7y ago

sorry at this point we need to stop wishing Apple would adopt standards or wishing Apple would stop reinventing the wheel in their own bespoke stacks and just support what we believe in elsewhere.

ksec 7y ago

Vulkan is on Android, Direct X is on Windows, Metal is on macOS and iOS. I don't see anything wrong with it. Just like Windows did't adopt Vulkan. And that is assuming Vulkan is good in the first place. And most of the gaming development are now done with Middlewares like Unity and Unreal. The way I see it, more and more people will develop with Middlewares in mind, those API won't be touched by a shrinking amount of developers.

leddt 7y ago
Vulkan runs on Windows.
- tambre 7y ago
  And Linux.
  - bronxbomber92 7y ago
    And macOS. And iOS.
    - thrower123 7y ago
      And anybody who is not a masochist and cares about compatibility across all those platforms will use Unity or Unreal or one of the lesser-known others. DirectX 12 is the easiest of these APIs to use, and it's not exactly fun.
    - master-litty 7y ago
      Exclusively with the use of MoltenVK, which uses Metal under the hood...
      - grovesNL 7y ago
        Not exclusively -- gfx-portability (https://github.com/gfx-rs/portability https://github.com/gfx-rs/portability) is another option.

morio 7y ago

Why would Apple care about how DirectX is doing? They support 'Standards' and 'Open Source' to the extent that it benefits them and that's it. Vulkan is not designed to be used by game developers directly but rather as a basis for games engines like Unreal or Unity. So I don't see how game developers would benefit from its widespread support as the majority of game developers will never have to deal with it directly. That said Vulkan is an unmitigated disaster, though less so than classic OpenGL. Any API which fiddles with void* in 2019 should be put right back in a box. Security is mentioned exactly twice in the entire spec. Type-safety is mentioned twice also. And that is in a spec which is 900 pages long and incredibly complex.

johncolanduoni 7y ago
> Vulkan is not designed to be used by game developers directly but rather as a basis for games engines like Unreal or Unity. So I don't see how game developers would benefit from its widespread support as the majority of game developers will never have to deal with it directly. Vulkan has significant benefits even if you're not writing Unreal or Unity. One of the biggest is that it removes a lot of the heuristics and guesswork that OpenGL drivers do (e.g. with regards to when to move things in and out of GPU memory) that cause a lot of the bugs and incompatibilities on different IHVs/cards/platforms. Its validation layers also leave the halfhearted, vendor specific debugging extensions in the dust. > That said Vulkan is an unmitigated disaster, though less so than classic OpenGL. Any API which fiddles with void* in 2019 should be put right back in a box. Security is mentioned exactly twice in the entire spec. Type-safety is mentioned twice also. And that is in a spec which is 900 pages long and incredibly complex. Metal overtly has statically checked memory safety via ARC, but the reality is that the IHV libraries will segfault in response to semantic mistakes, just like Vulkan. A big difference is that Vulkan has cross-IHV validation layers that catch most of these mistakes during development, and they're only getting more comprehensive. It's totally trivial to write a wrapper over Vulkan that fixes the type/memory safety of the C interface; it's not trivial to create a validation system of anywhere near the quality of Vulkan's for Metal.
- flohofwoe 7y ago
  From what I've seen so far, Metal's own validation layer also does very thorough checks, to a point where it almost replaces the documentation (as far as the quality of the validation error messages goes).

atq2119 7y ago

Pretty much all of the major game studios already have Vulkan implementations for their engines because of Stadia, Google's game streaming platform. Obviously we've yet to see how much staying power that will have.

Const-me 7y ago

You can't adopt stuff which doesn't exist. Apple was the first to release next-gen 3D API, Metal was released in 2014. Then came MS, DX12 was launched with Win10 in 2015. Vulkan was too late, initial release in 2016.

knolan 7y ago
What about AMD’s Mantle?
- dmitriid 7y ago
  Created by AMD and supported in only a subset of AMD's cards. Appeared in 2013 (so, a year before Metal, and by that time Apple had probably already invested millions in Metal), and abandoned in 2015. So. What about Mantle?
  - knolan 7y ago
    Mantle lead to Vulkan. Your point about Vulkan simply arriving too late for Apple is not as clear cut as you make it.
    - dmitriid 7y ago
      Someone else answered about Mantle/Vulkan/Metal timeline in a different thread: https://news.ycombinator.com/item?id=20200116 https://news.ycombinator.com/item?id=20200116 (Note: I in no way imply that you spread false narrative etc. It just happens that this linked comment is such a reply)
- Const-me 7y ago
  I don’t think Apple could adopt Mantle. They needed a GPU API to spawn across PCs and phones/tablels. Phones & tablets earn them most profits i.e. more important for them, but mantle was a PC-only tech.
vetinari 7y ago
Metal 1.0 was ultra-limited; it was more MVP than anything else. It was done exactly for the Apple to be "first". The initial Vulkan release was more comprehensive than Metal 2 in 2017.

Someone 7y ago

Ignoring both technical merit and politics, both of which I’m not qualified to judge on, one reason they didn’t adopt it may be that it didn’t exist when they switched away from OpenGL. https://en.wikipedia.org/wiki/Metal_(API) https://en.wikipedia.org/wiki/Metal_(API): ”Metal has been available since June 2, 2014 on iOS devices powered by Apple A7 or later” https://en.wikipedia.org/wiki/Vulkan_(API) https://en.wikipedia.org/wiki/Vulkan_(API): ”The Khronos Group began a project to create a next generation graphics API in July 2014” Of course, Apple could have changed direction later on, but they must have had a large investment in Metal by the time it became clear Vulkan would become a long term thing.

bangonkeyboard 7y ago
Johan Andersson (then of DICE) was a presenter at Metal's unveiling. Andersson was one of the prime movers for Vulkan and Mantle before it, dating to 2013. Apple was very aware of Mantle/Vulkan while designing Metal, just as Apple was very familiar with CUDA when it released its own ill-fated OpenCL alternative.
- Someone 7y ago
  ”its own ill-fated OpenCL alternative.” https://en.wikipedia.org/wiki/OpenCL https://en.wikipedia.org/wiki/OpenCL: ”OpenCL is an open standard maintained by the non-profit technology consortium Khronos Group.” And yes, it started life that way. https://en.wikipedia.org/wiki/OpenCL#History https://en.wikipedia.org/wiki/OpenCL#History: ”OpenCL was initially developed by Apple Inc., which holds trademark rights, and refined into an initial proposal in collaboration with technical teams at AMD, IBM, Qualcomm, Intel, and Nvidia. Apple submitted this initial proposal to the Khronos Group. On June 16, 2008, the Khronos Compute Working Group was formed with representatives from CPU, GPU, embedded-processor, and software companies. This group worked for five months to finish the technical details of the specification for OpenCL 1.0 by November 18, 2008. This technical specification was reviewed by the Khronos members and approved for public release on December 8, 2008.” Apple first shipped OpenCL in August, 2009. So, OpenCL may be ill-fated, but I don’t see why Apple would have to have gone with CUDA, which is Nvidia-exclusive, both in actual hardware, and, AFAIK, license-wise.