News AMD Ryzen und Epyc mit Zen 6(c): Gerüchte zu Medusa Ridge, Point, Halo und Epyc „Venice“

[SaschaHa]

@stefan92x
Mit Sicherheit spielt der IF auch eine Rolle, insbesondere wenn es um die Kommunikation der CCDs untereinander geht. Der 3D V-Cache dürfte aber gezeigt haben, welch enorme Bedeutung vor allem der L3-Cache hat, zumindest bei der Gaming-Performance. Der IF bewirkt ja lediglich, dass die Kommunikation "nach außen" bzw. zum anderen CCD möglichst zügig ist, aber im Optimalfall holen sich die Kerne ihre Daten ja aus dem eigenen Cache und greifen gar nicht erst auf den IF zu. Ich halte daher den L3-Cache tatsächlich für ziemlich essenziell.

Neben dem 3D V-Cache ist ja auch Zen 3 ein Beleg für dessen Relevanz (beim Gaming). Zen 2 kam noch mit 2 CCX pro Die, man hatte also 2x 16 MB L3-Cache statt 1x 32 MB. Zen 2 hatte bereits eine top Anwendungsperformance aufgrund der schieren Anzahl an Kernen, aber beim Gaming war es eine Krücke. Mit Zen 3 hat sich das Blatt dann gewendet: Zen 3 konnte massiv bei der Gaming-Performance zulegen, weitaus stärker als bei der Anwendungsperformance. AMD selbst hat immer wieder das neue Cache-Design hervorgehoben und es mit der massiven Gaming-Performance in Verbindung gebracht. Und letztendlich hatte sich da ja nur die Aufteilung und nicht die Gesamtgröße des Caches geändert. Tatsächlich könnte das aber auch für dein Argument mit dem IF sprechen, denn letztendlich bedeutet der Zusammenschluss des Caches ja auch, dass der IF möglicherweise die Daten schneller an ein CCD verteilt, da es eben nur ein und nicht 2 CCX pro CCD gibt, an die er die Daten senden muss. Aber das hängt eben von der Funktionsweise im Detail ab, von daher ist das von außen schwer zu beurteilen.

Aber unabhängig davon, was nun relevanter ist: Die Frage ist doch, kann AMD es sich leisten, den Cache nicht zu vergrößern, falls dieser tatsächlich einen erheblichen Einfluss auf die Performance hat? Letztendlich wird ein etwas größerer Cache kaum zu Mehrkosten führen, aber er könnte einen enormen Einfluss auf das finale Produkt haben. Hier würde ich Lisa Su eher so einschätzen, dass sie da lieber kein vermeidbares Risiko eingeht.

Nur nochmal als Gedankenspiel: Zen 6 wird mit Sicherheit stärkere Kerne haben als Zen 5. Und wenn die Anzahl an Kernen dann um 50% erhöht wird, wird es auch mehr als 50% mehr Anfragen an den Cache geben. Den Cache unverändert zu lassen, wäre aus meiner Sicht daher gewagt. Und ob eine höhere Bandbreite alleine ausreicht, ist auch fraglich, da es neben der Bandbreite ja auch auf die Latenzen ankommt, die bei 50% mehr Kernen dann ebenfalls stärker ins Gewicht fallen.

Aus meiner Sicht ist die Frage daher eher, für welchen Weg AMD sich entscheidet: 1 oder 2 CCX pro CCD. Und dann eben, wie groß der Cache wird. Ich würde es aber tatsächlich für gewagt halten, wenn sie den Cache nicht vergrößern.

Naja, das alles steht noch in den Sternen. Letztendlich wird keiner von uns zu 100% Recht behalten, es wird wohl ein wilder Mix aus allen Spekulationen werden. Ich hoffe zumindest, dass meine Gedankengänge nachvollziehbar sind, auch wenn es am Ende anders kommen sollte

 

[stefan92x]

@SaschaHa das sind alles gute Ausführungen, denen ich auch so zustimmen würde. Du bist allerdings auf eine Option nicht eingegangen: 3D-Cache. Es gibt nunmal Anwendungen, die enorm von Cache profitieren, andere hingegen weniger (erst recht, wenn der IF schneller/IOD besser wird).

Da wir bei Zen 5 praktisch keinen Nachteil mehr durch den 3D-Cache haben, sondern nur noch Vorteile, kann ich mir gut vorstellen, dass AMD da einfach auch stärker drauf setzen könnte. Also CCD mit begrenzt großem Cache in N3P, aber Option auf deutlich mehr Cache (in günstigerem Node) für die, die es brauchen.

 

[SaschaHa]

@stefan92x
Guter Punkt, den ich ebenfalls für möglich halte. Letztendlich könnte AMD damit die Schere zwischen den X3D- und den normalen Modellen noch weiter öffnen und X3D damit umso attraktiver machen. Allerdings - und das spricht aus meiner Sicht tendenziell dagegen - könnte man sich damit aber einige Kritik bei den normalen Modellen einfangen, falls sich der "kleine" Cache dann tatsächlich als Schwachpunkt herausstellen sollte. Die Frage ist halt, wo AMD dann den Schwerpunkt setzt.

Denkbar wäre auch, dass AMD mit Zen 6 nur die Anzahl der Kerne erhöht, und mit Zen 7 dann auch den Cache vergrößert. Das wäre vor allem dann sinnvoll, falls Zen 7 von der Architektur her zu nahe an Zen 6 liegt.

Letztendlich können wir aktuell nur spekulieren, da es ja noch keinerlei Details dazu gibt. Aus meiner Sicht wäre es zumindest höchst wünschenswert, wenn der Cache auch bei den Basismodellen wächst. Und aus aktueller Sicht würde ich zumindest auch dazu tendieren, dass AMD diesen Schritt gehen wird. Aber wir werden sehen. Unterm Strich zählt ja eh nur das Gesamtergebnis, und nicht, wie genau dieses erreicht wird. Da vertraue ich einfach mal, dass wir mit Zen 6 auf jeden Fall einen ordentlichen Sprung nach vorne sehen werden, auf den wir uns freuen können

 

[ETI1120]

Ja auf die Flächenangaben würde ich aktuell auch noch nicht so viel geben.

Nicht nur auf die Flächenangaben.

Alles was von MLID kommt nehme ich zur Kenntnis. Ohne Bestätigung von anderen nehme ich es nicht sonderlich ernst. Die Trefferquote ist einfach zu schecht.

Was mich stutzig macht ist das "Good job" von Kepler.

Seitdem ist mir kein Tweet von Kepler zu den Dies von Zen 6 bekannt.

Das "good job" kann tatsächlich ein Lob sein (d. h., Keplers Info vom Mai war falsch) oder eine sarkastische Bemerkung. Kepler postet mit Vorliebe die Folien von MLID, wenn Mal wieder offensichtlich wurde was für ein Müll MLID verzapft hat.

Im Zweifel gehen sie auch wieder höher, hat man bei Strix ja gesehen. Du bekommst eben gerade auch für ne APU nicht alles unter.

Die APUs leiden als Monolithe massiv darunter dass die IO praktisch nicht mehr skaliert. Und wenn dann noch eine NPU drauf muss, mehr CPU Kern und mehr CUs, dann wird es halt groß.

Dann hilft es auch nicht mehr viel, wenn AMD bei PCIe Gen 4 bleibt und zudem noch 4 Lanes streicht, ...

Das Lehrgeld zahlt AMD bei Grafikkarten zur Genüge.

Bei RDNA 3 ist allerdings das Problem, dass AMD mehr Silizium als Nvidia investiert und trotzdem, wenn man die Rasterperformance betrachtet, gerade so mit der 4080 mithalten kann. Von Raytracing und Leistung in AI ...

 

[ETI1120]

Wir sind aktuell mindestens 1,5 Jahre vom Release entfernt. Aktuell würde ich diese 75 mm² als frühe Prognose bzw. einen Orientierungswert interpretieren, den man aber auch noch überschreiten kann.

IMO weiß AMD momentan sehr genau wie groß die Zen 6 Dies werden.

Allerdings ist diese Information geheim.

Und wie gesagt, 16 MB L3-Cache nehmen aktuell lediglich 7,85 mm² ein und sind im Vergleich zur Logik vermutlich günstiger bzw. wirken sich weniger stark auf den Yield aus. Eine leichte Erhöhung der Fläche zugunsten eines größeren L3-Caches wäre also vermutlich nicht so tragisch für AMD.

Latenz und Größe legen fest wie effektiv ein Cache funktioniert. Es ist seht schwer einen Cache zu vergrößern ohne die Latenz zu erhöhen.

Wenn sie auf demselben Wafer gefertigt werden, kosten 1 mm² SRAM und 1 mm² Logik dasselbe. Lediglich wenn sie auf verschiedenen Wafern gefertigt werden, könnten sich die Kosten je mm² unterschieden.

Es gibt Kostenziele, es gibt Performanceziele. Beides muss zusammenpassen.

Ja sehr viel Cache mit geringer Latenz wäre toll. Kerne mit mehr IPC wären toll. Mehr Kerne wären toll. Allerdings sind die Zeiten vorbei, an dem man mit einem Shrink die Kosten drastisch reduzieren kann.

Fakt ist, dass Intel mit seinem 8+16-Design ordentlich Druck macht und AMD nicht ewig bei 16 Kernen bleiben kann.

Wenn die Kerne ordentlich Dampf liefern, sind 16 Kerne mehr als genug.

Das Problem von Zen 5 ist nicht, dass es es weiterhin nur 16 Kerne sind. Das Problem ist dass sich die Änderungen von Zen 5 bei den typischen Anwendungen von PCs nur in einem moderaten Performanceanstieg äußern

Es gibt übrigens einen offensichtlichen Weg die Anzahl der Kerne zu erhöhen: 3 CCD verwenden.

Und dass man die Anzahl der Kerne erhöht, den Cache aber gleich lässt, wäre ein gewagtes Spiel.

Nicht unbedingt. Derzeit ist relativ offensichtlich, dass der IF zwischen IOD und CCD eine ziemliche Bremse darstellt. Großer Cache kann diesen Effekt abmildern, aber ein deutlich schnellerer IF (ermöglicht durch technisch besseres Packaging), gegebenfalls in Kombination mit Unterstützung für schnelleren RAM, könnte den Bedarf an großem Cache auch einfach deutlich reduzieren. Cache steht ja nicht für sich alleine, da muss man die gesamte Kette DIMM -> RAM-Channel -> Memory-Controller -> Infinity Fabric -> Cache -> Core betrachten.

Wenn die Cache Misses weniger kosten, könnte es einen Anstieg der Missrate kaschieren.
Das sind Dinge die AMD intensiv durchspielen wird.

Ich glaube dass es wie es MLID in seinem Video bereits erwähnte, nur einen 12 Kern CCD und die
daraus resultierenden davon abgeleiteten z.B.: 10 und 8 Kern Varianten im Desktop geben wird.

Es ist ja schön was MLID so alles erzählt. Es ist halt sehr viel Blödsinn dabei. Wie war das mit dem Release von RDNA 4 in 2024? Dass Intel die GPUs einstellt, ...

Als ich den Tweet von Kepler im vorgherigen Post gesucht habe, bin ich auf mehrere Tweets gestoßen, in denen Folien von MLID gezeigt wurden bei denen Aussagen mit "High Confidence" komplett falsch waren.

Wenn AMD auf 12 Kerne je CCDs geht, muss AMD die 6 und 8 Kerner ausschließlich durch APUs abdecken.

Aber der Sprung von 8 auf 12 bringt natürlich andere Vorteile wie zum Beispiel
eine feinere Untergliederung ihres Produktfolio.

Kannst Du mir Mal bitte erklären, wie man mit größeren Bausteinen eine feinere Unterteilungen erreichen kann?

Es gibt Konfigurationen die mit 12 Kern CCD praktikabel sind, die mit 8 Kern CCD unpraktikabel sind. Aber es gibt auch Konfigurationen die mit 8 Kern CCD praktikabel sind, die mit 12 Kern CCD unpraktikabel sind

Wenn AMD von 8 auf 12 Kernen je CCD geht, wird die Konfiguration mit 12 kernen günstiger und die Mit 10 überhaupt erst praktikabel. Gleichzeitig wird die Konfiguration mit 8 Kernen teuer und die mit 6 Kernen unpraktikabel. Die bisherige Spitzenkonfiguration mit 16 Kernen wird ebenfalls unpraktikabel. Dafür werden die Konfigurationen mit 20 und 24 Kernen möglich.

Wenn AMD im Desktop auf 8 Kernen je CCD bleiben würden und auf maximal 3 CCDs gehen würde, gäbe es mehr praktikabele Konfigurationen.

Mit Sicherheit spielt der IF auch eine Rolle, insbesondere wenn es um die Kommunikation der CCDs untereinander geht.

Die Darstellung ist Zen 4, passt aber auch für Zen 5

Quelle siehe Folie

Das CCD ist über den IF mit dem IOD verbunden und der gesamte Datenverkehr von und zum CCD geht über den IF. Hier ist inbesondere der Zugriff auf den Hauptspeicher wichtig.

Eine Option bei Zen 6 mit advanced packaging wäre, die Verbindung zwischen CCD und IOD breiter zu machen. Aber wie sinnvoll das ist, hängt letztendlich von der Geschwindigkeit der Speichermodule ab.

 

[RKCPU]

Auch ist anzumerken, dass wenn es sich wirklich um eine Kombination von Big / Little Cores handeln würde,
die erwähnten 75mm2 (TSMC 3nm) für ein CCD nicht dazu passen würden. Die Fläche wäre viel zu groß.

DRAM schrumpft geringer als Logik und Zen 5c ist vielleicht -25% groß.

Eigentlich wollte AMD ja die Big-Cores um low power Units erweitern, wenn Teillast anliegt. Auch wollte AMD Nutzung big.little ja automatisch auf dem Chip via dortiger Ansteuerung lösen.

 

[RKCPU]

ich gehe auch davon aus ,das höchstens ein 12 Kern Die kommen wird.Zumindest sind so 2x12 Chiplet möglich aber auch 16 Kerne aus 2x8 wie immmer oder aus den 2x12 wenn welche defekt sein sollten.

Ein Hexacore Zen 6 wäre 2026 kaum noch interessant, ergänzt um 4x Zen 6c = 10-Core schon.
Selbst 6x Zen 6 plus 2x Zen 6c noch denkbar - siehe unten.

Für Server stören eher die Zen 6c, dafür wären aber 48 MByte L3 denk- und nutzbar bei 8x Zen 6 aktiviert.
Obiger 6x Zen 6 plus 2x Zen 6c könnte ja auf 24 oder 32 MByte L3 deaktiviert werden.

Bei Dual-Chiplet würden dann plus 8x Zen 6c die Stromaufnahme nur mässig erhöhen zu heutigen Zen 5 Designs.

Zen Chiplet in 3nm und wahlweise I/O in 4nm mit RDNA 4 plus 3D Cache darunter könnte DDR5 Riegel bis zum Anschlag ausnutzen. Dazu dann nur Anschlüsse für ein CPU Chiplet vorsehen.

 

[ArrakisSand]

Kannst Du mir Mal bitte erklären, wie man mit größeren Bausteinen eine feinere Unterteilungen erreichen kann?

Es gibt Konfigurationen die mit 12 Kern CCD praktikabel sind, die mit 8 Kern CCD unpraktikabel sind. Aber es gibt auch Konfigurationen die mit 8 Kern CCD praktikabel sind, die mit 12 Kern CCD unpraktikabel sind

Wenn AMD von 8 auf 12 Kernen je CCD geht, wird die Konfiguration mit 12 kernen günstiger und die Mit 10 überhaupt erst praktikabel. Gleichzeitig wird die Konfiguration mit 8 Kernen teuer und die mit 6 Kernen unpraktikabel. Die bisherige Spitzenkonfiguration mit 16 Kernen wird ebenfalls unpraktikabel. Dafür werden die Konfigurationen mit 20 und 24 Kernen möglich.

Wenn AMD im Desktop auf 8 Kernen je CCD bleiben würden und auf maximal 3 CCDs gehen würde, gäbe es mehr praktikabele Konfigurationen.

Ich denke dass der low budget Bereich weiterhin mit 6 und 8 Kern Zen 5 Varianten abgedeckt werden.
Eventuell auch mit einem Refresh der weiterhin bei TSMC in 4nm gefertigt wird.
Mögliche 8 Kern Zen 6 Varianten wären dann eh nur teildefekte CPU Chiplets die in einem überschaubaren Rahmen noch anfallen würden
Zugleich wäre man mit einer solchen Vorgehensweise auch extrem Flexibel was die verwendete Fertigung anbelangt.

Zen 5 (Refresh ?) in TSMC N4 (6 / 8 cores)
Zen 6 (12 core chiplet) in TSMC N3 (Medusa Point / Halo / Venice non high density / Ridge)
Zen 6 Venice (12 core chiplet up to 192 cores???) in TSMC N3
Zen 6 Venice (32 core high density chiplet up to 256 cores) in TSMC N2 / N3?

Es gibt also gar keinen Grund mehr, aus Kostengründen einen 8 Core Zen 6 Chiplet
zu verwenden. Mit nur zwei core chiplets und einem Zen 5 Refresh
könnte man so, den kompletten Desktop Bereich abdecken.

Gegenwärtiger Status:
6, 8, 12, 16, 128, 192 (Zen 3, 4 und 5)

Spekulativ:
6, 8 (Zen 5), 8 (Zen 6), 10, 12, 16 (Zen6), 20, 24, 192 und 256
Wobei ich bei dieser Aufzählung 8, 16 (Zen 6) noch als am unwahrscheinlichsten halte, da sich diese gegenseitig überlagern.

Noch feiner geht die Unterteilung ja wohl kaum.

An eine 3 CCDs Variante habe ich eigentlich gar nicht gedacht.
Ist eine solche den überhaupt ohne Einschränkungen machbar?
Es erscheint mir aus meinem Bauchgefühl heraus aber,
nicht sehr wahrscheinlich zu sein, dass dies so kommen wird.
Denn mach es nicht unnötigerweise komplex, wenn es auch einfacher
geht.

 

[ETI1120]

Die Darstellung des Zen 5 CCX
https://pics.computerbase.de/1/1/3/3/8/5-61c94cef483d86c9/13-1080.6a4ba483.png

Im Zen 5 Kern hat AMD dieBandbreite massiv erhöht, aber eben nicht von CCD zum IOD, das meinte ich mit passt auch zum Zen 5

Darstellung des Granite Ridge SOC
https://pics.computerbase.de/1/1/3/3/8/5-61c94cef483d86c9/18-1080.347c8e0f.png

Leider sind hier die datenraten nicht eingetragen und die Entsprechung der Darstellung des vorherigen Posts habe ich nicht gefunden.

Bei der Pressevorstellung von Zen 5 hat AMD diese Folie präsentiert:

https://pics.computerbase.de/1/1/3/3/8/5-61c94cef483d86c9/14-1080.485a70c5.png

Bitte den Abschnitt Futures wörtlich nehmen:

• Es wird CCX mit verschiedenen Größen geben
• Es wird homogene und hetreogene CCX geben
• AMD will den Bereich von Data Center bis Embedded abdecken

Wenn nur ein CCX auf einem CCD ist, ist der Designaufwand für das CCX ein sehr hoher Anteil des Designaufwands für das gesamte CCD. Deshalb verstehe ich diesen Abschnitt auch so, dass es mehr CCDs geben wird.

Ergänzung (30. November 2024)

Ich denke dass der low budget Bereich weiterhin mit 6 und 8 Kern Zen 5 Varianten abgedeckt werden.

Schau Dir einfach Mal an wie hoch der Anteil der 6 und 8 Kerner am Gesamtabsatz aktuell ist.

Was Du schreibst bedeutet im Klartext keinen Nachfolger des 9800X3D zu bringen.

 

[RKCPU]

Ich denke dass der low budget Bereich weiterhin mit 6 und 8 Kern Zen 5 Varianten abgedeckt werden.
...
Mögliche 8 Kern Zen 6 Varianten wären dann eh nur teildefekte CPU Chiplets die in einem überschaubaren Rahmen noch anfallen würden

Zen 5 (Refresh ?) in TSMC N4 (6 / 8 cores)
Zen 6 (12 core chiplet) in TSMC N3 (Medusa Point / Halo / Venice non high density / Ridge)
Zen 6 Venice (12 core chiplet up to 192 cores???) in TSMC N3
Zen 6 Venice (32 core high density chiplet up to 256 cores) in TSMC N2 / N3?

Wenn AMD dem Zen 6 je 1,5 MB L2 gäbe,
den Zen 6c aber beim Desktop in Modulbauweise ausführt (shared FPU 4-fach SMPT, L3-Cache)
dann wären gut 40 statt 32 MB L3, 15 MB statt 8 MB L2 und 10 Blöcke CPU vorhanden.

Der Zen 6c würde dann etwa schwächer bei der IPC, dafür aber am großen L3 angehängt.
6 statt 8 Zen 6 plus 1 statt 2 Module Zen 6c wären immer noch als 8-Core zu bezeichnen - Ryzen 10600,
6 statt 8 Zen 6 plus 2 Module Zen 6c dann als 10-Core ein Ryzen 10700,
8 Zen 6 plus 2 Module Zen 6c dann als 12-Core ein Ryzen 10800.

 

[ArrakisSand]

Schau Dir einfach Mal an wie hoch der Anteil der 6 und 8 Kerner am Gesamtabsatz aktuell ist.

Was Du schreibst bedeutet im Klartext keinen Nachfolger des 9800X3D zu bringen.

Das ist ja auch nur logisch wenn Intel und AMD nichts anderes als 6-8p Kerne anbieten.
Die zwei Chiplet Varianten mit 12 und 16 Kernern, von Intel gar nicht erst zu reden, sind da eher kontraproduktiv und bringen beim Gaming ihre PS nicht richtig auf die Strasse.
Ich bin überzeugt davon, dass sich ein one chiplet mit 12 oder 16 Kernen inkl. der zu erwartenden + 5-10% Gaming Performance (relativ zu den 8 Kernern) bereits heute, deutlich besser verkaufen würde.

Daher würde der 10800X3D, oder wie immer der heißen soll. Mit 12p Kernen den 9800X3D beerben und ein 10p 9700X3D währe wohl wahrscheinlich wenn sie wie gesagt auf ein 12 Core Chiplet setzten würden.
8p hätten somit im High-Performance-Gaming für Enthusiasten ein für alle Mal ausgedient.

 

[RKCPU]

Das ist ja auch nur logisch wenn Intel und AMD nichts anderes als 6-8p Kerne anbieten.
Die zwei Chiplet Varianten mit 12 und 16 Kernern, von Intel gar nicht erst zu reden, sind da eher kontraproduktiv und bringen beim Gaming ihre PS nicht richtig auf die Strasse.

Nun, AMD gibt ja schon bei kommenden APUs ein 4x Zen 5 plus 8x Zen 5c Design.

TSMC hat 3nm Variante die low power und Performance Cores gleichzeitig ermöglicht.
Ggf. Kann man die Zen 6c so mittig platzieren, dass die Kühlung sich für die Zen 6 verbessert.

 

[Limit]

Nur nochmal als Gedankenspiel: Zen 6 wird mit Sicherheit stärkere Kerne haben als Zen 5. Und wenn die Anzahl an Kernen dann um 50% erhöht wird, wird es auch mehr als 50% mehr Anfragen an den Cache geben. Den Cache unverändert zu lassen, wäre aus meiner Sicht daher gewagt. Und ob eine höhere Bandbreite alleine ausreicht, ist auch fraglich, da es neben der Bandbreite ja auch auf die Latenzen ankommt, die bei 50% mehr Kernen dann ebenfalls stärker ins Gewicht fallen.

Die optimale Cache-Größe hängt sehr viel stärker von der Software als von der Zahl der Kerne ab, zumindest solange alle Kerne am gleichen Task arbeiten. Deswegen braucht man bei mehr Kernen nicht zwangsläufig mehr Cache. Wenn die "heißen" Daten kleiner als der Cache oder deutlich größer als dieser sind, bringt es kaum was den Cache zu vergrößern. Man braucht also die "richtige" Größe für die jeweilige Software.

Aus meiner Sicht ist die Frage daher eher, für welchen Weg AMD sich entscheidet: 1 oder 2 CCX pro CCD. Und dann eben, wie groß der Cache wird. Ich würde es aber tatsächlich für gewagt halten, wenn sie den Cache nicht vergrößern.

Mehrere CCX macht für den Desktop-Bereich nicht so viel Sinn, einfach weil man stattdessen auch einfach Chiplets benutzen kann mit denen man für deutlich geringere Kosten verschiedene Varianten bringen kann. Mehrere CCX sehe ich eher bei monolithischen APUs, Konsolen-Chips und sonstigen spezielleren Anwendungen.

Im Zen 5 Kern hat AMD dieBandbreite massiv erhöht, aber eben nicht von CCD zum IOD, das meinte ich mit passt auch zum Zen 5

Mit Zen 5 hat AMD viel an der "Infrastruktur" gearbeitet. Jetzt müssen sie mit den nächsten Generationen dieses erhöhte Potential aber auch besser ausnutzen.

Ich finde AMD sollte im Desktop-Bereich mehr auf einen hybriden Ansatz setzen, z.B. bei den Dual-CCD CPUs ein CCD mit 3D-Cache und ein CCD den kompakten Kernen ausstatten, denn es gibt nicht viele Anwendungen, die sowohl viele Kerne, große Caches und hohe Taktraten brauchen.

 

[ETI1120]

Mit Zen 5 hat AMD viel an der "Infrastruktur" gearbeitet. Jetzt müssen sie mit den nächsten Generationen dieses erhöhte Potential aber auch besser ausnutzen.

Die Umbauarbeiten im Kern sind was die FPU und AVX-512 anbelangt weitgehend abgeschlossen. Mal schauen was AMD in Bezug auf die anderen Erweiterungen macht.

Was die Integerseite anbelangt, war Zen 5 nur ein erster Schritt. Hier stehen noch einige Änderungen an.

 

[RKCPU]

Die zwei Chiplet Varianten mit 12 und 16 Kernern, von Intel gar nicht erst zu reden, sind da eher kontraproduktiv und bringen beim Gaming ihre PS nicht richtig auf die Strasse.
Ich bin überzeugt davon, dass sich ein one chiplet mit 12 oder 16 Kernen inkl. der zu erwartenden + 5-10% Gaming Performance (relativ zu den 8 Kernern) bereits heute, deutlich besser verkaufen würde.

Sobald AMD den ganzen L3 nach unten verlegt - also beim X3D 2* SRAM Chips - würden im CPU-Chiplet Platz für min. 4* Zen 6c frei werden.
Also 'normale' CPU's mit 48 MByte L3, X3D dann 128 MByte oder 144 Mbyte L3-Cache.

Bei den APUs sind ja auch Gerüchte zu gestapelten L3 bekannt, dann wäre dort CPU und GPU Cache zusammen unten angebracht ?!

 

[ETI1120]

Sobald AMD den ganzen L3 nach unten verlegt - also beim X3D 2* SRAM Chips - würden im CPU-Chiplet Platz für min. 4* Zen 6c frei werden.

und wenn AMD L2 + L3 cache unten verlegt ist im CCD Platz für 16 classic Cores.

Bei den APUs sind ja auch Gerüchte zu gestapelten L3 bekannt, dann wäre dort CPU und GPU Cache zusammen unten angebracht ?!

Bei den APUs ist der Cache nicht das was Fläche kostet, es ist der uncore und die PHYs.

 

[RKCPU]

und wenn AMD L2 + L3 cache unten verlegt ist im CCD Platz für 16 classic Cores.

N3P nach N3E bietet Optimierungen für Zen 6 -Power und Zen 6c - Energy.
Die little-Cores können dann erstmals ihr Potential voll ausreizen.
Beim L2 setzt AMD vielleicht auf 4MB shared der Zen 6c Cores, beim Zen 6 dann auf 1 MB L2 je Core oder 2 MB je 2 Cores ?!
Darunter dann 48 MB SRAM L3.
Das thermische Budget des AM5 ist begrenzt, auch nur 128 Bit DDR5.

Beim EPIC wären 16 Zen 6 (3 nm) mit 8x shared L2 auf dem CPU Chiplet plus 64 MB SRAM (in 4 nm) unten doch denkbar?

 

[ETI1120]

N3P nach N3E bietet Optimierungen für Zen 6 -Power und Zen 6c - Energy.

Die little-Cores können dann erstmals ihr Potential voll ausreizen.

Was soll ihr volles Potential sein?

N3P bringt im Vergleich zu N3E 5 % mehr Performance bei gleicher Power oder 5 bis 10 % weniger Power bei gleicher Performance. Und zusätzlich ca. 4 % höhere Dichte.

Beim L2 setzt AMD vielleicht auf 4MB shared der Zen 6c Cores, beim Zen 6 dann auf 1 MB L2 je Core oder 2 MB je 2 Cores ?!

Wieso sollte AMD die Architektur so stark ändern?
Privater L2, geteilter L3 hat sich bewährt. Was sollte der Grund sein dies zu ändern?

Wenn AMD in der Lage sein sollte bei Zen 6 den L3 Cache komplett auf einen anderen Die zu verschieben, wieso nur den L3 Cache verschieben?

Darunter dann 48 MB SRAM L3.
Das thermische Budget des AM5 ist begrenzt, auch nur 128 Bit DDR5.

Bei der Power sollte N3P im Vergleich zum aktuellen N4P helfen.

DDR5 SDRAM mit 6000 MT/s sind bei Zen 4 wie auch bei Zen 5 der Sweetspot. Bei Zen 6 könnte der Sweetspot erheblich höher liegen.

Beim EPIC wären 16 Zen 6 (3 nm) mit 8x shared L2 auf dem CPU Chiplet plus 64 MB SRAM (in 4 nm) unten doch denkbar?

Wenn AMD in der Lage sein sollte das bisherige CCD auf mehrere Dies zu verteilen, ist sehr viel denkbar.

Bei Zen 6 den L2 Cache des classic Cores zu beschneiden, gehört IMO eher zu den unwahrscheinlichen Optionen.

 

[LamaMitHut]

Könnte man nicht gleich einen sehr großen geteilten L2 unter die Kerne platzieren, und sich den L3 ganz schenken?

 

[stefan92x]

Privater L2, geteilter L3 hat sich bewährt. Was sollte der Grund sein dies zu ändern?

Du hast völlig recht, das wird AMD nicht ändern. Vor allem gibt es keinen Grund, das zwischen den Standard- und den Dense-Cores unterschiedlich zu behandeln. Wenn AMD auf einen Shared L2 setzen sollte, dann wird das für die ganze Generation gelten. Aber ist natürlich derzeit nicht absehbar.

Wenn AMD in der Lage sein sollte bei Zen 6 den L3 Cache komplett auf einen anderen Die zu verschieben, wieso nur den L3 Cache verschieben?

Je nachdem, auf welche Prozesse man setzt und wie groß AMD den L3 macht, könnte das durchaus passen, dass der L3 ebenso groß ist wie die Kerne. Aber denkbar wäre bei so einem Setup sicher auch, den L2 mit in den Cache-Die zu packen, das wäre wahrscheinlich flächenmäßig noch besser ausbalanciert.

Könnte man nicht gleich einen sehr großen geteilten L2 unter die Kerne platzieren, und sich den L3 ganz schenken?

Kann man sicher. Ist aber zu langsam. Die Distanzen werden zu groß, damit die Signallaufzeiten und dementsprechend die Latenzen beim Zugriff. Es gibt einen Chip, der im Prinzip so aufgebaut ist, aber da ist lokaler L2 zu einem "virtuellen L3" verbunden - sehr großer geteilter L2 ist auch das nicht: https://www.computerbase.de/news/pr...l2-cache-erschaffen-einen-monster-chip.89347/