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.
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):
”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.
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:
”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.
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.
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.
OK are you a graphics professional? Have you written renderers in Vulkan? Do you have any idea of what you're talking about? What "void*" pointers are you referring to? Are you aware that type-safety is very much a design goal of the API? Are you aware that the spec ships with a formal memory model which is a godsend for graphics engineers that had to deal with implicit guarantees in other APIs for years? I'm not someone that authored the original spec, but reading your comment is somewhat rage-inducing given how off-base it is.
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.
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.
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
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
You're definitely right about significant parts of the toolchain being weaker. In particular sorting out how glslang -> Vulkan works in practice is pretty trial-and-error, and if you want to use HLSL it's even more poorly documented. You have to expect to be going through the Vulkan spec (which I will say is much easier than directly using the OpenGL spec). However the Vulkan validation layers are incredible, and leave the equivalents for Metal, DirectX, and especially OpenGL in the dust.
I think it's just a matter of not having had much experience with it. It is natural to look at the shape of the API and have PTSD about wrestling with OpenGL for the past few decades.
So what made Metal a better technical choice than Vulkan, back when the options were "Metal without Apple's support built yet" and "Vulkan without Apple's support built yet"?
I believe the stated strategy is to let third party middleware handle the higher level abstractions so that different approaches that appeal to different people can coexist. This also theoretically reduces driver complexity and thus (hopefully) bugs.
I have absolutely no idea if this is actually a good idea, or if it's working out in practice. In case anyone wants to poke around the ecosystem: (https://github.com/vinjn/awesome-vulkan).
Oh god I hope not. I come from the API mess that was OpenGL over 3 major versions, and I was hoping all the lessons learned from that were applied to Vulkan.
Graphics APIs are not good when designed by committee.
Metal predates Vulkan by years. They were already using Metal in shipping products before Vulkan existed.
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.
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.
The same devs that rather use DirectX, libGCM, libGNM, GX, GX2, NVN.
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?
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.
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.
Many game studios are quite happy being Apple experts, just like many other game studios release exclusives or sell themselves as experts on a given platform, including selling consulting services.
For those, vendor tooling is very much appreciated.
The ones that care for portable code, they also care about having the easiest way to start coding on each platform.
If Khronos cares about adoption, they should improve LunarG SDK to be more than just a set of bare bones libraries.
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.
So. What about Mantle?
(Note: I in no way imply that you spread false narrative etc. It just happens that this linked comment is such a reply)
It was done exactly for the Apple to be "first". The initial Vulkan release was more comprehensive than Metal 2 in 2017.
Nowhere was mentioned, that Metal 1 and Vulkan 1 were not comparable by a long shot. Exacly, precisely because it was MVP focusing on specific mobile GPU.
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.
DirectX 12 is the easiest of these APIs to use, and it's not exactly fun.
Linux distributions and the more recent android versions?
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.