Such a shame that such essential support for hardware that comes with every Mac apparently needs to be provided by a third party.
Why? The whole point of having a general purpose computer is that you can install stuff. I do prefer to use the bundled facilities in my OS but sometimes third party alternatives are superior.
(The point of a phone is arguably different.)
That'd be pretty shameful, were it real. How macOS has handled the whole metal saga has been pretty shameful too.
The Linux Standard Base is a superset of POSIX (Portable Operating System Interface [for Unix]), with some small incompatibilities [1]
[0] https://www.opengroup.org/openbrand/register/ [1] ISO/IEC TR 24715:2006 Technical Report on the Conflicts between the ISO/IEC 9945 (POSIX) and the Linux Standard Base http://standards.iso.org/ittf/PubliclyAvailableStandards/ - there is probably a newer version of this report but that is not freely available
I do agree that this time it might be different. There's no great cross-platform open-spec solution for, say, EventKit, so when Apple offers up their own API, we've just gone with it. Game Developers are a huge existing community, in a way that Calendar Developers are not. Metal and Vulkan are an unstoppable force meeting an immovable object.
As someone who learned to program in the 1980's, it's pretty amazing that it's getting feasible to target high-performance graphics on every major platform from a single code base. Targeting every user in the world using only 2 graphics libraries doesn't seem so terrible to me. Consider how different the "Lemmings" source code must have been for Commodore Amiga versus the Commodore C=64, for example, not to mention the other 25 platforms it was ported to.
Metal has no such argument, to the best of my knowledge.
Vulkan is the typical Khronos API, pure C, has the extension dance to find out what is available, just knows about pixels and for everything else everyone needs to go fishing for libraries.
Maybe in absolute terms, but relatively speaking these things could not exist and nothing would change. They are /exceptionally niche/ libraries at best .. non-existent if honest
>At the time that DirectX was created Microsoft also largely controlled the OpenGL standard, the success of DirectX in gaming caused Microsoft to largely lose interest in OpenGL leaving it in the hands of the 3D chip OEM’s to advance as an open standard that they could use to pressure Microsoft to implement features they wanted in DirectX. Apple’s adoption of OpenGL and subsequent active participation on the ARB breathed life into OpenGL in mobile gaming because Apple’s iPhone implementation of OpenGL became the “standard” that other mobile phone and chip vendors had to emulate if they wanted to get IOS games ported to their devices. Without some form of “standard” hardware definition, OpenGL drivers and media drivers in general are often just a grab bag of broken inconsistent functionality. Of course in the absence of a “DirectX” like media API of their own design, Apple had little choice but to jump on the OpenGL bandwagon and ride it for gaming, but clearly it is not to Apple’s competitive advantage to be propping up OpenGL support in mobile for all of their competitors. Just as it did for Microsoft, creating their own proprietary gaming API’s is entirely in Apple’s strategic interest…. Why help Android siphon off their game developers by propping up OpenGL?
https://web.archive.org/web/20140606055700/http://www.alexst...
And such studios prefer APIs that fully expose the hardware, and then build their own abstractions, than something that hides that extra performance features.
All major AAA game engines already support Metal.
https://web.archive.org/web/20100524023205/http://playstatio...
Metal’s main advantage is that it lets you adopt more manual management incrementally (you can basically use it as a DX11 analogue if you’re not interested in low level performance gains). Vulkan is definitely intended primarily for engine developers, not for one-off games.
And you’re right - a look at the developer docs for Metal do show that ‘this matters’
[1] https://techcrunch.com/2017/09/12/the-new-iphone-8-has-a-cus... [2] https://developer.apple.com/documentation/metal/about_gpu_fa...
https://www.extremetech.com/gaming/238246-apple-built-its-ow...
Nobody is expecting Microsoft to add native Vulkan drivers on Windows, why would that be expected of Apple?
Windows has modern, fast OpenGL & Vulkan support due to Windows allowing IHVs (nvidia & amd) to supply the implementation through the Installable Client Driver model ( https://docs.microsoft.com/en-us/windows-hardware/drivers/di... ), which they do.
It's why AAA games have already shipped Vulkan and performed superbly with it (Doom, DOTA2, etc...), since they work with the IHVs to tune & fix bugs and then ship the driver update along with the game drop.
Microsoft doesn't support Vulkan or OpenGL, yet they also are not blocking them. That's the critical difference here. Why is Apple not allowing Nvidia or AMD to do the same on macOS? It's not a question of not supporting it out of the box or doing the work, it's a question of preventing others from supporting it.
Meanwhile, on the Mac, the cheese grater Mac Pro is the only model you can install their graphics cards into and it exited production half a decade ago.
The problem isn't that MacOS lacks Kernel Extensions.
The question is why should Nvidia or ATI take on the expense when there is no marketplace to compete in.
The only Mac you can purchase and use their products in exited production half a decade ago.
Without the possibility of making sales, why would they bother?
Apple's pro software made a big bet on OpenCL in the past, so I don't see them going with anybody but ATI for built in GPUs until they root that dependency out of their software and switch over to Metal for compute.
Nvidia certainly isn't going to put OpenCL performance on an equal footing with CUDA performance, so I can't see them getting a design win with Apple as long as Apple's in house software is still using OpenCL.
And yet: https://www.phoronix.com/scan.php?page=news_item&px=GTX-1080...
OpenCL performs great on Nvidia.
That happens to be not terribly long after Apple started offering rewrites of their pro apps that went all in on OpenCL.
Nvidia did put out a driver for the cheese grater Mac pro so it can use Pascal based cards, which is nice, but I imagine that's motivated by a desire to maintain CUDA dominance.
They probably figure, if developers are willing to do it for DirectX, they'll be willing to do it for Metal also / instead.
iPhone sales in 2017 were 223 million (https://www.usatoday.com/story/tech/talkingtech/2017/12/29/i...)
The total market share is a much more complicated picture, obviously, but I don't think the difference is nearly as big as you do.
In any case, that still puts Metal and DirectX in the same order of magnitude.
But AAA on a Windows desktop commands $40-60, whereas AAA on mobile commands < $8 +/- scuzzy IAP schemes.
This list[1] is quite a bit different looking from this list[2]
From Apple's perspective it's probably worth a try to get lock-in! Their real leverage is iOS, which lots of games want to target.
For comparison the Vulkan project began July 2014 and was released 19 months later. That released on multiple GPU vendors and OSes at launch, which Metal did not. So let's say Metal took 2 years from conception to release, even though it only targeted one platform and one GPU (and likely took less time as a result)
That means OpenGL was abandoned on OSX roughly 3 years before Metal existed as a project at all.
The timelines of Metal vs. OpenGL on OSX just don't line up at all to be any sort of API redirection effort. It just doesn't mesh.
Other than the framebuffer there's not even any data of worth on the GPU.
The attack of note that's been mitigated is DoS attacks through webgl, but GPU preemption is a thing now which largely solves the infinite loop in a shader to lock up the machine.
(And re the MMU features upthread, it's just a building block. Just like CPU having a MMU doesn't make your OS magically secure)
If you want to attack the shader compiler go for it, but since that lives in your own process anyway so you could skip that step and go straight to attacking whatever it is you wanted to attack.
> WebGL history (it's been much worse, not DoS only etc).
Such as? All I'm finding are DoS attacks. But regardless WebGL's problems were more due to WebGL and its designs than in vulnerabilities in the drivers or GPUs.
Regarding WebGL vulnerabilities, you can use your favourite search engine to look up vulnerabilities, here are some first hits for RCE bugs: https://www.cvedetails.com/cve/CVE-2012-3968/ https://bugs.chromium.org/p/chromium/issues/detail?id=740603 https://nvd.nist.gov/vuln/detail/CVE-2017-5128