Question Zen 6 Speculation Thread

[Josh128]

Definitely hallucination.

A bit OT, but about Grok, apparently X CEO stepped down today, and there is some speculation it has to do with Groks ( calling itself MechaHitler, lol) recent Hitler contraversy or the upcoming Grok4 release. 🤣 🤣

 

[511]

Anyway back to Zen 6 what are the expectations for ST Improvement I am expecting ~1.2X.

 

[Josh128]

Even better View attachment 126896

Brutal, and hilarious, lol.

 

[Josh128]

Yup, they are lobotomizing Grok to make sure it stays withing the guidelines issued in Tel Aviv.

https://twitter.com/x/status/1942800705871569173

WTF?!! Its like the thing is actually thinking now.

**Sorry, no more OT stuff...

 

[Josh128]

Anyway back to Zen 6 what are the expectations for ST Improvement I am expecting ~1.2X.

Honestly, realistically, ~10% IPC + ~5-8% clocks. Im not expecting more than 6 GHz.

 

[igor_kavinski]

Honestly, realistically, ~10% IPC + ~8% clocks. Im not expecting more than 6 GHz.

Leaves plenty of room for AMD to impress us

 

[Josh128]

Leaves plenty of room for AMD to impress us

And hopefully not much room to disappoint

 

[inquiss]

Keep dreaming not happening for client as for DC we will see it took them 5-6 years to be at 40% in DC and that was with Intel screwing every time until last year which they released a DC product that is genuinely good nor AMD has a volume and are at a Volume constrained TSMC .
They will prioritize wafer for DC.

AMD has never been wafer constrained for DC. Their issues with building volume have been entirely different

 

[igor_kavinski]

And hopefully not much room to disappoint

For once, I pray that other forum members can contain themselves from hyping up Zen 6. Let's have a serene launch this time around.

I would encourage those same members to hype up Nova Lake if they want

 

[Saylick]

Anyway back to Zen 6 what are the expectations for ST Improvement I am expecting ~1.2X.

20% minimum.

 

[511]

AMD has never been wafer constrained for DC. Their issues with building volume have been entirely different

That is?

 

[Doug S]

i've only seem CAMM memory modules hitting those speeds.

AMD helped develop MRDIMM technology, which doubles bandwidth. It doubles server DIMM bandwidth though, so it is starting at 8800, then going to 12800, then 17600. That's most likely slated for Epyc & Threadripper which would benefit both from the higher bandwidth as well as the increased capacity of the optional "tall" MRDIMM form factor.

 

[Io Magnesso]

don't forget TSMC is ramping packing

Still not enough...

 

[MS_AT]

highest Mem Bandwidth available on a server platform

Out of curiosity, do they have also highest usable bandwidth?

AMD's stretch goal should be 10,000 MT/s EXPO profile

Yup, they could do that. Then cut the CCD<->IOD link width in half, just for laughs

1.) 12 core CCX / CCD
2.) MT & ST freq increase due to node shrink (whatever that ends up being)
3.) Fix high idle power draw
4.) Hopefully enhanced memory controller / better 1:1 uclk/memclk speeds / CUDIMM support.

If you are looking forward to single CCD SKU, I will also add to list a 5) wider CCD<->IOD link, otherwise your faster memory will be bottlenecked by the link.

 

[CouncilorIrissa]

If you are looking forward to single CCD SKU, I will also add to list a 5) wider CCD<->IOD link, otherwise your faster memory will be bottlenecked by the link.

Famous last words when it comes to anything client from AMD.

 

[Thunder 57]

2 layers X3D is like 2 X3D CCD.

Can they do it?
YES

Will they do it?
NO

I'll say it again, inter CCD latency is a thing.

that's still below from Intel's platform of 10000+ MT/s and extreme 12K+ MT/s also lets not forget ARL by default support DDR5-8000 i will expect the IMC crown with Intel this gen as well.

You just love to piss on AMD even in an AMD thread. Who cares about memory bandwith when overall performance is what matters? AMD has a dated IOD.

An L3 cache and DDR5-6000 CL24 should help things a bit. The last few halo P4 CPUs with HT could overclock to 4.25 GHz even with 65nm process. That means their double pumped FPUs were already clocking above 8 GHz. With some key inefficiencies removed, I bet engineers today could get some good mileage out of the carcass of P4 architecture.

Please stop with the P4 (expletive). You got it wrong as well. It was the ALU's that were double pumped. The P4 sucked. Stop beating the dead horse. It's already dead!

A bit OT, but about Grok, apparently X CEO stepped down today, and there is some speculation it has to do with Groks ( calling itself MechaHitler, lol) recent Hitler contraversy or the upcoming Grok4 release. 🤣 🤣

View attachment 126895

Somebody must've played Wolfenstein 3D. I was playing "Cards Against Humanity" one time around new years, and my brothers FIL thought I meant "Mega Hitler" not "Mecha Hitler". Good times.

 

[LightningZ71]

I predict that mobile availability will be inversely proportionally related to the degree of performance improvement.

 

[Makaveli]

I'll say it again, inter CCD latency is a thing.

Everyone that makes this request for cache on both CCD's doesn't seem to understand it does nothing to address this.

Unless AMD changes how data flows in Zen 6 this is still a no.

 

[igor_kavinski]

Unless AMD changes how data flows in Zen 6 this is still a no.

It could be helpful in a scenario where the cache needs are so high that evicted data is getting requested over and over again. Instead of evicting it completely, it can go into the other CCD's V-cache and reside there until needed, saving memory access latency. But yes, this is a special scenario where the other CCD isn't very busy and AMD will need to do something in hardware or driver to make this work seamlessly. Obviously won't be of any use when both CCDs are getting hammered by data hungry threads.

 

[Joe NYC]

Everyone that makes this request for cache on both CCD's doesn't seem to understand it does nothing to address this.

Unless AMD changes how data flows in Zen 6 this is still a no.

100%

It would take a whole new algorithm for cache coherency. Which is something that is not entirely outside of realm of possibilities, but it is not something to bank on.

One thing that changes from previous generations - accesses between IOD and CCD (and even possibly direct link between 2 CCDs) would be much cheaper from power consumption POV.

So, maybe one barrier reduced. Who knows if it is enough to open the door to a new algorithm.

 

[Makaveli]

It could be helpful in a scenario where the cache needs are so high that evicted data is getting requested over and over again. Instead of evicting it completely, it can go into the other CCD's V-cache and reside there until needed, saving memory access latency. But yes, this is a special scenario where the other CCD isn't very busy and AMD will need to do something in hardware or driver to make this work seamlessly. Obviously won't be of any use when both CCDs are getting hammered by data hungry threads.

Does AMD offer this on the EPYC line don't remember if they do.

But I can see it helping in maybe server and data center workloads just not helpful in general desktop and gaming workloads.

 

[Joe NYC]

Does AMD offer this on the EPYC line don't remember if they do.

But I can see it helping in maybe server and data center workloads just not helpful in general desktop and gaming workloads.

No, it is not available in server CPUs either.

 

[igor_kavinski]

I am going to guess that majority of current game developers are now developing on X3D computers, and maybe 2-3 years down the road, that level of performance will be a requirement.

Quoting you from the other thread because, suppose if developers got these new fangled dual V-cache CCD CPUs to tune their engines on, they could conceivably create a "pre-load" thread whose sole job would be to pre-cache stuff into the second V-cache (obviously they would use tricks since they can't directly put data into the cache). Then when the data is needed, the main thread is fed that data from the pre-load thread on the other CCD, thus mitigating the high RAM latency. Of course, this would benefit a minority of their userbase but it would be a very welcome addition to their game engine and really help in smoothing frames out.

 

[Io Magnesso]

100%

It would take a whole new algorithm for cache coherency. Which is something that is not entirely outside of realm of possibilities, but it is not something to bank on.

One thing that changes from previous generations - accesses between IOD and CCD (and even possibly direct link between 2 CCDs) would be much cheaper from power consumption POV.

So, maybe one barrier reduced. Who knows if it is enough to open the door to a new algorithm.

Well, I think it's better to have less communication between CCDs.
It is better to keep that thread in one CCD
No matter how low the power consumption is, there is a reasonable cost.

 

[Josh128]

Speaking of cache coherency, reminded me of my musings about it being possible on Zen 5. Since that was a bust, maybe we can dream about Zen 6 or Zen 7?? Just add 4 cores to the CCDs shown below, put the SRAM die under both of them in a "bridge" configuration, and there you'd have it, the baddest x86 gaming CPU known to mankind.