Discussion Apple Silicon SoC thread

Page 405 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.

Eug

Lifer
Mar 11, 2000
24,048
1,679
126
M1
5 nm
Unified memory architecture - LP-DDR4
16 billion transistors

8-core CPU

4 high-performance cores
192 KB instruction cache
128 KB data cache
Shared 12 MB L2 cache

4 high-efficiency cores
128 KB instruction cache
64 KB data cache
Shared 4 MB L2 cache
(Apple claims the 4 high-effiency cores alone perform like a dual-core Intel MacBook Air)

8-core iGPU (but there is a 7-core variant, likely with one inactive core)
128 execution units
Up to 24576 concurrent threads
2.6 Teraflops
82 Gigatexels/s
41 gigapixels/s

16-core neural engine
Secure Enclave
USB 4

Products:
$999 ($899 edu) 13" MacBook Air (fanless) - 18 hour video playback battery life
$699 Mac mini (with fan)
$1299 ($1199 edu) 13" MacBook Pro (with fan) - 20 hour video playback battery life

Memory options 8 GB and 16 GB. No 32 GB option (unless you go Intel).

It should be noted that the M1 chip in these three Macs is the same (aside from GPU core number). Basically, Apple is taking the same approach which these chips as they do the iPhones and iPads. Just one SKU (excluding the X variants), which is the same across all iDevices (aside from maybe slight clock speed differences occasionally).

EDIT:

Screen-Shot-2021-10-18-at-1.20.47-PM.jpg

M1 Pro 8-core CPU (6+2), 14-core GPU
M1 Pro 10-core CPU (8+2), 14-core GPU
M1 Pro 10-core CPU (8+2), 16-core GPU
M1 Max 10-core CPU (8+2), 24-core GPU
M1 Max 10-core CPU (8+2), 32-core GPU

M1 Pro and M1 Max discussion here:


M1 Ultra discussion here:


M2 discussion here:


Second Generation 5 nm
Unified memory architecture - LPDDR5, up to 24 GB and 100 GB/s
20 billion transistors

8-core CPU

4 high-performance cores
192 KB instruction cache
128 KB data cache
Shared 16 MB L2 cache

4 high-efficiency cores
128 KB instruction cache
64 KB data cache
Shared 4 MB L2 cache

10-core iGPU (but there is an 8-core variant)
3.6 Teraflops

16-core neural engine
Secure Enclave
USB 4

Hardware acceleration for 8K h.264, h.264, ProRes

M3 Family discussion here:


M4 Family discussion here:

 
Last edited:

Jan Olšan

Senior member
Jan 12, 2017
542
1,075
136
It's trickier than that. The reason CP performed so poorly on the PS4 is that the game was designed to stream assets and the relatively slow spinning drives in stock PS4 couldn't do what even a crappy SSD, let alone a good PS5 stock SSD could do. On PS4 the game was IO constrained, not GPU or CPU constrained. CP on a PS4 often didn't even turn the fan on because the game was so frequently just waiting on HD seek. How you shove 168GB of assets across a storage bus, then keep in CPU RAM, then shove over a PCIe bus, and prioritize to stay on the GPU is no small feat as any one of them that goes into the weeds tanks your performance.
I don't think I/O is a major issue that often. Or perhaps better said, this is more often a different core issue: VRAM capacity being insufficient on cheap (8GB, starting to hit 12GB) graphics cards. The topic has been discussed a lot recently.
And ARM Apple platforms are not going to use HDDs or low-sequential speed SSDs.
Apple is presenting the industry with the Cell processor all over again. In theory it might be better but if you have to completely reoptimize your game to get to better, the economics may not exist to allow that to happen.
Hmm, I really don't think it is anything that drastic by far. It's retargetting to a pretty standard GPU acceleration model (whereas Cell... lol). What they have to handle is really to have well performing driver, good compiler (I forgot to specify it, but above I meant shader compiler that is part of GPU drivers, not anything related to usual compilers) and generally a driver that will be able to properly utilise the GPU's units. That's really business as usual for GPU vendors, nothing revolutionary or paradigm-shifty. But at the same time it's hard business as usual only few can do, as mentioned.
Sure, suddenly dealing with a new lineage of GPU architecture and software stack is going to trip you in unexpected places. Different approaches (number of threads, long-lived vs. short lived threads) may be needed to get good occupancy. But it is not going to be THAT different from when Intel became a game graphics target.
 
Last edited: