Question Zen 6 Speculation Thread

[Io Magnesso]

I like your enthusiasm guys but you are expecting too much lol, we're already getting :

- Higher clock speed
- Higher memory speed support
- More cores
- More cache

Not even talking about IPC but let's be conservative and say 8-10%, do you really think AMD will feel pressured to add one layer to its L3 stacking technology ?
Regardless we're already getting more L3 even before they add another layer, it will cover some more edges cases but we're soon reaching points of diminishing returns.

It's cool to know that they're able to do that but we shouldn't read too much into it, it's not like Intel can really do anything about it...

Well, it's not always the case that the over-enhancement will be a merit.
I agree
96MB which has increased from the previous 64MB, is enough

 

[Joe NYC]

I like your enthusiasm guys but you are expecting too much lol, we're already getting :

Let's go one by one:

- Higher clock speed

Almost certainly. 5-10+%

- Higher memory speed support

Almost guaranteed. AMD is moving from ancient Zen 4 IO die.

- More cores

That's what the leaks say, and it seems credible.

- More cache

There is already going to 1.5x the cache amount (and V-Cache amount) from maintaining L3 per core amount and going up 1.5x cores.

Not even talking about IPC but let's be conservative and say 8-10%,

Higher memory speed support, lower internal latency from chiplet interconnect, larger L3 (for use of single thread applications) will all contribute to IPC. There will be some (likely small) IPC gain from the core itself.

do you really think AMD will feel pressured to add one layer to its L3 stacking technology ?

Intel still has 75% of client CPU market share. I don't think AMD should leave any stone unturned until it is at least 50% : 50%

This could be one of those stones...

 

[HurleyBird]

They developed the ability to stack >1-Hi, but it was never brought to market. I don't even think there's an engineering sample floating in the wild with 2-Hi stack.

It's been referenced in at least one server BIOS.

 

[LightningZ71]

I speculate that there would be an additional latency hit for each additional layer, this reducing it's suitability for purpose.

 

[adroc_thurston]

This could be one of those stones...

no it isn't.
Please surrender.

I speculate that there would be an additional latency hit for each additional layer, this reducing it's suitability for purpose.

4 cycles per layer is whatever since you're piling up the capacity.

lower internal latency from chiplet interconnect

That's very Not True.
You are getting more bytes at less watts, though.
But that's universal across the entire Z6 stack.

 

[OneEng2]

BTW, it is possible that very little FP IPC uplift comes from the core itself and most of it comes from better memory bandwidth and latency.

I think this is very likely true. I also heard a rumor that there has been a small FP errata in Zen 5 that is fixed in Zen 6 .... but I doubt it will amount to a hill of beans. I suspect the bandwidth is a much bigger deal as you assert.

Let's go one by one:



Almost certainly. 5-10+%



Almost guaranteed. AMD is moving from ancient Zen 4 IO die.



That's what the leaks say, and it seems credible.



There is already going to 1.5x the cache amount (and V-Cache amount) from maintaining L3 per core amount and going up 1.5x cores.



Higher memory speed support, lower internal latency from chiplet interconnect, larger L3 (for use of single thread applications) will all contribute to IPC. There will be some (likely small) IPC gain from the core itself.



Intel still has 75% of client CPU market share. I don't think AMD should leave any stone unturned until it is at least 50% : 50%

This could be one of those stones...

I think you are on track with your thinking here.

Most of the uplift will be lower latency and more bandwidth. I think there will be some improvements to the core, but likely most of those will be centered around ..... well .... lower latency and more bandwidth .

AMD has managed a chiplet design that minimizes the latency penalty of going off chip, but also maximizes the interconnect design to make that latency as low as it can reasonably be.

In contrast, Intel is still learning these hard lessons.

 

[Saylick]

It's been referenced in at least one server BIOS.

That’s practically the only hard evidence we have that AMD got it working in-house but that’s as far as it got.

 

[adroc_thurston]

Most of the uplift will be lower latency and more bandwidth.

You're not getting lower latency.
Lower power? yeah.

I think there will be some improvements to the core

That's the only thing you're really getting.

 

[Kaffeekenan]

You're not getting lower latency.
Lower power? yeah.

That's the only thing you're really getting.

So you think Zen6 will not have lower latency? That HAS to be wrong...

 

[adroc_thurston]

So you think Zen6 will not have lower latency?

Why the hell would it.

 

[Darkmont]

Lower latency might come in the form of a tighter physical integration, but that saves like, 1-3 nanoseconds at most. Any lower latencies Olympic Ridge might see would probably be down to the analog and SRAM people, along with node. I.E. a cycle or 2 saved on the L1, L2, L3, caches if you're lucky.

Historically die to die links in the realm of mobile to DT have been about lowering power and relatively cheap cost, at the compromise of whatever latency is deemed acceptable. This is different to maybe flagship EPYC or XEON platforms and GPGPU where you have money and power to burn and whoever's buying gives less of a shit what picojoules-per-bit your fabric delivers.

Look at the fabrics that Intel developed for Atom SOCs and sorta resurrected from the grave for Meteor Lake, Lunar Lake, Arrow Lake, etc. Or AMD's presentations in Client and Data Center every time GMI is updated. It's about being cheap, high (enough™) bandwidth, and power efficient. The solution to the latency question has historically been "Lol, that's up for the uArch and SRAM teams to figure out".

There's no free lunches in semiconductor design anymore. Data movement is routinely the most energy and cost expensive part of your design because bye bye DRAM bandwidth scaling vs. core count, bye bye SRAM and DRAM scaling, and bye bye PHY scaling. If you need throughput it's either moar clocks, moar width, or both. None of which help in keeping cost or efficiency down. Just look at Dragon and Fire Range idle about that. That's not to say a lower latency GMI successor for Zen 6 CAN'T happen, but it's probably not uber high on the list vs. pJ/bit

 

[Kepler_L2]

What evidence do we have that they ever double stacked for EPYC? Someone mentioned this earlier in the thread as if it was common knowledge.

Milan-X BIOS had options up to 8-Hi

 

[adroc_thurston]

That's not to say a lower latency GMI successor for Zen 6 CAN'T happen, but it's probably not uber high on the list vs. pJ/bit

GMI isn't a real latency adder either way, and no, AMD is not re-architecting their fabric to please latencucks.

 

[Darkmont]

GMI isn't a real latency adder either way, and no, AMD is not re-architecting their fabric to please latencucks.

Have you considered going full HairChasers and aiming for nanoseconds?

 

[adroc_thurston]

Have you considered going full HairChasers and aiming for nanoseconds?

More like aiming at WHEA per nanosecond.

 

[Darkmont]

More like aiming at WHEA per nanosecond.

COD Black Ops 7 FPS normalized to WHEA/ns:

 

[Cheesecake16]

GMI isn't a real latency adder either way, and no, AMD is not re-architecting their fabric to please latencucks.

I would both laugh real hard and be in awe if they managed to pull a K10 with Zen 6's L1d and made the complex addressing penalty 0 cycles again...

 

[Joe NYC]

That's very Not True.
You are getting more bytes at less watts, though.
But that's universal across the entire Z6 stack.

SerDes has no latency overhead? It seems like there would have to be some latency to Serialize and DeSerialize data.

 

[CouncilorIrissa]

GMI isn't a real latency adder either way, and no, AMD is not re-architecting their fabric to please latencucks.

b-b-but what about muh amdip

 

[Joe NYC]

That’s practically the only hard evidence we have that AMD got it working in-house but that’s as far as it got.

Exactly. No evidence that the chips were ever made, or undergone any verification.

It seems that this was there, as a possible side-quest, which AMD never embarked on this side quest for real.

Maybe now, when AMD CPU division is cruising on its main quest, maybe Lisa will OK this side quest...

 

[adroc_thurston]

COD Black Ops 7 FPS normalized to WHEA/ns:

god bless him.

I would both laugh real hard and be in awe if they managed to pull a K10 with Zen 6's L1d and made the complex addressing penalty 0 cycles again...

Would be cool but this is something they'd probably reserve for proper tocks.

SerDes has no latency overhead?

GMI? Tiny.

It seems like there would have to be some latency to Serialize and DeSerialize data

Yeah but that's cheap.
Expensive stuff in serdes applications like Ethernet is FEC and friends.

Maybe now, when AMD CPU division is cruising on its main quest, maybe Lisa will OK this side quest...

lmaoooooooooooooooooooo

 

[Cheesecake16]

SerDes has no latency overhead? It seems like there would have to be some latency to Serialize and DeSerialize data.

As of Zen 2, which is the latest architecture we have numbers for directly from AMD, the round trip cycle count from CCD to IOD and back to the CCD is 13 cycles which for Zen 2 was below 9 nanoseconds with the FCLK at 1467MHz as found on Rome... I don't know if GMI3 has added cycles to the round trip path, but if it is the same 13 cycles then at 2000MHz which is what Zen 5 runs its GMI links at, then it's ~6.5ns for the round trip... and 6.5ns round trip is frankly quite low and you shouldn't expect much lower frankly...

 

[Joe NYC]

GMI? Tiny.

Each nanosecond is 6.5 clocks at 6.5 GHz CPU. So shaving off a few nanoseconds can add up.

 

[adroc_thurston]

Each nanosecond is 6.5 clocks at 6.5 GHz CPU.

Who cares.

So shaving off a few nanoseconds can add up.

People at AMD not gonna subject themselves to copious amounts of *redacted torture just to shave a few fabric ns for a bunch of forum dwellers. they have better stuff to do.
case. closed.

 

[Joe NYC]

As of Zen 2, which is the latest architecture we have numbers for directly from AMD, the round trip cycle count from CCD to IOD and back to the CCD is 13 cycles which for Zen 2 was below 9 nanoseconds with the FCLK at 1467MHz as found on Rome... I don't know if GMI3 has added cycles to the round trip path, but if it is the same 13 cycles then at 2000MHz which is what Zen 5 runs its GMI links at, then it's ~6.5ns for the round trip... and 6.5ns round trip is frankly quite low and you shouldn't expect much lower frankly...

Thanks for the figures.

BTW, I asked Grok and Grok answer (could be hallucination) for ballpark estimate was 10-15 ns for GMI link and 2-3 ns for Strix Halo type parallel link.