Question Zen 6 Speculation Thread

[poke01]

But do I want to, I can easily pop in a 9950X3D and my gaming PC becomes a workstation. This is the true benefit of PC, the open ecosystem. Something we should keep ahold off.

Good on AMD for creating Zen cause without it, x86 would HAVE been dead. Cause Intel is doing jack sh*t.

You see going with Apple would be fine if they were open and a repair friendly company. Let’s just say there is more the pc ecosystem than just CPU performance.

 

[adroc_thurston]

Cause Intel is doing jack sh*t

Atoms are fine if underwhelming in places.

 

[mikegg]

Nonsense. What world do you live in?

Silicon Valley. No software engineer here uses a Windows computer. It's 95% Macs and 5% Linux.

 

[mikegg]

Hard disagree (and I use Linux anyway). Windows has WSL2 to run everything Linux at native speeds. Macs don’t run full blown visual studio, nor do they run a bunch of commercial CRMs and other software. None of the games I play are on the Mac. Linux runs more software than the Mac thanks to more ports and also WINE. WINE on Mac is much more limited due to a few reasons.

When I travel for client work, I take my PC. It has full compatibility with all the software I use.

Many of the companies I’ve worked with have transitioned away. Don’t get me wrong , Apple has its niche, but let’s not pretend they are bigger or more relevant than they are.

Regardless, this is a Zen 6 thread, not an Apple one.

Hard disagree. No one in Silicon Valley, where I work, uses a Windows computer for software development. If you agree that the best software comes out of Silicon valley, then you'd agree with me. If not, there's no point in arguing.

WSL2 is much better than native Windows terminal but it's not native. You're going to run into issues. Example, slower file system due to 9P overhead, higher RAM usage, uses a separate virtual network adapter, no native Systemd support, no native GUI app support, compatibiltiy issues with software that use low level Linux kernel features, increased performance requirement because it's literally virtualizing linux.

 

[poke01]

Hard disagree. No one in Silicon Valley, where I work, uses a Windows computer for software development. If you agree that the best software comes out of Silicon valley, then you'd agree with me. If not, there's no point in arguing.

You know what’s funny, this is actually true. AMDs head of GPU software engineering was using an M4 Max Macbook as his main laptop until the Framework laptop Strix Point laptop came out.

So it’s ridiculous anyone here says Macs cannot be used for software development at all.

 

[mikegg]

So it’s ridiculous anyone here says Macs cannot be used for software development at all.

Anyone who says that doesn't know what they're talking about. No one uses a Windows computer for software development at any Silicon Valley companies. If you find one, that engineer is actually just using it for Linux.

The only people in Silicon Valley who use Windows are finance people because of Excel.

 

[jpiniero]

It's cheap since the cost bump is low single digit %% and you get 10-15% more freebie speed.

Yeah right.

they just kept client inna ghetto, but that's not gonna last forever.

That ghetto is the majority of AMD's sales.

 

[DrMrLordX]

Intel has a yearly cadence. AMD will need Zen 6 simply to recover ground lost to Intel delivering new products.

That is a very rosy view of Intel's immediate future.

 

[adroc_thurston]

That ghetto is the majority of AMD's sales.

a) no
b) they're barely breaking into commercial.

 

[jpiniero]

a) no
b) they're barely breaking into commercial.

OEM Retail is even cheaper than Commercial.

Do note that DIY is only a small part of the desktop market.

 

[adroc_thurston]

OEM Retail is even cheaper than Commercial.

no?

Do note that DIY is only a small part of the desktop market.

Well AMD has zero penetration in OEM DT.

 

[jpiniero]

Well AMD has zero penetration in OEM DT.

It's not that bad.

Didn't AMD admit that half of the volume on desktop was AM4 not too long ago?

 

[inquiss]

It's not that bad.

Didn't AMD admit that half of the volume on desktop was AM4 not too long ago?

AM4 does not by itself imply OEM desktop though...

 

[Win2012R2]

Silicon Valley. No software engineer here uses a Windows computer. It's 95% Macs and 5% Linux.

This explains everything about declining quality of Windows "updates"...

 

[Win2012R2]

N2 is the most expensive process node on the planet (outside of some specialized military grade stuff). How is it "cheap"?

Military typically uses very old nodes

 

[Jan Olšan]

Despite considerable changes in Zen 5, the Zen microarchitecture is just getting long in the tooth. Here's how often AMD has started from scratch (first level indicates new designs, second level shows iterations):

• K5 - 1996
• K6 - 1997
• K7 (Athlon) - 1999
• K8 (Athlon 64) - 2003
  • K10 - 2007
• Bulldozer - 2011
  • Piledriver - 2012
  • Steamroller - 2014
  • Excavator - 2015
• Zen - 2017
  • Zen 2 - 2019
  • Zen 3 - 2020
  • Zen 4 - 2022
  • Zen 5 - 2024
  • Zen 6 - 2026

Two things - first K8 was pretty much an iteration of K7, and there was another one between them (Athlon XP gets lumped together with original K7 but core is updated).

Second, I think it is a bit of a reductionist viewpoint and it fails to see a difference in how far the "iterations" go. Is it a tick or a tock? Even Intel's tocks were iterations. Zen 3 and 5 are pretty extensive tocks... (Edit: Actually, Zen 2 / 4 are quite extensive too, certainly closer to the idea of tock than to ticks).

You would probably do better to just treat "development lineage reboots" as an entirely different thing. That is going to be a rare occasion, probably more of an answer to company getting into unforeseen trouble. Having to throw away the uarch lineage and start largely anew is actually likely to be something the engineers want to avoid, because that means you need more time, more resources to succesfully deploy that particular step of the roadmap (and the ones after it too, likely), and you will be fighting various regressions and catching up with all the features of the old lineage.

Something to think about: How many times has Apple done such a reboot, actually, hmmm? Doing that frequently is certainly not part of their success recipe.

 

[basix]

It's cheap since the cost bump is low single digit %% and you get 10-15% more freebie speed.

When it is cheaper, so this could also apply for dGPUs? Or do we have a wafer count limitation here?

 

[soresu]

Here's how often AMD has started from scratch (first level indicates new designs, second level shows iterations):

• K5 - 1996
• K6 - 1997
• K7 (Athlon) - 1999
• K8 (Athlon 64) - 2003
  • K10 - 2007
• Bulldozer - 2011
  • Piledriver - 2012
  • Steamroller - 2014
  • Excavator - 2015
• Zen - 2017
  • Zen 2 - 2019
  • Zen 3 - 2020
  • Zen 4 - 2022
  • Zen 5 - 2024
  • Zen 6 - 2026

Now that I'm more familiar with its history the K8 derived family looks like this fully expanded:

• K8 (Athlon 64) - 2003
  • Barcelona (Phenom/Agena) - 2007
  • Shanghai (Phenom II/Deneb) - 2008
  • Istanbul (Phenom II X6/Thuban)
  • Husky (Llano APU)

Not sure about Husky having significant µArch improvements, but Shanghai and Istanbul definitely did.

 

[StefanR5R]

I hope one thing for Zen 6 platform will come to fruition.
EPYC CXL.mem to come to DT.
Turin can interleave CXL and DDR memory regions already, so ideally GPU CXL device attached to the root can see the memory of the host.

Linux is getting patches for address translation for Zen 5. Hopefully this Zen 6 goes further in this direction

CXL Address Translation Support For AMD Zen 5 Sees Linux Patches - Phoronix

www.phoronix.com

With such a setup we could install 1 TB of DDR on CPU and let the GPU use all of that for some LLMs and other interesting use cases. Can turn your Linux PC to some LLM monster
Will not be the most performant but at least can run something interesting.

Is this something akin to Memory Caching from Apple M4 and M4 architectures?

Do you mean "Dynamic Caching" of the M3/M4 iGPU?
If so, no.
– Apple's Dynamic Caching is about the GPU's own resource management.
– CXL is about data sharing between CPUs and devices. CXL adopts the PCIe physical layer but is running an alternate transaction layer over it, one which in contrast to PCIe's transaction layer notably has a cache coherence protocol baked in. AFAIU: Cache-coherent DMA can be performed over the PCIe transaction layer too, but it is costly and therefore used only for smaller data like commands, status messages, buffer descriptors, and such, whereas all the usual data transfers from and to PCIe devices happen with cache-incoherent DMA. An introductory article to CXL with some slides: servethehome

Now I don't know how LLMs* work to be able to tell whether or not

[host CPU and lots of RAM] <--- CXL ---> [discrete GPU with some VRAM]​

would indeed enable more capable LLMs* than

[host CPU and lots of RAM] <--- PCIe ---> [discrete GPU with some VRAM]​

with the difference between the two that CPU and GPU access the host RAM in cache coherent manner in the CXL case but not in the PCIe case. In either case, the application would have to swap data between RAM and VRAM.
*) or other GPGPU applications

If yes, then the next question would be whether or not CPU vendors and GPU vendors recognize a market potential in CXL-enabled client products.

 

[desrever]

This explains everything about declining quality of Windows "updates"...

Maybe it explains the declining quality of silicon valley.

 

[DisEnchantment]

Do you mean "Dynamic Caching" of the M3/M4 iGPU?
If so, no.
– Apple's Dynamic Caching is about the GPU's own resource management.
– CXL is about data sharing between CPUs and devices. CXL adopts the PCIe physical layer but is running an alternate transaction layer over it, one which in contrast to PCIe's transaction layer notably has a cache coherence protocol baked in. AFAIU: Cache-coherent DMA can be performed over the PCIe transaction layer too, but it is costly and therefore used only for smaller data like commands, status messages, buffer descriptors, and such, whereas all the usual data transfers from and to PCIe devices happen with cache-incoherent DMA. An introductory article to CXL with some slides: servethehome

Now I don't know how LLMs* work to be able to tell whether or not

[host CPU and lots of RAM] <--- CXL ---> [discrete GPU with some VRAM]​

would indeed enable more capable LLMs* than

[host CPU and lots of RAM] <--- PCIe ---> [discrete GPU with some VRAM]​

with the difference between the two that CPU and GPU access the host RAM in cache coherent manner in the CXL case but not in the PCIe case. In either case, the application would have to swap data between RAM and VRAM.
*) or other GPGPU applications

If yes, then the next question would be whether or not CPU vendors and GPU vendors recognize a market potential in CXL-enabled client products.

The concept is much simpler. In CXL.mem, the memory of the CXL device can be mapped into another, so it appears as memory in its address space

For instance a GPU of 16GB VRAM, can map another device memory, e.g. the host CPU memory as its own. Let say it can map host's 1 TB as its own and it will have its entire memory of 1TB + 16GB in its addressible region
Shaders can access this entire thing as if it is local VRAM without doing SDMA
Now you can load DeepSeek 670B Model in RAM, and it would appear to GPU as everything local in VRAM

But since it is also an active device, it needs CXL.cache to maintain cache coherency with CPU , e.g., L3. in case there is concurrent access.

Memory expander devices like Samsung's don't need CXL.cache because memory is not doing write operations on its own. Just CXL.mem

 

[StefanR5R]

Shaders can access this entire thing as if it is local VRAM without doing SDMA
Now you can load DeepSeek 670B Model in RAM, and it would appear to GPU as everything local in VRAM

Logically, yes. Performance wise, there is still the large cliff between on-board and off-board memory. I am guessing that a naive dGPU implementation with CXL access might easily end up performing worse than a pure CPU implementation. Hence my thought that a CXL enabled implementation still needs to explicitly "swap" between local and remote RAM.

Edit: Regarding the addressing of host memory, I do admit that I am only familiar with the CPU view on classic PCIe DMA, not with the GPU view.

 

[DisEnchantment]

Logically, yes. Performance wise, there is still the large cliff between on-board and off-board memory. A naive dGPU implementation with CXL access might easily end up performing worse than a pure CPU implementation. Hence my though that a CXL enabled implementation still needs to explicitly "swap" between local and remote RAM.

Of course having lots of VRAM would be better than having CXL backed VRAM.
But it does not swap. The memory access at any address mapped to another device is simply routed, It is just like any NUMA access.
This is not me explaining the standard is like that.

Also most competitive models these days use MoE and the entire model is not activated. Case in point is DeepSeek. There are hotspots but you dont need to access everything, it is just that the entire model has to be loaded, a fraction of the entire model depending upon the expert being engaged gets accessed

The main advantage is being able to load the full model without getting distilled to oblivion.

 

[adroc_thurston]

Of course having lots of VRAM would be better than having CXL backed VRAM.

CXL.mem is kinda slow by GPU standards and NUMA kinda blows too.
I'd rather not have more tiers outside of some real edge cases.

 

[OneEng2]

The most expensive node per wafer yielded is 18A, one of many reasons why it has little traction.
N2 is worth the cost bump over N3.

Not sure I agree that N2 is worth the cost bump over N3 for all applications. If AMD can compete with N3P on client, why would they pay for N2?

Silicon Valley. No software engineer here uses a Windows computer. It's 95% Macs and 5% Linux.

Hard disagree. No one in Silicon Valley, where I work, uses a Windows computer for software development. If you agree that the best software comes out of Silicon valley, then you'd agree with me. If not, there's no point in arguing.

Ahh... I am the head of a software department (and hardware). Exactly what percentage of computer sales do you think people like you and I represent?

In my office, we have mostly people using windows PC's .... even in development. Note, we are heavily embedded vs cloud and mobile apps.

Mobile group does use mostly Mac (because Apple is such a PITA and won't cross compile like EVERY other OS on the planet). THIS and THIS alone is why our mobile developers use a Mac. Cloud group is a mix of Mac, Windows and Linux. Embedded is 100% PC and Client computing is about 80% Windows.

Still, the VAST majority of business computer users are Windows. Look it up (around 85% IIRC).