MP All Models 40 core ASI with PCI-E slot is around the corner!!

[leman]

This is the question; assuming we get an ASi Mac Pro, what form will the CPU/GPU come in...?

Since I am supervising an exam and don't have anything constructive to do, I'll bite.

• AMD-style CPU & GPU chiplets with a larger (process) I/O die/memory controllers/whatnot...?

I doubt that Apple will use this kind of solution because of its drawbacks. Apple has much more sophisticated technology in the pipeline (e.g. die stacking)

• Nvidia-style SuperChip...?

Nvidia's super chip is basically an M1 Ultra, just with a slower connector and specialised dies. If anything, I'd describe Grace Hopper as an "Apple-style chip".

I don't think Apple will go this route simply because Mac Pro is a low-volume product and it will be very cost-inefficient to make two specialised dies just for it. There is a reason why Nvidia charges 8-digit sums for their "superchip".

• Two Mn Ultra daughtercards on a proprietary high-speed backplane...?

That's my personal favourite, but comes with its own set of challenges. Will Apple be interested in going that route? Who knows...

• Mn Extreme (quad SoC configuration) on new interface/packaging technology...?

Rather unlikely, me things. There is no indication that they have a quad SoC technology close to release. Usually there is a flurry of patents close before product release, but everything we saw for M2 specifically mentions two dies. But everything is possible, I suppose...

I like the SuperChip, because it is similar to the asymmetrical SoC concept; one "regular" Mn Max SoC UltraFusioned to a "GPU-specific" SoC; for a CPU-cores to GPU-cores ratio that favors the GPU-core count...

Yeah, that's certainly an advantage. Another advantage is that you can use specialised RAM for each die without losing the UMA property. But again, I don't think Apple will go that route. Overclocked M2 Ultra is more likely, and multiple overclocked M2 Ultra boards would be even better.

 

[Boil]

Look mang, I'm just trying to throw more GPU cores at "the problem"...?!? ;^p

 

[deconstruct60]

However, it might soon become one if they want to improve performance. The dies are already getting very large. And they have to deal with bad density scaling for SRAM. Breaking the SoC into, say, a higher-density compute die and a lower-density memory/aux die could be one way to continue increasing compute cluster sizes without incurring high manufacturing cost. And package size reduction kind of goes hand in hand with this — as you say, these chips are already big, 2D stacking would make them even bigger.

SRAM isn't getting larger ( minor N3B -> N3E backslide aside. relative to N5 it isn't) . It is just stopping.
the Ultra's InFO-LSI is still 3D stacking. ( uses 3D to cover the additional die-to-die overhead). If the compute die gets smaller and the cache memory die stays the same (and the die-to-die interface gets absorbed 3D without an extra long interposer length), then the whole package should get smaller relative to some large , too chunky monolithic die.

This overlapping logic die approach isn't going to solve the problem that the CPU/NPU/GPU cores competing for budgeted die space. Or die edge space bandwidth limits because using 'poor man's HBM' instead of bleeding edge HBM (and stacking RAM dies higher).

Increasing the compute cluster size is going to be problematical if that also drives a huge run up on L3/L4 cache sizes. Overlapping cache on cache isn't necessarily going to get you more memory controllers paths. The CPU/GPU/NPU cores could take over more of the budget on the main die , but growing that die even bigger and then trying to 'cover it up' with 2.5D seems unlikely to scale well along any one of those core dimensions. More specialized cores that don't necessarily push a L3/L4 size increase perhaps.

Glue things together with twice as many interposers as InFO-LSI ( there is a horizontal and vertical interposer here) may or may not control costs. (factors of pad size of interposers playing a role).

 

[deconstruct60]

Is it out of the question that Apple might have been fiddling around with things closer to what nvidia and other HPC actors been doing with ARM? Even Amazon and Meta are creating their own chips now so to me it wouldn't be that far fetched for Apple to also make an apple silicon version for workstations and servers.

to a very large extent Amazon and others have not creating their own server chips. The bulk of Amazon's core design is standard Arm Neoverse cores. Amazon add some tweaks on top, but much of what is synergistically going on in the server market has been different vendors only slightly changing the baseline Neoverse design.

The reason why everyone and their mother has a 'Arm server package' is largely due to being able to license most of the design already done. That pragmatically means the vast majority of players here are all collectively sharing R&D costs (funneled through Arm. roughly similar to how everyone would funnel through Intel/AMD in x86. ).

Ampere Computing has their new core AmpereOne that is 'architectural license' derived. Nuvia disappeared off into Qualcomm. Most of the custom designs from before Arm's Neoverse effort are largely dead in the water (or just plain dead) now.

There is no practical way Apple can displace Neoverse significantly in the server space. Apple isn't going to license to those folks so they aren't going to replace Arm's stuff with Apple's stuff. Apple has no server products. So there is no foundation to even leverage off of. There is really about zero reason for Apple to "eat their own dog food' here also. M-series is unique good at running Mac stuff , not Linux server workloads. If Arm Neoverse and Ampere Computing get to a stable duopoly for Arm server packages , then Apple has stable two vendor space to buy product from for the vast majority of their web services needs. (and can slap Mini's , Studios , and MP into service for Mac specific stuff like XCode Cloud. )

 

[mode11]

Because Apple's standard corporate policy is to not talk about future products. When Apple said "Mac Pro later" they really were not talking about the Mac Pro at all. There is no descriptive adjective on the Mac Pro there. 'later' more so refers to some extremely nebulous even than to the 'Mac Pro'.

The Mac Pro providing some 'transform experience' is an attempt to add characteristic features to the Mac Pro. The whole point to is point off to some nebulous event off into the future. What "power and transform" activity going on is reserved for products he can actually talk about.

Yes, I said in a recent post that mentioning the Mac Pro at the Studio launch was primarily to make clear the Studio wasn't the Mac Pro's successor, not to fuel interest in the Mac Pro. And that the MP could take any form, not necessarily (or even likely) a direct replacement for the current one.

He would also be opening the door for the reporter to ask follow up questions about the Mac Pro trying to pull even small tidbits about the Mac Pro out trying to walk this guy right up to the very edge of what could be said ( which is basically nothing substantial). By leaving the Mac Pro out , he is basically directing the follow ups into what he can talk about.

OK, I get Apple's SOP, but Borcher was talking in very general terms about the potential for ASi. And if it's Apple's official stance that it's even possible there may not be a new Mac Pro, it contradicts the idea that they're also reminding us it's on the way (as the poster I replied to had suggested).

At the end of the day, the exec wasn't under any obligation to answer any follow up questions about the Mac Pro. Given its long delay, fielding a question or two about it could have been reasonably expected regardless. If so, he'd of course just said he can't talk about unreleased products, as per Apple's well-known policy.

The potential for someone who hasn't bought one yet. They are selling Macs here in this interview. That's their primary job. If it doesn't exist openly as a product you cannot buy it. If can't buy it 'potential' isn't really something to talk about.

He really isn't talking about M3, M4, and/or M5 series potential here either. And again those are future products.

Saying "we believe strongly" inherently suggests future tense. You don't have to 'believe' anything about products that are already on the market - customers are using them. He certainly includes current products in his statement, but it's not limited to them.

He is trying not to say something that could get him fired. He is putting a healthy boundary around a topic he doesn't want to discuss.

Quite possibly. Apple better have something to say soon though.

 

[dgdosen]

... Apple either needs to glue multiple dies together or resort to some other trickery, none of which come cheap.

With Moore's Law slowing via shrinking semiconductor node sizes - I'd think Apple would be heavily investing in ways to make multi-die packaging cheaper.

Especially if you can use different nodes for different parts of today's SOCs. Expensive packaging glides down that cost curve when scaled to 200-300 million SOCs per year (phones).

 

[smulji]

There's already been the Gurman note that M2 Extreme was cancelled and the Mac Pro will top out at M2 Ultra

He's just guessing

 

[goMac]

He's just guessing

Is he? Cause he was right on the money with M1/M1 Pro/M1 Extreme/M1 Ultra. Down to the circuit design level.

If he's guessing then he needs to buy some lottery tickets.

 

[smulji]

There is plenty of evidence of the pending M3 Pro Max Ultra, they have been in HVM for months now.

Such as?

 

[leman]

He's just guessing

There is plenty of circumstantial evidence that M2 does not support quad configurations. From patents to die shots and firmware info.

 

[smulji]

Maybe in a year or two, or they'll shock us with some massively revamped XCode at WWDC this year (I doubt it).

Hot off the heels of FCP and LP for iPad, they could surprise us with Xcode for iPad.

 

[steve123]

Such as?

TSMC's earnings call. The CEO disclosed HPC and Smartphone chips were in production using the N3 process. There is widespread reporting that the only customer deliveries in 2023 for N3 will be to Apple. Apple's product introduction strategy changed last year to address supply constraints when ramping yield of a new process node (as opposed to ramping yield of a new product on a mature process). iPhone 14 Pro Max utilized the A16 which was manufactured using the N4P process. Base model iPhone used the A15 manufactured on a mature N5P process. Given this information, I suggest Apple will adopt a similar strategy for M3 series products and the M3 Pro Max Ultra will land at the next product announcement. Base M3 supply will be constrained so I suggest base M3 products will come later in the cycle.

We will know if this is the case in 5 days ...

 

[treehuggerpro]

Look mang, I'm just trying to throw more GPU cores at "the problem"...?!? ;^p

Done!

 

[Boil]

Watch apple tomorrow, i was tipped that M2 MBA 15 to launch tomorrow...

I'll take "Things That Never Happened" for $1000, Ken..."

View attachment 2209902

That bad boy could have up to 2TB of LPDDR5X RAM...

 

[prefuse07]

I'll take "Things That Never Happened" for $1000, Ken..."

Don't worry, he really meant tomorrow (and tomorrow and tomorrow and tomorrow until June 5th)

SOURCE

 

[Joe The Dragon]

Does Apple need better MDM in the Mac space. Yes. Is it going to be old school IMPI tools ? No.

IMPI is not MDM
and an server with no IMPI = fail
an server that need's an other full system hooked directy to it to reload / wipe / restore / install the OS / firmware = super fail
an sever that does not have at min an setup to let your boot disk be at least raid 1 with hotswap bays = Ultimate fail
Now maybe if apple had an small base disk for boot / os data. (not the 512GB - 1TB) that apple systems start at. then maybe but still need that IMPI that can do the DFU stuff.

 

[Joe The Dragon]

A second processor so a remote user on a computer can blow up the whole security chain of the host computer with the user not knowing? Probably not coming.

Does Apple need better MDM in the Mac space. Yes. Is it going to be old school IMPI tools ? No.

Just about all server boards have that.

 

[deconstruct60]

IMPI is not MDM

No. But where folks wine and grumble about raw imaging systems there is way too much overlap.

and an server with no IMPI = fail

Apple killed off macOS Server. What in the world makes you think Apple is going after the server market? The Mac Pro is primarily designed to be a single user , personal workstation. One user sitting in front of the system with a screen and operating a GUI.

HP Z4 G5 (best selling workstation) ... no IMPI (without add-ons ) [ there is Intel vPro but that is different product/standards)
HP Z6 G5 ditto.
HP Z8 G5 ditto.

Dell ... again if want to throw vPro and Intel machines into the mix.


Going down a very deep rabbit hole if thing Apple is going to chase after Nvidia's Arm server offering with anything. Extremely likely not going to happen.

an server that need's an other full system hooked directy to it to reload / wipe / restore / install the OS / firmware = super fail

Wipe/Restore/Install OS none of that absolutely requires a DFU scrub. Additionally the vast majority of Macs
don't even have a Ethernet jack so... where is you IPMI coming from when there is no Ethernet?

Firmware updates nominally come inside of macOS updates. There is zero need for a second computer there in the slightest.

Again need some recovery system that works on systems that could be borked and have no working networking at all. ( 70+ % of Mac sold are laptops with no Ethernet at all). The notion that oh well the Mac Pro should have an utterly completely different restore process. Again off in fantasy land.

an sever that does not have at min an setup to let your boot disk be at least raid 1 with hotswap bays = Ultimate fail

Hotswap bays ... up there with the rants during XServe era about redundant power supplies. If Apple doesn't do bow and scrape at the feed of the data center priests then the Mac will fail. No XServe Macs will fail. Not.

The Macs allows a security firmware setting where can boot off an alternative drive. As long as have that can just use the default Apple provided drive as either maintenance or hypervisor boot drive.

APFS does really support booting from software RAID 1. APFS does not do user data (non metadata) integrity protections either. This isn't a Server OS so that really shouldn't be surprising.

Is Apple going to offer hardware RAID 1 to separate disks built into the system? Practically the whole line only has one , and only one, internal drive. Doubtful they will make something different just for the Mac Pro. Additionally, Apple's SSD pricing is so relatively high, is there even much of market for buying two of them in a single system? That is doubtful.

Now maybe if apple had an small base disk for boot / os data. (not the 512GB - 1TB) that apple systems start at. then maybe but still need that IMPI that can do the DFU stuff.

DFU happens using Apple Configurator . There is no way a baseband , out of bandwidth core is going to run that.
Firmware and resets come straight from the 'mothership' at Apple. Can wish it worked differently, but it doesn't.

 

[deconstruct60]

I should clarify that I was primarily thinking of desktop Macs. I completely accept ASi's strength with mobile (which isn't surprising given its heritage). I also accept that most Mac sales are laptops (or essentially a laptop with either a big or no screen).

My point wasn't about using commodity PC parts though. It was about whether Apple can make a desktop with a GPU equivalent to a high-end PC GPU. Or whether the SoC architecture makes this impractical and they just sacrifice this part of the Mac market (given that most Mac Pros are likely used for audio / video work, which ASi excels at).

... I'll loop back to this.

Buying an iOS app and using it on both an iPhone and iPad makes sense, as both are touchscreen devices. No Mac has a touchscreen, so the synergy there is more dubious (other than perhaps for iOS dev).

With iOS devices spanning down to 4.7" screens and iPads up to 12" (and reportedly future 14" ) screens. The layout differences in between a 14' iPad Pro and a 13" MBA are not that much different. Mechanisms like SwiftUI and other modern Apple libaries are suppose to help with portability inside the Apple ecosystem.

The other issues is that vast majority of Mac do have a touch surface. It isn't the screen , it is the touchpad.

Too this day Instagram looks clunky on an iPad. Clunky on a 13" Mac really wouldn't be that much different.

Sure, the same x86 cores are used across mobile, desktop and workstation/server. The difference is that Intel and AMD systems have the option of using dGPUs or iGPUs. ASi is more 'mobile' in the sense that its SoC architecture makes it extremely power efficient, but appears to preclude dGPUs.

No dGPU in M-series so far is vastly more likely a software issue than an architecture issue. There is really nothing in the SoC architecture so far that precludes dGPUs at all. There are over 50 PCi-e cards that work with M1-M2 system right now. So a device on a PCI-e bus is not some serious impediment at all at the hardware level.

There is not copious extra , unused room on these dies so folks looking to get into a pissing contest of maximum number of PCI-e lanes with Xeon W2x00-3x000 or AMD Eypc or Ampere Computing Ampere One probably will be left unsatisfied but there is nothing in the hardware architecture itself that precludes this. Apple is doing four x1 PCI-e v4 and four x4 PCI-e v3 controllers on the arhectutres so far so it isn't like they don't "do" PCI-e. It is a matter of lanes (and associated edge space).

UltraFusion connector opens the door to put some PCI-e on another chip. And the architecture doesn't preclude a second or third die being present.

What is limited is Apple GPU's ability to run badly optimized code well. There isn't loads of excess bandwidth , excess GPU cores , tons of data copying, excess etc etc to just blindly brute force results running quicker. Nor is Apple going to jump through tons of gyrations to add hacks into the graphics stack to get around quirks in someones misguided approach to a graphics engine overlay. The vast majority of the line up doesn't have dGPUs. That means dGPUs are not priority one.

Without Apple iGPU optimized apps being highly widespread that puts the whole Mac ecosystem at risk . The problem space that absolutely requires multiple dGPUs would fall into is much more smaller. Apps for distributed , non uniform memory spaces are typically just constructed differently than those for a single , uniform , unified address space. That is where the big gap is.

 

[deconstruct60]

And this becomes particularly interesting when we look at Nvidia's Hopper. This is pretty much the same paradigm as Apple Silicon, only they use heterogenous RAM for the CPU and GPU dies plus a fast interconnect, and of course, everything is bigger.

Not really. The solution space that Hopper is aimed at is also filled with significant more distributed , NUMA memory structured apps. [e.g., lots of supercomputer nodes connected with very high speed Infiniband so that there are lots of near and far memory pools that need to be explicitly dealt with in code. ]

So not only are the memory pools hetrogenous but also demonstrably more non uniform also.

 

[Boil]

Apple killed off macOS Server. What in the world makes you think Apple is going after the server market? The Mac Pro is primarily designed to be a single user, personal workstation. One user sitting in front of the system with a screen and operating a GUI.

I fear there are some who see the rackmount variant of the 2019 Intel Mac Pro on the Apple website & automatically think Apple is back in the server business; the rackmount variant is mainly aimed at audio/video users who want to slap it in a remote equipment closet and move the noise out of the room they work in...?

 

[leman]

Not really. The solution space that Hopper is aimed at is also filled with significant more distributed , NUMA memory structured apps. [e.g., lots of supercomputer nodes connected with very high speed Infiniband so that there are lots of near and far memory pools that need to be explicitly dealt with in code. ]

So not only are the memory pools hetrogenous but also demonstrably more non uniform also.

Yeah, you are right, the Infiniband thing is probably the biggest difference. I was focusing on one Grace Hopper system and didn't mention this very important detail.

What is the board-to-board bandwidth of Nvidia's solution? I have difficulty understanding the marketing materials. Nvidia says they are using "NDR400 InfiniBand", which is supposed to be 400 Gbps (that's 50GB/s, right), but they also claim "up to 100 GB/s of total bandwidth across the superchips". So how does it work exactly? Two "super chips" on the same switch board only have the unidirectional bandwidth of 50GB/s (and bidirectional of 100GB/s)? What about the total throughput of the InfiniBand interconnect? Still only 100GB/s bidirectional? So if I have eight of these super chips per switch board, does it mean all of them have to share the 100GB/s channel when communicating with each other? That doesn't sound like much... what am I missing?

 

[stevebatter]

[DELETE - posted by mistake]

 

[theluggage]

No dGPU in M-series so far is vastly more likely a software issue than an architecture issue. There is really nothing in the SoC architecture so far that precludes dGPUs at all. There are over 50 PCi-e cards that work with M1-M2 system right now. So a device on a PCI-e bus is not some serious impediment at all at the hardware level.

Except that, of the ASi SoCs released so far, only the Ultra has enough external I/O to drive a higher-end GPU at full bandwidth and still have some TB4 ports left for other uses (and that's assuming you could convert 4 of the TB4 ports to 16 lanes of PCIe). Yes, you can run a dGPU with less than 16 lanes, even run a dGPU via Thunderbolt, but that's not going to impress the GPU performance freaks.

I think the real underlying reason is business planning: Apple don't have any track record in workstation or gaming dGPUs - Macs with AMD GPUs will only be as good as AMD's latest (at best - often it was more like "AMD's midrange from 2 years back") and Apple seem to have have burned their bridges with NVIDIA. They could develop their own dGPUs - but that R&D would be funded from >>10% of Mac sales whereas NVIDIA and AMD have far larger markets.

What Apple do have is a comfortable lead (which they will maintain if M3 and "3nm" turn up soon) in integrated SoCs for consumer/prosumer/light-professional phones, tablets, laptops and small-form-factor desktops - which is where most of Apple's money likely comes from. There's nothing really to directly compete with the MacBook Pro (you can get more powerful PC laptops, but they're bulky and have poor battery life) or Mac Mini/Studio (Intel NUC is hot, noisy and has a huge power brick, MS's ARM development system comes closest but a M1 Mini still cleans its clock). Macs aren't much good for "serious" gaming - but that doesn't stop Apple from having one of the major gaming platforms (it's called the iPhone and it doesn't need dGPUs).

It makes perfect sense for Apple to double-down on those markets - and if AR/VR and AI are the next big things, they'll be delivered to consumers via mobile gear, for which ASi is perfectly fitted. If the cloud-based backends are running on HP kit or the AIs have been trained on NVIDIA dGPUs that's not necessarily a problem for Apple, who walked away from the data centre years ago when they dropped the XServe (does anybody believe that the backends for Apple's current services are running on Macs?)

As far as we know, the Mac Pro is likely less about making money and more about maintaining Apple's rep as a maker of serious computers for serious people*. The tangible part of that is making sure that third-party pro apps remain available for MacOS - but if that means the apps are optimised for dGPUs, possibly even AMD or NVIDIA ones, rather than the Apple iGPUs in Apple's cash cow machines, that doesn't help Apple much.

* Although, frankly, a 4-year old Xeon/AMD tower with slightly improved plumbing to get power and Thunderbolt to PCIe cards - who's future has been in limbo since the announcement of Apple Silicon - isn't doing much for that.

 

[mode11]

With iOS devices spanning down to 4.7" screens and iPads up to 12" (and reportedly future 14" ) screens. The layout differences in between a 14' iPad Pro and a 13" MBA are not that much different. Mechanisms like SwiftUI and other modern Apple libaries are suppose to help with portability inside the Apple ecosystem.

The iPad Pro is 12.9", so is already a similar size to their lower end laptops (though uses a 4:3 aspect rather than 16:10).

The other issues is that vast majority of Mac do have a touch surface. It isn't the screen , it is the touchpad.

Right, but that hardly allows apps to work in the same way. iPhone apps can assume your hands are cradling the device, with your thumbs free to press on the screen; iPad apps can assume a much bigger screen than a touchpad.

Too this day Instagram looks clunky on an iPad. Clunky on a 13" Mac really wouldn't be that much different.

Great, something to look forward to...

No dGPU in M-series so far is vastly more likely a software issue than an architecture issue. There is really nothing in the SoC architecture so far that precludes dGPUs at all. There are over 50 PCi-e cards that work with M1-M2 system right now. So a device on a PCI-e bus is not some serious impediment at all at the hardware level.

Fair point. Though why has Apple shown no interest in eGPUs since switching to ASi? Would seem to have been an ideal opportunity to iron out any bugs before introducing dGPUs with a Mac Pro.

There is not copious extra , unused room on these dies so folks looking to get into a pissing contest of maximum number of PCI-e lanes with Xeon W2x00-3x000 or AMD Eypc or Ampere Computing Ampere One probably will be left unsatisfied but there is nothing in the hardware architecture itself that precludes this. Apple is doing four x1 PCI-e v4 and four x4 PCI-e v3 controllers on the arhectutres so far so it isn't like they don't "do" PCI-e. It is a matter of lanes (and associated edge space).

It's not a 'pissing contest' to want at least one or two PCIe 4.0 16x slots in a workstation. Thunderbolt 3 is just PCIe 3.0 x4.

UltraFusion connector opens the door to put some PCI-e on another chip. And the architecture doesn't preclude a second or third die being present.

Does UltraFusion really allow for this? Presumably, low-latency communication between the two SoCs is critical to them acting as one. If you start splitting and routing traffic, this is likely affected.

What is limited is Apple GPU's ability to run badly optimized code well. There isn't loads of excess bandwidth , excess GPU cores , tons of data copying, excess etc etc to just blindly brute force results running quicker. Nor is Apple going to jump through tons of gyrations to add hacks into the graphics stack to get around quirks in someones misguided approach to a graphics engine overlay. The vast majority of the line up doesn't have dGPUs. That means dGPUs are not priority one.

Sure, but "badly optimised" code = the way the rest of the computer industry does things. Why should developers of pro software bother to optimise their code for the way Apple does things, just because it suits their computers-based-on-iOS business model?

Without Apple iGPU optimized apps being highly widespread that puts the whole Mac ecosystem at risk . The problem space that absolutely requires multiple dGPUs would fall into is much more smaller. Apps for distributed , non uniform memory spaces are typically just constructed differently than those for a single , uniform , unified address space. That is where the big gap is.

One step at a time. How about supporting a single, big dGPU? This is something a lot of people would benefit from, not just edge cases.