Discussion Beyond zen 6

[CouncilorIrissa]

No need to speculate about stuff that has been known already ages ago.

Good catch, but "known" is stretching it, considering even the OP is using the word "might", rather than "is".

 

[Thunder 57]

nope.

Shut up without more commentary.

 

[adroc_thurston]

Shut up without more commentary.

I'm not obliged to spoonfeed anyone.
Especially not you.

 

[dangerman1337]

They're both 2028.

There's been recent rumors that Titan Lake is now a Mobile product, makes sense in context. Though I expect RZL to beat Zen 7 but not by much and at a larger BOM cost in MT, ST it'll likely be Zen 7's advantage. Hammer Lake especially with eLLC will probably take the ST crown from Z7 (though in theory AMD could just do a Zen 7+ with A14 SPR to counter that and still be on AM5).

 

[adroc_thurston]

Though I expect RZL to beat Zen 7

It haez to beat Zen6 first.

Hammer Lake especially with eLLC will probably take the ST crown from Z7

oh my wherddya heard about that.

(though in theory AMD could just do a Zen 7+ with A14 SPR to counter that and still be on AM5).

Hammer Lake is like H1'30 optimistically aka Zen8 timeline.

 

[Doug S]

8 bro, 4 is for children.

SMT640 ought to be enough for anyone

 

[itsmydamnation]

SMT640 ought to be enough for anyone

sweet child of larrabee

 

[aigomorla]

Shut up without more commentary.

I'm not obliged to spoonfeed anyone.
Especially not you.

Both of u guys need to put each other on ignore.
I am not going to play kindergarden teacher and ask you two to face the corner wearing a dunce hat next time.

Moderator Aigomorla

 

[OneEng2]

It haez to beat Zen6 first.

I suspect that Zen 6 will not be a great as you have predicted and that NVL (especially the bLLC version) will be much better than you imagine.

Having said that, I still believe AMD will retain the lead in most benchmarks with Zen 6 as they have been at 3D cache and MCM's longer than Intel that is still teething on both.

I don't think NVL and it's successors will be such crap as you think. AMD is going to need Zen 6.

 

[adroc_thurston]

I suspect that Zen 6 will not be a great as you have predicted and that NVL (especially the bLLC version) will be much better than you imagine.

Intel sucks.

I don't think NVL and it's successors will be such crap as you think

They're bad because Intel CPU IP is bad.

 

[del42sa]

SMT4 baybeeeee

and FD-SOI

 

[Kepler_L2]

The recently surfaced changes to the scheduler layout make me kind of suspicious as to who's exactly working on Zen 6. I don't think it's the same team, but this is purely speculative on my part.

Both Zen6 and Zen7 are Kai Troester team no?

 

[inquiss]

Both Zen6 and Zen7 are Kai Troester team no?

How come they changed the cadence? Would you mind letting me know who has designed each. That's super interesting!

 

[adroc_thurston]

Both Zen6 and Zen7 are Kai Troester team no?

Don't think so.

Not the E cores

Atoms are less bad, but power sucks.
Case and point: Clearwater Forest.

 

[adroc_thurston]

Clearwater Forest still has the horrible mesh it's not untill DMR that problem is getting solved doing a big gigantic mesh is a problem

Graviton 5 has a big chonky mesh and is <100ns memlat and looks swanky.

 

[CouncilorIrissa]

Both Zen6 and Zen7 are Kai Troester team no?

Dunno. Zen 6 looks like it's being worked on by Troester, Zen 7 is anyone's guess?

 

[adroc_thurston]

Zen 7 is anyone's guess?

Leslie Barnes probs

 

[inquiss]

I am wondering if Intel will be able to stay with the yearly cadence, and full stack of products release yearly.

Also, it seems like Intel is stabilizing its chiplet strategy, while AMD is upending it, with a number of components that don't seem to perfect re-usability (from what I can tell).

What do you mean by this? Seems like the longer term move is to move more cache off latest node and to reuse CPUs/GPUs to make APUs. Seems like more reuse than ever

 

[Joe NYC]

What do you mean by this? Seems like the longer term move is to move more cache off latest node and to reuse CPUs/GPUs to make APUs. Seems like more reuse than ever

I am counting:
- at least one distinct desktop IOD (memory controller, IO, unique iGPU - 1st die
- MDS1 - duplicates IO, MC, has unique iGPU, unique CPU - 2nd die
- MDS Mini - duplicates IO, unique CPU, removes MC and iGPU - 3rd die
- MDS Halo - duplicates IO, another unique CPU, removes MC and iGPU - 4th die
- XBox Magnus - SoC die #5 that just again reshuffles stuff, more unique CPU counts

There seems to be more IP reuse, some GPU reuse, but SoCs seem like a big mess with too many dies.

With the mess of the dies and SoCs, it would not be surprising if the release of all of these takes 1.5 year or more.

 

[Tangopiper]

I am counting:
- at least one distinct desktop IOD (memory controller, IO, unique iGPU - 1st die
- MDS1 - duplicates IO, MC, has unique iGPU, unique CPU - 2nd die
- MDS Mini - duplicates IO, unique CPU, removes MC and iGPU - 3rd die
- MDS Halo - duplicates IO, another unique CPU, removes MC and iGPU - 4th die
- XBox Magnus - SoC die #5 that just again reshuffles stuff, more unique CPU counts

There seems to be more IP reuse, some GPU reuse, but SoCs seem like a big mess with too many dies.

With the mess of the dies and SoCs, it would not be surprising if the release of all of these takes 1.5 year or more.

Magnus is at least semi-custom, so not really something to worry about from a reuse perspective.

MDS Premium and Halo are the ones I think are wasteful - they could share a 3nm SOC chiplet between them. N3P, 2x Zen 6lp, 12x Zen 6 w/ 48MB L3. All the required I/O and controllers etc. MDSP would be AT4 + SOC, MDSH is AT3 + SOC + optional 2nm CCD.

I am sure AMD considered this and deemed it not viable. Probably too large a chiplet on 3nm with full fat Zen 6 + 48MB and chopping that down would just be asking for trouble with scheduling for MDSH. But idk, just speculation.

In any case I expect the reuse strategy to only grow more advanced with Zen 7 and beyond.

 

[Joe NYC]

Magnus is at least semi-custom, so not really something to worry about from a reuse perspective.

MDS Premium and Halo are the ones I think are wasteful - they could share a 3nm SOC chiplet between them. N3P, 2x Zen 6lp, 12x Zen 6 w/ 48MB L3. All the required I/O and controllers etc. MDSP would be AT4 + SOC, MDSH is AT3 + SOC + optional 2nm CCD.

I am sure AMD considered this and deemed it not viable. Probably too large a chiplet on 3nm with full fat Zen 6 + 48MB and chopping that down would just be asking for trouble with scheduling for MDSH. But idk, just speculation.

In any case I expect the reuse strategy to only grow more advanced with Zen 7 and beyond.

Intel die partitioning is just more sane, more logical than the mess AMD came up with.

The only way AMD partition strategy would be understandable is if MDS1 die is so good, so competitive in price, performance efficiency and additionally, so early on the market that it was worth eliminate all the reusability with other SKUs that will come later.

In other, it needs to be a home run, that would make it worth taking it out of the epicenter of product line and then making all the other chiplet based solution on periphery saddled with high design costs, low volumes of their chiplets and low reusability.

 

[DAPUNISHER]

No more Intel talk.

 

[Mopetar]

I'm a little more interested in what AMD does with their v-cache than most of the other aspects of the architecture.

By the time some of these come out they should have had plenty of time to work out how to incorporate some of the next generation 3D packaging technologies that have been talked about as well as built up the engineering knowhow to make the best use of the potential.

 

[marees]

Magnus is at least semi-custom, so not really something to worry about from a reuse perspective.

Anything stopping AMD from using the same CPU chiplet for Magnus & Medusa Premium

Magnus — series X2
MDS-P — series S2

 

[adroc_thurston]

Anything stopping AMD from using the same CPU chiplet for Magnus & Medusa Premium

How is this even a question?
Semi-custom console tile has an extremely poverty CPU config.