Sources say (being fair of course) all this can be said about Apple’s efforts with Metal.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Intel Alder Lake vs. Apple M1
- Thread starter leman
- Start date
- Sort by reaction score
Well it is obvious that Apple isn't not releasing open source drivers for Apple silicon GPUs for lock-in. They already have lock-in since no one else will be using their SoC. Apple is keeping their GPU drivers private so that they have more flexibility to make under the covers changes as their hardware changes.
Difference: Apple sells the complete machine. They have no reason to gimp other hardware because there is no other hardware. Your choice for an Apple machine is what they give you, or you go PC. For better or worse.
Likewise, they cannot intentionally gimp PCs in a similar way NVidia leverages against AMD.
In fairness, they could document their own processors better to make Open source OSes easier to port I agree.
Apple has control over Apple, NVidia can stranglehold more than just NVidia.
I think there is an important difference: Apple has its own software platform with its unique APIs and characteristics. Nvidia does not - they sell hardware for existing platforms yet actively manipulate the ecosystem and the market to put their competitors at the disadvantage. Furthermore, Apples hardware is sufficiently different to justify new API patterns (Nvidia‘s is not), and Metal is sufficiently different from other existing approaches to justify its existence as a separate API with a unique forward-thinking design philosophy (in comparison, DX12 and Vulkan are mostly cosmetic variations of the same design).
Finally, let’s not forget that Apple tried hard to play the open standards games and got burned - multiple times. Apple was the one who developed OpenCL and donated it to Khronos, and it was Nvidia who essentially killed OpenCL by refusing to support it properly and pushing their own proprietary CUDA instead. Apple was initially on board with Vulkan working group but after other committee members refused to support its effort of creating an ergonomic API they backed out to focus on Metal.
More recently, Apple spearheaded the development of the next-gen web GPU API standard, ”donating” Metal as the basis of the upcoming WebGPU standard (you can read more about it here: https://gpuweb.github.io/gpuweb/)
Well, CUDA? There was a perfectly fine GPGPU API around - OpenCL, developed by Apple, managed by Kronos and fully embraced by AMD. Instead of helping to nurture this vision of unified GPU compute API, Nvidia used their market leader position to sabotage its adoption, pushing their own CUDA instead and denying the HPC GPU market to their competitors. Of course, it was a move that made perfect sense from business perspective for them, but it did end up making things worse for everyone else - especially the users - because now tons of useful software is locked behind the parasitic CUDA.
How that? Where are the examples of Apple forcing developers to sabotage their apps from running properly on other platforms? How do your statements relate to Metal specifically? For example, where would Apple withhold specific features from third-party GPUs capable of implementing these features? Metal runs great on AMD and Intel hardware btw, not because Apple has been “sabotaging” OpenGL somehow but simple because OpenGL is a terrible API by modern standards that makes is infinitely more difficult to write bug-free drivers and high-performance software.
Just counted the pixels from the bottom of the graph to the highest mark on each SoC series. 433 pixels high for the M1 Max vs 468 pixels high for the i9 11980HK, so (468 - 433) / 433 ≈ 8% faster than the M1 Max, according to the obviously cherry-picked graph.
None of the W6000 series GPUs can use the RT hardware with Metal even though it is present (unless something has changed with that).
That’s an excellent example, I didn’t think about it! Yes, true, makes one wonder. Are they simply using Navi 1 drivers? Is RT acceleration for AMD forthcoming? Did AMD simply not bother to implement hardware RT? Is Apple actively prohibiting AMD to implement these features? Or is it possible that the Metal driver model yet lacks support for HW-accelerated RT?
Also, a note on Intel using the ICC compiler. By default, Xcode uses Clang with the -Os flag set for release builds. This applies all known compiler optimizations that don't typically increase code size. This makes sense, since most apps are not performance critical and having a small binary is actually a benefit (less time to download when distributing the app, for instance). You can change the compiler flags to use -O3, for example (which instructs it to apply basically all known compiler optimizations, even those that result in a higher final binary size).
This are the default settings in Xcode 13.1, so it stands to reason that those are the settings that Intel used, since they didn't say otherwise. But you could get faster code compiling with the -O3 flag, for example. So using a different compiler, one that is specifically designed for HPC, and comparing it to a 'general purpose' compiler setup, which is typically used to run regular apps, not HPC apps, is comparing two different things.
(There are a thousand other things you can change in the compiler settings here and there, this was just an example, I don't know how big the effect of using a different set of -O flags for Clang would be, my point is that comparing a specific subset of tests that favour your architecture from a bigger benchmark while also using a custom compiler tailored for your own hardware that is not even used outside HPC to claim CPU superiority is stupid).
This are the default settings in Xcode 13.1, so it stands to reason that those are the settings that Intel used, since they didn't say otherwise. But you could get faster code compiling with the -O3 flag, for example. So using a different compiler, one that is specifically designed for HPC, and comparing it to a 'general purpose' compiler setup, which is typically used to run regular apps, not HPC apps, is comparing two different things.
(There are a thousand other things you can change in the compiler settings here and there, this was just an example, I don't know how big the effect of using a different set of -O flags for Clang would be, my point is that comparing a specific subset of tests that favour your architecture from a bigger benchmark while also using a custom compiler tailored for your own hardware that is not even used outside HPC to claim CPU superiority is stupid).
Last edited:
Yep, and icc optimizes much more aggressively by default than Apple’s clang. Also, check out slide 29 here: https://crc.pitt.edu/sites/default/files/Intel Compilers Overview.pdf
They are twiddling with compiler parameters to get best performance for each benchmark! It makes sense of course, but did they go through the same rigorous parameter selection procedure when compiling the tests on M1?
Unless Apple asked for the TMU to only be a TMU (and not a split TMU/RT unit, which would be weird) all RDNA 2 cards support hardware RT. Now maybe Apple is treating the W6000 line as RDNA 1 in drivers but that wouldn't explain why they don't support the 6700XT (which is "just a tarted up" 5700XT).
If I had to hazard a guess, all hardware optimizations for non-apple hardware have halted or drastically slowed to focus on Apple Silicon. Apple probably knows that they could implement the hardware rt in the Mac Pro but are not allocating reasources.
We’ll know for sure if there’s performance degredation after a couple years whether it’s malicious or not.
Oooh I thought of another one, Primitives IIRC Metal API doesn't support them right? And Smart Access Memory (something Intel added support for).
From what I understand it’s still AMD who writes Metal drivers (in cooperation with Apple of course, but still). Frankly, I think the most likely explanation is the driver model one. Since the bulk of the Mac hardware does not support hardware RT, the RT functionality is probably implemented in the common OS layer - before reaching the hardware-specific driver. This is probably the most economical approach as it would allow Apple to reuse much of the previously existing drivers (only adding new features like dynamic function linking and function pointers).
Just realised I said GCC ?
Yep, it makes no sense to tweak parameters individually for each sub-test and then claim it's representative of the general performance of the CPU vs another CPUs compiled with different, non-optimized settings.
Whats “Primitives”?
It’s far from obvious whether current Intel-based Macs are in principle capable of supporting resizable BAR. And frankly, even if they were I don’t really see how one can blame Apple for not investing resources into implementatino these features for practically obsoleted machines, especially given the fact that resizeable BAR mostly benefits high-end games (and even then, marginally), which are simply not available on macOS. Anyway, Apple Silicon makes it all moot as it has real unified RAM with shared cache.
from my understanding primitives are the AMD precursor to Mesh Shaders (which the W6000 also supports, but Apple doesn't in Metal).
That is fair on the SAM support (or lack thereof).
I think the key caveat to “blame” is whether or not effort was spent to hamper competition. I think it’s evident that Apple allocates resources to improve their devices only, ignoring say, Linux. NVidia has, through partnership leverage, actively put forth efforts to hamper their competition.
How many APIs actually support that feature? Never heard about it before. Metal also has to cater to certain common denominator, like any other API. It’s clear that Apple prioritizes features of their own hardware, after all, they are the platform’s future. My point was that it generally does not happen at the expense of other hardware or software manufacturers.
Great summary!
Mesh Shaders? 2 (Vulkan and DX12). Primitives? Technically 2, Vulkan and PS5 API, but functionally 1.
Metal does not support mesh shaders, probably because they are poor fit to Apple’s hardware - and virtually no Intel Mac software would support them anyway (kind of weird to implement a heavy feature for a single extremely niche available GPU option). But who knows, maybe next Metal version will offer something similar. It will most likely be Apple GPU exclusive though.
What Vulkan extension is that?
Actually looking at Mesh Shaders for Vulkan (there isn’t a Primitive Shader extension from what I could find, I think I was under the impression that it was AMD implementation of Mesh Shaders which existed in RDNA [and was broken in Vega]) it looks like the Vulkan implementation uses nvidia’s call. Which apparently isn’t 100% supported on AMD Hardware because nvidia implementation does some “shady stuff” [yall love the pun] That AMD Hardware isn’t expecting:
My bad I got confused there.
Last edited:
Overall I don't disagree about the things Nvidia did - especially in not updating OpenCl support on their cards to keep it crippled was an especially dick move on their part (which now that they've effectively killed OpenCL, they've now done ... just as Apple has deprecated OpenCL ... irony is dead and buried apparently) - but there are a couple of corrections and amendments:
1) CUDA actually predates OpenCL by just over 2 years. This gave Nvidia a huge lead. So there was not actually an open source GPGPU API to adopt (not that I think that this was would've stopped Nvidia's CUDA development had there been).
2) Like with their failure to compete successfully against DX with OpenGL, quite a bit of the blame goes to the Khronos group.
a) The biggest problem is that they didn't iterate on it quickly enough. In contrast, Nvidia (and this part is actually like Apple) leveraged their tight integration between software and hardware to iterate their features quickly.
b) Nvidia did a much better job of ensuring that that were great teaching materials, that community feedback got listened to and implemented quickly, and that there was an easy installation processes for a full, easy to use toolset.
The net result was that CUDA was simultaneously easier to use and more feature rich.
3) AMD cards, while having very good compute, had difficulty competing for much of the 2010s against Nvidia's graphics cards resulting in a smaller overall market share at all levels. Intel was supposedly going to save OpenCL with Xeon Phi, but that ultimately failed as a product to gain traction. Had Intel released serious GPUs in those days with OpenCL support, the combination of competitive Intel and AMD GPUs *might* have resulted in a different outcome. Or at least forced Nvidia to offer better OpenCL support.
I know we're getting deep off topic of Alder Lake now and, again, I don't want to minimize the things that Nvidia did that were anti-competitive. But a lot of things went wrong for OpenCL. (and this supports your overall thesis of Apple getting burned by supporting the Khronos group's open source projects)
Last edited: