Zen 6 (Morpheus-Kerne, 2/3 nm, H2/2025)

[Zossel]

Bisher war es halt auch eine Verschwendung dass die CCDs nur mit xGMI narrow angebunden waren und somit eigentlich die doppelte Bandbreite zum IO hätten haben können. Die 4CCD Epycs haben afaik GMI Wide. Die Bergamo 128C und Turin Dense 192C CPUs nutzen trotz der mehr Kerne ein ganzes Viertel der im I/O vorhandenen xGMI Links har nicht. Die haben nur die Halbe I/O Bandbreite pro Core. Das sind also 12x GMI CPUs während die CPUs mit den kleineren CCDs 16x xGMI links nutzen.

Es macht schon Sinn bei den normalen und den Dense Kernen auf die gleiche CCD Anzahl zu gehen damit man nicht Bandbreite verschwendet und damit Teile des IO DIEs.

Designkosten (Invest) vs. Stückzahl.

[Skysnake]

Also Faktor 2 ist das pro Core definitiv nicht. Wenn du nur einen Core nutzt ist die Bandbreite wenn ich mich recht erinnere gleich.

Was man aber sieht sind zwei Sachen. Die Peak Bandbreite ist bei gleichem Speicher mit den großen CPUs höher.

Wenn man aber die CCDs die sich eine NUMA Domain teilen ungleichmäßig nutzt, dann sackt die Performance deutlich ab. Es ist scheinbar eien fair share bzw round Robin auf CCD Ebene implementiert aber nicht auf Core Ebene.

[basix]

Wenn die jetzt direkter angebunden werden wundert mich das überhaupt nicht, dass es nur noch 8 Verbindungen gibt.

Die direktere Verbindung schränkt die Anordnung der CCDs natürlich ein. Da muss AMD anders skalieren:
1.) Grössere CCD -> 32C CCD
2.) IOD als Chiplet -> Werden wir noch sehen

Ultimativ sehe ich Punkt 2.) verwandt mit Intels Clearwater Forest Chiplet-Anordnung:
- Längliches CCD-IOD, wo man seitlich die CCDs anbinden kann. Bei Clearwater Forest sind in diesen länglichen Chiplets die CPU Cores mit drin. Bei AMD kämen die via CCD-Chiplets aussen dran
- Mehrere CCD-IODs aufgereht -> Skalierung der CCDs und entsprechend der Anzahl CPU-Cores
- IO-DDR (DDR, PCIe) kommt aussen dran, mit separaten Chiplets
- IO-v2: Alternativ kann es noch ein zentrales IOD geben (mittig zwischen den CCD-IOD), welches ein paar zentrale/gemeinsame Plattform Sachen wie Ethernet, USB, einen Teil PCIe usw. integriert hat.
https://www.servethehome.com/wp-content/uploads/2024/09/Intel-Xeon-Clearwater-Forest.jpg

Max. 96 Cores sind für die "High Frequency" Varianten zudem auch ausreichend. Zen 6c mit 32C CCD bietet nämlich neu ebenfalls 4MB/Core L3$. Da hat man keinen Nachteil mehr. Bei 128C+ kannst du die Cores eh nicht mit 5 GHz betreiben. AMD Epyc 9755 geht auf 4.1 GHz und Zen 5c auf 3.7 GHz. Das dürfte Zen 6c schaffen oder sogar übertreffen. N2 kommt mit ca. 1.15...1.2x mehr Performance wie N4P, dazu NanoFlex/FinFlex und dazu natürlich die überarbeitete Zen 6 Architektur. Wenn Zen 6c sagen wir mal 4.5 GHz schafft, wäre das voll OK. Das wären +10% Takt für das 128C Modell und +20% für Zen 6c zu 5c, was auf Takt-Ebene ein ähnlicher Sprung wie Zen 4 zu Zen 5 wäre.

[davidzo]

Designkosten (Invest) vs. Stückzahl.

Inwiefern? Der IO-DIe bleibt da ja gleich, ich nehme an man nutzt jetzt eben durch die bank GMI-wide, also 16x links, zwei per DIE.

Also Faktor 2 ist das pro Core definitiv nicht.
So schwer ist das doch nicht zu rechnen, oder? :rolleyes:

Bei Turin sind 8C CCDs mit jeweils einem GMI Link angebunden.
Bei Turin Dense sind 16C CCDs mit jeweils einem GMI link angebunden. Auf die Anzahl an Cores aufgeteilt hat ein Turin classic Core also die doppelte i/o Bandbreite.

Beim 9575F und einigen anderen Epcs mit 64C und weniger (8x CCDs und weniger) sind die sogar mit jeweils 2x GMI Links angebunden. AMD sagt da zwar nicht viel zu, aber diese CPUs haben die doppelte i/o Bandbreite pro Core im Vergleich zu 16CCD Turin classics, bzw. sogar die Vierfache im Vergleich zu Turin dense. Das kann man in hoch vektorisiertem Code auch sehen. Wenn ausschließlich die Bandbreite limitiert sollte ein 64Kern Epyc genau so schnell sein wie ein 128C bzw. schneller als ein 192Kerner.

Während die Speicherbandbreite beim 9950x bei ca. 70gb/s gipfelt, schafft ein Single Epyc 9575F CCD mal eben 140gb/s. Ja, das ist das vierfache pro Kern. Liegt daran dass die GMI Links im Desktop Package nut 16B wide sind, im Server allerdings 32b und bis 64C eben doppelt vorhanden.


Wenn du nur einen Core nutzt ist die Bandbreite wenn ich mich recht erinnere gleich. Und singlecore workloads sind genau wie aussagekräftig für eine cloud native Scale-out Server CPU?



Ultimativ sehe ich Punkt 2.) verwandt mit Intels Clearwater Forest Chiplet-Anordnung:
- Längliches CCD-IOD, wo man seitlich die CCDs anbinden kann. Bei Clearwater Forest sind in diesen länglichen Chiplets die CPU Cores mit drin. Bei AMD kämen die via CCD-Chiplets aussen dran
- Mehrere CCD-IODs aufgereht -> Skalierung der CCDs und entsprechend der Anzahl CPU-Cores
- IO-DDR (DDR, PCIe) kommt aussen dran, mit separaten Chiplets

Die Gerüchte sprechen ja auch von 2x IO-DIEs die jeweils vier CCDs ansteuern und mittig direkt zusammengeklebt werden.

Allerdings mus sich dir bei Clearwater forest widersprechen:
1. Die DRAM Controller sind nicht in den I/O DIes sondern in den Compute DIEs.
2. Durch multiple IODs wird es non-uniformen memory access geben, also far memory und near memory mit unterschiedlichen Latenzen. Wieviel extra Komplexität das mit sich bringt wenn man die maximale Leistung extrahieren möchte man ja bei Sapphire Rapids gesehen.

Clearwater Forest hat theoretisch bessere Speicherlatenzen zum lokalen Dram Controller als wenn dieser Remote über ein IOD angebunden wäre. Allerdings hat es Intel in der Vergangenheit auch schon fertig gebracht trotz on-DIE Speichercontrollern und EMIB Chipletverbund schlechtere Latenzen zu bringen als AMDs Infinity Fabric on package links in simplen organischen Packages. Es würde mich nicht wundern wenn wie schon bei Granite rapids die internen Speichercontroller gerademal knapp an die Latenz von AMDs fabric angebundene IO/DIE memorycontroller herankommen.

[Nightspider]

MLID hatte ein mockup erstellt:

https://www.guru3d.com/data/publish/224/2c00e214be8710bc79e8765bf0f638108c5b6a/1732866990_guru3d.webp

[Skysnake]

@davidzo das ist auf ganz vielen Ebenen nicht richtig. Das ist mir am Handy jetzt aber zu nervig das auszudröseln.

Single Core Performance ist aber definitiv sehr relevant bei parallelen Workloads so lange diese nicht Embarrassing parallel sind. Einfach mal Amdahls law anschauen. Und ja Gustafson rettet uns den Arsch aber die grundsätzliche Problematik bleibt bestehen.

Und hohe Single Thread Leistung hilft einem da einfach weil diese höher ist als die parallele Performance aufgrund der Power Limits

[davidzo]

@davidzo das ist auf ganz vielen Ebenen nicht richtig. Das ist mir am Handy jetzt aber zu nervig das auszudröseln.

Single Core Performance ist aber definitiv sehr relevant bei parallelen Workloads so lange diese nicht Embarrassing parallel sind. Einfach mal Amdahls law anschauen. Und ja Gustafson rettet uns den Arsch aber die grundsätzliche Problematik bleibt bestehen.

Und hohe Single Thread Leistung hilft einem da einfach weil diese höher ist als die parallele Performance aufgrund der Power Limits

Wir gucken da immer zu sehr als Gamer drauf.

Ich gehe davon aus dass die meisten EPYC 9965 in Cloudinstanzen aufgeteilt werden die im Durchschnitt weniger als 8 Kerne pro Instanz haben. Insofern teilen sich hier Kunden durchaus ein CCD. Die Diskussion um den einen Workload der 384 Threads perfekt auslastet erübrigt sich wenn wir in Wirklichkeit 192 logische Maschinen vor uns haben, die alle eine mit SLAs garantierte Leistung bringen müssen, egal was die anderen Kunden hier drauf gerade machen.

Im übrigen war mein Post gar nicht über die Relevanz von Singlethreaded Leistung, sondenr nur darüber dass AMD bisher bei Bergamo und Turin Dense unnötig Bandbreitenpotential verschenkt welches die CPUs für manche Einsatzzwecke ineffizient macht. Das wird sich bei Zen6 nicht ändern, da die Kernanzahl gleichermaßen steigt wie die Anbindung der CCDs, aber immerhin hat man diesmal weniger dead silicon im IOD bei der Top Corecount SKU, was bisher etwas merkwürdig war.

Und Cheese and chips hat ja auch nachmessen können wieviel mehr Bandbreite der 9575F hat als andere Epycs.

Klar ist es der Mehrzahl der Anwendungen egal, sonst würde man wohl kaum das Desktop Flaggschiff mit so einer mickrigen CCD-Anbindung ausliefern. Aber dass es Anwendungen gibt die Bandbreitenlimitiert sind, ist unbestreitbar. Ich würde sogar vermuten dass gerade LLMs auf die Speicherbandbreite voll ansprechen. Und bevor jemand sagt das macht man doch auf GPUs: Nein, viel Entwicklung und Testing wird auch auf CPUs gemacht. Das ist immer noch die billigste Methode um an genug Ram zu kommen um die extragroßen Modelle überhaupt mal probelaufen lassen zu können.

[Nightspider]

. Das wird sich bei Zen6 nicht ändern, da die Kernanzahl gleichermaßen steigt wie die Anbindung der CCDs,

Wenn die CCDs via Infinity FanOut Links angebunden werden wird sich eine Menge ändern.

[davidzo]

Wenn die CCDs via Infinity FanOut Links angebunden werden wird sich eine Menge ändern.

Du liest anscheinend sehr selektiv. Ich habe nicht Zen5 und Zen6 verglichen sondern Zen6 und Zen6C. Der Umstand dass Venice Dense wesentlich weniger I/O Bandbreite pro Core aufweist als Venice classic, genau wie zuvor schon Bergamo und Turin, wird sich auch mit einem physisch anderen Fabric nicht ändern. Entscheidend ist wieviele Cores auf einen Link kommen. Und das sind bei Venice Dense eben fast dreimal soviele.

[HOT]

MMn wird das aber nur ein großes, längliches IOD und die 32c-CCDs werden einfach in die Länge gehen, weil das nur ein CCX ist. MMn hängen da auch alle Chips direkt zusammen ohne Lücken dazwischen. Die c-Variante ist nur ca. 25% breiter und dürfte fast die gesamte innere Trägerfläche abdecken denke ich.

[Skysnake]

Wir gucken da immer zu sehr als Gamer drauf.

Bitte nicht von dir auf andere schließen. Ich gehe rein nach Server und da vorzugsweise auch noch nach HPC.


Ich gehe davon aus dass die meisten EPYC 9965 in Cloudinstanzen aufgeteilt werden die im Durchschnitt weniger als 8 Kerne pro Instanz haben. Insofern teilen sich hier Kunden durchaus ein CCD. Die Diskussion um den einen Workload der 384 Threads perfekt auslastet erübrigt sich wenn wir in Wirklichkeit 192 logische Maschinen vor uns haben, die alle eine mit SLAs garantierte Leistung bringen müssen, egal was die anderen Kunden hier drauf gerade machen.

Ja, da wird wahrscheinlich wirklich das Meiste in der Cloud liegen. Aber wie gesagt. Ich gehe davon aus, dass das Verhalten wie bei Genoa schon unschön ist. Zumindest konnte mir AMD bis jetzt nicht sagen, dass das anders wäre.

Und das wäre dann schon ein ziemlich bescheidenes Verhalten. Wobei in der Cloud eventuell die QoS Features von den neuen AMDs bezüglich Memory Bandbreite benutzt werden. Sicher sagen kann ich das aber nicht. Unter RedHat 8 ist der Support von den Features noch bescheiden.... RedHat 9 kann ich noch nicht wirklich sagen.


Im übrigen war mein Post gar nicht über die Relevanz von Singlethreaded Leistung, sondenr nur darüber dass AMD bisher bei Bergamo und Turin Dense unnötig Bandbreitenpotential verschenkt welches die CPUs für manche Einsatzzwecke ineffizient macht. Das wird sich bei Zen6 nicht ändern, da die Kernanzahl gleichermaßen steigt wie die Anbindung der CCDs, aber immerhin hat man diesmal weniger dead silicon im IOD bei der Top Corecount SKU, was bisher etwas merkwürdig war.

Die Anbindung ist schmäler pro CCD, aber du kannst trotzdem den Memory voll auslasten wenn du ihn gleichmäßig belastest. Von daher wenn du einfach nur maximal aggregierte Speicherbandbreite willst dann nimmst du die großen CPUs. Wenn du aber nicht gleichmäßig innerhalb eines NUMA nodes belasten kannst, dann können die kleineren besser sein mit nur einem CCD pro NUMA node.

Ich bin da auch schon länger mit AMD in der Diskussion wegen. Mir gefällt das Verhalten nämlich überhaupt nicht. Software Entwickler, Admins und erst recht User erwarten das Verhalten nicht, was dann am Ende zu Problemen mit echter Workload führt.


Und Cheese and chips hat ja auch nachmessen können wieviel mehr Bandbreite der 9575F hat als andere Epycs.

Die takten halt auch höher. Du musst da aber sehr sehr sehr aufpassen was du genau vergleichst. Max Bandbreite mit einem Core pro CCD, max Bandbreite wenn man alle Cores nutzt oder Max Bandbreite pro CCD bei X Cores.



Klar ist es der Mehrzahl der Anwendungen egal, sonst würde man wohl kaum das Desktop Flaggschiff mit so einer mickrigen CCD-Anbindung ausliefern. Aber dass es Anwendungen gibt die Bandbreitenlimitiert sind, ist unbestreitbar. Ich würde sogar vermuten dass gerade LLMs auf die Speicherbandbreite voll ansprechen. Und bevor jemand sagt das macht man doch auf GPUs: Nein, viel Entwicklung und Testing wird auch auf CPUs gemacht. Das ist immer noch die billigste Methode um an genug Ram zu kommen um die extragroßen Modelle überhaupt mal probelaufen lassen zu können.
Ich weiß jetzt nicht genau welche Daten wann wo wie noch unter NDA stehen, aber interessant ist an sich die Frage wie viele Cores brauchst du um das Memory Interface zu saturieren und musst du die speziell verteilen oder nicht.

Und das liefert teils sehr interessante Ergebnisse.

[Nightspider]

Der Umstand dass Venice Dense wesentlich weniger I/O Bandbreite pro Core aufweist als Venice classic, genau wie zuvor schon Bergamo und Turin, wird sich auch mit einem physisch anderen Fabric nicht ändern. Entscheidend ist wieviele Cores auf einen Link kommen. Und das sind bei Venice Dense eben fast dreimal soviele.

Woher weißt du denn wie genau Venice und Venice Dense angebunden sind?

AMD gab bei N31 damals an das man mit Infinity FanOut Links knapp 10x so hohe Bandbreitendichte erreicht.

Die Thematik könnte sich damit eben massiv entschärfen.

[davidzo]

Woher weißt du denn wie genau Venice und Venice Dense angebunden sind?

AMD gab bei N31 damals an das man mit Infinity FanOut Links knapp 10x so hohe Bandbreitendichte erreicht.

Die Thematik könnte sich damit eben massiv entschärfen.

Du hast es immer noch nicht kapiert.
Ich weiß nicht wie sie angebunden sind.

Aber wenn die Gerüchte und Screenshots aus dem Baidu Forum stimmen sind es jeweils 8x CCDs. Die Relation zwischen beiden ist also klar, denn classic soll ja 12C per CCD haben und dense 32C, aber beide mit der höchstwahrscheinlich gleichen Bandbreite zum IOD.

[Nightspider]

beide mit der höchstwahrscheinlich gleichen Bandbreite zum IOD.

Naja, wir werden sehen.

[Nightspider]

Es ist noch etwas zu früh für einen Zen 7 Thread aber MLID hat gerade gedropt das Zen 7 3D Cores bekommt mit dem Cache auf den anderen Layern.

https://i.ibb.co/VpDtG5cT/Zen7.jpg

Diese Woche kommt wohl noch ein extra Video dazu.

[MSABK]

Angeblich soll amd für Microsoft eine ARM CPU entwickeln. Soll angeblich in die Surface Geräte kommen.

https://www.computerbase.de/news/prozessoren/sound-wave-amd-soll-an-einer-arm-cpu-fuer-ein-2026er-surface-arbeiten.92636/

[basix]

Du, wieso nicht. Wenn man die Engineering-Manpower hat, kann man das machen. Grundsätzlich müssen sie "nur" Medusa Point nehmen und das Zen 6 CCD gegen ein CCD mit X930/935 Cluster ersetzen. Fertig ist die ARM CPU.

An einen monolithischen SoC glaube ich irgendwie nicht. Zu viel Aufwand. Medusa Point soll aber noch ein paar Low Power Zen 6 Cores mitbringen. Die kann man inkl. ARM CCD wohl nicht verwenden. Evtl. sind gleich noch 4x Cortex A730/735 auf dem IOD drauf, die sollten klein sein ;)

Dann wäre es irgendwie sowas:
- Medusa Point = 12C Zen 6 CCD + 4C LP-Zen6
- Medusa ARM = 8...12C X930/935 + 4C A730/735

[MSABK]

Manche Dinge verstehe ich nicht bei AMD. Auf der einen Seite sind sie relativ klein aber bringen einfach mal ein Strix Halo welches in überschaubaren Mengen verkauft wird. Jetzt soll auch was mit ARM kommen und das wird auch keine Stückzahlen bringen.

[basix]

Ich glaube bei diesem Projekt geht es mehr um Risiko-Minimierung und TAM-Absicherung. Wer weiss, wie sich ARM vs. x86 in Zukunft entwickeln wird. Hat man ein Produkt, hält man den Fuss in der Tür und wird nicht so schnell abgehängt (zumindest in einigen Marktbereichen).

AMD hat hier sogar eine sehr gute Position, da sie mit Chiplets sehr flexibel arbeiten können. Macht AMD ein ARM-CCD, könnten sie es auch in ihrer Desktop- und Server-Sparte einsetzen, falls sie wollten.

[HOT]

Zu Zen7:
- Der L3$ verschwindet jetzt also finally vom CCD.
- Das Dense-CCD ist eine Matrix, kein Ringbus mehr
- Das Dense-CCD hat 33 Cores (3x11), das Cache-Die hat 33x7MB L3$(alles total krumme Zahlen, aber man muss es bauen, wie es passt :D)
- Ein Dense-Core hat 2MB L2$
- Die CCDs sind TSMCs A14 mit C3D
- Die Cache-Chiplets scheinen N4C zu sein
- Basisarchitektur ist erstmals der Dense-Core, nicht mehr der Classic Core, wie bis zu Zen6
- Der Classic-Core scheint alles einzusparen (Powergating etc), was Takt verhindert, der Ansatz ist also genau diametral zu jetzt
- Den Dense-Core gibt es in 2 Varianten, einer mit wenig Takt und IPC und einen mit voller IPC und mehr Takt.

Leider ist nichts über das Classic-CCD bekannt bisher. Aber man kann sicherlich davon ausgehen, dass der Kern größer ist und der darunter gestackt Cache sicherlich auch (auch mehr Lagen sicherlich). Ob man auch hier beim Ringbus bleibt oder auch hier die Topologie ändert ist unmöglich vorherzusagen.

[Nightspider]

IPC Uplift 15-25% (target is "above 20% in SpecINT17")

Die Classic Cores sollen natürlich auch höher takten als die Dense Cores.

[bbott]

IPC Uplift 15-25% (target is "above 20% in SpecINT17")

Die Classic Cores sollen natürlich auch höher takten als die Dense Cores.
Zen 6? Quelle? Wäre wieder mehr als Zen 5, und mehr als die bisher spekulieren 10-15%.

[Nightspider]

Zen 7

[Der_Korken]

Den L3 vollständig auf eine zweite Ebene auszulagern und quasi von überall aus zugänglich zu machen, hat sicherlich enorme Vorteile beim Layout des Dies und dessen Latenzen. Die Kerne müssen nicht mehr so länglich sein, da sie nicht mehr alle an einem "Cache-Flur" in der Mitte des Dies andocken müssen. Stattdessen kann man die Kerne quadratisch machen und der L2 kann überall liegen, theoretisch auch in der Mitte oder in räumlich voneinander getrennten Slices. Die Vias auf den L3 platziert man dann einfach genau daneben.

[Nightspider]

Jepp, die Kerne rücken enger zusammen. Dazu dann noch die deutlich höhere Transistordichte durch A14.

Die Frage ist wie viel Kerne das Classic Core Chiplet bekommen wird. 12 wie bei Zen6? 16?
Eine krumme Zahl? 12 könnten auf jeden Fall schon zu klein werden ohne L3 bei A14.

16 relativ eng gepackte Classic Cores ohne L3 auf dem Chip würde 2027/28 durchaus drin sein, zumal Intel auch weiter pusht mit der Kernzahl.
Die Cache Chiplets wird man wahrscheinlich so oder so zwei mal designen müssen für Dense und Classic.

Mit Zen 6 und Zen 7 werden das in den kommenden ~3 Jahren riesige Sprünge werden.

Zen 6
+10% Takt
+10% IPC oder mehr
+50% L3
+50% Kerne

Zen 7
+15-25% IPC
+100% L2
+nochmal mehr L3
+eventuell 33% mehr Kerne (bei den Classic Core Chiplet)

Könnte zusammen so ein Sprung sein wie zwischen Zen 2 und Zen 5, auf jeden Fall bei Multithreading.

[latiose88]

Zen 6 ist ne krasse Sache, ja gut das ich zu am5 ryzen wechsle. Das hätte auch einiges mehr gedauert bis mal threadripper Zen 5 und später Zen 6 kommen werden und da wird technisch immer ryzen vorne sein.
Ist zwar unter diesen Umständen klar das durch die mehr an Kerne eigentlich threadripper vorne ist, nur wenn man nicht ganz von mehr Kerne profitiert oder die Anwendung gut bis sehr gut von takt profitiert dann sieht es anderst aus. Zen 5 9950x mag zwar nicht den 7960x überholen aber spätestens Zen 6 mit mehr Kernen sieht es anderst aus. 2 Generation weiter, mehr kerne und so, das wäre eng gewesen. nächstes Jahr kommt ja schon Zen 6. Klar irgendwann geht nix mehr. 2 Generation weiter, gleiche Anzahl an Kernen, also 24 vs 24 Kerner also ryzen vs threadripper, da ist klar wer gewinnt, nämlich ryzen.
Nur wer mehr als nur Kerne braucht fährt noch mit threadripper besser.
auf den Zen 6 schiele ich schon obwohl ich gerade erst auf 9950x wechsle. Der zockel ist cool.

[basix]

Was ich bei der Zen 7 Speku interessant finde:
- 2MB L2$ pro Core
- 7MB L3$ pro Core
- Bei einem allfälligen V-Cache Modell wohl 2*7MB L3$ pro Core
- 33C Chiplets vermutlich 3x11 angeordnet (anhand des leaked Schaubildes)
- 15C Chiplets für Consumer in 3x5 Anordnung? Mehr Cache pro Core, da die Cores grösser sein könnten? z.B. 10 MByte/Core?
- 3D-Core: L1/L2-Cache könnten mittig im Core angeordnet sein, was die Zugriffswege verkürzen würde

[horn 12]

Wann kommt Zen 6 laut Neuesten Gerüchten bitte
Frühjahr 2026 bis Sommer 2026 in etwa ?

[basix]

H2/2026 ist im Gespräch. Vermutet wird Q3/2026 oder eher Anfang Q3.

[HOT]

Was ich bei der Zen 7 Speku interessant finde:
- 2MB L2$ pro Core
- 7MB L3$ pro Core
- Bei einem allfälligen V-Cache Modell wohl 2*7MB L3$ pro Core
- 33C Chiplets vermutlich 3x11 angeordnet (anhand des leaked Schaubildes)
- 15C Chiplets für Consumer in 3x5 Anordnung? Mehr Cache pro Core, da die Cores grösser sein könnten? z.B. 10 MByte/Core?
- 3D-Core: L1/L2-Cache könnten mittig im Core angeordnet sein, was die Zugriffswege verkürzen würde

Ich bezweifle, dass Consumer 15 Kerne bekommen, das wird nach wie vor 12 Kern-Ringbus sein, das hat zuviele Vorteile. Nur das dense-CCD geht mMn nach von 32 Kern-Ringbus (Zen6) auf 33 Kern-Mesh (Zen7). Die 7MB werden deshalb zustande kommen, weil die 7MB in N4 genauso groß sein werden, wie ein dense-Kern+L2$+IO in A14 C3D. Classic-Kerne werden ganz andere L3$-Größen abbekommen. 3D-Kerne nennen die das Ding eh nur deshalb, weil der L3$ obligatorisch gestackt wird, vielleicht auch in 3 zusätzlichen Lagen.

Wann kommt Zen 6 laut Neuesten Gerüchten bitte
Frühjahr 2026 bis Sommer 2026 in etwa ?

Die sind wieder alle viel zu optimistisch. Zen6 mMn Ende 26 und Zen7 Ende 28. Vorher wird das nix.

[horn 12]

H2/2026 ist im Gespräch. Vermutet wird Q3/2026 oder eher Anfang Q3.

Also in ca. frühestens 14 Monaten
Ob dies mein AM4 5800 X3D mit 9070XT noch durchhält mit Dell Bildschirm 4K 3225QF
Müsste aber gehen :-)

[basix]

Interessant:
https://x.com/9550pro/status/1923255707173871868
Medusa Point 1
R5/R7=4C+4D+2LP+8CU RDNA 3.5+
R9=12C CCD+4C+4D+2LP+8CU RDNA 3.5+

APU=IOD👀

Somit wäre die Low-Cost APU das IOD und die Highend Modelle wären IOD + CCD? Scheint mir sinnvoll zu sein. Total bis zu 20C auf R9 (ohne LP Cores) ist auch massiv. Dass es nur 8CU für die iGPU sind ist schade, aber Strix Point zieht nur wenig Vorteil aus 16CU. Schön wäre allerding RDNA4 und nicht RDNA3+

[Der_Korken]

Klingt nach einem Scheduling-Alptraum:
- LP-Kerne
- Dense-Kerne
- Classic-Kerne mit wenig L3 (im IOD)
- Classic-Kerne mit viel L3 (im CCD)

Dazu noch drei oder vier (je nachdem, ob die 4+4 im IOD an einem L3 hängen oder nicht) Cluster, auf die sich die Kerne aufteilen und das ganze jeweils noch mit SMT :freak:. Sieht mir völlig overengineered aus. Ich würde in der Konstellation als erstes die Dense-Cores rauswerfen und stattdessen 8 normale Kerne ins IOD packen, alle an einem L3. Die minimale Flächenersparnis der 4 geschrumpften Kerne macht niemals den Entwicklungs- und Scheduling-Aufwand wett, den sie nach sich ziehen. Abgesehn davon fand ich die Perf/mm² und Perf/W der Dense-Cores jetzt auch nicht so überragend. In einem Epyc, der fast nur aus Cores besteht, kann man das machen, aber in APUs nehmen die Cores neben iGPU, NPU, DisplayEngine, IMC und PCIe/USB/DDR-PHYs nur einen Bruchteil der Fläche ein.

[OgrEGT]

Wäre es denkbar dass die unterschiedlichen Kerne mehr sequentiell genutzt werden je nach Lastzustand, so dass gar nicht über alle verschiedenen Kerne verteilt werden muss?

niedrige Last -> nur LP an - Dense und Classic Cores aus
mittlere Last -> Dense Cores übernehmen - LP und Classic Cores aus
hohe Last -> Classic Cores übernehmen (entweder nur IOD oder alle) - LP und Dense Cores aus

[Der_Korken]

Dann wäre das ja eine noch größere Diespace-Verschwendung, weill ich dann z.B. statt 4+4 (Classic+Dense) auf dem IOD einfach bei gleicher oder weniger Fläche 6+0 verbauen könnte und das immer schneller wäre als 4+4. Dense Cores haben für mich, so wie AMD sie designed hat, nur zwei Anwendungsfälle: Hintergrundlast, um Strom gegenüber einem Classic Core zu sparen oder als MT-Boost, wo ich so viele kleine Kerne auf meinen Chip quetsche wie möglich. Für Ersteres hätte man aber schon die LP-Cores und für Zweiteres sind es viele zu wenig Dense-Cores als dass es einen Unterschied macht.

Und wie gesagt: Im Gegensatz zu Intel, Apple und Qualcomm nutzt AMD auch noch SMT, was die Anzahl an "Kernsorten" quasi nochmal verdoppelt.

[HOT]

Interessant:
https://x.com/9550pro/status/1923255707173871868


Somit wäre die Low-Cost APU das IOD und die Highend Modelle wären IOD + CCD? Scheint mir sinnvoll zu sein. Total bis zu 20C auf R9 (ohne LP Cores) ist auch massiv. Dass es nur 8CU für die iGPU sind ist schade, aber Strix Point zieht nur wenig Vorteil aus 16CU. Schön wäre allerding RDNA4 und nicht RDNA3+

Na ob das RDNA3.5 wird glaub ich nicht, wenn die Zen6-CPU RDNA4 bekommt.

Der_Korken
Wieso Scheduling-Alptraum? Ist doch Unsinn. Dense und Classic haben exakt die gleiche IPC, nur die LP sind langsamer und nur Zen5.

[KarlKastor]

Dann wäre das ja eine noch größere Diespace-Verschwendung, weill ich dann z.B. statt 4+4 (Classic+Dense) auf dem IOD einfach bei gleicher oder weniger Fläche 6+0 verbauen könnte und das immer schneller wäre als 4+4.
Warum sollten das so sein? Bei 15-25 W TDP takten die 8 Kerne eh nicht höher als die Dense Kerne mitmachen. Da sind 6 Kerne nie im Leben schneller.

[KarlKastor]

Der_Korken
Wieso Scheduling-Alptraum? Ist doch Unsinn. Dense und Classic haben exakt die gleiche IPC, nur die LP sind langsamer und nur Zen5. hat er sich geschrieben warum.
Die Classic takten schneller. Also muss schon entschieden welche Kerne bei wenigen Threads zum Einsatz kommen.
Zudem kann es durchaus Unterschiede beim Cache kommen zwischen Dense, Classic und Chiplet Classic.

[HOT]

Toll, zuerst die Classic, sekundär die Dense und die LP nur im Idle, da ist kein Alptraum. Wenn du unterschiedliche Kerne hast sieht das anders aus, aber das sind im Falle von Medusa 1 mono 8 Big Cores und 2 little für idle.

[basix]

Mal spekuliert:

4C Classic + 4C Dense auf dem IOD sind ein einzelnes CCX
2C LP könnten separat und allenfalls noch etwas zusätzlich runtergestutzt (Core intern) sein. Sie könnten aber auch als 4C + 4C + 2C in ein einzelnes CCX integriert sein. Ich tippe auf genau das. Dann ist das Scheduling "easy". Im einfachsten Fall sind die LP Cores identisch mit den Dense Cores, aber einfach im Takt begrenzt. Aber AMD könnte hier natürlich noch weiter für LP optimieren. Da die LP-Cores ins CCX integriert sind, reichen 2C völlig aus.


|CCD Classic|IOD Classic|IOD Dense|IOD Dense LP
Anzahl Cores|12|4|4|2
L2$/Core|1MB|1MB|1MB|0.5...1MB
L3$/Core|4|2|2|2
IPC|1.0|1.0|1.0|0.8...1.0
Max. Takt|6.0 GHz|5.4 GHz|4.5 GHz|3.0 GHz
AVX512|Full (evtl. auf Half gestutzt)|Half|Half|Half or Quarter?


Scheduling Idee:
|Anwendungen
IOD Dense LP|Background-Tasks, Dokument-Scrolling, Web-Scrolling, File-Explorer Zeugs, Media Playback (Youtube, Spotify, lokal gespeicherte Medien)
IOD Dense|Web-Browsing, Dokumente öffnen, Video Conferencing
IOD Classic|Enhanced Web-Browsing usw., bursty Workloads
CCD Classic|Anwendungen mit hoher MT-Last und Peak-ST Anforderungen. Allenfalls hohe AVX512 Last, falls man Full-Rate beibehalten sollte (unwahrscheinlich)


Schlussendlich muss die CPU die Cores einfach rangieren. Schnellste zu langsamsten Cores. Das gibt es aufgrund der Boost Mechanismen bereits. Scheduling auf 2x unterschiedliche CCX oder Core Cluster ebenfalls (siehe Strix Point, alle Intel CPUs mit E-Cores). Das Betriebssystem kann anhand diesem Ranking, den Anforderungen des ausgeführten Programms und den Energiespareinstellungen entscheiden, wohin die Ausführung verschoben wird. Zwischen den zwei CCX gibt es eine Zusatzanforderung, dass man nur bei Peak Performance Anfrage aufs externe CCD auslagert. Das wird sicher die Knacknuss sein, aber ein Fehl-Scheduling aufs IOD-CCX wäre nicht so tragisch, da nur 10-15% weniger Takt. Deswegen wäre ein eher konservatives Scheduling "vorzugsweise IOD-CCX" am sinnvollsten.

Die LP-Cores sind in dem ganzen Konstrukt einfach die Bottom-Feeder. Da der Takt auf tiefe ~3 GHz begrenzt ist, läuft auch der Cache und der ganze Rest des Fabrics auch auf stark reduziertem Takt. Deswegen bleibt das CCX sehr effizient, auch wenn mal der ganze 20MB L3-Cache aufgeweckt werden sollte (Zen kann aber schon lange einzelne L3-Cache-Segmente power/clock-gaten).

Scheduling auf verschiedene Cores ist eigentlich eine gelöste Sache. Intel hat je nach CPU 2-3x verschiedene Core-Typen. ARM SoCs ebenfalls. Bei Zen 6 wären es im Idealfall sogar der grundsätzlich gleiche Core-Typ (gleiche IPC, gleiche Features) aber auf 2x CCX verteilt und verschiedene Maximaltaktraten. Aber auch das ist nichts Neues.

[Zossel]

Scheduling Idee:

Die Experten für Scheduler sind wieder unterwegs, haut doch mal eure Ideen in den Linux-Kernel und präsentiert die Ergebnisse.
Das geht mittlerweile per ebpf und online (ohne booten) ladbar und entladbar.

[basix]

Du weisst schon, dass das nur ein Beispiel vom Konzept war? ;)
Wie beschrieben, ist das Thema unterschiedliche Core Cluster und verschiedene Leistungsfähigkeit schon in verschiedenen CPUs sowie Betriebssystemen behandelt worden. Es gibt da also nicht wirklich was Neues zu erfinden, es wäre mehr eine Optimerung und Justierung des Bestehenden. Aber OK, wenn du nicht alles lesen und verstehen willst...

Und wenn du schon herablassend sein willst, kannst du gerne deine (Scheduling-) Weisheiten mit uns Teilen und hier deine wahre Grösse zur Schau stellen ;)

[Zossel]

Du weisst schon, dass das nur ein Beispiel vom Konzept war? ;)
Wie beschrieben, ist das Thema unterschiedliche Core Cluster und verschiedene Leistungsfähigkeit schon in verschiedenen CPUs sowie Betriebssystemen behandelt worden. Es gibt da also nicht wirklich was Neues zu erfinden, es wäre mehr eine Optimerung und Justierung des Bestehenden. Aber OK, wenn du nicht alles lesen und verstehen willst...

Und funzen tut das nur richtig auf Telefonen, weil das Nutzungsprofil dazu passt.
Bei General-purpose-Computern sieht das aber völlig anders aus.

[basix]

Ach, ein Telefon ist kein General Purpose Computer? Oder was ist dort das Problem, dass man es Idle auf A520 und aktiv auf X925 und A725 laufen lässt? X925 = CCD oder Classic im IOD / A725 = Dense. Wo ist hier also der grosse Unterschied beim Browsen auf dem Smartphone und Laptop? Oder Media Playback? Oder mal Mails/Nachrichten schreiben oder ein Dokument lesen/bearbeiten? Das sind 90% der Tasks, die auf einem Laptop laufen werden (somit sehr ähnlich wie auf einem Smartphone). Fokus ist nicht Gaming und nicht CPU-Rendering.