Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Why doesn't the dynamic caching and superscalar execution help the gaming side as much as it does the rendering side?


They built those features into metal 4 api they just can’t get developers to rewrite there entire games to use those features. Or developers don’t want to exclude all devices older than the 17pro/ m3. Apple needs to put the a19 in the iPad hopefully that helps . And they need to market the newer devices as gaming machines. Metal 4 updates should create 30-40% increases in performance in current games if implemented at minimum.
 
They built those features into metal 4 api they just can’t get developers to rewrite there entire games to use those features. Or developers don’t want to exclude all devices older than the 17pro/ m3. Apple needs to put the a19 in the iPad hopefully that helps . And they need to market the newer devices as gaming machines. Metal 4 updates should create 30-40% increases in performance in current games if implemented at minimum.

There is nothing in Metal 4 that exposes these hardware details, nor is there anything you have to do as developer to take advantage of dynamic cashing or extra FP16 pipes. If you follow the same best practices Apple has been describing for years (and in fact, the best practices for writing shaders on any generic GPU), you are all set.

Metal 4 is about lowering the driver overhead and API friction. The main purpose of Metal 4 is allow for easy porting from DX12.
 
  • Like
Reactions: Mac_fan75
There is nothing in Metal 4 that exposes these hardware details, nor is there anything you have to do as developer to take advantage of dynamic cashing or extra FP16 pipes. If you follow the same best practices Apple has been describing for years (and in fact, the best practices for writing shaders on any generic GPU), you are all set.

Metal 4 is about lowering the driver overhead and API friction. The main purpose of Metal 4 is allow for easy porting from DX12.


Metal 4 is about changes to the rendering pipeline and dx12 features
 
There is nothing in Metal 4 that exposes these hardware details, nor is there anything you have to do as developer to take advantage of dynamic cashing or extra FP16 pipes. If you follow the same best practices Apple has been describing for years (and in fact, the best practices for writing shaders on any generic GPU), you are all set.

Metal 4 is about lowering the driver overhead and API friction. The main purpose of Metal 4 is allow for easy porting from DX12.


I didn't say anything that you claim I'm saying.
 
I didn't say anything that you claim I'm saying.

You didn't? Maybe I misunderstood what "those features" refer to, who knows.

1767935393440.png
 
Not a chance. Stacking multiple GPU's has shown to cause a loss in efficiency. It's why it is generally recommended to just buy 1 powerful GPU rather than multiple GPU's.

Even if the 4 x M5 Max would get close a RTX 5090 in benchmarks, in real world applications the RTX 5090 will still win most likely.
 
Not a chance. Stacking multiple GPU's has shown to cause a loss in efficiency. It's why it is generally recommended to just buy 1 powerful GPU rather than multiple GPU's.

Even if the 4 x M5 Max would get close a RTX 5090 in benchmarks, in real world applications the RTX 5090 will still win most likely.

UltraFusion is not GPU stacking. Common GPU stacking techniques use the GPUs as two separate devices and communicate between them using an external interface. UltraFusion links the on-chip networks directly, combining the SoCs into a single one. The resulting system is, for all intends and purposes, behaves just like an equivalent monolithic chip (except it would be impossible to manufacture one with current technology).
 
UltraFusion is not GPU stacking. Common GPU stacking techniques use the GPUs as two separate devices and communicate between them using an external interface. UltraFusion links the on-chip networks directly, combining the SoCs into a single one. The resulting system is, for all intends and purposes, behaves just like an equivalent monolithic chip (except it would be impossible to manufacture one with current technology).
Basically the same thing Nvidia does with GB100.
 
  • Like
Reactions: crazy dave
UltraFusion is not GPU stacking. Common GPU stacking techniques use the GPUs as two separate devices and communicate between them using an external interface. UltraFusion links the on-chip networks directly, combining the SoCs into a single one. The resulting system is, for all intends and purposes, behaves just like an equivalent monolithic chip (except it would be impossible to manufacture one with current technology).
This conversation nerd sniped me into trying to figure out if I could still see a performance hit for the interconnect on the M3 Ultra ... so far when increasing GPU size there is almost no extra performance hit going from the Max to the Ultra in various tests relative to what is expected from comparing Nvidia monolithic dies making similar jumps in size, very impressive. Will publish when I get a few more data points.
Basically the same thing Nvidia does with GB100.

Yep, or Intel with the newer Xeons.
Or Intel with Ponte Vecchio (called Data Center Max now) or the AMD Instincts. For whatever faults any of the B200, M3 Ultra, Data Center Max, or Instinct may have as platforms, the die-to-die interconnects are generally not seen as among them.

There is nothing in Metal 4 that exposes these hardware details, nor is there anything you have to do as developer to take advantage of dynamic cashing or extra FP16 pipes. If you follow the same best practices Apple has been describing for years (and in fact, the best practices for writing shaders on any generic GPU), you are all set.

Metal 4 is about lowering the driver overhead and API friction. The main purpose of Metal 4 is allow for easy porting from DX12.

I suppose for dynamic caching the one thing you would want to rewrite once M3/A17Pro GPUs become the baseline (though you don't have to) is being able to get rid of shader compilation. But no longer having to worry about shader compilation is more of a very nice programming convenience feature rather than a performance optimization and doesn't have anything to do with Metal 4 in particular.
 
Last edited:
  • Like
Reactions: OptimusGrime
UltraFusion is not GPU stacking. Common GPU stacking techniques use the GPUs as two separate devices and communicate between them using an external interface. UltraFusion links the on-chip networks directly, combining the SoCs into a single one. The resulting system is, for all intends and purposes, behaves just like an equivalent monolithic chip (except it would be impossible to manufacture one with current technology).
Basically the same thing Nvidia does with GB100.
I could be wrong, but I was under the impression that Nvidia's "NV-HBI" (Nvidia High-Bandwidth Interface) is basically the same thing as Apple's UltraFusion, a "die-to-die interconnect" that allows the two Blackwell dies to function as one. We know that UltraFusion uses TSMC's InFO-L (L = LSI "local silicon interconnect"), and we also know that TSMC's CoWoS-L incorporates InFO-L. The difference is that Nvidia then takes that LSI package and uses CoWoS-L to combine it with the Grace CPU and/or other Blackwells, and so on.

If there ever was an M1/2 Extreme project that made it beyond the concept/design stage, it was that -- combining two Ultras via CoWoS-L. This slide is from 2022:

TSMC-3DFabric-2022.png
 
If there ever was an M1/2 Extreme project that made it beyond the concept/design stage, it was that -- combining two Ultras via CoWoS-L. This slide is from 2022:

Combining two Ultra's probably wouldn't work directly — the interconnect is only present on one side of the die, and if you join them too far apart you'd start running into issues with data movement. What Apple patents describe is a dedicated I/O die that sits at the center of the system and connects to four Max-type dies. The I/O die would take care of the routing, ensuring that each data packet can always travel between two dies directly.
 
  • Like
Reactions: tenthousandthings
For this test of Apple's interconnect as of the M3 Ultra, I primarily used 3D Mark Steel Nomad with support from Solar Bay Extreme for a ray tracing benchmark*.

Primary pairs of test GPUs:
RTX GPUSteel NomadBandwidthExpected Ratio from TFLOPsApple GPUSteel NomadBandwidthExpected Ratio from TFLOPs
5070 Ti60678962.29M3 Ultra (80)5474819.32
50602930448-M3 Max (40)2980409.6-
507047066722.12M3 Ultra (60)4601614.4**
819.3
2
5050 OC2316320-M3 Max (30)2306307.2-

I was able to match GPUs and ratios pretty well. Basically we're going to compare the ratio of expected performance based on TFLOPs alone between pairs 5070 Ti & 5060 vs M3 Ultra (80) & M3 Max (40) + 5070 & 5050 OC vs M3 Ultra (60) & M3 Max (30) and the actual performance of the GPU. As GPUs increase in size generally we see a performance degradation away from 1. This is primarily because the benchmarks are designed to run a wide range of GPU sizes. So if it can fit and run in a reasonable time on small GPUs, then they will also have more difficulty taking advantage of the resources of larger GPUs. We see this across benchmarks across many generations. Other factors can be that the GPU drivers/firmware themselves can have more difficulty controlling larger GPUs - we've seen that with Intel and Qualcomm's difficulties scaling their GPUs for the first time and even Apple's M1 Ultra didn't ramp up its clock speed very fast leading to extremely poor GB 5 GPU benchmarks since those were so short. Or of course if those GPUs use a die-to-die interconnect to achieve its size ... something we will be testing here.
GPU RatioSteel Nomad Normalized*** O/E RatioSolar Bay Extreme Normalized O/E Ratio
5070 / 5050 OC0.920.96
M3 Ultra (60) / M3 Max (30)0.990.93
5070 Ti / 50600.830.84
M3 Ultra (80) / M3 Max (40)0.840.80


For these GPUs the scaling remains near perfect up to the performance size of the 5070 and M3 Ultra (60), after both drop about 10% performance relative to expected based on TFLOPS. We can thus see no effect of the interconnect on the M3 Ultra's performance. The 60-core effectively scales perfectly and the 80 core's scaling loss is in line with the 5070 Ti's.

So why do we think the interconnect matters at all? Well ... it did, for the M1 Ultra.


Apple GPU​
Steel Nomad​
Bandwidth​
Expected Ratio from TFLOPs​
M1 Ultra (64)​
3134​
819.3​
2​
M1 Max (32)​
1730​
409.6​
-​
M1 Ultra (48)​
2522​
819.3​
2​
M1 Max (24)​
1376​
409.6​
-​

Here we can see the M1 Ultra is effectively no more powerful in raster performance than the M3 Max and should therefore have no scaling issues. But it does:
GPU RatioSteel Nomad Normalized O/E RatioSolar Bay Extreme Normalized O/E Ratio
M1 Ultra (48) / M1 Max (24)0.8320.71
M1 Ultra (64) / M1 Max (32)0.8110.72

Again, based on GPU size/performance, both of these pairs should be much closer to 1. But instead we see a 20-30% performance degradation moving from the Max to the Ultra. In contrast the M3 has perfect scaling from the base M3 to the 60-core Ultra (base/Pro M3 not shown).

I did not test the M2 Ultra, but either it or the M3 Ultra managed to fixed the performance scaling issue across the interconnect. As far as I know, the physical hardware of the interconnect hasn't changed at all over the generations, but Apple must've improved their ability to handle data and compute locality either in drivers/software or other hardware features beyond the interconnect itself.

*A note especially on Windows machines, since these tests are user run there is going to be a lot of variation in the results. Thankfully the 3D Mark website allows you to control for GPU & GPU memory clock, however this doesn't solve all the problems and some configurations can have very few data points, especially in the newer Solar Bay Extreme test and Windows machines (some only a single results or had a second result in the window that was clearly run on a flawed machine or while the computer was otherwise in use). So the amazing concordance between the Nvidia GPUs and the Apple GPUs might be slightly coincidental but other tests I did suggest that overall it is real. Bottom line, there's at least a few percent error.

**Wikipedia has the binned M3 Ultra at 819.3 GB/s as well, but I don't think that's true. It would make more sense if the binned M3 Ultra was 2x the binned M3 Max, but it was difficult to get confirmation one way or the other. EDIT2: Wikipedia is correct. The binned has the same bandwidth as the full. I don't think it makes too much difference (maybe a small one cause if tests are bandwidth limited), but if someone knows, leave a comment. To be fair I think the M1 Ultra had the same bandwidth regardless of binning, but then so did the M1 Max regardless of binning and the M3 was different.

***EDIT: just realized my old ratio of observed/expected for the scaling metric is not great when comparing them and the expected differs significantly - in the above they don't so it's mostly fine, but I have fixed it with a metric that normalizes better: (Observed Ratio - 1) / (Expected Ratio - 1). This accounts for the floor of the original metric being 1/E rather than 0 and the ceiling still being 1. Now the floor is always 0 no matter the Expected Ratio and the ceiling is 1. For instance: if the Observed Ratio is equal to the Expected Ratio, the metric still gives 1 and if the larger GPU is the exact same speed as the smaller one, it had 0 performance scaling, the result is 0. Previously that would have been 1/Expected and so if your expectation was say only 30% improvement in performance in GPU X over Y , X compared to Y could be no less than 1/1.3 = 0.769 scaling, but you want that to be 0 if X == Y. I've changed the numbers in the above table. The primary effect on the table is that the further away from 1 the old scaling factor was, it will now be pushed even further away since the floor is now 0 rather 1/E.
 
Last edited:
So why do we think the interconnect matters at all? Well ... it did, for the M1 Ultra.

If I remember correctly, the less then expected scaling was already a factor with M1 Max. The issue here was not the interconnect — but how the work was divided across the GPU cores. Apple since made some significant improvements to their work scheduling algorithms.
 
If I remember correctly, the less then expected scaling was already a factor with M1 Max. The issue here was not the interconnect — but how the work was divided across the GPU cores. Apple since made some significant improvements to their work scheduling algorithms.
At least with Steel Nomad, the scaling for the M1 Max is much closer to expected*.

M1 Max 32-core: 1730
M1 Pro 16-core: 896

M1 Max 24-core: 1366 (1410 in 16")
M1 Pro 14-core: 810

yielding 93% normalized** scaling expecting 2 as above and 96% normalized scaling expecting 1.71 respectively (and the 16" 24-core Max probably with better thermals or just random noise has better than expected scaling). That said, the 93% should be closer to 2 for perfect scaling (and the relative M3 and M3 Pros ratios are) and you're right it's hard to distinguish between general work scheduling issues as the GPU gets bigger vs the interconnect since the M1 was just smaller and slower overall than later GPU generations. Why I zero-in on the interconnect itself is that the 48-core and 64-core GPUs have the exact same loss. If the work scheduling algorithm by itself was to blame such that it got worse as the GPU got bigger, I would've expected the 64-core to be worse than the 48-core and it isn't. Both have the interconnect, both drop almost the same performance.

Is that concrete, fool proof evidence? No. But absent other data I feel it's the best hypothesis supported by the data I've seen. Of course the work scheduling algorithm still has to play a major role here. After all, the GPU interconnect hasn't changed and the situation has improved dramatically. But I suspect the M1 Ultra's interconnect played a complicating factor making that initial work scheduling algorithm less efficient for the Ultra rather than just its size. I suspect a major improvement was how to do to work scheduling smarter around the interconnect.

*Edit: Spot checking with Solar Bay Extreme seems similar with only minor additional losses of 1% or less consistent with Solar Bay Extreme results from other devices. And nothing compared to the scaling drop to the Ultra in Solar Bay extreme.

**EDIT 2: replaced with normalized scaling as described in post.
 
Last edited:
  • Like
Reactions: M4pro
At least with Steel Nomad, the scaling for the M1 Max is much closer to expected*.

M1 Max 32-core: 1730
M1 Pro 16-core: 896

M1 Max 24-core: 1366 (1410 in 16")
M1 Pro 14-core: 810

yielding 96% of 2 and 98% of of 1.71 respectively (and the 16" 24-core Max probably with better thermals or just random noise has better than expected scaling). That said, the 96% should be closer to 2 for perfect scaling (and the relative M3 and M3 Pros ratios are) and you're right it's hard to distinguish between general work scheduling issues as the GPU gets bigger vs the interconnect since the M1 was just smaller and slower overall than later GPU generations. Why I zero-in on the interconnect itself is that the 48-core and 64-core GPUs have the exact same loss. If the work scheduling algorithm by itself was to blame such that it got worse as the GPU got bigger, I would've expected the 64-core to be worse than the 48-core and it isn't. Both have the interconnect, both drop almost the same performance.

Is that concrete, fool proof evidence? No. But absent other data I feel it's the best hypothesis supported by the data I've seen. Of course the work scheduling algorithm still has to play a major role here. After all, the GPU interconnect hasn't changed and the situation has improved dramatically. But I suspect the M1 Ultra's interconnect played a complicating factor making that initial work scheduling algorithm less efficient for the Ultra rather than just its size. I suspect a major improvement was how to do to work scheduling smarter around the interconnect.

*Edit: Spot checking with Solar Bay Extreme seems similar with only minor additional losses of 1% or less consistent with Solar Bay Extreme results from other devices. And nothing compared to the scaling drop to the Ultra in Solar Bay extreme.

Thanks for this!

I vaguely remember looking at Blender results and noticing that the scaling factor drops off with M1 Pro/Max/Ultra, while remaining constant on M2 and later. Again, this was a while ago so I might be confused.

Would you mind also doing your Steel Nomad analysis for RTX 5090/5080? The 5090 is almost 2x faster nominally, and I am curious whether the scaling is maintained at that extreme performance class level. I looked at Blender, and it appears to flatten off somehow, but still remains fairly good.
 
  • Like
Reactions: crazy dave
Thanks for this!

I vaguely remember looking at Blender results and noticing that the scaling factor drops off with M1 Pro/Max/Ultra, while remaining constant on M2 and later. Again, this was a while ago so I might be confused.

Would you mind also doing your Steel Nomad analysis for RTX 5090/5080? The 5090 is almost 2x faster nominally, and I am curious whether the scaling is maintained at that extreme performance class level. I looked at Blender, and it appears to flatten off somehow, but still remains fairly good.
Already done! 🙂 (just didn't write it up above) Using normalized scaling, the 5090 in Steel Nomad is about 85%/75% compared to the 5070 Ti/5080 - for some reason the 5080 scales better than 5070 Ti in Steel Nomad, not sure why. Sadly without an Extreme we won't get to see how Apple scaling continues along bigger and bigger chips.

Solar Bay Extreme scaling drops significantly though for the 5090 compared to the 5070 ti/ 5080, it's 64%/60%. But again I had a lot less Windows data for Solar Bay. I think the 5090 was one of the ones where I only had a single GPU result at stock (although I think I did futz around with the boundaries and different clock speeds didn't change too much when OC was accounted for).
 
Last edited:
  • Like
Reactions: M4pro
As for the OP's query:

Yes a theoretical M5 Extreme would match (or beat) a stock 5090 in most applications based on scaling the M3 Ultra by the performance improvement of the M5 over the M3 and assuming core counts and GPU size remain consistent. You then multiply by 2 and assume a similar scaling loss of the Extreme relative to the Ultra as the 5090 relative to the 5070 Ti/5080.

A stock RTX 5090 scores about ~13129 in Steel Nomad and ~47383 (very rough, only a single data point) in Solar Bay Extreme. A theoretical M5 Extreme is estimated by the above to score ~14852 and ~49196 respectively.

Now how well does raster performance in Steel Nomad correspond to real games? Actually not bad, although we don't have a lot of games to test and since most of the recent native ones are very recent, I'm using the Apple M5 which in Notebookcheck was mostly tested in 1080p Ultra (a couple were tested at QHD, doesn't change the results much) while Steel Nomad is a 4K test. I'll compare to a (near?) stock 5060 (it was a slim variety) that they used in one of their reviews for consistency with the above though that's not really crucial since this is all ratios.

AC: Shadows​
TW: Pharaoh​
BG3​
CP2077​
Steel Nomad​
RTX 5060​
43​
156.6​
126.5​
112.6​
3162​
Apple M5​
16​
49​
47​
29.3​
1125​
Ratio​
2.875​
3.19​
2.69​
3.84​
2.81​
Game/Nomad Ratio​
0.956​
1.137​
0.957​
1.367​
-​

With the exception of CP2077 where the M5 does not do as well as expected, Steel Nomad is decently predictive of performance across the games this small set of games tested. I know CDPR has promised future Mac-enhancements for CP2077 (Metal 4), we'll see if those happen and what performance gains, if any, occur for Apple Silicon.

Of course there is also Blender GPU where even a theoretical M5 Ultra could get very close to the 5090. Blender is itself a real world program, but being open source has had contributions from Apple, on the GPU side at least*. In tests, this makes Blender better optimized for Apple Silicon than even other 3D renderers never mind most games or gaming benchmarks. Thus, in many ways, despite Blender being a real world program itself, Apple's GPU performance there relative to Nvidia and AMD GPUs remains .. aspirational - what could be if developers began optimizing for Apple's GPUs as much as they do for Nvidia and AMD GPUs. Thus it's great for examining what the hardware could do in theory, but, unless your workflow is Blender of course!, for the most part will not be reflective of what you'll get for anything else.

And lastly there is the matter of VRAM and professional applications. If your working set is hundreds of GBs a 5090, if it runs at all and many times it won't, will slow to crawl while an Mx Ultra will keep happily chugging along. This is obviously less relevant for gaming, but then the Mx Ultra (or even more so a theoretical Mx Extreme) is not really designed primarily as a gaming chip.

*Blender's CPU renderer is interestingly not as optimized as say Maxon's Redshift CPU renderer when tested in CB2024 (and I think 2026), while, as aforementioned, Blender's GPU renderer shows much better performance on Apple Silicon than Redshift when tested by Cinebench. I imagine Apple engineers were more focused on optimizing the GPU rendering pipeline - I'm not sure I heard much about Apple contributing to its CPU code except to actually Intel ray tracing code which is common across lots of 3D renderers. Funnily, CB2023, while technically native, was one Apple's worst performing CPU 3D renderers (no GPU renderer for that benchmark version)) and had a known, but undisclosed performance issue. The engineers at Maxon fixed that in a big way in subsequent revisions.
 
Last edited:
  • Like
Reactions: M4pro and leman
As an aside, Blender-GPU appears to be highly bandwidth limited on Apple Silicon for the M3-M4. For any tier which changes in core count but not bandwidth, the core count can increase by 20-30%, but the performance increase will only be 2-8% (for like 83-84% scaling within the tier - e.g. 1.08/1.3). Double bandwidth along with doubling core counts meanwhile will double performance (minus the scaling issues mentioned above, which are slightly worse on Blender than Steel Nomad/Solar Bay Extreme - e.g. M3 Ultra 60/Max 30 is 94% rather than 99/96% for SN/SBE and Ultra 80/Max 40 is 88% rather than 92/90% for SN/SBE, unfortunately can't really do the same analysis for Nvidia chips since I don't how much on average each GPU tier is overclocked by). <- EDIT2: this is all with original, non-normalized scaling

Junkshop is the main culprit - looking at individual scores and it is the most bandwidth sensitive and the most overall likely one to show scaling problems I feel.

EDIT: just realized my scaling ratio metric isn't great when the expected scaling differs widely. Hmmm ... will have to come up with a better one.

EDIT2: I've fixed the original post with a new scaling ratio metric:

just realized my old ratio of observed/expected for the scaling metric is not great when comparing them and the expected differs significantly - in the above they don't so it's mostly fine, but I have fixed it with a metric that normalizes better: (Observed Ratio - 1) / (Expected Ratio - 1). This accounts for the floor of the original metric being 1/E rather than 0 and the ceiling still being 1. Now the floor is always 0 no matter the Expected Ratio and the ceiling is 1. For instance: if the Observed Ratio is equal to the Expected Ratio, the metric still gives 1 and if the larger GPU is the exact same speed as the smaller one, it had 0 performance scaling, the result is 0. Previously that would have been 1/Expected and so if your expectation was say only 30% improvement in performance in GPU X over Y , X compared to Y could be no less than 1/1.3 = 0.769 scaling, but you want that to be 0 if X == Y. I've changed the numbers in the above table. The primary effect on the table is that the further away from 1 the old scaling factor was, it will now be pushed even further away since the floor is now 0 rather 1/E.
 
Last edited:
  • Like
Reactions: M4pro
Blender's CPU renderer is interestingly not as optimized as say Maxon's Redshift CPU renderer when tested in CB2024 (and I think 2026), while, as aforementioned, Blender's GPU renderer shows much better performance on Apple Silicon than Redshift when tested by Cinebench. I imagine Apple engineers were more focused on optimizing the GPU rendering pipeline - I'm not sure I heard much about Apple contributing to its CPU code except to actually Intel ray tracing code which is common across lots of 3D renderers.
Uh huh. Blender artists commonly build small vignettes - interior scenes with simple geometry and 1-3 light sources. Optimized GPU rendering is a good friend.

Change is coming tho. Pixar’s Renderman XPU (GPU/CPU) renderer is planned for Apple Silicon “in a future release”. There will be a plug-in for Blender. So we wont be dependent on Cycles alone for fast GPU renders.

Renderman XPU has interesting materials and textures. It will inspire greater ambition.

We’ll see more large-scale exteriors, more complex geometry, and higher use of multiple/many light sources - as all are a good match for GPU+CPU hybrid-rendering in XPU.
 
Last edited:
  • Like
Reactions: crazy dave
We don't even have M4 Ultra yet or ever.
What's the point of speculating if there's nothing to go on? In that sense, nVidia may come up with a whole new generation of chips or two until Apple come up with another Ultra.

When Ultra was announced, I had high hopes. And they are great, but always a generation or two behind thingy is kinda irritating .
 
  • Like
Reactions: Matt2012
AFAICT they’ve really only been a gem behind this gen since we didn’t get an M4 Ultra.
Agreed, in that just one generation has been skipped. It’s odd because we can debate which generation was skipped, but regardless it is only one.

I’m still of the belief that Apple has a product in mind with something beyond the Ultra. They are not in the business of designing silicon for unspecified products. They absolutely had something in mind. Probably a Mac Pro variant, but really it doesn’t matter. The 4x Max didn’t give Apple the product they had envisioned. So they didn’t build it.

That said, whatever product the Jade 4C was designed for surely still has a legitimate, compelling case for its existence. We can speculate about what that case might be, but all we really know is that it passed muster as recently as 2021.

Maybe Apple will take another bite at the proverbial apple with M5, using a completely different approach from what they did earlier (Jade 4C), toward the same end product. Maybe this time they will achieve their goal, and they will build it. We can only hope, without quite knowing what we’re hoping for.
 
  • Like
Reactions: thenewperson
I'm hopeful but in reality, doubt it will happen.
For context, we have x2 high end PC's with 5090's which costs around the same as M3 Ultra with upgraded RAM and also had the M4 Max Studio and then an M3 Ultra Studio.

What I've found is I no longer now really pay much attention stats on paper but real world tests with the main software we actually use which are very heavy GPU based.
The Mac Studio when pushed hard do struggle with GPU tasks and lets not forget that the 5090 is now 1 years old already and the M5 Ultra/Extreme still isn't even confirmed.
I have no interest in gaming either.

Even if Apple do bring out a decent M5, we always want to buy the latest, most powerful hardware so we can work faster. Being able to swap out a GPU in the PC is perfect and a super easy and quick upgrade - and in the current market, can be quite lucrative the way Nvidia resale price are remaining incredibly high!
If we kept our M3 Studio Ultra then tried selling it to upgrade to a whole new M5 machine, from past experience with other Studios, it would be a difficult sell and would lose a ton of cash.

There always seems to be a gossip/rumor cycle of a high end, Nvidia beating new Mac coming soon 'maybe sometime next year' but it never really happens. If it does, by the time it actually gets released, the Nvidia GPUs have moved on to there next upgrade cycle and the gossip cycle starts again with Apple always being one or two generations behind Nvidia.
 
  • Like
Reactions: innerproduct
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.