Will ARM Macs have ARM GPUs?

[johngwheeler]

Is there a particular reason why Apple SoC cannot operate at 250W if Intel/AMD/NVIDIA GPU can? I think not. Apple SoC for Mac will not be built with all day battery life as a key feature.

As Rastafabi pointed out in another thread, GPU tasks on Apple SoC are split into dedicated processors for machine learning and encoding video and maybe soon raytracing. For Mac Pro, there is already a dedicated video processing card in the form of the After burner. We may see more of these dedicated cards for instance for ML leaving Apple SoC to handle "just" the true graphics. Everything is about efficacy and splitting the general purpose GPU/CPU into dedicated silicon for separate functions seem to be a viable way to be explored.

In that contexts, it is interesting how the Mac pro is constructed. The introduction of the MPX modules (which do very little for traditional GPU packaging) looks like an excellent package for a high power dedicated Apple Silicon ML modules or other functions.

There are ARM CPUs for servers that have c. 225W TDP, so it's not unreasonable to think that Apple could develop a SoC with 250W TDP or even greater, provided the cooling is there - which it is in a Mac Pro.

It will be very interesting to see if APUs or SoC designs can match the huge PCIe GPU cards found in workstations & gaming desktops.

In the case of the Mac Pro, it wouldn't surprise me to see an exception to the "single memory architecture" for GPU & CPU, and see the ARM SoC use PCIe 4 to interface to a discrete GPU - designed by Apple or AMD.

 

[leman]

Is there a particular reason why Apple SoC cannot operate at 250W if Intel/AMD/NVIDIA GPU can? I think not. Apple SoC for Mac will not be built with all day battery life as a key feature.

I was under impression that one starts running into all kinds of production issues as the chips getting bigger and bigger... is there a precedent for SoC systems running at high power? But I might have spoken too hastily, from the logical standpoint you are right. There should not be a principal difference between a CPU/GPU running at 200W or a SoC... but then again, I have no idea about all this stuff.

Maybe someone with a semiconductor engineering background can chime in?

 

[iPadified]

I was under impression that one starts running into all kinds of production issues as the chips getting bigger and bigger... is there a precedent for SoC systems running at high power? But I might have spoken too hastily, from the logical standpoint you are right. There should not be a principal difference between a CPU/GPU running at 200W or a SoC... but then again, I have no idea about all this stuff.

Maybe someone with a semiconductor engineering background can chime in?

I do not know either but SoCs are typically designed for low power small devices so perhaps no one has tried making a high power SoC? Sometimes, someone need to be first.

The yield of good chip should be poorer with larger chips. A12Z is 135 mm2 while the 28 core xeon i 698 mm2. The larger GPUs are 500 mm2 so it is not far fetched that Apple could triple the die size. If all that additional area was used for graphics cores we may be in for a nice surprise performance wise.

 

[06tb06]

I believe Apple with continue to offer discrete AMD graphics options on select Mac models.

I remember when Intel announced they were developing their own discrete GPU a few years ago. The performance of those early chips couldn't even match AMD's TeraScale architecture (at a time when AMD was focusing on 2nd and 3rd generation GCN; the successor of TeraScale).

It's going to be hard for Apple to top something like the Mac Pro with a GPU of their own.

 

[miscend]

Further more, the feature set of these GPUs will be combining both the MetalFamilyMac v2 as well as MetalFamilyApple v3, and for code written against the Catalina SDK or earlier there will be some performance limiting options enabled by default to force the GPU to behave more like an immediate renderer like AMD and Intel GPUs, even though it is actually a tile based deferred renderer. While it reduces performance, if code assumes an immediate renderer incorrectly it can cause graphics glitching.

This will be the first time in maybe 20 years that we see a desktop class tile based renderer GPU. Brings back memories of PowerVR.

 

[Birkan]

This will be the first time in maybe 20 years that we see a desktop class tile based renderer GPU. Brings back memories of PowerVR.

Actually, Nvidia implemented (another article) "tile-based immediate-mode rasterizers" as the article calls it since Maxwell generation which is released on 2014. That was one of the reasons of greater efficiency in Maxwell generation. However, it seems like this is a hybrid approach to use TBR internally to bring efficiency gains without breaking compatibility with previous intermediate mode renderers. Hopefully some people like Anandtech will do detailed analysis of the Apple Silicon GPU in the new consumer based Macs later this year so we can see the performance characteristics of the GPU.

PS: Just to give complete context, AMD also introduced similar Draw Stream Binning Rasterizer in their Vega generation of GPUs.

 

[leman]

Actually, Nvidia implemented (another article) "tile-based immediate-mode rasterizers" as the article calls it since Maxwell generation which is released on 2014. That was one of the reasons of greater efficiency in Maxwell generation. However, it seems like this is a hybrid approach to use TBR internally to bring efficiency gains without breaking compatibility with previous intermediate mode renderers. Hopefully some people like Anandtech will do detailed analysis of the Apple Silicon GPU in the new consumer based Macs later this year so we can see the performance characteristics of the GPU.

PS: Just to give complete context, AMD also introduced similar Draw Stream Binning Rasterizer in their Vega generation of GPUs.

I was always very curious to how exactly this works. I understand TBDR, the concept is pretty simple, but how does Nvidia do its tiling? David Kanter's video does not make things too clear to me either, because the rasterization pattern is still weird. With "proper" tile based rendering, one tile will be completely done before you proceed to the next tile, or at least, some times might be rendered in parallel. But what we see in the tests is some sort of progressive tile in a tile thing that gets filled out in a checkerboard pattern. It looks like some sort of binning is used in combination with a weird framebuffer layout..

Also, I am not quite sure why TBDR is incompatible with immediate mode renderers. Forward renders use a plethora of optimization such as early depth rejection, so they don't guarantee that fragment shaders will be executed in any particular order anyway. And if you are using alpha blending etc., there is a guaranteed order, but TBDR can deal with this simply by disabling the deferred rendering part.

And finally, I really don't understand what are the "benefits of immediate-mode rendering" (in AMD's words). No matter how I looked at it, TBDR is just superior in every way from efficiency standpoint. The only advantage of the forward rendering is that it's much simpler to implement.

 

[Brien]

This tweet makes it sounds like no dGPUs at all under Apple Silicon:

https://twitter.com/i/web/status/1280207485278789633

 

[leman]

This tweet makes it sounds like no dGPUs at all under Apple Silicon:

That’s what we’ve been talking about for weeks Apple made that rather clear during the WWDC.

 

[endlessike]

That’s what we’ve been talking about for weeks Apple made that rather clear during the WWDC.

As this thread illustrates, I think its far from clear that there will be no discrete GPUs in any Apple silicon macs.

 

[Brien]

Conspiracy theory time - assume Apple does force iGPUs only.

Paired with the new UI in 11, the API changes to make universal apps easier...

Kind of makes you wonder if the actual goal of all this is to force developers to transition to universal apps. Macs get a bunch apps that were previously iOS/iPadOS only (from indies and PC devs), iDevices get Pro apps (Adobe, etc. who have to rewrite everything to use Metal and run on ARM).

If that's the case I could see Apple lead by example and port Final Cut and Logic to the iPad.

 

[macsplusmacs]

Apple silicon Mac documentation suggests third-party GPU support in danger | AppleInsider

Some Apple support documentation seems to suggest that Mac shift to Apple silicon will drop support for non-Apple GPUs.

appleinsider.com

 

[iPadified]

As this thread illustrates, I think its far from clear that there will be no discrete GPUs in any Apple silicon macs.

I think it is important to realise that GPU do graphics as well as compute. I would be surprised if not dGPU in e.g Mac Pro for compute will be supported. What else are you using 2XVega duo for. It is compute cards and not gaming cards? For graphics only, it is highly likely that Apples GPU will be more than enough. This means that all laptops and some iMacs will be without dGPU.

 

[Boil]

Mac Pro products will probably use Threadripper-sized APUs

32 P cores / 4 E cores / 48 GPU cores / 32GB HBM2e UMA
48 P cores / 6 E cores / 64 GPU cores / 48GB HBM2e UMA
64 P cores / 8 E cores / 80 GPU cores / 64GB HBM2e UMA

Possible GPGPU (compute / render) card(s) - 160 GPU cores (the "GPU package" would be very similar to the APUs outlined above, just without the high P core counts, a 160 GPU core card would be dual cut-down 80 GPU core packages)

Single package size cards would MXM (or something Apple-esque), for the iMac Pro & Mac Pro Cube (it's back!)

Dual package size cards will be MPX, for the Big Chungus Mac Pro chassis.

 

[leman]

As this thread illustrates, I think its far from clear that there will be no discrete GPUs in any Apple silicon macs.

The only official information we have at this time is that Apple Silicon is using Apple GPUs. Apple has also been repeatedly stressing that Apple Silicon Macs share memory between the GPU and CPU. I agree that this is probably not the end of the story, as the higher-end desktop solutions still remain an enigma, but I have little doubt that the entire Mac laptop line will move to Apple SoC, CPU and GPU.

I also do not think that the common distinction of iGPU and dGPU applies here. Paired with fast memory interface (e.g. LPDDR5) with a bandwidth around 100gbps and having enough cache, the already bandwidth efficient Apple GPUs won’t be at a disadvantage compared to any GDDR5 equipped GPU. You need to look at the technical characteristics and not just where the GOU resides.
[automerge]1594140214[/automerge]

Conspiracy theory time - assume Apple does force iGPUs only.

Paired with the new UI in 11, the API changes to make universal apps easier...

This is not a conspiracy theory, this is the official strategy. All Apple devices will have the same set of basic capabilities, the difference will be performance, user interface and flexibility. Which in the end bakes things easier for the developers and the users. It’s a good thing, not a bad thing.
[automerge]1594140350[/automerge]

Possible GPGPU (compute / render) card(s) - 160 GPU cores (the "GPU package" would be very similar to the APUs outlined above, just without the high P core counts, a 160 GPU core card would be dual cut-down 80 GPU core packages)

Sorry, now you are going too far. 160 GPU cores at 50% of current performance will be over twice as fast than the fastest GPU shipping today. Let’s stay realistic here. A 32 core Apple GPU would already be high-end.

 

[Birkan]

I was always very curious to how exactly this works. I understand TBDR, the concept is pretty simple, but how does Nvidia do its tiling? David Kanter's video does not make things too clear to me either, because the rasterization pattern is still weird. With "proper" tile based rendering, one tile will be completely done before you proceed to the next tile, or at least, some times might be rendered in parallel. But what we see in the tests is some sort of progressive tile in a tile thing that gets filled out in a checkerboard pattern. It looks like some sort of binning is used in combination with a weird framebuffer layout..

Also, I am not quite sure why TBDR is incompatible with immediate mode renderers. Forward renders use a plethora of optimization such as early depth rejection, so they don't guarantee that fragment shaders will be executed in any particular order anyway. And if you are using alpha blending etc., there is a guaranteed order, but TBDR can deal with this simply by disabling the deferred rendering part.

And finally, I really don't understand what are the "benefits of immediate-mode rendering" (in AMD's words). No matter how I looked at it, TBDR is just superior in every way from efficiency standpoint. The only advantage of the forward rendering is that it's much simpler to implement.

I think checkerboard pattern was special to Maxwell generation. Nvidia appears to have moved to some sort of row based pattern in Pascal. And who knows what they are using in Turing or in upcoming Ampere GPUs. I guess they probably figured out that sending whole row and doing the whole row was more efficient compared to checkerboarding since depending on the data, the size of the checkerboarding might need to change thus requiring new data. One thing I noticed was that while doing checkerboarding on a GTX 970, it was drawing 1 in 6 pixels and then moving to the next one. GTX 970 had 3 out of 4 SMM per GPC and inside each SMM there were 2 L1 cache shared by Warp Schedulers. Therefore, checkerboarding was dividing the tiles into 6 and rasterising one by one. Pascal seems to have 5 SMM per GPC and inside each SMM there were 2 L1 cache shared by Warp Schedulers again. When they are harvesting lower quality dies to make 970 out of 980, they were disabling SMMs. However, this changed to disabling GPCs for making 1070 out of 1080 dies. I suspect that they changed checkerboarding to row based pattern to have better yields when they are harvesting GPU dies. For your second and third remarks, I honestly do not know.

 

[leman]

I think checkerboard pattern was special to Maxwell generation. Nvidia appears to have moved to some sort of row based pattern in Pascal. And who knows what they are using in Turing or in upcoming Ampere GPUs. I guess they probably figured out that sending whole row and doing the whole row was more efficient compared to checkerboarding since depending on the data, the size of the checkerboarding might need to change thus requiring new data. One thing I noticed was that while doing checkerboarding on a GTX 970, it was drawing 1 in 6 pixels and then moving to the next one. GTX 970 had 3 out of 4 SMM per GPC and inside each SMM there were 2 L1 cache shared by Warp Schedulers. Therefore, checkerboarding was dividing the tiles into 6 and rasterising one by one. Pascal seems to have 5 SMM per GPC and inside each SMM there were 2 L1 cache shared by Warp Schedulers again. When they are harvesting lower quality dies to make 970 out of 980, they were disabling SMMs. However, this changed to disabling GPCs for making 1070 out of 1080 dies. I suspect that they changed checkerboarding to row based pattern to have better yields when they are harvesting GPU dies. For your second and third remarks, I honestly do not know.

Super interesting, thank you! If I have some time, I'll play with a metal shader to study these effects on the Mac side.

 

[Brien]

This is not a conspiracy theory, this is the official strategy. All Apple devices will have the same set of basic capabilities, the difference will be performance, user interface and flexibility. Which in the end bakes things easier for the developers and the users. It’s a good thing, not a bad thing.

Unless third parties bail.

Also - long term roadmap talk here, but, if the end-goal is to reach feature parity with iOS/iPadOS/macOS, and assuming that we see far more powerful iPad Pros and much more pro app support (with pencil, KB/mouse, external device, multi-user support etc.)...

Why would Apple bother keeping the Mac at that point?

 

[Falhófnir]

Unless third parties bail.

Also - long term roadmap talk here, but, if the end-goal is to reach feature parity with iOS/iPadOS/macOS, and assuming that we see far more powerful iPad Pros and much more pro app support (with pencil, KB/mouse, external device, multi-user support etc.)...

Why would Apple bother keeping the Mac at that point?

There isn't going to be exact parity of features or functionality between macOS and iPad OS - they will just share more at their core with functionality particular to their strengths being the differentiator. Craig Federighi has already stated outright their aim with MacOS is to continue to allow enthusiasts to tinker more than they can on iOS/iPad OS - hence why you can disable secure boot.

 

[leman]

Unless third parties bail.

Also - long term roadmap talk here, but, if the end-goal is to reach feature parity with iOS/iPadOS/macOS, and assuming that we see far more powerful iPad Pros and much more pro app support (with pencil, KB/mouse, external device, multi-user support etc.)...

Why would Apple bother keeping the Mac at that point?

Not feature parity, basic capability parity. That is, using the same underlaying APIs and the same underlaying technologies. I have no doubt that iPad Pro will gradually take over some of the traditional use case from the desktop computers, but it is still a limited system compared to a laptop and will remain so for a while (simply because of its form factor).

 

[macsplusmacs]

Apple's Homegrown Chips Could Be the End for AMD Graphics in Macs

Apple’s transition to its own Mac silicon has brought up a slew of questions, and now it seems like the future of the company’s third-party graphics card

gizmodo.com

 

[Moonjumper]

Conspiracy theory time - assume Apple does force iGPUs only.

Paired with the new UI in 11, the API changes to make universal apps easier...

Kind of makes you wonder if the actual goal of all this is to force developers to transition to universal apps. Macs get a bunch apps that were previously iOS/iPadOS only (from indies and PC devs), iDevices get Pro apps (Adobe, etc. who have to rewrite everything to use Metal and run on ARM).

If that's the case I could see Apple lead by example and port Final Cut and Logic to the iPad.

A big differentiator will be RAM. Many desktop applications will not run efficiently on the 6GB RAM of the best current iPad, never mind the full range, and I don’t expect devs will be forced to compromise macOS performance to enable universal apps, nor do I expect massive RAM increases on iPads.

 

[Brien]

Not feature parity, basic capability parity. That is, using the same underlaying APIs and the same underlaying technologies. I have no doubt that iPad Pro will gradually take over some of the traditional use case from the desktop computers, but it is still a limited system compared to a laptop and will remain so for a while (simply because of its form factor).

Could you at least foresee the entry-level being ceded to iPads and the Pros the sole remaining Macs at that point?

 

[throAU]

Hi all, I think I heard at Keynote that GPUs in ARM Macs will ARM too. But I wasn't fully paying attention at that time. I could be very wrong. Do you think ARM Macs won't have AMD GPUs but will have custom, integrated and/or ARM GPUs?

They will use in-house GPUs for the Mac.

Many have missed or overlooked this, but I do not think that Apple will take on the task of writing ARM drivers for high end Radeon based GPUs - and AMD certainly won't. So even if they didn't want to do it, their hand has essentially been forced. This is also why (I feel) they are calling this "Apple Silicon" not an "ARM CPU" or even "Apple CPU" migration this time.

Given GPU driver software is some of the most complex/difficult software to write (and be performant) and given apple are already making/supporting their own GPU designs, and given that being independent of AMD for GPU is just as important as being independent of intel for CPU - they will go it alone.

 

[leman]

Could you at least foresee the entry-level being ceded to iPads and the Pros the sole remaining Macs at that point?

Not really. Entry level Macs are popular with students for example. The iPad can’t replace that completely. I do see it as a good device for basic home computing/note taking/auxiliary designer device.