As far as I knew, Apple had native but deprecated support. The translation layers I know of are supported by the community: https://github.com/openglonmetal/MGL
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.
Hard Truths About The Apple Silicon Replacement to the Mac Pro (2019)
- Thread starter Yebubbleman
- Start date
- Sort by reaction score
As far as I knew, Apple had native but deprecated support. The translation layers I know of are supported by the community: https://github.com/openglonmetal/MGL
If you run an opengl program under M1 and view trace in lldb, you will see it goes through `AppleMetalOpenGLRenderer`. Implemented at /System/Library/Extensions/AppleMetalOpenGLRenderer.bundle.
So they bothered to at least make their own translation layer, when they could easily have chosen to just drop support on M1 entirely.
So they bothered to at least make their own translation layer, when they could easily have chosen to just drop support on M1 entirely.
Metal is far better integrated with C++ than Swift. Metal Shading Language is based on C++17 and Metal is one of the only frameworks with custom C++ bindings.
Also most of the sample code is in C++/Objective-C and not Swift.
Apple are stubborn, but I think even they realized that swapping out C++ for Swift would be a step too far.
Also Swift isn’t that great for Metal anyway because Swift’s entire thing is type safety while Metal is mostly about working with pointers to huge buffers full of raw memory.
Apple is not going to design an entire hardware platform that defies the conventions of the PowerPC and Intel Macs that they've shipped for the last 25 years (as well as the rest of the PC industry) and then flip that on its head again for the Mac Pro. That's not how they generally do things, especially when it comes to THAT Mac. Is it a 100% definite? No. Everyone seems to love glomming onto that. But I'd be willing to bet the cost of one of these machines that I'm not wrong here.
That's not how (a) architectures and (b) computers in general work. Again, Apple is not going to create a radically different system architecture (and I'm specific when I say "system architecture here; not referring to the ARM architecture at all here) and then change it yet again for the Mac Pro. They did what they did with the Mac Pro in mind.
They have not done so as radically as they did with the advent of Apple Silicon SoC GPUs. And it seriously stands to reason that, with the kind of GPUs they have in things as high-end as the M1 Ultra version of the Mac Studio, they're not going to change gears that radically for the Mac Pro. Could they do Afterburner type GPU assist cards? I suppose they could. But you're not going to see PCIe GPUs the way we had on every PowerPC and Intel Mac that had a discrete GPU before.
While that may be true, Apple doesn't seem to agree with you. Or, they're gambling that those workloads could transition to Metal and/or be optimized for their GPU and accompanying SoC components (ProRes encode/decode engines and such). One of the two. That's the double-edged sword of Apple's now-total control over the Mac platform in the Apple Silicon era; it's their world; developers just build for it.
Sure! With that logic they can switch right back to Intel! The point isn't that they CAN. It's that they WON'T. That's a key distinction that you all are overlooking here!
Apple told everyone how this transition was going to go. I reiterated what Apple said and then logical conclusions that one can and should draw from that. You wanna call that rumors, be my guest. I'm not here for semantics debates!
If you like being surprised at Apple Keynotes, what are you doing here? This is like the spoilers page for Apple Keynotes.
OpenCL is stuck because OpenCL is effectively dead. Khronos prodding the cadaver with an electrode once in a while doesn't make it more alive. Serious compute nowadays is all about proprietary frameworks: CUDA for Nvidia, HIP for AMD etc.
I don't think Apple is averse to C++ as such. Metal Shading language is based on C++ 11 and Apple recently released C++ bindings to Metal. They are also generally quick with keeping up with latest C++ standards and they use C++ internally quite a lot.
But you mention a very interesting topic here. CUDA has popularised using C++ based DSLs to mix CPU and GPU code in the same source, and initiatives like SYCL are coping this approach. Personally, I am not a big fan. This model is targeting a typical HPC programmer who just wants to write some code and not to care about interfacing details (another technology that's similar in spirit is OpenMP, and I dislike it for similar reasons). But this convenience comes at a high cost. These tools lump too many things together, they lack tooling flexibility, leave you at the mercy of the framework implementor, and of course, they mess with the C++ standards.
The main reason why this model became so popular is because low-level interfacing in traditional APIs is just so incredibly awful. Merely sending some data to GPU and back can be a total nightmare. A C++ dev doesn't want to deal with dozens or more of API calls and difficult to understand synchronisation primitives. To put differently, it's not that CUDA is that good, but that GPU APIs are that awful.
Metal programming model is much more interesting to me, as it keeps the execution domains separate (and thus gives you more flexibility), but massively simplifies the interfacing between them. In this, Metal follows the well understood and conceptually simple shared memory RPC model. Apple can (and should) still make things easier. First, they should introduce unified virtual memory, so that pointers don't need to be marshalled between execution domains. Second, the interfacing API can still be made simpler. For example, keep the separation between CPU and GPU code at the source level (just like web does with JS and CSS), but add some syntactic sugar for importing GPU kernels as native functions. I think just implementing these two things will massively improve the GPU programming experience on Apple platforms without suffering from the same issues as other frameworks.
You are most likely spot on with this description of Apple strategy. However, I don't share your pessimism. There is evidence that their strategy is working, albeit slowly. In the last two years we saw popular framework implementing Metal backends. Sure, most of this was sponsored by Apple, but it's pretty much the first time that one can really use GPU-accelerated machine learning or rendering on a Mac.
Hehe, in my post I said it was based on C++ 17 so when I saw this I wondered which one of us was correct.
Turns out it's based on C++ 14
Damn! Exact midpoint!Hehe, in my post I said it was based on C++ 17 so when I saw this I wondered which one of us was correct.
Turns out it's based on C++ 14
Hehe, in my post I said it was based on C++ 17 so when I saw this I wondered which one of us was correct.
Turns out it's based on C++ 14
Yeah, Metal doesn't support my beloved fold expressions and I always forget whether those are in C++14 or C++17
I actually wish they did, it would make my use of Macs easier.
I just don't know. I really, really, don't see any use for a Mac Pro if they don't change their mind. Might as well go with a Studio Ultra and forget about any expandability. It'll be cheaper.
Thunderbolt/USB4 sucks compared to internal PCI expansion, but whatever. I know I wont be buying one.
I actually wish they did, it would make my use of Macs easier.
I'm pretty bummed about the end of x86-64 virtualization and Boot Camp, and I'm generally not a fan of how much more closed Apple Silicon Macs are as a hardware platform from Intel Macs. But for the future of macOS, I think this isn't so bad! (Plus, I really hate the T2 Security Chip with a passion and, professionally speaking, I'll be much happier when I don't have to deal with T2 Macs as part of my day job.)
The Mac Pro is for people that need expansion. The ability to swap out an SoC in favor of another one isn't as convenient (or as affordable), but if that's an option, that's not horrible! Otherwise, it's those PCIe slots! If you don't care about PCIe slots and don't need whatever is higher-end than Mx Ultra, then yeah, probably not the Mac for you. The Mac Pro was never the Mac for me. I figured if ever I needed to use one, I'd be using one owned by my employer and not one that I owned.
I think the Mac Pro is for those that can't do that. I think the Ultra configuration of Mac Studio is meant for those that were fine with an iMac Pro. Not every professional out there needs PCIe slots or more than 128GB of RAM. That said, there are surely those who do.
I actually wish they did, it would make my use of Macs easier.
I just don't know. I really, really, don't see any use for a Mac Pro if they don't change their mind. Might as well go with a Studio Ultra and forget about any expandability. It'll be cheaper.
Thunderbolt/USB4 sucks compared to internal PCI expansion, but whatever. I know I wont be buying one.
I think they will do internal expansion but it will be for things like sound cards and storage cards and other useful features like that.
As for accelerators, I don't think, nor would I want, them to backtrack on the Unified Memory Architecture, I really like the fact that we don't need memory copies to and from separate GPU memory any more and I think that it will be even better when Apple can drop support for external GPUs. I think the M(n) Extreme will have more than one chip fused together but it will all be on one package.
I would love it if you could basically have internal compute nodes - putting M(n)Extreme chips onto a PCIE/MPX card which essentially act as separate compute nodes on a network, except that network is internal to your computer! It would be even better if they added APIs to make distributing work to different nodes easier.
There are no folks on here who actually buy top end Mac Pros anyway. They just bitch about them.
Gurman's days were up nearly 10 years ago
Not for me, I expect I'll have to give it up eventually unless a hardware solution becomes available for running x86 VM's. There's just no advantage to me running it, even at home if I can't do me work on it, and for that, I need Windows. WoA really isn't good enough, so currently I have to remote into a Windows PC to do my work, and it's just a short change to just be using the Windows PC to begin with. For the kind of money I spent on my Studio Max, I could have bought a REAL nice Windows machine. I currently just use a Mac because I like them, but that only goes so far. I like Windows too. (not so high on Linux though!) I'm an outlier here, and I know it, so don't take what I say as doom and gloom for Apple. I'd much prefer if Macs and Windows machines hang around so I can buy the best machine for whatever job I need at the time.
Agreed, but I'm not seeing any rumors of expansion capabilities at all other than maybe ssd's. I hope I'm wrong because like you say, it's for people that need expansion. The RAM limits I've heard don't really even cover some of the stuff I do (VM based developing/testing) I'm not the target of the Mac Pro and never have been, but I have bought hi end machines for work, so I kind of know what they buy and why.
"Expansion capabilities" of a Mac Pro = specialised expansion boards. Things like extra storage (e.g. Pegasus R4i), capture cards, specialised network cards, etc.
It's been done before (cluster computing), but it's real hard OS/job wise to take advantage of such a setup. The timing of things and maximizing usage of these nodes just plain gives me a headache to think about. I suspect that if Apple did cancel the M2 Extreme chip, it was a bit of the same problem even at that scale.
NUMA computing is very difficult, yes. One of the problems is that the software needs to be aware of this configuration and coordinate execution with the system in order to maximise shared work within closer nodes, otherwise you can forget about achieving good performance. Apple already has NUMA APIs for Metal, what's tricky is the CPU side. There is a thread affinity API that could be used for this, but achieving between different SoCs could be tricky...
Their multi-SoC packages approach scaling very differently. The real killer of any kind of multi-processor system is synchronisation. Apple kind of side-steps the entire problem by directly connecting the on-chip networks. This effectively gives you a bigger chip. The rest works just like with the single-die system. For example, every memory controller is responsible for its own block of physical memory, and every block of SoC cache is responsible for its own set of controllers. When you send a memory request it might get routed to a memory controller/cache on the same die, or on the different die — this doesn't matter to the system. The latency will obviously increase due to the larger network size, but that's fine, that's what L2 caches are there to hide. The best part of all this — no need to worry at all about coherency, since there is only one source of truth.
Of course, the technical details are likely extremely complicated and building a physical interconnect that is capable of supporting network bandwidth of a workstation-class chip is a massive undertaking. There are also problems with power consumption (but Apple has some patents which describe how they plan to tackle it). Still, this is very cool stuff.
Gurman had an actual source that garnered him fame at 9to5mac and got him hired at Bloomberg, and that source promptly disappeared when get got hired by Bloomberg. Today he simply surveys what the other leakers say and waits until 3 days before a product launch to weigh in. He's a total nothing.
The Mac Pro served a lot of different customers in the past. From those that wanted a $2,500 Mac to a $50,000 Mac and all in between.
Today the Mac Studio is already serving a good 70% of the previous Mac Pro market. The Apple Silicon Mac Pro (which is essentially a 2x Mac Studio) will serve about 25% more.
The negligible group of users who remain don't need to be serviced by Apple. Not if serving them is counter to the direction of the Mac itself, which it is.
It doesn't seem unfeasible to me that Apple could simply write AMD drivers for ASi based Macs. That's all that's really missing from those Macs at any level. Doing so would allow for eGPUs, and allow for AMD GPUs in future Mac pros. It allows them to retain their SOC architecture and so on, while allowing users to upgrade their GPUs or to have multiple GPUs should their workflow support that need.
On the RAM front, I'm not sure. Maybe it is doomed to have SOC only RAM. Maybe not.
We can read the rumor mill to death, but ultimately we won't know what to expect until Apple releases their first Mac Pro and we see it ourselves.
It's entirely possible Apple will depart from the SOC style and break it down into modular components specifically for the modular Mac. That would support their cancellation of the M2 Extreme chip, because they realized that when you get to the high end market, your needs for more RAM, CPU cores, GPU power, etc don't scale linearly with each other. Sometimes you're a pro that needs 5x GPU power and standard CPU power, and sometimes the other way around. Why pay for systems you don't need, until you need it, when you're talking about the high end modular sector?
I'm pretty sure Apple knows all of that, and the struggle to build something that can check the modular requirement box is probably why the Mac Pro has been the last in the lineup to be updated. It's not that they can't just interconnect more chips, it's that interconnecting more chips doesn't always make sense.
On the RAM front, I'm not sure. Maybe it is doomed to have SOC only RAM. Maybe not.
We can read the rumor mill to death, but ultimately we won't know what to expect until Apple releases their first Mac Pro and we see it ourselves.
It's entirely possible Apple will depart from the SOC style and break it down into modular components specifically for the modular Mac. That would support their cancellation of the M2 Extreme chip, because they realized that when you get to the high end market, your needs for more RAM, CPU cores, GPU power, etc don't scale linearly with each other. Sometimes you're a pro that needs 5x GPU power and standard CPU power, and sometimes the other way around. Why pay for systems you don't need, until you need it, when you're talking about the high end modular sector?
I'm pretty sure Apple knows all of that, and the struggle to build something that can check the modular requirement box is probably why the Mac Pro has been the last in the lineup to be updated. It's not that they can't just interconnect more chips, it's that interconnecting more chips doesn't always make sense.
While it would be hard to take advantage of the capability I think that a Mac Pro with an internal compute cluster would have value to people who currently use a cluster of Mac Pros or Mac Studios to do rendering or compilation. These are tasks Apple should work to recapture and enable.
I don't think most application need to know anything about this cluster that lives alongside the main processor, most developers shouldn't ever worry about this. It should be for scientific computing, rendering, large scale compilation etc... I think it's an opportunity to really differentiate the Mac Pro from competitors as well.
From what I understand, any GPU drivers would need to deal with UEFI hooks for boot up when Apple silicon Macs don't have UEFI at all. I'm not sure how that would get resolved. Maybe it doesn't matter since the default boot display could be the internal GPU.