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

[HPVD]

Es ist Zeit für nen Speku Thread für ZEN 6 :-)

- 10%+ IPC increase vs ZEN 5 (der 10-15% IPC increase vs ZEN 4 haben soll)
- FP16 instruction for AI/ML algorithms acceleration
- new memory profiler
- 32 core complex CCX (ZEN 6c cores)
- new packaging techniques (CCDs on IODs with silicon bridges?)
- new gen infinity fabric
- goal: "monolithic levels of latency"
- Epyc: 256 cores / 512 threads (6c cores?)
- Epyc: SP7
- Epyc: 16 memory channel DDR5 (+ kleinere 12 channel Variante)


Quelle:

original:
https://www.youtube.com/watch?v=ueXUoRw5LZk

als Text (teilweise):
https://videocardz.com/newz/amd-x86-core-roadmap-leaks-out-zen5-nirvana-zen6-morpheus-microarchitectures-detailed

[HOT]

IPC Increase ist absolutes Minimum der Projektionen. Das wird Final mehr sein. Man muss bedenken, dass die Slides, die da gezeigt werden von Ende 21 oder früher sind.

[Tobalt]

hmmz, Low Precision Einheiten auf der CPU? Weiß nicht so recht was ich davon halten soll.

Bei GPU bin ich ja großer Freund davon, weil dort eben auch der Rest durch die traditionellen Grafikauslegung AI freundlich ist: starke Bandbreite, viel Parallelität...

Natürlich werden solche Workloads in Zukunft zunehmen, aber dann macht es IMO doch eher Sinn die dGPU/iGPU oder gleich dedizierte Low Prec Beschleuniger dafür zu nutzen.. Das kleine Häufchen an CPU Cache ist doch für solche Workloads sicher nicht gut geeignet?

[HPVD]

hmmz, Low Precision Einheiten auf der CPU? Weiß nicht so recht was ich davon halten soll.
...
Natürlich werden solche Workloads in Zukunft zunehmen, aber dann macht es IMO doch eher Sinn die dGPU/iGPU oder gleich dedizierte Low Prec Beschleuniger dafür zu nutzen.. Das kleine Häufchen an CPU Cache ist doch für solche Workloads sicher nicht gut geeignet?

Joa, gibt imho auch usecases wo das Sinn macht, z.B. wenn man nur kleine/temporäre KI Spitzen benötigt werden und man ne dedizierte GPU nicht auslasten kann vielleicht bei nem "in der cloud" gehosteten Shop für
- Suche
- Recommandation
- o.ä.
hast ja nicht nur den "normalen Betrieb" sondern
- musst das auch einrichten, pflegen
- aus Gründen der Verfügbarkeit auch 2 vorhalten
- etc
-> das wird dann schnell auch teuer...
(Aufwand / wirtschaftliche Gründe)

[HOT]

Das machen die nur weil diese CCDs im Server auch genutzt werden und KI der heiße Scheiss grade ist.

[HPVD]

Ergänzung (aus technischer Sicht):
und auch von der Latenz kann es Sinn machen, kleine KI Dinge auf der CPU zu machen, statt sie erst von der CPU zur GPU zu schieben und dann das Ergebnis wieder auf die CPU zur Weiterverarbeitung zu holen.
Selbst wenn die CPU zum Beispiel 3 mal so lange braucht, das hin und her schieben dauert länger..

[Tobalt]

Das machen die nur weil diese CCDs im Server auch genutzt werden und KI der heiße Scheiss grade ist.


Und Leute die Rechenzentren bauen, sind zu dumm um GPUs oder TPUs für ihre AI Workloads zu nutzen? Oder was willst du damit sagen?

@HPVD:

Bei "kleinen" AI usecases, die keine GPU auslasten, wirst du auch keine großen Nachteile erfahren, wenn du das einfach in den regulären Vektor ALUs der CPU rechnest, nur dass die CPU dann halt billiger ist.

[Der_Korken]

Was muss ich mir denn unter einem Memory Profiler vorstellen?

[HPVD]

Ergänzung (aus technischer Sicht):
und auch von der Latenz kann es Sinn machen, kleine KI Dinge auf der CPU zu machen, statt sie erst von der CPU zur GPU zu schieben und dann das Ergebnis wieder auf die CPU zur Weiterverarbeitung zu holen.
Selbst wenn die CPU zum Beispiel 3 mal so lange braucht, das hin und her schieben dauert länger..

-> das wird erst besser wenn CPU und GPU auf den gleichen Speicher zugreifen können...

[HPVD]

Was muss ich mir denn unter einem Memory Profiler vorstellen?
analog zu sowas vielleicht?
https://www.intel.de/content/www/de/de/gaming/extreme-memory-profile-xmp.html

[HOT]

Und Leute die Rechenzentren bauen, sind zu dumm um GPUs oder TPUs für ihre AI Workloads zu nutzen? Oder was willst du damit sagen?
[...]
Das war nur flapsig, nicht wertend :freak:

[Tobalt]

Ok, aber wenn jemand eine neue CPU Gen plant, dann macht die Firma das sicher nicht "flapsig" sondern hat einen Usecase im Sinn. Und dieser erschließt sich mir grad nicht.

[Der_Korken]

analog zu sowas vielleicht?
https://www.intel.de/content/www/de/de/gaming/extreme-memory-profile-xmp.html

Das Gegenstück dazu wäre EXPO. Ich kann mir aber nicht vorstellen, dass AMD sowas auf die Slide packen würde, zumal es bei Zen 4 (Einführung von EXPO) nicht steht.

[davidzo]

Hm, ich frag mich was 16ch DDR5 bringen soll. Schon jetzt gibts viele Serverchassis die gar nicht soviel Platz haben den riesensockel und die vollen 12ch unter zu bringen und das daher auf 8ch limitieren. Außerdem explodiert der Verbrauch mit so vielen Dimms. Stacked Cache oder inboard HBM halte ich für die wesentlich smartere Lösung für Bandbreitenlastige Szenarios.
Ein weiterer Nachteil an 16ch ist dass man wieder eine neue Plattform validieren muss und wenig später schon DDR6 um die Ecke kommt und man wieder wechseln muss.

Was ich für wahrscheinlicher halte ist dass auch AMD irgendwann MCR-Dimms unterstützen wird. Wobei ich nicht weiß wie die Lizenzsituation da aussieht, nachher ist das proprietär Intel verteilt keine Lizenzen. Wenn Intel mit 12ch MCRdimm antritt und AMD ohne, dann braucht man vielleicht die 16ch um per brute force mit Intel konkurrieren zu können.

[Zossel]

Das Gegenstück dazu wäre EXPO. Ich kann mir aber nicht vorstellen, dass AMD sowas auf die Slide packen würde, zumal es bei Zen 4 (Einführung von EXPO) nicht steht.

Das dürfte eher zusätzliche Sensorik zur Hitrate von Caches und Auslastung der DRAM-Anbindung sein.

Spielzeug-RAM interessiert außerhalb des Sandkastens kein Schwein.

[Zossel]

Hm, ich frag mich was 16ch DDR5 bringen soll. Schon jetzt gibts viele Serverchassis die gar nicht soviel Platz haben den riesensockel und die vollen 12ch unter zu bringen und das daher auf 8ch limitieren. Außerdem explodiert der Verbrauch mit so vielen Dimms. Stacked Cache oder inboard HBM halte ich für die wesentlich smartere Lösung für Bandbreitenlastige Szenarios.
Ein weiterer Nachteil an 16ch ist dass man wieder eine neue Plattform validieren muss und wenig später schon DDR6 um die Ecke kommt und man wieder wechseln muss.

Es wird wohl weniger um Bandbreite gehen, sondern um die Mengen an RAM die man in die Kisten reinstopfen kann.

[y33H@]

Man muss bedenken, dass die Slides, die da gezeigt werden von Ende 21 oder früher sind.Da steht 2023 unten links.

[davidzo]

Es wird wohl weniger um Bandbreite gehen, sondern um die Mengen an RAM die man in die Kisten reinstopfen kann.

Dafür ist doch aber CXL memory da. Außerdem könnte man natürlich auch 2 DPC boards bauen wenn man wollte.

Nee, wenn es um die Speichergröße geht gibt es elegantere Lösungen als das i/o DIE und den Sockel auf zu blähen. Das muss hier um die Bandbreite gehen imo. Die Bandbreite wird auch schnell zum Limit wenn man mit Bfloat16 und aufgebohrten AVX512 Einheiten bei AI workloads mitspielen will.

[Zossel]

Dafür ist doch aber CXL memory da. Außerdem könnte man natürlich auch 2 DPC boards bauen wenn man wollte.

Was sind "DPC boards"?

Ansonsten werden die Latenzen die über letztendlich kohärentes PCIe möglich sind bestimmt nicht besonders prall sein.
Hat da jemand Zahlen?

[Skysnake]

Ich hol mal das Popkorn. Viel Spaß beim spekulieren 😁

[davidzo]

Was sind "DPC boards"?

2DPC = 2 Dimms per Channel. board = mainboard.
Früher war 2DPC der Standard, so wie auf dem Desktop immer noch.

[Lehdro]

Was sind "DPC boards"?

2 DPC Boards sind halt z.B. bei 12 Channel CPUs 24 RAM Slots Mainboards. Halt "2 DIMMs per Channel"

[latiose88]

diese kleine ki Sache,was für Vorteile hätte man da wenn es um Zahlen geht wie bei Videoumwandeln und so.Hoffe das auch was für mich rausschaut weil sonst ist es viel zu wenig für mich.Will ja noch mehr Mehrleistung haben.Das mit KI bringt mir leider nix.Dann werde ich da zumindest leer Ausgehen,schade.

[HOT]

Neue Infos: Es gibt wohl 8, 16 und 32C CCDs. Ich würde mal darauf tippen, dass AMD ab Zen5 mit dem Ladder-Cache 16C CCX hinbekommt.
Zudem soll es bei Zen6 keine reinen c-CCDs mehr geben, ich wette, dass die einzelnen CCDs beides enthalten werden, also 4+4, 8+8 und 8+24 oder sowas. Mit dem erwarteten IOD-Stacking wären dann auch monolithische APUs Vergangenheit.

[Nightspider]

Wenn die Hotspots dichter gepackt werden dürfte es schwierig werden mit der alten V-Cache Technik den Cache draufzubekommen ohne das Bereiche zu heiß werden.
Wenn der IOD gestacked wird, könnte das auch der Zeitpunkt sein ab dem der V-Cache unter die Kerne kommt, also zwischen IOD und CCD.

*außer AMD halbiert die benötigte Fläche für V-Cache indem man 2 Layer V-Cache verwendet. Aber besser wäre es natürlich den L3 dann gleich komplett aus dem CCD zu bekommen, zwecks günstigerer Fertigungskosten.

Den L3 komplett aus dem CCD zu bekommen könnte die Mehrkosten durch das Stacking des Caches komplett ausgleichen, vielleicht sogar mit einem Plus.

Vorraussetzung ist natürlich genug Kapazität beim Packaging neben MI500/MI600 und RDNA5.

Mit dem erwarteten IOD-Stacking wären dann auch monolithische APUs Vergangenheit.

Wirft allerdings die Frage auf wohin die GPU wandert.

Die 2-4 CU IGP im IO wie bei Zen4 wird schließlich nicht ausreichen.

Wird man dann für Laptops einfach per CoWos wie bei Strix Halo die GPU direkt daneben anbauen?

Das Ganze könnte man schon sehr modular gestalten.

Business Laptop: 4-6 CUs im IO (das wäre quasi die Standard CPU aus dem Desktop)

Average Laptop: 20-24 CUs per CoWos (gefüttert über LPPDR5X/6X)

Gaming Laptop: 48-60 CUs per CoWos mit 1-2 MCDs auch mit CoWos

Frage am Rand:

Wie viel günstiger ist ein N6 Wafer Ende 2023 im Vergleich zu Anfang 2022 ?

Wie hoch schätzt ihr die Chance ein das AMD beim Cache noch 2 oder 3 Jahre bei N6 bleibt?

Wenn ich es richtig mitbekommen habe, ist der L3 Cache beim Takt durch den N6 Prozess limitiert.
Ich kann mir aber nicht vorstellen das der Vorteil von N4 die Mehrkosten ansatzweise aufwiegen würde.

Ein angepasster Prozess mit weniger Belichtungsschritten für den Cache in 4nm halte ich aber für möglich.
Welche Optionen TSMC anbietet kriegen wir ja leider nicht mit.

[basix]

Neue Infos: Es gibt wohl 8, 16 und 32C CCDs. Ich würde mal darauf tippen, dass AMD ab Zen5 mit dem Ladder-Cache 16C CCX hinbekommt.
16C CCD kann man bei Zen 5c vermuten, ja.

Bei Zen 6 hören sich 8C pro Chiplet aber nicht sehr sinnvoll an, wenn man auf 3D-Stacking gehen sollte (CCD besteht aus Base-Die bestehend aus IFOP und L3$ mit on-top stacked Cores inkl. L2$). Ausnahme: Man hat ein 8C Chiplet, wo man 1/2x Chiplets pro CCD verwenden kann. Zen 6c dann als 16C Chiplet? 1/2x Chiplets pro CCD. Die gestackten Chiplets werden via Base-Die zu einem "unified CCD" gemacht.

Und: Dann noch die Frage ob Wafer-on-Wafer anstatt Chip-on-Wafer Stacking . Wäre prozesstechnisch günstiger, aber Yield und Binning-Möglichkeiten sind vermutlich schlechter.


Zudem soll es bei Zen6 keine reinen c-CCDs mehr geben, ich wette, dass die einzelnen CCDs beides enthalten werden, also 4+4, 8+8 und 8+24 oder sowas.
Woher die Info? Höre ich zum ersten Mal. Und macht irgendwie keinen Sinn.

Mit dem erwarteten IOD-Stacking wären dann auch monolithische APUs Vergangenheit.
Ich denke, AMD wird ein zentrales IOD beibehalten. Es ist aus praktischen Gründen (z.B. rein geometrischer Flächenbedarf sowie Chiplet-Anordnung) einfach nicht sinnvoll, die Cores aufs IOD zu stacken.

Hier müssen wir dann allerdings uns einigen, was als IOD bezeichnet wird. Ich sehe das so:
- IOD = DDR Phy, IFOP, iGPU, Display & Multimedia, USB, PCIe, ... -> N6
- CCD Base Die = IFOP & L3$ (vermutlich 64MByte) -> N4P
- CCD Core Die = Cores & L2$ -> N4P & N3E
- V-Cache = Wird zwischen Base & Core Die gestacked, vermutlich ebenfalls 64 MByte -> N6

Die physische Anbindung ans IOD ändert sich allenfalls (siehe MCDs von N31/32, Glas-Substrat von Intel), doch CCDs aufs IOD oder ein APU-Die zu stacken scheint mir sehr, sehr fraglich zu sein.

Wirft allerdings die Frage auf wohin die GPU wandert.

Die 2-4 CU IGP im IO wie bei Zen4 wird schließlich nicht ausreichen

Siehe obige Auflistung von mir. Ich denke nicht, dass man ein zentrales IOD wegoptimiert. Dazu bietet dieses Konzept zu viele Vorteile.

Ich hoffe es werden 6-8 CUs. Das wäre ein ordentlicher Sprung und performancemässig in etwa auf Niveau der schnellsten heutigen Mobile-APUs (welche mit reduziertem Takt laufen).

[amdfanuwe]

Ich denke nicht, dass man ein zentrales IOD wegoptimiert.
Mal abwarten, wie MI300 aufgebaut ist. Vielleicht bewährt sich das Konzept und ist auch im Desktop nutzbar.
Die CoWoS Kapazitäten werden benötigt um bei MI300 die 4 Compute Module und den HBM miteinander zu verbinden.
Für Desktop benötigte man nur ein Compute Module und wäre von der CoWoS Knappheit nicht betroffen.

[basix]

MI300 ist ein ganz anderes Kaliber und Anwendungsgebiet. Und viel teurer in der Herstellung und gleichzeitig weniger gut skalierbar als CCD + IOD vom heutigen Epyc/Ryzen, da entweder IO wegfällt oder man Dummy Dies stacken müsste. Für "normale" Anwendungszwecke wäre sowas wie MI300 zudem deutlich overengineered.

Ich denke schon, dass bei Zen 6 3D-Stacking zum Einsatz kommt / kommen kann. Aber eben nur insofern, dass das heutige CCD aufgesplitted wird in Cores (Core Die) sowie Cache & IO (Base Die). Das dortige IO umfasst aber eigentlich nur IFOP sowie allenfalls einen schnellen CCD-to-CCD Interconnect (2x CCDs lassen sich kombinieren), aber nicht das restliche IO-Zeugs wie DDR, PCIe und USB.

[dildo4u]

Er vermutet 32 Zen6 Chiplets für Server(2nm) und 16 Core für Ryzen.(3nm)


qpzTmKjaIMU

[basix]

Ich hätte eher erwartet, dass man auf 16C / CCD geht. Ob stacked oder nicht ist eine andere Frage (Cache + IFOP unten, Cores oben).

Edit:
OK, er geht auch von 16C / CCD aus. Aber allenfalls gibt es keine 2x CCD SKU, dafür 1x CCD + 1x AIE. Meine Meinung: AIE gehört für Consumer ins IOD. Siehe Phoenix, siehe Strix. Für Zen 5 oder 6 erwarte ich ein neues IOD mit entsprechendem AIE integriert. Und wenn man 2x IFOP am IOD spendiert, wird es auch 2x 16C CCD SKUs geben. Egal ob AIE als Option oder nicht.

[HOT]

Wie gesagt, es gibt 8, 16 und 32C CCDs.

[basix]

8C macht irgendwie keinen Sinn neben dem 16C CCD. Oder für was würdest du das verwenden? Mobile?

[iamthebear]

Also ich verstehe das so:

32 Kerne => Entspricht den bisherigen c Kernen d.h. auf Density optimiert um mehr Kerne unter zu bringen aber dafür weniger Takt bei gleicher Spannung (ca. 25% weniger war es bei Zen4c).
Neu ist, dass man von 16 auf 32 Kerne geht und wohl auch, dass es nur 1 CCX pro CCD gibt (letzteres noch unsicher)

16 Kerne => Das entspricht den normalen Zen4 Kernen.
Neu ist, dass man von 8 auf 16 Kerne geht, wobei es auch nur CCX pro CCD gibt.
Noch unsicher ist, ob es weiterhin eine Option für mehr als 16 Kerne im Desktopbereich gibt. Meiner Meinung nach ja, denn wenn Intel mit ARL 8+32 bringt und die E Cores auch noch deutlich stärker sind als bisher, dann wird AMD nicht viel anderes übrig bleiben wenn sie die MT Krone nicht im Desktop nicht komplett aufgeben wollen.
Solange Intel nichts liefert ist es für AMD jedoch besser bei 16 Kernen zu bleiben, da sie dann die Workstation Kunden richtung Epyc/Threadripper Pro treiben.

8 Kerne => Eine alternative/abgespeckte Version des 16 Kern CCDs. Diese ist dazu da, um den Einstiegsbereich zu bedienen.
Ich kann mir gut vorstellen, dass diese Version später kommt und man eine Zeit lang versuchen wird die unteren Preissegmente mit Zen5 abzudecken ähnlich wie man es jetzt mit Mendocino (Zen2) und dessen 4 Kern CCX macht.

Ich halte den Ansatz von AMD für sehr sinnvoll, denn 8 Kerne sind im Midrangebereich nicht mehr lange haltbar und gerade beim Gaming verdoppelt sich bei 2 CCX auch der L3 Bedarf.
Umgekehrt macht es aber wenig Sinn mit einen 16 Kern CCD den Markt für Bürorechner aufmischen zu wollen wo so gut wie alle Anwendungen ST sind.

[basix]

Ja in Bürorechnern für reine Office Arbeiten sind 6-8C genug. Da wird ein ML Accelerator für Teams usw. fast wichtiger sein. Ergo: Hat man eigentlichs schon in Form der APUs.

Was ich mir vorstellen könnte: 16C & 32C sind stacked. 8C nicht. Das gibt dem noch einen zusätzlichen, fertigungstechnischen Aspekt.

[dildo4u]

Also ich verstehe das so:

32 Kerne => Entspricht den bisherigen c Kernen d.h. auf Density optimiert um mehr Kerne unter zu bringen aber dafür weniger Takt bei gleicher Spannung (ca. 25% weniger war es bei Zen4c).
Neu ist, dass man von 16 auf 32 Kerne geht und wohl auch, dass es nur 1 CCX pro CCD gibt (letzteres noch unsicher)

16 Kerne => Das entspricht den normalen Zen4 Kernen.
Neu ist, dass man von 8 auf 16 Kerne geht, wobei es auch nur CCX pro CCD gibt.
Noch unsicher ist, ob es weiterhin eine Option für mehr als 16 Kerne im Desktopbereich gibt. Meiner Meinung nach ja, denn wenn Intel mit ARL 8+32 bringt und die E Cores auch noch deutlich stärker sind als bisher, dann wird AMD nicht viel anderes übrig bleiben wenn sie die MT Krone nicht im Desktop nicht komplett aufgeben wollen.
Solange Intel nichts liefert ist es für AMD jedoch besser bei 16 Kernen zu bleiben, da sie dann die Workstation Kunden richtung Epyc/Threadripper Pro treiben.

8 Kerne => Eine alternative/abgespeckte Version des 16 Kern CCDs. Diese ist dazu da, um den Einstiegsbereich zu bedienen.
Ich kann mir gut vorstellen, dass diese Version später kommt und man eine Zeit lang versuchen wird die unteren Preissegmente mit Zen5 abzudecken ähnlich wie man es jetzt mit Mendocino (Zen2) und dessen 4 Kern CCX macht.

Ich halte den Ansatz von AMD für sehr sinnvoll, denn 8 Kerne sind im Midrangebereich nicht mehr lange haltbar und gerade beim Gaming verdoppelt sich bei 2 CCX auch der L3 Bedarf.
Umgekehrt macht es aber wenig Sinn mit einen 16 Kern CCD den Markt für Bürorechner aufmischen zu wollen wo so gut wie alle Anwendungen ST sind.
Für Gameing wird sich die nästen 5 Jahre nix ändern da die Konsolen vorgeben was entwickelt wird.
Je größer die Budgets werden desto unwahrscheinlicher sind PC Only AAA Games.
Daher plant Intel ja mit 8 Big Core plus 32 E-Cores für Arrow Lake.

[The_Invisible]

16 Kerne => Das entspricht den normalen Zen4 Kernen.
Neu ist, dass man von 8 auf 16 Kerne geht, wobei es auch nur CCX pro CCD gibt.
Noch unsicher ist, ob es weiterhin eine Option für mehr als 16 Kerne im Desktopbereich gibt. Meiner Meinung nach ja, denn wenn Intel mit ARL 8+32 bringt und die E Cores auch noch deutlich stärker sind als bisher, dann wird AMD nicht viel anderes übrig bleiben wenn sie die MT Krone nicht im Desktop nicht komplett aufgeben wollen.
Solange Intel nichts liefert ist es für AMD jedoch besser bei 16 Kernen zu bleiben, da sie dann die Workstation Kunden richtung Epyc/Threadripper Pro treiben.

Glaub gar nicht das die Kernanzahl mehr Verkaufsargument Nr. 1 für solche CPUs sind, Intel spammt ja den Mainstream auch zu damit. Der große Unterschied ist dann Ram Channels und vor allem PCIe Lanes

Vor allem Intel geizt im Mainstream sehr damit, bei AMD mit 670e gehts ja noch obwohl der 4x PCIe Interconnect halt auch nicht das wahre ist.

AMD weiß das und lässt sich das mit Threadripper auch gut bezahlen, die Preise sind halt in einer Dimension wo man nicht eben denken kann "leg ich halt ein bisschen drauf und hab dann geilere Ausstattung". Von demher derzeit ein riesen Loch zwischen Mainstream und HEDT.

[basix]

RAM Channels interessiert doch die wenigsten Consumer. Gibt nur wenige Anwendungen, die von mehr Bandbreite profitieren. Speicherkapazität ist in Zeiten von 24/32/48 GByte pro DIMM auch fast nie ein Problem.

Für mich wären einzig mehr NVMe mit PCIe 5.0 und USB 4.0 Ports Kriterien, welche man bei Mainstream noch ausbauen könnte. Und hier bietet X670E eigentlich schon recht viel.

Edit:
Er vermutet 32 Zen6 Chiplets für Server(2nm) und 16 Core für Ryzen.(3nm)


https://youtu.be/qpzTmKjaIMU

Noch zu dem Interconnect Thema:
Ich vermute, dass AMD hier organische RDL verwendet. Ähnlich denen von den "Infinity Fanout Links" von RDNA3. Das würde die Kosten fürs Packaging im Rahmen halten und die Interconnects könnten einiges schneller und gleichzeitig sparsamer sein.

[/Locutus oB]

Für Gameing wird sich die nästen 5 Jahre nix ändern da die Konsolen vorgeben was entwickelt wird.
Je größer die Budgets werden desto unwahrscheinlicher sind PC Only AAA Games.
Daher plant Intel ja mit 8 Big Core plus 32 E-Cores für Arrow Lake.

das intel sich bei Desktop CPUs nach konsolen richtet würde gut zu ihnen passen....

ist cpu Leistung im Desktop NUR NOCH zum spielen wichtig?

Innovationenen gingen einmal anders...

[Exxtreme]

Ist nicht unbedingt schlecht. Wenn sie den Stromverbrauch der E-Kerne in den Griff bekommen dann passt das. :) Die E-Kerne sind bei Intel das eigentliche Problem grad. Sie fressen viel zu viel Strom für die Leistung, die sie bringen.

[/Locutus oB]

was ist nicht schlecht? auf Innovation und mehr Leistung verzichten?

[Exxtreme]

Wie gesagt, was Intel derzeit bremst sind die E-Kerne. Sie fressen exorbitant viel Strom für die Leistung, die sie bringen. Wenn man den Stromdurst in den Griff bekommt dann wird auch mehr Leistung rüberkommen da man eventuell viel höher takten kann. Die E-Kerne bräuchten wohl eine separate Stromversorgung. Derzeit hängen sie AFAIK am gleichen Stromkreis wie die P-Kerne und werden deshalb mit zu hoher Spannung betrieben.

[][immy]

Frage mich was man mit noch mehr Kernen um consumer Bereich will? Außer mit viel ineffizientem Code in spielen bekommt man die Kerne eigentlich nicht ausgelastet. Und wenn noch die Datendekomprimierung auf der GPU in spielen läuft, gibt es noch weniger zu tun.
Physik und KI wird ebenfalls auf die GPU ausgelagert... und Simulationsladtige Spiele sind meist extrem IPC abhängig.
Klar gibt es noch andere Dinge als Spiele aber ich muss sagen, die Technik ist inzwischen derart fortgeschritten, das man auf absehbare Zeit in dem Bereich nicht mehr viel über die Anzahl der Kerne reißen können wird.
Schwieriger wird vermutlich die Kühlung wenn die Dies kleiner werden. Da können zusätzliche Kerne natürlich helfen. Mehr Cache etc würde da aber wohl mehr schaffen.

[The_Invisible]

RAM Channels interessiert doch die wenigsten Consumer. Gibt nur wenige Anwendungen, die von mehr Bandbreite profitieren. Speicherkapazität ist in Zeiten von 24/32/48 GByte pro DIMM auch fast nie ein Problem.

Für mich wären einzig mehr NVMe mit PCIe 5.0 und USB 4.0 Ports Kriterien, welche man bei Mainstream noch ausbauen könnte. Und hier bietet X670E eigentlich schon recht viel.


RAM-OC sollte stabiler sein wenn nur 1 DIMM pro Kanal. Anscheinend auch nicht so viel teurer wenn man sich an alte Intel HEDT Zeiten zurückerinnert.

Man hat aber wie gesagt selbst bei X670e Boards Probleme mit dem mageren Interconnect zum Chipsatz, wäre halt schön wenn alles von der CPU kommt. Außerdem fängt bei den meisten Boards bei 3/4 NVME Slots schon massives Sharing bzw abschalten von anderen I/O Sachen an.

Ansonsten: Ja selbst 4 Kerne genügen heute Office mäßig noch locker für alles, meine Mutter hat noch immer meinen alten Intel Q6700 und keine Probleme wenn gepaart mit SSD + Grafikkarte mit entsprechend Videodecoder.

Aber eh egal, selbst die billigsten Office-Kisten haben heute schon >=6C/12T und man fragt sich für was eigentlich...

[/Locutus oB]

wenn das soo ist brauchen wir ja keinen zen6.
Spekulationen beendet...

[Der_Korken]

wenn das soo ist brauchen wir ja keinen zen6.
Spekulationen beendet...

Die Wahrheit ist zumindest im Bereich Gaming, dass 8 Kerne in allen Lagen mehr als ausreichend sind. Die Unterschiede zwischen 8-Kernen und größeren Modellen lassen sich quasi mit höheren Boost-Clocks und mehr Cache bei letzteren erklären. In einem neulichen Test auf CB wurden auch nochmal ein paar ältere CPUs vermessen: https://www.computerbase.de/2023-11/cpu-gaming-benchmark-2023-amd-ryzen-intel-core/

Nur in Ratchet & Clank kann sich bei AMD der 8-Kerner der Vorgängergeneration gegen den 6-Kerner der Nachfolgegeneration durchsetzen. Ansonsten hat man durchgehend eine strikte Rangordnung: Ganz unten Zen 1, dann alle Zen-2-Modelle (egal wie viel Kerne), dann alle Zen-3-Modelle (egal wie viele Kerne), dann Zen 4. Modelle mit 3D-Cache ausgenommen. Dass man weiterhin 16-Kerner anbieten wird, ist völlig OK, aber 32-Kerner und ähnliches sind eine so kleine Nische, dass ich da nicht viel erwarten würde. Auch eine dicke IO-Ausstattung werden wir eher nicht sehen, da die Masse eben nicht 3 M2-SSDs mit voller 4xPCIe 4.0 (oder gar 5.0) Anbindung braucht, genauso wenig wie 14 SATA-Anschlüsse und 28 USB-Ports. AM5 ist schon eine relativ teure Plattform geworden und die hohen Mainboard-Preise haben AMD das Client-Geschäft Ende 2022 ordentlich verhagelt. Zen 4 lag anfangs wie blei in den Regalen und das lag nicht daran, dass die CPUs so schlecht waren.

[/Locutus oB]

ist schon alles soweit klar, aber zu sagen die games/konsolen geben es so "vor" ist nicht Innovations fördernd. Intel sieht es ja scheinbar auch so, da hoffe ich doch sehr stark das amd immer noch genug "neue" ideen für zen6 hat.

[Der_Korken]

Es wird sowohl mit Zen 5 und Zen 6 gesunde IPC-Steigerungen geben, denn die führen auch bei "konsoligen" 8-Kernen immer zu mehr Leistung in Spielen. Und mit Stacking wird man die Latenzen und oder die Effizienz noch deutlich verbessern können. Alles deutlich sinnvoller für Consumer als ein 32-Kern-Holzhammer.

[Savay]

Definiere "Consumer".
Also mit DSS, Siril und Co. bekäme ich sicher auch als "Consumer" 32 Kerne recht gut ausgelastet... :wink:

Die Ryzen 9 waren aber streng genommen irgendwie noch nie wirklich reine "Consumer" CPUs...das tendiert eher richtung "Prosumer" in Neusprech und ist quasi auf halbem Weg zu einer "Workstation"...
Für alles drunter gibt's ja eigentlich die R 7 inkl den X3D für die wirklich reinen Gamer.

Das bei Intel grundsätzlich nur die 9er Reihe sowohl die höchste 1T Performance als auch die meisten Kerne UND die höchste Gaming Performance hat ist eher deren strikt hierarchische Produktsegmentierung.

[][immy]

ist schon alles soweit klar, aber zu sagen die games/konsolen geben es so "vor" ist nicht Innovations fördernd. Intel sieht es ja scheinbar auch so, da hoffe ich doch sehr stark das amd immer noch genug "neue" ideen für zen6 hat.

Das Problem ist eher alle Threads und Aufgaben zu synchronisieren. Bei einer Echtzeitanwendung wie Spielen ist das eher schwierig und es läuft meist darauf hinaus, das man ein paar Kerne hat die man voll auslasten kann und der Rest nur manchmal was ab bekommt. Was man da sinnvoll Teilen kann ist halt endlich. Man kann natürlich wahnsinnig viel Rechenleistung in ineffizientes Zeugs stecken, ist aber halt auch nicht zielführend.

Erhöhung der IPC hilft aber immer. Es werden halt immer mehr Aufgaben ausgelagert.
Klar man könnte so was wie KI in spielen verbessern und quasi jeden NPC deutlich komplexe gestalten (Tagesabläufe etc), aber das wiederum ist so rechenintensiv (relativ schnell mit immer mehr NPCs), das es da ganz schnell zu Flaschenhälsen kommt an den unterschiedlichsten Stellen (auch bei der Entwicklung selbst). Lässt sich vermutlich aber auch besser auf Grafikkarten auslagern ;)

Aber das betrifft halt eher nur Spiele. Im Office Bereich haben wir diesen Punkt schon lang erreicht und da wird immer mehr in die Cloud verlagert.
Videoschnitt ist wohl noch etwas wo mehr Kerne immer nützlich sind, aber ist nun mal nicht die Masse der Leute die das braucht.

[davidzo]

Ich sehe das Problem nicht. Das hatten wir doch schon immer. Rendering ist eigentlich beliebig parallelisierbar. Und Spiele sind eben zum Großteil Rendering. Je moderner die Engine, je mehr Pathtracing, Voxel LODs/ GI, asset streaming etc. desto besser parallelisierbar, so würde ich das Einschätzen.

Wir hatten diesen Punkt in der Vergangenheit immer wieder. Beim Wechsel von Dual- auf Quadcores und zuletzt beim Wechsel von Quad auf Hexacores. Derzeit zeichnet sich gerade ab dass 8-und Mehr-kerner schon jetzt besser performen als Sechskerner. Das war vor 1-2 jahren in Games noch nicht der Fall, da waren 5600X und 5700X in Spielen absolut identisch. Und auch der 7800X3D hat manchmal schon das Nachsehen gegenüber dem 7950X und 13900K, wenn auch noch selten.

Zu DirectX10 Zeiten waren Dualcores die schnellsten Gaming CPUs. Ein Thread fürs Rendering und einer für die Compute Tasks. Ht-Threads für alle Hintergrundtasks und Windows. GTAIV war das erste Spiel dass den Q6600 auslasten konnte, vorher waren schnell taktende Dualcores das Maß der Dinge.
DirectX11 hat dann relativ lange die Dominanz von Quadcores zementiert, da nur ein main render thread mit der GPU sprechen kann und die anderen zu Nebentasks verdammt waren.

Dass die Mehrzahl der Spiele nicht über 8 Kerne skaliert liegt denke ich mehr am Optimierungsziehl als an der Sache an sich. 8Kerne/1T sind halt seit den last-gen Konsolen der Standard und Intel hatte mit 8Threads quasi lange Zeit etwas vergleichbares. Es hat vor allem durch Intel sehr lange gebraucht bis die installierte Basis 8 echte Kerne bzw. 16T erreichte.

Wir hatten in der Vergangenheit bei jedem Core-count Wechsel eine vermeintlich unüberwindbare Software-Barriere. In Wirklichkeit war es aber eine Verbreitungsbarriere. Und da ist im moment vor allem AMD das problem, also umgekehrt zu früher wo sie bei den Kernanzahlen meist führend waren. Sobald die installierte Basis zu mehr als 50% mehr als 8C/16T bietet, also z.B. 12C/24T oder 16C/24T ändert sich das Optimierungsziehl. Danach wird es noch 1-3 jahre dauern bis diese Spiele den Markt erreichen.

Wie üblich fährt man also besser damit immer nur midrange zu kaufen und lieber häufiger zu upgraden anstatt alle fünf Jahre Highend für zu viel Geld.

[][immy]

...
Und auch der 7800X3D hat manchmal schon das Nachsehen gegenüber dem 7950X und 13900K, wenn auch noch selten.
...
Das liegt eher am Taktunterschied.
Wirkliche Vorteile hat man normalerweise nicht. Wie gesagt, die Synchronisation der Threads ist halt irgendwann am ende und mehr bringt dann nicht mehr wirklich mehr. Und eine große Aufgabe (Daten entpacken) die man gut verteilen könnte fällt bald weg. Mit Verschwendung von Ressourcen bekommt man natürlich immer was gedeichselt aber es nähert sich dem Ende zu.
Mit den Konsolen hat das nur indirekt zu tun. Die sind bei 8 Kernen (eigentlich 6,x-7) geblieben, haben aber diese Gen hyperthreading (wie man es nun auch immer nennen will) spendiert bekommen. Der größte Zuwachs kommt aber über die IPC Steigerung.
"Echtzeit" ist halt das Problem, das sich nicht unendlich zerlegen lässt. Selbst Simulationsspiele sind gern mal auf wenige Kern-Threads "spezialisiert". Mit steigender Komplexität steigt halt auch der Aufwand und irgendwo ist dann gern mal eine Grenze ab wo es keinen Sinn mehr macht.
Ja in der Vergangenheit war es gerne mal <dx12 was die Bremse war, aber die ist schon lange weg gefallen. Und auch hier reden wir eigentlich nur über Grafikaufgaben. Abseits dessen sieht es dann noch schlechter aus, weil diese Aufgaben sehr klein sind, aber trotzdem sehr komplex werden können.

Ich sag ja nicht das es keine Anwendungsfälle mehr gibt, aber bei Echtzeit-spielen wird es langsam schwierig mehr Kerne sinnvoll zu beschäftigen.

Soundkarten sind ja inzwischen auch überflüssig geworden und diese Berechnung werden nebenbei von der CPU und teils inzwischen auch von der GPU übernommen.

Klar mit KI in Spielen könnte man auch noch einiges machen, aber hier ist eher die Komplexität und damt verbundene bug-Anfälligkeit ein Problem.

Btw, das aktuelle cities skylines hat auch eher ein Problem mit der IPC als mit der Anzahl der Kerne (so wie auch Anno). Nebenaufgaben berechnen und auslagern ist weniger ein Problem. Diese Ergebnisse dann aber zu übernehmen schon eher.

[Leonidas]

Die Problematik liegt im Zwang, den Kernen möglichst gleich viel Arbeit aufgeben zu können - erst dann kommt schließlich mehr Performance heraus. Wenn ein DualCore zu einem Spiel mit einer Threadlast-Aufteilung von 90/10 kommt, ist der letztlich nur 10% schneller als ein SingleCore (Windows-Effekt nicht beachtet). Der rechenmäßig dickste Thread bestimmt, wie schnell der ManyCore-Prozessor sein kann - die anderen Threads müssen auf diesen warten.

Je mehr Kerne man ansetzt, um so schwieriger wird diese Ausgangslage zu beherrschen. Bei Zweikernern darf der rechenmäßige dickste Thread idealerweise nur 50% der Rechenleistung verbraten. Beim Vierkerner nur 25%, beim Achtkerner nur 12%, beim 16-Kerner nur 6%, beim 32-Kerner nur noch 3%. Das Risiko, dies nicht zu erreichen bzw. sogar weit zu verfehlen, nimmt mit mehr Kernen immer weiter zu. Wo liegt schließlich die Differenz zwischen 3% oder 6% Rechenauslastung eines einzelnen Threads? Ist eigentlich kein Unterschied - bedeutet aber im Negativ-Fall, dass der 32-Kerner nicht schneller als der 16-Kerner sein kann.

Will sagen: Nur weil es in der Vergangenheit diesen Übergang gegeben hat, ergibt sich daran keine Gesetzmäßigkeit. Kann durchaus sein, dass es da ein echtes Limit gibt oder aber dass die Weiterentwicklung zukünftig weit zähflüssiger wird als bisher.

[Der_Korken]

Der rechenmäßig dickste Thread bestimmt, wie schnell der ManyCore-Prozessor sein kann - die anderen Threads müssen auf diesen warten.

Das ist im Grunde eine Abwandlung von Ahmdahl's Law, aber sie trifft zu. Deswegen fand ich den Ansatz von Alder Lake von Beginn an sehr spannend, während sich viele über die "verkrüppelten Atom-Kerne" lustig gemacht und mehr dicke P-Cores gefordert haben. Es würde mich ehrlich gesagt nicht wundern, wenn wir bei Intel nie mehr als 8 P-Cores sehen werden und von AMD nicht mehr als 16. Eine Anwendung, die mehr als 8 oder 16 Kerne gut auslasten kann, kann in der Regel nach Belieben parallele Arbeit spawnen, sodass es sich nicht lohnt über diese Zahl hinaus dicke P-Cores zu verbauen, sondern das lieber durch flächeneffizienzere E-Cores zu erledigen. Selbst so ein 6+16-Ausbau wie der von MTL würde sich imho sehr gut auch im Desktop schlagen, sofern die ST-Leistung stimmt (laut Gerüchten soll es hier am Takt hapern ...).

Ich würde sogar weit gehen, dass AMD die Ryzen 9-Modelle lieber mit einem ZenX- und einem ZenXC-Chiplet bestücken sollte (für X=5 oder X=6), wo das ZenX-Chiplet optional noch 3D-Cache bekommen kann und ZenXC ausschließlich für einen MT-Boost da ist. Das wäre eine deutlich sinnvollere Einteilung als der aktuelle 7950X3D, wo mal das eine und mal das andere Chiplet schneller ist für eine bestimmte Aufgabe.

[Lehdro]

Ich würde sogar weit gehen, dass AMD die Ryzen 9-Modelle lieber mit einem ZenX- und einem ZenXC-Chiplet bestücken sollte (für X=5 oder X=6), wo das ZenX-Chiplet optional noch 3D-Cache bekommen kann und ZenXC ausschließlich für einen MT-Boost da ist. Das wäre eine deutlich sinnvollere Einteilung als der aktuelle 7950X3D, wo mal das eine und mal das andere Chiplet schneller ist für eine bestimmte Aufgabe.
Das wird denke ich auch langfristig so geplant sein, weil es einfach Sinn ergibt. Wäre auch ein ziemliches Effizienzbrett gegenüber Intel: Man stelle sich einen 16C CCD Zen6 + 3DV + 32C CCD Zen 6 (Dense) vor. Das wäre auch für Zen 5 schon denkbar, dann mit 8C 3DV + 16C Zen5c.

[OgrEGT]

(...)
Ansonsten: Ja selbst 4 Kerne genügen heute Office mäßig noch locker für alles, meine Mutter hat noch immer meinen alten Intel Q6700 und keine Probleme wenn gepaart mit SSD + Grafikkarte mit entsprechend Videodecoder.

Aber eh egal, selbst die billigsten Office-Kisten haben heute schon >=6C/12T und man fragt sich für was eigentlich...

... weil modernes Office wesentlich höhere Anforderungen hat als Du sie skizzierst und wohl über die des q6700 hinaus gehen...
Viele große Tabellen und Datenbanken gleichzeitig öffnen bearbeiten... viele Browser Tabs viele Teams Videokonferenzen viel Sicherheits und Verschlüsselung Software etc pp...

[basix]

Man müsste hier schon berufsmässiges Office von privatem Office & Browsing unterscheiden. Das hat ganz andere Anforderungen.

[][immy]

... weil modernes Office wesentlich höhere Anforderungen hat als Du sie skizzierst und wohl über die des q6700 hinaus gehen...
Viele große Tabellen und Datenbanken gleichzeitig öffnen bearbeiten... viele Browser Tabs viele Teams Videokonferenzen viel Sicherheits und Verschlüsselung Software etc pp...

Das wird Grad alles in die Cloud verlagert. Besonders Datenbanken etc. Selbst große Excel Dokumente sind kein Problem. Und ein thin Client im Office ist dann mehr oder minder nur zum streamen gut. Für den Rest gibt es Workstations und selbst da wird immer mehr auf Server (soll heißen Cloud) ausgelagert.
Nicht das ich das positiv finde, aber das ist halt der aktuelle Trend.

[Gortha]

Die "Cloud"-Clients sind meist lahmste Xeon-Haufen. Nicht zu gebrauchen für echtes Office...

[basix]

Cloud ist ausserdem wegen dem ganzen Networking Ballast oftmals sehr träge. Office 365 via Browser ist einfach Mist, selbst verglichen mit der relativ langsamen Local Client App.

[Zossel]

Cloud ist ausserdem wegen dem ganzen Networking Ballast oftmals sehr träge. Office 365 via Browser ist einfach Mist, selbst verglichen mit der relativ langsamen Local Client App.

Fast alle Browser-Clients sind scheiße zu bedienen.
Jeder macht seinen eigenen Kram alles sieht anders aus und grundlegende Funktionen verschwinden einfach.

[basix]

Ja, solche Probleme kommen dann noch dazu.

[robbitop]

[immy;13447033']
Physik und KI wird ebenfalls auf die GPU ausgelagert... und Simulationsladtige Spiele sind meist extrem IPC abhängig.
Das geht aber nur für Effektphysik und für KI nur, wenn es nicht relevant für den nächsten Frame ist. Die Latenz zwischen CPU und GPU ist zu groß damit die GPU die Physik für die CPU für den jeweils aktuellen Frame rechnen kann bevor die GPU dann dran ist 3D zu rendern.

Alles was in Echtzeit für den jeweiligen Frame gerechnet werden muss und Interdependenzen mit anderen Dingen hat, die die CPU berechnet, muss in die CPU bzw in das Silizium (oder mittels Chiplets und modernem packaging dann zumindest auf's gleiche Package).
Man könnte die IGP entsprechend für solche Sachen nutzen. Aber dummerweise haben nicht alle CPUs eine IGP und die sind auch sehr variabel was das Featureset und die Performance angeht. Deswegen hat man es wohl auch noch nicht gemacht.

[HOT]

Lt. RGT wird Desktop Zen6 bis zu 2 16c CCDs haben. Die CCDs sind nicht mehr nur Big oder compact, sondern Mischformen, wahrscheinlich
4+4c für 8 Kern CCD
8+8c für 16 Kern CCD
16+16c oder 32c Kern CCD

Der X3D-Cache wandert auf IOD und die Anbindung der Chiplets ans IOD wird ganz anders gelöst.

RGT geht auch anders als Tom von MLID, welcher ja spekuliert, dass es weiterhin AM5 sein wird, davon aus, dass es einen neuen Sockel geben wird, der aufgrund des neuen Packages notwenig wird - allein der 3,5mm HS dürfte da hinderlich sein. Zudem soll es ja CXL3 auch für Desktop geben bei AMD.

[w0mbat]

Der X3D cache ist so effizient, weil er ja wirklich nur cache ist und z.B. kein Steuerungslogik beinhaltet. Das funktioniert, weil er direkt über dem L3 cache der CCDs sitzt, die diese Logik haben. Er erweitert nur den vorhandenen L3 cache vertikal (SoIC).

Wenn der X3D cache jetzt auf's IOD wandert, wie wird der cache dann angesprochen? Und wenn er übers IOD mit den CCDs kommunizieren muss, wäre er viel langsamer.

Muss ich sehen um's zu glauben.

[robbitop]

Der IOD soll ja anscheinend per COWOS angebunden sein. Das würde eine latenzärmere Verbindung erlauben als aktuell wo das wirklich nur Standard MCM ist. Aber auf das Niveau vom heutigen L3 wird man aus Latenzsicht dennoch nicht kommen.
Da Cache aber mit modernen nodes nicht mehr skaliert, macht es ggf. schon Sinn, das zu tun. Für mich erscheint es dann eher eine Art L4 zu sein. Und die Implementierung kann ja genauso sein. 32 MiB im IOD und darüber dann 64 MiB gestackt. Oder aber mehr als 2 Stack ebenen um den Latenznachteil durch höhere Hitrate auszugleichen (oder es zumindest zu versuchen).
Ggf. muss man die kleineren Cachestufen auch etwas anwachsen lassen.

[w0mbat]

Dann müsste man aber die cache Verwaltung entwerder ins IOD stecken oder in das cache chiplet selber. Nicht unmöglich, aber total anders als jetzt. Und ja, wäre dann eher eine Art L4 cache.

Die leaks von MLID sehen für mich eher nach silicon bridge aus, also CoWoS-L/InFO-LSI oder FoCoS-B etc.

[robbitop]

Info_LSI / COWOS_L / EMIB / Silicone Bridge - das ist doch alles das gleiche?
Mit der Technoloie hat Apple es hinbekommen die GPUs aus 2x SoCs transparent zur Anwendung zu verbinden (was high bandwidth und low latency benötigt).

Ja es wäre eher eine Art L4 / LLC. Macht ja auch Sinn, wenn die IGP es mitnutzen können soll. Insbesondere wenn man bedenkt, wie viel mehr es in Richtung Chiplet gehen soll in Zukunft. Es könnten GCDs verbunden werden oder auch FPGAs oder andere accelerators. Entsprechend ist der Vorteil da, zentral Cache zu verwenden, der für "alle da" ist.

Aber ja damit das keine Performance kostet ggü der IMO heute sehr ausbalancierten Cachelevels wird man die kleineren Cachelevels anpassen müssen um den Cachepressure etwas zu verringern.

[HOT]

Der IGP soll in die CCDs wandern, was ich aber etwas komisch fände. So richtig rund hört sich das nicht an, da geb ich w0mbat recht. Irgend ne Brückenlösung muss man für den Cache aber so oder so finden, von daher ist das dann auch egal, ob das ein separater LLC ist oder ob eine Erweiterung des L3$ mit einem anderen CCD verbunden werden muss, denn man müsste so oder so über Siliziumbrücken gehen. Man könnte sogar beides machen.

[w0mbat]

Info_LSI / COWOS_L / EMIB / Silicone Bridge - das ist doch alles das gleiche?
Mit der Technoloie hat Apple es hinbekommen die GPUs aus 2x SoCs transparent zur Anwendung zu verbinden (was high bandwidth und low latency benötigt).
Jupp, InFO-LSI und CoWoS-L sind von TSMC. Gleiche tech, aber chip-first bzw. chip-last. EMIB ist von Intel und FoCoS-B ist von ASE.

Apple nutzt entweder CoWoS-L oder InFo-LSI für die Mx Ultra chips.

[amdfanuwe]

Mal gespannt, ob man heute Abend mehr zu den MI300 Base Dies erfährt (Infinity Cache, Anbindung an Chiplets...).
Vielleicht gibt das die Richtung für ZEN6 vor.

[robbitop]

Der IGP soll in die CCDs wandern, was ich aber etwas komisch fände. So richtig rund hört sich das nicht an, da geb ich w0mbat recht. Irgend ne Brückenlösung muss man für den Cache aber so oder so finden, von daher ist das dann auch egal, ob das ein separater LLC ist oder ob eine Erweiterung des L3$ mit einem anderen CCD verbunden werden muss, denn man müsste so oder so über Siliziumbrücken gehen. Man könnte sogar beides machen.
IGP im CCD fand ich auch komisch. Einerseits macht es Sinn, da Logik (wenn man annimmt, dass nur der GCD Teil der IGP im CCD verbaut ist und der Rest im IOD) vom neusten Node profitiert in Bezug auf Dichte. Ggf. ein enabler etwas stärkere/bessere IGPs zu verbauen und dennoch immer im Chipletansatz zu bleiben (und gar keine monolitischen APUs mehr anzubieten).
Wenn man allerdings mehrere CCDs verbaut, verschwendet man wiederum Fläche.
Allerdings könnte man auch GCDs mit IODs kombinieren, wenn man etwas mehr GPU power bräuchte (was auch mit der IGP im IOD ginge zugegebenermaßen).

[davidzo]

Lt. RGT wird Desktop Zen6 bis zu 2 16c CCDs haben. Die CCDs sind nicht mehr nur Big oder compact, sondern Mischformen, wahrscheinlich
4+4c für 8 Kern CCD
8+8c für 16 Kern CCD

Das macht total Sinn und hätte ich eigentlich schon für zen5 erwartet. Phoenix2 halte ich für den Testballon dafür.
Aktuell gilt der Turbotakt sowieso nur bei wenigen Threads Load und läuft nur auf preferred Cores. Bei richtigen Multithreaded Workloads wäre es egal ob der rest der Cores mit 1Ghz weniger läuft wenn dafür mehr Cores zur Verfügung stehen und diese auch noch weniger pro Core verbrauchen. Imo macht es daher eher Sinn wenn wir 4+4 und 4+12 sehen würden und keine 1:1 Aufteilungen.


Ggf. muss man die kleineren Cachestufen auch etwas anwachsen lassen.
Tun sie ja schon. Zen4 hat den L2 verdoppelt und Zen5 kümmert sich um den L1d.

Intel geht den Weg die OoO Ressourcen zu vergrößern und damit Cache misses abzufedern. Das ist auch eine Lösung und passt inbesondere auch gut zu den zusätzlichen Alus die mit Zen5 dazu kommen.

IGP im CCD fand ich auch komisch.
Ich denke das ist einfach nötig wenn man die IGP Leistung oberhalb von Phoenix noch steigern will. Ohne Zugriff auf den LLC limitiert ist der DDR5 das Limit. Wenn die GPU im CCD sitzt wird braucht man nur einen fetten Die to Die interconnect und der kann sowohl von der CPU als auch GPU benutzt werden. Intel dagegen hat wesentlich mehr Interconnect Overhead bei Meteorlake und fängt ja auch mit Lunalake schon an zurück zu rudern.


Es gab ja auch mal Gerüchte zu einem shared L2 bei zen5, der wohl noch nicht kommen wird, aber das könnte bei Zen6 eine Methode sein wie man die Off-CCD Hits reduzieren kann. Das kostet sicher auch alles Latenz, aber das muss man halt irgendwie durch bessere Hitraten wieder auffangen.

[robbitop]

Ja aber wie gesagt, wenn man 2x CCDs hat, dann verschwendet man top node Fläche. Oder auch für Desktop PCs wo eine schnelle CPU gewünscht wird und die IGP (fast egal wie schnell die ist) sinnfrei ist. IMO hätte man das eher als eigenes GCD implementieren sollen.

[davidzo]

Vielleicht gibt es im Desktop nur noch single CCDs.
Der Hauptgrund für die Einführung der Strategie sehr kleiner Chiplets mit Zen2 war ja nicht nur Yield, sondern auch Ersparnisse bei time-to market und den Maskeninvestitionen. Mit der größeren Marktanteilen von AMD mittlerweile scheint das in den Hintergrund gerückt zu sein, sieht man ja schon bei der Diversifizierung des Epyc Portfolios mit Genoa, Genoa-X, Bergamo, Siena, oder auch bei Navi31 und 32 etc. wo nicht die gleichen Compute-Chiplets zum Einsatz kommen.
Mittlerweile spielt der hohe Packagingaufwand wohl eine größere Rolle, erst recht wenn in Zukunft Die stacking oder EMIB und nicht mehr OSP zum Zuge kommt. Deshalb bekommt Zen6 bei Epyc ja auch 32Core CCDs. Ich könnte mir gut vorstellen dass AMD dann neben dem 32Kern CCD noch 16C und 8C CCDs anbietet oder bei nur 8 Kernen gar monolitisch bleibt.
16 und 8kerner haben dann je eine IGP mit drauf, die Epyc 32C CCDs dagegen nicht.

EDIT: In 2/3 nm wäre ein 16Kern Zen4 Die nur noch rund 80mm2 groß. Zen6 wird sicher auch mehr Transistoren pro Kern fressen, gleichzeitig werden die Mehrzahl der Kerne wohl auch High Density Kerne sein. Ich tippe darauf dass der 8Kerner monolitisch und womöglich in N4 bleibt, das 16Kern CCD unter 100mm2 bleibt und das 32Kern Epyc CCD auch nur wenig größer wird als der 16Kerner. Möglicherweise kommt auch nur das Epyc Chiplet schon in N2 und der Rest in N3P.

[Der_Korken]

Der IOD soll ja anscheinend per COWOS angebunden sein. Das würde eine latenzärmere Verbindung erlauben als aktuell wo das wirklich nur Standard MCM ist. Aber auf das Niveau vom heutigen L3 wird man aus Latenzsicht dennoch nicht kommen.
Da Cache aber mit modernen nodes nicht mehr skaliert, macht es ggf. schon Sinn, das zu tun. Für mich erscheint es dann eher eine Art L4 zu sein. Und die Implementierung kann ja genauso sein. 32 MiB im IOD und darüber dann 64 MiB gestackt. Oder aber mehr als 2 Stack ebenen um den Latenznachteil durch höhere Hitrate auszugleichen (oder es zumindest zu versuchen).
Ggf. muss man die kleineren Cachestufen auch etwas anwachsen lassen.

Ich hab das schonmal geschrieben, dass die 8C+3D-Cache Lösung für mich eine Art "lokales Optimum" ist wie damals die Conroe/Penryn-CPUs. Damit hat man auch Quadcores bauen können, aber die waren bei echten Quadcore-Aufgaben einfach bei weitem nicht so effizient wie es Nehalem war, obwohl Penryn 6+6MB L2 hatte und dieser auch wesentlich bessere Latenzen als der 8MB L3 im Nehalem***. Für 8T-Workloads wird man die aktuelle Config mit 3D-Cache auf dem CCD niemals schlagen. Sobald aber Spiele mehr als 8 Kerne auslasten, wird auch ein 7950X3D Probleme bekommen, obwohl er 16 Kerne hätte. Langfristig wäre es wahrscheinlich performanter, wenn man den 3D-Cache eine Ebene nochzieht und über die CCDs legt. Ob es ein L4 sein muss, ist eine andere Frage. Es gab auch mal Gerüchte, dass Zen 5 (oder irgendeine damals in der Zukunft liegende Zen-Iteration) einen shared L2 pro CCX besitzen würde. Das wäre auch denkbar mit z.B. 8x1MB L2, wo der Zugriff geteilt wird. Dann wären auch 8C pro CCX kein Problem mehr. Theoretisch könnte man die CCDs wieder in mehrere CCXs aufteilen, um die Latenz eines solchen L2 kleiner zu halten, weil man dahinter immer einen dicken 3D-Cache hat, der die misses auffängt. Es wird auf jeden Fall spannend.

*** Ja, Nehalem hatte erstmals den IMC on die und dadurch einen krassen Vorteil, aber die Skalierung von 2T auf 4T in entsprechenden rechenlastigen Spielen war bei Nehalem viel besser, das hatte afaik dargo damals ausführlich getestet.

[robbitop]

Vielleicht gibt es im Desktop nur noch single CCDs.
Der Hauptgrund für die Einführung der Strategie sehr kleiner Chiplets mit Zen2 war ja nicht nur Yield, sondern auch Ersparnisse bei time-to market und den Maskeninvestitionen. Mit der größeren Marktanteilen von AMD mittlerweile scheint das in den Hintergrund gerückt zu sein, sieht man ja schon bei der Diversifizierung des Epyc Portfolios mit Genoa, Genoa-X, Bergamo, Siena, oder auch bei Navi31 und 32 etc. wo nicht die gleichen Compute-Chiplets zum Einsatz kommen.
Mittlerweile spielt der hohe Packagingaufwand wohl eine größere Rolle, erst recht wenn in Zukunft Die stacking oder EMIB und nicht mehr OSP zum Zuge kommt. Deshalb bekommt Zen6 bei Epyc ja auch 32Core CCDs. Ich könnte mir gut vorstellen dass AMD dann neben dem 32Kern CCD noch 16C und 8C CCDs anbietet oder bei nur 8 Kernen gar monolitisch bleibt.
16 und 8kerner haben dann je eine IGP mit drauf, die Epyc 32C CCDs dagegen nicht.

EDIT: In 2/3 nm wäre ein 16Kern Zen4 Die nur noch rund 80mm2 groß. Zen6 wird sicher auch mehr Transistoren pro Kern fressen, gleichzeitig werden die Mehrzahl der Kerne wohl auch High Density Kerne sein. Ich tippe darauf dass der 8Kerner monolitisch und womöglich in N4 bleibt, das 16Kern CCD unter 100mm2 bleibt und das 32Kern Epyc CCD auch nur wenig größer wird als der 16Kerner. Möglicherweise kommt auch nur das Epyc Chiplet schon in N2 und der Rest in N3P.

80 mm² ist eine gute Die size für Yields und time to market. Wenn der GCD Teil der IGP aber auch noch mit rauf muss, wird das allerdings nichts mehr.

Ich hoffe, dass nur weil AMD jetzt mehr Budget und Resources hat nicht die ganzen Effizienzvorteile (die man nutzen musste als man kleiner war um zu bestehen) ad acta legt. Der Charme der Chiplets ist es ja yield zu erhöhen und weniger Entwicklungsaufwand zu haben und dann über chiplets die Performance zu skalieren.

[robbitop]

Ich hab das schonmal geschrieben, dass die 8C+3D-Cache Lösung für mich eine Art "lokales Optimum" ist wie damals die Conroe/Penryn-CPUs. Damit hat man auch Quadcores bauen können, aber die waren bei echten Quadcore-Aufgaben einfach bei weitem nicht so effizient wie es Nehalem war, obwohl Penryn 6+6MB L2 hatte und dieser auch wesentlich bessere Latenzen als der 8MB L3 im Nehalem***. Für 8T-Workloads wird man die aktuelle Config mit 3D-Cache auf dem CCD niemals schlagen. Sobald aber Spiele mehr als 8 Kerne auslasten, wird auch ein 7950X3D Probleme bekommen, obwohl er 16 Kerne hätte. Langfristig wäre es wahrscheinlich performanter, wenn man den 3D-Cache eine Ebene nochzieht und über die CCDs legt. Ob es ein L4 sein muss, ist eine andere Frage. Es gab auch mal Gerüchte, dass Zen 5 (oder irgendeine damals in der Zukunft liegende Zen-Iteration) einen shared L2 pro CCX besitzen würde. Das wäre auch denkbar mit z.B. 8x1MB L2, wo der Zugriff geteilt wird. Dann wären auch 8C pro CCX kein Problem mehr. Theoretisch könnte man die CCDs wieder in mehrere CCXs aufteilen, um die Latenz eines solchen L2 kleiner zu halten, weil man dahinter immer einen dicken 3D-Cache hat, der die misses auffängt. Es wird auf jeden Fall spannend.

*** Ja, Nehalem hatte erstmals den IMC on die und dadurch einen krassen Vorteil, aber die Skalierung von 2T auf 4T in entsprechenden rechenlastigen Spielen war bei Nehalem viel besser, das hatte afaik dargo damals ausführlich getestet.

Sehe ich ähnlich. Die CCX waren ja immer ein Kompromiss um Skalierbarkeit und Latenz unter einen Hut zu bringen. Auf Kosten dass der LLC außerhalb des CCX nicht nutzbar war (für IGPs, andere CCX, beschleuniger etc) und dass Inter Corelatenzen außerhalb des CCX deutlich anstiegen.

Die modernen Packagingmethoden sind hier sicherlich ein enabler die Konfiguration deutlich ändern zu können, ohne zu viele Nachteile zu bekommen. Das lokale Optimum zu verlassen ist nicht immer ganz ohne Risiken. Man kann sich dabei auch vertun.

[HOT]

Das macht total Sinn und hätte ich eigentlich schon für zen5 erwartet. Phoenix2 halte ich für den Testballon dafür.
Aktuell gilt der Turbotakt sowieso nur bei wenigen Threads Load und läuft nur auf preferred Cores. Bei richtigen Multithreaded Workloads wäre es egal ob der rest der Cores mit 1Ghz weniger läuft wenn dafür mehr Cores zur Verfügung stehen und diese auch noch weniger pro Core verbrauchen. Imo macht es daher eher Sinn wenn wir 4+4 und 4+12 sehen würden und keine 1:1 Aufteilungen.
[...]
Das ergibt überhaupt keinen Sinn. Schon von der Chipgeometrie nicht. Das wird mit großer Sicherheit 8+8 werden.
Und für Desktop brauchst du die ja auch, meinetwegen ein x800X mit einem 8+8 CCD als perfekte Spiele-CPU. Warum dafür 2 CCDs verschwenden? Die 4+4 sind sowieso nur für APUs und ultra-low-end interessant.

[Gipsel]

Mal gespannt, ob man heute Abend mehr zu den MI300 Base Dies erfährt (Infinity Cache, Anbindung an Chiplets...).
Vielleicht gibt das die Richtung für ZEN6 vor.
Genau. Cache im IO-Die und CCD obendrauf gestackt. Das ist ja schon länger im Spiel.
Erklärt vielleicht auch die Verwirrung, wo was integriert wird. Bei MI300 gibt es 4 IO-Dies mit insgesamt 8 GCDs obendrauf (2 pro IO-Die) und der Infinity-Cache ist im unteren IO-Die.

[HOT]

Ich denke auch, so wird Zen6 und auch RDNA5 ebenfalls aussehen - minus das hbm. MI300 bringt das in die Praxisreife, MI400 bringt es Ende 24 in high-volume, RDNA5 wird nach dem AI-Boom Ende 25 damit weitermachen und Zen6 dann Mitte 26 das Ganze in den Desktop-Massenmarkt bringen, 27 kommt das Ganze dann in dem mobilen Massenmarkt an. Man bekommt schnell ne Idee, warum man RDNA4c so überhaupt nicht gebrauchen konnte - MI400 ist viel wichtiger.

Übrigens kann das stinknormale Zen4-CCD, was ja jetzt schon seit nem Jahr auf dem Markt ist, einfach auf das IOD gestapelt werden.

[basix]

Bei CB gibt es Infos zum IOD Aufbau:
https://www.computerbase.de/2023-12/amd-mi300a-mi300x/

Prinzipiell könnte man die xGMI Anschlüsse bei Zen 6 weglassen und nur mit den TSV-ähnlichen Kontakten aufs IOD kontaktieren. z.B. wie es RDNA3 bei N31/32 macht, nicht 3D-Stacked.

[robbitop]

Genau. Cache im IO-Die und CCD obendrauf gestackt. Das ist ja schon länger im Spiel.
Erklärt vielleicht auch die Verwirrung, wo was integriert wird. Bei MI300 gibt es 4 IO-Dies mit insgesamt 8 GCDs obendrauf (2 pro IO-Die) und der Infinity-Cache ist im unteren IO-Die.
Genau daran dachte ich auch als ich die MI300X Präsentation gesehen habe.
Das wäre für Latency viel viel besser. Aber wahrscheinlich nicht billig was packaging tech angeht. Andererseits ist es ja noch eine Weile hin - ggf genug Zeit um die Verfügbarkeit und Preis von modernen Packaging Technologien zu verbessern.

Ich kann mir auch gut vorstellen, dass RDNA mittelfristig so gebaut werden wird.

[davidzo]

Das ergibt überhaupt keinen Sinn. Schon von der Chipgeometrie nicht. Das wird mit großer Sicherheit 8+8 werden.
Und für Desktop brauchst du die ja auch, meinetwegen ein x800X mit einem 8+8 CCD als perfekte Spiele-CPU. Warum dafür 2 CCDs verschwenden? Die 4+4 sind sowieso nur für APUs und ultra-low-end interessant.
Und Phoenix2 ist auch soo symmetrisch?
Ich glaube nicht dass AMD sich da auf Symmetrie versteifen wird. Die packen das rein was Preis-, Packaging und Fertigungstechnisch Sinn macht. Ich gehe allerdings davon aus dass sich beide Kernvarianten in einem CCD mit einem L3 pool kombinieren lassen. Und für Spiele ist ein gemischter CCD auch okay, da reichen ein paar wenige schnelle preferred Kerne.

Der Grund wieso die E-Kerne bei Intel in Spielen nichts bringen ist afaik nicht dass Spiele nur mit hochtaktenden P-Kernen etwas anfangen können, sondern dass Spiele aktuell nicht über 8C skalieren und moderne Intel CPUs eben dafür schon genug P-Kerne mitbringen. Es gibt da leider wenige Tests zu, aber wenn man die Physics / TimespyCPU Scores von 13500H (4P/8E) mit dem 13700H (6P/8E) oder 13900H (alle drei Alderlake) vergleicht, dann liegen die alle ziemlich gleichauf. Die Anzahl an P-Cores scheint hier keinen Unterschied zu machen, wenn dann ist es eher das Powerlimit, thermische Auslegung des Chassis bzw. die maximalen Taktraten des preferred Cores die den Ausschlag geben.

80 mm² ist eine gute Die size für Yields und time to market. Wenn der GCD Teil der IGP aber auch noch mit rauf muss, wird das allerdings nichts mehr.

Es muss nicht größer sein. Vielleicht braucht man sogar die CUs auf dem Logic DIE damit der DIE überhaupt genug Fläche hat um die IF Links unter zu bringen?

1. Sollte man das Scaling von N3E nicht vergessen. Für Logic ist das mit 1.7x gegenüber N5 angegeben. Ein reiner logic DIE in Zen4 CCD Größe wäre also lediglich 39mm2 groß.

2.
Dies:
Langfristig wäre es wahrscheinlich performanter, wenn man den 3D-Cache eine Ebene nochzieht und über die CCDs legt.

Wenn der LLC Cache auf den Base-DIE wandert wird ein 8Core CCX zu klein für den interconnect und der Wafer-Verschnitt steigt. Da ändern auch die etwas größeren Cores mit 50% größerem L1D und die 2x extra Alus nicht viel dran. Die CUs der GPU auf den Compute DIE zu packen ermöglicht dann nicht nur überhaupt erst einen ausreichend großen DIE, sondern bringt dann auch endlich den Zugriff der GPU auf den LLC pool mit, den wir so lange vermisst haben.

Für die 16C CCDs kann ich mir wiederum vorstellen dass es dort dann doch keine IGP gibt, was bei Epyc ja auch Verschwendung wäre. Wobei da überhaupt nicht klar ist ob überhaupt Consumer SKUs mit 16C CCDs kommen oder stattdessen weiterhin 2x8C zum Zuge kommt. Ich könnte mir auch vorstellen dass 8C+IGP und 16C CCD vom LLC- und ioDIE-Interconnect kompatibel sind und auch weniger unterschiedlich bei der Größe als die doppelte Kernanzahl vermuten lässt.

Und Latenztechnisch muss das gar nichts schlimmes sein wenn der LLC nicht mehr auf dem Compute-DIE sitzt. Sieht man ja an Zen3 und Zen4, die mit gestacktem Cache immer noch wesentlich bessere L3 Latenzen haben als Intel mit Raptorlake on-DIE. Wieso sollte AMD also noch einen Teil des L3s auf dem teuren N3 Compute-DIE belassen, wenn das eh nicht mit skaliert und man sowieso 3D Stacking fürs i/o DIE bringt?

[HOT]

Und Phoenix2 ist auch soo symmetrisch?
Ich glaube nicht dass AMD sich da auf Symmetrie versteifen wird. Die packen das rein was Preis-, Packaging und Fertigungstechnisch Sinn macht. Ich gehe allerdings davon aus dass sich beide Kernvarianten in einem CCD mit einem L3 pool kombinieren lassen. Und für Spiele ist ein gemischter CCD auch okay, da reichen ein paar wenige schnelle preferred Kerne.
[...]

Was hat den ein CCD einer potenziellen SpieleCPU mit Phoenix2 zu tun? Nur weil P2 asymetrisch ist muss doch nicht alles weitere asymetrisch werden, was ist das denn fürn Schluss :freak:.

Nix, der 16C ist mit Sicherheit 8+8. Man würde den ja auch so für Server benötigen, da der 32c ja sicherlich nur aus c-Kernen besteht.

8C -> 4+4 oder 2+6 (OEM-Ware, low-end), Nachfolger für Phoenix2, Mendocino
16C -> 8+8 (da gibts keine andere Option aus meiner Sicht) (Standard-CPUs für Desktop mit 1 oder 2 CCDs, Standard-Notebook-CPU mit einem CCD, Hochleistungs-Server/WS-CPUs für viel Takt), Nachfolger für Kraken, Strix, Granite Ridge, Turin/X, Sorano
32C -> 32c-Kerne (nur Server mit vielen Threads), Nachfolger für Turin-Dense, Turin AI

[robbitop]

@davidzo
gehst du davon aus, dass der IOD unter dem CCD gestapelt wird bei Zen 6?

[davidzo]

Was hat den ein CCD einer potenziellen SpieleCPU mit Phoenix2 zu tun? Nur weil P2 asymetrisch ist muss doch nicht alles weitere asymetrisch werden, was ist das denn fürn Schluss :freak:.

P2 ist imo der Testballon für künftige mixed Density CPUs auf einem DIE. Gegenüber Phoenix sind die Flächenersparnisse so gering dass man wohl auch mit salvages hätte arbeiten können. Aber man brauchte eben diesen Testballon, also wieso s einen Test nicht auch produktiv einsetzen um die Marge zu optimieren?

Auch für die Marketingkommunikation sehe ich hier die Blaupause. Es wird einfach nicht mehr kommentiert ob es dense Kerne sind oder nicht, sondern lediglich die MT Taktrate. Bisher macht AMD diese Unterscheidung lediglich im Server-Markt, wobei hier ja aber auch weniger L3 pro Kern und weniger IFOP Bandbreite zum i/o pro Kern anliegen.

@davidzo
gehst du davon aus, dass der IOD unter dem CCD gestapelt wird bei Zen 6?

Ja, zumindest hoffe ich das, denn das ist sowohl von den Leitungslängen als auch thermisch am sinnvollsten. Dann kann trotzdem oben der Compute-DIE gut gekühlt werden. Eine leichte Überlappung reicht wahrscheinlich schon, wenn man sich mal die TSVs vom 3D Vcache anguckt und bedenkt dass man die next gen noch dichter packen wird. Die Alternative wäre halt EFB bzw. TSMC LSI wie auch schon bei den Apple Ultra CPUs.

[Leonidas]

https://twitter.com/Olrak29_/status/1742741127697166714
Medusa is the codename of Zen 6 client

[basix]

@davidzo
gehst du davon aus, dass der IOD unter dem CCD gestapelt wird bei Zen 6?

Ich gehe nicht davon aus. Zumindest nicht das IOD in der heutigen Form. Wenn man die CCD direkt aufs IOD stapelt, hat man mMn grosse Probleme bei der Skalierbarkeit oder macht es unnötig teuer. Nicht alles muss so aussehen wie CDNA3 ;)

Meine Speku:
- Es gibt ein Base Die fürs CCD mit IO ("IFOP-Next") und L3$ -> N4
- Oben drauf wird Zen 6 gestapelt (Cores bis und mit L2$) -> N3E
- 16C pro CCD -> N3E
- CCD & Base Die = ca. 50mm2 je Die
- Stacking von Base Die + CCD = Wafer-on-Wafer Stacking -> günstiger als das Die-on-Wafer Stacking wie beim heutigen V-Cache
- "IFOP-Next" ist etwas ähnliches wie bei RDNA3 die Infinity Fanout Links zwischen GCD und MCD -> Organischer RDL
- Variante: 32C pro CCD -> N2 -> Grösseres Base Die mit doppelt so viel Cache
- V-Cache kommt als Sandwich zwischen Base Die und CCD

[amdfanuwe]

Man müsste halt wissen, wie die Kosten und Yield für die verschiedenen Packages sind.
Vielleicht gibt es wieder Zwitter CCDs, die man sowohl Stacken als auch einzeln verwenden kann, wie das ZEN4 CCD.
Mobile, Desktop, TR, Server, HPC wollen ja alle bedient werden und haben unterschiedliche Anforderungen an maximalen Produktionskosten und Leistung.

[Nightspider]

Laut RGT ist das Stacking von CCDs auf IOD wohl bei Zen6 entweder vom Tisch oder war noch kein Thema.

Gibt intern aber eventuell 2-3 verschiedene Entwicklungsvarianten.

Das AMD alle Packaging Kapazitäten zu Datacenter / AI geschoben hat, wäre denkbar.

Eventuell hält sich AMD Intel mit Zen5 noch etwas auf Abstand und versucht erstmal neue Marktanteile zu gewinnen. Ist die Frage ob Zen6 dann trotzdem noch vor Intel landen könnte, wenn Intel auch voll auf Advanced Packaging setzt.

Bleibt zu hoffen das eine highend RDNA5 Variante mit Advanced Packaging trotzdem für Gamer erscheinen wird.

[amdfanuwe]

Laut RGT ist das Stacking von CCDs auf IOD wohl bei Zen6 entweder vom Tisch oder war noch kein Thema.

Wenn der Hahn kräht auf dem Mist, ändert sich das Wetter oder es bleibt wie es ist.
Warum sollte jetzt alles stacked sein bloß weil sie es bei MI300 machen?
Sicher, ist die energieeffizienteste und platzsparendste Art ein paar Chiplets miteinander zu verbinden. Aber auch nicht die billigste.
Braucht man das für Desktop?

[Nightspider]

Warum sollte jetzt alles stacked sein bloß weil sie es bei MI300 machen?

Weil L3 Cache in 3nm und 2nm arschteuer ist, zum Beispiel.

Weil es höhere Leistungsregionen erreichen lässt.

Um bisherige Kompromisse (CCD <-> CCD Latency) zu entschärfen.

Um die Effizienz zu verbessern und den Idle Verbrauch zu senken.

Weil man noch kleinere Chiplets mit hoher Yieldrate in neuen Prozessen fertigen kann ohne Probleme mit der Kontaktdichte zu bekommen.

Um alles in noch kleinere Packages zu bekommen. Wäre zumindest im Mobile Bereich ein kleiner Pluspunkt

Um die Konkurrenz schlecht dastehen zu lassen.

Such dir was aus. ;)

Es sprach ja auch keiner von "alles".

Zen6 wird aber nunmal AMDs übernächste highend Architektur und Advanced Packaging wird in immer mehr Bereiche einziehen.
Das ist so sicher wie das "Amen" in der Kirche.

Wenn es bei Zen6 nicht kommt, können wir Wetten darüber abschließen ob es bei Zen7 soweit sein wird.
Der Großteil der bisherigen CCDs besteht aus Cache und der wird deutlich teurer mit jedem Prozess.

Im Moment sieht es so aus als ob jedes Megabyte Cache mit jedem neuen Prozess 50-80% teurer wird!!!
Scaling ist kaum noch vorhanden und die Waferkosten verdoppeln sich fast mit jeder Generation.

[amdfanuwe]

Weil L3 Cache in 3nm und 2nm arschteuer ist, zum Beispiel.
Falls du den Faden verloren hast, es ging um Stacking der Chiplets auf dem IOD. Inwiefern wird dadurch der Cache billiger?

Weil es höhere Leistungsregionen erreichen lässt.
Macht im Desktop nicht das meiste aus.
Um bisherige Kompromisse (CCD <-> CCD Latency) zu entschärfen.
Da gibt es andere Möglichkeiten, z.B.: Wide IF, FanOut Package.
Um die Effizienz zu verbessern und den Idle Verbrauch zu senken.
Da würde ich eher am IOD ansetzen.
Weil man noch kleinere Chiplets mit hoher Yieldrate in neuen Prozessen fertigen kann ohne Probleme mit der Kontaktdichte zu bekommen.
Hast du dir mal die Kontaktdichte bei einem CCD angesehen? Ich meine, wieviele der Kontakte davon für den IF benötigt werden.
Und wird schon seinen Grund haben, warum AMD bei ~80mm² CCDs bleibt und lieber mehr Cores bei ZEN C verbaut anstatt mehr kleine Chiplets.
Um alles in noch kleinere Packages zu bekommen. Wäre zumindest im Mobile Bereich ein kleiner Pluspunkt
Mobile ist ein anderes Thema mit anderen Anforderungen als Desktop.

Um die Konkurrenz schlecht dastehen zu lassen.
Bin mal gespannt, was Meteor Lake der Konkurrenz an Gewinn beschert. Das Packaging hat nicht viel Leistung gebracht und dürfte mit dem Interposer und hohem TSMC Anteil an Tiles relativ teuer sein. Natürlich hat Meteor Lake auch seine Vorteile im Idle oder beim Media Konsum wenn nur das IO-Tile aktiv ist.


Zen6 wird aber nunmal AMDs übernächste highend Architektur und Advanced Packaging wird in immer mehr Bereiche einziehen.

Bestreitet doch keiner. Ist lediglich ein Kostenfaktor für welchen Bereich es sinnvoll ist.

Wenn es bei Zen6 nicht kommt, können wir Wetten darüber abschließen ob es bei Zen7 soweit sein wird.
Der Großteil der bisherigen CCDs besteht aus Cache und der wird deutlich teurer mit jedem Prozess.

Im Moment sieht es so aus als ob jedes Megabyte Cache mit jedem neuen Prozess 50-80% teurer wird!!!
Scaling ist kaum noch vorhanden und die Waferkosten verdoppeln sich fast mit jeder Generation.
Kann mir durchaus vorstellen, das weiterhin 3D Cache verwendet wird oder andersrum das CCD auf ein Base Die mit Cache gestacked wird.

Die CCDs auf den IOD zu stacken macht für mich bei AM5 nur Sinn, wenn der bisherige Platz der CCDs für anderes benötigt wird, z.B.: LPDDR on Package.
Oder eben, wenn die Kosten fürs Stacking so niedrig sind das es keinen Unterschied mehr macht.

Letztendlich hat AMD genügend qualifizierte Leute die nichts anderes machen als die verschiedenen Package Variante durchzurechnen und die optimale Lösung für den jeweiligen Anwendungsbereich zu finden. Optimal in der Hinsicht: mehr Leistung, weniger Verbrauch, mehr Gewinn etc.:smile:

[Nightspider]

Falls du den Faden verloren hast, es ging um Stacking der Chiplets auf dem IOD. Inwiefern wird dadurch der Cache billiger?


Wenn man CCDs immer auf den IOD stacken würde, könnte man gleich auch immer den L3 komplett aus dem CCD ziehen.
Den Cache Slice kann man dichter und deutlich günstiger in einem anderen Prozess herstellen.

Wenn man schon die CCDs auf den IO stacked wäre es ziemlich logisch den Großteil des Caches aus dem CCD zu nehmen und ihn gleich noch unter die CCDs zu packen.
Das löst auch das Problem mit der thermischen Barriere beim V-Cache.


Macht im Desktop nicht das meiste aus.


Wenn man enorm viel Platz im CCD freimachen kann, indem der Cache auf eine andere Ebene wandert, dann gewinn man enorm viel Platz und hat gegebenenfalls kürzere Wege zum Cache in der 3. Dimension.

Ich glaube nicht das du weißt, wie viel Potential da eventuell freiwerden könnte.


Hast du dir mal die Kontaktdichte bei einem CCD angesehen? Ich meine, wieviele der Kontakte davon für den IF benötigt werden.


Ist doch ein Witz im Vergleich zu den 24.000 Kontakten des V-Caches.

Und das ist gerade mal Version 1.1 beim V-Cache.
Zukünftigere Architekturen können komplett auf diese 3. Dimension und kürzere Datenwege hin optimiert werden.
Dafür müssten dann aber alle Prozessoren dieser Architektur auf die 3. Dimension und damit auf Stacking zurückgreifen können.

[Zossel]

Dafür müssten dann aber alle Prozessoren dieser Architektur auf die 3. Dimension und damit auf Stacking zurückgreifen können.

Das müsste dann auch für Server-CPUs mit vielen Cores funktionieren.
Für Desktop mit weniger Cores wäre das sicherlich eine Möglichkeit um Intel weiter auf Abstand zu halten.

[basix]

Ich bin relativ stark überzeugt, dass wir bei Zen 6 3D-Stacking sehen werden. Aber wie gesagt, nicht beim IOD mit DDR, PCIe usw.

Falls man das aber machen möchte: Hey, hätte man mit MI400/MI500 ja schon mehr oder weniger. Einzig die DDR-Channels fehlen noch. Nur: Sehr teuer das ganze und ohne HBM ein wenig Perlen vor die Säue. Für 0815 Server-CPUs ist das einfach der falsche Ansatz. Für "billige" Consumer CPUs ebenfalls.

Cache und Cores zu stacken: Das macht sehr viel Sinn. Grundvoraussetzungen:
- Es muss unter dem Strich kosteneffizienter sein als Cores & Cache monolithisch in N3E und N2
- Es muss genug energieeffizient sein
- Es muss Fertigungskapazität vorhanden sein

Ich sehe da bei allen drei Punkten relativ gute Chancen.

[amdfanuwe]

Wenn man CCDs immer auf den IOD stacken würde, könnte man gleich auch immer den L3 komplett aus dem CCD ziehen.
Den Cache Slice kann man dichter und deutlich günstiger in einem anderen Prozess herstellen.

Wenn man schon die CCDs auf den IO stacked wäre es ziemlich logisch den Großteil des Caches aus dem CCD zu nehmen und ihn gleich noch unter die CCDs zu packen.
Das löst auch das Problem mit der thermischen Barriere beim V-Cache.
Wenn man enorm viel Platz im CCD freimachen kann, indem der Cache auf eine andere Ebene wandert, dann gewinn man enorm viel Platz und hat gegebenenfalls kürzere Wege zum Cache in der 3. Dimension.
Dazu muss der Cache nicht im IOD stecken. Wie ich oben schon schrieb kann der ebensogut in einem Base Chiplet mit gestacktem CCD stecken.
Dann hat man weiterhin kleine Cache/CCD Pakete die man wie bisher an einen IOD anschließen kann. Dürfte auch vom Yield her besser sein.
Im IOD bietet es sich eher an einen IF$ zu implementieren.


Ich glaube nicht das du weißt, wie viel Potential da eventuell freiwerden könnte.

Doch, ist mir klar. Man muss aber nicht mit Kanonen auf Spatzen schießen.


Ist doch ein Witz im Vergleich zu den 24.000 Kontakten des V-Caches.

Eben. Deshalb ist ein Stacking für die Verbindung zum IOD nicht unbedingt nötig.

Ich bin relativ stark überzeugt, dass wir bei Zen 6 3D-Stacking sehen werden. Aber wie gesagt, nicht beim IOD mit DDR, PCIe usw.

Falls man das aber machen möchte: Hey, hätte man mit MI400/MI500 ja schon mehr oder weniger. Einzig die DDR-Channels fehlen noch. Nur: Sehr teuer das ganze und ohne HBM ein wenig Perlen vor die Säue. Für 0815 Server-CPUs ist das einfach der falsche Ansatz. Für "billige" Consumer CPUs ebenfalls.

Muss nicht HBM sein, reichen eventuell auch LPDDR wie bei Apple. Vielleicht schon bei Strix Halo?

Jedenfalls hat AMD seinen Baukasten an Verbindungstechniken und IP zusammen. Bin gespannt darauf, was sie daraus machen.

[robbitop]

Ungestackt wird die Latenz aber deutlich schlechter da weiter weg. Das wäre dann eher was für ein L4.
VCache funktioniert vor allem weil der Abstand so gering ist und weil die Cachelogik um CCD ist. Was mit 2,5D ginge wäre sowas wie Crystallwell.

[iamthebear]

Also ich habe an der Geschichte mit dem VCache auf dem IO Die meine Zweifel.

1.) Zen4/5 hat aktuell das Problem, dass nur ein CCD auf den VCache zugreifen kann. Das wird beim 7950X3D aktuell so gelöst, dass bei Spielen einfach nur 8 Kerne genutzt werden, was bei aktuellen Spielen noch möglich ist, bei zukünftigen aber nicht mehr so einfach sein wird. Einen Vorgeschmack darauf bekommt man ja schon mit dem 7900X3D.
Ein geshareter Cache im/auf dem IOD würde zwar das Problem lösen aber ich denke die Lösung wird ein zusätzlicher CCD Typ sein
.) 8 Kern CCD für Office PCs und Low End Gaming
.) 16 Kern CCD für Gaming und Midrange Content Creation (VCache optional obem drauf wie bisher). Für Content Creation dann 2x16.
.) 32 Kern dense CCD für Datacenter

2.) Lagert man nur den VCache in das IO Die aus würde dieser zu einem L4 Cache d.h. es kommen bei der ohnehin schon höheren Latenz noch einmal die 10ns des L3 dazu.
Kostenmäßig gewinnt man damit nichts da der VCache Die sowieso schon auf einem alten Node ist.

3) Lagert man den gesamten L3 in den IO Die aus so würde sich kostenmäßig ein Vorteil ergeben und die Latenz der 4. Cachstufe fällt weg.
Dafür wäre nun die Latenz jedes L3 Zugriffs deutlich höher und man bräuchte deutlich mehr Bandbreite.
Um das zu Kompensieren müsste der L2 dafür deutlich erhöht werden was die Flächenersparnis am CCD wieder zu Nichte macht.

Was passiert sieht man ja gut bei RDNA3: Der IF$ und das Speicherinterface sind weg vom GCD, die Shader Engines konnte man wunderbar shrinken aber der ganze Overhead die MCDs anzubinden frisst alles wieder auf und man wäre besser dran gewesen gleich alles auf einen Die zu packen.

4.) Im Datacenterbereich bringt es zumindest in klassischen Workloads wenig dem L3 über mehr als 1 CCD zu sharen, dahier meist unabhängige Workloads laufen, die mit getrennten Daten arbeiten. In vielen Fällen sind das sogar andere virtuelle Maschinen von anderen Kunden.

[Nightspider]

Eben. Deshalb ist ein Stacking für die Verbindung zum IOD nicht unbedingt nötig.


Nur wenn man den Potential der 3. Dimension nicht sinnvoll nutzt.
Die Verbindungen zwischen CCD und IO waren bisher "wenige" weil man eben nicht 30 oder 100% mehr Verbindungen unterbringen konnte.
Mit echtem 3D Stacking könnte AMD diese Verbindungen um den Faktor 10-100 erhöhen.
Eine echte vertikale Integration würde die Schaltungsdichte massiv erhöhen, die Datenwege verkürzen.
Datenlokalität ist eine der größten Bremsen morderner Architekturen.

Ohne die thermische Barriere wären auf einen Schlag ~~15% mehr Takt drin, das wäre schon ein miltterer Generationssprung.

[Der_Korken]

Beim Stacking frage ich mich, ob man irgendwann auch den L1 oder Registerarrays auf einen gestapelten Die auslagern wird. Wenn der L1, alle Register und auch sowas wie der µOp-Cache oder BTB auf dem Haupt-Die nur noch halb so viel Fläche brauchen bei gleicher Kapazität, würden sich innerhalb des Cores die Wege massiv verkürzen. Die dadurch eingesparte Energie oder gestiegene IPC durch weniger Pipeline-Stages könnte die Beschränkungen beim Verbrauch (wegen Hitze) mehr als wett machen. Gerade die Temperaturprobleme sind imho hausgemacht, weil die Kerne bis zum äußersten geprügelt werden. Die letzten 10% Takt machen gefühlt 50% des Verbrauchs auf, d.h. wenn man diese 10% durch ein kompakteres 3D-Design überkompensiert, hat man auch keine Temperaturprobleme. Das ganze ist aber eher was für Zen 7, wenn das nächste Redesign ansteht. Für Zen 6 erwarte ich eher Änderungen an der Anbindung, der CCX-Größe und als Folge davon der Speicherhierachie.

[Nightspider]

Das wird noch spannend die nächsten Jahre.

Mit Backside Power Delivery wird ja auch mehr Platz frei in Logik Areas.
Für die reine Logik könnte um den Faktor 3-4 mehr Platz verfügbar werden in den nächsten 3 Jahren und dazu kommen noch kleiner werdende Transistoren.

Oder man könnte die Chiplets, wie bereits gesagt, deutlich kleinere Chiplets fertigen. Ohne L3 Cache wären die Chiplets heute nur irgendwas um die 40-45mm² groß.
Mit 40mm² großen Chiplets könnte AMD noch schneller auf neue Prozesse springen und noch höhere Yields erreichen. Nicht unwichtig bei 20.000 Euro Wafern.

Abgeschliffene CCDs hätten dazu noch einen besseren Wärmeübergang, falls man diese dünnt, so wie die V-Cache Chiplets.

[HOT]

Also ich halte Zen6 nicht für weiter gestackt. Das wird ein 2,5D-Package werden, natürlich mit X3D. Das MCM wird aufhören, die Dies werden alle über Silizium und hoher Bandbreite miteinander verbunden sein. Die Cache-Segmentierung wird mit Zen6 kein großes Latenzproblem mehr sein. Aber echte 3D-Chips, nicht nur Cache, wird es erst 2 Generationen nach Zen6 geben mMn.
Zen1 -> Monolith
Zen2/3 -> MCM 12nm IOD
Zen4/5 -> MCM2 6nm IOD
Zen6/Post-Zen -> 2,5D+IOD 4nm
Post-Zen2 (2029/30) -> echte 3D-Chips

[basix]

Die letzten 10% Takt machen gefühlt 50% des Verbrauchs auf, d.h. wenn man diese 10% durch ein kompakteres 3D-Design überkompensiert, [...]
Ich bin da genau bei dir. Dafür benötigt man aber kein 3D-Stacking. Sieh dir Zen 4c an.

Meine Speku:
- Man nimmt die Learnings von Zen 4 & 5 als Basis für das kompakte und maschinenoptimierte Chip-Layout. Deswegen gibt es keine Unterscheidung mehr in Zen 6 und 6c
- Zen 6 ist hinsichtlich Taktbarkeit und Density ein Hybrid aus Zen 4 & 4c // 5 & 5c
- Die letzten paar Prozent Takt werden mit mehr IPC (=mehr Transistoren) kompensiert
- ST max. Performance bleibt damit gleich, aber der Core wird kleiner und energieffizienter
- Insgesamt erreicht man also einen Vorteil, speziell wenn die Lithographie-Nodes immer teurer werden

3D-Stacking kann hier als zusätzliches Mittel zum Einsatz kommen. Sehr kompakte Cores mit entsprechend viel Cache zu verheiraten wird ohne Stacking schwierig (oder das CCD würde zu zwei Dritteln aus Cache bestehen, welcher schlecht mit N3E/N2 skaliert).
Wenn man sich Zen 4c anschaut, sieht man dass Logik im Verhältnis relativ wenig Platz einnimt. Der Grossteil ist Cache. Auch wenn man den L3$ aussen vor lässt: https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fd3ae5eac-9709-443c-80d2-978f24ee65f8_1059x1751.png
Das bedeutet, dass man bei Zen 6 den Core viel fetter machen könnte (=mehr IPC), ohne dass man relativ gesehen allzuviel mehr an Fläche spendieren muss.
Schlussendlich wäre Zen 6 damit ein auf Density und Kosten optimiertes Design, ohne aber wirklich Performance-Nachteile aufzuweisen.
Und Performance-Nachteile sind nur für maximale Taktraten ein Faktor. 90+% der CPUs laufen nie bei Desktop Maximal-Boost. Server und Mobile benötigen so hohe Taktraten nicht, da ist Density und Energieeffizient wichtiger.

[iamthebear]

Ja AMD hätte die Möglichkeit die Kerne fetter zu machen. Die Frage ist nur ob sie das wollen. Im Desktop sicher eine tolle Idee, im Mobilebereich eher weniger da damit meistens auch der Energiebedarf ansteigt und im Datacenterbereich wird man eher versuchen noch mehr Kerne unter zu bringen.

Auch ist fraglich wie viel ST Performance durch zusätzlichen Transistoreinsatz generell noch zu holen ist. Irgendwo ist dann ja mal ein Limit erreicht. Manche Sprünge lassen sich einfach nicht vorhersagen und manche Anweisungen haben eben Abhängigkeiten. Auf das Problem wird auch Intel mit ihren Royal XXL Beast Kernen stoßen.

[Nightspider]

Bei Apple sind die Kerne doch auch super breit und bei der Effizienz weit voraus.

[iamthebear]

Breit ja, vertragen aber leider keinen hohen Takt wodurch die ST Performance im Endeffekt auch nicht höher ist obwohl man schon einen Node weiter ist.

[Nightspider]

Breite und Takt korrellieren aber nicht zwangsläufig.

Man kann auch eine sehr breite Architektur mit hohem Takt entwerfen.

Im Moment ist die Datenlokalität ja eines der größten Probleme. Der Cache nimmt mehr Platz weg als die Logik und die Transistoren stehen sich gegenseitig im Weg.
Die 3. Dimension kann viele Probleme umgehen. Einheiten rücken näher zusammen, die Dichte steigt.

Bin gespannt was wir für Veränderungen in den Architekturen sehen werden in den nächsten 10 Jahren durch die 3. Dimension und Machine Learning.

[Zossel]

Machine Learning.

Was soll den durch Machine Learning rumkommen?

[Nightspider]

AI wird zunehmend die Arbeit der Chipdesigner übernehmen.
Ein fettes AI Rechenzentrum kann diverse Architekturenvariationen durchspielen und verändern und immer schnellere und effizientere Designs entwickeln.

Wir sind doch bald im Zeitalter der Technologischen Singularität. :uhippie:

[Zossel]

AI wird zunehmend die Arbeit der Chipdesigner übernehmen.
Ein fettes AI Rechenzentrum kann diverse Architekturenvariationen durchspielen und verändern und immer schnellere und effizientere Designs entwickeln.

Und das ist schneller und billiger als wenn man die RTL auf FPGAs aufspielt?
Gib uns doch mal den Link wo du das gelesen hast.

[Nightspider]

RTL ist das Design, nehme ich mal an?

Wie oft wird denn ein neues Design auf ein FPGA gespielt und wie lange dauert die Analyse?

Sowas wird eine richtig gute KI in Zukunft viel schneller erledigen können. Zumal ein FPGA nicht die 3. Dimension beherrscht. Was bringt dir da ein FPGA Briefbeschwerer?

Die Devs können ja nicht 1000 verschiedene Varianten mit gestackten Chiplets zusammenlöten, wie ein Lego Baukasten. Woher sollen sie also wissen welche von "unendlich" vielen Möglichkeiten zu den (deutlich) besseren gehören?
Spätestens wenn die Logik in die 3. Dimension geht wirds extrem schwer dort noch durchzublicken, würde ich mal sagen.

[basix]

Ja AMD hätte die Möglichkeit die Kerne fetter zu machen. Die Frage ist nur ob sie das wollen. Im Desktop sicher eine tolle Idee, im Mobilebereich eher weniger da damit meistens auch der Energiebedarf ansteigt und im Datacenterbereich wird man eher versuchen noch mehr Kerne unter zu bringen.
Der Kern ist ja nur bei der Anzahl Transistoren breit. Bei der Chipfläche nicht, dort liegt man näher an den "c" Varianten, weil man dichter packt. Beispiel:
- Basis = Zen 4c
- Grösse = +10%
- IPC = +10%
- Takt vs. Zen 4 "big" = -10%

Und Apples M1-M3 zeigen es: Viele Transistoren bedeuten nicht automatisch einen hohen Stromverbrauch. Apples Chips sind besonders im Idle und Single-Thread sehr effizient. AMDs x86 Chips schliessen bei MT dann auf, weil sie den Takt reduzieren und auf SMT setzen.


Auch ist fraglich wie viel ST Performance durch zusätzlichen Transistoreinsatz generell noch zu holen ist. Irgendwo ist dann ja mal ein Limit erreicht. Manche Sprünge lassen sich einfach nicht vorhersagen und manche Anweisungen haben eben Abhängigkeiten.
Siehe Apple. Vergleichbare oder zum Teil höhere ST-Performance bei 4 GHz vs. 5.7 GHz. Da ist noch einiges an Luft nach oben. Und man muss wie gesagt auch nicht zu 100% dort hin, deswegen sagte ich Hybrid. Man geht dann evtl. auf 5 GHz runter doch kompensiert das mit mehr IPC.

Breit ja, vertragen aber leider keinen hohen Takt wodurch die ST Performance im Endeffekt auch nicht höher ist obwohl man schon einen Node weiter ist.
Dann vergleiche halt Zen 4 mit Apple M2. Vergleichbare ST Performance auf dem selben Node. Halber Stromverbrauch beim M2 bei ST (https://www.techspot.com/review/2499-apple-m2/). Genau das müsste auch AMDs und Intels Design-Ziel sein.

[basix]

Und das ist schneller und billiger als wenn man die RTL auf FPGAs aufspielt?
Gib uns doch mal den Link wo du das gelesen hast.

Bei physikalischen Design und Placement ist ML bereits quasi State-of-the-Art. Für automatisiertes Testing & Verifikation des Designs ebenfalls. Das ist noch nicht in Volldurchdringung so und allenfalls ist Zen 4c eines der ersten x86 Designs, die das im grösseren Stil nutzten (meine Vermutung, ist nicht verifiziert). Das wird allerspätestens bei Zen 6 im grossen Stil eingesetzt werden.
https://arxiv.org/pdf/2004.10746.pdf
https://www.synopsys.com/ai/what-is-ai-chip-design.html
https://www.cadence.com/en_US/home/explore/ai-chip-design.html

Beim Chip Design an sich (Architektur) ist man noch nicht so weit:
https://dds.sciengine.com/cfs/files/pdfs/view/1674-733X/58C90BE6EB964558BC9D10A02289D537-mark.pdf

Aber bereits ohne der Architektur an sich: Es werden Engineering Stunden frei, die man in die Architektur investieren kann. PPA Optimierungen sowie Design Verifikation übernimmt ML/AI.

[basix]

Gute Zusammenfassung hinsichtlich Packaging Technologien und wieso InFO-R ("Infinity Fanout Link" von RDNA3) für Zen 6 gut passen würden. Nicht alles ist 100% fachlich korrekt aber vom Sinn her und den Schlussfolgerungen passt es schon.
https://www.youtube.com/watch?v=ex_gPeWVAo0

Eine AMD Folie am Schluss des Videos hat bei mir noch einen Gedanken hervorgebracht:
- Aufgrund Chiplets hat man einen gewissen Area-Overhead aufgrund der zusätzlichen Interconnects
- Mit InFO-R wird das Packaging zwar teurer als MCM, doch die Chiplets werden kleiner.
- Bei MI300 gibt es ein schönes Diagramm, welches grün die viel kleineren PHYs fürs Stacking einzeichnet. Bei Zen 6 könnte das ähnlich sein.
- Packaging wird also teuerer, aber die Chiplets billiger (da kleiner)
- Unter dem Strich, muss das nichtmal teurer sein als MCM mit etwas grösseren Chiplets
- Es muss natürlich genügend InFO-R Packaging Kapazität vorhanden sein
- Höhere Energieffizienz (ca. 4...5x) könnte auch bei den APUs den Schritt zu Chiplets ermöglichen
- Anhand der RDNA3 Folien schätze ich ca. 5W pro TByte/s ("5% der TDP bei 3.5 TByte/s")
- Bei max. 150 GB/s mit 2-CH LPDDR5 wären das gerade mal 0.75W (maximale DDR5 Load, durchschnittlich viel weniger)

[HOT]

Soll übrigens bei Sarlak (Strix Halo) erstmals bei einer CPU eingesetzt werden. Sarlak wird offenbar auch keine große Serie werden und soll als Testlauf für die Technologie für Zen6 eingesetzt werden.
Übrigens ist das wohl so gedacht, dass hier 8 Zen5c auf Sarlak direkt zu finden sind und weitere 8 Kerne über ein CCD kommen (mit X3D?), welches eben über RDNA3-Chiplet-Technologie angebunden werden soll. Das sind Infos, die RGT neulich brachte.

[amdfanuwe]

- Bei MI300 gibt es ein schönes Diagramm, welches grün die viel kleineren PHYs fürs Stacking einzeichnet.
Die PHYs sind aber für Hybrid Bonding (stacking). Für Fan-Out Packaging fallen die noch etwas größer aus.
Leider wird Hybrid Bonding in dem Video nicht erwähnt.


Übrigens ist das wohl so gedacht, dass hier 8 Zen5c auf Sarlak direkt zu finden sind und weitere 8 Kerne über ein CCD kommen (mit X3D?), welches eben über RDNA3-Chiplet-Technologie angebunden werden soll.

Wie soll das denn aussehen? Eine dicke 8C+40CU APU wahlweise mit zusätzlichem 8C Chiplet? Dazu braucht man kein Fan-Out Packaging.

Einfachste Lösung wäre noch Fire Range + N44GPU auf einem Package, würde nur etwas groß. Soll da nicht noch LPDDR5 mit auf dem Package sein?
Bräuchte man auch kein Fan-Out Package.

Überhaupt denke ich, das Package mit 16C CPU + 40CU GPU + LPDDR5 in flächiger 2D Anordnung wird zu groß.
Vielleicht wird es doch etwas im MI300 Stil, Base Die mit I/O+IF$+L2 für GPU und darauf gestackt 2 * CCD + 40CU GCD.

Bin schon gespannt darauf, was sich AMD da wieder ausdenkt.

[robbitop]

Ich glaube nicht dass der dran auf dem Package sein wird. Es ist ja keine sockel AM5 CPU.

[amdfanuwe]

Chips and Cheese hat den Z1 ausgemessen:
https://chipsandcheese.com/2024/02/12/amds-mild-hybrid-strategy-ryzen-z1-in-asuss-rog-ally/

Zum Packaging hat Semianalysis interessante Beiträge:
Advanced Packaging Part 1 - 5
Advanced Packaging Part 1 – Pad Limited Designs, Breakdown Of Economic Semiconductor Scaling, Heterogeneous Compute, and Chiplets (https://www.semianalysis.com/p/advanced-packaging-part-1-pad-limited)

Advanced Packaging Part 2 - Review Of Options/Use From Intel, TSMC, Samsung, AMD, ASE, Sony, Micron, SKHynix, YMTC, Tesla, and Nvidia (https://www.semianalysis.com/p/advanced-packaging-part-2-review)

Advanced Packaging Part 3 – Intel’s Curious Bet on Thermocompression Bonding, ASM Pacific, Kulicke and Soffa, and Besi TCB Tool Landscape (https://www.semianalysis.com/p/advanced-packaging-part-3-intels)

The Future Of Packaging Gets Blurry – Fanouts, ABF, Organic Interposers, Embedded Bridges – Advanced Packaging Part 4 (https://www.semianalysis.com/p/the-future-of-packaging-gets-blurry)

Hybrid Bonding Process Flow - Advanced Packaging Part 5 (https://www.semianalysis.com/p/hybrid-bonding-process-flow-advanced)

Hier geht es noch etwas um die Kapazitätsbeschränkungen von CoWoS
AI Capacity Constraints - CoWoS and HBM Supply Chain (https://www.semianalysis.com/p/ai-capacity-constraints-cowos-and#§cowos-variants)

Im Semianalysis Archive findet man noch weitere interessante Beiträge:
https://www.semianalysis.com/archive?sort=new

Zum Fan-Out Packaging hab ich hier noch etwas:
https://semiengineering.com/fan-out-packaging-gets-competitive/

“We had a customer replace a 12-layer substrate with a 5-layer RDL, and at the same time the body size shrank by 20%,” said Deca’s Olson. “Fan out is currently more expensive than the substrate solutions, but if you’re able to reduce the layer count, it’s very cost-competitive.”

Unter dem Aspekt und weiterer Kostensenkung durch Massenproduktion könnte Fan-Out Packaging durchaus zum Standard für AMDs MCM Chips werden.

[amdfanuwe]

Ich glaube nicht dass der dran auf dem Package sein wird. Es ist ja keine sockel AM5 CPU.
Du meinst den RAM beim Strix Halo?
Was ich bisher gelesen habe, soll das ein Konkurrenzprodukt zu Apples M Familie werden. Weshalb haben die denn den RAM on Package?

[robbitop]

Du meinst den RAM beim Strix Halo?
Was ich bisher gelesen habe, soll das ein Konkurrenzprodukt zu Apples M Familie werden. Weshalb haben die denn den RAM on Package?

1.) kann kein Nicht Apple Chip ein Konkurrenzprodukt zu M3 werden weil Apple aktuell nur eigene CPUs in ihren Consumer products verbaut. (das ist wahrscheinlich klar zeigt aber dass „M3 Konkurrenz“ eher reißerischer Sensationsjournalismus ist und nicht was AMD offiziell so angegeben hat)
2.) Um vergleichbare Notebooks mit einem solchen SoC zu bauen ist kein ram on package notwendig. Argumente wie XYZ macht es doch aber auch sind keine Argumente.
RAM on package tut aber sicherlich eines: es spart Energie da die Leitungswege kleiner sind.

Um es klarzustellen: ich sage nicht, dass AMD kein ram on package kit Sarlak macht. Sondern nur dass es nicht zwingend notwendig wäre. Möglich ist es sicherlich denn packages kann man ja fast beliebig groß machen. M1/M2 Ultra hat ja auch 256 bit und 2x Chips auf dem package.

Hier ein Bild: https://www.notebookcheck.com/Apple-M2-Ultra-Foto-ohne-Heatspreader-zeigt-gigantischen-ARM-Chip-im-Detail.726792.0.html#news_intro_image

[Zossel]

1.) kann kein Nicht Apple Chip ein Konkurrenzprodukt zu M3 werden weil Apple aktuell nur eigene CPUs in ihren Consumer products verbaut. (das ist wahrscheinlich klar zeigt aber dass „M3 Konkurrenz“ eher reißerischer Sensationsjournalismus ist und nicht was AMD offiziell so angegeben hat)

Also ist es völlig belanglos ob die Anwendung X auf einer Obstkiste schlechter oder besser läuft als auf einem X64-Hobel?

[HOT]

Sarlak/Halo wird eh nur mit aufgelötetem LPDDR5X 8566 ausgeliefert. Alles andere ergibt keinen Sinn. Das ist ein alles-in-eins-Produkt, das möglichst stromsparend betrieben werden soll, dafür aber eben auch teuer in Herstellung ist.

[robbitop]

Also ist es völlig belanglos ob die Anwendung X auf einer Obstkiste schlechter oder besser läuft als auf einem X64-Hobel?

Ich sehe keinen Zusammenhang zu Zen6 oder Sarlak. Entsprechend eher offtopic.

Sarlak/Halo wird eh nur mit aufgelötetem LPDDR5X 8566 ausgeliefert. Alles andere ergibt keinen Sinn. Das ist ein alles-in-eins-Produkt, das möglichst stromsparend betrieben werden soll, dafür aber eben auch teuer in Herstellung ist.

Ja wobei auch dafür der RAM nicht auf dem package sein muss. Der kann auch aufs PCB verlötet werden wie es heute oft der Fall ist.

[amdfanuwe]

RAM on package tut aber sicherlich eines: es spart Energie da die Leitungswege kleiner sind.

Die nötigen PHYs dürften dadurch auch kleiner ausfallen.
Für Mobile zählt jedes Watt und da soll Strix Halo ja auch hingehen.
Wäre also auch für AMD sinnvoll LPDDR5 auf dem Package zu verbauen.

Der M3 Max hat 12P+4E + 40 GPU Kerne und 36 GB, 48 GB, 64 GB oder 128 GB RAM
Strix Halo soll 16 CPU + 40CU GPU und ein 256 Bit RAM Interface haben, welches auch 36 GB, 48 GB, 64 GB oder 128 GB ermöglicht.

Das wird nicht billig. Aber wenn Apple da einen Markt sieht, will AMD dort wohl auch mit dabei sein.

M3 Pro 6P + 6E + 18 GPU, 18 GB und 36 GB
Strix Point 4 + 8c + 16CU GPU

[amdfanuwe]

Ich sehe keinen Zusammenhang zu Zen6 oder Sarlak. Entsprechend eher offtopic.

Naja, Strix Halo könnte der Testlauf für ZEN6 Packages sein.

[davidzo]

Übrigens ist das wohl so gedacht, dass hier 8 Zen5c auf Sarlak direkt zu finden sind und weitere 8 Kerne über ein CCD kommen (mit X3D?), welches eben über RDNA3-Chiplet-Technologie angebunden werden soll. Das sind Infos, die RGT neulich brachte.

Eine merkwürdige Aufteilung imo. Die Unterschiede zu einer mobile doppel-chiplet H-CPU wie Fire Range wären dann sehr begrenzt. Wie soll das effizienter sein wenn hier wieder energetisch teure IFOP Links und getrennte LLCs zum Zuge kommen?
Gerade wenn Sarlak nur RDNA3.5 bekommt ist das ein Nachteil zu den gleichzeitig verfügbaren N44 und N48 Chips. Dann wäre der einzige Vorteil noch der unified RAM, wobei ich befürchte das Windows/UEFI den erstmal gar nicht als solchen behandeln wird.

Wieso sollte ich nicht also lieber einen Fire Range Chip mit X3D cache nehmen mit einer diskreten RDNA4 GPU, z.B. auf Navi44 Basis, die vermutlich sogar vor Sarlak verfügbar sind? So groß unterschiedlich wird die PCB Komplexität nicht sein, da sowohl CPU als auch GPU nur über ein 128bit SI verfügen vs 256bit LPDDR unified. Klar ist das mehr Chipfläche, aber die Gerätegröße wird in erster Linie vom Akku und in zweiter Linie von der Kühllösung bestimmt. PCB real estate ist erst der Dritte Einflussfaktor. 16Kerne und 20CU werden wohl kaum unter 80Watt betrieben werden, insofern sind die Geräte ohnehin nicht ganz thin and light was Akku und Kühlung betrifft.

Meine Schätzung wäre eine komplett andere Aufteilung für Zen6 und eben auch für Sarlak, falls der wirklich ein Zen6 Packaging-Testballon ist.

Früher oder später wird man versuchen das jeweils optimale Verfahren für die jeweilige IP zu benutzen und dann mit günstigeren Verfahren in Stapeln zu integrieren.

Die imo jeweils optimalen Verfahren sind:
CPU-Kerne: N4 bzw. N3E (Zen6)
GPU WGPs: N4 bzw. N3E (Zen6)
LLC Cache: N6
MCH: N6 oder gar N12
IOH: N6 oder gar N12

- Einen CPU-DIE ohne LLC hat man bisher nicht bauen können wegen der Power Density. Die power Density ist ja bei den jetzigen 80mm2 Chiplets immer wieder problematisch, wenn da jetzt statt L3 doppelt soviele Kerne wären, wäre das noch schlimmer. GPU WGPs haben allerdings eine geringere Power Density, bei guter Die Aufteilung wäre das also möglich die Wärmeverteilung besser zu managen. Zudem kann man von vornherein mit geringeren Taktraten Planen.
- Für Mobile sehe ich ohnehin sparsamere c-Kerne mit niedrigem Takt in Front. Man braucht für lightly threaded Loads nur ein Kerncluster mit high performance Kernen und damit ist der Usecase schon abgedeckt. Der Rest können C-Kerne sein. Phoenix2 hat es ja mit dem gemischten Kerncluster an einem gemeinsamen LLC schon vorgemacht.
- AMD hat ja bereits Forschung in "thermal Mitigations" von gestacktem L3 cache gesteckt und das könnte genau hier bei den Performancekernen zum Einsatz kommen.
- Die WGPs als weniger thermisch belastete Zone würde man wie jetzt den L3 Cache in die Mitte packen, während die CPU kerne so wie jetzt an den Rand gepackt werden, möglichst weit auseinander. Ausgehend von 60CUs/200mm2 bei Navi32 wären das 100-140mm2 die alleine für CUs und dazwischenliegende Cache Bonding Pads draufgehen. Da ist also reichlich Platz um an der Kante Entlang ein paar 3.84mm2 große zen5 und 2.46mm2 große Zen5C kerne zu verteilen. Der resultierende Compute-DIE wäre nicht viel größer als Phoenix oder Strix point, also ca. 200mm2, allerdings trotzdem viel teurer durch advanced packaging mit extra Cache- und IO-DIE.
- Der große Vorteil einer unified APU ist nicht nur der gemeinsame DRAM, sondern eigentlich auch ein großer gemeinsamer LLC. Wenn die WGPs eh auf demselben DIE liegen wie die CPUkerne, dann ist auch die Anbindungstopologie und Kohärenz des LLC ein nobrainer.

Vielleicht enthält der gestackte LLC dann auch den Memory Controller, ggf. als Overhang, also mit Leitungen direkt ins Package oder mit einem RDL-DIE als Zwischenlage. Vielleicht ist es aber auch wieder nur LLC wie bei den X3D CPUs.

Ob der i/o DIE jetzt gestapelt ist oder nicht ist glaube ich relativ egal, weil der Bandbreitenbedarf vergleichsweise niedrig ist.
Aber der LLC und Memory Controller sollte gestapelt sein, das spart immens Power und Fläche.


RAM on package tut aber sicherlich eines: es spart Energie da die Leitungswege kleiner sind.

Wieviel?
Phoenix und Dragon Range haben gegenüber M2 im gleichen Node ca. Faktor 2x an Effizienz aufzuholen. Das kann man nicht mal eben mit etwas on Package RAM lösen. Zumal die Vergangenheit zeigt dass breitere SIs auch immer etwas mehr statische Power ziehen, siehe AMD GPUs. Selbst bei Apple ist das erkennbar denn die Max CPUs sind bei SingleCore Lasten deutlich ineffizienter als die Pro CPUs.

Wenn AMD wirklich vergleichbare Effizienz abliefern wollte, dann müssten auch die Singlecore Taktraten runter. Möglicherweise reichen schon zwischen 3 und 3.5Ghz um die Leistungsaufnahme zu dritteln und mit Apple-Effizienz gleich zu ziehen. Das Problem ist dann aber dass bei 1/3 weniger Takt die IPC-Defizite sichtbar werden, also Apple mit ähnlichen Taktraten seine gut 30-50% höhere IPC ausspielen kann.
Ich vermute daher eher AMD weiterhin auf die singlecore Effizienz verzichten wird und eine gute, konkurrenzfähige Multicore Leistung abliefert.

Wie man aber den Idleverbrauch einer so Monster APU in Zaum halten wird wird noch spannend. Mit der bisherigen IP für das SI und i/o geht das nicht und auch stacked Cache ist da kein Heilsbringer. Der Idle- und Teillastverbrauch sind eben extrem wichtig für den mobilen Markt. Apple schafft es aktuell bei Teillast einen kompletten Arbeitstag durchzuhalten ohne ins schwitzen zu kommen. Da muss man auch hin, sonst nützt einem die Fette APU nichts und man kann eben gleich Firerange und diskrete GPUs in einem Desktopreplacement mit 180+W Power brick verwenden.

[HOT]

[...]


Ja wobei auch dafür der RAM nicht auf dem package sein muss. Der kann auch aufs PCB verlötet werden wie es heute oft der Fall ist.

Und warum sollte das so sein? Ich seh den Sinn nicht. AMD wird ein Package liefern und fertig. Das wird ja auch keine große Serie.

[robbitop]

Und warum sollte das so sein? Ich seh den Sinn nicht. AMD wird ein Package liefern und fertig. Das wird ja auch keine große Serie.
Beides ist möglich. Mehr wollte ich damit gar nicht sagen. Eine kleine Serie spricht übrigens eher dagegen - denn entsprechende Kosten kann man dann nur über eine kleinere Stückzahl abschreiben.
Auch gibt es bisher noch keinen (zumindest mir bekannten) halbwegs modernen Präzedenzfall (gut den kann es ja auch in Zukunft jeder Zeit geben) von AMD für so etwas (RAM on package).

Mal am Rande etwas feedback. Ich finde es immer wieder merkwürdig (fast schon ironisch), wie du Dinge behauptest, wie es "sein wird" und meistens falsch liegst. Ggf. formulierst du es mal anders. "IMO" / "meiner Meinung nach" etc

[woodsdog]

Wieviel?
Phoenix und Dragon Range haben gegenüber M2 im gleichen Node ca. Faktor 3x an Effizienz aufzuholen

Hast du da mal Zahlen? Das hört sich etwas arg viel an.

[basix]

Wieviel?
Phoenix und Dragon Range haben gegenüber M2 im gleichen Node ca. Faktor 3x an Effizienz aufzuholen. Das kann man nicht mal eben mit etwas on Package RAM lösen. Zumal die Vergangenheit zeigt dass breitere SIs auch immer etwas mehr statische Power ziehen, siehe AMD GPUs. Selbst bei Apple ist das erkennbar denn die Max CPUs sind bei SingleCore Lasten deutlich ineffizienter als die Pro CPUs.

MT ist man absolut auf Augenhöhe. Ist immer die Frage, was du als Designziel setzt und was die als Andendungslast für den Vergleich beiziehst.


Wenn AMD wirklich vergleichbare Effizienz abliefern wollte, dann müssten auch die Singlecore Taktraten runter. Möglicherweise reichen schon zwischen 3 und 3.5Ghz um die Leistungsaufnahme zu dritteln und mit Apple-Effizienz gleich zu ziehen. Das Problem ist dann aber dass bei 1/3 weniger Takt die IPC-Defizite sichtbar werden, also Apple mit ähnlichen Taktraten seine gut 30-50% höhere IPC ausspielen kann.
Ich vermute daher eher AMD weiterhin auf die singlecore Effizienz verzichten wird und eine gute, konkurrenzfähige Multicore Leistung abliefert.
Warten wir mal ab was Zen 5 liefert. Dann können wir diesen Vergleich hinsichtlich selben Node nochmals anstellen. Ich vermute, dass da nicht sehr viel dazwischen liegen wird. Dann hat man halt -10% Performance bei +10% Verbrauch. Das würden dei wenigsten merken. Nur dass man Zen 5 obenraus weiter ausfahren kann und mehr FP bringen wird. Bei Mobile Chips würde ich mir aber generell wünschen, dass man nochmals 10% mit dem Takt runter geht und dafür ist das Ding leiser, kühler und der Akku hält länger.

[davidzo]

Hast du da mal Zahlen? Das hört sich etwas arg viel an.
Sry hatte mich verschrieben meinte Faktor 2x - 3x ist es bei Intel. Hatte Basix hier auf der letzten Seite schon mal gepostet: https://www.forum-3dcenter.org/vbulletin/showthread.php?p=13468286#post13468286

Im ST 8Watt vs mindestens 18Watt bei der x86 Konkurrenz (Delta Idle zu ST).
Da gehört effizientes System Design aber sicher mit dazu und beim Pro und Max mit breiterem SI und GPU dürfte es etwas schlechter aussehen.

Notebookcheck misst halt das Gesamtgerät, da sind die Unterschiede geringer. Zwischen 7840U im 14" HP Elitebook 845 G10 und dem 13,6" macbook Air M2 liegen nur noch +72%.
Messwerte als Gesamtgerät sind natürlich ungünstig, da dann helle, große Displays negativ ins Gewicht fallen. Z.B. hat das 16" Macbook Pro mit M3pro nur +41% mehr Effizienz als besagtes 7840U 14" Gerät.

Im großen und ganzen kann man aber sagen dass da noch mehr als ein Node oder eine CPU µArch Generation dazwischen liegt was die ST Effizienz angeht.



MT ist man absolut auf Augenhöhe. Ist immer die Frage, was du als Designziel setzt und was die als Andendungslast für den Vergleich beiziehst.


Ich bezog mich ja aber explizit auf ST und Teillast. Das Designziel für ein Notebook mit Außnahme von Gaming und DTR ist immer: Akkulaufzeit für den ganzen Tag bei leichten bis mittleren workloads. MT ist zwar auch wichtig, aber was man bei MT Workloads einsparen kann fressen extensive Teillastphasen mehrfach wieder auf. Ich würde mich als Power-User kategorisieren und nutze mein Notebook für CAD, Rendering und auch mal Videokonvertierung. Im Schnitt würde ich trotzdem sagen Idlet es zu 80%, 15% Teillast (webbrowsing) und 2-5% MT Last. Und vermutlich haben die GPU/Codecs an allem einen größeren Anteil als die CPU.
Selbst wenn die AMD-Kerne bei MT Loads und näher am Baseclock auf eine ähnliche performance und Effizienz kommen, bedeutet dass eben auch weniger performance pro Thread, da man mehr als doppelt soviele threads hat. In Teillast wird das also irgendwo zwischen den schlechten 1T und den passablen MT Effizienzwerten liegen.
Btw, GPU und Mediencodecs sind für den Zweck natürlich ebenso relevant und da muss man bei AMD leider bisher immer noch einen diskreten Chip einplanen wenn man mehr als Entrylevel Leistung haben möchte.



Warten wir mal ab was Zen 5 liefert. Dann können wir diesen Vergleich hinsichtlich selben Node nochmals anstellen. Ich vermute, dass da nicht sehr viel dazwischen liegen wird. Dann hat man halt -10% Performance bei +10% Verbrauch. Das würden dei wenigsten merken. Nur dass man Zen 5 obenraus weiter ausfahren kann und mehr FP bringen wird. Bei Mobile Chips würde ich mir aber generell wünschen, dass man nochmals 10% mit dem Takt runter geht und dafür ist das Ding leiser, kühler und der Akku hält länger.

Fände ich auch gut, aber das hängt auch ein wenig von Intel ab ob das möglich ist. AMD konkurriert ja nicht nur mit Apple sondern in erster Linie mit Intel, also auf dem Markt für Windows Notebooks. Und da gibt Intel eben die zu erreichende ST Performance vor. AMD kann den Betriebspunkt nicht ganz frei wählen sondern muss quasi Intels Leistungsvorgabe zumindest matchen, wenn nicht leicht übertreffen, denn sonst steht man in den Reviews schlecht da.
Zen5 wird sich aber nicht mit dem M2 messen müssen sondern klar dem M3. Da interessiert der Node auch nicht mehr. Sarlak wird sehr interessant, da das nach dem ersten ernstzunehmenden M3Max Konkurrenten aussieht.

[basix]

Wenn ich wetten müsste: Strix Point wird sich mit dem M3 Max messen können. MT etwa gleich schnell und dabei sogar etwas effizienter. In ST etwas schneller aber auch etwas mehr verbrauchen.

Dass es mit weniger ST Takt geht, zeigen z.B. das HP Elitebook G845. Dort wird der Takt eines 7940HS auf glaube ich 4.5 GHz beschränkt. Dann ist man auch ST mässig nicht weit von einen M3 Max weg, was Effizienz anbelangt: https://www.notebookcheck.com/Apple-M3-Pro-M3-Max-Analyse-Apple-wertet-die-Max-CPU-deutlich-auf.772159.0.html

[Zossel]

Dass es mit weniger ST Takt geht, zeigen z.B. das HP Elitebook G845. Dort wird der Takt eines 7940HS auf glaube ich 4.5 GHz beschränkt. Dann ist man auch ST mässig nicht weit von einen M3 Max weg, was Effizienz anbelangt: https://www.notebookcheck.com/Apple-M3-Pro-M3-Max-Analyse-Apple-wertet-die-Max-CPU-deutlich-auf.772159.0.html

Er hat Jehova gesagt!

[davidzo]

Wenn ich wetten müsste: Strix Point wird sich mit dem M3 Max messen können. MT etwa gleich schnell und dabei sogar etwas effizienter. In ST etwas schneller aber auch etwas mehr verbrauchen.

Ich hoffe doch sehr du meinst Sarlak, also Strix Halo und nicht strix point.
Wenn du Vanilla Strix meinst dann :ulol3: never ever



Dass es mit weniger ST Takt geht, zeigen z.B. das HP Elitebook G845. Dort wird der Takt eines 7940HS auf glaube ich 4.5 GHz beschränkt. Dann ist man auch ST mässig nicht weit von einen M3 Max weg, was Effizienz anbelangt: https://www.notebookcheck.com/Apple-M3-Pro-M3-Max-Analyse-Apple-wertet-die-Max-CPU-deutlich-auf.772159.0.html

Das Gerät hatte ich ja auch verlinkt und erklärt wieso der Test nichts taugt um CPU Effizienz zu vergleichen. Ehrlich gesagt sind da soviele red flags in dem Artikel dass ich gar nicht weiß wo man anfangen soll.

1. Die messen den Gesamtverbrauch des Geräts und nicht den der CPU. Deshalb generell die Delta Idle Vergleiche von techspot: https://www.techspot.com/review/2499-apple-m2/
Beim m2 hat Notebookcheck auch mal nur die package Power gemessen, da kommt in ST loads teilweise Faktor 3x im Vergleich zum 5600U heraus: https://www.notebookcheck.com/Der-neue-Apple-M2-SoC-in-der-Analyse-Deutlich-schlechtere-CPU-Effizienz-als-der-M1.631030.0.html
Btw war in den M2-Messungen der M1 sogar besser, allerdings schätze ich das das eben am helleren Display liegt bzw. Notebookcheck einfach Pech beim Binning hatte.

2. Wenn man schon Gesamtgeräte vergleicht, dann sollte man auch versuchen einigermaßen vergleichbare Konfigurationen zu nehmen, also z.B. das Macbook Air 15" oder das Macbook pro 13" M2 vs das HP 845 G10.

3. Phoenix als 8-Kern APU mit entrylevel IGP konkurriert von der Kernanzahl, Leistungsmäßig und auch vom Preis-Segment eindeutig mit dem M2 und M3 Vanilla. Im ST liegt der M3 um gut 20% vorne und im Multithreading dann der 7840U um etwa den gleichen Betrag. Ich würde die CPUs also grob als gleichwertig einschätzen, was eine gute Leistung für AMD ist weil man ja einen Node-Rückstand hat. Bei der ST Effizienz liegt der M3 aber mit 89% vorne, bei der MT Effizienz nur um 9%.

4. Wenn ich mir die Daten des M3-Artikels näher anschaue zweifle ich aber auch an dem was Notebookcheck da gemessen hat, bzw. an der Datenauswahl für das Diagramm. Die Effizienz in Points per Watt ST im oberen Diagramm ohne x86-CPUs sind noch 198Pts/W, weiter unten wird ein Bestwert von nur noch 142Pts/W angezeigt. Wenn ich manuell den M3 hinzufüge sind es 190pts/W bzw, 89% vor dem 7840U.

5. Ähnliche Abweichungen bei den x86 CPUs, sogar im sonst identischen HP 845 G10. Der von dir genannte 7940HS ist eigentlich eher ein Negativbeispiel, da er trotz 10% mehr Leistungsaufnahme eine leicht schwächere singlecore performance aufweist als der 7840U im gleichen Gerät. Okay, yield und Binning vielleicht. Mittelwerte bilden?

6. Der 7840S im Lenovo Yoga Slim 7 G8, also ein 7840U der sich nur durch das Package unterscheidet, kommt aber nichtmal auf die Hälfte der Efizienz des 7840U im HP Gerät. Das ist ein Rückstand gegenüber dem M3 um Faktor 3,95x.
Das ist schon eine Normalabweichung wo man keine Mittelwerte mehr bilden sollte. Aber welcher Wert stimmt mit dem durchschnittlichen Phoenix-Gerät überein?

7. Die Pro und Max-CPUs sind einfach eine ganz andere Geräteklasse die man mit den Dragon Range + dGPU vergleichen muss. Natürlich hat der M3Max als Riesenchip eine höhere Idle-Power wie eine nur kaum ein viertel so große Spar-APU. Und natürlich zieht das Big-Chips wie den M3max in einem reinen Singlethread-Effizienzvergleich runter. Das wird bei einer Sarlak CPU mit 16 Kernen, fetter GPU und breitem SI auch so sein.

Der 7945HX kommt übrigens auf 25 points/w in CB R23 ST, also ein Viertel von dem was der 7840U im Bestcase-Szenario schafft. In einem vergleichbaren 16" Gerät. - Bei nur 10% Leistungsrückstand ST.
Im MT beträgt der leistungsvorsprung 44%, der Effizienzrückstand aber auch wieder 57% (M3max) bis 103% (M3pro).

[basix]

Ich hoffe doch sehr du meinst Sarlak, also Strix Halo und nicht strix point.
Wenn du Vanilla Strix meinst dann :ulol3: never ever

Du weisst schon, das Strix Point +50% Cores und Zen 5 bekommt? Und dass M3 Max nur in wenigen Benches wie Geekbench 5/6 >50% schneller ist als ein 7940HS (Geekbench = Bandbreite hilft)? Hier ist ausserhalb Geekbech noch CB 2024 mit +65% und Blender 3.3 mit +55% drin, das wars.
https://www.notebookcheck.com/M3-vs-R9-7940HS-vs-Apple-M3-Max-16-Core_15110_14946_15113.247552.0.html

Und selbst +65% bei CB2024 könnten bei 7940HS -> Strix Point drin liegen. Mehr Cores, mehr IPC, verbessertes FP.
ST ist man mit den gerüchteweisen +30% von Zen 4 zu Zen 5 auch beim M3 oder drüber unterwegs.

Oder anders gefragt: Wieso sollten 12 Big Cores mit HT vs. 12 Big Cores + 4 Little Cores CPU mässig so viel schlechter dastehen, wenn man heute mit Zen 4 zum Teil mit ähnlicher Energieffizienz unterwegs ist (7840U vs. M3 Derivate bei MT)?

Der M3 Max ist stark, keine Frage. Aber absolut aussergewöhnlich & unerreichbar ist es nicht. Apple wird ST Effizienz vorne bleiben, OK. Mir ging es aber um die Performance bei 25-35W.

Das Problem hinsichtlich Datenlage:
Ich sehe vor allem Cinebench und Geekbench Werte, welcher jeder DAU in seinem YT Video bencht. Nur bei Notebookcheck findet man auch noch ein paar andere Anwendungen. Es gibt schlicht nicht wirklich gute zusätzliche Quellen.

Edit:
Hier gibt es noch eine breiten Test unter Linux zwischen M2 und Rembrandt https://www.phoronix.com/review/apple-m2-linux

[iamthebear]

Diese ganzen AMD vs. Apple Vergleiche sind doch sinnlos. Eine AMD CPU wird nicht in Apple Geräten verbaut werden und Apple verkauft seine CPUs auch nur in Kombination mit eigener Hardware und OS.

Niemand wird von Windows aif macOS umsteigen oder umgekehrt nur weil doie CPU 10-20% schneller oder langsamer läuft. Man entscheidet sich für ein Betriebssystem und wird dann ein Gerät kaufen auf dem dieses läuft.

[Zossel]

Man entscheidet sich für ein Betriebssystem und wird dann ein Gerät kaufen auf dem dieses läuft.
Anwendungen.

[basix]

Es geht ja mehr um den technischen Vergleich und nicht wer welchen Plattform wählt. Apple hat unendlich Kohle, AMD ist ein Design-Spezialist. Ein spannendes Duell ;)

[davidzo]

Niemand wird von Windows aif macOS umsteigen oder umgekehrt nur weil doie CPU 10-20% schneller oder langsamer läuft. Man entscheidet sich für ein Betriebssystem und wird dann ein Gerät kaufen auf dem dieses läuft.

Sorry, da muss ich dir Widersprechen, denn ich bin genau derjenige der sich das fragt. Ich nutze beruflich ein Macbook und CAD Software (Rhino) die es sowohl für Windows als auch MacOS gibt. Privat habe ich einen PC (gaming).
Angesichts der gesalzenen preise überlege ich mir schon gerade ob mein anstehendes Upgrade ein Macbook Pro wird (5k€) oder ein x86 Gerät mit Windows.
Ich hatte mir 2014 ein Macbook mit Intelprozessor und Nvidia GPU beschafft da das die solideste Hardware war, aber zunächst Windows drauf genutzt. Irgendwann habe ich mich dann mal zu MacOS getraut und mit hat der Workflow sehr gefallen. Da meine Softwarelizenz aber auf beiden Betriebssystemen lauffähig ist, es darf nur nicht gleichzeitig laufen, kann ich diese auch auf meinem Desktop nutzen.
Da ich an an vier verschiedenen Standorten arbeite (Büro, Homeoffice Werkstatt, Elektronikwerkstatt) und nicht immer ein Netzteil zur Hand habe, verwende ich tatsächlich überwiegend das Notebook. Zum Rendern nehme ich dann manchmal den PC.

Für mich ist das Betriebssystem also irrelevant, auch wenn der bessere Workflow = Zeitersparnis natürlich ein Pluspunkt für MacOS ist. Aber sonst ist das Gesamtpaket relevant, also guter Bildschirm, Tastatur, Touchpad, solides Gehäuse, leiser Betriebsmodus, gute Akkulaufzeit, geringes Gewicht etc.

Wenn ich ein Gerät mit solider Bauweise, um die 2kg Gewicht, gutem 16" Display, idealerweise wechselbarer SSD und RAM sowie Prozessor+IGP auf M3max Niveau (schiele da auf Sarlak) und die Akkulaufzeit nicht ganz scheiße ist (6-8h unter Teillast), dann würde ich das wahrscheinlich einem M3pro/max Macbook pro vorziehen. Zumal so ein Gerät wahrscheinlich eher für 3K€ erhältlich ist und ich meine 4TB SSD dann selber einbauen kann. Die Upgrades sind ja das teure bei Apple. 2K gespart wäre schon ein starkes Argument.

Aktuell gibt es das nicht, da die Geräte häufig ein schlechtes klobiges Gehäuse + Display haben welches im Arbeitsalltag bei mir zu schnell verschleißen würde und die Geräte mit ausreichender Leistung leider alle viel zu schlechte Akkuleistung bieten, auch bedingt durch die notwendige diskrete GPU.

Du weisst schon, das Strix Point +50% Cores und Zen 5 bekommt?

Abwarten.
Es sind außerdem 4+8 bei Strix, nicht 12c. Das geht also sehr wahrscheinlich mit Taktratenregressionen bei MT einher.

Klar kann man mit der Hardwareansetzung ein paar Benchmarkwirksame Ergebnisse produzieren, aber angesichts des gleichen Nodes wie Phoenix habe ich wenig Hoffnung dass sich in der Praxis, also beim Schnitt der Geräte etwas grundsätzlich ändert. Ich sehe auch dann nicht wie es den Rückstand von fast 2x in Effizienz bei ST und Teillast aufholen sollte.

+50% mehr Cores im gleichen Node wären für mich grundsätzlich erstmal +50% TDP.
Zen5 wird außerdem ein breiterer Core mit mehr IPC und Epyc Turin zeigt ja dass die TDP auch ansteigt bei Zen5 (von 400Watt auf 600Watt). Im Server und Desktop ist das nicht so schlimm und wenn die IPC Gewinne den Verbrauchszuwachs übertreffen, dann ist die Effizienz trotzdem besser.

Singlethreaded mag man die 20% Rückstand zu den M-CPUs ja aufholen, aber das wird nicht viel ändern am fast doppelt so hohen Verbrauch dabei.

Multithreaded steht man ja ohnehin nicht schlecht da, also auf M3pro Niveau bzw. 60% hinter dem M3max. Trotzdem glaube ich wird man die +50% Cores und +20% IPC im MT nicht einfach addieren können, denn das wird sehr wahrscheinlich mit Taktregressionen daher kommen. Die V/F Kurve der C-Kerne ist (bei Z4c) auch nur unterhalb von 2,5Watt besser, darüber gar schlechter als die normalen Kerne. Unter voller MT-Last ist also mit den C-kernen nichts gewonnen and TDP Budget, bzw. gehen diese bei voller PPT sogar ineffizienter zu Werke als die Leistungs-Kerne.

[Gipsel]

Es sind außerdem 4+8 bei Strix, nicht 12c. Das geht also sehr wahrscheinlich mit Taktratenregressionen bei MT einher.4C + 8c sollten die MT-Effizienz gegenüber 8C deutlich anheben (und die absolute Leistung übrigens auch, weil 1c ~ 0,65C [bei typischerweise niedrigerem Verbrauch in dem Bereich]).

Ich sehe auch dann nicht wie es den Rückstand von fast 2x in Effizienz bei ST und Teillast aufholen sollte.Eigentlich ganz einfach: Grundverbrauch des SoC etwas drücken und einzelne Kerne nicht bis zum absoluten Maximum boosten lassen. 1W Grundverbrauch weniger und einen Kern nur noch z.B. bis 8W (statt 20+W) boosten zu lassen ergibt vermutlich mindestens doppelte ST-Effizienz (ich behaupte jetzt mal, ein Zen5 bei 8W wird grob die gleiche Leistung wie ein Zen4-Kern bei 20W haben [wenn nicht gar mehr], bei Zen4 sind das vielleicht 10% Taktregression; ja, für die letzten 10% Takt schmeißt man die Effizienz komplett aus dem Fenster, diese Wahl muß man nicht unbedingt so treffen).
+50% mehr Cores im gleichen Node wären für mich grundsätzlich erstmal +50% TDP.Nur wenn man die voll ausfährt. Z.B. haben 8 Zen4 Kerne in 35W bestimmt +70% MT-Leistung im Vergleich zu 4 Zen4-Kernen in 35W. Das nähert sich bei AMD erst in einem Nullsummenspiel bei <2W pro Kern oder so.
Singlethreaded mag man die 20% Rückstand zu den M-CPUs ja aufholen, aber das wird nicht viel ändern am fast doppelt so hohen Verbrauch dabei.Das läßt sich wie oben angegeben prinzipiell fixen. Das hängt nicht unbedingt an den Kernen selber.
Die V/F Kurve der C-Kerne ist (bei Z4c) auch nur unterhalb von 2,5Watt besser, darüber gar schlechter als die normalen Kerne. Unter voller MT-Last ist also mit den C-kernen nichts gewonnen and TDP Budget, bzw. gehen diese bei voller PPT sogar ineffizienter zu Werke als die Leistungs-Kerne.Wenn Du insgesamt mehr davon hast (wie beim Schritt zu Strix Point) hilft das sehr wohl, insbesondere da die Vorteile im Bereich eines harten Verbrauchslimits ja größer werden.
Die V/F-Kurve sagt übrigens längst nicht Alles. Ein Zen4c Kern benötigt vielleicht etwas höhere Spannung als ein Zen4 bei gleichem Takt (von sagen wir mal <=3GHz), verbraucht da aber trotzdem weniger.

[davidzo]

4C + 8c sollten die MT-Effizienz gegenüber 8C deutlich anheben (und die absolute Leistung übrigens auch, weil 1c ~ 0,65C [bei typischerweise niedrigerem Verbrauch in dem Bereich]).

Eigentlich ganz einfach: Grundverbrauch des SoC etwas drücken und einzelne Kerne nicht bis zum absoluten Maximum boosten lassen. 1W Grundverbrauch weniger und einen Kern nur noch z.B. bis 8W (statt 20+W) boosten zu lassen ergibt vermutlich mindestens doppelte ST-Effizienz (ich behaupte jetzt mal, ein Zen5 bei 8W wird grob die gleiche Leistung wie ein Zen4-Kern bei 20W haben [wenn nicht gar mehr], bei Zen4 sind das vielleicht 10% Taktregression; ja, für die letzten 10% Takt schmeißt man die Effizienz komplett aus dem Fenster, diese Wahl muß man nicht unbedingt so treffen).

Wie kommst du darauf dass der Grundverbrauch sinkt und zen5 bei 8Watt soviel leisten wird wie Zen4 bei 20W?
In der Vergangenheit kam nichtmal Renoir gegenüber Picasso auf solche Werte und der hatte den wahrscheinlich größten Nodesprung in der Geschichte von AMD. Bei Cezanne und Phoenix ist der Grundverbrauch gegenüber Renoir wieder angestiegen, auch wegen PCIe Gen4 und DDR5 MC. PCIe Gen5 bei Strix aber im gleichen Node wird sehr wahrscheinlich auch nicht kostenlos.

Wenn Du insgesamt mehr davon hast (wie beim Schritt zu Strix Point) hilft das sehr wohl, insbesondere da die Vorteile im Bereich eines harten Verbrauchslimits ja größer werden.

Ja schon, aber das schmälert sich halt wenn du C-Kerne hast die du aber oberhalb des sweetspot betreibst. Der Sweetspot liegt zumindest bei Zen4C bei 2,5Watt. Bis 30Watt skaliert das also vermutlich noch gut, aber die H-CPUs werden den kernzuwachs weniger gut verkraften können denn die C-kerne brauchen oberhalb des Sweetspots mehr Energie für die gleiche Leistung wie normale Kerne.


Die V/F-Kurve sagt übrigens längst nicht Alles. Ein Zen4c Kern benötigt vielleicht etwas höhere Spannung als ein Zen4 bei gleichem Takt (von sagen wir mal <=3GHz), verbraucht da aber trotzdem weniger.
Ich bezog mich auf das AMD Diagramm zu Phoenix2 mit Verbrauch in W / Leistung. Du hast aber recht, V/F war die falsche Bezeichung dafür, das meinte ich gar nicht.

[latiose88]

was ist denn bitte schön die V/F ausgeschrieben? Und hat das was mit Spannung und so auch zu tuen?

[mczak]

Wie kommst du darauf dass der Grundverbrauch sinkt und zen5 bei 8Watt soviel leisten wird wie Zen4 bei 20W?

Das dürfte locker übertroffen werden. Ein Zen4 Kern bei 20W ist nun mal extrem ineffizient, selbst ein Zen4 Kern bei 10W hat wohl schon 90% der Performance davon... (edit: ok das ist vielleicht etwas zu hoch geschätzt, könnten auch bloss 85% sein.)
Gibt's eigentlich irgendwo schöne Diagramme mit Stromverbrauch und Taktfrequenz pro Kern für Zen 4? Ich rede von sowas wie dem hier: https://www.anandtech.com/show/16214/amd-zen-3-ryzen-deep-dive-review-5950x-5900x-5800x-and-5700x-tested/8
Leider gibt's das beim Zen4 Review nicht mehr (Zen3 - 5.05Ghz bei 20W, 4.45Ghz bei 10W).

[Gipsel]

Wie kommst du darauf dass der Grundverbrauch sinktDer Grundverbrauch (also im idle) hängt nicht von der Kern-Architektur (sondern vom SoC-Design) ab und kann somit von AMD prinzipiell auf Apple-Niveau verbessert werden.
Vielleicht is das oben nicht klar geworden, aber ich sage nicht, daß es unbedingt so kommt, ich argumentiere dagegen, daß es kein Möglichkeit gibt, daß mit verfügbaren Mitteln zu erreichen.
und zen5 bei 8Watt soviel leisten wird wie Zen4 bei 20W?Bei Zen4 schluckt ein einzelner Kern bei maximalem Boost etwas über 20W. Das ist völlig ineffizient, weil bei halbem Verbrauch des Kerns (nicht Package) nur einstellige Prozentwerte an Takt verloren gehen. Jetzt nehme man sagen wir mal 20% höhere IPC von Zen5 und booste den nicht so hoch. Voila!
In der Vergangenheit kam nichtmal Renoir gegenüber Picasso auf solche Werte und der hatte den wahrscheinlich größten Nodesprung in der Geschichte von AMD. Bei Cezanne und Phoenix ist der Grundverbrauch gegenüber Renoir wieder angestiegen, auch wegen PCIe Gen4 und DDR5 MC. PCIe Gen5 bei Strix aber im gleichen Node wird sehr wahrscheinlich auch nicht kostenlos.Dann weißt Du ja, woran AMD arbeiten muß, um in M3-Regionen vorzustoßen ;). Und der Auslegunsgpunkt ist nicht gottgegeben.
PCIe hat übrigens auch Stromsparmodi (runtertakten und dynamische Verringerung der genutzten Lanes werden unterstützt, wenn ich mich richtig erinnere).
Und was Renoir gegenüber Picasso angeht, offiziell gab es 19% IPC gain und bei 3700U=>4700U haben wir 2,3GHz => 2,0GHz Baseclock bei gleichen 15W TDP aber doppelter Kernzahl. Die Effizienz hat sich also mehr als verdoppelt (bei halbiertem Powerbudget pro Kern, was abzüglich Grundverbrauch eher nur noch 45% des Verbrauchs pro Kern sein dürfte) und schneller wurde es auch noch. Und das war im absolut effizienten Bereich (knapp über 2GHz) nicht im Bereich des Peaks des single core Boosts (sagen wir mal 5GHz bei Zen4/5), wo man auch ohne Prozeßänderung deutliche Einsparungen beim Verbrauch mit nur minimalem Leistungseinbußen realisieren kann. Wieviel Leistung verliert ein auf 180-200W geprügelter 7700X (21W pro Kern + IO-Die) wenn man ihn auf 100W limitiert? Fünf Prozent, 10 Prozent? Die letzten 5 % Takt heizen doch quasi nur noch. In dem Bereich wird es völlig ineffizient. Was passiert also, wenn man einfach nur noch bis 8W (ich glaube, das ist grob die Zahl für Apple) für einen Kern boostet? Die Effizienz erhöht sich beträchtlich. Packe noch ein paar Designverbesserungen dazu und man verliert vielleicht noch nicht einmal Leistung (oder gewinnt gar!).
Ja schon, aber das schmälert sich halt wenn du C-Kerne hast die du aber oberhalb des sweetspot betreibst.Dann macht man das eben nicht.
Der Sweetspot liegt zumindest bei Zen4C bei 2,5Watt.Und da laufen die mit >3GHz Takt in üblichen Anwendungen.
Bis 30Watt skaliert das also vermutlich noch gut, aber die H-CPUs werden den kernzuwachs weniger gut verkraften können denn die C-kerne brauchen oberhalb des Sweetspots mehr Energie für die gleiche Leistung wie normale Kerne.Wie gesagt, dann läßt man die c-Kerne eben unter 3,2GHz oder 3,5GHz und fertig ist der Lack (Zen4c boostet im 8500G konstant auf 3,7GHz und da schießt der Verbrauch auch nicht gerade durch die Decke). 4xZen5 bei sagen wir mal 4,2GHz + 8x Zen5c-Kernen bei 3,2GHz verbrauchen sicher deutlich weniger als die Alternative von 8x Zen5 bei 5,3GHz (gleiche theoretische MT-Leistung).

Und H-CPUs können mehr Kerne besser verkraften als U-CPUs. Durch den höheren Verbrauch ist die Steigerung der Effizienz dort nämlich sogar größer. H-CPUs mit weniger Kernen betreiben diese nämlich in einem ineffizienteren Bereich als U-CPUs mit gleicher Kernanzahl. Die Steigerung der Kernanzahl rückt die H-CPUs dann dichter an die U-CPUs in Sachen Effizienz.
Ich bezog mich auf das AMD Diagramm zu Phoenix2 mit Verbrauch in W / Leistung. Du hast aber recht, V/F war die falsche Bezeichung dafür, das meinte ich gar nicht.Ja, je nachdem wie die Firmware das Boostverhalten steuert, scheint dort der Crossover bei knapp 20W Package-Power zu liegen, was also oberhalb von ~2,5W pro Kern (wenn man z.B. 3-4W für IO usw. abzieht) Zen4 effizienter als Zen4c machen würde. Aber das spricht gegen ganz genau gar nichts.
Bauen wir theoretisch einen StrixPoint mit 4x Zen4 +8x Zen4c: 12x2,5W = 30W. Ist doch jetzt nicht so schlecht und vermutlich besser als 8xZen4 bei 30W in Sachen multithread (8xZen4 müßte mit >4,8GHz all-core laufen, um die MT-Leistung zu erreichen, das ist in 30W schwer drin).

PS:
Wenn man mal nachdenkt, wo man bei Phoenix2 den Auslegungspunkte von Zen4 vs. Zen4c hinlegen will, um die Leistung zu optimieren, dann ergibt sich bei gegebenem PPT-Limit man das so einstellen will, daß die Ableitung von Takt über Verlustleistung identisch ist (nicht die Verlustleistung selber). Da Zen4c besser zu niedrigeren Leistungen skaliert, verbraucht ein Zen4c-Kern in diesem Optimum also weniger als ein Zen4-Kern. Der eigentliche Gleichstand in der Effizienz liegt also bei minimal höherem Zen4c-Takt (und niedrigerem Zen4-Takt) als wir in den kaufbaren CPUs sehen.
Z.B. 8640U bei 15W, also ~2W pro Kern + IO: 4x Zen4c@3GHz + 2x Zen4@3,7GHz Baseclock => Gleichstand der Effizienz bei x mit 3GHz < x < 3,7GHz.
Bei einem 8500G-Test lag bei Cinebench die Packagepower bei 42W im Mittel (die haben einen idle-Verbrauch von >6W gemessen, macht also ~6W pro Kern im Mittel) und Zen4c lag bei 3,7GHz (dem Maximum, das Optimum wäre eventuell woanders, da das Boostverhalten noch fraglich ist, wie mczak schon anmerkte) mit Zen4 bei 4,6GHz.
Takt um 24% (Zen4) bzw. 23% (Zen4c) höher als Baseclock des 8640U, aber auch voller 2,8facher Verbrauch (und in Cinebench sollte der 8640U vermutlich leicht oberhalb Baseclock takten). "Optimalerweise" (wir sind ja schon recht deutlich über dem Sweetspot) sollten die Zen4-Kerne noch etwas höher takten um obige Bedingung zu erfüllen (auch im Vergleich zum 8600G, wo die mit ~4,8GHz laufen [+4%], da dann aber offenbar schon an die 12W pro Kern ziehen [>80W Package Power]).
Kurz: Die Effizienz ist extrem davon abhängig, in welchem Bereich man die Kerne betreibt. Eigentlich eine Binsenweisheit.

[HOT]

https://youtu.be/cv3k_LP1cr4

Tom labert wieder Mist, wie immer.

Es gibt aber einige neue Infos aus dem Video:

1.) Er spinnt sein Märchen weiter, dass Zen5 architektionische Probleme hatte. Diese These ist aber nicht haltbar, da Zen5 a.) absolut im Zeitplan liegt und b.) als B0 erscheint, was ein ganz normaler Erscheinungszyklus bei Produkten ohne Probleme ist.
Er folgert das daraus, dass AMD für Zen6 große Teile neu designt hat (was er geleakt hat in dem Video), wesegen Zen6 erheblich später ist als gedacht - das konkrete Siliziumdesign beginnt Q3 24 (das leakt er), weswegen das Produkt für frühestens 2H 26 zu erwarten ist (meine Interpretation, Tom labert nur um den heißen Brei).
Das muss aber nicht richtig sein und ist angesichts des ersten Teils von 1.) unwahrscheinlich. Ich würde daraus interpretieren, dass das Zen5-Design designtechnisch ne Sackgasse ist und deshalb das anders geplant war. Früher gab es mMn solte Planungen:

a.) Zen5 -> Zen6 als Zen5-Refresh -> Zen7 wieder komplett neue µArch

neuer Plan:

a.) Zen5 -> Zen6 starkes Redesign von Zen5 -> Zen7 weitere Zen6-Evolution

Das sagt nur alles gar nichts über die Leistungsfähigkeit der Iterationen, inbesondere Zen5, aus. Überigens heißt das auch, dass seine geleakte interne Designroadmap (welche er im Video mal wieder bringt) bei Zen5 endet, weil die Zen6-Infos auf der Roadmap durch die Änderung von AMDs Plänen obsolet geworden ist, mal sehen, ob er das in den nächsten Vdeos bedenkt, oder weiter sich auf der Basis dann Fehlinformationen zusammenspinnt ;).

2.) Es gibt 2 Dense-Stufen für Zen 4 und 5, normal und dense. Ab Zen6 gibt es nicht nur 3 CCD-Stufen, sondern auch 3 Dense-Stufen, normal, dense, client-dense (ab Zen7 soll es dann 4 geben). Er interpretiert, dass "client-dense" noch dichter gepackt wäre, das ist sicherlich auch wieder Blödsinn. "client-dense" wird stattdessen sicherlich mehr Transistoren haben als "dense", aber deutlich auf Verbrauch getrimmt sein, sodass er sehr viel effizienter arbeiten kann als normal und dense und man also für mobil einen eigenen Effizienzkern hat.

3.) Labert er wegen der Fertigungsprozesse herum, aber es ist ziemlich klar, dass Zen6 sowohl N3P/X als auch N2 nutzen dürfte. Da gibts eigentlich keinen Spielraum.

[Zossel]

https://youtu.be/cv3k_LP1cr4

Boah, dieser Pornobalken ist brutal, der Klobrillenbart stand ihm bedeutend besser.

[amdfanuwe]

Je früher man leaked, umso besser kann man sich später rausreden das die Planung geändert wurde?
Ich warte erst mal ab, was ZEN 5 bringt.

[rentex]

Boah, dieser Pornobalken ist brutal, der Klobrillenbart stand ihm bedeutend besser.

Sieht gelinde gesagt...dämlich aus. Kein Bartträger Typ.

[iamthebear]

Für mich hört sich das so an als reimt er sich da seine eigene Story zusammen um sich nicht einzugestehen, dass einige seiner bisherigen Märchen nicht eintreffen:

a) Zen5 hatte keine größeren Probleme. Doe 40% waren wieder einmal hoffnungslos overhyped.

b) Wir haben einen normalen 2 Jahres Releasezyklus. Da ist nichts verspätet.

c) Die Information, dass Zen6 wenig an der Architektur der Kerne ändert war anscheinend falsch, vermutlich weil er oder seine Quellen nur Teilinformationen hatten.
Für mich sieht von Zen1 bis Zen7 nach einer durchgehenden Weiterentwicklung jede Generation aus. Gewisse Teile sind neu, gewisse Teile bleiben so wie sie sind.

d) Zen4c Kerne sind nicht effizienter. Diese können lediglich in etwas tieferen Taktregionen betrieben werden aber da reden wir vom Sub 2GHz Bereich als nichts was einen Desktopuser interessieren würde.
Zusammenfassend kann man sagen:
.) 0.75x Takt bei gleicher Spannung bei 0.65x Die Size.
.) Bei gleichem Takt deutlich höherer Verbrauch, da mehr Spannung benötigt wird

Meine Vermutung:
Zen6 Dense classic ist 2nm
Zen6 Client Dense ist 3nm

2nm hat fast keine Density Verbesserungen mehr, bietet jedoch niedrigeren Verbrauch, wird jedoch sauteuer sein also kaum eine Option for Low End Clientchips, die nur aus Kostengründen auf die Dense Variante setzen.

[Gipsel]

d) Zen4c Kerne sind nicht effizienter. Diese können lediglich in etwas tieferen Taktregionen betrieben werden aber da reden wir vom Sub 2GHz Bereich als nichts was einen Desktopuser interessieren würde.
Zusammenfassend kann man sagen:
.) 0.75x Takt bei gleicher Spannung bei 0.65x Die Size.
.) Bei gleichem Takt deutlich höherer Verbrauch, da mehr Spannung benötigt wirdNein. Oder nur irgendwo über 3GHz. Zen4c hat deutlich verringerte Kapazität der schaltenden Transistoren und auch geringere Leakage (laut AMD halbiert). Bei moderaten Taktraten verbraucht ein Zen4c Core also trotz höherer Spannung weniger als ein Zen4-Kern bei gleichem Takt mit etwas niedrigerer Spannung. Erst ab 3 GHz vergrößert sich das Verhältnis der nötigen Spannungen so weit (außerdem überwiegt dann der aktive Verbrauch immer stärker gegenüber dem passiven Verbrauch durch Leakage), daß dann Zen4 aus Verbrauchssicht günstiger als Zen4c wird. Zen4c kann bei gleichem Takt locker bis zu 20% höhere Spannung fahren und trotzdem weniger verbrauchen als Zen4.

[Skysnake]

Ist denn schon etwas über die TDP der Maximalausbauen bekannt?

[reaperrr]

Ist denn schon etwas über die TDP der Maximalausbauen bekannt?
Bleibt nach bisheriger Gerüchtelage gleich (außer Server, wo es bis zu 500W hochgeht).

Hab nicht gemerkt/vergessen, dass wir hier im Zen6-Thread sind. Für Zen6 wird sicher noch nichts dergleichen feststehen.

[DozerDave]

https://youtu.be/cv3k_LP1cr4

Tom labert wieder Mist, wie immer.

Es gibt aber einige neue Infos aus dem Video:

1.) Er spinnt sein Märchen weiter, dass Zen5 architektionische Probleme hatte. Diese These ist aber nicht haltbar, da Zen5 a.) absolut im Zeitplan liegt und b.) als B0 erscheint, was ein ganz normaler Erscheinungszyklus bei Produkten ohne Probleme ist.
Er folgert das daraus, dass AMD für Zen6 große Teile neu designt hat (was er geleakt hat in dem Video), wesegen Zen6 erheblich später ist als gedacht - das konkrete Siliziumdesign beginnt Q3 24 (das leakt er), weswegen das Produkt für frühestens 2H 26 zu erwarten ist (meine Interpretation, Tom labert nur um den heißen Brei).
Das muss aber nicht richtig sein und ist angesichts des ersten Teils von 1.) unwahrscheinlich. Ich würde daraus interpretieren, dass das Zen5-Design designtechnisch ne Sackgasse ist und deshalb das anders geplant war. Früher gab es mMn solte Planungen:

a.) Zen5 -> Zen6 als Zen5-Refresh -> Zen7 wieder komplett neue µArch

neuer Plan:

a.) Zen5 -> Zen6 starkes Redesign von Zen5 -> Zen7 weitere Zen6-Evolution

Das sagt nur alles gar nichts über die Leistungsfähigkeit der Iterationen, inbesondere Zen5, aus. Überigens heißt das auch, dass seine geleakte interne Designroadmap (welche er im Video mal wieder bringt) bei Zen5 endet, weil die Zen6-Infos auf der Roadmap durch die Änderung von AMDs Plänen obsolet geworden ist, mal sehen, ob er das in den nächsten Vdeos bedenkt, oder weiter sich auf der Basis dann Fehlinformationen zusammenspinnt ;).

2.) Es gibt 2 Dense-Stufen für Zen 4 und 5, normal und dense. Ab Zen6 gibt es nicht nur 3 CCD-Stufen, sondern auch 3 Dense-Stufen, normal, dense, client-dense (ab Zen7 soll es dann 4 geben). Er interpretiert, dass "client-dense" noch dichter gepackt wäre, das ist sicherlich auch wieder Blödsinn. "client-dense" wird stattdessen sicherlich mehr Transistoren haben als "dense", aber deutlich auf Verbrauch getrimmt sein, sodass er sehr viel effizienter arbeiten kann als normal und dense und man also für mobil einen eigenen Effizienzkern hat.

3.) Labert er wegen der Fertigungsprozesse herum, aber es ist ziemlich klar, dass Zen6 sowohl N3P/X als auch N2 nutzen dürfte. Da gibts eigentlich keinen Spielraum.

Zumal das mit den zwei Design- und einem Implementationsteam schonmal Mark Papermaster vor Jahren in einem Interview erzählt hatte.

[iamthebear]

Nein. Oder nur irgendwo über 3GHz. Zen4c hat deutlich verringerte Kapazität der schaltenden Transistoren und auch geringere Leakage (laut AMD halbiert). Bei moderaten Taktraten verbraucht ein Zen4c Core also trotz höherer Spannung weniger als ein Zen4-Kern bei gleichem Takt mit etwas niedrigerer Spannung. Erst ab 3 GHz vergrößert sich das Verhältnis der nötigen Spannungen so weit (außerdem überwiegt dann der aktive Verbrauch immer stärker gegenüber dem passiven Verbrauch durch Leakage), daß dann Zen4 aus Verbrauchssicht günstiger als Zen4c wird. Zen4c kann bei gleichem Takt locker bis zu 20% höhere Spannung fahren und trotzdem weniger verbrauchen als Zen4.

Hast du da zufällig ein unabhängiges Review bei der Hand oder sind das nur die Behauptungen von AMD?

David Huang hatte dazu mal ein Review gemacht und da schnitten die Zen4c Kerne echt nicht gut ab:
https://i.imgur.com/nQZuAPc.jpeg
https://i.imgur.com/7hRNope.jpeg

[Skysnake]

Bleibt nach bisheriger Gerüchtelage gleich (außer Server, wo es bis zu 500W hochgeht).

Hab nicht gemerkt/vergessen, dass wir hier im Zen6-Thread sind. Für Zen6 wird sicher noch nichts dergleichen feststehen.
Ok danke.

Bin mal gespannt, was da so kommen mag.

[basix]

Mit Zen 4 hat AMD bei Desktop auf 230W erhöht. Denke nicht, das Zen 5 & 6 noch weiter hoch gehen. Ist einfach sinnfrei, für eine Consumer Platform. Und 230W sind mMn bereits zu viel für eine Consumer CPU als Default-Einstellung.

Hast du da zufällig ein unabhängiges Review bei der Hand oder sind das nur die Behauptungen von AMD?

David Huang hatte dazu mal ein Review gemacht und da schnitten die Zen4c Kerne echt nicht gut ab:
https://i.imgur.com/nQZuAPc.jpeg
https://i.imgur.com/7hRNope.jpeg

Beim Phoronix-Test ist Zen 4c auch nicht energieffizienter (2x Zen 4 vs. 1x Zen 4 / 1x Zen 4c anschauen).
https://www.phoronix.com/review/amd-zen4-zen4c-scaling

Aber 1T ist nicht der Anwendungsfall für Zen 4c, sondern nT. Man müsste also den 7540U vs. 7640U antreten lassen.
Zen 4c holt bessere Energieeffizienz anscheinend zu guten Teilen davon, dass man schlichtweg mehr Cores verbauen kann (ergo geringere Taktraten fährt).

[Skysnake]

Consumer interessiert mich jetzt persönlich überhaupt nicht mehr.

[latiose88]

Warum das weil da nicht wirklich mehr noch mehr heraus geholt wird oder wie?
Mein Weiß ja noch nicht was sich bei Zen 6 so alles verändern wird. Erst mal abwarten was bei Zen 5 dabei rum kommt. Man erwartet jedoch so um die 10 % bei Zen 6.Ob das stimmt kann man nicht wissen und ob sich dann der Aufpreis von 300 € dann lohnen wird, das bleibt dann jedem selbst überlassen. Wobei zum Schluss wird Zen 6 der 16 Kerner doch keine 900 € kosten sondern mehr. Dann wären ohnehin die meisten raus kann man so sagen weil viel Spielraum zu einem 24 Kerner hat man ja eh nicht mehr am Ende. Also alleine vom Preis her gesehen.

[basix]

Meine Vermutung:
[Zen6 Standard ist 3nm]
Zen6 Dense classic ist 2nm
Zen6 Client Dense ist 3nm

Noch eine weitere Vermutung:
Client Dense strippt die Vektor-Einheiten zusammen und vielleicht auch den L2$. Also anstatt Single-Cycle AVX512 gibt es nur noch Dual-Cycle AVX512, also halbierte Breite der Floating-Point Unit. Dito beim L2$. Für viele Use Cases ist das immer noch genug Bumms. Und zudem ideal geeignet für Mobile. Sieht man sich Zen 4c an, nimmt die FPU und der L2$ sehr viel Platz ein. Wenn Zen 5 die FPU nochmals ordentlich aufbohrt oder Zen 6 den L2$ vergrössert, wird das proportional wohl noch mehr sein (siehe unten verlinktes Bild vom Zen 4c Core)

Das wäre ungefähr sowas:
- Zen 6 Standard, 3nm, Single-Cycle AVX512, 1MB L2$/Core, 4MB L3$/Core
- Zen 6 Dense Classic, 2nm, Single-Cycle AVX512, 1MB L2$/Core, 2MB L3$/Core
- Zen 6 Dense Client, 3nm, Dual-Cycle AVX512, 512kB L2$/Core, 2MB L3$/Core

Und ich hoffe immer noch auf 3D-Stacking (am besten Wafer-on-Wafer):
- 64 MByte Base-Die (L3$ + IO integriert)
- Zen 6 Standard (16C) & Dense Classic (32C) passen auf das selbe Base Die
- Monolithisch für Zen 6 Dense Client falls nur 16C. Ebenfalls stacked falls 32C. Oder gar nicht als Chiplet, sondern jeweils integriert als "APU" Version von Zen 6 (Zen 6 Standard & Dense Client sind beide 3nm, da kann man ein z.B. 4+12 Design rausbringen, analog zu 4+8 bei Strix Point)

https://substackcdn.com/image/fetch/w_1456,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Ff7e48eab-af56-435b-9680-1ecfd901835b_1200x1502.png

[HOT]

Glaub ich alles nicht. Man wird weder die Laufzeiten ändern noch wird man die Kerne abhägig vom Prozess behandeln.

Zen6cc dürfte einzig auf niedrige Spannung designt sein, Zen6c dürfte so klein wie möglich sein, das ist alles.

Ab Zen7 will man offenbar eigene Kerne für Server basteln, ab da dürften die Client-Produkte dann tatsächlich anders performen als die Server-Produkte.

[basix]

Kann schon sein, dass man nichts and der Core Konfiguration ändert. Dann wäre Zen 6 Dense Client aber kein Chiplet Produkt sondern eher was für monolithische APUs only oder einem kleinen 2-4C Cluster auf dem IOD (ähnlich wie es Intel bei Meteor Lake auf dem SOC Die macht).

[latiose88]

single cycle avx 512 ist dann nur wie immer 2x256 bit und dual cycle ist Dann 2x512 bit oder irre ich mich da?

[HOT]

Kann schon sein, dass man nichts and der Core Konfiguration ändert. Dann wäre Zen 6 Dense Client aber kein Chiplet Produkt sondern eher was für monolithische APUs only oder einem kleinen 2-4C Cluster auf dem IOD (ähnlich wie es Intel bei Meteor Lake auf dem SOC Die macht).
Das wäre dann ein Kern für Client-APUs, vor allem mobil. Auch das IOD wird ja nicht so aussehen wie jetzt. Ich könnt mir eher vorstellen, dass es ein Leistungs-CCD und ein mobil-CCD gibt, die per COWOS verbunden werden mit entsprechenden IODs. Darauf Kerne zu platzieren halte ich für blödsinnig, dafür gibts doch die CCDs.

[Gipsel]

Hast du da zufällig ein unabhängiges Review bei der Hand oder sind das nur die Behauptungen von AMD?
David Huang hatte dazu mal ein Review gemacht und da schnitten die Zen4c Kerne echt nicht gut ab:
https://i.imgur.com/nQZuAPc.jpeg
https://i.imgur.com/7hRNope.jpegWaren das nicht unterschiedliche CPUs mit unterschiedlichen Speichersettings (LP5X-7400 vs. LP5-6400) in unterschiedlichen Systemen (Handheld vs. Notebook)? Bei 15W und drunter spielt es schon eine Rolle, ob etwa 2W extra für den LP5X bei Phoenix2 verbraten werden. David Huang hat nicht umsonst diese Fußnote da drunter gesetzt:
It should be noted that since the two SoCs tested in this article use different memory types, uncore frequencies, motherboard designs and PhoenixPI versions, the low-power tuning is also different, and the data of different SoCs are not suitable for direct comparison.
Aber schau Dir mal die Spannungskurve an. Bei 3GHz erreichen wir genau den Punkt, wo Zen4c die von mir bereits erwähnten 20% mehr Spannung benötigt als Zen4 (0,77V * 1,2 = 0,92V). Und nach den von AMD veröffentlichten zahlen für die effektive dynamische Kapazität der Transistoren in Zen4 ist dann auch ziemlich genau da der Crossover für die Kerne im Verbrauch (je nach Art der Last kann sich das noch etwas verschieben, ober so im Mittel dürfte das ganz gut hinkommen).
Beim Phoronix-Test ist Zen 4c auch nicht energieffizienter (2x Zen 4 vs. 1x Zen 4 / 1x Zen 4c anschauen).
https://www.phoronix.com/review/amd-zen4-zen4c-scalingNa, bei 65W TDP, wo die Dinger sowieso maximal 40-50W ziehen, der Crossover zwischen Zen4 und Zen4c bei dem Modell aber irgendwo unter 20W Package-Power liegt. Das ist also genau so zu erwarten. Wenn man sich die Zahlen mal ansieht, dann erkennt man, daß ein Zen4c-Kern da ungefähr 2 bis 3W Verbrauch addiert. Und die boosten dort bis 3,7GHz (die sind nie im TDP-Limit, was ja bei 65W, PPT 88W liegt, die schöpfen nur die Hälfte aus). Bei 3GHz liegen die also wohl um/unter 2W pro Kern (außer irgendwelchen AVX512-Loads oder einem "Power-Virus" Code vielleicht).
Zen4c lohnt sich in ultramobilen Notebooks/Handhelds (TDP <20W, Takt im Mittel unter 3,2GHz oder so) oder eben in Server-CPUs mit massiven Kernanzahlen (<=2W pro CPU-Kern). Ich z.B. hätte gerne ein ultramobiles Convertible, am besten passiv gekühlt, TDP <10W für extralange Akkulaufzeit und geringes Gewicht. Da bietet sich Zen4c an und ist dort auch energieeffizienter als Zen4.
Das wird sich vermutlich so ähnlich auch auf Zen5c und Zen6c übertragen (um mal wieder auf das Thema des Threads zu kommen).

[Altehardware]

ich weis ja nicht wieso man so gehyped vom zen6 ist
Das ist nur ein node sprung von n5 auf n3 was maximal 15% Takt bringt
Da zen5 nur arch Änderungen hat und grob +15% perf bringt bei gleichem Takt. Ergeben maximal +30% perf Steigerung bei gleicher tdp für den so am5
Den der zen6 ist die letzte apu/cpu gen für den sockel am5 und der kommt 2026
Dieser wird dann 8kerne mit 8 kleinen kernen bei 6,2ghz haben also ohne SMT 16 threads
Der sheduler wird ne Herausforderung weswegen ich reine 8 kern cpu erwarte mit 3d vcache
Ob das dann wirklich schneller wird als die nächste zen5 cpu ist fraglich

Am6 wird das beerben und mit dem n3x node nochmal +10% bringen bis man mit zen8 dann die 7,5gz marke durchbricht in n2 node (2027) 8ghz wären drin sofern amd die tdp nicht senkt was aber wahrscheinlich ist. Da mehr kerne pro ccx vermutlich 24 (8+16)
cpu seitig ist die perf Steigerung grob vs zen4 +60% bis zen8
das wird in high end gaming Wichtig aber in low end macht das kein unterschied aus.
Dort erwarte ich kompletten umdenken Richtung apu mit quadchannel und ddr6 ram.
Was vermutlich mit am6 kommen wird.
bsp zen7 60cu 3,0ghz 8 kern cpu mit 3dvcache 128mb 5,5ghz= 26tf mit ipc von zen5 (+15% zu heutigen cpu) grob 409gb/s das entspricht der rtx4070 super mit ne r7 7800x3d und das mit 250w tbp inklusive mainboard.
zum vergleich die rtx4070 super alleine 220w und r7 7800x3d system 150w =370w min

low end wird 2027 an nicht mehr geben ab dann kauft jeder ein apu system und high end zum Gegenstück etwa den amd zen8 24kern (8+16) mit 2cu igp bei 7,5ghz ab 800€ mit board und ram und ner rtx7070 ab 600€
Die rtx7070 dürfte grob so schnell sein wie die rtx4090 heute ab 2027

[iamthebear]

Waren das nicht unterschiedliche CPUs mit unterschiedlichen Speichersettings (LP5X-7400 vs. LP5-6400) in unterschiedlichen Systemen (Handheld vs. Notebook)? Bei 15W und drunter spielt es schon eine Rolle, ob etwa 2W extra für den LP5X bei Phoenix2 verbraten werden. David Huang hat nicht umsonst diese Fußnote da drunter gesetzt:

Also ich interoretiere das so:
Die violette Linie ist eine andere CPU. Deshalb die Bemerkung mit unterschiedlichen CPUs. Die würde ich geistig ais dem Diagramm streichen.
Die dunkelblaue und olivfarbene Linie sind die Zen4 bzw. Zen4c Kerner desselben Geräts.

Aber schau Dir mal die Spannungskurve an. Bei 3GHz erreichen wir genau den Punkt, wo Zen4c die von mir bereits erwähnten 20% mehr Spannung benötigt als Zen4 (0,77V * 1,2 = 0,92V). Und nach den von AMD veröffentlichten zahlen für die effektive dynamische Kapazität der Transistoren in Zen4 ist dann auch ziemlich genau da der Crossover für die Kerne im Verbrauch (je nach Art der Last kann sich das noch etwas verschieben, ober so im Mittel dürfte das ganz gut hinkommen).

Das mit den 20% behauptet AMD. Aber ist das auch durch unabhängige Tests belegt?
Zumindest beim Test von David Huang ist Zen4 bei ca. 3GHz (um die 5.5 im Diagramm) noch um ca. 400mW sparsamer.

Es mag schon stimmen, dass Zen4c bei gleichem Verbrauch etwas höhere Spannungen verwenden darf aber eben keine 20%.
Nach dem Diagramm von David Huang würde ich eher ca. 10% schätzen bzw. 20% weniger Verbrauch bei gleicher Spannung.

Na, bei 65W TDP, wo die Dinger sowieso maximal 40-50W ziehen, der Crossover zwischen Zen4 und Zen4c bei dem Modell aber irgendwo unter 20W Package-Power liegt. Das ist also genau so zu erwarten. Wenn man sich die Zahlen mal ansieht, dann erkennt man, daß ein Zen4c-Kern da ungefähr 2 bis 3W Verbrauch addiert. Und die boosten dort bis 3,7GHz (die sind nie im TDP-Limit, was ja bei 65W, PPT 88W liegt, die schöpfen nur die Hälfte aus). Bei 3GHz liegen die also wohl um/unter 2W pro Kern (außer irgendwelchen AVX512-Loads oder einem "Power-Virus" Code vielleicht).

Anhand der Kurve würde ich den takt/spannungsunabhängigen Grundverbrauch auf ca. 4.5W schätzen.
Damit sind wir bei 3GHz bei ca. 1.4W für Zen4 und 2W für Zen4c.
Der Break even Point ist in etwa bei 2.2GHz bzw. grob geschätzt im 0.5-1W Bereich.
Da frage ich mich schon welche Geräteklasse man damit ansprechen will?
Anwender, die regelmäßig 8+ Kerne auslasten werden wohl kaum ein Gerät kaufen, dass auf 8W gedrosselt ist.
Das Ganze macht eher nur bei Idle/Teillast Sinn aber da ist die Frage, ob man nicht eher bei den 4.5W Grundverbrauch ansetzen sollte.

Zen4c lohnt sich in ultramobilen Notebooks/Handhelds (TDP <20W, Takt im Mittel unter 3,2GHz oder so)

Die Geräteklasse wird die meiste Zeit nur leichte Office Workloads erledigen mit 1-2 Threads.

oder eben in Server-CPUs mit massiven Kernanzahlen (<=2W pro CPU-Kern)

Aktuell sind wir bei maximal 128 Kernen bei 360W TDP. Das wären 2.8W pro Kern. Auch hier wäre Zen4 schon schneller.

Im Endeffekt gibt es nur einen Grund: AMD spart mit Zen4c einfach Die Size/Kosten bzw. kann man umgekehrt bei gleicher Die Size mehr Kerne unterbringen und 128 Zen4c Kerne gewinnen dann gegen 96 Zen4 Kerne wenn dkje Workloads parallel genug sind.

Ich z.B. hätte gerne ein ultramobiles Convertible, am besten passiv gekühlt, TDP <10W für extralange Akkulaufzeit und geringes Gewicht. Da bietet sich Zen4c an und ist dort auch energieeffizienter als Zen4.
Das wird sich vermutlich so ähnlich auch auf Zen5c und Zen6c übertragen (um mal wieder auf das Thema des Threads zu kommen).

Zen5c ist N3, Zen5 ist N4
Bei Zen6 wird es vermutlich genauso laufen mit Zen6c N2 vs. Zen6 N3
Das alleine ändert die Lage bezüglich des Verbrauchs schon massiv.

Theoretisch wären da sogar 3 Varianten denkbar:
N3: Zen6 classic (Client)
N2: Zen6 Server classic (selbe/höhere Performance, niedrigerer Energieverbrauch aber höhere Kosten durch teure Wafer)
N2: Zen6 dense (niedrigere Performance, niedrigerer Energieverbrauch, gleiche Kosten durch höhere Density)

[Nightspider]

ich weis ja nicht wieso man so gehyped vom zen6 ist
Das ist nur ein node sprung von n5 auf n3 was maximal 15% Takt bringt
Da zen5 nur arch Änderungen hat und grob +15% perf bringt bei gleichem Takt. Ergeben maximal +30% perf Steigerung bei gleicher tdp für den so am5

Man kann erwarten das für Zen6 mehr Advanced Packaging Methoden Anwendung finden.
Es wurde ja schon spekuliert das die CCDs deutlich näher an den IOD wandern und sich 2 CCDs mehr wie ein monolithischer Chip verhalten wird.
Ebenso wird Idle Effizienz massiv verbessert.

AMD könnte die Cache Hierarchie auch komplett anders aufbauen. L2 V-Cache und ein dicker eDRAM über dem IOD oder ähnliche Späße.

Vielleicht wird man auch erst mit Backside Power Delivery die Cache Hierarchie komplett über den Haufen werfen aber irgendwann wird ein Schritt in dieser Richtung kommen.

Mit Zen5 wird die Rohleistung vermutlich erstmal stark ansteigen. Wie AMD das Memory Bottleneck (teilweise?) umschifft muss man abwarten.
Wie man an den X3D Varianten gesehen hat können einige Anwendungen gar nicht genug Cache+bessere Latenzen haben.

[dildo4u]

Zen 6 in XPS Laptops?Oder Strix mal sehen.

https://videocardz.com/newz/exclusive-dell-xps-16-laptop-may-integrate-amd-cpu-in-2027

[HOT]

Das ist ja sehr interessant, wie stark man Qualcomm intergrieren möchte.
Gibt noch ein paar interessante Dinge zu entdecken:

Nova Lake ist ein Nachfolger von PTL-U/P, NICHT H, also scheint es eher um so ne Art LNL-Nachfolger zu geben, während es von PTL auch größere, also H-CPUs gibt.

[basix]

Noch als Idee, was AMD an den FPUs ändern könnte, um einen noch kleineren "Zen 6 Dense Client" zu realisieren: Etwas ähnliches wie bei Zen 2 auf dem PS5 SoC https://chipsandcheese.com/2024/03/20/the-nerfed-fpu-in-ps5s-zen-2-cores/

[=Floi=]

der artikel ist ja mal gut

[][immy]

Noch als Idee, was AMD an den FPUs ändern könnte, um einen noch kleineren "Zen 6 Dense Client" zu realisieren: Etwas ähnliches wie bei Zen 2 auf dem PS5 SoC https://chipsandcheese.com/2024/03/20/the-nerfed-fpu-in-ps5s-zen-2-cores/
Damit würde man aber die Performance reduzieren und es dem scheduler unnötig schwer machen. Man hat sich ja für dense cores entschieden, weil es dann nur einen taktunterschied gibt. Vom beschneiden in der Performance ist man ja abgewichen. Man könnte ja so was wie avx512 etc raus lassen, hätte dann aber funktionelle Unterschiede was es nur komplexer macht. Was den Konsolen CPUs wirklich weh tat ist die Reduzierung des Caches. Das spart Fläche aber man lässt halt auch masdig Leistung liegen.
Bei den dense cores könnte es mit den neuen Fertigungen allerdings wieder zu Problemen beim takt kommen. Denn die Wärmeentwicklung trifft auf weniger Fläche, während (nachdem was bislang bekannt ist) der Energiekonsum nur moderat zurück geht.

[davidzo]

Noch als Idee, was AMD an den FPUs ändern könnte, um einen noch kleineren "Zen 6 Dense Client" zu realisieren: Etwas ähnliches wie bei Zen 2 auf dem PS5 SoC https://chipsandcheese.com/2024/03/20/the-nerfed-fpu-in-ps5s-zen-2-cores/
Ich kann mir gut vorstellen dass das auch für Dense Server interessant ist. Bei Hyperscalern steht Integer performance und "good enough" per Core Performance im Vordergrund. Neoverse V2 und Sierra Forrest setzen beide auf mittelprächtige Floatingpoint Units mit lediglich 256bit maximaler Länge. Zen4C tanzt da also schon aus der Reihe it mehr Vektorleistung als nötig.

Allerdings sind Hyperscaler jetzt nicht gerade der beliebteste Markt / Kunde und mit Sierra Forrest und Ampere, Gravitron, azure Cobalt gibts auch zuviel Konkurrenz. Nicht nur sind Hyperscaler hauptsächlich an Konsolidierung interessiert, die drücken auch gerne auf die Margen weiul sie ja soviel kaufen. Nichts im Vergleich zu der Goldgräberstimmung aktuell im AI Markt.
Es kann also sein dass AMD sich diese Mühe einfach nicht mehr macht und den "kleinen" Dense Server Markt einfach Intel und ARM überlässt und stattdessen lieber gute HPC und AI Server CPUs mit voller FPU baut.

[Leonidas]

Nova Lake ist ein Nachfolger von PTL-U/P, NICHT H, also scheint es eher um so ne Art LNL-Nachfolger zu geben, während es von PTL auch größere, also H-CPUs gibt.

Normalerweise müsste NVL alles bedienen, da es endlich mal über 8P gehen soll. Aber natürlich ist dies bei so weit entfernten Projekten alles noch nicht so sicher.

[HOT]

Ja aber es war doch wieder die Rede davon (also Gerüchte), dass man für die S-CPUs N2/P nutzen wollte. Wenn das stimmt gibts sicherlich wieder nen eigenen Codenamen.

[basix]

Neue Gerüchte: Zen 6 soll 8/16/32C CCX haben
https://wccftech.com/amd-zen-6-three-ccd-configurations-8-16-32-cores-zen-5c-16-cores-single-ccx/

Meine Speku:
- Consumer Standard = 8C (single CCD)
- Consumer High End = 16C (single CCD)
- Server Standard = 16C
- Server Dense = 32C

[robbitop]

Neue Gerüchte: Zen 6 soll 8/16/32C CCX haben
https://wccftech.com/amd-zen-6-three-ccd-configurations-8-16-32-cores-zen-5c-16-cores-single-ccx/

Meine Speku:
- Consumer Standard = 8C (single CCD)
- Consumer High End = 16C (single CCD)
- Server Standard = 16C
- Server Dense = 32C

CCDs laut Kepler. Können also immernoch mehrere CCX pro CCD sein.

[Nightspider]

War ja offenbar eh für AM5 geplant und da Intel jetzt mehr Druck aufbaut ist es eine logische Entscheidung.

Zen5 bringt massiv mehr SC Leistung

Zen6 verringert Latenzen und erlaubt deutlich mehr MC Leistung

[mboeller]

CCDs laut Kepler. Können also immernoch mehrere CCX pro CCD sein.

das Bild sagt was anderes

[robbitop]

Welches Bild meinst du?

[mboeller]

Welches Bild meinst du?

das hier:
https://cdn.wccftech.com/wp-content/uploads/2024/05/AMD-Zen-5-Zen-5C-Core-Configurations.png

rote Spalte: CCX = 1 bei ZEN6

[amdfanuwe]

Wohl das hier:
88205
https://x.com/InstLatX64/status/1791830391025742310

Edit: Hier stand Unsinn

[HOT]

Das wäre ja eh der nächste Schritt, ein flexibles CCX- Design. Und das übernächste wäre dann das flexible 3D-CCX.

[Gipsel]

Wohl das hier:
88205
https://x.com/InstLatX64/status/1791830391025742310
Wobei ∑th anscheinend L3 Cache sein soll. ∑ = Summe
th = Threads
Maximale Anzahl Threads im System (mit 2 Sockeln).

[amdfanuwe]

∑ = Summe
th = Threads
Maximale Anzahl Threads im System (mit 2 Sockeln).
AH, OK. Mit 2 Sockeln ergibt es Sinn. Danke.

[basix]

Meine Speku:
- Consumer Standard = 8C (single CCD)
- Consumer High End = 16C (single CCD)
- Server Standard = 16C
- Server Dense = 32C

Vielleicht als Ergänzung zu dem:
- Consumer Mobile = 8C (single CCD) + 8C Zen 6c (auf den SoC/IOD)

[latiose88]

hm schade also nix mit 32 Kernen im mainstream oder 24 Kerner. Also Zen 6 erhöht die Anzahl an maximalen Kernen nicht bei der consomer Plattform.

[Altehardware]

Davon ist nicht auszugehen
Was passieren kann ist das ab zen6 16 Kerne ich einen ccx sind da hat vorteile beim cache in multicore Programmen spiele werden davon nicht profitieren da bis 8 thread sowieso dicht ist mit der Parallelisierung
Was dagegen hilft ist ein größerer x3d cache der schneller zugriffe hat also bspw mit 8ns was ich schon mit zen5 erwarte

[Mangel76]

hm schade also nix mit 32 Kernen im mainstream oder 24 Kerner. Also Zen 6 erhöht die Anzahl an maximalen Kernen nicht bei der consomer Plattform.

Gibt es nur noch 1 CCD?

[latiose88]

Nun das weiß ich nicht weil ich was auf ner anderen Plattform gelesen hatte das es mit Zen 6 angeblich bis zu 32 Kerner geben wird. woher die diese Info her haben, kann ich aber nicht sagen. denke mal das es nur ein Gerücht ist wie fast alles was keine klaren Aussagen sind. Zumindest eines ist sicher das es auf am5 kommen wird und sonst weiß man ja nix genaues.

[basix]

Gibt es nur noch 1 CCD?

Keine Ahnung ;)

Ich habe das einfach spekuliert, weil es bei separaten 8C / 16C CCD Sinn machen würde. Beide in 3nm gefertigt. 32C dann in 2nm und "Dense". Es kann aber auch anders sein. Z.B. wenn 8C Zen 6 ist und 16/32C Zen 6 "Dense". Kann auch möglich sein. Ich tippe allerdings auf 8/16C in 3nm und früher Start (da N3P/X früher bereit sein sollten als N2). 32C kommt etwas später.

Für Consumer sind 8 sehr schnelle Kerne in den meisten Fällen wertvoller als 16C etwas langsamere. Und es besteht immer noch die Möglichkeit, dass AMD 2x CCD bringt und bis zu 32C. Erwarte ich aber nicht, da N3/N2 relativ teuer sein werden. Und irgendwie wäre es auch ein wenig verblüffend, da bereits Zen 2 bis zu 16C in den Desktop-Bereich brachte.

[iamthebear]

Davon ist nicht auszugehen
Was passieren kann ist das ab zen6 16 Kerne ich einen ccx sind da hat vorteile beim cache in multicore Programmen spiele werden davon nicht profitieren da bis 8 thread sowieso dicht ist mit der Parallelisierung
Was dagegen hilft ist ein größerer x3d cache der schneller zugriffe hat also bspw mit 8ns was ich schon mit zen5 erwarte

Bereits aktuelle Spiele nutzen bereits 8 Kerne aus. Bei 6 Kernen gibt es schon Performanceeinbußen.
Zen6 Release ist vermutlich 2026 d.h. er wird von 2026-2028 gekauft werden und muss daher mindestens mindestens für Spiele 2033 ausgelegt sein.

Die Variante mit 16 Kernen + VCache hört sich verdammt interessant an.

Keine Ahnung ;)

Ich habe das einfach spekuliert, weil es bei separaten 8C / 16C CCD Sinn machen würde. Beide in 3nm gefertigt. 32C dann in 2nm und "Dense". Es kann aber auch anders sein. Z.B. wenn 8C Zen 6 ist und 16/32C Zen 6 "Dense". Kann auch möglich sein. Ich tippe allerdings auf 8/16C in 3nm und früher Start (da N3P/X früher bereit sein sollten als N2). 32C kommt etwas später.

Afaik ist nur die 32 Kern Variante eine Dense Version. Sowohl 8 Kerne als auch 16 Kerne werden normale Zen6 sein.

Für Consumer sind 8 sehr schnelle Kerne in den meisten Fällen wertvoller als 16C etwas langsamere. Und es besteht immer noch die Möglichkeit, dass AMD 2x CCD bringt und bis zu 32C. Erwarte ich aber nicht, da N3/N2 relativ teuer sein werden. Und irgendwie wäre es auch ein wenig verblüffend, da bereits Zen 2 bis zu 16C in den Desktop-Bereich brachte.

Die 16 Kerne werden normale Zen6 Kerne sein. Da ist nichts langsamer und die benötigt AMD schon für die reguläre Datacenterschiene (Dense ist hier eher eine Nische).
AMD wird die 12/16 Kerne dann kaum noch als Dual CCD raus bringen.
Und auch eine 32 Kern Variante sehe ich ehrlich gesagt als relativ sicher an wenn Intel mit ARL 8+32 bringt (mit deutlich stärkeren E Cores als jetzt).

Was die Kosten angeht: Die Kerne selbst sind bereits jetzt relativ klein und mit N3 werden diese noch weiter schrumpfen und der L3 und der "Rest" für die Die 2 Die Kommunikation werden den Großteil des Platzes einnehmen. Da ist ein 16 Kern CCD mit 32MB L3 deutlich günstiger als 2CCDs mit je 8 Kernen.
Ob die Endkundenpreise nach oben gehen werden oder nicht wird davon abhängen was Intel liefert.
Kostendeckend bleibt das Ganze auf jeden Fall noch. Aus einem Wafer kann AMD um die 800 Dies herstellen. Selbst bei einem Preis von 20K pro Wafer sind das gerade einmal 25$ pro CCD bei einem Aufpreis von >200$ von 8 auf 16 Kerne.

Unrentabel sind eher die Low End 4/6 Kerner, die zu Schleuderpreisen an OEMs gehen aber trotzdem ein 12

[amdfanuwe]

Mal die Daten von N3(E) vs N5 rausgesucht:
88231
https://www.anandtech.com/show/18833/tsmc-details-3nm-evolution-n3e-on-schedule-n3p-n3x-deliver-five-percent-gains

Da die SRAM Zellen nicht shrinken, frag ich mich wieviel L3 Cache der 32 Core haben soll.
Beim ZEN4c 16 Core ist AMD ja schon auf 2 x 16MB runter gegangen, also 2MB /Core.
Also entweder wird das Chiplet größer oder der L3 Cache wird gestacked, bzw. das Compute Chiplet auf L3.

8Core Chiplet dürfte wie bisher auch gebaut werden für günstige Standardware.
Bei den 16Core bzw. 32Core Chiplets könnte ich mir durchaus etwas wie bei MI300 vorstellen.

Wie viele Cores wir im Desktop sehen, hängt von der TDP und der Bandbreite ab. Bringt ja nichts, wenn die Cores nicht entsprechend ausgelastet werden können.

Na, jetzt erst mal ZEN5 abwarten. N3 bringt ja nicht viel im Vergleich zu N4P.
88234

[latiose88]

jap vorallem weil wir ja bei n4p sein werden und da schrumpft es dann schon sehr stark gegenüber N3 dann.
Da kann AMD nur noch wenn es 24 oder 32 Kerner im Mainstream nur noch den Stromverbrauch erhöhen.
Wenn AMD einen 32 Kerner bringt dann sicherlich auch einen 24 Kerner.
Ob AMD es durch misch konfig macht oder anderst kann man auch nur spekulieren.
Die threadripper die ich immer mal testen durfte bei anderen war es bei jedem 32 Kerner das selbe gewesen das abschalten von smt schadete nicht und beim 24 Kerner steigerte es sogar die Leistung massiv.
hier könnte durchaus der andere Ansatz besser als smt sein.
ist halt die frage was besser ist 16 Kerne + smt mit normaler l3 Cache aufbau oder misch Betrieb 16+8 mit gesenkten l3 Cache als Duell. Hier wird sich erst noch zeigen ob Cache Verlust vs ein kleiner Plus durch mehr Kerne hier mehr wiegt oder nicht.
ich sage mal das wird sich die wage legen wie 10 % Verlust durch weniger l3 aber 15 % plus durch 8 bzw 16 extra Kernen.
es wird also wie immer entscheiden was mehr Leistung bringt. Ich lasse es auf mich zu kommen.

[Badesalz]

Bereits aktuelle Spiele nutzen bereits 8 Kerne aus. Bei 6 Kernen gibt es schon Performanceeinbußen.Also wie 2015 schon :usweet:

6c skalierten schon immer bei den meisten Spielen weniger gut als 4C und 8c. Sogar auch bei vielen realen MT-Anwendungen (Packer mal generell ausgenommen) und es gab IMHO bisher noch keine Anzeichen, daß sich das in naher Zukunft grundlegend ändern könnte.

[iamthebear]

jap vorallem weil wir ja bei n4p sein werden und da schrumpft es dann schon sehr stark gegenüber N3 dann.
Da kann AMD nur noch wenn es 24 oder 32 Kerner im Mainstream nur noch den Stromverbrauch erhöhen.

Oder sie drosseln bei Last auf allen 32 Kernen einfach wieder etwas den Takt ähnlich wie beim 5950X. Dann hat man statt 2x MT Performance eben nur mehr 1.7x MT Performance aber gleichen Verbrauch.

Wenn AMD einen 32 Kerner bringt dann sicherlich auch einen 24 Kerner.
Ob AMD es durch misch konfig macht oder anderst kann man auch nur spekulieren.
Die threadripper die ich immer mal testen durfte bei anderen war es bei jedem 32 Kerner das selbe gewesen das abschalten von smt schadete nicht und beim 24 Kerner steigerte es sogar die Leistung massiv.

Es gibt immer teildefekte CCDs die man wunderbar zu 12 oder 24 Kernern machen kann. Genauso läuft es ja auch mit 6/12 Kernen heute. Ich denke, dass auch eine 12 Kern VCache Variante sehr gut laufen würde. Bis dahin werden 8 Kerne wohl schon zu wenig sein aber 12 für viele gerade passen.

[latiose88]

Naja wenn ne Anwendung vom takt sehr gut profitiert dann werden am Ende 24 oder 32 Kerne die weniger takten gleich schnell sein als sehr schnelle 16 Kerner.
um das zu packen wird es wohl am Ende 4 GHz oder nur 3,8 GHz allcore takt bei einem 24 oder 32 Kerner sein der dann mit dem 16 Kerner der 5,4 GHz allcore takt antritt wohl nicht mehr besser sein weil das funktioniert nicht. Bei der Software wo sehe gut davon profitert wird selbst mit nur 3,5 oder 3 GHz der 32 Kerner noch immer schneller sein als eine 5 GHz 16 kerner. Aber bei 2 GHz verliert selbst da dann die CPU mit mehr Kernen jeden Kampf gegen eine 5 GHz 16 jener klar. Bei mir ist es klar die rund 14 % Leistungsunterschied bei einem 24 Kerne würde es bei nur 3 GHz ganz klar verlieren und da ist die Wahl klar mit den 16 kernen.
wenn ich also mehr Leistung haben will bleibt am ende nur treadripper übrig weil 24 Kerne und 4,8 GHz allcore takt. das bringt man ganz klar nicht in einer Mittelklasse unter.
Da brauche ich mir keine falsche Hoffnung zu machen.

[Wuge]

Bei entsprechender Auslastung ist ein Design mit mehr Kernen die im Powerlimit stärker drosseln immer schneller und effizienter!

[dildo4u]

Er Erwartet in 2025 eine 3nm IO Die was zur Verschiebung von Strix Halo geführt hat.


oUv4US_FAjM

[HOT]

Er macht sich das natürlich wieder zu leicht, die Entscheidungen düfür müssen ja schon in 21/22 gefallen sein, wie für RDNA4. Allerdings würde ich das auch im Rahmen von RDNA4 sehen wollen. Ich denke, sowohl AMD als auch NV haben mit N3 ursprünglich geplant. Aber beides wuirde nix wegen KI und der Verschiebung von N3 auf N3B und natürlich Intels Großaquise von N3B.
MMn sind Strix Halo, Strix Point und N4x sind "Ersatzchips" für die ursprüngliche N3 Planung.

Medusa scheint aber im Plan zu liegen, N2 CCDs mit N3 IODs.

[iamthebear]

Also wie 2015 schon :usweet:

6c skalierten schon immer bei den meisten Spielen weniger gut als 4C und 8c. Sogar auch bei vielen realen MT-Anwendungen (Packer mal generell ausgenommen) und es gab IMHO bisher noch keine Anzeichen, daß sich das in naher Zukunft grundlegend ändern könnte.

Im Jahr 2015 war gerade 4 Kern Haswell aktuell und SMT wurde oft noch immer abgeschaltet da es noch keine Spiele gab die mehr als 4 Threads hatten.

Der Ryzen 1800X war beim CB Launch Review 2017 gerade mal 1% schneller als der 1600X im Gaming Test.

Vor 3-4 Jahren nutzten Spiele um die 6-8 Threads. Je nach Spiel konnte selbst 4 Kern CPUs (mit ausreichend schnellen Kernen und L3) noch gut mithalten. Es gab jedoch öfters mal noch etwas "Schluckauf" wenn sich 2 Threads mit SMT einen Kern teilen mussten weshalb 8 Kerne manchmal schon etwas schneller als 6 Kerne waren.

Mit heutigen Spielen (TLOU, Starfield etc.) gibt es schon um die 12-16 aktive Threads. 4 Kerner brechen komplett weg. Bei 6 Kernern sind es im Schnitt auch schon 10%. Es gibt jedoch deutlich weniger "Schluckauf" Fälle wodurch 8 Kerne mit SMT im Normalfall immer ausreichen und 12 Kerne noch keinen erkennbaren Vorteil bringen. Es ist halt aktuell alles auf 8 Kerne + SMT optimiert.

Was wird wohl mit Spielen in 3 Jahren passieren wenn:
.) Zen6 ein 16 Core CCD mit VCache hat
.) Intel neben den P Cores noch 16 schnelle Skymont Kerne hat die auch wirklich brauchbar sind
.) Die nächste Konsolengeneration mit einer Mischung aus Standard und Dense Cores launchen (z.B. 8+8)

[Badesalz]

Irgendwie bin ich da bis heute der Meinung, daß mehrere Threads zwar fürs Ganze ackern, aber für die jeweilige Aufgabe macht man meist "einen Job für 2" (bei Spielen z.B. ). Und deswegen skaliert ist immer schlechter von 4 auf 6 als von 6 auf 8. Als wenn bei 6 immer eine Aufgabe gäbe wie jene 2 Threads auf einem Core ablaufen :confused:

Jedenfalls eben vom Eindruck her. Ich meine bie Adobe skalieren 6 und 12 Kerne auch feststellbar schlechter als von 2 auf 4 auf 8.

[Complicated]

mehrere Threads zwar fürs Ganze ackern, aber für die jeweilige Aufgabe macht man meist "einen Job für 2"
Für mich liest sich das wie ein Widerspruch der immer wieder in den Köpfen spukt. Die jeweilige Aufgabe=das ganze Ackern.

Du schreibst einfach von Workloads die eben nicht so ackern müssen auf der CPU und wo 2 Threads reichen um eine GPU mit Arbeit zu füttern, wo die eigentliche Arbeit stattfindet. Wo keine Arbeit, kann auch nichts skalieren für die CPU.

[MiamiNice]

Was wird wohl mit Spielen in 3 Jahren passieren wenn:
.) Zen6 ein 16 Core CCD mit VCache hat
.) Intel neben den P Cores noch 16 schnelle Skymont Kerne hat die auch wirklich brauchbar sind
.) Die nächste Konsolengeneration mit einer Mischung aus Standard und Dense Cores launchen (z.B. 8+8)

Ich schätze genau so viel wie bisher passiert ist. Mehrkern CPUs gibt es schon ein paar Tage und die Software und Spielelandschaft nutzt diese seit jahren, im Desktop, nicht aus. Warum sollte sich daran etwas ändern? Das Problem ist, so weit mir bekannt, nicht die verfügbare HW, sondern dass sich diverse Dinge nicht parallelisieren lassen und es nicht einmal eine passende Sprache gibt für echtes MT. Es wird noch eine ganz lange Zeit nicht so sein, wie es sein sollte. 1 Kern 100 Prozent Leistung, 2 Kerne 200 Prozent Leitung - über alle Applikationen hinweg. So lange das nicht so ist, ist das alles nur Augenmalerei. Das Auslagern von diversen "Subtasks" auf einen anderen Kern, ist imo kein Multithreading. Und so lange kann ich auch mit einem schnellem 4 Kerner alles gamen was es gibt. Und genau so lange haben, IMO, die ganzen Many Core CPUs im Desktop auch keinen tieferen Sinn. Außer natürlich man macht DInge die sich gut parallelisieren lassen, Bildbearbeitung, Rendern, etc. pp.

[latiose88]

naja selbst wenn es nicht ganz so kommt wie es da als gerüchte kommen,so wäre ein 16 Kern non Chiplet ja für einige schon ein Gewinn.Wenn dann macht das AMD nur damit im Threadripper bereich mehr Kerne geht.Und das wäre auch für den ein oder anderen ein Gewinn.Keine Latenzverzögerung mehr,keine hohen Idle Stromverbrauch mehr usw.
Das wäre ein Gewinn für uns.Wie dann die Onbaord GPU dann Platziert wird,weis ich auch nicht.Ich kann nur was wäre wenn es nicht so laufen wird wie wir denken.Wenn es doch keine 24 und 32 Kerne im Mainstream kommen sollten.AMD hätte ja noch immer die Option dies nachzuholen.Solange also Intel nicht auf Augenhöhe und zwar ganz ist,wird AMD das auch so nicht bringen.Ne Single Chiplet könnte ich mir also durchaus vorstellen.Das wird sich alles dann im Jahre 2026 schon noch sehen wie es aussehen wird.Ich denke auch nicht das wir so schnell 24 Kerne und so sehen werden.Intel kann es sich ja Leisten und zudem erst nun recht weil Hypertrading weg fällt.Durch das hat Intel etwas mehr Platz,auch wenn das nicht so viel ist.

Und wir wissen auch nicht welchen Weg AMD am Ende gehen wird.

[Windi]

Es ging ja um Spiele.
Die Playstation 4 hatte schon 8 Kerne und trotzdem können heutzutage die meisten Spiele damit nicht effizient umgehen. Und wie lange ist das schon wieder her?

Die Playstation 5 hat 8 Kerne
Die Playstation 6 hat vermutlich 8 Kerne (bessere Kerne + großer gemeinsamer Cache // für mehr ist die Fertigung wohl zu teuer).
Der ganze Alt-Bestand hat größtenteils 6 oder 8 Kerne.
Notebooks haben meist nur 6 oder 8 Kerne.
Neuste Gamingrechner, mit einer Grafikkarte die weit über 1000€ kostet, haben nur eine CPU mit 8 Kernen.
....


Nur weil plötzlich Chiplets mit 16 Kernen (an einem großen Cache) auf dem Markt kommen, werden es die Spiele nicht sofort brauchen. Das wird wieder ewig dauern. 10 Jahre? Vieleicht etwas mehr oder weniger.

[basix]

Die Playstation 6 hat vermutlich 8 Kerne (bessere Kerne + großer gemeinsamer Cache // für mehr ist die Fertigung wohl zu teuer).

Ich kann mir schon gut vorstellen, dass man z.B. auf eine 4+8 Konfiguration wechselt. D.h. vier Zen 6 und acht Zen 6c Kerne. Dann taktet man die grossen Kerne einiges höher, was für kritische Threads gut helfen würde. Und wohl auch mehr bringen würde als eifnach 16 Zen 6c Cores. Dieses P+E Core Schema wird auch einem Grossteil des Umfelds bei Mobile und Desktop entsprechen, welcher bis dann etabliert ist. Intel macht es bereits seit einiger Zeit vor, AMD macht es bei Mobile auch. Und für die Big Core Only CPUs spielt es auch nicht so eine Rolle, wenn Games auf Big+Little optimiert sind.

[Badesalz]

Du schreibst einfach von Workloads die eben nicht so ackern müssen auf der CPU und wo 2 Threads reichen um eine GPU mit Arbeit zu füttern, wo die eigentliche Arbeit stattfindet. Wo keine Arbeit, kann auch nichts skalieren für die CPU.Ich finde das ist auch eine bessere Beschreibung dessen was ich meinte :smile: Nur erklärt sie das gemeinte Phänomen bei 6/12 nicht so ganz...

[Complicated]

Die beste Beschreibung ist: Die Software//Treiber skaliert die CPU-Kerne nicht mit dem benötigten Workload. Hat nichts mit der CPU zu tun.

[Windi]

Ich kann mir schon gut vorstellen, dass man z.B. auf eine 4+8 Konfiguration wechselt. D.h. vier Zen 6 und acht Zen 6c Kerne.

Es ging mir vor allem um die Software.
Wie gesagt, die Playstation 4 hatte schon 8 Kerne. Erst jetzt nutzen Spiele das wirklich und noch immer ist es nicht optimal.

Selbst wenn bald etwas kommt, das mehr Kerne im Gaming Bereich bringt, wird die Software noch lange brauchen. Vor allem schauen die Entwickler ja eher auf den Altbestand und nicht auf die neusten Highend Kisten. Und die Vorgängerkonsolen müssen auch noch lange unterstützt werden.

Bei den neuen Konsolen muss man Mal abwarten was da kommt. Die Hersteller sind alle am jammern, das alles so teuer geworden ist. Und zusätzlich will man sicherlich auch noch neue Sachen, wie zum Beispiel eine NPU integrieren. Mich würden 8 Kerne bei den neuen Konsolen nicht großartig überraschen.

[bbott]

Die PS 3 hatte doch schon 8 Cell Kerne, wovon 7 aktiv waren.
https://www.computerbase.de/2007-04/test-sony-playstation-3/6/

[latiose88]

Man kann es nur mit Tricks schaffen mit 2 gleichzeitig. Würde ich die Software nur 1 x starten wäre mein 16 Kerner bei rund 35 - 42 % ausgelastet. Das wäre weniger als ein 8 Kerner kann man so sagen. Würde ich mich auf sowas pochen dann würde sich auch da das selbe ergeben. Nun in dem Fall, würde ich das selbe Problem haben wie die meisten auch. Es wurde mal gezeigt das man bei einem game wie serious sam 4 mal gezeigt wurde das man teilweise von einem 12 Kerner profitieren würde aber zwischen nutzen und ausnutzen sind halt 2 paar Stiefel. Ob das Game wirklich ein echten Vorteil dabei heraus holt, ich weiß ja nicht. So richtig vorteile ist ja ne andere frage.
Zumindest 8 Kerne sind ja inzwischen ja ganz angekommen.

[00-Schneider]

Die PS 3 hatte doch schon 8 Cell Kerne, wovon 7 aktiv waren.
https://www.computerbase.de/2007-04/test-sony-playstation-3/6/


Nope, ein Cell-Kern und 8 SPEs, von denen 7 SPEs aktiv waren. Steht auch in deinem Link.

[basix]

Es ging mir vor allem um die Software.
Wie gesagt, die Playstation 4 hatte schon 8 Kerne. Erst jetzt nutzen Spiele das wirklich und noch immer ist es nicht optimal.

Ja, die PS4 hatte 8 Kerne. Nur hatte man am Desktop noch ein paar Jahre hauptsächlich 4 Kerner. Das hat auch einen Einfluss auf das Design der Engine. Und es gab schon einige Spiele, die mit 4C8T besser liefen als mit 4C4T. Nur fiel das nicht extrem auf, weil die Jaguar Kerne viel, viel langsamer waren als Sandy Bridge bis Skylake. Da reichten vier schnelle Cores meistens aus, obwohl die Engine mit 8 Threads umgehen konnte.

[Badesalz]

Die beste Beschreibung ist: Die Software//Treiber skaliert die CPU-Kerne nicht mit dem benötigten Workload. Hat nichts mit der CPU zu tun.JA. Das war doch eh klar :confused: :tongue:

Das irgendwas an solchen CPUs nicht stimmt sollte auch nicht die Punchline werden. Ändert halt nur nichts an dem Zustand.

[Nightspider]

Viele Spiele nutzen 8 Kerne sinnvoll.

Aber die Spiele wurden eben nicht für 8 Kerne mit 5,5 bis 6 GHz programmiert.

Bei geringer Taktrate ist die Auslastung einfach besser während bei hoher Taktrate die Latenzen und Bandbreite von Hauptspeicher, Cache und und zwischen den Kernen die Vorteile von zusätzlichen Kernen schrumpfen lassen.

Wenn ihr sehen wollt wie gut die Software skaliert taktet die CPUs auf 2Ghz.

Bei über 5Ghz bremsen die Latenzen im System ungemein stärker, da für jeden Frame nur noch ein Bruchteil der Zeit zur Berechnung zur Verfügung steht.

Und der Gamecode ist sicherlich selten for eSports Frameraten hin optimiert.

Das ist auch einer der Gründe weshalb alte 8 Kerner meistens gegen den Nachfolger mit 6 Kernen verlieren.

Siehe auch den 6 Kerner mit V-Cache.

CPUs mit 12 oder 16 Kernen müssten überdurchschnittlich von höher taktendem Cache, größerem Cache und einer schnelleren Verbindung zwischen den Kernen profitieren.

[latiose88]

gillt das ganze auch bei Anwendung oder nur bei Spielen.Ich weis nur das ab einen gewissen hohen Allcore Takt die Ausbeute immer kleiner wird.Also so ab 5 ghz ist der Gewinn geringer.Und cool das das Cache auch höher Takten kann,also so das die Latenz geringer wird oder?
Und was du meinst ist eine CCD zu CCD verbindung das diese sich schnneller und besser miteinander Kommunzieren können nicht wahr?

[Nightspider]

Spiele reagieren empfindlich auf Latenzen.

Je höher die frames liegen, desto größer werden die Nachteile der Latenzen.

Je mehr die Kerne ausgelastet, desto mehr Aufgaben müssen sich die Bandbreite teilen und desto mehr IOs belasten Caches, Register und RAM.

Manche Anwendungen profitieren genauso von größeren Caches und Bandbreite. Sieht man doch an den X3D CPUs.

Die meisten Spiele werden auf 30,40 oder zunehmend 60fps optimiert.

Deswegen ist steigt der Vorteil von X3D CPUs bei hohen Frames immer weiter, weil Non-V-Cache CPUs immer mehr durch den RAM gebremst werden.

In einigen Spielen hast du mit V-Cache 40% mehr Leistung wenn du zum Himmel schaust und 200fps hast.
Sobald du nach unten schaust sind es vielleicht nur noch 15-25%.

[latiose88]

nun ich habe anwendung wo das mit dem extra Cache nicht der fall ist.
Nun ja ich bemerke das ebenso.Der Nachfolge 12 Kerner ist gleichschnell wie der vorgägner 16 Kerner.Der 8 Kerner ist fast so schnell wie der vorgänger 12 Kerner usw.
Ist das auch schon ein Zeichen dafür das es sich wie bei den Games verhält oder doch nicht so?

[Nightspider]

Beim Nachfolger einer Architektur wird ja an vielen Stellschrauben gedreht. Viele Bottlenecks werden "geweitet". Man kann nicht sagen das es an einem Faktor liegt.

Aber alles hängt eben auch von der Speicher-Hierarchie ab.

Ich habe es oben unglücklich formuliert. Die reine Rohpower, die IPC ist der Hauptgrund.
Das ganze Speichersystem innerhalb der CPU ergibt ja als ein Faktor von vielen die IPC.

Wenn auf den Hauptspeicher zugegriffen werden muss wird er halt zum Bottleneck.

[fondness]

AMD confirms Zen 6 and Zen 6c will arrive in 2025
https://www.techradar.com/pro/amd-confirms-that-zen-6-and-zen-6c-will-arrive-in-2025-but-intel-is-set-to-grab-the-fastest-cpu-server-spot-for-the-first-time-in-a-decade-within-weeks

Könnte sich allerdings um ein Missverständnis handeln, da die Quelle für das Jahr 2025 nicht wirklich aus dem Text hervor geht.

[ryan]

AMD hat es ja auch gleich dementiert.

AMD says they didn't confirm any release date for Zen 6 CPU/Architecture.
https://x.com/hms1193/status/1815669270052831538

[HOT]

Wenn ein Zen6 kommt ist das für mobil genau am Ende des Jahres. Der normale Zyklus für Desktop wäre Mai 26 und das ist auch am realistischsten.

[dildo4u]

Der normale Zyklus wäre 2026, Zen 4 war 2022.

Verkaufsstart 27. September 2022

https://de.wikipedia.org/wiki/Zen_4

Erst wenn Apple von 3nm runter ist bekommt AMD die Reste die übrig bleiben anders kann man keine billigen CPU produzieren.

[Badesalz]

Einen Grund sich damit zu überschlagen gibt es nicht.

[Nightspider]

Es gibt keine festen Zyklen.

Kann genauso gut sein, das Zen5 deutlich hinter dem Zeitplan liegt.

[dildo4u]

Ja da geht es aber eher um Monate nicht Jahre Anfang 2024 hätte Sinn gemacht da 4nm alt ist und Intel 3nm Modelle fast gleichzeitig bringt.(Lunar Lake ist Q3)

[basix]

Jetzt da Zen 5 dicke 512bit FPUs hat:
512bit und aber auch 256bit Operationen können aber nur 2 pro Cycle abgearbeitet werden. Soweit ich das verstehe ist das bei 128bit Operationen ebenfalls so. Ausnahem ist, wenn man FADD + FMA mixt, dann gehen auch 4x Operationen pro Cycle (bei 128/256/512bit).
Könnte man es hier nicht relativ leicht umbauen, sodass man zumindest bei 128/256bit Operationen mehr Befehle pro Cycle abarbeiten kann? Bei 128bit im besten Fall sogar 8x Instruktionen / Cycle. Damit würde man die bestehende FPU-Breite deutlich besser ausnutzen, unabhängig von der Vektor-Breite.

Ich stelle mir hierbei sowas wie Instruction Fusion vor, wo man mehrere 128/256bit Instruktionen zu 512bit "zusammenkleben" kann und in einem Rutsch durch die Pipeline schiebt. Load/Store ist hier evtl. noch tricky aber auch hier hätte man bereits die erforderliche Datenpfad-Breite sowie Bandbreite.

[Gipsel]

Jetzt da Zen 5 dicke 512bit FPUs hat:
512bit und aber auch 256bit Operationen können aber nur 2 pro Cycle abgearbeitet werden. Soweit ich das verstehe ist das bei 128bit Operationen ebenfalls so. Ausnahem ist, wenn man FADD + FMA mixt, dann gehen auch 4x Operationen pro Cycle (bei 128/256/512bit).Gibt auch noch logische Operationen und Swizzles und so.
Könnte man es hier nicht relativ leicht umbauen, sodass man zumindest bei 128/256bit Operationen mehr Befehle pro Cycle abarbeiten kann? Bei 128bit im besten Fall sogar 8x Instruktionen / Cycle. Damit würde man die bestehende FPU-Breite deutlich besser ausnutzen, unabhängig von der Vektor-Breite.Nein.
Hauptproblem ist, daß man zu viele Operanden hat. Das Registerfile würde dann auch mindestens doppelt so viele Ports benötigen (Alleine 20 Readports und dann nochmal einen Sack Write-Ports obendrauf). Der Aufwand dafür wäre astronomisch.

[basix]

Könnte man die Anzahl Operanden nicht reduzieren? Wie oben beschrieben via "Fusion"? Mein Grundgedanke ist ähnlich wie MicroOp-Fusion, damit man das Zeugs vorne zusammen-merged und damit im Backend nicht mehr Ressourcen für die Ausführung verwenden muss.

-> 2*256bit werden zu 1*512bit zusammengelegt
-> 2/3/4*128bit werden zu 1*512bit zusammengelegt

In den Ausführungseinheiten sieht das dann wie eine 512bit Operation aus. Man muss es aber vorher zusammenlegen und nachher wieder auftrennen. Ist sicher nicht eine Low-Hanging Fruit und man kann das Problem lösen, indem man die SW auf 256b / 512b umbaut. Ich sehe aber dennoch einiges Potential.

[Exxtreme]

Ich glaube, um sowas tun zu können braucht's wiederum spezielle CPU-Operationen ala MMX/SSE.

[mksn7]

Könnte man die Anzahl Operanden nicht reduzieren? Wie oben beschrieben via "Fusion"? Mein Grundgedanke ist ähnlich wie MicroOp-Fusion, damit man das Zeugs vorne zusammen-merged und damit im Backend nicht mehr Ressourcen für die Ausführung verwenden muss.

-> 2*256bit werden zu 1*512bit zusammengelegt
-> 2/3/4*128bit werden zu 1*512bit zusammengelegt

In den Ausführungseinheiten sieht das dann wie eine 512bit Operation aus. Man muss es aber vorher zusammenlegen und nachher wieder auftrennen. Ist sicher nicht eine Low-Hanging Fruit und man kann das Problem lösen, indem man die SW auf 256b / 512b umbaut. Ich sehe aber dennoch einiges Potential.

Ich denke es ist nicht das gleiche 2 256bit Register statt einem 512bit Register zu lesen. Die zwei kleinen Register könnten ja irgendwelche sein, das eine große liegt auf jeden Fall schön beisammen. Ich möchte mich jetzt aber auch nicht in Spekulationen über die physikalische Implementierung von register files in Transistoren zu verstricken. Fühlt sich einfach komplizierter an :smile:

[basix]

Ja das Daten-Alignment hatte ich schon auf dem Radar, dass das evtl. schwierig wird. Aber evtl. wird mit 3nm ja das Transistor-Budget für ein entsprechendes Handling frei :D

[Der_Korken]

Wenn man eine 512bit-ALU so auslegen will, dass sie auch zwei beliebige 256bit-Operationen ausführen kann, dann ist es eigentlich nicht mehr eine ALU, sondern zwei. Mit anderen Worten: AMD müsste dazu die Anzahl der FP-Ports verdoppeln und deren Breite wieder halbieren. Das klingt für mich sehr unwahrscheinlich, denn dann müssten sie genau die Änderungen von Zen 5 wieder rückgängig machen, wo sie (scheinbar) am meisten investiert haben. Hätte AMD Pläne mehr FP-Ports zu verbauen, hätten sie das gleich getan und von Full-AVX512 erstmal die Finger gelassen.

[Gipsel]

Ja das Daten-Alignment hatte ich schon auf dem Radar, dass das evtl. schwierig wird. Aber evtl. wird mit 3nm ja das Transistor-Budget für ein entsprechendes Handling frei :DWird nicht passieren. Das ist vermutlich deutlich schwieriger, als Du Dir das vielleicht vorstellst.

Wenn Du 512bit Operationen sehen willst, muß der Programmierer AVX512 in den Compileroptionen anknipsen um einen entsprechenden Codepfad zu erzeugen (und seine Daten möglichst freundlich dafür organisieren). Dies sollte jetzt im Prinzip ohne Probleme möglich sein, da Zen5 anders als bei frühen intel Implementationen von AVX512 praktisch nicht langsamer werden kann, wenn das nur kurz zum Einsatz kommt (auch recht wenige Instruktionen im Mix bringen Performancevorteile, bei intel mußten es recht große Blöcke mit AVX512-Code sein [sonst wurde es wohl langsamer als mit AVX256]).

[basix]

Wenn man eine 512bit-ALU so auslegen will, dass sie auch zwei beliebige 256bit-Operationen ausführen kann, dann ist es eigentlich nicht mehr eine ALU, sondern zwei. Mit anderen Worten: AMD müsste dazu die Anzahl der FP-Ports verdoppeln und deren Breite wieder halbieren. Das klingt für mich sehr unwahrscheinlich, denn dann müssten sie genau die Änderungen von Zen 5 wieder rückgängig machen, wo sie (scheinbar) am meisten investiert haben. Hätte AMD Pläne mehr FP-Ports zu verbauen, hätten sie das gleich getan und von Full-AVX512 erstmal die Finger gelassen.

Wenn man die Instruktionen merged, braucht es eben nicht mehr Ports. Das wäre ja der Sinn des ganzen. Ob das ohne zusätzliche Instruktionen wie Exxtreme anmerkt funktionieren kann, weiss ich nicht. Und auch nicht genau, wie kompliziert oder gar realistisch das ganze ist. Aber jetzt hat man 384x 512bit (24kByte! ...oder 50% vom L1D) FP/Vektor-Registerfile und 2*512b ALUs. Beides sind relativ fette Ressourcen und werden nur zu einem Bruchteil von 128/256bit Befehlen ausgelastet. Wenn man diese mergen könnte, würde man Dark Silicon bei FP/Vektor um ein gutes Stück reduzieren. Und das bei Befehlen, die doch relativ häufig in typ. Code vorkommen. Von meiner Laien-Perspektive aus hört sich Instruction-Merging effizienter an als generell die Strukturen noch weiter zu vergrössern (breitere Scheduler, mehr Register Files, mehr Ports, mehr Load/Store). Dazu könnte man dadurch deutlich an Effizienz gewinnen. Beim y-Cruncher benötigen 128/256/512bit Instruktionen alle ~200W bei einem 9950X (http://www.numberworld.org/blogs/2024_8_7_zen5_avx512_teardown/#throttling). Die Performance steigt aber linear mit der Vektor-Breite. Das ist ein enormer Effizienz-Gewinn, welcher sich ziemlich schnell rechnen könnte.

Aber wie gesagt:
Prinzipiell ist das Problem auch via SW lösbar, wenn man halt generell die breiteren Vektor-Formate verwendet. Bei bestehender SW oder wenn SW-Entwickler wegen Intel bei Consumer-Apps AVX512 liegen lassen, wäre ein Boost bei schmaleren Vektoren gerne gesehen.

[mczak]

Hätte AMD Pläne mehr FP-Ports zu verbauen, hätten sie das gleich getan und von Full-AVX512 erstmal die Finger gelassen.
Das Problem mit mehr FP-Ports ist ja auch dass die extrem schwierig auszulasten sind. Die typische Latenz dieser FP-Befehle ist so um die 3 Zyklen - da muss man erst mal genügend Befehle finden die sich da auch schon mit nur 4 Ports ausführen lassen (die dürfen ja keine Abhängigkeiten haben von den Befehlen die die letzten 2 Takte gestartet wurden). Das geht bei den Int-Pipes einfacher weil da die meisten Befehle bloss 1 Zyklus Latenz haben.

[Gipsel]

Wenn man die Instruktionen merged, braucht es eben nicht mehr Ports.Das Mergen der Instruktionen merged aber nicht automagisch die Daten. Deswegen würde man mehr Ports (doppelt so viele) am Registerfile benötigen, was nicht realistisch ist.
Im Prinzip verlangst Du, daß AMD einen Autovektorisierer in Hardware vor den Vektoreinheiten verbaut und die dafür eventuell zusätzlichen nötigen Lade-, Kopier- und Shuffle-Vorgänge in den Instruktionsstream einfügt. Wie viel Rechenleistung schmeißt ein Compiler auf das Problem? Ist es realistisch, daß in Echtzeit hinzubekommen?

Also nochmal: Das ist bei der grob vorgegebenen Arbeitsweise der CPU (wir reden hier ja nicht von Transmeta oder so) nicht realistisch, weder doppelte Anzahl an Instruktionen und Registerports noch das in Hardware umzuordnen.
Prinzipiell ist das Problem auch via SW lösbar, wenn man halt generell die breiteren Vektor-Formate verwendet.Es ist die einzig realistische Option, ja.

[Orko]

Könnte man die Anzahl Operanden nicht reduzieren? Wie oben beschrieben via "Fusion"? Mein Grundgedanke ist ähnlich wie MicroOp-Fusion, damit man das Zeugs vorne zusammen-merged und damit im Backend nicht mehr Ressourcen für die Ausführung verwenden muss.

-> 2*256bit werden zu 1*512bit zusammengelegt
-> 2/3/4*128bit werden zu 1*512bit zusammengelegt



Die Anforderungen an ein "einfaches" Merging von AVX Instruktionen wären:
1) Die CPU muss im OoO-Window geeignete Befehle finden, z.B. zwei AVX256 Instruktionen
2) Diese müssen jeweils die gleiche (!) Rechenoperation auf den Daten durchführen damit gemerged werden kann*
3) Die Daten müssen voneinander unabhängig sein
4) Die Daten müssen etwa zeitgleich vorliegen
Es wäre z.B. ungünstig, wenn die "erste" AVX256 Instruktion so lange abwarten muss, bis die Daten der "zweiten" AVX256 Instruktion verfügbar werden, nur damit eine gemergte AVX512 Instruktion berechnet werden kann.

Ich schätze mal, die Wahrscheinlichkeit dass dies einfach mal so zufälligerweise im Instruktionsstrom eintritt ist sehr gering.
Die meisten solchen Fälle wird wohl der Compiler schon mergen.

* Zwei unterschiedliche Rechenoperationen erfordern zwei Ports wie oben bereits erklärt, mergen auf einen Port nur bei gleichen Rechenoperationen.

[Gipsel]

Die Anforderungen an ein "einfaches" Merging von AVX Instruktionen wären:
1) Die CPU muss im OoO-Window geeignete Befehle finden, z.B. zwei AVX256 Instruktionen
2) Diese müssen jeweils die gleiche (!) Rechenoperation auf den Daten durchführen damit gemerged werden kann*
3) Die Daten müssen voneinander unabhängig sein
4) Die Daten müssen etwa zeitgleich vorliegen
Es wäre z.B. ungünstig, wenn die "erste" AVX256 Instruktion so lange abwarten muss, bis die Daten der "zweiten" AVX256 Instruktion verfügbar werden, nur damit eine gemergte AVX512 Instruktion berechnet werden kann.
5) Die 256bit-Operanden-Paare müssen irgendwie noch jeweils gleichen ZMM(AVX512)-Register stehen. Das tun sie aber im Normalfall nur, wenn man AVX512-Befehle benutzt, um die da hinzubekommen.
Zen5 hat (genau wie schon Zen4) 512bit breite Einträge im Registerfile (wenn SSE/AVX benutzt, wird, bleiben 3/4 bzw. 1/2 leer). Mann kann keinem 512bit FMA-Befehl einfach sechs YMM (256bit) Quellregister (wie für 2 unabhängige 256bit Operationen) angeben, sondern nur drei ZMM (512bit) Register). Die Anzahl der maximal gleichzeitig gelesenen und geschriebenen Register ist strikt begrenzt. Jede Erweiterung ist sehr sehr teuer (kostet Stromverbrauch, massig Platz und begrenzt gegebenenfalls die Taktfrequenz).

[Skysnake]

Absolut. Dem ist nichts hinzuzufügen

[Zossel]

An der Firmware Front scheint es voran zu gehen:

https://www.phoronix.com/news/AMD-openSIL-September-2024

[Leonidas]

Nicht nur das, es zeigt auch auf den Release-Termin von Zen 6 hin:
- Q4/2026: openSIL für Zen 6 Venice
- Q3/2026: Release von Zen 6 Venice (ein Quartal vor openSIL, von AMD selber so ausgedrückt)
- Q2/2026: Release von Zen 6 Consumer (ein Quartal vor Venice, reine Annahme)

[HOT]

Würd ich auch so sehen. Bin mal gespannt, wann man die ersten OpenSIL-BIOSse sehen wird.

[fondness]

An der Firmware Front scheint es voran zu gehen:

https://www.phoronix.com/news/AMD-openSIL-September-2024

Schon nice, dass AMD jetzt selbst die Firmware auf Open-Source umstellen will.

[Nightspider]

Untergräbt Open Source nicht gewisse Sicherheitsaspekte?

Bin da nicht vom Fach und bitte um Erleuchtung.

Was sind denn alles die Vorteile?

[fondness]

Untergräbt Open Source nicht gewisse Sicherheitsaspekte?

Bin da nicht vom Fach und bitte um Erleuchtung.

Was sind denn alles die Vorteile?

Das exakte Gegenteil ist der Fall. Nichts ist sicherer als open source Software, denn nur dort kann man die Sicherheit auch tatsächlich überprüfen. Deshalb sind auch messenger wie Signal open source, das garantiert, dass es kein backdoor gibt.

[robbitop]

Komisch dass da die „Nichtskönner Hans und Franz“ plötzlich hilfreich sein sollen, die bei open source Treibern aber klaglos versagen ;)

Abseits des Sarkasmus stimme ich der Aussage aber zu. Finde es nur merkwürdig, weil das schon im Widerspruch implizit zu deinen mMn abfälligen Aussagen zu Contribution der Community zu den anderen Open Source Projekten stand. ;)

[fondness]

Komisch dass da die „Nichtskönner Hans und Franz“ plötzlich hilfreich sein sollen, die bei open source Treibern aber klaglos versagen ;)

Abseits des Sarkasmus stimme ich der Aussage aber zu. Finde es nur merkwürdig, weil das schon im Widerspruch implizit zu deinen mMn abfälligen Aussagen zu Contribution der Community zu den anderen Open Source Projekten stand. ;)

Haha, ich habe fast darauf gewartet, dass du drauf anspringst :D. Ich habe ja gesagt 99%. Du hast aber auch immer das eine Prozent dass sich auskennt und sicherstellt, dass die Open Source Software zB safe ist. Ganz davon abgesehen, dass es schon ein Unterschied ist, ob man open source Software "frei" entwickelt wie du dir das vorstellst, oder ob ich den source Code zur Verfügung stelle und damit eine Überprüfung ermögliche. Selbst wenn diese Überprüfung nicht stattfindet, wäre das Risiko viel zu groß dort irgendwelche Schweinerei zu machen ;-)