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 doch 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.

[Windi]

Medusa Point hört sich für mich nach einem Nachfolger des Dragon Range an.


Neue Architektur, mehr Kernen, neuere und größere Grafikeinheit, NPU und weitere Neuerungen.

Diesmal nimmt man halt nicht das Desktop IOD, sondern die neue mobile APU und kombiniert sie mit dem Standard Chiplet.
Dadurch hat man zwar nur 20 anstatt 24 Kerne, wie auf dem Desktop, aber das ist für den Stromverbrauch sicherlich besser.

Und zum Scheduling: auf dem Chiplet hat man sicherlich einen großen zusammenhängenden L3 Cash, den man auch noch mit 3D Cash erweitern kann. Die bevorzugt man am Anfang. Dann kommen die vier normalen Kerne in der APU, dann die vier Kompakten.

[Der_Korken]

@basix: Du hast in deinen Ausführungen noch SMT vergessen. Du hast nicht nur vier verschiedene Kerne, sondern eigentlich 8. Was mache ich, wenn ich mehr als zwei Hintergrundtreads habe? SMT auf LP-Cores nutzen oder auf Dense auslagern? Und wenn Dense, wieviele schiebe ich drauf? Nur einen oder alle drei, damit ich das LP-Cluster wieder abschalten kann? Was, wenn von den drei Threads einer mehr Leistung braucht? Schiebe ich den auf IOD-Classic oder auf CCD-Classic? Und schiebe ich die anderen zwei dann wieder auf LP zurück, um das Dense-Cluster abschalten zu können? Und so weiter.

Edit:

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.

Das war unter der Prämisse von OgrEGT, dass man die Cluster sequentiell durchschaltet und nie zwei verschiedene zusammen benutzt. In dem Fall würden 4xDense und 4xClassic nie zusammen laufen und folglich auch nicht als ein Cluster an einem gemeinsamen L3 angebunden. Da wäre es quasi immer besser (Performance und Flächenverbrauch) direkt 6xClassic zu bauen und an einen L3 zu hängen.

[Nightspider]

Scheduling Idee:

Ich weiß ja nicht ob das sinnvoll ist so viele Kerne gleichzeitig und teilweise nur minimal zu belasten anstatt easy workloads auf den Big Cores laufen zu lassen, die eh schon paar Aufgaben wegschießen.

Die 2nm Chiplets mit 6+ Ghz dürften sowieso extrem effizient laufen.

Ob die 3nm IOD Kerne da überhaupt großartig bei der Effizienz besser abschneiden können ist für mich im Moment etwas fraglich ohne weitere Infos.

MLID sagte auch das Zen5 (LP) in Medusa Point 1 stecken soll / kann.
Und er sagte auch das ein paar dieser Projekte vielleicht gar nicht das Licht der Welt erblicken werden, was durchaus auch von der Availability und Quality des 2nm Prozesses abhängen wird/kann und dann erst in einigen Monaten entschieden wird.

https://static.tweaktown.com/news/1/0/104279_604_amds-next-gen-zen-6-desktop-cpus-olympic-ridge-gator-range-with-over-6ghz-clock-speeds_full.jpg

[latiose88]

wenn ich das schon lese 4 dense und 4 LP kerne.Ob das nicht unter Windows Probleme machen wird.Windows 11 ist naja nicht gerade ein parade Beispiel dafür das es ohne Probleme laufen wird.
Ich sehe da schon einige Probleme drauf zu kommen.
Und 12 Power Kerne.Jap das sind dann 20 Kerne und mit SMT dann 32 Threads wo so wer wie ich aktiv nur die 12 Kerne mit SMT nutzen kann und der rest beim Videoschneiden oder für uralte Game genutzt wird.Ich habe zurzeit einen i3 12220p wo 2 Kerne mit HT 4 Threads und 8 E kerne.Das klappt fürs so zocken wie ich es betreibe ganz gut.Bin gespannt wie das bei AMD so aussehen wird.
Für die meisten meiner Sachen reicht das gut,nur ein Programm da brauche ich dann doch mehr Power.Und da bin ich gespannt was Zen 6 von AMD zu bieten hat.Alleine ich kann gut mit 16 Kernen mit SMT umgehhen.Das nenne ich also Power User.
Da hoffe ich dann doch das AMD was gescheites liefert.Wobei ich mit dem 9950x den ich ja bald haben werden gut überbrücken kann.Ob es da mehr Allcore Takt geben wird,bin ich mir nicht sicher.Bei 12x 6 ghz könnte es sein ,das es aussreicht um ein 16x5,2 gghz gleich zu ziehen.
Ich lasse mich also Überraschen wie es da weiter geht.
Zuerst dachte ich ja dann kommen halt 2x12 Chiplets also 24 Kerner als Zen 6 Topmodell raus.
Aber so wie ich es von euch gelesen habe,wird das wohl vielleicht doch nicht so sein.Ich erwarte ja eh nicht mehr Kerne.

Denn sollte sich bei mir herausstellen das mir in Zukunft auf vielleicht nur 12 Kerner reichen könnte,dann habe ich das Problem wie ihr so geschrieben habt nicht mehr.Dann bin ich fein raus aus der ganzen Sache.

Wenn ich Ehrlich bin,nen richtigen Nutzen aus 24 Kernen habe ich nicht.Somit ist klar das ich auf so viele Kerne verzichten kann.Wenn ich einen 24 Kerner geben würde und ich ihn hätte würde eh erst mal SMT abgeschaltet und da käme dann 24 Threads dabei raus.Warum weil mehr Nutzen ich aus den Kernen sonst nicht ziehen kann.

Ich musste die Erfahrung Sammeln.Nun durch das hat der Kerne Wahn ein Ende bei mir.
Es bleibt also dennoch spannend wie AMD die Anzahl so erreichen will bzw kann.

Die Software bleibt auch in Zukunft ein Problem.Die Software Brauchne ist langsam und Träge.Also wird sich leider alle Hardware Hersteller der Software anpassen müssen. Microsoft ist bei Betriebsystemen ein Negatives Beispiel für das große scheitern.
Nur Linux hat bisher gezeigt wie flexible es ist,aber für einen Windows Proggramm User wie mir ,dennoch leider keine Option.

Wie ich mich also am Ende mit dem Wissen wo die Grenze so ist,mich Entscheiden werde,da bin ich gespannt.

[Windi]

Viele glauben anscheinend, dass Medusa Point das neue Effizienzwunder wird.
Für mich klingt das aber nach einem Dragon Range Nachfolger. Eine günstige Lösung, um im Mobilbereich viele Kerne mit einem externen Grafik-Chip zu kombinieren.
Wenn der Grafikteil schon 150W benötigt, braucht man sich keine großen Gedanken mehr darüber zu machen, welche Kerne man als erstes schlafen legt.

Die wirklichen Energiesparwunder werden die großen APUs sein, die viele Grafikeinheiten bieten und auf fest verlötetem Arbeitsspeicher setzen.
Und die wird sich AMD fürstlich bezahlen lassen.

Mit Medusa Point braucht AMD halt nur eine einzige APU, um im günstigen Preisbereich 6 bis 20 Kerne zu bieten.

[HOT]

Sehr effzent dürfte die monolithische Chip sein, der ist aber auch "nur" N3P. Die große APU hat zwar das Desktop-CCD, das ist aber schon in N2P gefertigt, das würde ich dabei nicht außer Acht lassen bei der Effizienzbetrachtung.
Zudem ist Medusa Point ja auch ein Strix Halo von der Anbindung des CCDs her, das ist ja auch sehr effizient. Ich denke aber auch, dass man alle big-Cores auf der APU deaktiviert, wenn ein CCD angeschlossen wird.

[Windi]

Ja der monolithische Chip dürfte effizient werden.
Aber die meisten Käufer der großen Variante mit dem Desktop-CCD, werden wohl auch einen externen Grafikchip dabei haben wollen. Der ist dann per PCI Express angebunden und hat seinen eigenen Speicher.

Das ist dann viel ineffizienter als eine große APU mit großem Grafikteil und fest verlöteten Arbeitsspeicher. Aber natürlich ist es viel effizienter als das alte Dragon Range Konzept.

[Nightspider]

Dragon Range war einfach der Desktop Kram mit leichten Optimierungen ins Notebook gequetscht.

Medusa Point hat einen ganz anderen Aufbau und nicht viel mit Dragon Range zu tun.

Dank der 2nm Chips und der effizienteren Anbindung der Chiplets wird es erstmal nichts effizienteres oder schnelleres geben.

2nm ist 2 Nodes moderner als Strix Point.

[Windi]

Wenn man einen externen Grafik-Chip mit einbezieht, dann gibt es schon gewisse Ähnlichkeiten im Konzept.

Zum einen ist die integrierte Grafikeinheit so schwach und veraltet, dass sie nur für Office taugt. Zum anderen ist es dann auch nicht so tragisch wenn diese dann deaktiviert wird.
Eine große APU mit starker Grafikeinheit und gemeinsamen Speicher wird immer effizienter sein. Und solch eine Lösung erwarte ich auch von AMD mit Zen6.

Wäre Medusa Point auf maximale Effizienz ausgelegt, hätte ich bei Zen6 12 Kerne in der Basis APU erwartet. Zum einen kann man mehr Kerne häufig mit geringeren Taktraten kombinieren. Zum anderen hat man dabei häufig einen größeren gemeinsamen Cash, der Energie spart. Und man könnte größere Modelle anbieten, ohne dass man ein weiteres Chiplet benötigt.

Für mich sieht Medusa Point nach einem klugen Konzept aus, mit dem man viele Kerne im mobilien Bereich kostengünstig realisieren kann. Dass man hier die mobile Einsteiger APU mit einem CCD erweitert, ist natürlich viel intelligenter, als die Desktoplösung umzulabeln.
Die Prioritäten liegen meiner Meinung nach hier im Bereich Kosten sparen und nicht bei der maximalen Effizienz. Ähnlich wie bei Dragon Range.

[HOT]

Die 16CUs bei Strix sind nicht mal im Ansatz ausgelastet, eher werden die 8 CUs in N3P sicherlich ordentlich hoch takten und den Nachteil wettmachen. Zudem dürfte Medusa mehr Bandbreite bekommen, ich bezweifle ernsthaft, dass die Medusa-GPU langsamer ist als Strix. Sie wird nur ordentlich kleiner sein.
Es gibt ja wie gesagt auch noch Fragen im Aufbau, denn Medusa1 ist offenbar ein APU/IOD-Hybrid, sprich, man kann den Chip einfach mit einem CCD erweitern. Das will man ja eh nur, wenn man die CPU-Leistung wirklich haben will.

[basix]

Ja, es gibt Skalierungs-Tests von der Strix Point iGPU, wo so zwischen 1.4...1.8 GHz die Bandbreite nicht mehr limitiert. Da wären 8CU bei knapp 3 GHz vermutlich nicht langsamer. Die 12CU 880M ist ja auch nicht wirklich langsamer wie dei 890M.

Ich finde im Tweet die "3.5+" noch interessant. Es gibt RDNA 3.5. Was ist RDNA 3.5+? Eine verbesserte Version von RDNA 3.5? Oder es könnte RDNA 3.5 oder dann doch >= RDNA 4 sein? 8CU RDNA4 wären definitiv schneller als die 890M.

Ich habe mal ganz grob die Die Size abgeschätzt (Anhand Strix Point = 233mm2). Ich würde sagen, Medusa Point dürfte knapp <200mm2 landen, wenn in N3P (8CU RDNA4, verdoppelte NPU FLOPS, 10C CCX, 1x IFOP Interface). Immer noch ein ziemlicher Brummer.

[bbott]

RDNA 3.5+ würde ich als mehr AI (FSR4) aber ohne bzw kaum RT update interpretieren. Bei APUs mach RT noch wenig Sinn, FSR4 dagegen sehr...

[MSABK]

Ich tippe auch auf FSR4 für die APU. Eine weitere gen ohne diese Funktion wäre nicht so toll, besonders im Vergleich zu Intel, die aktuell sehr gut aufholen im mobilen Markt.

[CrazyIvan]

Ich habe mal ganz grob die Die Size abgeschätzt (Anhand Strix Point = 233mm2). Ich würde sagen, Medusa Point dürfte knapp <200mm2 landen, wenn in N3P (8CU RDNA4, verdoppelte NPU FLOPS, 10C CCX, 1x IFOP Interface). Immer noch ein ziemlicher Brummer.
Einen IFoP wird er definitiv nicht mehr haben - und das ist immerhin ca. halb so groß wie ein Zen5 Kern. Der Ersatz wird vermutlich nur 5% der Fläche einnehmen.
Ist aber natürlich in der Gesamtschau auch nicht dramatisch.

[basix]

Es ist nicht mehr IFOP, klar. Aber wie das Interconnect-Kind heissen wird, wissen wir ja noch nicht ;) Vielleicht nennt es sich Infinity Fanout Link wie bei RDNA3.

[HOT]

Da das Ding sicherlich ne echt leistungsfähige NPU hat bezweifle ich ernsthaft, dass die Architektur AI über die GPU rechnet. Ich denke, dass das ein abgespeckter RDNA4 ohne AI und ohne gesonderte RT-Einheiten ist, aber die gleiche IPC mitbringt wie RDNA4 und die hohen Takte natürlich (wie bei allen vorherigen APUs sicherlich sogar deutlich höhere Takte als RDNA4). FSR kann man ja über die NPU lösen. MMn spart dieser Ansatz ordentlich Platz, die NPU braucht man sowieso und die GPU ist so wirklich klein. Sicherlich sind auch die Zen6-Kerne ordentlich abespeckt, ähnlich wie bei Strix Point und weniger L3$ wirds auch geben. Wer im Notebook viel AVX512-Performance und viel Cache haben möchte und generell viel CPU-Leistung braucht, hat ja die Option, die CCD-Variante zu nehmen... Medusa 1 ist ein Nachfolger von Kraken Point mit ähnlichen Features und sollte ebenfalls nicht über 170mm² groß sein.

[latiose88]

interessant wie ihr über die onboard gpu so schreibt. Wird es laut euer Meinung echt keine leistungssteigerung geben? Weil ich verwende die Intel udhd gpu und naja ich merke ja selbst bei den alten games wie need for speed most wanted (2005) da ist Schatten Einstellung deaktiviert. Bei counter stile source geht nur low settings und bei c&c die stunde null auch eher low setting aber wenigstens laufen die spiele flüssig. Für eine 7 Watt gpu echt nicht schlecht. Wie sieht es da denn bei AMD aus, packt die mehr und sind dann die Settings bei der onboard gpu auf maximale Details und wie viel darf denn die AMD onboard gpu sich so genehmigen?

[basix]

Wird es RDNA 3.5(+):
Vermutlich keine oder nur geringe Leistungssteigerung.

Wird es RDNA 4:
8CU sollten die 890M überflügeln können. Unter Umständen sogar relativ deutlich (kommt auf die Bandbreiteneffizienz drauf an). Inkl. RT oder ML/AI sowieso.

Was man auch bedenken muss:
N3P und nur 8CU dürften ziemlich hohe Taktraten zulassen. Und die 890M/880M sind stark bandbreitenlimitiert.

Hier ein Video zu Takt vs. Bandbreite vs. Performance: https://www.youtube.com/watch?v=6Y9e7Db3ny0
- Mit 2.0 GHz hatte man noch 95% der Performance
- Mit 1.6 GHz hatte man noch 85% der Performance (und <50% Verbrauch!)

Kann die GPU mit RDNA 3.5 also knapp 3GHz halten, wäre die Realperformance nicht wirklich schlechter als mit 16CU. Eine geringere Anzahl CU dürfte auch generell die höhere IPC liefern.

Da das Ding sicherlich ne echt leistungsfähige NPU hat bezweifle ich ernsthaft, dass die Architektur AI über die GPU rechnet. Ich denke, dass das ein abgespeckter RDNA4 ohne AI und ohne gesonderte RT-Einheiten ist, aber die gleiche IPC mitbringt wie RDNA4 und die hohen Takte natürlich [...]
Drei Gedanken dazu:
- Ich befürworte, dass AMD bei den APUs die NPU für den DNN Part von FSR4 nutzen soll. Mehr FLOPS, höhere Energieffizienz, entlastet die iGPU
- RT-Cores könnte man entfernen. Aber ich weiss nicht, ob sich hier der Aufwand wirklich lohnt. Es sind nur 8CU und entsprechend gering ist deren Chipfläche
- Matrix-Cores aus RDNA4 entfernen wird nicht passieren. Dazu wird das AI-Ross zu hart geritten ;) Und es gibt Anwendungen, welche Matrix-Operationen auf der GPU nutzen. Deutlich mehr als Programme, die die NPU unterstützen

[HOT]

Da wird denke ich nichts entfernt, sondern AMD hat von Anfang das Designziel dafür angepasst. Ein all-in-Design mit voller RT und Matrix-Performance für N4P und ein stark abgespecktes Design für Rendering für N3P für die APUs. RDNA3.5+ ist das mMn nur dem Namen nach und reflektiert halt das Featureset, aber die Technik ist mMn RDNA4.

[robbitop]

Das denke ich nicht. Die CUs sind in RDNA4 ganz anders. Wenn das RDNA4 Technik wäre, würde AMD das nicht RDNA3.5+ nennen. Dafür gab es bei AMD auch noch nicht einen einzigen Präzedenzfall. GPUIP 11.x.
Ist für die meisten APU Käufer wahrscheinlich nicht so relevant weil die IGPs von den allerwenigsten im Massenmarkt intensiv gezockt wird und es wird - das sah man immer wieder in der bisherigen Historie - vom Massenmarkt auch kaum belohnt (bzw bestraft). RDNA3.5 GPU IP ist einfach kleiner und man kann die size sparen. Gute Effizienz und starke CPU hingegen wird anscheinend vom Markt belohnt. Also scheint zunächst da der Fokus zu liegen.
Entweder wird RDNA4 dann übersprungen bei APUs (wie RDNA1) und es geht gleich mit UDNA weiter oder es kommt dann eben 1 Jahr später. Und dann in jedem Fall mit mächtigem Speedup. Es soll ja mittelfristig auch IF$ in die APUs kommen (die nicht Halo meine ich) und dann wird es sich richtig lohnen.
Wenn man sich die bisherigen Speedups seit Van Gogh, Rembrandt so anschaut (insbesondere im 15W Bereich) ist das ziemlich mager dafür dass 3-4 Jahre vergangen sind. Da wird RDNA4/UDNA + IF$ dann wirklich mächtig mächtig was drauf knallen.

Mein Tipp ist, dass sowas dann auch im custom silicon für das Steam Deck 2 landen wird - denn die wollen in 15W einen richtig fetten Sprung. Dafür braucht es beides (RDNA4 oder besser und zumindest einen kleinen IF$)

[basix]

Medusa Halo soll gfx13 bekommen. Das wäre RDNA5 / UDNA

Bekommt Medusa Point nur RDNA 3.5, wäre das schon eine arg grosse Diskrepanz. Ausserdem wohl beides in N3P. Vermutlich kommt Medusa Halo aber erst ein paar Monate später, da ist RDNA5 anscheinend zeitlich ready. RDNA4 wäre allerdings bereits heute verfügbar. Und eine neue Implementation muss man aufgrund N3P eh machen, egal ob RDNA4 oder RDNA 3.5. Da würde es sich mMn mehr lohnen, die modernere RDNA4 IP auf N3P zu schrinken.

Flächenunterschiede dürften nicht extrem gross sein. Ich habe grob N31 und N48 vermessen.

N31:
- 4x SE = 110mm2
- 16x CU = 21mm2
- CMD = 40mm2
- Media = 28mm2
- IO = 15mm2

N48:
- 4x SE = 135mm2
- 16x CU = 26mm2
- CMD = 41mm2
- Media = 35mm2
- IO = 16mm2

Nimmt man 1x SE à 8CU ist der Flächenunterschied ~7.5mm2. In N3P wohl eher 5-6mm2. Auf die gesamte GPU gesehen inkl. Media-Block <10% Flächenzuwachs für +30...40% GPU-Bumms und nochmals mehr bei RT unt Matrix-Operationen. Aufs gesamte Die gesehen vielleicht 3% oder so Flächenzuwachs.

RDNA3.5 macht für mich somit kaum Sinn:
- Alte IP und Features
- Geringere Performance pro Fläche
- Geringere Energieeffizienz
- Keine Timeline Restriktionen
- Marginale Verteuerung des Die bei RDNA4

[robbitop]

Wo hast du das mit RDNA5/UDNA her? IIRC war bei MLID da noch alles offen RDNA3.5/4 und 5(UDNA).
Allerdings würde ich auch vermuten, dass bei 3.5 der Sprung mit den 48 vs 40 CUs zu klein wäre und man dafür auch nicht zwangsweise ein 384 bit SI brauchen würde.
UDNA kommt mir noch etwas zu weit weg vor - historisch landeten erschwerenderweise die GFX IPs auf APUs auch immer später. RDNA4 würde hier IMO etwas plausibler erscheinen oder?

[basix]

adroc_thurston aus dem Anandtech Forum:
https://forums.anandtech.com/threads/zen-6-speculation-thread.2619444/page-121#post-41449520

Medusa Halo kommt halt auch später. Und nur RDNA 3.5 wäre dort ein Rohrkrepierer.

Ausserdem sei das Zen 6 CCD bereits N2P oder zumindest eine angepasste Version von N2. Kepler_L2 sagt ebenfalls N2P

[robbitop]

OK also dann 2026 - trotzdem wäre das ungewöhnlich schnell für neue GPU IP in APUs.
Ich kenne diesen user nicht - ist der bekannt dafür gute Quellen zu haben? Guter Track record oder so? :)

[basix]

Er scheint ein paar Infos zu haben. Ob die von eigenen Quellen stammen, weiss ich nicht. Bei Zen 5 lag er allerdings im Hinblick auf Consumer-CPUs völlig daneben (wie eigentlich alle).

Medusa Halo könnte auch erst Anfang 2027 erscheinen.

[robbitop]

Also wissen wir dass wir nichts wissen X-D. Aber ja 2027 könnte auch UDNA sein. :)
IMO waren die Halo SKUs bisher auch ziemlich teuer. Integration sollte ja eigentlich Kosten senken -_-

[HOT]

Was ist das denn fürn Argument, dass AMD das dann nicht RDNA3.5+ nennen würde? Wenn das Featureset dem entspricht und das weniger als RDNA4 ist, wieso sollte man das nicht so nennen? Du glaubst doch nicht ernsthaft, dass man ne ältere IP in N3P verbaut :freak: so ein Unsinn. Ich wette, dass das eine abgespreckte RDNA4-IP ist, ne Art RDNA 3.9. Und noch was, die bauen keinen Medusa Point, der langsamer ist als Strix Point, garantiert mal nicht.

Halo kommt 1 Jahr später als Medusa1. Das wäre dick nach UDNA-Desktop-Release. Klar hat der UDNA.

[Nightspider]

Wenn man sich die bisherigen Speedups seit Van Gogh, Rembrandt so anschaut (insbesondere im 15W Bereich) ist das ziemlich mager dafür dass 3-4 Jahre vergangen sind.

Da gabs ja CPU seitig mehr Leistung im gleichen Zeitraum und das sagt schon viel aus.

Mit einem 16 MB IF$ wäre Strix Point halt schon ein ganz anderes Kaliber geworden.
....aber man verschwendet ja lieber Silizium für nutzlose NPUs....:rolleyes:

Die Strix Point GPU mit IF$ würde in einem Steam Deck 2 schon einen ordentlichen Sprung bringen.
Aber noch besser halt dann eine RDNA4 GPU in N3P mit IF$ und FSR4. =)

[basix]

Ja, Strix Point krankt an Bandbreitenmangel. RDNA4/5 dürfte eine deutlich erhöhte Bandbreiteneffizienz haben und allenfalls sehen wir sogar LPDDR6 bei der nächsten Generation.

Noch zum Thema RDNA 3.5:
Für Desktop wäre das für mich stimmig. Dessen IOD wird vermutlich in TSMC N4C kommen und nicht in einem TSMC N3-Derivat. Da hätte man also fast alle wichtigen IP-Blöcke bereits von Strix Point/Halo und auch RDNA4 (Multimedia usw.) verügbar. Es wird vermutlich eine Revision der Chiplet-Verbindungen und der NPU geben (XDNA3?). Aber viel mehr als das braucht es eigentlich nicht. In den APUs ist höhere iGPU-Leistung und insbesondere Energie- und Bandbreiteneffizienz deutlich wichtiger. Und da macht es dann auch mehr Sinn, ein N3-Derivat sowie RDNA4/5 als Basis zu nehmen. LPDDR6 sowie IF$ noch als zusätzliche Optionen.

[mboeller]

Ja, Strix Point krankt an Bandbreitenmangel. RDNA4/5 dürfte eine deutlich erhöhte Bandbreiteneffizienz haben und allenfalls sehen wir sogar LPDDR6 bei der nächsten Generation.


Hoffentlich!
Soweit ich gelesen haben sind bei LPDDR6 die Kanäle nicht mehr 16bit breit (wie bei LPDDR5) sondern 24bit breit. Zusammen mit der höheren Geschwindigkeit sollte das zu einer verdoppelten Bandbreite führen.

... außer die Hersteller verbauen nur noch Speicher mit 4 (96bit) statt 8 Kanälen (192bit) bei LPDDR6

[robbitop]

IIRC gab es ja Gerüchte, dass die APUs auch ein bisschen LLC bekommen sollen. Auch die normal APUs und nicht nur die Halos. Das wäre ein echter Enabler. Zusammen mit RDNA4.

[latiose88]

ja gut,wie ggut sind denn so aktuelle onbaord GPu als gegenstück zu Desktop GPUs?

[aceCrasher]

ja gut,wie ggut sind denn so aktuelle onbaord GPu als gegenstück zu Desktop GPUs?
Langsamer als eine RX6400 AFAIK.

Die aktuell schnellsten haben 768 RDNA3 Shader, so wie eine RX6400, aber eben keinen IF$ und kein eigenes Speicherinterface. Für casual gaming ist es okay. Baldurs Gate 3 1080p low @30fps ist beispielsweise machbar.

[Nightspider]

MLID:

AMD Quelle: "Es wird bei Zen7 wahrscheinlich noch klassische 16C Chiplets mit L3 auf dem Core Chiplet für den Consumer Markt geben und die fancy 3D Chiplets ohne L3 auf dem Core Die wird es vielleicht nicht im Consumer Markt geben"

Also sicher ist noch nichts und vieles kann sich noch ändern. Am Anfang gibt es ja mehrere Designs von denen dann einige verworfen werden.

Also heißt es weiter abwarten, was wir mit Zen7 und wahrscheinlich Am6 im Desktop Bereich bekommen werden.

[dargo]

Endlich mehr Cores pro Chiplet.
https://youtu.be/w6JBCsOtFs4?si=HZR9Krh4oAupcTig&t=287

Also ganz chillig bis Zen7 X3D warten. :cool:

[Nightspider]

Gibt's doch schon bei Zen 6.

[HOT]

Wenn Zen7 das IOD von Zen6 wieder übernimmt wird der auch AM5. Wenn nicht, wird er AM6. Das hat Tom dabei wieder nicht beachtet.

[Badesalz]

MLID:

AMD Quelle: "Es wird bei Zen7 wahrscheinlich noch klassische 16C Chiplets mit L3 auf dem Core Chiplet für den Consumer Markt geben und die fancy 3D Chiplets ohne L3 auf dem Core Die wird es vielleicht nicht im Consumer Markt geben"Der Loss vom X3D zu nonX3D bei Anwendungen die nichts vom V-Cache haben, hat sich jetzt schon stark reduziert gegenüber früher. Wenn sie das im Labor nochmal reduzieren können macht es keinen Sinn noch nonX3D für Consumer zu bringen. Das verkauft sich ja ungleich zäher als die X3D und wenn es mal ähh... Volumengeschäfte gibt (Office&Co.) sind APUs dann nicht nur mehr als schnell genug dafür, sondern ergeben an der Stelle mittlerweile allgemein enfach nur wesentlich mehr Sinn.

Also heißt es weiter abwarten, was wir mit Zen7 und wahrscheinlich Am6 im Desktop Bereich bekommen werden.:freak: :uup:

[Nightspider]

:freak: :uup:

Ja, ich weiß. Obviously.

Ich meinte nur das wir uns vielleicht zu früh gefreut haben echte 3D Kerne zu bekommen.

[davidzo]

Halo kommt 1 Jahr später als Medusa1. Das wäre dick nach UDNA-Desktop-Release. Klar hat der UDNA.

Ahem, AMD hat gerade eine Zen2 RDNA2 APU vorgestellt.

Also AMD hat keine Scheu auch ältere Technologie zu verwursten und wieso auch nicht, wenn diese die Anforderungen an Performance und Energieeffizienz erfüllen? Van Gogh ist immer noch Top: Zen2 immer noch eine der effizentesten Zen CPU-Generationen und vermutlich ist der 6nm SOC bei gleichem sub 15Watt power budget auch nicht langsamer als Krackan.

Das IOD von Raphael und Granite Ridge hat man auch bewusst nur mit RDNA2 ausgestattet obwohl RDNA3 zur Verfügung gestanden haben dürfte.

N33 wird ja auch weiter geführt obwohl es N44 gibt. RDNA4 ist von der PPA einfach nicht so gut wie RDNA3.5: N44 hat den 2,2fachen Transistorbedarf von N33, erzielt damit aber lediglich 30% Mehrperformance.
Der Vergleich von Navi4x mit den den Navi3x Chiplet GPUs verzerrt die PPA Diskussion immer zugunsten von RDNA4. Der beste Vergleich ist allerdings immer noch N44 vs N33.

Wenn AMD sich einen neuen IOD gönnt, dann wegen einer neuen NPU, Videocodecs und LPDDR6 Speicherinterface statt LPDDR5. Ob dann UDNA verwendet wird oder RDNA3.5/4 ist eine Frage des Transistorbudgets.

[HOT]

Macht ja Sinn Postings zu exhumieren, die schon lange tot sind.... toll jetzt ist der untot.
Es ist immer noch nicht klar, womit wir es zu tun haben, aber UDNA ist es definitiv nicht. Ich gehe eher von einem extrem eingeschränkten RDNA4 aus, was RDNA3.5 ja schon im Prinzip ist. Aber RDNA wird ja seit jeher in Modulen entwickelt und da ist RDNA2 von 2020 nicht unbedingt 100% gleich RDNA2 von 2022...

[Lehdro]

Wenn Zen7 das IOD von Zen6 wieder übernimmt wird der auch AM5. Wenn nicht, wird er AM6. Das hat Tom dabei wieder nicht beachtet.
AMD kann den auch einfach mit jeweils einem der beiden verschiedenen IODs für beide Sockel bringen. Ist zwar sehr unwahrscheinlich, allerdings technisch nicht unmöglich.

[Exxtreme]

Wenn die wirklich mit 32 Kernen anrücken dann ist AM6 mit DDR6 sehr wahrscheinlich. Mit AM5 ist nicht genug Bandbreite da um alle Kerne auszulasten. Da kann man sich die 32 Kerne eigentlich sparen. Was aber vorstellbar wäre, ist ein Zen7-16-Kerner für AM5. Ich halte es aber nicht für sehr wahrscheinlich, dass die das bringen. Da werden die MoBo-Hersteller heulen.

[Complicated]

Die 16-Kerner gabs auf AM4 und auch für AM5.
Siehe EPYC 4004/4005 Serie:
https://www.pcgameshardware.de/CPU-CPU-154106/News/AMD-Epyc-4005-Server-CPUs-AM5-mit-3D-V-Cache-1472614/
der*AMD Epyc 4585PX*mit 16C/32T und bis zu 5,7 GHz bei 170 Watt an der Spitze des neuen CPU-Portfolios, der letztgenannte Server-Prozessor verfügt darüber hinaus über einen 64 MiByte großen gestapelten L3-Zwischenspeicher, den sogenannten 3D V-Cache.

[Zossel]

Wenn die wirklich mit 32 Kernen anrücken dann ist AM6 mit DDR6 sehr wahrscheinlich. Mit AM5 ist nicht genug Bandbreite da um alle Kerne auszulasten. Da kann man sich die 32 Kerne eigentlich sparen. Was aber vorstellbar wäre, ist ein Zen7-16-Kerner für AM5. Ich halte es aber nicht für sehr wahrscheinlich, dass die das bringen. Da werden die MoBo-Hersteller heulen.

It depends.

[basix]

Wenn ich raten würde:
- Zen 6 kommt mit neuem IOD, bleibt bei AM5 und somit DDR5 und PCIe 5.0, bekommt dazu noch USB4
- 10 GbE, Bluetooth 6 und WiFi 7 Support
- Es gibt einen neuen Chipsatz, PCIe 5.0 Uplink zur CPU und USB4
- Vielleicht gibt es daraus sogar einen AM5+ (und vielleicht +4 PCIe Lanes bei der CPU)
- Zen 7 übernimmt die Zen 6 Plattform 1-zu-1
- Zen 8 kommt auf AM6

[basix]

Wisst ihr, was ich an AI dessen Einfluss auf CPUs liebgewonnen habe? Die AI-Server (inkl. Accelerator GPUs) performen am besten mit schnellen und hoch taktenden CPUs. Grund für z.B. AMD, die ST-Performance noch mehr zu pushen :D

[Zossel]

Wisst ihr, was ich an AI dessen Einfluss auf CPUs liebgewonnen habe? Die AI-Server (inkl. Accelerator GPUs) performen am besten mit schnellen und hoch taktenden CPUs. Grund für z.B. AMD, die ST-Performance noch mehr zu pushen :D

NV verbaut CPU-Cores mit hoher ST-Leistung?

[basix]

Nicht umsonst werden von AMD als auch Nvidia die Epyc xxxxF CPUs für AI-Server empfohlen. Was Nvidia mit ihren CPUs macht, werden wir mit Vera noch sehen ;)

Gab in der Vergangenheit bereits mehrere Präsentationen, die hohe ST Performance = Gute AI-Performance aufgezeigt haben. Und AMD hat gerade in ihrer aktuellen Präsentation gezeigt, dass man mit einer schnelleren CPU bspw. 6-17% mehr Performance aus den GPUs holt. Das ist eine massive Kostenverbesserung bei den sehr teueren Systemen.

[Badesalz]

Irgendwie würde ich mich schon wundern, wenn erst Zen8 mit neuem Sockel kommt.

[basix]

Und wieso? Was fehlt dem Consumer mit WiFi7, USB4, PCIe 5.0 und DDR5? Mit (vermutlich) neuem Chipsatz und IOD sollten genug Feature-Updates kommen, sodass sich ein neuer Sockel hinauszögern lässt.

[HOT]

Wenn ich raten würde:
- Zen 6 kommt mit neuem IOD, bleibt bei AM5 und somit DDR5 und PCIe 5.0, bekommt dazu noch USB4
- 10 GbE, Bluetooth 6 und WiFi 7 Support
- Es gibt einen neuen Chipsatz, PCIe 5.0 Uplink zur CPU und USB4
- Vielleicht gibt es daraus sogar einen AM5+ (und vielleicht +4 PCIe Lanes bei der CPU)
- Zen 7 übernimmt die Zen 6 Plattform 1-zu-1
- Zen 8 kommt auf AM6

So würd ich das auch sehen. Aber es könnte wohl PCIe6 geben, war bei AM4 ja ähnlich. DDR6 ist glaube ich noch in sehr weiter Ferne bei beiden Herstellern, auch NVL und Nachfolger haben ja DDR5.
Auch wahrscheinlich ist, dass USB4 direkt in das neue IOD integriert wird, 2 der 3.2-Ports also durch 4.0 Ports ersetzt werden.

Was mich da eher wurmt, ist, dass Zen7 schon ein Jahr später kommen soll. So stehts ja auch der AI-Roadmap, 2026 Venice und 2027 direkt Verano. Jetzt ist auch klar, warum man schon solche Leaks hat.

[Badesalz]

Und wieso? Was fehlt dem Consumer Ich sehe auch keine Korrelation zwischen dem Sockel und Wifi... Werden halt sehen, aber ich glaub stand jetzt nicht dran.

[Badesalz]

DDR6 ist glaube ich noch in sehr weiter Ferne bei beiden Herstellern, auch NVL und Nachfolger haben ja DDR5.Ich erinnere mich an eine Aussage hinterm Vorhand und dann mit noch mit vergehaltener Hand, eines CPU-Ingenieurs, daß wenn sich "memory bandwidth" nicht wenigstens alle 3 Jahre verdoppelt, die Arbeit an den Kernen zu einem großen Teil verpufft... Das war aber noch vor X3D :usweet:

Das ganze Geballer läuft in 2 Problemzonen.
1. Daten bewegen kostet schweineviel Energie und zerrt stark am Powerbudget. Photonics wäre eigentlich schon gestern fällig.

2. Durchsätze am Hauptspeicher sind dazu noch der absolute King unter den Flaschenhälsen.
Was man an all den fancy Folien auch erahnen kann wie untypisch mehr das im RZ ausmachen soll, wenn man dran wieder HBM4 12Hi lötet.

[dargo]

Gibt's doch schon bei Zen 6.
Ja... aber bei Zen6 X3D erwarte ich noch nicht genug mehr Bums pro Core vs. 5800X3D, dass sich ein Plattformwechsel lohnt.

[HOT]

Ich erinnere mich an eine Aussage hinterm Vorhand und dann mit noch mit vergehaltener Hand, eines CPU-Ingenieurs, daß wenn sich "memory bandwidth" nicht wenigstens alle 3 Jahre verdoppelt, die Arbeit an den Kernen zu einem großen Teil verpufft... Das war aber noch vor X3D :usweet:

Das ganze Geballer läuft in 2 Problemzonen.
1. Daten bewegen kostet schweineviel Energie und zerrt stark am Powerbudget. Photonics wäre eigentlich schon gestern fällig.

2. Durchsätze am Hauptspeicher sind dazu noch der absolute King unter den Flaschenhälsen.
Was man an all den fancy Folien auch erahnen kann wie untypisch mehr das im RZ ausmachen soll, wenn man dran wieder HBM4 12Hi lötet.

Bisher gab es ca. alle 7 Jahre neuen RAM. DDR3 2008, DDR4 2015, DDR5 2022, DDR6 dann 2029. Würde also genau zu den Nachfolgern von Zen7 und LGA1954 passen. AM6 (Zen8) und der Nachfolger des Intel-Sockels dürfte dann also DDR6+PCIe7 werden.

[Badesalz]

@Hot
Der "neue RAM" ist aber immer ne ganze Weile erstmal nur Show. Wie lange dauert es bis es real den doppelten Durchsatz gibt? (gegenüber den Riegeln die es zum Ende der vorherigen Generation gibt)

[davidzo]

Ich erinnere mich an eine Aussage hinterm Vorhand und dann mit noch mit vergehaltener Hand, eines CPU-Ingenieurs, daß wenn sich "memory bandwidth" nicht wenigstens alle 3 Jahre verdoppelt, die Arbeit an den Kernen zu einem großen Teil verpufft... Das war aber noch vor X3D :usweet:
Naja, im Client-Markt ist ST performance immer noch maßgeblich für die Experience und da gibt es heute noch kein Bandbreitenbottleneck mit normalem DDR5. Ein Apple M4 ist auch mal eben 25% schneller ST und hat auch kein anderes SI als die x86 mobile Chips.

Andererseits hat mein sub 2kg Notebook doppelt soviel Speicherbandbreite für die CPU wie ein 3K€ Desktop PC. Und das ist noch nichtmal die Spitze, der M4max hat nochmal das doppelte, also viermal soviel wie ein 9950HX3d.

"Wir müssen warten auf DDR6" ist eine schlechte Entschuldigung für etwas was eigentlich "wir sind zu geizig" heißen müsste.

Wo sind die mehr als 2 Kanal Desktop-Plattformen hin? Bloomfield war doch triple Channel und Sandybridge-E quad channel - und das war vor 14 Jahren! Für ST und gaming hat es damals nichts gebracht, aber mittlerweile haben wir ganz andere Software und ganz andere Kernzahlen im Desktop, dass ein mickriges dualchannel SI hier wirklich zum Bottleneck wird.
Dass das in ATX nicht möglich ist kann mir keiner erzählen. Wir haben schließlich GPU PCBs mit 16 Layern mit VRMs die 600Watt auf einem Bruchteil der Fläche schaffen als die VRM area bei PC mainbards.
Die mainboards haben außerdem eh mehr Layer als früher für PCIegen5 für SSD und GPU. Da dürften also rund um die DRAM-sockel noch Fläche und Layer frei sein.

[Badesalz]

Dass das in ATX nicht möglich ist kann mir keiner erzählen.Die dicken X99 Boards waren doch ATX und hatten Quad (?)

Das brachte imho bei ST/Consumer nicht soviel wie gehofft, weil man im Quad u.a. wieder mit Timings federn musste. Ich sehe das Problem aber nicht mehr, wenn man das aktuell modern macht.
Aber ok. DAS wird mit Zen6 bestimmt nicht kommen :usweet:

Ich hab an der Stelle aber so ein seltsames Gefühl, daß wir beim x86 damit bisschen verarscht werden...

[Exxtreme]

"Wir müssen warten auf DDR6" ist eine schlechte Entschuldigung für etwas was eigentlich "wir sind zu geizig" heißen müsste.


Das ist korrekt. Wahrscheinlich will aber niemand den Aufpreis dafür bezahlen. Wobei ich nicht weiss wie hoch die Mehrkosten so sein werden. Und ein zweites Problem ist, mit 4 Speicherkanälen müsste man auch immer 4 Speichermodule installiert haben für volle Leistung.

[Der_Korken]

Ich bin nach wie vor skeptisch, wie groß der Markt für >=16 Kerne wirklich ist. Bei Zen 5 werden praktisch nur die 1-CCD-Modelle verkauft und für die ist Dual-Channel DDR5 völlig ausreichend. Hier ist der Bottleneck eher der mickrige IFOP-Durchsatz pro Link. Bei Intel werden bzw. wurden die großen Modelle zwar anteilig mehr verkauft, aber auch nur weil sie zusätzlich mehr Cache und mehr ST-Leistung geboten haben. Der Anteil der Kunden, die einen 9950X oder 285K für die MT-Performance kaufen und von den angeblichen 24- oder gar 32-Kernen von Zen 6/7 profitieren würden, dürfte sehr überschaubar sein. Nur für diese Käuferschickt den ganzen Sockel auf Quad-Channel hochzuziehen, wird schlicht zu teuer sein. Ich fand schon fraglich, dass AMD mit AM5 auf 230W PPT gegangen ist, weil das imho nur die Boards verteuert hat, ohne einen wirklichen Nutzen zu bringen. Bei Zen 4 haben eher alle den Eco-Mode angeworfen, weil die CPUs damit keine 5% langsamer waren.

Was im Gegensatz zu früher fehlt, ist eine kleine HEDT-Plattform. Also sowas wie Haswell-E, Broadwell-E oder auch die ersten Threadripper. Quad-Channel doppelte Kerne im Vergleich zum Desktop, mehr PCIe Lanes, keine APUs. Aber gut, es wird sicherlich einen Grund haben, warum dieses Segment nicht fortgeführt wurde. Auch wenn die Lücke zwischen Desktop und Server so groß ist wie nie.

[HOT]

@Hot
Der "neue RAM" ist aber immer ne ganze Weile erstmal nur Show. Wie lange dauert es bis es real den doppelten Durchsatz gibt? (gegenüber den Riegeln die es zum Ende der vorherigen Generation gibt)

Das ist klar, es gibt aber immer den Sweetspot, DDR400, DDR2 800, DDR3 1600, DDR4 3200, DDR5 6400. Das hat AMD nur bei DDR5 verzerrt, da das IOD auf DDR6000 Sweetspot ausgelegt ist.

davidzo
Die Bandbreite ist bei den meisten Workloads ziemlich unwichtig oder sagen wir limitiert in der jeweiligen Iteration selten und LPDDR hat blöde Latenzen. Wir brauchen auch keine 3 oder mehr Kanäle, das wäre höchstens für 16Kerne+ wertvoll und der Marktanteil dafür ist mikroskopisch klein. Ich bin sogar ein Verfechter davon endlich diese 4 Speichersockel einzustellen und immer nur noch 2 zu verbauen, das würde für die Boardhersteller Kosten einsparen und man hätte immer optimalen Support.

[Lehdro]

Das ist klar, es gibt aber immer den Sweetspot, DDR400, DDR2 800, DDR3 1600, DDR4 3200, DDR5 6400.

Ich korrigiere mal die Sweetspots:
DDR400, DDR2 8001066, DDR3 16002133, DDR4 3200, DDR5 64006000.
Im Bereich DDR1, 2 und 3 muss man sagen dass der Sweetspot pro CPU Generation ordentlich gewandert ist.

Das hat AMD nur bei DDR5 verzerrt, da das IOD auf DDR6000 Sweetspot ausgelegt ist.
Ausgelegt ist da gar nichts, wohl eher des technische Optimum was man bei der Mehrzahl der Prozessoren problemlos erreichen kann, "ausgelegt" ist man auf 5600. Mit der 9000er Serie sind meist sogar 6400 sync drin (IOD) oder halt 8000 async - da limitiert dich nur noch das Board.

[HOT]

Nope, DDR2 800 war das Standardmodul, 1600 und 3200, diese liefen so auch fast immer und überall, Nur bei AM5 nicht. Und selbstredend ist 6000 für das IOD der Sweetspot, da es diesen eigentlich immer erreicht ohne 1:2 gehen zu müssen. Sagt AMD ja auch selber, dass 6000 optimal ist.

[Zossel]

Wo sind die mehr als 2 Kanal Desktop-Plattformen hin? Bloomfield war doch triple Channel und Sandybridge-E quad channel - und das war vor 14 Jahren! Für ST und gaming hat es damals nichts gebracht, aber mittlerweile haben wir ganz andere Software und ganz andere Kernzahlen im Desktop, dass ein mickriges dualchannel SI hier wirklich zum Bottleneck wird.

Rupf doch einfach mal einen von den beiden Ramriegeln raus und hol die Stoppuhr raus und teile deine Ergebnisse mit uns-

[latiose88]

Ich hätte auch auch noch ein x99 System mit 6950x also quadchannel mit niedrigen RAM takt. Da könnte ich es mal ausprobieren. Eigentlich müsste ich das ja machen weil scheinbar einer der RAM riegel defekt ist. Ich Der Nachteil bei 4 riegel ist welcher ist nun defekt. Die Suche ist viel aufwendiger als mit nur 2 riegel.

achja soviel zu es werden für Zen 6 24 oder 32 Kerner I'm desktop kommen mit mehr allcore takt, ipc Steigerung usw.Und soviel zu nach dem kommt kurz drauf zen 7 ( 2028) auf neuer Plattform. Was es am Ende werden wird werden wir sehen und ob da allcore 6 GHz kommen wird, bleibt spannend. erwarte jedoch nicht zu viel weil sonst werde ich wohl Entäuscht werden, das will ich nicht.

[Complicated]

...DDR6 dann 2029. Würde also genau zu den Nachfolgern von Zen7 und LGA1954 passen. AM6 (Zen8) und der Nachfolger des Intel-Sockels dürfte dann also DDR6+PCIe7 werden.
Mit PCIe6 rechnet man nicht vor 2030 im Desktop/Mobile Segment.
https://www.heise.de/news/PCs-AMD-Intel-und-Hersteller-haben-offenbar-kein-Interesse-an-PCIe-6-0-10445092.html
"Für Verbraucher? Bis 2030 werden Sie keine PCIe-Gen-6-Lösungen sehen. PC-Hersteller haben derzeit nur sehr geringes Interesse an PCIe 6.0 – sie wollen nicht einmal darüber sprechen. AMD und Intel wollen nicht darüber sprechen", sagte Kou.
Das könnte durchaus zu AM6 mit DDR6+PCIe6 erst in 2030 führen - Zen7 kommt 2027. AM5 könnte über Zen7 hinaus noch 1-2 Generationen bekommen.

[Lehdro]

Nope, DDR2 800 war das Standardmodul, 1600 und 3200, diese liefen so auch fast immer und überall,
Dann haben wir unterschiedliche Auffassungen von "Sweetspot". Du meinst Spec/Standard und selbst dann MUSS man das differenzieren.
Und übrigens läuft auch jedes AM5 System mit 6400 - nur halt async dann, was zu Performanceeinbußen führt, weswegen AMD das nicht möchte. Deswegen ja der halboffizielle Sweetspot mit 6000.

Wenn du jetzt ernsthaft argumentieren willst, dass die anderen ja alle "mehr" konnten so sei dir eins gesagt: Sockel A startete mit DDR266. Erst mit S754/939 gab es flächendeckend DDR400. DDR2 startete bei AMD mit DDR2 800, mit AM2+ gab es 1066 Support. AM3 startete mit 1333 Support, die besten CPUs hatten 1866/2133 Support. AM4 startete mit 2666 Support und endete mit 3200 supported. AM5 startete mit 5200, jetzt sind wir bei 5600 Support. Es ist nicht ausgeschlossen dass mit einem neuen IOD auch die Geschwindigkeit erneut steigt. Um auf das Thema zurück zukommen: Von Zen 6 erwarte ich das sogar!

[iamthebear]

Wenn wir die DDR5 und DDR6 Timeline vergleichen:

Juli 2020: Version 1.0 der DDR5 Spezifikation
Herbst 2021: Alder Lake launched mit DDR4 und DDR5 Support (DDR5 noch sehr teuer)
Herbst 2022: Zen4 launched mit DDR5 Support (Preise schon annehmbar, Timings aber noch lahm)
Herbst 2023: Ab jetzt auch günstig mit akzeptablen Timings erhältlich

Mitte 2025: Version 1.0 der DDR6 Spezifikation angekündigt (+ 5 Jahre)
Herbst 2026 (entspricht Alder Lake Launch): Zen6 Launch (nur DDR5 => AMD macht sicher keine DDR5/6 Mischvarianten zwecks Boardinkompatiblität)
Herbst 2027: Ab jetzt wäre ein DDR6 only Launch denkbar
Herbst 2028: Zen7 Launch => Problemlos mit DDR6 machbar

Auch MLID bestätigt dass Zen6 mit AM5 und Zen7 mit AM6 kommt.

Dass AM6 mit DDR5 kommt können wir denke ich ausschließen. Dann müsste AMD nach einer Generation schon wieder den Sockel wechseln.
Bisher war es bei AMD immer so: Neuer Memory Standard = Neuer Sockel

PCIe 6 ist kein Grund für einen Sockelwechsel. Zumindest war es das bei AM4 nicht, da ist AMD auch während der Generation von PCI3 auf PCI4 gegangen. Ist ja alles abwärtskompatibel.
Sofern man keine Krüppel GPUs mit zu wenig VRAM hat gibt es auch keinen Zwang zum PCIe Upgrade.

Was die 16 Kern CCDs angeht: Diese wären auch mit DDR5 noch sehr sinnvoll:
a) Man kann damit 16 Kerne mit 1 CCD liefern. Ein zweites CCD ist im Gaming sowieso nicht sinnvoll nutzbar
b) Ein großer Teil der Desktop Anwendungen, die grundsätzlich von mehr als 16 Kernen profitieren ist nicht besonders speicherlastig
c) Zur Not hat man immer noch die Möglichkeit VCache zu stacken. Mit 64+128MB L3 pro CCD sollte bei den meisten Anwendungen nur mehr eher sporadisch auf den RAM zugegriffen werden
d) AMD will sich wohl kaum dauerhaft von Intel schlagen lassen. Wenn Nova Lake mit 16+32 (auf 2 CCDs) kommt, dann sollte AMD spätestens mit Zen 7 32 Kerne + SMT haben um mithalten zu können.

[HOT]

Ich weiss dass MLID das mit AM6 schreibt, aus meiner Sicht ist das aber Unsinn. Und ich hatte die Timeline schon eine Seite vorher, das sind bei Intel immer 7 Jahre gewesen. In der Praxis wurde DDR5 Ende 2022 eingeführt, was theoretisch war interessiert keine Sau. in der Paxis wirds also nichts vor allefrühestens Ende 28 bei Intel, passend zum Launch des Nachfolges des künftigen Nava Lake Sockels. falls man dann nicht aus Kostengründen trotzdem bei DDR5 bleibt, was man nicht ausschließen kann. Zeiträume verlängern sich bei fortschreitendem Kostendruck, sie werden nicht kürzer. AMD kann also theoretisch auch DDR6 launchen, aber ich bezweifle stark, dass man das IOD 2 Iterationen nutzen wird.
MLID schreibt ja auch gleichzeitig, dass Desktop Zen7 den L3 nach wie vor integrieren wird und ich geh mal davon aus, dass man auch an der Topologie nicht viel ändern wird, was kompatibel zum dann genutzten IOD wäre.

[stinki]

Mal was anderes zu Zen7 (haben wir da eigentlich noch keinen Thread zu?)...
Wenn der Tape-Out von Zen7 Ende 2026 sein soll, dann kann der meiner Meinung nach unmöglich auf A14 sein, da A14 auf der letzten TSMC Roadmap erst für Mitte 2028 steht.
https://semiwiki.com/semiconductor-manufacturers/tsmc/355121-tsmc-2025-technical-symposium-briefing/
Nach der Roadmap würde ich für Zen7 eher auf A16 oder N2X tippen.

[Badesalz]

Ich hätte auch auch noch ein x99 System mit 6950x also quadchannel mit niedrigen RAM takt.Der niedrigere Takt ist warum das nicht ordentlich skaliert. Ich bin mir nur nicht sicher, ob das aktuell immernoch so ein gottgegebenes Naturgesetz sein muss...

[HOT]

Mal was anderes zu Zen7 (haben wir da eigentlich noch keinen Thread zu?)...
Wenn der Tape-Out von Zen7 Ende 2026 sein soll, dann kann der meiner Meinung nach unmöglich auf A14 sein, da A14 auf der letzten TSMC Roadmap erst für Mitte 2028 steht.
https://semiwiki.com/semiconductor-manufacturers/tsmc/355121-tsmc-2025-technical-symposium-briefing/
Nach der Roadmap würde ich für Zen7 eher auf A16 oder N2X tippen.

Das hab ich mir auch gedacht, das kann eigentlich nicht stimmen. Zen7 dürfte dann A16 sein, weil damit schon 2026 Tapeout möglich wäre in der Risc-Phase. Die Risc-Produktion von A14 soll ja erst 2028 anlaufen.

Also nach jetzigem Stand:

Zen6 N2P
Zen7 A16P
Zen8 A14P

Das P steht, so wie ich das verstande habe, übrigens nicht mehr für eine verbesserte Variante wie bisher sondern für PPA, also backside Power-Delivery. 16A ist das was früher N2P gewesen wäre. N2, A16 und A14 gibts in klassischer und PPA-Variante.

[latiose88]

Der niedrigere Takt ist warum das nicht ordentlich skaliert. Ich bin mir nur nicht sicher, ob das aktuell immernoch so ein gottgegebenes Naturgesetz sein muss...

Naja ich habe es so niedrig eingestellt,weil es sonst die Temperatur der CPU hochgetrieben hätte. Naja es half dem Defekt allerdings nicht vorzubeugen.Sicher ist also nix.

[Nightspider]

Das Thema Bandbreite wird ja zum Teil auch nochmal entschärft dadurch das der L3 Cache bei Zen 6 deutlich ansteigen wird.

Die Basis Variante des 12C Chiplets hat 50% mehr L3 Cache und die 2 Hi X3D Variante wahrscheinlich entweder 144 oder 240 MB und damit 50% oder 150% mehr Cache als die bisherigen X3D CPUs.

V-Cache Möglichkeiten| 1 HI Stack| 2 HI Stack
64 MB Slice | 48 + 64 | 48 + 128
96 MB Slice | 48 + 96 | 48 + 192


Ist halt die Frage ob auch 96 MB ungefähr in das untere V-Cache Chiplet passen, in etwa mit den Maßen des Zen5 V-Cache Chiplets oder ob man zwecks Latenz und Größe und Preis/Slice lieber bei den 64 MB bleibt.

Ich hoffe beim Namensschema wird es nicht so eine Totalentgleisung wie bei den mobilen Ryzen AI Chips.


Und bei Zen7 fällt es mir auch noch schwer an das stinknormale Cache Schema für die Desktop CPUs zu glauben, wenn die Server Varianten einen teils ganz anderen Cache Aufbau bekommen werden.

[iamthebear]

Ich glaube nicht, dass 2 Hi im Consumer Segment tatsächlich kommen wird. Der Mehrwert gegenüber der 1 Hi Variante wäre überschaubar.

Zu Zen4 Zeiten hat man die 64MB VCache schon auf der halben CCD Größe untergebracht. Bei Zen5 hat man wohl nicht allzu viel Wert auf Density Optimierung gelegt da man sowieso einen ganzen Die braucht.
Wenn mit Zen6/7 das VCache Chiplet dann in N4 gefertigt wird dann sollten da locker 96MB für Zen6 und 128MB für Zen7 drin sein.

Allerdings denke ich nicht, dass der VCache in der Lage sein wird den Bedarf nach DDR6 vollständig zu komensieren.
Spiele nutzen pro Frame auch mehr und mehr Daten und die VCache Erhöhung ist notwendig damit man die aktuelle Hitrate halten kann. Die 96MB L3 sind aktuell in etwas das was bei Zen3 Release dessen 32MB waren.

[Nightspider]

Wie du schon sagst werden die Programme und Spiele auch anspruchsvoller und benötigen mehr Speicher, auch im Cache.

Enthusiasten hätten auch kein Problem nochmal extra für eine 2 Hi Variante zu zahlen, solange sie etwas mehr Leistung aus der Architektur bekommen oder sie dadurch einfach ruhiger schlafen können.

Es wird ja sowieso in die Richtung gehen.

[latiose88]

wieso ruhiger schlafen, haben die etws Angst das würde einfach nicht ausreichen die Bandbreite oder die CPU Leistung nicht ausreichen würde?

[Badesalz]

Enthusiasten hätten auch kein Problem nochmal extra für eine 2 Hi Variante zu zahlen, solange sie etwas mehr Leistung aus der Architektur bekommen oder sie dadurch einfach ruhiger schlafen können.Enthusiasten sind zu 98% nur noch Gamer und von denen hängen 97% im GPU-Limit.

[HOT]

Grad die Unreal Engine hat gezeigt, dass das nicht wahr ist.

[Badesalz]

Die wird ja noch bisschen besser ;) Und ja, die letzten Iterationen können auch mal mit mehr als 8 Threads real was anfangen.

Steckst du etwa in einer "aber ich will ich will" Blase?

[Nightspider]

Wenn ich Star Citizen spiele sind alle 16 Threads meines 9800X3D dauerhaft auf an der 100% Grenze dran.

Und wie schon gesagt wurde, gibts auch andere extrem CPU hungrige Spiele.

Star Citizen ist auch so ein Fall wo der zusätzliche V-Cache meistens nur dann mehr Leistung bringt, wenn die CPU Last niedriger ist, so als ob die Daten zu groß sind für die popeligen 64MB V-Cache.
Die hohen Anforderungen zeigen sich auch an der RAM Belegung die Richtung 32GB geht.

Ein Tester meinte mal das der Performance Sprung mit doppelt so großem V-Cache wahrscheinlich merklich größer wäre und der Analyse stimme ich zu, da das Game stark von besseren RAM Timings profitiert.
Da werden einfach massiv viele Daten gestreamt und parallel berechnet, da wundert es einfach nicht das der 64MB V-Cache höchstwahrscheinlich zu klein ist.

[Badesalz]

Das ist auch nicht die UE =) und halt eine grafisch aufwendige Simulation. Wie jede Simulation also entsprechend die CPU-Auslastung. Ich weiß garnicht, ob ihr nicht lesen könnt oder einfach nur nicht lesen könnt
"Enthusiasten sind zu 98% nur noch Gamer und von denen hängen 97% im GPU-Limit."

Man kann alles so programmieren, daß alles am Anschlag ist. Hardware auf schlechte Software auslegen soll jetzt DER Weg sein?

[Nightspider]

Vielleicht kannst du ja selbst nicht lesen.

Das ist auch nicht die UE =)

Hat auch keiner behauptet. Es war nur ein Beispiel.

[Badesalz]

Ja. Sehr cool.

[HOT]

Die wird ja noch bisschen besser ;) Und ja, die letzten Iterationen können auch mal mit mehr als 8 Threads real was anfangen.

Steckst du etwa in einer "aber ich will ich will" Blase?

Ich halte dieses "ein Gamer braucht nur ne starke-GPU"-Narrativ einfach fürn Märchen. Man sieht das Gegenteil.

[robbitop]

Wenn ich Star Citizen spiele sind alle 16 Threads meines 9800X3D dauerhaft auf an der 100% Grenze dran.

Und wie schon gesagt wurde, gibts auch andere extrem CPU hungrige Spiele.

Star Citizen ist auch so ein Fall wo der zusätzliche V-Cache meistens nur dann mehr Leistung bringt, wenn die CPU Last niedriger ist, so als ob die Daten zu groß sind für die popeligen 64MB V-Cache.
Die hohen Anforderungen zeigen sich auch an der RAM Belegung die Richtung 32GB geht.

Ein Tester meinte mal das der Performance Sprung mit doppelt so großem V-Cache wahrscheinlich merklich größer wäre und der Analyse stimme ich zu, da das Game stark von besseren RAM Timings profitiert.
Da werden einfach massiv viele Daten gestreamt und parallel berechnet, da wundert es einfach nicht das der 64MB V-Cache höchstwahrscheinlich zu klein ist.

Wenn die Kerne alle stark ausgelastet sind und der VCache kaum Performance bringt ist es viel eher ein Zeichen dafür dass die bitrate auch bei kleinen Caches gut ist und die Kerne gut gefüttert werden.

Sollte ein Cache zu klein sein würde er in 3x Größe eines noch kleineren trotzdem extrem viel bringen, weil die Hitrate dann viel besser wäre.

Sowas wie ein die Daten sind zu groß und es „passt nicht“ (also bringt es nichts weil entweder ganz oder gar nicht) gibt es in der Konstellation mMn nicht.

[Nightspider]

Der V-Cache bringt in SC am meisten wenn die fps schon in der 200 Region sind.

Aber bei den heftigen lows in teilweise ein 9700X mit max. Ram Tuning genauso schnell.
Also bringt der V-Cache in den extrem CPU lastigen Szenen nichts oder kaum etwas.

[latiose88]

Ja das sehe ich auch so. Gibt auch bei Anwendung Ausnahmen wo es schon eine sehr gute Bitrate vorhanden ist. Je besser also die hitrate desto weniger mehr Leistung bringt das ganze. Ab einem gewissen Punkt lässt sich die hitrate nicht mehr weiter steigern, dann bringt noch mehr Cache dann nix mehr. alleine wenn das meiste schon bei l1 cache berechnet wird, ist der Zugewinn immer kleiner. oder noch besser es passen alle berechnung schon in den l1 cache dann noch weniger. Das gute was die CPU so macht ist bei 2 gleichen Programmen da fasst die CPU das ganze besser gebündelt in den Cache, so daß es dann Ende im der Steigerung kommt.
ich habe auch schon gehofft alleine durch größere cahce mehr Leistung zu haben aber wenn selbst die verdoppelung des l2 cache zu keiner Steigerung mehr kommt, dann weiß man das man am Ende ist bei der Bandbreite. So das man sich garkeine sorgen in dieser Sache mehr machen braucht.
viel hilft wirklich nicht immer egal ob Spiel oder Anwendung es sich dreht.

[robbitop]

Der V-Cache bringt in SC am meisten wenn die fps schon in der 200 Region sind.

Aber bei den heftigen lows in teilweise ein 9700X mit max. Ram Tuning genauso schnell.
Also bringt der V-Cache in den extrem CPU lastigen Szenen nichts oder kaum etwas.
Weil dann einfach die hitrate nicht limitiert. Ein großer Cache sorgt dafür dass die CPU weniger auf Daten warten muss. Bringt er wenig, muss auch mit kleinerem Cache nicht viel auf Daten gewartet werden. Die hohe CPU Last und dass alle 16Threads gut genutzt werden können spricht dafür dass ggf. auch Wartezeiten mit anderen Threads ausgefüllt werden können.

[Badesalz]

Also bringt der V-Cache in den extrem CPU lastigen Szenen nichts oder kaum etwas.Das ist zwar richtig, aber eigentlich schon nach den ersten paar Wochen nach dem Launch von 5800X3D bekannt gewesen.

Wir sind jetzt im Zen6 Thread ;)

[Nightspider]

Weil dann einfach die hitrate nicht limitiert. Ein großer Cache sorgt dafür dass die CPU weniger auf Daten warten muss. Bringt er wenig, muss auch mit kleinerem Cache nicht viel auf Daten gewartet werden. Die hohe CPU Last und dass alle 16Threads gut genutzt werden können spricht dafür dass ggf. auch Wartezeiten mit anderen Threads ausgefüllt werden können.

Das schneller RAM in dem Beispiel viel bringt deutet doch aber darauf hin das die Architektur noch durch die RAM Latenzen ausgebremst wird.
Genau da müsste der V-Cache eigentlich viel bringen, tut es aber nicht.

Bestätigen lässt sich die These, dass die 64MB V-Cache in dem Beispiel zu klein sind, natürlich erst wenn es man 1-HI CPUs gegen 2-HI CPUs testen kann.

Schon alleine um sowas testen zu können wäre es schön wenn wir bei Zen6 die Option mit 2 Slices V-Cache bekommen.

[latiose88]

hm was sind denn 1 und 2 Hi cpus ausgeschrieben?

[Der_Korken]

Ich frage mich bei den ganzen Spekulationen um V-Cache-Größen, wie das eigentlich mit dem TLB funktioniert. Bei Zen 5 hat ein Kern 3072 L2TLB-Einträge, d.h. damit kann man maximal 12MB Cache addressieren (und 48(?)MB wenn man aufeinanderfolgende (?) Seiten zusammenfassen kann). Wo geht die Query bei einem L2TLB-Miss hin? Immer in den RAM? Da muss man echt schauen, wieviel ein noch größerer L3 überhaupt noch was bringt, wenn ein einzelner Kern sowieso bis in den RAM muss, um überhaupt die richtige Line im L3 zu finden. Klar können mehr Kerne mehr vom Cache abbilden in ihren TLBs, aber für Daten, die von mehreren Kernen genutzt werden werden, müssen auch die TLB-Einträge repliziert werden.

Bei 2Hi-Lösungen müsste also eigentlich auch der TLB kräftig mitwachsen, damit der große Cache überhaupt was bringt. Allerdings kostet der TLB bereits heute viel Platz im Kern und dessen Latenz wird auch immer größer. Afaik sind das bereits heute 7 Takte für den L2TLB, d.h. der L2-Zugriff dauert bereits heute schon 21 statt 14 Takte, wenn die Adresse nicht im 96-entry L1TLB war. Da könnte man fast schon über einen dreistufen TLB nachdenken - was mich wieder zu der Frage führt, wann wir denn endlich mal größere Pagesizes nutzen ;).

[robbitop]

Das schneller RAM in dem Beispiel viel bringt deutet doch aber darauf hin das die Architektur noch durch die RAM Latenzen ausgebremst wird.
Genau da müsste der V-Cache eigentlich viel bringen, tut es aber nicht.

Bestätigen lässt sich die These, dass die 64MB V-Cache in dem Beispiel zu klein sind, natürlich erst wenn es man 1-HI CPUs gegen 2-HI CPUs testen kann.

Schon alleine um sowas testen zu können wäre es schön wenn wir bei Zen6 die Option mit 2 Slices V-Cache bekommen.

Schneller RAM heißt aber auch Bandbreite. Wenn alle 16 Threads ausgelastet sind, muss man die auch füttern.
Hitrate scheint jedenfalls nicht der Flaschenhals zu sein.

[aceCrasher]

hm was sind denn 1 und 2 Hi cpus ausgeschrieben?
1Hi -> 1x Die 3D VCache
2Hi -> 2x Dies 3D VCache

[Zossel]

Ich frage mich bei den ganzen Spekulationen um V-Cache-Größen, wie das eigentlich mit dem TLB funktioniert. Bei Zen 5 hat ein Kern 3072 L2TLB-Einträge, d.h. damit kann man maximal 12MB Cache addressieren (und 48(?)MB wenn man aufeinanderfolgende (?) Seiten zusammenfassen kann). Wo geht die Query bei einem L2TLB-Miss hin? Immer in den RAM? Da muss man echt schauen, wieviel ein noch größerer L3 überhaupt noch was bringt, wenn ein einzelner Kern sowieso bis in den RAM muss, um überhaupt die richtige Line im L3 zu finden. Klar können mehr Kerne mehr vom Cache abbilden in ihren TLBs, aber für Daten, die von mehreren Kernen genutzt werden werden, müssen auch die TLB-Einträge repliziert werden.

Sieht der L3 überhaupt logische Adressen?

[HOT]

Der große Vorteil bei 2 Stacks wäre die fast gleiche Latenz bei deutlich mehr Cache, wenn ich mich nicht irre. Das könnte also auch für Desktop gut sein. Ob das auch kommt, kann man nicht sagen.

[Nightspider]

Schneller RAM heißt aber auch Bandbreite. Wenn alle 16 Threads ausgelastet sind, muss man die auch füttern.
Hitrate scheint jedenfalls nicht der Flaschenhals zu sein.

Wenn die RAM Timings hohe Auswirkungen haben kannst du die Hitrate als Problem doch nicht ausschließen, imo.

Wenn die Bandbreite der Flaschenhals wäre, hätte man das wohl schon vor langer Zeit rausgefunden.

[HOT]

Das schneller RAM in dem Beispiel viel bringt deutet doch aber darauf hin das die Architektur noch durch die RAM Latenzen ausgebremst wird.
Genau da müsste der V-Cache eigentlich viel bringen, tut es aber nicht.

Bestätigen lässt sich die These, dass die 64MB V-Cache in dem Beispiel zu klein sind, natürlich erst wenn es man 1-HI CPUs gegen 2-HI CPUs testen kann.

Schon alleine um sowas testen zu können wäre es schön wenn wir bei Zen6 die Option mit 2 Slices V-Cache bekommen.

Versteh ich nicht, die 1% und 0,1% sind doch auch bei X3D viel höher als non-X3D? Klar, nicht überall, aber schon doch auch, also kann diese Theorie ja nicht stimmen...

[Der_Korken]

Sieht der L3 überhaupt logische Adressen?

Die afaik sieht nicht mal der L1. Aber meine Frage ist ob oder wie sehr der TLB zum Flaschenhals wird, wenn ich mit der Cache-Größe immer weiter nach oben gehe.

[Badesalz]

@korken
Gibt es s keine Vergleichswerte wie die Hersteller das bisher gegeneinander skaliert haben? ;)

[Der_Korken]

@korken
Gibt es s keine Vergleichswerte wie die Hersteller das bisher gegeneinander skaliert haben? ;)

Ich könnte mir jetzt historische Daten raussuchen zu L3-Größe vs vom TLB abgedeckte Größe aus Sicht eines einzelnen Kerns und allen Kernen eines CCXs:

Zen 1: 8MB L3 vs 6MB (1536 Entries) vs 24MB (4er CCD)
Zen 2: 16MB L3 vs 8MB (2048 Entries) vs 32MB (4er CCD)
Zen 3: 32MB L3 vs 8MB (2048 Entries) vs 64MB (8er CCD)
Zen 4: 32MB L3 vs 12MB (3072 Entries) vs 96MB (8er CCD)
Zen 5: 32MB L3 vs 16MB (4096 Entries) vs 128MB (8er CCD) <-- Zen 5 hat doch 4K und nicht 3K wie ich zuerst schrieb
Zen 5-3D: 96MB L3 vs 16MB (4096 Entries) vs 128MB (8er CCD)

Der TLB ist tendenziell immer weiter zurückgefallen. Mit Zen 4 und 5 hat er wieder etwas Boden gut gemacht, aber nur auf die nicht-gestackte Variante. Wenn man sich die zunehmende Verbreitung von 3D-Cache-Modellen noch dazudenkt, dann setzt sich der alte Trend eher fort.

Daher meine Frage, ob das noch ewig so funktioniert. Vielleicht wetten die CPU-Hersteller auch darauf, dass sich nach Äonen doch mal eine größere Pagesize unter Windows durchsetzt, um alle TLB- und L1-Größenprobleme zu lösen.

Edit: Bei Intel sind es übrigens seit Sunny Cove bis heute 2048 Entries. In der Zeit ist der L3 von 16MB auf 36MB gewachsen.

[Mortalvision]

TLB un L1 sind nunmal fürs bare minimum gedacht. Nicht, dass man das nicht größer gestalten könnte. Aber afaik gehts da auch um Sicherheit.

[Zossel]

Ich könnte mir jetzt historische Daten raussuchen zu L3-Größe vs vom TLB abgedeckte Größe aus Sicht eines einzelnen Kerns und allen Kernen eines CCXs:

Zen 1: 8MB L3 vs 6MB (1536 Entries) vs 24MB (4er CCD)
Zen 2: 16MB L3 vs 8MB (2048 Entries) vs 32MB (4er CCD)
Zen 3: 32MB L3 vs 8MB (2048 Entries) vs 64MB (8er CCD)
Zen 4: 32MB L3 vs 12MB (3072 Entries) vs 96MB (8er CCD)
Zen 5: 32MB L3 vs 16MB (4096 Entries) vs 128MB (8er CCD) <-- Zen 5 hat doch 4K und nicht 3K wie ich zuerst schrieb
Zen 5-3D: 96MB L3 vs 16MB (4096 Entries) vs 128MB (8er CCD)

Der TLB ist tendenziell immer weiter zurückgefallen. Mit Zen 4 und 5 hat er wieder etwas Boden gut gemacht, aber nur auf die nicht-gestackte Variante. Wenn man sich die zunehmende Verbreitung von 3D-Cache-Modellen noch dazudenkt, dann setzt sich der alte Trend eher fort.

Daher meine Frage, ob das noch ewig so funktioniert. Vielleicht wetten die CPU-Hersteller auch darauf, dass sich nach Äonen doch mal eine größere Pagesize unter Windows durchsetzt, um alle TLB- und L1-Größenprobleme zu lösen.

Edit: Bei Intel sind es übrigens seit Sunny Cove bis heute 2048 Entries. In der Zeit ist der L3 von 16MB auf 36MB gewachsen.

Ich hatte mal eine Messreihe mit 4K vs. 2M via GLIBC_TUNABLES=glibc.malloc.hugetlb=x gemacht. Ergebnisse im Anhang.

[Badesalz]

Ich könnte mir jetzt historische Daten raussuchen zu L3-Größe vs vom TLB abgedeckte Größe aus Sicht eines einzelnen Kerns und allen Kernen eines CCXs: Weiß wer was Apple da diesbezüglich bisher getrieben hat?

[Der_Korken]

Weiß wer was Apple da diesbezüglich bisher getrieben hat?

Ich ziehe meine Infos immer aus diesen Diagrammen: https://drive.google.com/drive/folders/1W4CIRKtNML74BKjSbXerRsIzAUk3ppSG

Sind natürlich nicht offiziell, aber ich glaube der Dude versucht die fehlenden Zahlen durch micro benchmarks zu füllen. Deswegen stehen da manchmal auffällig krumme Zahlen (noch besser wäre natürlich geschätzte Werte kenntlich zu machen gegenüber bestätigten).

Da sind es 3072 L2TLB und 256 L1TLB. Firestorm war 3072/128. Hier muss man aber bedenken, dass die Pagesize 16K ist, d.h. L1TLB deckt 4MB ab und L2TLB sogar 48MB, obwohl der shared L2 nur 16MB groß ist.

[Badesalz]

Mehr als 16k kann auch mäh werden
https://en.wikipedia.org/wiki/Fragmentation_(computing)#Internal_fragmentation

IA-64 hatte wenigsten 8k...

[Zossel]

Mehr als 16k kann auch mäh werden
https://en.wikipedia.org/wiki/Fragmentation_(computing)#Internal_fragmentation

IA-64 hatte wenigsten 8KB...

In dem Link geht es primär um logischen bzw. linearen Adressraum.

[Der_Korken]

Ich hatte mal eine Messreihe mit 4K vs. 2M via GLIBC_TUNABLES=glibc.malloc.hugetlb=x gemacht. Ergebnisse im Anhang.

Welche CPU? Ist die TLBmiss-Spalte die absolute Zahl an Misses? Die geht schon ordentlich runter, auch wenn der Anteil an der Gesamtzeit nicht sehr hoch ist. Welche Größen sind hugetlb 0, 1 und 2?

[Zossel]

Welche CPU?

$ lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 48 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 16
On-line CPU(s) list: 0-15
Vendor ID: AuthenticAMD
Model name: AMD Ryzen 7 7700 8-Core Processor
CPU family: 25
Model: 97
Thread(s) per core: 2
Core(s) per socket: 8
Socket(s): 1
Stepping: 2
CPU(s) scaling MHz: 23%
CPU max MHz: 5389,0000
CPU min MHz: 400,0000
BogoMIPS: 7585,16
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good amd_lbr_v2 nopl nonstop_tsc cpuid extd_apicid aperfmpe
rf rapl pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core p
erfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate ssbd mba perfmon_v2 ibrs ibpb stibp ibrs_enhanced vmmcall fsgsbase bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a avx512f avx512dq rdseed adx smap avx512ifma clflu
shopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local user_shstk avx512_bf16 clzero irperf xsaveerptr rdpru wbnoinvd cppc arat npt lbrv svm_lock nrip_
save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif x2avic v_spec_ctrl vnmi avx512vbmi umip pku ospke avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpo
pcntdq rdpid overflow_recov succor smca fsrm flush_l1d
Virtualization features:
Virtualization: AMD-V
Caches (sum of all):
L1d: 256 KiB (8 instances)
L1i: 256 KiB (8 instances)
L2: 8 MiB (8 instances)
L3: 32 MiB (1 instance)
NUMA:
NUMA node(s): 1
NUMA node0 CPU(s): 0-15
Vulnerabilities:
Gather data sampling: Not affected
Itlb multihit: Not affected
L1tf: Not affected
Mds: Not affected
Meltdown: Not affected
Mmio stale data: Not affected
Reg file data sampling: Not affected
Retbleed: Not affected
Spec rstack overflow: Mitigation; Safe RET
Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl
Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Spectre v2: Mitigation; Enhanced / Automatic IBRS; IBPB conditional; STIBP always-on; RSB filling; PBRSB-eIBRS Not affected; BHI Not affected
Srbds: Not affected
Tsx async abort: Not affected
$

Ist die TLBmiss-Spalte die absolute Zahl an Misses? Die geht schon ordentlich runter, auch wenn der Anteil an der Gesamtzeit nicht sehr hoch ist. Welche Größen sind hugetlb 0, 1 und 2?

Testscript:

#!/bin/bash
bash -c 'export log=/tmp/log-$$; echo $log; for cmd in zstd bzip2 xz lzip gzip; do for level in $(seq 0 9); do for huge in $(seq 0 2); do for i in $(seq 0 4); do dd if=/dev/zero of=/dev/null conv=ascii count=64 bs=1M 2> /dev/null; perf stat -e dTLB-load-misses,iTLB-load-misses sh -c "GLIBC_TUNABLES=glibc.malloc.hugetlb=$huge $cmd -$(if [ $cmd = "bzip2" ] && [ $level -eq 0 ]; then echo 1; else if [ $cmd = zstd ]; then echo $(( $level * 2 + 1 )); else echo $level; fi fi) < b > /dev/null" 2>> $log ; done; done; done; done'


tlbmiss ist der Performance-Counter von der CPU.

Tunable:


Tunable: glibc.malloc.hugetlb

This tunable controls the usage of Huge Pages on malloc calls. The default value is 0, which disables any additional support on malloc.

Setting its value to 1 enables the use of madvise with MADV_HUGEPAGE after memory allocation with mmap. It is enabled only if the system supports Transparent Huge Page (currently only on Linux).

Setting its value to 2 enables the use of Huge Page directly with mmap with the use of MAP_HUGETLB flag. The huge page size to use will be the default one provided by the system. A value larger than 2 specifies huge page size, which will be matched against the system supported ones. If provided value is invalid, MAP_HUGETLB will not be used.

https://www.gnu.org/software/libc/manual/html_node/Memory-Allocation-Tunables.html

[Badesalz]

In dem Link geht es primär um logischen bzw. linearen Adressraum.Ja mir ging es um die sekundäre Erwähnung... Internal fragmentation ist beim paging halt auch ein Thema.

[Zossel]

Ja mir ging es um die sekundäre Erwähnung... Internal fragmentation ist beim paging halt auch ein Thema.

Naja, NVMe-Platten fühlen sich ja erst mit mehreren parallelen Requests erst richtig
wohl.
Aber andere Pagesizes als 4K oder 2M könnte X64 durchaus vertragen.

Hier noch eine Messreihe wie sich eine 980Pro bei kleinen random IO (4K) mit verschiedener Parallelität schlägt:
"mul" ist das Produkt aus "jobs" und "depth", "clat" ist die completion latency in µs.
$ sh ./stat.sh /tmp/out | sort -n -k1
mul jobs depth clat iops bw
1 1 1 15.56 48.50 199.00
2 1 2 13.01 130.00 534.00
2 2 1 15.16 99.30 407.00
4 1 4 11.68 267.00 1095.00
4 2 2 14.01 224.00 919.00
4 4 1 15.10 199.00 815.00
8 1 8 26.76 266.00 1089.00
8 2 4 12.01 524.00 2146.00
8 4 2 16.27 384.00 1573.00
8 8 1 15.24 393.00 1611.00
12 1 12 40.81 272.00 1115.00
12 12 1 17.21 529.00 2167.00
16 1 16 56.70 267.00 1092.00
16 2 8 26.65 534.00 2189.00
16 4 4 17.67 790.00 3235.00
16 8 2 24.54 543.00 2223.00
16 16 1 24.61 541.00 2217.00
24 2 12 41.70 534.00 2189.00
24 12 2 24.07 828.00 3391.00
32 2 16 56.62 534.00 2187.00
32 4 8 25.90 1119.00 4585.00
32 8 4 26.57 1080.00 4422.00
32 16 2 34.18 832.00 3406.00
48 4 12 39.64 1128.00 4621.00
48 12 4 38.86 1105.00 4527.00
64 4 16 53.77 1131.00 4631.00
64 8 8 52.70 1158.00 4744.00
64 16 4 52.29 1114.00 4564.00
96 8 12 80.15 1160.00 4752.00
96 12 8 79.62 1137.00 4657.00
128 8 16 107.73 1160.00 4749.00
128 16 8 107.19 1135.00 4649.00
144 12 12 121.87 1145.00 4691.00
192 12 16 163.30 1140.00 4670.00
192 16 12 162.30 1142.00 4677.00
256 16 16 215.43 1134.00 4644.00
$ sh ./stat.sh /tmp/out | sort -n -k4
mul jobs depth clat iops bw
4 1 4 11.68 267.00 1095.00
8 2 4 12.01 524.00 2146.00
2 1 2 13.01 130.00 534.00
4 2 2 14.01 224.00 919.00
4 4 1 15.10 199.00 815.00
2 2 1 15.16 99.30 407.00
8 8 1 15.24 393.00 1611.00
1 1 1 15.56 48.50 199.00
8 4 2 16.27 384.00 1573.00
12 12 1 17.21 529.00 2167.00
16 4 4 17.67 790.00 3235.00
24 12 2 24.07 828.00 3391.00
16 8 2 24.54 543.00 2223.00
16 16 1 24.61 541.00 2217.00
32 4 8 25.90 1119.00 4585.00
32 8 4 26.57 1080.00 4422.00
16 2 8 26.65 534.00 2189.00
8 1 8 26.76 266.00 1089.00
32 16 2 34.18 832.00 3406.00
48 12 4 38.86 1105.00 4527.00
48 4 12 39.64 1128.00 4621.00
12 1 12 40.81 272.00 1115.00
24 2 12 41.70 534.00 2189.00
64 16 4 52.29 1114.00 4564.00
64 8 8 52.70 1158.00 4744.00
64 4 16 53.77 1131.00 4631.00
32 2 16 56.62 534.00 2187.00
16 1 16 56.70 267.00 1092.00
96 12 8 79.62 1137.00 4657.00
96 8 12 80.15 1160.00 4752.00
128 16 8 107.19 1135.00 4649.00
128 8 16 107.73 1160.00 4749.00
144 12 12 121.87 1145.00 4691.00
192 16 12 162.30 1142.00 4677.00
192 12 16 163.30 1140.00 4670.00
256 16 16 215.43 1134.00 4644.00
$ sh ./stat.sh /tmp/out | sort -n -k6
mul jobs depth clat iops bw
1 1 1 15.56 48.50 199.00
2 2 1 15.16 99.30 407.00
2 1 2 13.01 130.00 534.00
4 4 1 15.10 199.00 815.00
4 2 2 14.01 224.00 919.00
8 1 8 26.76 266.00 1089.00
16 1 16 56.70 267.00 1092.00
4 1 4 11.68 267.00 1095.00
12 1 12 40.81 272.00 1115.00
8 4 2 16.27 384.00 1573.00
8 8 1 15.24 393.00 1611.00
8 2 4 12.01 524.00 2146.00
12 12 1 17.21 529.00 2167.00
32 2 16 56.62 534.00 2187.00
16 2 8 26.65 534.00 2189.00
24 2 12 41.70 534.00 2189.00
16 16 1 24.61 541.00 2217.00
16 8 2 24.54 543.00 2223.00
16 4 4 17.67 790.00 3235.00
24 12 2 24.07 828.00 3391.00
32 16 2 34.18 832.00 3406.00
32 8 4 26.57 1080.00 4422.00
48 12 4 38.86 1105.00 4527.00
64 16 4 52.29 1114.00 4564.00
32 4 8 25.90 1119.00 4585.00
48 4 12 39.64 1128.00 4621.00
64 4 16 53.77 1131.00 4631.00
256 16 16 215.43 1134.00 4644.00
128 16 8 107.19 1135.00 4649.00
96 12 8 79.62 1137.00 4657.00
192 12 16 163.30 1140.00 4670.00
192 16 12 162.30 1142.00 4677.00
144 12 12 121.87 1145.00 4691.00
64 8 8 52.70 1158.00 4744.00
128 8 16 107.73 1160.00 4749.00
96 8 12 80.15 1160.00 4752.00
$

Testscript:
for jobs in 1 2 4 8 12 16
do
for depth in 1 2 4 8 12 16
do
printf "===== %3d %3d %3s\n" $(($jobs * $depth)) $jobs $depth
sudo fio --readonly --direct=1 --name=test --size=10G --bs=4k --rw=randread --filename=/dev/nvme0n1 --numjobs=$jobs --ioengine=libaio --iodepth=$depth --group_reporting
done
done

Übersicht der Ergebnisse bauen: (Quick & Dirty & Broken :-)
awk '
BEGIN { printf("%10s %10s %10s %10s %10s %10s\n", "mul", "jobs", "depth", "clat", "iops", "bw"); }
/^====/ && first { printf("%10d %10d %10d %10.2f %10.2f %10.2f\n", mul, jobs, depth, clat, iops, bw); mul = $2; jobs = $3; depth = $4; }
/^====/ && !first++ { mul = $2; jobs = $3; depth = $4; }
/^ *clat \(/ { gsub(/^.+=/,"", $5); gsub(/,$/,"", $5); clat = $5 * 1; if ($2 ~ /nsec/) { clat /= 1000; } }
/^ *read:/ { gsub(/^.+=/,"", $2); gsub(/k,$/,"", $2); iops = $2 * 1; gsub(/^\(/, "", $4); gsub(/MB\/s\)/, "", $4); bw = $4; }
END { printf("%10d %10d %10d %10.2f %10.2f %10.2f\n", mul, jobs, depth, clat, iops, bw); mul = $2; jobs = $3; depth = $4; }
' $1


BTW: Ich würde das gerne mal mit anderen NVMe-Platten vergleichen.

[Badesalz]

Aber andere Pagesizes als 4K oder 2M könnte X64 durchaus vertragen.Eben. 2025 könnte man darüber auch mal ernsthafter nachdenken.

Immerhin haben wir ja jetzt die "x86 Ecosystem Advisory Group" :rolleyes:

[Nightspider]

MLID (https://youtu.be/6aZeBe6p6eY?t=344) hat Taktraten von weiteren AMD Quellen erfahren und umschreibt sie mit "massive core clocks", "insane high clock speeds, you would not believe me", "roadblock, they are trying to get passed, is still well above 6 Ghz"

Da kann man jetzt natürlich spekulieren was er gehört hat, ob es 6,4 Ghz oder 6,7 Ghz waren. Er will die Zahlen erstmal mit weiteren Quellen verifizieren bevor es sie teilt.

Das Zen4 Design Team, das jetzt an Zen6 arbeitet, hat mit Zen4 ja auch schon abgeliefert.


Mit dem Sprung von 2 Full Nodes wird Zen6 so oder so ein großer Wurf und ein Musthave für viele Gamer.

[MSABK]

Ich würde da jetzt nicht auf den HypeTrain aufspringen. 6 Ghz könnten realistisch sein. Mehr würde ich da wegen dem Verbrauch nicht erwarten.

[Nightspider]

6 Ghz könnten realistisch sein.

Über 6 Ghz war ja schon alleine die Zielvorgabe.

Mehr würde ich da wegen dem Verbrauch nicht erwarten.

N2P soll 30-40% sparsamer sein als N3E und Zen5 läuft sogar nur in N4 vom Band.
Je nachdem ob von N4 oder N4P kommen dann nochmal 8-35% Ersparnis zu N3E hinzu.

5,7 Ghz hat man bereits mit N5 geschafft.

[Badesalz]

Über 6 Ghz war ja schon alleine die Zielvorgabe.
Womit 6.1Ghz auch realistisch sind... ABER, angesichts dessen (Prozessdaten) wäre alles bis 6.7Ghz tatsächlich noch kein Hypertrain. Es sei denn das wäre der X3D :wink:

[dildo4u]

Ich würde da jetzt nicht auf den HypeTrain aufspringen. 6 Ghz könnten realistisch sein. Mehr würde ich da wegen dem Verbrauch nicht erwarten.
Das ist ein größere Sprung da man 3nm übergeht daher müssen die 6Ghz fallen.

Das sind 3 Jahre zwischen den Zen 5 und Zen 6 Nodes.
Das ist der Zeitliche Abstand von Zen 1 und 3.

https://i.ibb.co/NngVfyJG/IMG-2567.png (https://ibb.co/k6VHzSwP)

[latiose88]

oh wow 6 GHz, das wird echt krass. Wenn schon beim 7960x wo ich mal gehabt hatte von 4,8 GHz auf 5 GHz rund 3-4 % mehrleistung gebracht hatte, freut es mich sehr das nun noch mehr takt kommen wird. Das waren dann vom 9950x ausgehend gleich 800 mhz mindestens mehr allcore takt. Den merkt wirklich jeder bei jeder Anwendung. Mich freut es.

[Lehdro]

Ich würde da jetzt nicht auf den HypeTrain aufspringen.
Sehe ich anders:
+ >10% Clock
+ >10% IPC
+ 50% Cores im CCX
+ L3 Cache pro CCX (weil mehr Cores im CCX wo der L3 geshared wird)
+ mehr 3D Vcache (ist quasi garantiert, weil es mit dem CCX skaliert, wo der L3 auch ansteigt, gehe von 96 MiB 3D Vcache aus -> insgesamt (48+96) 144 MiB L3 pro CCD)
Potenziell:
+ neues IOD
+ Bridge Chips für bessere Latenzen

[CrazyIvan]

Weitestgehend+1
Bridge Chips eher nicht, sondern InFO RDL wie bei N31.
Bei den Latenzen würde ich keine Wunder erwarten, aber bessere Energieeffizienz und damit mehr nutzbare TDP für die Kerne.

[Tarkin]

Sehe ich anders:
+ >10% Clock
+ >10% IPC
+ 50% Cores im CCX
+ L3 Cache pro CCX (weil mehr Cores im CCX wo der L3 geshared wird)
+ mehr 3D Vcache (ist quasi garantiert, weil es mit dem CCX skaliert, wo der L3 auch ansteigt, gehe von 96 MiB 3D Vcache aus -> insgesamt (48+96) 144 MiB L3 pro CCD)
Potenziell:
+ neues IOD
+ Bridge Chips für bessere Latenzen

Jup und AMD hat ja auch schon bekanntgegeben, dass Verano/Verona 1.7x mal Turin sein soll (bei +33,33% cores von 192 auf 256)

Wenn man das mit +50% cores am Desktop hochrechnet, kommt rund 2x an reiner core performance raus ;)

Und man darf auch nicht vergessen - der sprung von N4 auf N2 - das ist schon ziemlich krass. Wenn Zen 6 Desktop nicht ~ 100% schneller (bei MT Workloads) wird als Zen 5, dann haben sie was falsch gemacht IMO.

[Der_Korken]

Jup und AMD hat ja auch schon bekanntgegeben, dass Verano/Verona 1.7x mal Turin sein soll (bei +33,33% cores von 192 auf 256)

Wenn man das mit +50% cores am Desktop hochrechnet, kommt rund 2x an reiner core performance raus ;)

Und man darf auch nicht vergessen - der sprung von N4 auf N2 - das ist schon ziemlich krass. Wenn Zen 6 Desktop nicht ~ 100% schneller (bei MT Workloads) wird als Zen 5, dann haben sie was falsch gemacht IMO.

Ist schon wieder Hype-Train-Zeit wie bei "Zen 5%" und den kolportierten 32% IPC-Gains? Zur Erdung nochmal diese alte geleakte Slide: https://media.overclock3d.net/2023/09/AMD-Zen-5-zen-6-Roadmap-image.jpg

"FP16 for AI/ML" <- daher könnte der Wind wehen, wenn AMD irgendwelche Performance-Sprünge bei Server-Produkten angibt. Genauso wie die Beimischung von AVX512-Benchmarks den IPC-Schnitt von Zen 5 gegenüber Zen4 nach oben gezogen hat.

[HOT]

Bei NV und Intel ist das normal, bei AMD ist es immer "hypetrain".
Klar wird diese Generation sehr sicher mehr Leistung auffahren als die letzten 2, IPC-Sprung, massiver node-Sprung, deutlich mehr Cache, neues I/O und obendrein noch größere CCX, das ist ja alles auf einmal, klar wird das übel.

[Tarkin]

Ist schon wieder Hype-Train-Zeit wie bei "Zen 5%" und den kolportierten 32% IPC-Gains? Zur Erdung nochmal diese alte geleakte Slide: https://media.overclock3d.net/2023/09/AMD-Zen-5-zen-6-Roadmap-image.jpg

"FP16 for AI/ML" <- daher könnte der Wind wehen, wenn AMD irgendwelche Performance-Sprünge bei Server-Produkten angibt. Genauso wie die Beimischung von AVX512-Benchmarks den IPC-Schnitt von Zen 5 gegenüber Zen4 nach oben gezogen hat.

Möchte mal wisse das daran so furchtbar unrealistisch sein soll wenn alleine +50% cores kommen

1,5 (cores) x 1,15 Clocks x 1,15 IPC und man ist schon bei 1.98x - unrealistisch? Mit diesem Node Jump ist das locker möglich. AMD wird nicht von 1.7x Gen vs Gen sprechen und irgendwelche AI/ML Task meinen. Das wäre nämlich dann in den End Notes drinnen gewesen - war es aber nicht. Da ist "general compute performance" gemeint. Alles andere wäre idiotisch.

siehe https://www.amd.com/content/dam/amd/en/documents/corporate/events/advancing-ai-2025-distribution-deck.pdf

[latiose88]

diese steigerung ist aber nur bei perfekter ausnutzung so.Was ja meistens nicht so der fall ist.100% finde ich auch übertrieben.
Am ende würde man nur bei so hoher Erwartung Enttäuscht sein.
Wenn ne Anwendung mal als Beispeil nicht so gut mit AVX sich steigern lässt,die Kerne nicht ganz Optimal ausgelastet werden können also bei 2x12 Kernen zum Beispiel ,nur ohne SMT es so der fall wäre oder wenn weniger Kerner die selbe Leistung bringt wie 16 vs 24 Kerne als Beispiel,Takt durch Stromverbrauch wie maximal 200 Watt Limitiert werden ,dann noch der Größere Cache egal wäre weil alles in L1 Cache passt ,dann noch der ganze AI usw unwichtig wäre weil es das nicht beherscht.Dann bliebe am Ende nur noch IPC übrig bei gleichen Takt oder durch höheren Allcore Takt.
Dann ist es vorbei mit so hoher Steigerung.Zumindest wenn das stimmt die 32 % IPC ist nur der durschnitt.Es gibt Anwendung da ist nur dann was von 20-25 % Anstatt 32 % oder sogar weniger plus der höhere Takt.
Der rest kann also klappen ,muss aber nicht.Zumindest mit +25 % realistisch rechne ich schon.
Ist die Frage ob das wirklich ankommt.Erwarte einfach nicht zu viel,dann ist die Freude auch einfach größer.

Ich weis das ich von AVX nicht so Profitieren werde,darum war auch von Zen 4 zu Zen 5 im Grunde genommen für mich eigentlich ein Stillstand gewesen.

Das einzige Postive war das Zen 5 Kühler als Zen 4 ist.Das ist am Ende doch was Postives,auch wenn es nicht mehr Leistung gab.Bei mir war also IPC Steigerung am Ende also daneben gegangen.Das was verbessert worden ist,konnte die Anwendung nicht steigern.
Denke mal das sich bei Zen 6 was grundlegendes Ändern wird,so das der Zen 4 Effekt auch wieder eintreten wird.
Bei mir war es bei mir Taktbereinigt von Zen 3 auf Zen 4 auf 7 % mehrleistung bei gleichen Takt gewesen.Die andere Leistung kam durch höheren Allcore Leistung an.

Das war allerdings ja nur ein kleiner Sprung gewesen.Zumindest kann ich auf Zen 6 mit mindestens 14 % IPC Steigerung + durch den höheren Allcore Takt rechnen.
Und wenn es noch besser läuft sogar mit mindestens 10-15 % weniger Stromverbrauch bei den restlichen mehrleistung.
Das wäre mehr als ich erwarten würde.
Also was ich toll finde,mindestens 15% mehr IPC steigerung,10-15 % mehr Allcore Takt und 10-15 % weniger Stromverbrauch.
Das würde sich echt sehen lassen.

Was ich nicht weis,ist meine Anwendung Latenz Kritisch oder nicht.Bei 12 Kernen fällt die Latenz Probleme also weg.
Bei 2x12 Kernen vs 4x8 Kernen auf 24 Kerne gestuzt,wird es interessant werden.Da wird die Latenz mit sicherheit aus sinken.

Was mir aufgefallen war,8 Kerne sind eigentlich nicht viel wenn man es mit 16 Kernen vergleicht.Aber wenn der Abstand so gering wäre,kann man nur speklieren,ist die Latenz mit 2 Chiplet wirklich so hoch oder hat die Anwendung Problem mit so vielen Kernen umzugehen.Bei 15 % abstand frage ich mich genau das.

Ich müsste das also untersuchen warum das bei mir der Fall wäre.Wenn ich richtig liege,müsste der 12 Kern Chiplet bei der Leistung förmlich explodieren,weil nix mehr bremst.

Ich werde das schon noch heraus finden und die Latenz die scheinbar bremst ,wird sich dann lösen. Ich mag nicht das die Anwendung ausgebremst werden.Aber gut erst mal schauen wie die Produkte so werden.

[Der_Korken]

Bei NV und Intel ist das normal, bei AMD ist es immer "hypetrain".
Klar wird diese Generation sehr sicher mehr Leistung auffahren als die letzten 2, IPC-Sprung, massiver node-Sprung, deutlich mehr Cache, neues I/O und obendrein noch größere CCX, das ist ja alles auf einmal, klar wird das übel.

Imho wurden und werden neue Gens von Nvidia und Intel nicht ansatzweise so gehyped wie die von AMD. Natürlich nicht von den Firmen selbst, sondern von "Leakern". Zen 5 sollte der größe Umbau seit Zen 1 sein, ist aber faktisch der kleinste Generationensprung seit Zen 1 gewesen - zumindest aus Sicht von Normalnutzern. Die Datacenter-Performance ist gut, nicht zuletzt durch deren durchaus beeindruckende Full-AVX512-Implementierung.

Ich kenne die Interviews von AMD, wo sie davon reden, dass erst künftige Generationen das volle Potenzial des neuen Unterbaus zeigen sollen und auch die Mikrobenchmarks von Chips&Cheese. Die Frage ist nur, ob AMD mit diesem Potenzial auch das meint, von dem wir gerne hoffen, dass sie es meinen. Es wäre durchaus denkbar, dass die Architektur weiter auf Datacenter optimiert wird und die Gewinne für Ottonormalnutzer (d.h. für mich im wesentlichen 1T- und INT-Performance) wieder nur spärlich ausfallen.

Möchte mal wisse das daran so furchtbar unrealistisch sein soll wenn alleine +50% cores kommen

1,5 (cores) x 1,15 Clocks x 1,15 IPC und man ist schon bei 1.98x - unrealistisch? Mit diesem Node Jump ist das locker möglich. AMD wird nicht von 1.7x Gen vs Gen sprechen und irgendwelche AI/ML Task meinen.

Warum sollten sie nicht AI/ML meinen? Die Slides richten sich doch eindeutig an das Datacenter-Publikum und wenn AI/ML einen gewichtigen Teil der üblichen Anwendungen ausmachen, wird das für so einen Schnitt auch gebencht.

Wegen Takt und IPC: 15% Takt war bisher das Maximum, das eine Generation rausgeholt hat, nämlich Zen 4. Selbst mit dem Sprung von GloFo auf TSMC N7 gab es so einen Sprung nicht bzw. nur dann wenn man Zen+ mit Zen 3 vergleicht und Zen 2 als Zwischenschritt auslässt. Unmöglich ist es sicher nicht, aber dann gibt es nicht noch gleichzeitig 100% mehr Effizienz, die für deine Vorhersage nötig wären. Der 9950X reizt die Plattform verbrauchtechnisch quasi schon aus.

Und zu IPC habe ich oben was geschrieben. Zen 5 als der angekündigte große Wurf hat die 15% mit Ach und Krach erreicht und dafür sogar AVX512-Benches im Mix gebraucht. Vielleicht löst Zen 6 jede Menge Handbremsen, die sich ins Zen-5-Design eingeschlichen haben, aber vielleicht sind die low-hanging fruits auch einfach alle geflückt und große Sprünge bleiben bis auf weiteres erstmal aus. Lion Cove war auf dem Papier auch ein krasser Sprung (8-wide vs 6-wide, 8 vs 6 Decoder, 6x ALU vs 5x, FP von INT entkoppelt mit komplett eigenen Ports und Schedulern, mehr und schnellere Caches, etc.), hat damit aber IPC-technisch afaik sogar minimal weniger erreicht als Zen 5.

[latiose88]

Ah ok Lion Cove,ist also der Nachfolger von aktuellen Gen bei Intel.Finde es schade das es nicht mehr Leistung geben wird.Das Ht abgeschaltet worden ist und es am Ende nur 24 Threads waren bei aktuellen CPUs,tat dennoch gut bei der Rohleistung.Scheinbar kommt das den Anwendung zu gute die nicht so viele Threads verlangen um wirklich gute Arbeit zu leisten.Wie das AMD handhaben wird auf lange sicht,sehen wir dann schon am Ende.Immer mehr EInheiten bzw breiter kann ja auf dauer auch nicht automatisch zu mehr Leistung führen.

[KarlKastor]

Möchte mal wisse das daran so furchtbar unrealistisch sein soll wenn alleine +50% cores kommen

1,5 (cores) x 1,15 Clocks x 1,15 IPC und man ist schon bei 1.98x - unrealistisch? Mit diesem Node Jump ist das locker möglich.
Woher kommt dieses "locker möglich"? Verstehe ich nicht.
TSMC spricht von 25-30% weniger Power von N3E auf N2. Das reicht ja nicht mal aus, um die +50% Kerne zu versorgen.
N5 zu N3E gibt TSMC mit +18% Performance an. Nun ist aber Zen5 nicht N5 sondern N4P. Und N4P gibt TSMC schon mit +11% über N5 an. Beleiben also +6% Performance.

Also nein, der Node-Sprung gibt das nicht locker her. Da muss AMD ordentlich beim Design was gefunden haben.
Klar, wenn der IO-Die in N3 kommt und der Interconnect über InFO-R/L o.ä. dann ist da noch etwas drin. Aber das ist sicher kein Selbstläufer und schon völlig in trockenen Tüchern.

[robbitop]

Shrinks selbst bringen heutzutage äußerst selten deutliche Taktsprünge im oberen Bereich der Desktop CPUs. Die 5 GHz die Intels 32 nm Prozess (SB im OC) brachte hat man mit 22 nm zB nicht geschafft iirc und erst die drölfte Iteration von 14 nm schaffte es das zu übertrumpfen usw.
Aber ggf ist in Kombination design + shrink nochmal was möglich.

[Nightspider]

Woher kommt dieses "locker möglich"? Verstehe ich nicht.
TSMC spricht von 25-30% weniger Power von N3E auf N2. Das reicht ja nicht mal aus, um die +50% Kerne zu versorgen.
N5 zu N3E gibt TSMC mit +18% Performance an. Nun ist aber Zen5 nicht N5 sondern N4P. Und N4P gibt TSMC schon mit +11% über N5 an. Beleiben also +6% Performance.

Wenn du dich nur auf die Taktrate und die Anzahl der Kerne beziehst ist der Vergleich gegenüber Zen4 wahrscheinlich sinnvoller.

Denn Zen4 war ein Hochtaktdesign und Zen5 hat die Taktraten trotz besserer Fertigung nicht erhöht.

Wenn eine Architektur nicht mit dem Ziel auf höhere Taktraten designt wurde, sollte man die Architektur dann auch nicht heranziehen als Vergleich.
Denn TSMC gibt an wie viel mehr Speed mit einem Prozess gegenüber einem anderen Prozess möglich ist. Von Prozess zu Prozess, nicht von Architektur zu Architektur, weil da keine Korrelation bestehen muss.

Ergo N5 vs N2P. Denn mit N5 hat man schon die 5,7 Ghz erreicht vor 2,5 Jahren.

Meine Meinung.

[davidzo]

Ergo N5 vs N2P. Denn mit N5 hat man schon die 5,7 Ghz erreicht vor 2,5 Jahren.



Wieso denn N2P? habe ich was nicht mitbekommen?

Ich dachte der 12C Consumer DIE soll in N3E kommen und nur der 32C dense Server DIE in N2. Gibt es neue Infos die besagen dass N2 auch für Consumer kommt?

[latiose88]

Ne habe auch gelesen das N2 nur für Server gedacht sei aber nicht für die Desktop Variante,weil viel zu teuer für uns.
ALso ist schon mal sicher das es keine massive Steigerung nur durch die Fertigung erfolgen wird.

[Nightspider]

Ich dachte der 12C Consumer DIE soll in N3E kommen und nur der 32C dense Server DIE in N2.

Nein, MLID hat schon vor 3 Monaten (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=13733774#post13733774) gesagt das Zen6 12C in N2X (oder N2P oder irgendein Hybrid) kommt.
AMD ist ganz vorne dabei beim Rollout zusammen mit TSMC.

Lisa Su hat ja schon einen N2 Wafer hochgehalten.

[Neurosphere]

Shrinks selbst bringen heutzutage äußerst selten deutliche Taktsprünge im oberen Bereich der Desktop CPUs. Die 5 GHz die Intels 32 nm Prozess (SB im OC) brachte hat man mit 22 nm zB nicht geschafft iirc und erst die drölfte Iteration von 14 nm schaffte es das zu übertrumpfen usw.
Aber ggf ist in Kombination design + shrink nochmal was möglich.

Wo hat Intel in 32nm 5 GHz in Serie gehabt?

Edit, hab das OC überlesen

[amdfanuwe]

Lisa Su hat ja schon einen N2 Wafer hochgehalten.
Wird der 32Core ZEN6c Server Chiplet gewesen sein für Venice. Der ist auch für N2 schon bestätigt.

[Nightspider]

Jepp, hat AMD aber noch nie zuvor 1-1,5 Jahre vor dem Release gemacht.

Die Ansage war aber klar: "Wir können und wir werden jetzt aus vollen Rohren schießen!"

[HOT]

Venice soll 16x12Kern-CCDs haben macht insgesamt 192 Kerne. Ich bezweifle mittlerweile, dass es ein anderes Zen6 CCD geben wird als das 12-Kern. Ich würd bedenken, dass ein Jahr später schon Zen7 Verona erscheinen soll, dann mit 256 Kernen wahrscheinlich in 8 32-Kern-CCD, auf denen ein Kern jeweils deaktiert ist, ein Zen7-CCD hat 33 (3x11) Kerne im Mesh wie es aussieht und das in TSMC A16. In CCX wird nicht über 16 Kerne skalierbar sein und das Zen6 8+8c-Die ist ja gecancelt worden.

Also:
2026: Venice 16x 12 Kern-CCD in N2P macht 192 Kerne (nur IFOP)
2027: Verona: 8x 33 (-1) Kern-CCD in A16 macht 256 Kerne, Mesh, 3D-Stacking, Silicon Bridges

[latiose88]

ja zumindest 12 Kern CCD ist sicher ob es nen takt Plus geben wird ist es nicht weil muss ja in das 200 Watt Corsett passen.Achtektur verbesserung wird es bestimmt auch geben.Ist rein logisch betrachtet.Wieviel und so das ganze bringt und ob der Preis steigen wird,das weiß man ja noch nicht.

[HOT]

N2P ist ein recht großer Sprung von N4 aus gesehen.

N4 (Pheonix, Strix, Kraken, Granite Ridge) -> N4P/X (RDNA4) -> N3E (Zen5c) -> N3P/X (CDNA4) -> N2 (nix) -> N2P/X (Olympic Ridge) -> A16 Zen7

Das ist schon sehr heftig. Wenn da nicht mehr Takt bei rumkommt wird es sehr sicher ordentlich IPC geben. Es ist ja nicht so, dass AMD das Rad wieder neu erfindet, das tat AMD bei Zen5. Jetzt gibts wieder low-hanging-Fruits. Cool ist, dass wir erstmals einen absolut fairen Vergleich zwischen Zen6 und Coyote-Cove auf N2P/X bekommen ;).

Übrigens glaub ich auch, dass man die Produktreihenfolge ändern wird. MLID hat ja geleakt, dass Zen7 der dense-Core ist und der große Zen7 Classic Core heißt. Ich denke, der Dense wird ab Zen7 immer zuerst erscheinen:

2026: Zen6 12 Core -> N2P
2027: Zen7 33 Core-> A16
2028: Zen7 classic 16 Core -> A16
2029: Zen8 ? Core -> A14 PPA
2030: Zen8 classic -> A14 PPA

[Der_Korken]

Denn Zen4 war ein Hochtaktdesign und Zen5 hat die Taktraten trotz besserer Fertigung nicht erhöht.

Das stimmt imho so nicht ganz. Die maximale Taktrate ist nicht gestiegen, aber afaik benötigt Zen 5 für die 5,7Ghz weniger Spannung als Zen 4. 9800X3D und 9950X3D erreichen 200Mhz mehr als 7800X3D und 7950X3D, wenn alle auf 1,2V limitiert sind. Ob das jetzt von N4 vs N5 kommt oder von der Architektur selber, wissen wir natürlich nicht.

[amdfanuwe]

Was ist an der Folie nicht zu verstehen? Wurde von Lisa vorgestellt:
https://pics.computerbase.de/1/1/7/9/7/1-fb7efa3a98b129f9/2-640.76663e95.png

Das sind 8 x 32Core = 256Cores.
Desweiteren 8 x 12Core = 96Cores.

[iamthebear]

Zen 5 braucht weniger Spannung und der Prozess skaliert auch nach oben hin besser. Zen 4 hat ab einem gewissen Punkt dicht gemacht und man hat für zusätzliche TDP kaum mehr Performance bekommen.
Aber Zen 5 braucht grundsätzlich mehr Energie weshalb sich AMD wohl dazu entschieden hat ihn nicht ganz nach oben zu pushen obwohl er es vermutlich könnte.

Was Zen6 angeht:
Es ist doch gut möglich, dass der Spitzentakt deutlich höher ist aber der Verbrauch pro Kern gleich bleibt. Dann muss bei Last auf 24 Kernen/48 Threads der Takt eben etwas gesenkt werden. Davon wird die Welt auch nicht gleich einstürzen denn 48 Threads geben sowieso Performance genug.

Nova Lake wird mit seinen 52 Kernen genau dieselben Probleme haben. Ich kann mir nicht vorstellen, dass die genauso ausgefahren werden können wie beim 285K.

Venice ist dann noch einmal eine ganz andere Geschichte. 192 Kern Zen5c läuft mit 2,25GHz Basistakt.
1,15x Takt (2,6 GHz) * 1,33x Kerne * 1,1x IPC = 1,7x Performance (bei den richtigen Anwendungen, die mit der Kernanzahl linear skalieren)
Wenn die TDP dann vielleicht noch um 20% gesteigert wird ist das jetzt nicht unbedingt so eine Leistung.

[KarlKastor]

Denn Zen4 war ein Hochtaktdesign und Zen5 hat die Taktraten trotz besserer Fertigung nicht erhöht.
Dann wird AMD die Effizienz mitgenommen haben. AMD wird sicher nicht hingegangen sein und hat rein gar keinen Vorteil aus der bessern Fertigung gezogen. Bessere IPC kommt ja auch nicht automatisch umsonst.
Wenn man Zen 4 mit N5 als Vergleich nimmt, dann auch dessen Performance und Effizienz.

[latiose88]

also eines ist klar,das der 24 Kern Zen 6 weniger Strom braucht als beim Threadripper 7960x.
Dieser auch wenn da bis 320 Watt verballern kann,aber das heißt nicht das es das muss,Und 289 Watt bei 5 ghz ist schon sehr effzient.Wenn man also den Fokus auf gleiche Takt legt,dann sind es rund 87 Watt weniger verbrauch.Das wären also dann 200 Watt beim 24 Kerner mit SMt beim Ryzen Zen 6 CPU.Also ich könnte mir gut vorstellen das der 24 Kerner mit SMT bei 5 ghz landen wird.
Recht viel mehr müsste AMD das Power Target erhöhen.Das würde mehr Hitze bedeuten und das will gewiss AMD nicht. Das wäre zu viel Risiko.Zudem würde auch die Temperaturen steigen.Weil wer will schon richtung 100 Grad haben.
Somit kann man anhand von mir sich gut vorstellen,das man bremsen muss.Man will ja nicht so wie Intel enden.Von daher umso besser.

[robbitop]

Wo hat Intel in 32nm 5 GHz in Serie gehabt?

Edit, hab das OC überlesen

Wobei AMD 5 GHz mit 32 nm in Serie hatte mit dem FX9590. ^^

[Zossel]

Wobei AMD 5 GHz mit 32 nm in Serie hatte mit dem FX9590. ^^

Und IBM mit 65nm: https://en.wikipedia.org/wiki/POWER6

[robbitop]

Jepp kann mich noch gut daran erinnern. :)

[Zossel]

In any event those interested in 3mdeb's work around AMD OpenSIL or to learn more can find their latest vPub recording below. Meanwhile it would be great if there was a status update out of AMD around the Zen 5 OpenSIL PoC and if any of their roadmap plans have shifted as we approach Zen 6 next year.

https://www.phoronix.com/news/AMD-OpenSIL-Zen-1-Experiment

[genervt]

Wir sind bei den Top-CPUs in Regionen, wo es mir echt Latte ist, ob die nun nich ein paar % mehr rauslutschen oder nicht. Für mich wird der Unterbau entscheidend. AMD muss endlich mehr PCIe Lanes/ Features auf den TOP Chipsätzen bieten.(AM4 Wechsler).

[Badesalz]

@genervt
Für nicht-Zocker stimmt das schon fast, weil Leute die mehr brauchen, dann eher mehr Threads brauchen. Da ist für jeden was dabei. Die X3D-Zocker dagegen werden sich auf mind. den Zen6 noch eher freuen dürfen.

Ungeachet natürlich dessen, daß an deinem Einwand trotzdem nichts auszusetzen ist :wink:

[Tarkin]

Woher kommt dieses "locker möglich"? Verstehe ich nicht.
TSMC spricht von 25-30% weniger Power von N3E auf N2. Das reicht ja nicht mal aus, um die +50% Kerne zu versorgen.
N5 zu N3E gibt TSMC mit +18% Performance an. Nun ist aber Zen5 nicht N5 sondern N4P. Und N4P gibt TSMC schon mit +11% über N5 an. Beleiben also +6% Performance.

Also nein, der Node-Sprung gibt das nicht locker her. Da muss AMD ordentlich beim Design was gefunden haben.
Klar, wenn der IO-Die in N3 kommt und der Interconnect über InFO-R/L o.ä. dann ist da noch etwas drin. Aber das ist sicher kein Selbstläufer und schon völlig in trockenen Tüchern.

Nur zur Info... Turin Dense ist schon N3 ;) und wenn die da schon 1.7x performance schaffen mit 33% mehr cores und einem node Jump, dann ist es wohl LOCKER vorstellbar, dass sie am Desktop mit +50% cores und einem Sprung von N4 auf N2 2x Performance schafft! Und nein, die Rede ist hier sicher nicht von irgendwelchen speziellen ML Workloads!

Anderes Beispiel... AMD hat ca. 1,4x MT Performance von 5950x auf 7950X rausgeholt OHNE den core count zu erhöhen und mit nur einem node jump von n7 auf n5. Und von Zen 3 auf Zen 4 gabs jetzt auch nicht so den gigantische IPC-Gain.

Es ist doch relativ easy zu rechnen...

1.5x cores * 1.20 node (n4p auf n2 - und die 20% sind konservativ) * 1,10 ipc (das wäre der minimalste IPC gain ever) = 1,98

Ich fresse einen Besen wenn Zen 6 nicht bei diversen MT benchmarks 2x Performance vs 9950X hat

[davidzo]

Lisa Su hat ja schon einen N2 Wafer hochgehalten.
Das war Epyc Venice, bestätigt also eher dass die 32C CCDs N2 sind, damit ist zu den 12C Consumer DIEs aber nichts gesagt.

Venice soll 16x12Kern-CCDs haben macht insgesamt 192 Kerne.
Das geht mit den neuen i/o DIEs und direktem Chipletverbund nicht. Der 12C DIE wird bei den Top Compute SKUs gar nicht verwendet, sondern nur bei Consumer, SMB und Edge.

8x32C und 8x12C sind die einzigen Möglichkeiten, es sei denn es gibt noch ein 16C DIE dazwischen.

Außerdem macht AMD bei Zen6 keine Unterscheidung mehr zwischen Dense und Standard Cores. Es gibt bei beiden auch die gleichen 4MB L3 pro Core wie seit Zen2. Stattdessen gibt es eine Compute orientierte und eine IO orientierte Plattform.

SP7 hat 16Channel RAM und nur 96PCIe Lanes (2x64 bei 2P) ist dafür aber mit den 32C Chiplets augestattet für bis zu 256Cores.
SP8 hat nur 8Channel Ram und 128PCIe Lanes (2x 96 in 2P), aber nur maximal 96Cores (8x12C DIE).

Wenn man bedenkt dass der 12C DIE dieselbe Infinity Link Verbindung zum IOD haben muss wie der 32C DIE, böte sich ein etwas weniger dichtes Verfahren doch an?

Also MLID ist bisher die einzige Quelle die sagt das beide DIEs in N2 gefertigt sind? Vor einer Weile hatte er selbst noch geleakt dass es mindestens ein kleineres CCD auch in 3nm gibt.

Nicht zu vergessen die ältere geleakte AMD x86 Core Roadmap die auch "3nm / 2nm" für Morpheus/Monarch schrieb und sich bei Zen5 als authentisch herausgestellt hat.

[HOT]

Ja, genau, IFOP für Venice, keine Siliziumbrücken, da gehe ich jede Wette ein. Die gibts erst mit Zen7, dort ergibt das auch erheblich mehr Sinn mit den 33 Kernen pro CCD. Venice ist sicherlich aufgebaut wie Turin non-dense, dazu würde dann auch das N4 bzw. SF4X IOD passen. Im Prinzip ist das ähnlich wie Turin: Turin -> Venice, Turin Dense -> Verona, mit dem Unterschied, dass der dense diesmal die neue Architektur ist.

[Neurosphere]

Naja, die Sache ist auch, welchen Usecase gibt es für normale Anwender denn mit den hohen Kernzahlen die Novalake verspricht abseits von Sachen wie Cinebench?

Man sieht ja jetzt schon das 8 Kerne durch den 9800X3D noch immer ein Maß sind das über 80% der Anwender zufrieden stellt derzeit. Wenn nun ein Sprung auf 12 oder evtl. wirklich (nutzbaren) 24 Kernen kommt mit X3D ist das schon ein beachtlicher Sprung.

[Nightspider]

Denke auch, das wir MT Werte Richtung +100% sehen werden.

Einige simulationslastige Spiele mit hoher Thread Anzahl werden auch Richtung 30-40% mehr fps zeigen.
In Star Citizen hoffe ich sogar auf +40-50%.

Das war Epyc Venice,


Ich weiß. Venice stand ja sogar drauf.

MLID sagt aber das Zen6 12C 100%ig in N2"irgendwas" kommt.

[Der_Korken]

Anderes Beispiel... AMD hat ca. 1,4x MT Performance von 5950x auf 7950X rausgeholt OHNE den core count zu erhöhen und mit nur einem node jump von n7 auf n5. Und von Zen 3 auf Zen 4 gabs jetzt auch nicht so den gigantische IPC-Gain.

Du unterschlägst bei der Rechnung, dass das PPT bei Zen 4 um 60% gestiegen ist (wodurch die Effizienz lustigerweise sogar gesunken ist ...). Verbrauchsnormiert verliert der 7950X natürlich nicht sehr viel, aber trotzdem. Und den "nicht so gigantischen" IPC-Sprung muss Zen 6 erstmal überbieten. Laut den geleakten Slides rechnete AMD selber damit, dass der Sprung kleiner ausfallen wird als von Zen 4 auf Zen 5. Ich glaube du interpretierst zu viel Positives in die 1,7x von Venice und am Ende kommt das von der FP16 packed math.

@IFOP: Wie wahrscheinlich wird es wohl, dass die Desktop-Modelle auf FanOut setzen statt auf IFOP? Ich persönlich finde diesen hohen Grundverbrauch, den die Chiplet-Modelle gegenüber den APUs und Intels haben, schon einen Abturner. Da werden gefühlt 20W für nichts verbrannt, was bei UV und Effizienztrimmung sehr ärgerlich ist.

[Tarkin]

Du unterschlägst bei der Rechnung, dass das PPT bei Zen 4 um 60% gestiegen ist (wodurch die Effizienz lustigerweise sogar gesunken ist ...). Verbrauchsnormiert verliert der 7950X natürlich nicht sehr viel, aber trotzdem. Und den "nicht so gigantischen" IPC-Sprung muss Zen 6 erstmal überbieten. Laut den geleakten Slides rechnete AMD selber damit, dass der Sprung kleiner ausfallen wird als von Zen 4 auf Zen 5. Ich glaube du interpretierst zu viel Positives in die 1,7x von Venice und am Ende kommt das von der FP16 packed math.



Wir werden sehen. Ich tippe auf ~90% Leistungsgewinn bei den klassischen MT Rendering Workloads. Wie gesagt - es gibt keinen Hinweis darauf, dass hier diese speziellen ML Workloads gemeint waren. Es steht nichts diesbzgl. in den End Notes. Es stand da auch nicht "up to" 1.7x. Ergo werden hier allgemeine Specint od Specfp workloads gemeint sein.

[basix]

Es gibt viele Variablen:
- Es gehen in etwa 30W an den Kernen vorbei (IOD, Fabric). Mit zwei CCDs noch etwas mehr. Kann man das halbieren, hat man mehr Leistung für die Kerne übrig
- N2(P) ist hinsichtlich Energieeffizienz ein ziemlich grosser Sprung, auch gegenüber N3E

Bei den 1.7x von Zen 6 gegenüber Zen 5 muss man auch berücksichtigen, dass die TDP vermutlich steigt. Bei Zen 5 ist es bei Desktop allerdings so, dass man die hohen Wattagen gar nicht voll ausnutzen kann, da die Chips oben weg nur noch schwach skalieren (zwischen 160W und 230W geht nicht mehr viel).

Aus meiner Sicht dürfte ein 12C Zen 6 einem 9950X gefährlich werden oder sogar übertreffen, was MT Workloads angeht. Und das 24C Modell dürfte je nach Benchmark die 2x gegenüber 9950X auch erreichen können.

[Lehdro]

Ich glaube du interpretierst zu viel Positives in die 1,7x von Venice und am Ende kommt das von der FP16 packed math.

Rechne mal den Speedup von FP16 packed math raus und zurück bliebe eine wahrlich kümmerlicher Zen 6 Speedup. Abzüglich der Kernsteigerung würden sich IPC und Takt sicherlich um einstellige Prozente streiten. Bei der Milchmädchenrechnung ohne das FP16 packed math Speedup reden wir ja so schon von recht konservativen Werten, die große Steigerung kommt erst von der Kombination der Effekte.

Wenn AMD mit FP16 packed math hätte werben wollen, würde dort 2.x stehen und man hätte das ganze explizit so beworben ("made for AI" oder so). Verkauft sich schließlich besser.

[davidzo]

Laut den geleakten Slides rechnete AMD selber damit, dass der Sprung kleiner ausfallen wird als von Zen 4 auf Zen 5. Ich glaube du interpretierst zu viel Positives in die 1,7x von Venice und am Ende kommt das von der FP16 packed math.
AMDs Angaben dazu kommen frühzeitig aus der µArch-Abteilung. Die dürfen anscheinend schon früher leaken und konzentrieren sich natürlich auf die Projekte an denen sie am meisten neukonstruiert haben. Bloß weil vieles Neu ist muss das aber noch lange keinen großen Performancesprung bedeuten und umgekehrt. In der Vergangenheit war vor allem zen2 ein großer Sprung, wurde von AMD aber kleingeredet weil die Mikroarchitekturveränderungen gering waren. Ebenso war Zen4effektiv der größere Sprung als Zen5%, wurde von AMD aber umgekehrt kommuniziert.

In einer Architekturbetrachtung sind weder Implementierung -> Taktbarkeit, TDP, Speichertakt & Latenz noch Node-Verbesserungen hineingerechnet.
Die 10% können von dem team kommen was die Core Arch gemacht hat oder von denen die das CCD design haben. verbesserungen im IO/Die, zum Beispiel was die Speicherlatenz angeht mögen da noch gar nicht mit drin sein.


@IFOP: Wie wahrscheinlich wird es wohl, dass die Desktop-Modelle auf FanOut setzen statt auf IFOP? Ich persönlich finde diesen hohen Grundverbrauch, den die Chiplet-Modelle gegenüber den APUs und Intels haben, schon einen Abturner. Da werden gefühlt 20W für nichts verbrannt, was bei UV und Effizienztrimmung sehr ärgerlich ist.

Sehr wahrscheinlich! Die 12C CCDs ja auch für SP8 Epycs genutzt werden und dort auf jeden Fall auf Fanout Infinity Links setzen und nicht auf Infinity Fabric On Package. Wie man bei Strix halo sieht ist der Die dadurch ja sogar kleiner, da man zwar viel mehr Pins im Fanout hat, aber dafür der Serdes PHY wegfällt. Wenn AMD weiterhin einen Serdes PHY verbaut würde das also doppelt Fläche verbrauchen, einmal für den Fanout und für den PHY. Dass das dann billiger ist wage ich zu bezweifeln.

MLID behauptet ja sogar dass es ein Bridge DIE gibt, der bei UMC gefertigt wird. Das wäre dann also Info-LSI bzw. Fan-out Embedded Bridge (FOEB) von SPIL und nicht mehr Info-R. Es kann durchaus sein dass AMD die schnauze voll hat bei TSMC nur die zweite Geige hinter Nvidia beim advanced packaging zu spielen und deshalb mit dem Packaging zu den Mitbewerbern gegangen ist. Ähnlich wie man jetzt die HMB3E Module von Samsung aufsaugt die von Nvidia aus Qualitätsgründen abgelehnt wurden.

Im selben Video zeigt er aber seine Renderings von Medusa Point und die sind ohne jegliches organic Package, denn das wäre nicht L-förmig sondern quadratisch.
Er liegt also auf jeden Fall schonmal falsch, fragt sich nur mit was allem.

Wissen wir eigentlich sicher dass der Interposer bei Strix Halo und N31 nicht doch lokale Siliziumbrücken hat? AMD hat bei den Infinity fanout links bei N31 ja keine konreten Angaben gemacht aus was die bestehen. InFO-R/oS acht am meisten Sinn, aber ist das bestätigt?

[basix]

Vermutlich benutzt RDNA3 InFO. Si-Brigdes wären vermutlich zu teuer.
https://semiwiki.com/semiconductor-manufacturers/tsmc/290560-highlights-of-the-tsmc-technology-symposium-part-2/

https://cdn.mos.cms.futurecdn.net/XPkuEK3D3aYZxoqXq6zPQL.jpg

https://3dfabric.tsmc.com/site_img/dedicatedFoundry/technology/InFO/InFO_oS.png

[HOT]

Falls noch Zweifel bestehen was N2 angeht:

https://ir.amd.com/news-events/press-releases/detail/1245/amd-achieves-first-tsmc-n2-product-silicon-milestone

AMD und TSMC haben das verkündet. Das ist kein Leak, das ist Fakt. Venice CCD ist ein N2-Derivat, auf dem Bild über dem hochgehalten Wafer steht "Venice CCD".

[basix]

Venice ist die gesamte Epyc Plattform von Zen 6. Das grössere Chiplet mit 32C ist sicher N2. Die kleineren 12C Chiplets könnten theoretisch auch N3 sein. Ich erwarte aber auch N2 für die 12C Chiplets. N3P für alles "monolithische" (low end APU und Zen 6LP)
- Zen 6 = Morpheus
- Zen 6c = Monarch

[latiose88]

@basix abwarten, also bei meinem Fall profitierte ich nicht von den 24 Kerner. Und doppelt so viele Leistung gibt es auch nicht, wenn dann sind es höchstens 75 % weil perfekt skalieren gibt es ja selten.

[amdfanuwe]

Wissen wir eigentlich sicher dass der Interposer bei Strix Halo und N31 nicht doch lokale Siliziumbrücken hat?
Zitat aus https://chipsandcheese.com/p/amds-strix-halo-under-the-hood
The first thing we had to do was to change the interconnect between the two dies. And so the CCD that you see here, the core die that you see here, has a different item. That's the first change.

That's a sea of wires. We use fan out, we're for level fan out in order to connect the two dies. So you get the lower latency, the lower power, it's stateless. So we're able to just connect the data fabric through that connect interface into the CCD. So the first big change between a Granite [Ridge] or a 9950X3D and this Strix Halo is the die-to-die interconnect. Low-power, same high bandwidth, 32 bytes per cycle in both directions, lower latency. So everything - and almost instant on-and-off stateless - because it's just a sea of wires going across. So it's a little [bit of a tradeoff] of course, the fabrication technology is more expensive than the one over there [points to a 9950X3D], but it meets the needs of the customer and the fact that it has to be a low power that can actually connect.

Wenn da Bridges verwendet würden, wäre das sicher erwähnt worden.
Bridges, EFB, wurden bei MI200 verwendet. Bei MI300 sollte zuerst FanOut mit organic RDL verwendet werden. Gab aber schwierigkeiten wegen der Größe weshalb dann Silizium Interposer zum Einsatz kam. Eventuell geht AMD bei MI400 wieder auf EFB.

[HOT]

Venice ist die gesamte Epyc Plattform von Zen 6. Das grössere Chiplet mit 32C ist sicher N2. Die kleineren 12C Chiplets könnten theoretisch auch N3 sein. Ich erwarte aber auch N2 für die 12C Chiplets. N3P für alles "monolithische" (low end APU und Zen 6LP)
- Zen 6 = Morpheus
- Zen 6c = Monarch

AMD hat aus den MI500-Folien Zen7 wieder gestrichen, offenbar ist Verona auch Zen6. Da gibts offenbar noch einige Unstimmigkeiten.

[basix]

Wo hat AMD was rausgestrichen? Verona/Verano wurde nie konkret als Zen 7 angekündigt. Das kann Zen 7 sein oder eine Zen 6 Variante. Zen 7 wurde so von vielen intepretiert oder zumindest vermutet. Wenn das Zen 7 wäre, hätte das AMD vermutlich aber so gesagt.

[davidzo]

Wo hat AMD was rausgestrichen? Verona/Verano wurde nie konkret als Zen 7 angekündigt. Das kann Zen 7 sein oder eine Zen 6 Variante. Zen 7 wurde so von vielen intepretiert oder zumindest vermutet. Wenn das Zen 7 wäre, hätte das AMD vermutlich aber so gesagt.

Bei Turin und Venice spricht man auch nicht von Zen5 und Zen6.
Verano ist aber ein 7th Gen Epyc Processor. Das ist also schon ziemlich deutlich dass es eine neue µArch ist.

[Badesalz]

Laut den geleakten Slides rechnete AMD selber damit, dass der Sprung kleiner ausfallen wird als von Zen 4 auf Zen 5.Interessant. Nach dem Zen5 Launch haben sie unisono eine ganze Weile kolportiert, der Zen5 ist nur die Vorarbeit auf die echten Sprünge mit Zen6...

[KarlKastor]

Nur zur Info... Turin Dense ist schon N3 ;) und wenn die da schon 1.7x performance schaffen mit 33% mehr cores und einem node Jump,
Bei gleicher TDP?


Es ist doch relativ easy zu rechnen...

1.5x cores * 1.20 node (n4p auf n2 - und die 20% sind konservativ) * 1,10 ipc (das wäre der minimalste IPC gain ever) = 1,98

Was sollen die 1.2 sein? Performance Plus/Takt?
Dann liegst du am Ende auch bei 1.5x TDP abzüglich Effizienzverbesserungen die Abseits der Fertigung erzielt werden.

[davidzo]

SP7 wird auf 600Watt TDP hoch gehen. Von Genoa/Bergamo auf Turin ging es schon von 400 auf 500Watt. Diesmal steigt jedoch auch die Anzahl der Speicherkanäle von 12 auf 16. Da die Cores aber um 33% anwachsen, die TDP jedoch nur um 20%, muss jeder Core mindestens 13% weniger verbrauchen als bisher.

Wobei Turin classic weiterhin mit 360-400W ausgeliefert wurde. Dieselbe TDP soll auf SP8 zutreffen, diesmal aber mit nur 8 Kanal SI. Da beim Classic weiterhin maximal 96 Kerne angeboten werden, steht also minimal mehr Energie pro Core zur Verfügung.

Beide CPUs sparen ggf. etwas Energie ein die bisher für die IFOP Links draufgeht wenn das advanced Packaging kein Serdes mehr benutzt. Dann wäre in der Tat gleichviel oder sogar etwas mehr Energiebudget pro Core vorhanden.

[Nightspider]

MLID über Zen 6:

AMD Quelle 1:

"we expect final silicon to have 6-8% higher FP IPC vs Zen5. (not final overall result!)"

"oh, and i can confirm 96MB of cache per V-Cache layer and that Zen6 can stack multiple layers"

"it's possible for a 12 core 240 MB L3 Zen 6 gaming cpu to exist"

Das wäre dann die 2,5 fache Menge an L3 pro X3D CCD im Vergleich zu bisherigen X3D CPUs. =)

AMD Quelle 2:

"Early testing in our departement is yielding 13-16% higher performance over Zen5 at same clocks in server workloads, but i must stress this wasn't comprehensive testing - so dont take this as an average IPC uplift!

Clock speeds are also impressive! Even at target voltages (not OC'd), some of our Zen6c samples are boosting to nearly 4,5 Ghz! And, in lighter MT workloads, we can often run all 32 Cores on a CCD at ~4 Ghz! Thats much higher than what final Zen 5c silicon is capable of NOW!"

[robbitop]

Wobei das nicht notwendigerweise was über die maximalen Taktraten des kritischen Pfades aussagt (weil so hoch sind die genannten Taktraten nicht) sondern nur dass Zen 6 bei diesen Taktraten (die ja gemessen an 6 GHz noch moderat sind) noch sparsam ist.
Ansonsten ist es die Frage wie viel mehr Cache jetzt noch bringen wird. Gesetz des abnehmenden Grenzertrags gilt ja gerade bei Cachehitrate.
Aber dennoch kann sich das am Ende schon ordentlich aufaddieren. wie damals bei Zen 4. Mehr IPC des Cores, mehr Takt und nochmal ein bisschen bessere Auslastung durch mehr Cache, angeblich bessere Memorylatency durch neuen IOD der näher am ccd ist (modernes packaging).
Beim X3D war ja mehrere stack layer auch vorher schon möglich- gabs aber nicht. Kann mir gut vorstellen, dass es dabei bleibt. Blieben dann also 48+96 mb -> 144 mb.

Was ich mir allerdings vorstellen kann, ist dass es auch Regressions gibt die man bekämpfen muss. Mehr cores pro CCD wird die L3 latency erhöhen. Die war ja vorher super. Kann sein dass Faktor 1,5 an Speichermenge für den L3 dann stark wieder aufgefressen wird.
So ist das nunmal bei Cache. Latenz und Größe sind nunmal diametrale Kriterien - da kann man nicht stumpf größer machen und erwarten, dass alles nur besser wird. Ist immer ein Balance- und Kompromissakt.

Es wird allerdings sehr spannend wenn Novalake wirklich mit großem LLC kommt. Arrowlake war ein relativ starker Core der von der Latenz in Spielen zurück gehalten wurde. Der skalierte iirc ja deutlich krasser vom Speichertuning als seine Vorgänger und kam damit dann knapp an den 9800x3d ran (mit richtig richtig gutem Speicher und richtig aggressivem Tuning).
Und so stark stieg die IPC bei AMD zuletzt nicht mehr. Der große Vorteil ist vcache. Wenn Intel den auch hat wird es wieder spannend.

[Nightspider]

Intel stapelt aber nicht den Cache sondern packt ihn daneben, soweit ich weiß.
Das ist schon wieder ein relativ großer Nachteil gegenüber V-Cache.

Die höheren Latenzen durch mehr Cores und größeren Cache kann AMD hoffentlich mit deutlich höherem Takt kaschieren. Durch die viel besseren Nodes sollte schon einiges gehen.

[HOT]

FP war glaube ich zu erwarten so, da sich die FPU nicht so irre ändern wird ggü. Zen5, das gilt natürlich nicht für den Rest der CPU. Wieviel das letztendlich gesamt ist muss sich noch zeigen. Die 144MB für den normalen Desktop-Zen6 sind aber ne tolle Sache.

[Badesalz]

Wobei das nicht notwendigerweise was über die maximalen Taktraten des kritischen Pfades aussagt (weil so hoch sind die genannten Taktraten nicht) sondern nur dass Zen 6 bei diesen Taktraten (die ja gemessen an 6 GHz noch moderat sind) noch sparsam ist.
Ansonsten ist es die Frage wie viel mehr Cache jetzt noch bringen wird. Gesetz des abnehmenden Grenzertrags gilt ja gerade bei Cachehitrate.BWL-mäßig kann man sich das schon vorstellen, daß sie sich noch was übrig gelassen haben für folgende Gens und nicht direkt auf Optimum gingen, obwohl sie es könnten :wink: Es scheint aber schon ok (Größe).

Andererseits hat die Gleichung wahrscheinlich auch die Abhängigkeit MB pro Kern. Wenn sie jetzt noch kleinwenig anheben, werden sie wahrscheinlich im Verhältnis auch den V-Cache noch anheben.
Eine Baustelle wo man bezüglioch Größe noch unbedingt noch dran müsste scheint mit V-Cache aber auch nicht

Was ich mir allerdings vorstellen kann, ist dass es auch Regressions gibt die man bekämpfen muss. Das hat man beim Zen5 mit noch und nöcher Agesas schon gesehen ;)

Kann sein dass Faktor 1,5 an Speichermenge für den L3 dann stark wieder aufgefressen wird.bingo

Der skalierte iirc ja deutlich krasser [...]
Das ist bisschen schwierig 2 Sachen zu vergleichen, wenn man das eine an mehreren Komponenten komplett überfährt, um dann zu sagen, die Kerne sind echt nicht schlecht. Und dann kommt man ja nur in die Nähe von competetiv. Das ist aber nicht nur mit der Gen so gewesen. Als wenn man das Zeug immer für ein System rausbringt welches in 4 Jahren dafür soweit sein wird. Dann gibts intelgerecht den Sockel aber längst nicht mehr...

[robbitop]

Intel stapelt aber nicht den Cache sondern packt ihn daneben, soweit ich weiß.
Das ist schon wieder ein relativ großer Nachteil gegenüber V-Cache.

Die höheren Latenzen durch mehr Cores und größeren Cache kann AMD hoffentlich mit deutlich höherem Takt kaschieren. Durch die viel besseren Nodes sollte schon einiges gehen.

Das stimmt - es wird dennoch wahrscheinlich sehr hilfreich sein. Aber ein gestapelter Cache wäre besser.

[robbitop]

Das ist bisschen schwierig 2 Sachen zu vergleichen, wenn man das eine an mehreren Komponenten komplett überfährt, um dann zu sagen, die Kerne sind echt nicht schlecht. Und dann kommt man ja nur in die Nähe von competetiv. Das ist aber nicht nur mit der Gen so gewesen. Als wenn man das Zeug immer für ein System rausbringt welches in 4 Jahren dafür soweit sein wird. Dann gibts intelgerecht den Sockel aber längst nicht mehr...
Naja es zeigt dass die Cores viel auf den Speicher warten müssen und durch latency zurück gehalten werden. Und wenn dieser Bottleneck ein Stück weit geweitet wird die Performance massiv zulegt. Mit VCache ginge da sicher noch mehr. Will sagen Arrowlake wäre bei gleichen Voraussetzungen wie Zen5x3d wahrscheinlich gleichauf. Die Cores von Intel und AMD sind ziemlich auf Augenhöhe. Aber für Arrowlake gab es halt keinen VCache.
Wenn es dann mal einen geben wird, wird es spannend.
Mit NVL wird es einen großen, wahrscheinlich nicht gestapelten, LLC geben. Der ist ggf langsamer von der Latenz weil nicht gestapelt aber kann das ggf durch mehr Größe (bedeutet mehr hitrate) ausgleichen.

[Badesalz]

Das Massaker wie sich da die P und E und LPE um den LLC prügeln wird bestimmt ein Fest sein. Ich freu mich drauf.

Ich halte trotzdem in einem Zen6 Thread den Zen6 für spannender. Grundsätzlich ist es auch der eher vermeintlichen Objektivität wohl abträglich, wenn man sich grad hier in seinen Texten nur drauf konzentriert was AMD ggf. alles macht und welche Pferdefüße sich dabei ergeben können und was Intel alles ggf. macht und wie toll das vielleicht werden könnte...

[robbitop]

Naja Zen 6 muss sich ja mit einem Produkt von Intel messen. Insofern hat das schon Relevanz.

Was das Core Wirrwarr angeht: ja das ist bei Intel nicht ideal - aber das Scheduling ist da schon deutlich besser geworden. Und auch bei AMD müssen sich mehrere Kerne um den LLC streiten. Ob das nun LP/E oder P cores sind ändert daran nichts. Wenn es aber wirklich 200+ MB sind, stellt das wahrscheinlich eine deutliche Verbesserung des status quo da.

Wenn der big LLC bei NVL kommt, gehe ich jede Wette ein, dass es wieder ein Kopf an Kopf Rennen wird.

[Badesalz]

Naja Zen 6 muss sich ja mit einem Produkt von Intel messen. Insofern hat das schon Relevanz.Ich schrieb auch nicht über die Form, sondern über die Art...
(immernoch)

[robbitop]

Ich kann den Kommentar nicht nachvollziehen und sehe es anders. Agree to disagree würde ich sagen.

[Nightspider]

Die 144MB für den normalen Desktop-Zen6 sind aber ne tolle Sache.

Nein der normale Zen6 hat 48 MB L3. 50% mehr als Zen5 und pro Core gleich viel wie die letzten Generationen.

Ein V-Cache Slice hat dementsprechend doppelt so viel = 96 MB.

Zwei V-Cache Slices (2-Hi) haben 192 was zusammen mit den 48 eben =240 ergeben würde.

[Der_Korken]

Ich glaube nicht an 2-Hi-3D-Cache in Consumer-Produkten. Und wenn, dann könnte ich mir eher vorstellen, dass AMD das nur in den 2-CCD-Modellen bringt als Upselling gegenüber dem 1-CCD-Modell mit 3D-Cache. Mit 12 Kernen pro CCD werden die 2-CCD-Modelle für Spieler und die meisten Anwender noch uninteressanter, aber wenn der 11950X3D durch den 2-Hi-3D-Cache nochmal 10% schneller als der 11800X3D wird, dann werden den schon genug Leute kaufen.

[Badesalz]

Guter Punkt. Gabs eigentlich schon Gerüchte zum Wechsel der Nomenklatur?

[Der_Korken]

Wenn der neue IOD eine NPU hat, würde ich darauf tippen, dass AMD das dreistellige Namensschema um Ryzen AI auch auf den Desktop überträgt. Also z.B. Ryzen AI 495X3D und 480X3D (ohne das H der mobilen SKUs).

[Badesalz]

Wäre auch mal ein Ding :up:

So geht das jedenfalls kaum weiter. Man sieht ja wohin sowas führt :usweet:

[HOT]

500 nicht 400, sicherlich Ryzen AI9 580X3D für den 12C X3D. 400 ist Gorgon Point, 500 dürfte Medusa und Olympic werden und somit wirds sicherlich auch Ryzen R5 560 für eine 8Kern-CPU mit 6nm IOD ohne NPU, kommt sicherlich nicht vor 27 das Kleingemüse.
AI 300 entspricht 9000 Desktop, AMD hat seit Renoir immer eine Gen dazwischen für rein Mobil, Ryzen 4000, Ryzen 6000, Ryzen 8000, Ryzen AI400 wäre die nächste.

Ich würd mal tippen:

AI9 595X3D -> 24C + X3D
AI9 595X -> 24C
AI9 590X3D -> 16C + X3D
AI9 590(X) -> 16C
AI7 580X3D -> 12C + X3D
AI7 570(X) -> 12C
R5 560(X) -> 8C

[Der_Korken]

16 Kerne wird es bei 12C-CCDs eher nicht geben, genauso wie keine 10-Kerner mit 8C-CCDs gab. Der 590 dürfte eher mit 20 Kernen kommen. Ansonsten wäre das Kern-Upgrade auch die Gelegenheit für AMD mal das 7er und das 8er Modell sinnvoll zu trennen statt nur über das PPT.

[HOT]

Das ergibt keinen Sinn. Sicher wird das ein 16 Kern, 20 Kern wirds mMn gar nicht geben. AMD wird mit diesem Die nur 12, 8 und 6 Kerne anbiieten, so wie man jetzt 8, 6 und 4 anbietet.

[Badesalz]

Das könnte u.U. tricky werden, wenn es einen 16er geben soll. (Statt 24er)

Es könnte grad im DIY Szenarien geben wo der 12er sich dem 16er dann nicht geschlagen geben will...

[Der_Korken]

Das ergibt keinen Sinn. Sicher wird das ein 16 Kern, 20 Kern wirds mMn gar nicht geben. AMD wird mit diesem Die nur 12, 8 und 6 Kerne anbiieten, so wie man jetzt 8, 6 und 4 anbietet.

Im Consumer-Bereich gibt es aktuell quasi nur Modelle, wo entweder 100% oder 75% der Kerne aktiv sind. 4-Kerner werden mittlerweile eher über APUs abgedeckt. Die Yields des 12C-Chiplets werden wohl kaum so schlecht sein, dass AMD direkt 1/3 deaktivieren muss für den kleinsten Cut. Deswegen erwarte ich eher 10 aktive Kerne und vielleicht noch ein paar 8er für den ganz groben Ausschuss.

[basix]

Ja, denke ich auch. AMD kann für mehr Cores mehr Geld verlangen. Die Cores ohne Not zu deaktivieren ist also wenig sinnvoll. Und Intel macht in diesem Segment auch ein bisschen Druck hinsichtlich MT-Performance.

Mögliche Konfigurationen wären also 8, 10, 12, 16, 20 und 24 Cores. Ich nehme aber an, dass es bei den Dual-CCD CPUs nur zwei Modelle geben wird. Vermutlich lässt man die 16C SKU weg.

[Badesalz]

Ja, denke ich auch. AMD kann für mehr Cores mehr Geld verlangen. Die Cores ohne Not zu deaktivieren ist also wenig sinnvoll. Und Intel macht in diesem Segment auch ein bisschen Druck hinsichtlich MT-Performance.In diesem Segment - also den nicht mit Xeons und nicht mit Epycs - ist der Druck eher ein Streicheln, da außer für rausgepickte Benches weitgehend nutzlos.
Mögliche Konfigurationen wären also 8, 10, 12, 16, 20 und 24 Cores. Ich nehme aber an, dass es bei den Dual-CCD CPUs nur zwei Modelle geben wird.Mich würde es aber wirklich nicht erstaunen, wenn 16er raus sind.

[amdfanuwe]

Es gibt keine Ryzen 9000 oder Ryzen 7000 4Core.
Da müsste der Yield schon sehr schlecht sein, dass AMD CPUs mit mehr als 2 deaktivierten Cores pro Chiplet bringt.

Damit sind wir bei
24, 20, 12 und 10 Core für Ryzen 11000 Desktop.
Wer 8 oder 16 Core will, kann ja auf Ryzen 9000 zurückgreifen.

Dazu eben noch Medusa Point Little Ableger mit 4 bis 10 Cores.

Meiner Meinung nach fliegt die Ryzen 7000 Serie aus dem Programm, Ryzen 9000 wird etwas im Preis gesenkt und on Top kommt Ryzen 11000 (Ryzen 500AI?).
Ein 11900X3D (ein Chiplet) sollte mit einem 9950X3D mithalten können. Dann kann AMD dafür auch 700€ verlangen. Ryzen 11000 wird kein billiger Spaß.

P.S.:
Ein 9800X3D 8 Core geht aktuell für 460€ über die Theke, was mag dann ein ZEN6 10Core X3D kosten?

[HOT]

Hm, vielleicht kommen die Ryzen 9000 als rebranded Rx 300 oder 400 zurück... es kann schon sein, dass man die neuen Ryzen überhaupt nur in hochpreisigeren Segmenten anbietet.

[Nightspider]

Ich glaube nicht an 2-Hi-3D-Cache in Consumer-Produkten. Und wenn, dann könnte ich mir eher vorstellen, dass AMD das nur in den 2-CCD-Modellen bringt als Upselling gegenüber dem 1-CCD-Modell mit 3D-Cache. Mit 12 Kernen pro CCD werden die 2-CCD-Modelle für Spieler und die meisten Anwender noch uninteressanter, aber wenn der 11950X3D durch den 2-Hi-3D-Cache nochmal 10% schneller als der 11800X3D wird, dann werden den schon genug Leute kaufen.

Ich habe eher Angst das wir die 2-Hi Variante erst später bekommen, à la Salami Taktik.

Zen 6
+3 Monate X3D
+3 Monate 2-Hi X3D

[maximus_hertus]

Ich habe eher Angst das wir die 2-Hi Variante erst später bekommen, à la Salami Taktik.

Zen 6
+3 Monate X3D
+3 Monate 2-Hi X3D

Das kann sehr gut sein.

Mein "Tipp":

Mai 2026: Vorstellung Zen 6 (Architektur), Vorstellung neue MB-Chipsätze

Computex: Boardherteller können die 3. Iteration des AM5-Sockels bzw. ihre neuen Boards vorstellen

Ende Juni oder Jui: Launch Zen 6, keine X3D (so wie immer)

Entweder kurz vor und nach Nova-Lake K Launch: Launch der X3D CPUs

Sollte Novalake es irgendwie an die Spitze schaffen (Gaming) => CES 27 => Vorstellung einer 240 MB X3D-CPU und später dann Launch. Aktuell würde ich aber weniger davon ausgehen, dass wir eine solche CPU im Consumersegment sehen werden.


Zu der Anzahl der Kerne:

Bisher gab es immer 75% bei den kleinen Modellen (6 statt 8 bzw. 12 statt 16 Kerne). Bleibt es bei 75%, hätten wir 9 / 12 / 18 / 24 Kerne.
Ob das Sinn macht oder so kommen wird - keine Ahnung. 16 Kerne wären aber in der Tat etwas arg mau, gerade wenn es darunter ein 12er Single-CCD Chip gibt.

[amdfanuwe]

Hat mit 75% nichts zu tun. Wenn ein Fehler auftritt, betrifft es meist den Cache oder einen Kern.
Nimm ein Poster vom Chiplet und wirf mit einem Dartspfeil darauf.
Wiederhole das ein paar Tausend mal und du bekommst eine Statistik, mit welcher Wahrscheinlichkeit welche Teile des Chips von einm Defekt betroffen werden.

Bei den kleinen chiplets dürften selten 2 Defekte vorliegen. Durch abschalten eines 2ten schlecht Taktenden Kerns kann man den Zieltakt höher ansetzen.

[Badesalz]

Ich habe eher Angst das wir die 2-Hi Variante erst später bekommen, à la Salami Taktik.

Zen 6
+3 Monate X3D
+3 Monate 2-Hi X3DGlaub nicht, daß man diesen Segment so vergraulen kann. Wer das nicht checkt wird 3 Monate später austicken ;) und wer das checkt wird 6 Monate lang abkotzen, weil er solange warten muss.

Ich hoffe SO blöd sind sie nicht.

[Der_Korken]

Sie wissen, dass die normalen Modelle ziemlich tot sind, sobald es die 3D-Modelle zu kaufen gibt. Zen 4 wurde zum Launch kaum gekauft, weil die Boards so teuer waren und der alte 5800X3D in Spielen genauso schnell. Zen 5 lag auch wie Blei im Regal, weil der 7800X3D in Spielen schneller war und kurz vorm Launch auf 300€ und weniger gedroppt ist. Erst mit dem Launch des 9800X3D (und zuvor des 7800X3D) haben die Leute AMD die Bude eingerannt. Ich denke AMD hat die Message verstanden. Beim 9800X3D würde ich AMD sogar glauben, dass er wegen des neuen Cache-Chiplets und der neuen Stacking-Technik nicht zeitgleich mit dem Rest gelaunched werden konnte, weil er einfach noch nicht fertig war.

[Nightspider]

Ist TSMC mittlerweile in der Lage die neuesten Nodes mit älteren Nodes zu stacken?

N4 oder N6 Cache auf N2 ist ja nochmal was anderes als N6 auf den betagten N4.

[basix]

Was man so hört soll es N2P auf N4 (V-Cache) sein.

[stinki]

Ich denke auch, dass wir 24, 20, 12, 10-Core Produkte sehen werden, und vielleicht noch 8-Cores für den kompletten Ausschuss. Dazu sollen ja noch 2LP Kerne im IoD kommen.
Intel soll angeblich mit 52, 42, 28, 24 und 18 Cores/Threads antreten bei Nova-Lake.
AMD hätte dann 52, 44, 28, 24 und 20 Threads dagegen, das würde für mich Sinn ergeben.

Initial werden wir wahrscheinlich im nächsten Sommer erst nur die 24, 20, 12, 10-Core non-X3D Modelle sehen.
Und zum Nova-Lake Launch kommen dann die X3D Modelle und vielleicht ein 8-Core Chip.
Ich würde mir auch einen gemeinsamen Launch wünschen, allein mir fehlt der Glaube...