M3 Chip Generation - Discussion Megathread

[jmho]

So it is another form of efficiency?

Yes....ish.

It's far simpler and uses far less memory, but it requires far more processing power.

But it uses far less processing power and energy if you have dedicated hardware for it. So it's a sort of chicken and egg problem.

Apple has made it clear that the future of computing is spatial though, so more and more software is going to need a way of finding out if object A is "visible" from object B in a way that's simple enough for the average developer to understand.

Raytracing isn't going anywhere, so the sooner we get hardware, the better.

 

[leman]

So it is another form of efficiency?

As @jmho wrote, raytracing is a much more natural way to work with graphics, and it’s also conceptually simpler than rasterization. I don’t know if I would call RT more efficient (it certainly can be, but its still an expensive technique), but now that we finally have hardware capable of fast RT, I have little doubt that it is the future of graphics. In fact, I fully expect hardware rasterization to disappear within the next decade.

 

[Xiao_Xi]

Raytracing often uses less memory than traditional rasterisation.

So, ray tracing saves memory in 3D rendering because it completely replaces rasterization, but requires more in games because it is used on top of rasterization. Is it correct?

Cem Yuksel, a professor at the University of Utah, uploaded videos from his Interactive Computer Graphics course and talks about these things.

Interactive Graphics 03 - Rendering Algorithms.

Interactive Graphics 26 - GPU Ray Tracing

 

[jmho]

So, ray tracing saves memory in 3D rendering because it completely replaces rasterization, but requires more in games because it is used on top of rasterization. Is it correct?

Yes, at least currently when we're so ray-limited.

I'm ironically not a huge fan of hybrid rasterization because it's the worst of both worlds and involves a massive amount of duplication and added complexity.

But what makes raytracing the future is the research that is able to path-trace a very small handful of samples and then use machine-learning to reconstruct / de-noise the entire scene, and yeah I think at that point I totally agree with @leman that people are going to stop doing rasterisation altogether.

 

[Tyler O'Bannon]

I’m guessing die will end up being about the same size or slightly bigger (we’ve seen this with A chips many times).

More cores most likely, at least GPU. Less likely CPU.

Yes to higher clock speed.

Yes to overall slightly reduced power consumption (10%-ish).

 

[scottrichardson]

Yes, at least currently when we're so ray-limited.

I'm ironically not a huge fan of hybrid rasterization because it's the worst of both worlds and involves a massive amount of duplication and added complexity.

But what makes raytracing the future is the research that is able to path-trace a very small handful of samples and then use machine-learning to reconstruct / de-noise the entire scene, and yeah I think at that point I totally agree with @leman that people are going to stop doing rasterisation altogether.

What about stylised rendering techniques that don't need to look hyper-real? Won't that still need rasterisation? Or could that be handled post-ray-tracing using another method?

 

[Tagbert]

Apples primary interest for hardware RT is production renderers, where they have already invested a large amount of resources. Other applications (such as games) will surely come. In fact, Apple has a real chance of being the first vendor to offer good RT performance on baseline devices, making RT applications attractive across the entire ecosystem.

Hardware Ray Tracing might be useful to the Vision Pro as that evolves.

 

[leman]

What about stylised rendering techniques that don't need to look hyper-real? Won't that still need rasterisation? Or could that be handled post-ray-tracing using another method?

Stylized rendering is a question of shading, and can be easily integrated with RT. And if one really needs rasterization, it can be done via compute shaders. Unreal engine’s Nanite uses this approach to rasterize large amounts of small triangles, and it’s apparently faster that hardware rasterization.

 

[Xiao_Xi]

Stylized rendering is a question of shading, and can be easily integrated with RT. And if one really needs rasterization, it can be done via compute shaders. Unreal engine’s Nanite uses this approach to rasterize large amounts of small triangles, and it’s apparently faster that hardware rasterization.

What would the GPU of the future look like: computer shaders and "ray-tracing" shaders only?

 

[Falhófnir]

I'm just really interested to see the timing, it's looking more and more likely to be Spring if not WWDC 2024! And at what point they update the iMac, might it be one of the first macs available with M3?

 

[neinjohn]

Hardware Ray Tracing might be useful to the Vision Pro as that evolves.

Surely as ray tracing on its basic is a push for better/more natural simulation of lightning and it's multitude of interactions. It goes along with Apple putting a lot of resources on video recording and HDR capabilities.

 

[Po Dameron]

I doubt Apple will increase CPU cores. Instead, Apple could include more marketable IP like AV1 de/coder and a ray tracing accelerator. It also makes more sense for Apple to include more GPU cores to address its weakest point (gaming, 3D and machine learning).

Multiple macs can actually be connected via thunderbolt for distributed GPU computation like ML training, with almost linear performance increase. It would be awesome to see ASi GPGPU PCIE cards. It may not be suited for latency sensitive workloads like gaming, but could crunch ML and HPC computations, like a H100 card.

I think this is fairly unlikely, as it would require them to develop and maintain two separate GPU designs simultaneously.

They may need to start doing that? RT makes sense on M3, not so sure it’s a good fit on A series chips.

 

[T'hain Esh Kelch]

They may need to start doing that? RT makes sense on M3, not so sure it’s a good fit on A series chips.

Life like light rendering visuals in games on iPhones? Apple PR is likely drooling over that aspect.

 

[mcnallym]

Apple was/is developing ray Tracing as was reported been dropped from the new iPhones as too much power draw.

Obviously Desktop Machines not that issue.

Depending upon where placed the Ray Tracing as in GPU Cores or Media Engine then could add into the Pro and Max/Ultra in the M1 series then ProRes Encode/Decode was Pro/Max/Ultra only. So possible to use different media engines for the higher end systems withoput changing the CPU/GPU Cores.

 

[TigeRick]

I actually made a comparison table at Anandtech Forum of upcoming M3/M3 Pro vs 8cx Gen4/Pro. You will find how similar the overall design between two...No wonder Apple sued the ex-employees...

So my speculations are below for M3/M3 Pro:-

• Same CPU core counts (with higher IPC + clock improvement from N3B)
• E-cores might get double L2 caches
• L3 cache might get 50% extra
• LPDDR5x with 32GB max memory supported
• 12 cores GPU with RT & 1536 ALU
• Neural engines with more than 20 TOPS

Some features only for M3 Pro:-

• LPDDR5x with 64GB max memory supported
• Max of 24 GPU cores (might deduct 1-2 cores)
• Double the neural engines with more than 40 TOPS

 

[leman]

What would the GPU of the future look like: computer shaders and "ray-tracing" shaders only?

I think the GPU of the future is simply a programmable massively parallel processor. Some fixed function hardware will still remain: texture units, ROPs (on forward renderers), and of course RT hardware.

They may need to start doing that? RT makes sense on M3, not so sure it’s a good fit on A series chips.

Judging by the patents, Apples RT solution will only require minimal die area investment. They already have a bunch of really expensive hardware on A-series (like the extensive SIMD crossbar) that arguably doesn’t make any sense on a phone.

 

[Longplays]

In addition to the iPhone 15 lineup this fall, there will be two Apple Watch Series 9 models and an updated version of the Ultra (the watches are codenamed N207, N208 and N210).

Other products may come later:

- An M3 13-inch MacBook Pro (codenamed J504).

- M3 Pro and M3 Max 14-inch and 16-inch MacBook Pros (codenamed J514 and J516).

- New iMacs (codenamed J433 and J434) with 24-inch screens, like the current models. The company is also conducting early work on an iMac with a screen over 30 inches, I’m told.

- New MacBook Air models (codenamed J613 and J615).

- Revamped iPad Pros with OLED screens (codenamed J717 and J720).

- A new iPad Air (codenamed J507) to replace the current M1-based model.

There are also a few products in early development, including a third-generation version of the AirPods and new home equipment such as smart displays, as well as an Apple TV set-top box with improved specifications.


Source: https://www.bloomberg.com/news/news...-m3-macs-ipad-air-vision-pro-headset-ljbftjwx

 

[deconstruct60]

Didn't the M1 Pro/Max have en/decoders that the M1 didn't have?

By the time the M1 Pro/Max came out a year later( than plain M1 ) the A15 had some PeoRes decoders ( about a month before Pro/Max shipped. They were likely done desisgn wise much earlier ). Should the iPhone get ProRes before the most Mac models do… would that have made sense?


Apple probably scrimped slightly on the plain M1 probably in part to get it out the door quicker with tighter risk management. Pretty good chance the Pro+ ProRes decoders were available for the M1 but didn’t fit the transistor budget or validation timelines. ( i.e. smaller die out quicker to flip 50+% of product line unit volume to inside of 9 months ) . The A15 was also later.

M2 has ProRes . It isn’t a major segmention thing. Plain M1 was just ‘wrong‘ time. If going to stick decoders into 100M units per year silicon , then better to made double sure it isn’t broke . ( hence broad field prototypes in Afterburner cards and fix any mistakes there with FPGA. But long term heading for fixed function silicon )

Same with HW RT . Made sure it is correct and software API well lined up and then do it. Measure twice, cut once.

 

[deconstruct60]

According to Arm documentation, you can't do that.

Documentation – Arm Developer

developer.arm.com

8.2 to 8.5 is probably too long a gap ( since 8.4 was somewhat a catch-up dot increment on mandatory ) . However, pragmatically usually not , but depends upon how loose Arm lets the option stuff slide . That doc page example for dot product remaining optional from 8.0-8.3 but mandatory at 8.4 . You could be doing a stuff that was in the docs at 8.2 but would qual as 8.4 if did the mandatory 8.4 stuff ( I don’t rememer if 8.4 had any new stuff that was immediately mandatory ) . A fair amount of time Arm brings stuff in and then let’s implementers drag their feet for several ‘dot’ iterations before the actually have to do it.


Arm is a bit like USB-IF in that trying to keep a large diverse group all ‘happy’ so have a standard that also has a fair amout of “ well, you do not have to work quite as hard if you dont want to ” features . That the kind of slop I was trying to address where the span is pragmatically more than one generation on the feature list you are looking at On the specs page.

 

[deconstruct60]

- New iMacs (codenamed J433 and J434) with 24-inch screens, like the current models. The company is also conducting early work on an iMac with a screen over 30 inches, I’m ….

…..
Source: https://www.bloomberg.com/news/news...-m3-macs-ipad-air-vision-pro-headset-ljbftjwx

Grubet keeps rolling the large screen iMac rumor our up the hill and it keeps rolling back down later. I would not bet on that . There could be feuding factions inside of Apple , but so far the anti-large screen model folks have won.

’early work’ is highly indicative they somewaht do not want to do it. ( if ‘early’ then even earlier they were not working on it ) it ‘smells‘ like a “where do we attach mature/R&D-paid-for XDR panels to after we come out with XDR 2 ” project. Probably not what majority of folks looking for an affordable large screen iMac will want. ( e.g. it fall inside of the $3K gap between Studo and MacPro ) .

If the 3rd party monitor vendors continue to get better for higher end 30+ monIgor’s quality this iMac may never see light of day . ( even more if Apple does something between Studio Dispalu and XDR price range )

 

[scottrichardson]

Just to throw a curveball out there...

What if the M3 actually mirrors the A16? N4 process (5nm), minimal updates.

So far we have seen the A14 > M1, and the A15 > M2. Why wouldn't A16 > M3?

Is it so far fetched to imagine that 3nm isn't going to happen until M4?

 

[deconstruct60]

Just to throw a curveball out there...

What if the M3 actually mirrors the A16? N4 process (5nm), minimal updates.

probably not . M2 Pro , Max and Ultra all blasted sizably bigger. Lots of cores which in Apple’s design baseline brings lots more cache/SRAM usages ( and area consumption ). .

Plain N4 wasn’t much of a shrink . Probably does offset the bloat and still missing AV1 , HW RT , DisplayPort 2.1 , etc.

Plus, MBP 14/16 running full blast don’t have the battery life the tech specs suggest . N4 isn’t going to help there either.

So far we have seen the A14 > M1, and the A15 > M2. Why wouldn't A16 > M3?

A15 —- 2021 , M2 —- 2022.

no good reason for Apple to make the M series a year late . The are out of sync. It would make more sense to sync them than to drift 12 , then 18;, then 24 months behind. At some point the gap build up becomes so large that just skip.

Folks still are trying to push the M-series into yeaty updates. that really doesn’t make a lot of sense given the vast differences in unit volumes between A-series and M-series . Never mind that that thr Max/Ultra/bigger are even bigger order of magnitude change .


There is no technical reason that P andE core clusters shared across Aseries and M series always have to appear in the A series first . When the fab process goes HVM and when the demand bubbles are play just as big a role. The fab rollouts and Mac demand bubbles don’t always have to stay static in the calendar year.

Is it so far fetched to imagine that 3nm isn't going to happen until M4?

If Apple waiTs for M4 to get to N3 family they will in deep dodo completion wise. If they wait until every one else is on same fab node they loose substantial competitive advantage.

 

[senttoschool]

Just to throw a curveball out there...

What if the M3 actually mirrors the A16? N4 process (5nm), minimal updates.

So far we have seen the A14 > M1, and the A15 > M2. Why wouldn't A16 > M3?

Is it so far fetched to imagine that 3nm isn't going to happen until M4?

Probably because the A16 is speculated to be a stopgap chip due to the late arrival of 3nm. It's like a souped-up A15, which the M2 is already using.

There's not really a reason to port A16 to 3nm to make the M3. It's expensive to take the same chip and port it over to a completely new node. Why not just use A17, which is already a 3nm design? It seems easier to port A17 from N3B to N3E. Or, Apple could stay on N3B for M3 generation using the A17.

 

[koyoot]

Just to throw a curveball out there...

What if the M3 actually mirrors the A16? N4 process (5nm), minimal updates.

So far we have seen the A14 > M1, and the A15 > M2. Why wouldn't A16 > M3?

Is it so far fetched to imagine that 3nm isn't going to happen until M4?

Then we would already see it in real life, instead of M2 series chips.

 

[deconstruct60]

There's not really a reason to port A16 to 3nm to make the M3. It's expensive to take the same chip and port it over to a completely new node.

It costs substantive money , but the notion that it is extremely expensive is likely overblown. Intel's whole tick=tock strategy that worked extremely well was based on making major changes to architecture on the 'tock' iteration and primarily doing a die shrink on the 'tick' iteration. It is actually more expensive to do BOTH at the same time. Sure Intel snuck in minor arch changes on the 'tick' iterations sometimes. ( on integrated GPU cores where they were way behind, they sometimes did more than minor changes. )

TSMC has lots of new stuff in it. FlexFin didn't exist in previous iterations. The design tools needs to be adjusted to adapt to the substantively new paradigm.

Making something that works go faster is less risky and error prone than makes something new at the same time adjusting to a bleeding edge process. Multiple dimensions in motion at the same time is typically more expensive because errors in one dimension tend to propagate impacts into the other.

Why not just use A17, which is already a 3nm design? It seems easier to port A17 from N3B to N3E. Or, Apple could stay on N3B for M3 generation using the A17.

The notion that 'use the A17' is wrong. The A17 uses subsystems of cluster components. P core clusters, E core clusters, memory controller subsystems ,etc. Collectively those can compose an A17 , but they are independent of the A17.


N3B and N3E have different design rules, but yes it would like a Intel 'tick' iteration .... only going 'backwards' and making the die bigger ; not smaller. It is a port and rumors suggest that Apple is doing to do that 'inside' the A17 lifecycle. A while back Apple did a A-series chip at both Samsung and TSMC and the sky didn't fall in. That would be roughly similar ( same baseline design layout out on two different processes ). But the A-series has different unit volumes and potentially much longer lifecycles ( more products to 'hand me down' into. iPad , AppleTV , etc. If need an A17 in 3 years for a 'new' product then N3E would be your only option. )

Either the M3 series got throughly screwed on roll out time length and Apple took it straight to N3E , or the usage for M3 will be the last gasp of N3B ( In the second case , I suspect Apple will skip it for the iPad Air and any other 'long delay' hand-me-down product. Most M-series SoC disappear after they are replaced. No place else for M1 Pro / Max / Ultra to do other than the principle leading edge Macs they go into. ).

A17 has the unit volume to amortize a midlife redesign cost. The M-series really does not and there are a lot more dies to 'redesign'. Either Apple was too far along into N3B so they don't have an option. Or they blew up the timeline completely and there is a relatively long delay coming, but the M3-N3E would likely ship before A17-refresh-N3E. Apple wouldn't have to wait for the A17-Refresh to ship.