News AMD Ryzen 8000: Strix Point mit 4+8c- und Strix Halo mit 16 Zen-5-Kernen

[Deinorius]

Je mehr ich das Ganze Sacken lasse, desto mehr bin ich überzeugt, dass für die E-Kerne die Konfig mit 4 E-Kernen an einem gemeinsamen L2 für Zen 5 kommen wird.

Meinst du jetzt wirklich L2? Kannst du das genauer erläutern? Ich weiß, dass die E-Cores seit Alder Lake einen shared L2 haben, aber würde das bei AMD auch passen?

 

[ETI1120]

Meinst du jetzt wirklich L2?

Es ist halt die Meinung/Erwartung eines Laien.

Kannst du das genauer erläutern?

Ich habe mir Mal den Spaß gemacht und den E-Kern in dem Die Shot auszumessen. Da ich keine Bezugswerte habe, kommen natürlich nur relative Größen raus. Um die Kernteile zu identifizieren, habe ich die Folie von AMD verwendet. Ich komme auf folgende Werte:
L2-Cache: ca 41 %
Integer: ca 43 %
FP: ca 16 %

Für einen Kern der nicht auf High Performance ausgelegt ist, erscheint mir 40 % in den L2-Chache zu investieren, ein bisschen viel. Angesicht der Einschränkungen beim Takt fällt IMO der kleinere L2-Cache nicht so stark ins Gewicht.

Ich weiß, dass die E-Cores seit Alder Lake einen shared L2 haben, aber würde das bei AMD auch passen?

Wie so nicht?

 

[Deinorius]

Aus den Zahlen heraus erscheint es schlüssig, den L2 zu verkleinern, um noch kleinere Cores zu bekommen, durchaus. Die primäre Frage ist doch, wie sich Server Anwendungen in der Hinsicht verhalten würden. Basierend darauf bekommt Zen5c die L2 Größe und das würde auch auf Client Seite übernommen werden.
Ich sehe es also nicht zwingend als Vorteil an, aber wer weiß. ^^

Wie so nicht?

Es macht für AMD mehr Sinn den CCX/CCD Ansatz zu behalten und das ist jetzt auch nur eine Laien-Perspektive, aber ich sehe da ein Problem 2 oder gar 4 Zen5c/Zen6c einen L2 teilen zu lassen und dennoch mit einem L3 zu verbinden.
Am ehesten sehe ich das in Kombination mit einem V-3D Cache, aber da zumindest Zen4c keine TSV hat und das für die Nachfolger nicht die höchste Priorität haben dürfte, sehe ich dafür Schwarz. Aber mal sehen, was die Zukunft bringt.

 

[ETI1120]

Aus den Zahlen heraus erscheint es schlüssig, den L2 zu verkleinern, um noch kleinere Cores zu bekommen, durchaus. Die primäre Frage ist doch, wie sich Server Anwendungen in der Hinsicht verhalten würden.

AMD hat die Anzahl der Designs im letzten Jahr drastisch erhöht.
Server-Anwendungen und Hybrid Design verwenden andere Chips, haben also jeweils Designs.

Und in diesem Fall macht AMD IMO den Building Block nicht mehr aus Kern + L2 Cache sondern nimmt nur noch den Kern und organisiert den L2 Cache so wie es für die jeweilige Anwendung am besten ist.

• Bei den Hybrid CPUs teilen sich 4 E-Kerne den L2-Cache, und werden als Block in das CCX eingebunden. Don't ask me how,
• Bei den Server-CPUs sind die Kerne nach wie vor in einem CCX organisiert.
• Die Spannende Frage ist, wann AMD das CCX erweitert. Mike Clark hat im Anantech Interview erwähnt dass AMD daran arbeitet, aber auch klar gemacht dass es nicht trivial ist. IMO werden dann mehr xGMI-Links je einem Kern erforderlich und die Anbindung des L3-Caches an 12 Kerne wird auch nicht trivial sein.

Wenn ich richtig liege wäre die E-Kerne in einer Hybrid-CPU wären anders organisiert als die kerne auf einem Zen 4c CCD

Es macht für AMD mehr Sinn den CCX/CCD Ansatz zu behalten und das ist jetzt auch nur eine Laien-Perspektive, aber ich sehe da ein Problem 2 oder gar 4 Zen5c/Zen6c einen L2 teilen zu lassen und dennoch mit einem L3 zu verbinden.

Frag mich nicht wie das gehen könnte, dazu kenne ich mich in der Schaltungstechnik zu wenig aus.
Aber so wie ich die Die shots interpretiere werden aktuell die Kerne über den L2-Cache mit dem L3-Cache gekoppelt.

Die Alternativen mit 12 Kernen ergeben IMO noch viel weniger Sinn:

• Das CCX auf 12 gleichwertige Kerne zu erweitern, bedeutet massiven Aufwand, ich kann mir nicht vorstellen, dass AMD damit am unteren Ende der Produktpalette anfängt.
• 2 CCX in einer APU ergibt IMO keinen Sinn, da ja auch noch die Kopplung der CCX auf der APU implementiert werden muss. Außerdem wird der L3-Cache so nicht sinnvoll genutzt.