AMD X399 ！！！！！

[scannall]

Can an APU land on this socket? Not that it would make much sense...

Yes, and it would make sense. For GPGPU and OpenCL stuff. Better than AVX really.

 

[Topweasel]

Seems legit as it isn't technically possible to have 10C or 14C configurations with Zen.

Why I thought AMD had working samples of 3+1 4c configurations? They just preferred the symetrical designs and that CCX mirroring was more important per die. So 2+2 on one and 3+3 one the other or 4+4 and 3+3.

 

[Atari2600]

Can an APU land on this socket? Not that it would make much sense...

An APU would make an awful lot of sense - for number crunching where you need frequent access to the system memory pool.

PCIe3x16 has a bandwidth of ~15.5 GB/s.

The existing R7 have a bandwidth around twice that. Double up those memory channels and you will double that.

Niche market... maybe. But AMD thought it was worthwhile to tack an SSD onto a GPU for number crunching to avoid going through the PCIe slot...

 

[raghu78]

Seems legit as it isn't technically possible to have 10C or 14C configurations with Zen.

Why would it not be possible to have 10C and 14C with 2 8C dies in MCM.

10C = (3+3) + (2+2)
12C = (3+3) + (3+3)
14C = (4+4) + (3+3)
16C = (4+4) + (4+4)

I think its definitely possible to have 10C and 14C along with 12C and 16C. The flexibility with AMD's MCM approach is really very good.

 

[ryzenmaster]

Speaking as a software guy, I'm fairly confident there will be no asymmetric CCX configurations. Even if it were technically feasible(which I'm not at all convinced that it is), it would make very little sense given how difficult it would make any optimization for the platform. Even if you optimize for the CCX design, your code would run inconsistently as there would be no way of knowing whether the CCX you land on has full compute capacity and cache available to it. Load balancing and scheduling becomes a mess. What we will almost certainly see is 8, 12 and 16C chips.

In other words: 99.99% sure there will be no asymmetric Zen chips

 

[raghu78]

Speaking as a software guy, I'm fairly confident there will be no asymmetric CCX configurations. Even if it were technically feasible(which I'm not at all convinced that it is), it would make very little sense given how difficult it would make any optimization for the platform. Even if you optimize for the CCX design, your code would run inconsistently as there would be no way of knowing whether the CCX you land on has full compute capacity and cache available to it. Load balancing and scheduling becomes a mess. What we will almost certainly see is 8, 12 and 16C chips.

In other words: 99.99% sure there will be no asymmetric Zen chips

10C and 14C are not asymmetric if the CCXs are configured as 10C = (3+3) + (2+2) and 14C = (3+3) + (4+4) . Within each Zen die the CCXs are symmetric. There is no requirement for symmetricity across Zen dies.

 

[T1beriu]

I am curious about one thing. The R9 SKUs are supposed to be in 4CCX configuration (with 4 cores in each) and the disabling of the cores should be uniform across all CCX's they amalgamated together. Now, that means the existence of 10 and 14 cores do not possible unless AMD is actually using two 8-core CCX, or simply not equally disabling the core in each of the four 4-core CCXs.

Speaking as a software guy, I'm fairly confident there will be no asymmetric CCX configurations. Even if it were technically feasible(which I'm not at all convinced that it is), it would make very little sense given how difficult it would make any optimization for the platform. Even if you optimize for the CCX design, your code would run inconsistently as there would be no way of knowing whether the CCX you land on has full compute capacity and cache available to it. Load balancing and scheduling becomes a mess. What we will almost certainly see is 8, 12 and 16C chips.

That's why I'm pretty sure that product stack is fake. Not the mention the exaggerated number of SKUs and stupid naming scheme.

10C and 14C are not asymmetric if the CCXs are configured as 10C = (3+3) + (2+2) and 14C = (3+3) + (3+3) . Within each Zen die the CCXs are symmetric. There is no requirement for symmetricity across Zen dies.

How is that symmetrical?!

LE: (3+3) + (3+3) it's not 14. I think you meant (4+4) + (3+3), that's, in my book, 100% asymetrical.

 

[IEC]

10C and 14C are not asymmetric if the CCXs are configured as 10C = (3+3) + (2+2) and 14C = (3+3) + (3+3) . Within each Zen die the CCXs are symmetric. There is no requirement for symmetricity across Zen dies.

Technical possibility aside, what you are suggesting would require yields to be utterly atrocious. Which shouldn't be the case with a mature 14nm process and the small die size of Ryzen 7. That's the whole point of the CCX/Infinity Fabric arrangement - slap two (or more) smaller dies together (instead of a single big one) for better yields AND solid performance.

 

[tamz_msc]

10C and 14C are not asymmetric if the CCXs are configured as 10C = (3+3) + (2+2) and 14C = (3+3) + (3+3) . Within each Zen die the CCXs are symmetric. There is no requirement for symmetricity across Zen dies.

The OS scheduler has to know beforehand about thread allocation across asymmetrical dies. We have already seen what Microsoft thinks of the 'issues' surrounding its scheduler.

It's less likely that such a thing would happen, that's why AMD differentiates its SKUs on frequency bins, not core counts.

 

[The Stilt]

Why would it not be possible to have 10C and 14C with 2 8C dies in MCM.

10C = (3+3) + (2+2)
12C = (3+3) + (3+3)
14C = (4+4) + (3+3)
16C = (4+4) + (4+4)

I think its definitely possible to have 10C and 14C along with 12C and 16C. The flexibility with AMD's MCM approach is really very good.

Because all CCXs, dies and nodes must have same number of cores enabled.
If a MCM packaged part would have 6C/12T and 8C/16T capable dies installed, the PSP would automatically software downcore the 8C/16T die to match the 6C/12T die configuration.
The same applies for multiple node systems (i.e. different CPU SKU in 2P).

 

[DrMrLordX]

Can an APU land on this socket? Not that it would make much sense...

Snowy Owl, so . . . yes.

 

[The Stilt]

Snowy Owl, so . . . yes.

Snowy Owl isn't an APU.

 

[bauerbrazil2014]

Because all CCXs, dies and nodes must have same number of cores enabled.
If a MCM packaged part would have 6C/12T and 8C/16T capable dies installed, the PSP would automatically software downcore the 8C/16T die to match the 6C/12T die configuration.
The same applies for multiple node systems (i.e. different CPU SKU in 2P).

So, the only way this rumor could be true would be with 8 cores per CCX.

10C = 5+5
12C = 6+6
14C = 7+7
16C = 8+8

 

[Atari2600]

Snowy Owl isn't an APU.

For sure?

Thanks! I've seen it either way for some time now. Given the other APU code names knocking around being avian in nature - I was half-minded to believe it was an APU.

 

[The Stilt]

So, the only way this rumor could be true would be with 8 cores per CCX.

10C = 5+5
12C = 6+6
14C = 7+7
16C = 8+8

And again, you cannot have 5 or 7 core configs with Zeppelin.
Both CCXs must have the same number of cores enabled, or the other CCXs must be completely disabled.

 

[Saylick]

And again, you cannot have 5 or 7 core configs with Zeppelin.
Both CCXs must have the same number of cores enabled, or the other CCXs must be completely disabled.

Correct me if I am mistaken, but only the 2 CCXs on the same die need to have the same number of enabled cores, right? For a 2-die SKU, you can have a skewed configuration of active cores between the two dies, i.e. for a 10C part, it can be 2/2 + 3/3?

EDIT: Never mind. Looks like all I needed to do was scroll up a bit more.

 

[DrMrLordX]

Snowy Owl isn't an APU.

I thought Snowy Owl was going to be their massive 200-300W APU for the server socket?

 

[Ajay]

Because all CCXs, dies and nodes must have same number of cores enabled.
If a MCM packaged part would have 6C/12T and 8C/16T capable dies installed, the PSP would automatically software downcore the 8C/16T die to match the 6C/12T die configuration.
The same applies for multiple node systems (i.e. different CPU SKU in 2P).

Since I must have missed something, why does the Platform Security Processor handle this?

 

[The Stilt]

Since I must have missed something, why does the Platform Security Processor handle this?

Due to security.
In Zeppelin you cannot change any hardware settings without the PSP approving the changes.
Even things like memory training is being taken care of by the PSP and that occurs before any of the standard bios code has loaded.
The SMU handles runtime operations.

 

[Topweasel]

People keep saying the asymmetrical configuration can't happen. But AMD had working samples of a 3+1 configuration. It's not that I don't believe people, hell I questioned the existence of this platform in general in the first few pages of this thread.

But people seem to pretty sure of themselves of this no Assymetrical business but again reports where that AMD was testing several different configurations for R5 specially the 4 core versions and had 4+0, 2+2, and 3+1 samples testing in the wild.

 

[Atari2600]

People keep saying the asymmetrical configuration can't happen. But AMD had working samples of a 3+1 configuration.

reports where that AMD was testing several different configurations for R5 specially the 4 core versions and had 4+0, 2+2, and 3+1 samples testing in the wild.

Its not impossible to have both.

ES with asymmetric configs - but AMD realised based on the feedback from software houses that it wouldn't work. So canned it from all release plans.

 

[Topweasel]

Its not impossible to have both.

ES with asymmetric configs - but AMD realised based on the feedback from software houses that it wouldn't work. So canned it from all release plans.

Did they can it from all release plans or just the low cost consumer AM4 platform? I ask because they could have figured that with Numa and more workstation or server oriented tasks that configuration made less of a difference?

I only asked originally because people were making it sound like the PSP was completely restricted to not allow this setup, where we know AMD has had it working before. I think AMD really wanted to save chips that had wierd core issue combinations. But it was too much of a penalty on games and other non linear work. Maybe they kept it going in the workstation and server realm because the penalty if any is much smaller?

 

[lolfail9001]

I ask because they could have figured that with Numa and more workstation or server oriented tasks that configuration made less of a difference?

Simple straight-forward question: how many servers do you know that use multi-CPU configs with different CPUs.

Point made.

 

[Cookie Monster]

https://twitter.com/WikiChip/status/863874789622022145

If these are true and hopefully they wont charge you $$$ like intel does, this just might be my next work station.

However The naming scheme could be abit better.. would have thought something like:

Ryzen 9 1980X, 1970X, 1960X, 1950X sound better than 1998.. almost as bad as Titan Xp.

 

[lobz]

AMD hates money, don't they.

Surely not as much as you like uninspired trolling.