Zen 5 (3/4 nm, 2024)

[Leonidas]

3DC News-Übersicht zu "Zen 5" (https://www.3dcenter.org/news/amd-zen-5)


Derzeit relevante Gerüchte:
Performance-Gerüchte vom Februar 2021 (https://www.3dcenter.org/news/hardware-und-nachrichten-links-des-67-februar-2021)
big.LITTLE-Ansatz bei der APU "Stix Point" vom April 2021 (https://www.3dcenter.org/news/hardware-und-nachrichten-links-des-27-april-2021)

[basix]

Hier hätte ich zwei Anmerkungen:

Beim Zen 1 alike IPC Gain bin ich etwas skeptisch. Das wäre bombastisch verglichen mit Zen 4. Zen 1 hat in vielen Bereichen +50..70% zugelegt. Sollten es auch "nur" +40% sein wie anfangs von AMD angegeben wäre das extrem gut.
Big.Little wohl nur bei der APU. Finde ich soweit sinnvoll, da bei Server und Desktop das eher weniger vorteilhaft ist. Mobile kann bezüglich Akkulaufzeit davon profitieren, aber auch hier erwarte ich keine Quantensprünge.

[Der_Korken]

Es steht ja nicht dabei wie sich der Takt von Zen 5 verhalten wird. Wenn Zen 4 wirklich nochmal beim Takt nachlegen soll, könnte es bei Zen 5 wieder eine Regression von 5Ghz auf 4Ghz geben wie bei Bulldozer -> Zen 1. Das würde den IPC-Gewinn wieder etwas relativieren. Man kann aber in jedem Fall erwarten, dass Zen 5 das nächste große Redesign wird, so wie Zen 3. Zeitlich entspricht 2024 dem Abstand zwischen Zen 1 und Zen 3.

[HOT]

Hm die große Frage ist, ob der schon N3 ist, oder noch N5. Im Falle von N3 wird Zen5 noch recht weit weg sein und es besteht die Chance auf einen echten Zen4-Refresh vorher. (nicht wie XT und Warhol, welcher ja offenbar nichts weiter wird als ne Fertigungsumstellung)
Dass es nur 4 Little-Cores sind spricht dafür, dass diese anders als bei Intel, reines Powermanagement sind. Und ich würde auch sagen, dass das nur für Mobil gemacht wird.

[mboeller]

Hier hätte ich zwei Anmerkungen:
Beim Zen 1 alike IPC Gain bin ich etwas skeptisch. Das wäre bombastisch verglichen mit Zen 4. Zen 1 hat in vielen Bereichen +50..70% zugelegt. Sollten es auch "nur" +40% sein wie anfangs von AMD angegeben wäre das extrem gut.


die 40% sind gegenüber Zen2, also "nur" ca. 20% gegenüber Zen3

upps... hab die Tabelle falsch verstanden

[Nightspider]

Gerüchte sprechen ja davon das AMD bei Zen5 alles technisch machbare verwenden will.
Für mich ist Zen5 auch ein heißer Kandidat für neue Packaging Technologien, teilweise ausgelagerten und gestacktem Cache usw.

Ich rechne auch mit 4 oder 3nm. Je nachdem wie schnell Zen5 kommt.

[SKYNET]

Hier hätte ich zwei Anmerkungen:

Beim Zen 1 alike IPC Gain bin ich etwas skeptisch. Das wäre bombastisch verglichen mit Zen 4. Zen 1 hat in vielen Bereichen +50..70% zugelegt. Sollten es auch "nur" +40% sein wie anfangs von AMD angegeben wäre das extrem gut.
Big.Little wohl nur bei der APU. Finde ich soweit sinnvoll, da bei Server und Desktop das eher weniger vorteilhaft ist. Mobile kann bezüglich Akkulaufzeit davon profitieren, aber auch hier erwarte ich keine Quantensprünge.



big/little wird wohl bei AMD eher so laufen, das alles die gleichen kerne sind, aber maybe die hälfte im takt und leistungsaufnahme massiv beschnitten... halte ich eh für sinnvoller als zb. abgespeckte kerne mit weniger cache usw. zu machen.

[Skysnake]

Ist der Code Name eigentlich schon öffentlich bekannt?

[Der_Korken]

big/little wird wohl bei AMD eher so laufen, das alles die gleichen kerne sind, aber maybe die hälfte im takt und leistungsaufnahme massiv beschnitten... halte ich eh für sinnvoller als zb. abgespeckte kerne mit weniger cache usw. zu machen.

Nein, das wäre total sinnlos, weil die kleinen Kerne dann genauso viel Chipfläche brauchen wie die großen. Da kann man sie auch gleich als große Kerne laufen lassen und lieber den Gesamtverbrauch der CPU deckeln, wenn der sonst zu hoch wird.

[Leonidas]

Ist der Code Name eigentlich schon öffentlich bekannt?

Irgendein Twitterer war sich ziemlich sicher, das es "Turin" wird.

[registrierter Gast]

Nein, das wäre total sinnlos, weil die kleinen Kerne dann genauso viel Chipfläche brauchen wie die großen. Da kann man sie auch gleich als große Kerne laufen lassen und lieber den Gesamtverbrauch der CPU deckeln, wenn der sonst zu hoch wird.
Das macht dann Sinn, wenn in mindestens einem Core Fertigungsfehler sind und diese nicht auf voller Leistung laufen können. Das ergibt weniger Ausschuss von ansonsten guten CPUs.

[Skysnake]

Irgendein Twitterer war sich ziemlich sicher, das es "Turin" wird.

Ok danke, dann weiß ich jetzt wie die Informationslage ist

[Zossel]

big/little wird wohl bei AMD eher so laufen, das alles die gleichen kerne sind, aber maybe die hälfte im takt und leistungsaufnahme massiv beschnitten... halte ich eh für sinnvoller als zb. abgespeckte kerne mit weniger cache usw. zu machen.

Gibt es mittlerweile brauchbare Algorithmen für Big-Little Scheduler die für Desktop und Server taugen?

Hier mal ein Beispiel was so passieren kann wenn Datenverarbeitung zwischen Cores bzw. Caches hin und her wandert: https://blog.cloudflare.com/speeding-up-linux-disk-encryption/

Insofern könnte ein Ansatz der einen Little Core die Caches des Big Cores nutzen lässt die Anforderungen an die Trefferquote von /dev/glaskugel, was jeder Scheduler braucht, erheblich senken.

[Thunder99]

Pionier Arbeit mach ja Intel. Daher kann man schon erwarten, dass es laufen wird. Ich meine ein Prozess der im Hintergrund läuft oder im Vordergrund bekommt dann die entsprechenden Kerne zugewiesen. Stelle mir das nicht so wahnsinnig kompliziert vor.

Könnte mir auch bei den Kernen vorstellen, dass es dann so aussieht:
X Zen 5 Kerne + X Next Gen Jaguar Kerne

Aber bitte nur bei einer APU/Mobile. Desktop sehe ich es als nicht zielführend an (lasse mich aber gerne überraschen und vom Gegenteil überzeugen :wink:)

[Windi]

AMD hat doch auch so ein Patent, wo ein großer und ein kleiner Kern zusammen den gleichen Cache nutzen.

Kann man ja ruhig überall einbauen, stromsparen kann man in fast allen Bereichen benötigen.
Das bischen Chipfläche sollte nicht viel ausmachen, notfalls deaktiviert man den kleinen Kern halt.
Bei den APUs "verschwendet" AMD auch viel Platz für Grafikeinheit und IO-Kram.
Bei den Chiplets hat man hingegen einen riesigen L3 Cache.

Auf jeden Fall besser, als ein dutzend verschiedene Masken zu benötigen.

[Der_Korken]

AMD hat doch auch so ein Patent, wo ein großer und ein kleiner Kern zusammen den gleichen Cache nutzen.

Kann man ja ruhig überall einbauen, stromsparen kann man in fast allen Bereichen benötigen.
Das bischen Chipfläche sollte nicht viel ausmachen, notfalls deaktiviert man den kleinen Kern halt.


Das erinnert ein wenig an Bulldozers CMT-Design: Ein Modul mit einem fetten und einem kleinen INT-Kern, geteiltem L2 und geteilter FPU. Den fetten INT-Kern samt fettem Decoder und FPU schaltet man ab wenn nicht benötigt. Sobald FP gerechnet wird, wird die FPU kurz zugeschaltet und sobald hohe Last anliegt, wird der Prozess an den großen INT-Kern weitergereicht. Daten liegen ja schon im inklusiven L2, nur die Registerinhalte müssen rüberkopiert werden.

Allerdings passt das nicht zu dem 2:1-Verhältnis, welches spekuliert wurde (es sei denn, ein Modul besteht aus zwei großen und einem kleinen INT-Kern :freak:). Außerdem man wäre gezwungen die kleinen Kerne überall zu verbauen, wenn man das Kern-Design einheitlich verwenden will. Und die kleinen Kerne müssten auf derselben Takt-Domäne laufen (können) wie die großen Kerne, was eventuell effizienztechnisch nicht so gut ist.

[Leonidas]

"Strix point adopts the hybrid architecture of zen5+zen4 and introduces a new cache. The desktop version does not know if this mode will be adopted, but it is certain that the same 3nm will be used."
https://twitter.com/Broly_X1/status/1397062963215831043

Ah yes. Indeed there will be a L4 cache in Zen5 Strix Point which I expect to work as SLC (System Level Cache).
The littles are called Zen4D cores and are based on Zen4 cores.
https://twitter.com/Bullsh1t_buster/status/1397066029335945216

[HOT]

Also:

Vermeer -> (Warhol) -> Raphael -> Zen5 (weiss einer den Codenamen?)
Cezanne -> Rembrandt -> Phoenix -> Strix Point


Little Zen4 kerne? Dann muss Zen5 ja übelst riesig werden! Schon Zen4 wird doch sicherlich erheblich breiter werden.

[Platos]

Zen4 nutzt doch aber auch 5nm und Zen5 ja angeblich 3nm und die DIEs sind doch ohnehin schon ziemlich klein.

[Der_Korken]

Ah yes. Indeed there will be a L4 cache in Zen5 Strix Point which I expect to work as SLC (System Level Cache).
The littles are called Zen4D cores and are based on Zen4 cores.
https://twitter.com/Bullsh1t_buster/status/1397066029335945216

Was ist denn ein System Level Cache? Ein gemeinsamer Last-Level-Cache für mehrere Komponenten (CPU, GPU)?


Little Zen4 kerne? Dann muss Zen5 ja übelst riesig werden! Schon Zen4 wird doch sicherlich erheblich breiter werden.

Es müssen ja keine vollen Zen-4-Kerne sein. Halbierter L2, halbierte FPU-Breite, ein oder zwei ALUs weniger, etwas weniger Die-Space für BTB und µOp-Cache ... alles möglich.

[HOT]

Stimmt. Eine 128Bit-Variante von Zen4 und/oder halbierte L2/3-Caches wäre sicherlich noch mals kleiner.



Vielleicht ist ein System-Level-Cache auch ein Infinity Cache auf eigenem Chiplet oder gar auf dem Interposer.

[basix]

Zen 4D: 3nm, 4 Core-CCX und auf 1MB/Core gestutzter L3$ und gemeinsam genutzter L4$/System Level Cache wäre mein Tipp für geringste R&D Arbeit und geringe Flächenanforderungen. Das Zen 4 Chiplet soll ja ca. 70mm2 gross sein. Nimmt man GMI Links usw. weg, landet man bei 60mm2. Nur 4 Cores = 30mm2. Ca. 1/2 dieser Fläche = L3$ --> 1MB = 30 - 15*3/4 = 19mm2. Das noch nach 3nm geshrinkt -> 12...15mm2. Das bekommt man locker in ein Chiplet ;)

Das hat den Vorteil, dass man Zen 4 Kerne ohne Designanpassungen hinbekommt und von der Software her auch nicht anders behandeln muss (bis auf den gestutzten L3, der aber durch den L4 kompensiert werden würde). Halbierte FPU-Breite und halbierter L2$ wären aber zusätzlich denkbar.

[Tarkin]

Zen 5 kommt eventuell sogar schon Ende 2023... nachdem "Strix Point" (Zen 5 APU) wohl für Anfang 2024 geplant ist...

https://twitter.com/Broly_X1/status/1397391953201876994

[Nightspider]

Wenn wir in den kommenden 2,5 Jahren Zen 4 mit 5nm und Zen 5 mit 3nm bekommen werden das noch ein paar richtig heftige Jahre und Zen 3 wird bald alt aussehen.

Wer hätte so eine Entwicklung vor 2 Jahren erwartet?

Ich kann mich noch an den Broadwell und Skylake Release erinnern wo immer gesagt wurde das bei der IPC nicht mehr viel zu holen sei und die ST Leistung stagniert. :)

Bin mal gespannt ob Intel mit ihren verkorksten Fertigungsprozessen konkurrieren kann.

Am Ende sehen wir Zen5 in 3nm bevor Intel 7nm in den Desktop Bereich bringt.

[Duplex]

Die IPC Sprünge die AMD leistet sind bei Intel nicht so einfach möglich, AMD hat hier durch der neuen Architektur viel mehr Potential als Intel mit ihren 30 Jahren alten P6 Aufguss und dabei hat AMD nur ein Bruchteil der Entwicklungskosten von Intel.

[ChaosTM]

AMD hat gerade erst zu Intel aufgeschlossen. Bei dem Rückstand waren diese riesigen Sprünge relativ "leicht" zu erreichen. In der Tonart geht es garantiert nicht mehr weiter.
Jetzt kommen die 5 bis maximal 10% pro Jahr IPC Sprünge. x86 ist ziemlich ausgereizt glaub ich.

add.: würde mich freuen wenn ich mich da täusche, aber..

[Denniss]

spätestens mit Zen+ war die IPC egalisiert, da fehlte nur einiges an Takt um das besser ausnutzen zu können.

[davidzo]

AMD hat gerade erst zu Intel aufgeschlossen. Bei dem Rückstand waren diese riesigen Sprünge relativ "leicht" zu erreichen. In der Tonart geht es garantiert nicht mehr weiter.
Jetzt kommen die 5 bis maximal 10% pro Jahr IPC Sprünge. x86 ist ziemlich ausgereizt glaub ich.

add.: würde mich freuen wenn ich mich da täusche, aber..

Da irrst du dich aber gewaltig. Genau diese 5% Verbesserungen hatte AMD auf der Roadmap als sie mit Bulldozer weit abgeschrieben standen. Der Schock davon sitzt noch so tief dass man sich da sicherlich nicht so bald wieder hin begibt.

5% ist was was eine refresh Generation ausmacht, ein neues Stepping das ein bisschen besser taktet. Da sind keine Chip Designer dran beteiligt, das macht das Manufacturing schon selbst. Eine neue Architektur mit 5% würde man einfach während der Konzeptphase und FPGA testing schon als zu wenig ambitioniert stoppen.

Für Chip-Architekten gibt es nur 4-5 wichtige Standorte auf der Welt. Und an jedem gibt es irgendwo CPUteams, GPU Teams und mittlerweile AI Startups.
Die GPU Leute reden von 20x, 50x im Vergleich zu CPUs und 1,5x, 2x bis 5x speedup mit der neuen Architektur im vergleich zur alten (Cuda, int8, bfloat16, sparsity etc.)
Die AI Startups reden plötzlich von 100x im Vergleich zu CPUs und 5-10x im vergleich zu GPUs und wollen ihre Architektur mit jedem Schritt mindestens verzehnfachen.

Wenn du von der einen Firma zur anderen wechselst, dann nimmst du etwas von diesem Mindset mit. Kein Wunder das Zen gerade dann entstanden ist als der Aufwind durch HPC GPUs durch die Industrie ging. Als Jim Keller, Mike Clark und Raja Koduri ihre "gang" gebildet haben, da sind viele AMD Ingenieure mit ihrem 5% Ziel "wir fixen Bulldozer nochmal" einfach gegangen oder versetzt worden. Man braucht Leute die auch aus Fehlern lernen, sich nicht an ihre Assumptions klammern sondern die physikalischen Grundlagen hinterfragen.

Das Power Management von Zen ist von nem Typen gemacht der vorher nvidia Maxwell und Automotive ai chips geprägt hat. Kellers und Lisas Hauptaufgabe war die Leute auszufiltern die nicht an Zen bzw. den 40% IPC Catchup geglaubt haben und das kleine Kernteam vom lethargischen Rest der Firma abzuschirmen bis Resultate da sind. Wenn sich Erfolg einstellt, dann zieht das wohl auch eine Mehrzahl der Leute wieder mit und unterstützt den Kurs.

Die aktuellen Macher bei AMD, das sind first principle Enineers, genau wie bei Tesla.
Das aktuelle AMD hat ja gerade Erfolg mit dieser Strategie und wird sicher nicht wieder irgendwelche 5-8% IPC Ziele auf die interne Roadmap schreiben. Dann kann man gleich wieder in Resignation versinken.

Wieder mal sehr guter Journalismus von Ian: https://www.anandtech.com/show/16709/an-interview-with-tenstorrent-ceo-ljubisa-bajic-and-cto-jim-keller

[Zossel]

Die aktuellen Macher bei AMD, das sind first principle Enineers, genau wie bei Tesla.
Das aktuelle AMD hat ja gerade Erfolg mit dieser Strategie und wird sicher nicht wieder irgendwelche 5-8% IPC Ziele auf die interne Roadmap schreiben. Dann kann man gleich wieder in Resignation versinken.

Und wie viele Projekte gibt es die so vor gegangen sind von denen man nie was gehört hat weil sie gescheitert sind?

Success Storys sind toll, aber nur die werden weitererzählt. Das ist so ähnlich wie das die Geschichte von den Siegern geschrieben wird.
Also immer deine eigene Wahrnehmung kritisch hinterfragen und hinterfragen was wohl nicht erzählt wird.

Ach ja, und Tesla soll endlich mal richtige Stückzahlen liefern und verkaufen, vernüftige Gewinne machen und die Autos sollten auch mal die Features haben von den Elon Musk immer redet.

[ChaosTM]

@davidzo - dein Wort in Gottes Ohr -
Nur lassen sich solche Sprünge nicht auf Dauer halten. Irgendwann ist Schluss. Vielleicht haben wir ja noch ein/zwei Gens mit 20+%.

[HOT]

https://www.techpowerup.com/283325/amd-files-patent-for-its-own-x86-hybrid-big-little-processor

AMD wählt eine relativ billige Lösung. MMn sind die 4 little-Cores reines Powermanagement, AMD verfolgt hier offensichtlich nicht die Strategie, die Intel ab ADL verfolgt. Und die little-Cores übernehmen alle Verwaltungs- und I/O-Aufgaben. Was ja klar ist, da die Big-Cores ja nur anspringen sollen, wenn es was zu bearbeiten gibt ;).

[Lehdro]

AMD wählt eine relativ billige Lösung.
Du meinst nicht billig, sondern einfach & günstig. Während Intel den Verbrauch der BigCores im MT mit einer Masse an Littles kaschieren/erschlagen will, dreht AMD das ganze Konzept auf Links: Leistung kommt von den Big Cores, die Littles sind eher nur für das "Kleinzeug" da. Kann man sich aber auch nur leisten wenn die eigenen Bigcores nicht so versoffen sind.

[mboeller]

...Kann man sich aber auch nur leisten wenn die eigenen Bigcores nicht so versoffen sind.

und anscheinend auch bleiben

[HOT]

Ok, billig war nicht wertend gemeint ;). Man könnte auch fast klassischer big.LITTLE-Ansatz sagen.

[Lehdro]

Ok, billig war nicht wertend gemeint ;). Man könnte auch fast klassischer big.LITTLE-Ansatz sagen.
Ja. AMD scheint da den ARM weg zu gehen, auch Apple scheint ja lieber die Bigcores skalieren zu wollen um Leistung zu bekommen und eben nicht die Littles zu vervielfachen. Nur Intel geht derzeit diesen Weg. Bin gespannt wo uns das am Ende hinführt...

[davidzo]

@davidzo - dein Wort in Gottes Ohr -
Nur lassen sich solche Sprünge nicht auf Dauer halten. Irgendwann ist Schluss. Vielleicht haben wir ja noch ein/zwei Gens mit 20+%.


Natürlich lassen die sich auf Dauer halten, das sieht man ja am Industrietrend, der eben nicht Intel single Digit Improvements folgt. Intels Single digit Zuwächse sind eben nicht "die norm" selbst wenn AMD da ne zeitlang selber dran geglaubt hat. ARM, Apple, RiscV, etc. liefern seit Jahrzehnten double digit performance improvements mit jeder generation und wenn man die Chip Industrie als größeren Komplex fasst must du auch GPUs, Tensor Cores, AI Chips und Asics etc. dazuzählen und da geht es um multiples, nicht einstellige prozente.
Und bei GPUs ist der Zuwachs gen on gen auch eher zwischen 50 und 100%, siehe RDNA zu RDNA2, bei AI chips noch extremer.
CPUs entstehen nicht im luftleeren Raum, das sind auch nur chips die software ausführen. Und wenn das was man traditionell CPU genannt hat nicht mehr skaliert, dann baut man halt andere chips die software ausführen die skalieren. Mir egal wie die man dann nennt, für mich sind das weiterhin Prozessoren. Ich glaube Pat Gelsinger ist das auch sehr klar dass traditionelle CPUs sonst in der Bedeutungslosigkeit verschwinden.

Diese single Digit Stagnation für die Chipindustrie eben kein natürlicher Zustand, sondern ein Folge eines Marktmonopols und dahergehender Transformation von einer Firma in der die Engineers den Ton angaben zu einer in der Business Development am meisten Gewicht hat.
Das ist nun glücklicherweise für uns alle vorbei, jetzt kann wieder Normalität einkehren.

Ich kanns echt nicht mehr hören, seit den 80ern erzählen immer wieder Leute von Grenzen der Skalierung, Diminishing Returns etc und es gibt tatsächlich noch viele die immerwieder daran glauben. Langsam muss man das Muster doch durchschaut haben? Jim Keller meinte in nem Interview jedenfalls dass er aufgegeben hat sich solche Argumentationen anzuhören oder solche Diskussionen zu führen und lieber mit den Leuten baut die willig sind. Die Ergebnisse kennen wir ja.

Es gibt immer noch ein zwei Gens mit 20%, weiter können wir halt nur noch nicht gucken.

[HOT]

Na ja, bei den Intels ist das aber ja auch nur z.T. richtig, da die ja lange Tick/Tock gemacht haben. Wenn man die Sprünge von Sandy auf Haswell und dann wiederum auf Skylake sieht, sind die schon ordentlich. Natürlich fehlte da dennoch mangels Konkurrenz etwas die "Motivation" gewagte Sachen zu machen. Wie gesagt bin ich davon überzeugt, dass wir jetzt Tiger Lake 4/8 für 500€ im Desktop hätten, wenn AMD den Sprung nicht gemacht hätte. Mit der Erweiterung auf 6 und dann auf 8 Kerne wurden ja Sachen möglich, die wir ohne AMD überhaupt nicht gesehen hätten. Wenn man sieht, was möglich war mit einem Skylake Core beim 10900k vs. einem 6700k damals, ebenfalls 14nm, das ist schon gewaltig.
Anzeichen dafür, dass die Architekturen neuer wären, sehe ich jedoch nicht. Cannonlake wäre ein 10nm Skylake geworden, Icelake ist offenbar nicht mal 1 Jahr verspätet und Tigerlake dürfte schon so aussehen wie geplant und wäre auch nach früheren Planungen 2020 gelauncht.

Alder Lake und Raptor Lake hingegen dürften komplette Neuschöpfungen sein, da die ursprüngliche Planung hier sicherlich 7nm vorsah. Atom ist halt der Notnagel.

[amdfanuwe]

Es gibt immer noch ein zwei Gens mit 20%, weiter können wir halt nur noch nicht gucken.
Hängt doch vom Workload ab. Den muß man analysieren und kann dann mit entsprechenden Einheiten optimieren.
FPU, Cache, MMU, MMX, Audio, Video, SSE, AVX, Kryptobeschleuniger, GPU Computing und jetzt RT, DLSS, ML bzw. AI Unterstützung.
Bei manchen Aufgaben lassen sich nur noch mit hohem Aufwand die Leistung steigern, bei anderen Problemen ist man erst am Anfang und kann leicht die Performance steigern. Im Misch sinds dann vielleicht 20% mehr IPC.

[Der_Korken]

Bei ST-Workloads sehe ich durchaus "Grenzen der Skalierbarkeit". Um hier eine gute Skalierbarkeit zu haben, müsste der Takt der Schaltungen bzw. die Schaltgeschwindigkeit immer weiter exponentiell steigen, so wie es in der Prä-3Ghz-Ära vielleicht noch der Fall war. Einen Kern breiter zu bauen verpufft schlimmstenfalls komplett an harten Abhängigkeiten zwischen Instruktionen, die sich nur dadurch schneller abarbeiten lassen, indem sie schneller durch die Pipeline laufen. Da ST-Leistung immer noch gefragt ist, wird auch versucht sie weiterhin zu steigern durch mehr ALUs, größere Queues, Registerfiles, Caches, usw. Aber das Problem, dass einzelne Instruktionen dadurch nicht schneller durch die Pipeline laufen, bleibt bestehen und könnte in gewisser Weise als obere Schranke für die maximal mögliche ST-Leistung gesehen werden unter der Annahme, dass man 100% Cache-Hitrate und 100% Branch-Prediction erreicht.

Mal ein paar Zahlen in den Raum geworfen:
Athlon 64 Clawhammer: 106 Mio. Transistoren pro Kern
Core 2 Conroe: 145. Mio. Transistoren pro Kern
Sandy Bridge: 290. Mio. Transistoren pro Kern (allerdings inkl. iGPU)
Haswell: 350 Mio. Transistoren pro Kern (inkl. iGPU)
Zen 3: 520 Mio. Transistoren pro Kern (chiplets only)

Zu Willow Cove gibt es keine offiziellen Zahlen, aber die sehen auf Die Shots nochmal deutlich größer als Zen3-Kerne aus.

Man kriegt also schon mehr Leistung raus, aber mehr Kerne nebeneinanderzustellen skaliert um Welten besser, wenn man diese ausgelastet bekommt. Sonst hätte man ja nie auf Multicore gesetzt. Die Little Cores müssen mehr Leistung pro Watt und Fläche bieten, sonst würde man das Design nicht durch zwei Arten von Kernen verkomplizieren. Allerdings sind die kleinen Kerne nur auf einem geringeren absoluten Level effizienter. Hohe absolute Leistung in einem Kern ist halt teuer erkauft.

Ich selber hatte übrigens auch geglaubt, dass es nach Skylake auch weiterhin nur im Schneckentempo weitergeht bei der ST-Leistung, weil weitere ST-Leistung unverhältnismäßig teuer ist und man nicht gewillt ist z.B. auf 50% der Kerne zu verzichten, nur damit diese dann 10-20% schneller sind. Angesichts der mittlerweile verfügbaren IPC-Sprünge durch AMD und vor allem Apple habe ich mich aber "gerne" geirrt :tongue:.

[HOT]

Cove ist schon ne ordentliche Weiterentwicklung und genau der richtige Ansatz, die Leistung weiter zu erhöhen. Intel hat offenbar eher Probleme damit, die richtige Cache-Topologie/Organisation (vielleicht auch zusammenhängend mit dem Prozess, keine Ahnung) hinzubekommen, was aber eigentlich nur ein Luxusproblem ist. Hinderlich ist hier eher, dass die Cove auch mit 10nm zuviel fressen und weiterhin sehr viel Fläche brauchen. Also muss man sich mit dem Gracemont-Trick behelfen. Offenbar hatte man da ne Hardwarescheduler-Entwicklung noch in der Hinterhand, die da jetzt temporär hilft. Aber es kann durchaus sein, dass man mit 7nm dann wieder zurück zu den big-Cores findet und eine ähnliche big.LITTLE-Lösung präsentiert wie AMD oder Apple.

Intel hat offenbar keine rechte Antwort auf Zen5, was ja das Marketingstatement auch nahelegt, die Zen5 und Mx als problematisch einstufen. Das dürfte beides in eine ähnliche Richtung gehen, supermassive Cores, die deine Transistorzahl pro Core massiv in die Höhe treiben werden dank N3. Offenbar plante aber Intel bis Lunar-Lake eher mit cove-Optimierungen und Erweiterungen (Lunar Lake ist dann ja eine weitere 7nm-Stufe).

[Skysnake]

Wieso hat Intel dem nichts entgegen zu setzen? Mit Sapphire Rapids und HBM wird das schon interessant. AMD hat da aktuell kein Äquivalent. Und auch 60 Cores pro Chip sind nicht schlecht, wenn das nicht mit AVX512 und zwei pipes kombiniert wird.

Am Ende muss man aber schauen, was hinten bei raus kommt. Also sowohl was Perf/$ als auch Perf/W raus kommt.

[Nightspider]

Das Problem für Intel wird vor allem das sich Intel 10nm und TSMC 3nm zeitlich sehr nahe kommen.

Wenn bei Intel nur noch ein großes Problem auftaucht kann es passieren das 3nm eher auf dem Massenmarkt ist als Intel 7nm bringen kann.

Angeblich soll Zen5 in 3nm ja schon 12-15 Monate nach Zen4 kommen, da Zen4 sich verspätet hat.

RGT sagt ja auch das AMD bei Zen5 vieles umkrempeln und jeden heißen scheiß verwenden will an dem man so die vielen Jahre gearbeitet hat. (Stacking in Richtung FanOut Wafer Level Packaging? Eventuell werden die Chiplets (incl io und Cache) direkt miteiner verbunden ->kürzere Wege, bessere Latenzen, bessere Energieeffizienz,höhere Bandbreite, vielleicht ebenfalls mit HBM2e/HBM3 direkt gestacked)

[HOT]

Wieso hat Intel dem nichts entgegen zu setzen? Mit Sapphire Rapids und HBM wird das schon interessant. AMD hat da aktuell kein Äquivalent. Und auch 60 Cores pro Chip sind nicht schlecht, wenn das nicht mit AVX512 und zwei pipes kombiniert wird.

Am Ende muss man aber schauen, was hinten bei raus kommt. Also sowohl was Perf/$ als auch Perf/W raus kommt.
Es ging hier um weit in der Zukunft, 23/24.

Nightspider
Jo Zen5 soll wohl sehr fett werden, so fett, dass (ein abgespeckter) Zen4 als little-Cores eingesetzt wird.

Die Apple Cores sind ja jetzt schon relativ fett oder nicht? Da kommt sicherlich noch SMT hinzu mMn.

[Skysnake]

Ja ist noch ne Weile hin, aber Anschreiben sollte man die Ko Konkurrenz nie.

Hochmut kommt vor dem Fall...

[CrazyIvan]

Bei ST-Workloads sehe ich durchaus "Grenzen der Skalierbarkeit".
[...]
Ich selber hatte übrigens auch geglaubt, dass es nach Skylake auch weiterhin nur im Schneckentempo weitergeht bei der ST-Leistung, weil weitere ST-Leistung unverhältnismäßig teuer ist und man nicht gewillt ist z.B. auf 50% der Kerne zu verzichten, nur damit diese dann 10-20% schneller sind. Angesichts der mittlerweile verfügbaren IPC-Sprünge durch AMD und vor allem Apple habe ich mich aber "gerne" geirrt :tongue:.
QFT

[amdfanuwe]

In dem Interview bei Anandtech sagt Jim Keller:
(IC:)I think at one point, you said most compute happens on a couple of dozen op-codes. Am I remembering that correctly?

JK: [Arguing about instruction sets] is a very sad story. It's not even a couple of dozen [op-codes] - 80% of core execution is only six instructions - you know, load, store, add, subtract, compare and branch. With those you have pretty much covered it.

Ich frage mich nun ob man den Prozessor nicht deutlich verschlanken, flexibler gestalten könnte, wenn die restlichen 20% oder auch nur 10% der selten benötigten Funktionen über eine FPGA Einheit statt den aktuellen Fixed Function Einheiten realisiert?

[Gipsel]

Ich frage mich nun ob man den Prozessor nicht deutlich verschlanken, flexibler gestalten könnte, wenn die restlichen 20% oder auch nur 10% der selten benötigten Funktionen über eine FPGA Einheit statt den aktuellen Fixed Function Einheiten realisiert?Ich weiß nicht, was Leute immer mit FPGAs haben (vermutlich ein Mißverständnis). Für wirklich seltene Sachen hat man die µcoded Instruktionen. Allgemein sind FPGAs zur Abbildung eines Befehlssatzes denkbar schlecht geeignet und immer langsamer und stromfressender als fixed function.

[amdfanuwe]

Allgemein sind FPGAs zur Abbildung eines Befehlssatzes denkbar schlecht geeignet und immer langsamer und stromfressender als fixed function.
Dafür sind sie flexibel und können auf die Aufgabe optimierte Funktionen nachbilden. Ob sie dann noch langsamer und stromfressender als mit µOps nachgebildeten Funktionen sind, ist halt noch die Frage.
Wenn ein paar selten benötigte Fixed Function dafür rausfliegen könnte das gesamte Design eleganter und schlanker werden.
Das FPGA soll ja auch nicht den Befehlssatz abbilden sondern erweitern. Jedes Programm kann dann seine eigene "Befehlserweiterung" ausführen anstatt mit den vorgegebenen Befehlen mühsam die gewünschte Funktion zusammenzubauen.
(Kann mich noch daran erinnern auf dem Z80 Mul und Div in Assembler programmiert zu haben. War nicht schnell.)
Anstatt den Platz mit kaum benutztem AVX512 zu vergeuden, scheint mir stattdessen ein FPGA Modul sinnvoller.
FPGA heißt ja nicht nur low Level Logik, da können ja durchaus wesentliche Fixed Funktion verbaut sein, die sich dann flexibel verwenden lassen.

[mboeller]

so was in der Art gab es schon mal. Stretch.Inc hatte eine CPU mit configurable logic gebaut. Das hat sich aber, soweit ich mich erinnere nicht durchgesetzt. Auf die schnelle habe ich nur diesen Link gefunden:

https://www.eetimes.com/configurable-processors-as-an-alternative-to-fpgas/

https://de.wikipedia.org/wiki/Stretch_(Unternehmen)

[Brillus]

so was in der Art gab es schon mal. Stretch.Inc hatte eine CPU mit configurable logic gebaut. Das hat sich aber, soweit ich mich erinnere nicht durchgesetzt. Auf die schnelle habe ich nur diesen Link gefunden:

https://www.eetimes.com/configurable-processors-as-an-alternative-to-fpgas/

https://de.wikipedia.org/wiki/Stretch_(Unternehmen)

Zynq fällt mir in der Richtung ein aber das ist ja dickes Array, zumindest wo ich es kenne für extra IO zu implementieren.

Also FPGA in der CPU finde ich nicht sinnvoll. Kommt ja schon die Frage wie mit Scheduling handeln für jeden Context switch das FPGA neu laden.

[amdfanuwe]

Das hat sich aber, soweit ich mich erinnere nicht durchgesetzt.
Ebensowenig wie sich IA64, Transputer und viele andere nicht durchgesetzt haben. Deswegen gebe ich dem ganzen auch nur eine Chance, wenn es fest in einem X86 kompatiblem Prozessor mit entsprechender Verbreitung auf dem Markt kommt.
Bei AVX512 ist auch noch fraglich, ob sich das mal durchsetzen wird.

Zynq fällt mir in der Richtung ein
https://www.xilinx.com/products/silicon-devices/soc/zynq-7000.html
Den hab ich mal auf einem NI System unter Labview programmiert.
https://www.ni.com/de-de/shop/compactrio.html
Geile Sache. Messdatenerfassung und Decoder auf dem FPGA implementiert, der schwache ARM hat dann die Daten über Ethernet zum PC geschaufelt der die Anzeige erledigte. Für das Decodieren der Daten wäre der ARM Kern zu langsam gewesen, funktionierte nur auf dem FPGA in Echtzeit.
Ebensogut kann man auch Funktionen im FPGA unterbringen, die dann vom ARM aufgerufen werden und dadurch die Sache wesentlich beschleunigen.

Beim sceduling den FPGA neu laden wird zu lange dauern und wird auch nicht bei allen Tasks benötigt. Auch kann der FPGA mehrere Subfunktionen parallel halten. Da werden wohl andere Mechanismen benötigt um die Ressource zu handeln als simples sceduling. Im Normalfall läuft ja auch nur eine Applikation, die einen eigenen coder oder sonstigen Beschleuniger laufen hat.

Edit:
Bin mal gespannt, ob nach der XILINX Fusion etwas ähnliches wie der Zynq mit ZEN Cores kommt.

[HOT]

https://www.3dcenter.org/news/hardware-und-nachrichten-links-des-2122-august-2021

Vielleicht ist Strix Point auch die komplette Desktop-Serie. Ich sehe nicht, warum man hier noch ein Fass aufmachen sollte, wenn das eh schon Chiplets sind.

"Granite Ridge" ist ja offensichtlich ein anders gelagerter Codename. Das CCD als Solches vielleicht?

[Nightspider]

Eventuell schrumpft man das Compute Die auch in der Größe, so das man trotz schlechteren Yields auf den neuesten Prozess aufspringen kann, so wie Apple es jetzt jahrelang tat.

Ohne IO Anteil könnte man so ein (beispielsweise) 60mm² Compute Die im frischen 3nm Prozess eventuell noch mit einem RDNA3 GPU-Chiplet im 3nm Prozess kombinieren.

Intel will ja auch zeitig auf 3nm springen aber erst im HPC Segment, wenn mich mein Gedächtnis nicht täuscht. Wenn AMD im mobilen Segment zeitig mit 3nm Produkten Druck aufbauen kann, bevor Intel im mobilen Bereich auf 3nm schwenkt, könnte man weiter Marktanteile gewinnen.

[bbott]

Ach ja, und Tesla soll endlich mal richtige Stückzahlen liefern und verkaufen, vernüftige Gewinne machen und die Autos sollten auch mal die Features haben von den Elon Musk immer redet.
All das tut Tesla inzwischen. Ewig gestriger.

[HOT]

Das ergibt sicherlich Sinn, ist aber jetzt ja auch schon möglich bei knapp über 70mm². So wie es aussieht bekommt das Granite Ridge CCD ja 8 Zen5 + 4 Zen4D-Kerne. Das würde auch der APU sehr gut stehen. Von daher erhärtet das eher mein These. Kombinationen sind da ne Menge möglich, beispielsweise könnte man den IOD zusätzlich mit einem GFX-Chiplet versehen, wenn man fürs Notebook bessere Grafik benötigt.

Aber ich denke, das geht nur dank TSVs mit Chiplets, da der Energieverbrauch der Anbindungen hier deutlich niedriger und die Energiesteuerung deutlich einfacher ist als mit reinen MCMs.

[HPVD]

vielleicht doch (noch) keine Big (5) Little (4) Prozessoren mit ZEN 5:

wenn AMD nun aussagt, dass Hybrid-Architekturen für AMD noch einige Jahre kein Thema sein werden, dann ist Zen 5 sicherlich zu nah dran (erwartet 2023/24), als dass dies noch passen könnte. Denkbar, dass die seinerzeit genannten "Zen 4D" Kerne zwar tatsächlich existieren, diese jedoch einen anderen Sinn ergeben – beispielsweise nicht als kleine Kerne in einer Hybrid-Architektur, sondern als extra Prozessoren basierend rein auf diesen CPU-Kernen. Dass eine CPU-Generation mit "Zen 4D" und "Zen 5" Kernen daherkommt, muß schließlich nicht zwingend bedeuten, dass jene Kerne im selben Prozessor zusammengemixt werden.

https://www.3dcenter.org/news/hardware-und-nachrichten-links-des-13-oktober-2021

[HOT]

Naaa, vielleicht mobil. Mal gucken. Zen4D wird ja schon echt sein. Zen Kerne sind ja vieeel kleiner als cove-Kerne, von daher verwundet das auch nicht, dass das im Desktop wenig Sinn ergibt für AMD.

[CrazyIvan]

Oder sie bluffen ganz einfach, um die Konkurrenz im unklaren zu lassen.

[Nightspider]

Angeblich hieß es ja das Zen5 recht zügig nach Zen4 kommt und das Zen4 sich durch Corona auch etwas verspätet hat. Vor einiger Zeit hieß es mal Zen5 könnte 12-15 Monate nach Zen4 aufschlagen.
Der Abstand könnte sich durch die leichte Zen4 Verschiebung sogar noch veringern.

Jetzt sagt greymon55 das Zen5 wohl noch 2023 aufschlägt.

Ob man Zen5 Ende 2023 schon kaufen kann muss sich zeigen, vielleicht könnte zumindest die Vorstellung dann schon Ende 2023 sein.

https://twitter.com/greymon55/status/1448090356885737484

Zen5 wird in TSMCs N4 oder noch wahrscheinlicher in N3 kommen.

Wenn es kommt wie Greymon sagt, dann hätten wir von jetzt an in fast 2 Jahren:


V-Cache (10-25% im Gaming)
Zen4 IPC uplift (angeblich 20-30%)
Zen5 IPC uplift (spekulativ 10-25%)
5nm Vorteile bei Effizienz und Taktrate
3nm Vorteile bei Effizienz und Taktrate


=heftige 45 bis 80% höhere IPC und wohl höhere Taktraten.
(Die spek. Maximalzuwächse habe ich jetzt mal nicht aufaddiert aber da würde man bei Faktor 2 [+100%]herauskommen)

Natürlich alles spekulativ und wenn es so kommt wären das best-case Szenarien für uns User.

[w0mbat]

Mit Zen5 wird es dann wieder Zeit zum Aufrüsten.

[Platos]

=heftige 45 bis 80% höhere IPC und wohl höhere Taktraten.
(Die spek. Maximalzuwächse habe ich jetzt mal nicht aufaddiert aber da würde man bei Faktor 2 [+100%]herauskommen)



Wie viel davon dann im Gaming ankommt, ist eine andere Frage. Und somit bleibt das ganze quasi absolut offen und ist völlig ungewiss.

[Nightspider]

Joar, hab ich ja auch dazu geschrieben.

Aber da die letzten Architekturupdates bzw. Cache Verbesserungen ganz gut im Gaming ankamen hoffe ich das es so weiter geht.

[Der_Korken]

Einziger Hinweis zur Zen-5-Performance, den wir haben ist


– jump to Zen 5 from 4 from will be about as much as Piledriver to Zen 1 design goal
– original design goal was 2.5 to 3 times the IPC of Zen 1


Das klingt für mich so, als wäre Zen 5 das nächste Redesign. Und ausgehend von dem gigantischen IPC-Sprung wäre das wohl der Gegenspieler zu dem in Gerüchten aufgetauchte "Royal Core" von Intel. Eventuell eine verrückte Phantasie von Jim Keller, die erst von AMD-Ingenieuren und später von Intel umgesetzt wird? Wer weiß. Wobei IPC nicht alles ist, vielleicht geht auch der Takt runter wie bei P4 -> Core 2. Es ist ja nicht in Stein gemeißelt, dass ein Design unbedingt mit 5 Ghz laufen muss, um schnell zu sein.

Mich überrascht aber, dass das schon in N3 kommen soll. Das ist gerade mal gute 2 Jahre jetzt und wir sind noch bei N7. Nichtmal N6 existiert in realen Produkten und N5 (bei dem sogar mal spekuliert wurde, ob AMD wegen des Huawei-Absprungs nicht Vermeer noch schnell darauf portiert hätte ;D) kommt erst nächsten Spätsommer bis Herbst. Das passt nicht zu den sonst üblichen Lebenszyklen von Prozessen. N5 wird erst 2 Jahre später genutzt als er verfügbar und in anderen vergleichbaren Produkten (Apple M1) eingesetzt wird. Warum sollte AMD bei N3 plötzlich so schnell sein?

[basix]

N3 HPC wird fast gleichzeitig mit N3 hochgezogen. Bei N5 und N7 war das noch anders.

[iamthebear]

Für mich hört sich das in etwa so an, dass sowohl bei Intel als auch bei AMD 1-2 richtig fette Kerne gebracht werden, so ohne Kompromisse alles in ST Leistung geworfen wird.
Ein Royal Core kann dann vielleicht so groß wie 4 busherige Big Cores sein. Der ist für reine Single Threaded Software.

Dazu gibt es die bekannten Big/Little Cores bei Intel bzw. Medium Cores bei AMD.

[Zossel]

Wie sind die bisherigen Big/Little Cores bei ARM organisiert und wie stellen sich diese Richtung Software dar?

[Nightspider]

Hat AMD nicht gerade gesagt die nächsten Jahre kein heterogenes Design zu bringen?




Mich überrascht aber, dass das schon in N3 kommen soll. Das ist gerade mal gute 2 Jahre jetzt und wir sind noch bei N7. Nichtmal N6 existiert in realen Produkten und N5 (bei dem sogar mal spekuliert wurde, ob AMD wegen des Huawei-Absprungs nicht Vermeer noch schnell darauf portiert hätte ;D)

Huaweis N5 Kapazitäten waren vielleicht zu klein oder kamen knapp zu spät.

Zen3 kam knapp zu früh für N5 und Zen4 kommt recht spät in N5. Das liegt halt nicht an TSMC sondern daran das AMDs Roadmap nicht synchron zu TSMCs Roadmap läuft sondern es hin und wieder zu großen Versätzen kommt.

AMD hätte dieses Jahr schon eine CPU in N5 bringen können. Vielleicht hatte man Zen 4 für Anfang 22 angestrebt. Vielleicht kommt Zen4 schon im 2. Quartal in Server oder Supercomputer.

Apple bringt 2022 Produkte in N3. 12-15 Monate später, also Ende 2023, sind also kein Problem für 80-100mm^2 Chiplets.

Natürlich nur wenn sich das Zen5 Design nicht verspätet.

[Piefkee]

N3 HPC wird fast gleichzeitig mit N3 hochgezogen. Bei N5 und N7 war das noch anders.

Hat aber damit nichts zu tun.
AMD nutzt sowohl N7 als auch N5 als Base-Version des PDKs und nicht das HPC

[Piefkee]

Zen 5 Spek zu Big/Little:
- AMD hat gerade erst auf bei 5 Jahres Jubi gesagt das sie kein Big/Little verfolgen
- Wir vermuten das Strix-Point Zen 5 APU auf Big-Little setzt
- Die gerüchte Sprechen von Zen5 + Zen4D

Zen4D:
Vielleicht ist das Zen4D etwas ganz anderes als wir hier vermuten. Es kann auch in Richtung 3D Stacking gehen.


Speku von mir:
Strix Point APU
Mono Design mit Zen5 + RNDA2 gefertigt in TSMC N3
Stacked Die auf der APU mit Zen4 in N5

8C Zen5 + 8C Zen4 auf einer APU

[Ramius]

Also wenn Zen5 so schnell auf Zen4 folgen soll, dann glaube ich nicht, dass Zen5 schon in 3nm hergestellt wird.

Vor einiger Zeit hatte AMD mal gesagt, dass sie auf ausgereifte Prozesse setzen wollen und nicht den neuesten Prozess nehmen wollen. Wenn man sieht, dass TSMC gerade mit dem N3 Prozess Probleme hat und es damit zu Verzögerungen kommen wird, so wird AMD Zen5 nicht mit N3 bringen, sondern mit N5 oder N5+.

[HOT]

Zen 5 Spek zu Big/Little:
- AMD hat gerade erst auf bei 5 Jahres Jubi gesagt das sie kein Big/Little verfolgen
- Wir vermuten das Strix-Point Zen 5 APU auf Big-Little setzt
- Die gerüchte Sprechen von Zen5 + Zen4D

Zen4D:
Vielleicht ist das Zen4D etwas ganz anderes als wir hier vermuten. Es kann auch in Richtung 3D Stacking gehen.


Speku von mir:
Strix Point APU
Mono Design mit Zen5 + RNDA2 gefertigt in TSMC N3
Stacked Die auf der APU mit Zen4 in N5

8C Zen5 + 8C Zen4 auf einer APU


Bingo würde ich sagen. Ich denke aber, dass man ein Zen5 CCD mit einem Zen4D-CCD paaren wird. Monolithische sind dann Geschichte, dass das ein Ablaufdatum hat war ja eh absehbar.

https://www.techpowerup.com/287988/amd-ryzen-mobile-raphael-h-series-could-pack-16-cores-based-on-zen-4-architecture

Das passt dazu ganz gut, dass es eben auch jetzt H-Varianten geben soll, das wäre dann bis zu 16 Zen4-Cores, bei Zen5 dann eben bis zu 16 Zen5-Cores. Diese Variante passt einfach gut finde ich.

[Der_Korken]

Zen4D:
Vielleicht ist das Zen4D etwas ganz anderes als wir hier vermuten. Es kann auch in Richtung 3D Stacking gehen.

Der Gedanke kam mir auch schon mal als jemand in irgendeinem Post den gestackten Cache als "Zen 3D" bezeichnet hat. Wer weiß was sich die Marketingabteilung kreatives einfallen lässt, um dem ganzen noch eine vierte Dimension anzudichten. Und schon hätten wir unseren "Zen 4D", schöner Troll-Move :D.

[HPVD]

TSMC N3 update:

The extreme complexity of the technology will further add to the number of process steps – bringing it toto well over 1000 – which will further increase cycle times.

As a result, while mass production of the first chips using TSMC's N3 node will begin in the second half of 2022, the company will only be shipping them to an undisclosed client for revenue in the first quarter of 2023. Many observers, however, expected these chips to ship in late 2022.

"N3 risk production is scheduled in 2021, and production will start in second half of 2022," said C.C. Wei, CEO of TSMC. "So second half of 2022 will be our mass production, but you can expect that revenue will be seen in first quarter of 2023 because it takes long — it takes cycle time to have all those wafer out."

https://www.anandtech.com/show/17013/tsmc-update-3nm-in-q1-2023-3nm-enhanced-in-2024-2nm-in-2025

[Zossel]

TSMC N3 update:

https://www.anandtech.com/show/17013/tsmc-update-3nm-in-q1-2023-3nm-enhanced-in-2024-2nm-in-2025

Ist das eine signifikante Verspätung gegenüber bisherigen Terminen?

[Distroia]

Man hatte bis jetzt damit gerechnet, dass die nächste IPhone-Generation Ende 2022 schon in 3nm ist. Das klingt schon ziemlich signifikant. Bei Samsung und Intel kann man solche Verzögerungen ja schon mehr oder weniger einplanen (von Intels 10 nm rede ich da nichtmal :freak:), bei TSMC ist das schon ungewöhnlich.

[Blediator16]

Ist das eine signifikante Verspätung gegenüber bisherigen Terminen?


N3 als Top-Node für 2022
Das nächste Highend-Verfahren heißt N3 und soll verglichen mit N5 eine bis zu 15 Prozent höhere Geschwindigkeit bei gleicher Leistungsaufnahme oder aber die gleiche Performance bei bis zu 30 Prozent weniger Energiebedarf aufweisen. Weil es sich um einen Full-Node handelt, soll überdies die Logikdichte um 70 Prozent steigen, die für SRAM immerhin um 20 Prozent.

Laut TSMC wird N3 exzellent aufgenommen, so soll es im ersten Jahr mehr als doppelt so viele Node-Tape-Outs (NTO) geben wie bei N5. Die Serienproduktion ist für das zweite Halbjahr 2022 vorgesehen.
Ein Bericht
von
Marc Sauter
veröffentlicht am
6. Juni 2021, 9:00 Uhr

https://www.golem.de/news/halbleiterfertigung-was-tsmc-in-den-naechsten-monaten-vorhat-2106-156989.html

Würde ich jetzt nicht all zu sehr negativ einschätzen.

[Zossel]

Man hatte bis jetzt damit gerechnet,

Also etwas was sich irgendjemand aus den Fingern gesogen hat, ergo nicht belastbares.

[Nightspider]

Das Apple dieses Jahr kein 3nm bekommt war ja schon länger klar.

Wenn N3 pünktlich gewesen wäre hätte man Zen5 auch erst im dritten Jahr des Prozesses gefertigt.
Von daher ist es vielleicht gar nicht angebracht von "sehr zeitig" zu sprechen.

[iamthebear]

Schön langsam wird halt auch für TSMC die Luft etwas dünner.

Wenn 3nm so viel aufwändiger ist, wird sich das in erster Linie im Preis niederschlagen. Apple zahlt den Preis, denn die brauchen die Energieeffizienz. Bei AMD ist es jedoch fraglich, ob dies so bald Sinn macht.

Ich denke, dass 3nm nur dann Sinn macht, wenn man in erster Linie Logicteile shrinked, denn wie zuvor bei 7 vs. 5nm profitieren diese deutlich mehr als SRAM.

5nm vs. 7nm bringt 1.85x Logic Dichte und 1.2x SRAM
3nm vs. 5nm bring 1.7x Logic und 1.2x SRAM
3nm vs. 7nm bringt demnach ca. 3.1x Logic Dichte aber nur 1.44x SRAM

Bei GPUs ist der Weg eindeutig: Hier geht AMD den Weg mit Infinity Cache auf eigenen Chips in einem älteren Verfahren. Bei einer CPU ist jedoch fraglich wie sinnvoll das ist in Hinblick auf die Latenzen. Abgesehen davon würden z.B. 16 Zen3 Kerne auf einem 80mm² Chip + Cache auf einem 2. Chip alleine schon aus thermischen Gründen nicht sinnvoll funktionieren. Wenn man wie AMD sehr kompakte Kerne hat muss man SRAM in der Mitte dazu mischen sonst wird es unkühlbar.

Das Ziel von AMD bei Zen5 sollte denke ich ähnlich wie Apple sein: Unmengen an Transistoren verbraten um mit großen Kernen viel IPC zu erreichen allerdings mit weniger Verlustleistung.
Dann könnte man reine CPU Chips in 3nm fertigen (z.B. mit 16 Kernen) und den Cache mit einem älteren Verfahren fertigen und oben drauf stacken.

[Brillus]

Wenn 3nm so viel aufwändiger ist, wird sich das in erster Linie im Preis niederschlagen. Apple zahlt den Preis, denn die brauchen die Energieeffizienz. Bei AMD ist es jedoch fraglich, ob dies so bald Sinn macht.

Also HPC/Cloud Bereich sicher, für mobile wahrscheinlich auch noch, Desktop wahrscheinlich eher nicht aber das ist ja sowieso eher nur noch Resteverwertung (bzgl. F&E).

[Nightspider]

Bei GPUs ist der Weg eindeutig: Hier geht AMD den Weg mit Infinity Cache auf eigenen Chips in einem älteren Verfahren. Bei einer CPU ist jedoch fraglich wie sinnvoll das ist in Hinblick auf die Latenzen.

Was soll da fraglich sein nach Zen3D ?
Die TSVs sind sogar recht weit weg von der Logic weil dazwischen der halbe Cache liegt.
Wenn man den kompletten L3 verlagert kann man die TSV-Datenverbindungen noch viel näher an die Logic setzen und eventuell nochmal ein paar Nanosekunden sparen.

Abgesehen davon würden z.B. 16 Zen3 Kerne auf einem 80mm² Chip + Cache auf einem 2. Chip alleine schon aus thermischen Gründen nicht sinnvoll funktionieren.

Ist das so?

Bei Zen3D schleift man 95% vom Chip weg und klebt dann wieder Silizium drauf. Was wäre wenn man in der 2. oder 3. Generation den abgeschliffenen Compute-Chip auf den IO/Cache-Die setzt, so das die Hauptwärmequelle oben sitzt, direkt unter dem Kühler?

Da fehlt dann der thermische Widerstand von 95% des Siliziums.

[basix]

Hat aber damit nichts zu tun.
AMD nutzt sowohl N7 als auch N5 als Base-Version des PDKs und nicht das HPC

Das wäre mir neu. Gibt es belastbare Infos dazu?

Also HPC/Cloud Bereich sicher, für mobile wahrscheinlich auch noch, Desktop wahrscheinlich eher nicht aber das ist ja sowieso eher nur noch Resteverwertung (bzgl. F&E).
Laut TSMC haben sie mehr Tapeouts als bei N5 und N7 (im selben Zeitraum). Scheint sich für viele also zu lohnen.

[Brillus]

Laut TSMC haben sie mehr Tapeouts als bei N5 und N7 (im selben Zeitraum). Scheint sich für viele also zu lohnen.
Naja kommt ja noch NV wieder zurück und Apple scheint ja jetzt 3 statt nur einem Chip zu machen. Das könnte das mehr schon erklären.

[basix]

Es gibt noch x HPC und AI/ML Buden, die in diesen Prozessen designen. Dito andere Mobile SoCs. Bei N5 hat man glaube ich von 100 oder so Tape Outs gesprochen (evtl auch etwas weniger), das sind nicht nur eine Handvoll Chips.

[Linmoum]

Da ich das erst mit Zen5 für realistischer halte, packe ich das mal hier rein. Zen4 wäre IMO zu früh dafür. Kepler via Anandtech:

Nope, mobile APUs will be MCM as well (and 3D stacked!).

https://forums.anandtech.com/threads/speculation-zen-4-epyc-4-genoa-ryzen-6000.2571425/page-102#post-40614578

[AffenJack]

Hat Kepler irgendwelche Quellen? Kamen von ihm nicht zb sonstwelche Gerüchte, dass N31 seinen Tapeout so früh hatte und ja praktisch jetzt schon kommen müsste? Ich hatte da nicht den Eindruck, dass da mehr als raten dahinter steckt. Aber vll verwechsle ich ihn auch gaerade

[basix]

Es wurde ja über eine 16C APU gemunkelt, hier würde MCM langsam Sinn machen.

MCM kann hier aber vieles bedeuten:
- Integriert + mehr Cores = APU + 8C CCD = 16C + iGPU
- Integriert + mehr Cores + mehr GPU = APU + 8C CCD + GPU-Extension = 16C + Big iGPU
- Disaggregated = IOD + 2x CCD + GPU als separates Die = 16C + iGPU
- ...

Wenn ich wählen würde: CCD Extension würde am meisten Sinn machen, wenn man nicht grössere GPUs in die APUs packen will. Die Standard-APU wäre wie heute monolithisch, klein und auf Low Power getrimmt (max. 8C). Bei H-SKUs (>35W, 8-16C) ist dann das bisschen Mehrverbrauch aufgrund MCM off-chip Links weniger tragisch. Dieses Konstrukt wäre prinzipell auch bereits bei Rembrandt denkbar, aber eher unwahrscheinlich (Zen 3+ vs. Zen 3?).

Edit:
Sobald man grössere iGPUs verbauen will, würde ein disaggregated Ansatz langsam mehr Sinn machen.

[Linmoum]

Ein paar Auszüge aus dem Interview mit Mike Clark. Ich denke, das passt am besten zu Zen5.

But we are going to go wider, you're going to see us go wider, and to be efficient, we'll have the transistors around the front end of the machine to make it the right architectural decision. So it's really having the continuous increase in transistors that we get, allowing us to beef up the whole design to continue to get more and more IPC out of it.
We do see core counts growing, and we will continue to increase the number of cores in our core complex that are shared under an L3.
There were a lot of people, even internally, that were worried we weren't going to be able to sustain the rate of progress. It is a very risky strategy, - tearing the whole core up every three years is risky. But to me, I've managed to convince everyone, and it’s what the market requires. If we don't do it, someone else will.
https://www.anandtech.com/show/17031/anandtech-interviews-mike-clark-amds-chief-architect-of-zen

[Tarkin]

Mike Clark auf die Frage "what should AMD users look forward to?"

It's going be great! I wish I could tell you of all what's coming. I have this annual architecture meeting where we go over everything that's going on, and at one of them (I won't say when) the team and I went through Zen 5. I learned a lot, because of nowadays as running the roadmap, I don't get as close to the design as I wish I could. Coming out of that meeting, I just wanted to close my eyes, go to sleep, and then wake up and buy this thing. I want to be in the future, this thing is awesome and it's going be so great - I can't wait for it. The hard part of this business is knowing how long it takes to get what you have conceived to a point where you can build it to production.

[Nightspider]

Da innerlich nicht etwas zu hypen ist schwer. :D

[Tarkin]

gibt ja Gerüchte die darauf hindeuten, dass Zen 5 ziemlich krass werden könnte... langsam glaub ichs ;)

https://chipsandcheese.com/2021/02/05/amds-past-and-future-cpus/

the jump [to Zen 5 from 4] from will be about as much as Piledriver to Zen 1 design goal, which if you recall to earlier in this article was 40%. I was told from a 3rd source that Zen 5’s original design goal was 2.5 to 3 times the IPC of Zen 1 which roughly lines up with the perspective of a “Piledriver to Zen 1”-like jump.

[Platos]

Ja, wird spannennd. Mal schauen wie Arrow Lake dann dagegen antritt. Sollte vermutlich in 3nm kommen. Intel soll ja mehr gebucht haben, wie Apple.

[Zossel]

Ja, wird spannennd. Mal schauen wie Arrow Lake dann dagegen antritt. Sollte vermutlich in 3nm kommen. Intel soll ja mehr gebucht haben, wie Apple.

Intel will CPUs bei TSMC fertigen?

Ist das bestätigt oder ein Gerücht?

[basix]

TSMC N3 wird doch eher für Ponte Vecchio Next, Xe HPG+ und die Xe iGPUs benutzt werden (ab Meteor Lake als Chiplet-Tiles). Evtl. noch irgendwelche 5G-Module. Da kommt einiges an Chips und Wafer-Stückzahlen zusammen. Der CPU-Core wird mit allergrössterwahrscheinlichkeit auf einem Intel Node laufen.

Den CPU-Core auf TSMC N3 zu schieben käme einem wahnsinnigen Gesichtsverlust gleich. Bei der GPU und anderen Chips kann man das entspannter sehen.

[basix]

Mike Clark auf die Frage "what should AMD users look forward to?"

It's going be great! I wish I could tell you of all what's coming. I have this annual architecture meeting where we go over everything that's going on, and at one of them (I won't say when) the team and I went through Zen 5. I learned a lot, because of nowadays as running the roadmap, I don't get as close to the design as I wish I could. Coming out of that meeting, I just wanted to close my eyes, go to sleep, and then wake up and buy this thing. I want to be in the future, this thing is awesome and it's going be so great - I can't wait for it. The hard part of this business is knowing how long it takes to get what you have conceived to a point where you can build it to production.

Irgendwie fand ich die Aussage etwas dämlich. Eine Frage zuvor hat er gesagt, dass er internen Beschuss bekommen hat für seine damalige Aussage, dass er bereits an Zen 5 arbeite. Nun sagt er: Zen 5 ist absolut der Hammer. Und implizit: Wartet, kauft noch keinen Zen 4 ;D

Allgemein hatte ich beim Durchlesen des Interviews ein wenig das Gefühl, dass er sich etwas wichtig nimmt. Jim Keller ist in Interviews da viel angenehmer rübergekommen. Evtl. täuscht der Eindruck, aber so in etwa empfand ich es.

[Platos]

Intel will CPUs bei TSMC fertigen?

Ist das bestätigt oder ein Gerücht?

Nein, das ist ein Gerücht.

https://videocardz.com/newz/intel-arrow-lunar-and-nova-lake-codenames-appear-in-a-leak-as-meteor-lake-successors

[bloodflash]

Evtl. noch irgendwelche 5G-Module
Intel hat die Modemsparte doch an Apple verkauft:
https://www.heise.de/newsticker/meldung/Apple-uebernimmt-Intels-5G-Modem-Sparte-4479615.html

[HPVD]

Zen 5 based Epyc Turin angeblich mit bis zu 256 cores (@greymon55) und 600W (@ExecuFix),
zusammengfasst:
https://videocardz.com/newz/amd-epyc-turin-with-zen5-cores-rumored-to-feature-maximum-tdp-of-600w

[reaperrr]

Da ich das erst mit Zen5 für realistischer halte, packe ich das mal hier rein. Zen4 wäre IMO zu früh dafür. Kepler via Anandtech:

Nope, mobile APUs will be MCM as well (and 3D stacked!).

https://forums.anandtech.com/threads/speculation-zen-4-epyc-4-genoa-ryzen-6000.2571425/page-102#post-40614578

Es wurde ja über eine 16C APU gemunkelt, hier würde MCM langsam Sinn machen.
(...)
Wenn ich wählen würde: CCD Extension würde am meisten Sinn machen, wenn man nicht grössere GPUs in die APUs packen will. Die Standard-APU wäre wie heute monolithisch, klein und auf Low Power getrimmt (max. 8C). Bei H-SKUs (>35W, 8-16C) ist dann das bisschen Mehrverbrauch aufgrund MCM off-chip Links weniger tragisch. Dieses Konstrukt wäre prinzipell auch bereits bei Rembrandt denkbar, aber eher unwahrscheinlich (Zen 3+ vs. Zen 3?).

Laut Greymon55 (https://twitter.com/greymon55/status/1449928196535644168?ref_src=twsrc%5Etfw) kommt Raphael wohl auch als H-SKU.

Mit anderen Worten, da Raphael integrierte Grafik haben wird und dank 5nm auch mit 16 Kernen noch relativ effizient sein dürfte, bringt AMD den einfach auch in Notebooks, und deckt mit Rembrandt wohl nur den Bereich darunter ab.

[Nightspider]

Wenige Monate nach Zen5 dürfte eh der Rembrandt Nachfolger kommen.

[basix]

Das wäre dann Phoenix-H.

Aber würde Sinn machen:
- 6-8C + grosse iGPU = Rembrandt und danach durch Phoenix abgelöst (evtl. bleibt Rembrandt bei den Entry-SKUs noch drin, siehe Lucienne und Barcelo, da 6nm anstatt 5nm einfach günstiger sein wird)
- 8-16C + kleine iGPU + dGPU = Raphael-H

[robbitop]

Mike Clark auf die Frage "what should AMD users look forward to?"

It's going be great! I wish I could tell you of all what's coming. I have this annual architecture meeting where we go over everything that's going on, and at one of them (I won't say when) the team and I went through Zen 5. I learned a lot, because of nowadays as running the roadmap, I don't get as close to the design as I wish I could. Coming out of that meeting, I just wanted to close my eyes, go to sleep, and then wake up and buy this thing. I want to be in the future, this thing is awesome and it's going be so great - I can't wait for it. The hard part of this business is knowing how long it takes to get what you have conceived to a point where you can build it to production.
Auch interessant sind seine Aussagen zur Breite des Decoders und warum man bis dato auf 4 wide blieb und auch, dass man breiter werden wird.
Ich gehe jede Wette ein, dass das spätestens mit Zen 5 der Fall sein wird.

Wenn das Gerücht mit Zen5+4D stimmt, muss Zen5 fast zwangsläufig deutlich mehr ILP extrahieren können und dem entsprechend deutlich größer sein.

[Tobalt]

2.5 .. 3 *times* Zen1 IPC :o

Wer hätte zu Zen1 /Kabylake Zeiten gedacht dass es demnächst mal mehr als 2.5 .. 3 % IPC hoch geht :D

[aufkrawall]

Alles andere wäre wirklich desaströs für x86. Der SoC im Pixel 6 schafft ~19.5k in Octane V2 Firefox, mein 11400F auch nur 32k. :freak:

[basix]

2.5 .. 3 *times* Zen1 IPC :o

Wer hätte zu Zen1 /Kabylake Zeiten gedacht dass es demnächst mal mehr als 2.5 .. 3 % IPC hoch geht :D

Nur um das mal in Relation zu setzen: @Rendering liegen ~2.8x IPC zwischen Pentium 4 (Presler) und Sandy Bridge :D

- Presler -> Conroe ~2.0x
- Conroe -> Sandy Bridge ~1.4x

[Platos]

6-Kerner kosten dann hoffentlich nicht noch mehr bei AMD. Aber bisher gehts ja in Richtung mehr Leistung=mehr Preis

[Nightspider]

Soll die durchschnittliche IPC tatsächlich 2,5-3 mal höher liegen zwischen Zen1 und Zen5 ?

Nicht das am Ende nur so ein Maximalwert bei Games oder so gemeint ist....

[basix]

Soll die durchschnittliche IPC tatsächlich 2,5-3 mal höher liegen zwischen Zen1 und Zen5 ?

Nicht das am Ende nur so ein Maximalwert bei Games oder so gemeint ist....

Wenn wir das nur wüssten ;)

[w0mbat]

RGT hat nen Zen 5 leak video und seit seinem Infinity Cache leak für RDNA2 wissen wir, dass er gute Quellen hat.

Seine Infos zu Zen 5:
komplett neues design, viel mehr IPC als Zen4
2x cores per CCX
größere L1 cache
größerer L2 cache + L2 ist jetzt "shared"
L3 nur noch via 3D V-Cache und stacked auf dem I/O-die


gkibZqCwcSU

[Windi]

16 Kerne, die sich einen großen L2 Cache teilen? Das müsste doch sehr schlecht für die Latenzen sein.

AMD weiß hoffentlich was sie da tun.

[MSABK]

16 Kerne, die sich einen großen L2 Cache teilen? Das müsste doch sehr schlecht für die Latenzen sein.

AMD weiß hoffentlich was sie da tun.

Ich habe keine Ahnung von Entwicklung und CPUs, aber können die Hersteller die CPU Performance simulieren und abschätzen obs eine Fehlentwicklung werden könnte?

[Skysnake]

Ja du kannst das z.b. mit dem GEM5 Simulator taktgenau simulieren. Das ganze Zeug ist aber recht langsam. Alternativ halt per großer GPGA Büchsen simulieren. Aber auch da wieder mit deutlich niedrigeren Taktraten.

Kurz um. Man kann und tut es auch, aber sobald du das erste mal Silizium im Lab hast, hat du binnen kürzester Zeit ein vielfaches aller Simulationen getestet...

[Windi]

Ich habe keine Ahnung von Entwicklung und CPUs, aber können die Hersteller die CPU Performance simulieren und abschätzen obs eine Fehlentwicklung werden könnte?
Ich gehe fest davon aus, das die Hersteller das simulieren können. Natürlich können dabei auch Fehler passieren, aber meistens wird das hoffentlich passen.

Ich bin halt nur etwas verwundert, das man anscheinend bereit ist, die Latenzen deutlich zu verschlechtern. Wird noch interessant, was AMD in der neuen Architektur einführen will, um dies wieder auszugleichen.

[aufkrawall]

Schwer vorstellbar, dass AMD das so machen würde, wenn es nicht aufginge. 16C CCX, also gleiche (niedrige) Latenzen für alle Cores sind dann das Nonplusultra für Gaming für die nächsten fünf bis zehn Jahre und auch extrem effiziente Kernmonster-APUs mit monolithischem Die sind damit möglich.
Wenn dann noch die IPC extrem zulegt, wird es interessant, was Intel dem noch entgegensetzen will. :freak:

[MSABK]

Wenn dann noch die IPC extrem zulegt, wird es interessant, was Intel dem noch entgegensetzen will. :freak:

KSS++ Limited Edition mit 550W TDP.:D

[Brillus]

RGT hat nen Zen 5 leak video und seit seinem Infinity Cache leak für RDNA2 wissen wir, dass er gute Quellen hat.

Seine Infos zu Zen 5:
komplett neues design, viel mehr IPC als Zen4
2x cores per CCX
größere L1 cache
größerer L2 cache + L2 ist jetzt "shared"
L3 nur noch via 3D V-Cache und stacked auf dem I/O-die


https://youtu.be/gkibZqCwcSU
Da steht nichts vom L3 auf dem IO Die nur das es stacked ist.

[Der_Korken]

Weiß nicht was ich davon halten soll. L3 auf den IOD ausgelagert, OK, kann man machen. In 6nm ist Cache immer noch ausreichend dicht und performant und man spart sich eine Menge Diespace im teuren Node. Wie man hört, sollen es ja 16 Cores pro Chiplet sein, was auch heute schon ohne Vergrößerung der Chiplets möglich wäre, wenn man den L3 weglassen würde.

Aber das mit dem L2 verstehe ich nicht. Es muss jedem klar sein, dass ein Cache, der über 16 Kerne geshared wird, ähnlich langsam wie der L3 von Zen 3 sein muss. Hier mal die Latenzen von Zen +, 2 und 3:

L1: 4 Takte
L2: 8 Takte (insgesamt also 12)
L3 (Zen+): 23 Takte (also insgesamt 35)
L3 (Zen2): 27 Takte (also insgesamt 39)
L3 (Zen3): 34 Takte (also insgesamt 46)

Die Verdopplung von Zen+ auf Zen 2 war latenztechnisch deutlich günstiger als die Anzahl Kerne daran zu erhöhen wie bei Zen 3. Zumal sich die Bandbreite pro Core bei Zen 3 noch halbiert hat, sonst wäre es noch langsamer geworden. Ein hypothetischer L2 mit 16MB (angeblich soll der L2 "nicht kleiner" als bei Zen 4 werden, also >= 1MB/Kern) aber 16 Clients wäre sicherlich nicht schneller als der L3 von Zen 3. Die Lücke zum L1 wäre gigantisch, quasi so als würde man den jetzigen L2 einfach weglassen. Oder andersrum: Wenn AMD so einen Monster L2 mit moderaten Latenzen hinkriegen würde, also irgendwas um die 18-20 Takte, warum hat man nicht bereits einen L3 mit so einer Technik gebaut?

Irgendwie passt das für mich nicht zusammen. Als ich das erste mal vom shared L2 bei Zen 5 gehört habe (das war in dem Video, der RGT über RDNA3 gesprochen hat), da war mein erster Gedanke, dass AMD die CCX wieder auf 4 Kerne verkleinert, nur eben mit shared L2 und der L3 hängt dann hinter den CCX als gestackter Cache. Das habe ich hier oder im Zen-4-Thread schon mal beschrieben. Mit 4 Kernen könnte man den L2 sehr gut sharen, weil sich vier Kerne geometrisch günstig anordnen lassen. Dann hätte ein Kern, der einen kritischen Thread bearbeiten muss bspw. 4 oder 8MB schnellen L2 und dahinter einen eher langsamen, aber dafür rieseigen L3 (z.B. 32MB im IOD mit zwei Stacks oben drauf für insgesamt 160MB). Das hätte für mich Sinn ergeben, weil dann je 4 Kerne auf L2-Ebene verbunden sind und (bei 16 Kernen) je 4 CCX auf L3-Ebene. Von der Latenz hätte man dann z.B. 1ns beim L1, 3-4ns beim L2 und 15-20ns beim L3, also ungefähr gleichmäßige Abstufungen.

Bei der Version mit 16 Kernen an einem L2 sind ja beim 16-Kerner schon alle Kerne unter dem L2. Wozu brauche ich da noch mal einen L3 im IOD? Den hätte ich doch gleich auf den L2 stacken können und würde massiv Latenz sparen. Eine neue Cache-Ebene mache ich doch nur auf, wenn ich damit auch hinreichend viele Clients zusammenfasse.

Eine mögliche Erklärung wäre, dass der L1 massiv wächst, um die Lücke zum L2 zu verkleinern. 32kB sind ein sehr guter sweet spot, weil man hier VIPT nutzen kann bei einer moderaten Assoziativität von 8. Würde man den auf 64kB verdoppeln, müsste man entweder die Assoziativität auch verdoppeln (= viel Verbrauch und etwas mehr Latenz) oder VIPT aufgeben (= deutlich mehr Latenz). Wenn man VIPT aufgibt, dann nur wenn man auch einen ordentlichen Sprung macht, z.B. auf 128kB oder 256kB. Anhand der L2-Latenz von bisherigen Designs muss man da aber mit einer Latenz von 7-8 Takten rechnen (Differenz zwischen L1 und L2 bei Nehalem bis Skylake), was schon eine massive Verschlechterung wäre. Um die aufzufangen bräuchte man im Kern selber auch nochmal Mechanismen, um Cache-Zugriffe zu minimieren. Nun sagt RGT, dass der L1 größer werden soll und weniger Latenz hat. Das ist imho totaler Quatsch, denn die L1-Caches sind für ihre Taktraten und Größen am absoluten Limit. Intel musste für Sunny Cove sogar auf 5 Takte hochgehen, weil 4 Takte bei 5Ghz, 48kB und 128B/Takt wohl nicht mehr zu halten war.

Dass AMD irgendwo den heiligen Cache-Gral herzaubert, mit dem plötzliche alle Caches schneller werden, glaube ich nicht.

[w0mbat]

Da steht nichts vom L3 auf dem IO Die nur das es stacked ist.
Das ist ein Video, kein Text. Und er sagt, dass der L3 cache "moved off CCX" ist und im Video redet er über L3 auf dem I/O-die. Ich weiß nicht wieso du der Meinung warst, du musst einen Kommentar schreiben, kommt aber komisch.

[amdfanuwe]

Das ist ein Video, kein Text. Und er sagt, dass der L3 cache "moved off CCX" ist und im Video redet er über L3 auf dem I/O-die. Ich weiß nicht wieso du der Meinung warst, du musst einen Kommentar schreiben, kommt aber komisch.
Wo redet er im Video von L3 auf dem I/O Die?
"Moved off CCX" heißt doch nur, das gar kein L3 mehr auf dem Chip ist und dieser , nimmt er an, wie beim ZEN 3D gestacked wird.
Macht ja auch Sinn. Beim ZEN 3 nimmt der 32MB L3 ~50% des Chiplets ein.
Stattdessen 8 weitere Kerne drauf und 64 oder 128MB L3 Cache gestacked.
Da kann man mehr Cache stacken. Sieht man ja am ZEN 3D mit dem 64MB Cache Chiplet.

L3 Cache auf dem I/O Die ergibt nur Sinn, wenn die CPU Chiplets mit mehr Bandbreite angebunden würden, über EFOBs oder direkt gestacked auf den I/O.
Macht das ganze aber teuer. Ich denke, dass man beim herkömmlichen Aufbau bleibt, also L3 Cache auf den CPU Chiplets.

Ich denke 16 Core Chiplets sehen wir auch schon bei Bergamo, ZEN 4C.

[basix]

RGT ist mir einfach zu viel am schwafeln. Er hatte ein paar gute Treffer und bringt auch mal andere Ansätze ins Spiel aber pro Video-Minute ist nicht viel Info vorhanden.

Unified L2$ für das ganze CCD sehe ich als sehr schwer an. Wie will man das mit anständigen Latenzen lösen? Ich sehe da eher was anderes: "Super-CCX"
- 16C pro CCD und CCX
- Jeweils aber 4-Core Cluster, somit 4 Cluster pro CCD
- Innerhalb des 4-Core Clusters hat man dann den Unified L2$
- L3$ wandert eine Ebene tiefer aufs "CCD-IOD", wo neben dem L3$ + Ansteuerlogik auch die IFOP Interconnects drauf sind

Das CCD sieht aus Sicht L3$ -> L2$ gleich aus wie Zen 1/2. Deswegen "Super-CCX". Man hat vier Teilnehmer pro CCX, neu aber mit mehr Cores pro Teilnehmer. Später kann man den Schritt Zen 2 -> 3 nochmals wiederholen und auf total 8 Teilnehmer / Ringstops gehen. V-Cache käme als Sandwich zwischen das "CCD-IOD" und das "Super-CCX Die".

Irgendwie passt das für mich nicht zusammen. Als ich das erste mal vom shared L2 bei Zen 5 gehört habe (das war in dem Video, der RGT über RDNA3 gesprochen hat), da war mein erster Gedanke, dass AMD die CCX wieder auf 4 Kerne verkleinert, nur eben mit shared L2 und der L3 hängt dann hinter den CCX als gestackter Cache. Das habe ich hier oder im Zen-4-Thread schon mal beschrieben. Mit 4 Kernen könnte man den L2 sehr gut sharen, weil sich vier Kerne geometrisch günstig anordnen lassen. Dann hätte ein Kern, der einen kritischen Thread bearbeiten muss bspw. 4 oder 8MB schnellen L2 und dahinter einen eher langsamen, aber dafür rieseigen L3 (z.B. 32MB im IOD mit zwei Stacks oben drauf für insgesamt 160MB). Das hätte für mich Sinn ergeben, weil dann je 4 Kerne auf L2-Ebene verbunden sind und (bei 16 Kernen) je 4 CCX auf L3-Ebene.

Meine Schaubilder bilden mehr oder minder genau deine Gedanken ab :) Geklaut ist die Idee aber nicht ;) Was man nun CCX nennt ist dann Definitionssache. Nach Zen 1-3 müsste man alle 16C zu einem CCX zählen.

[iamthebear]

Also irgendwie hört sich das teilweise extrem unlogisch an:

L3 am IO Die: Das ist das Einzige, was wirklich Sinn macht. Erstens kann man den SRAM auf einen älteren Node auslagern der dafür optimiert wurde und zweitens: Dieser ist bei 2 Compute Dies nun shared. Werden nur 16 Threads (ein Compute Die) genutzt steht trotzdem der volle L3 zur Verfügung. Werden alle Threads genutzt, so müssen gemeinsam genutzte Daten nur einmal abgelegt werden.
Voraussetzung dafür ist, dass das mit dem Stacking bzw. Kommunikation zwischen den Dies klappt aber da hat AMD mit RDNA3 ja schon ein Pilotprojekt dafür.

Das mit dem Cache macht aus den schon genannten Gründen irgendwie keinen Sinn. Ich glaube da ist noch etwas vedreht oder wir haben das gesamte Konzept noch nicht begriffen.

Mögliche Erklärungen:
a) Die Information mit den 16 Kernen pro CCX ist falsch und es sind stattdessen wieder 4. Mit Zen2 hatbdas nicht so gut geklappt aber das lag in erster Linie daran. dass der L3 zu klein war. Mit gestacktem shared L3 gibt es das Problem ja nicht.

b) Das was RGT da beschrieben hat sind nicht die Zen 5 Cores, sondern die Zen4C Cores: 16 Kerne pro Die, kleinerer L3, 5/4nm Fertigung, das klingt stark nach dem Zen 5 Leak von MLID zu Zen4C. Wenn dort der L2 auch entfernt wurde würde mich das nicht überraschen.

Ich kann mir nicht wirklich vorstellen, dass AMD bei Zen4 den L2 verdoppelt genauso wie Intel massiv L2 erhöht und AMD den mit Zen5 komplett streicht. Genauso glaube ich nicht, dass bei Zen mit 30% mehr IPC den L1 stark erhöhen kann. Das erhöht die Latenz bei so gut wie jeder Operation und in der Praxis sind diese Ladebefehle ja auch verkettet, dass diese nicht parallel OOO ausgeführt werden können (z.B. Lade Pointer, Lade Element, addiere x und das ist dann ein Array Element das wieder geladen wird.
Bei Sunny Cove was es afaik so, dass zwar der L1 einen Takt langsamer war aber nicht wenn per Pointer auf ein Element zugegriffen wird.

[Der_Korken]

Meine Schaubilder bilden mehr oder minder genau deine Gedanken ab :) Geklaut ist die Idee aber nicht ;) Was man nun CCX nennt ist dann Definitionssache. Nach Zen 1-3 müsste man alle 16C zu einem CCX zählen.

Du hast bei dir Cores und L2 auf einer Ebene und L3 auf einer anderen. Während bei Stacking oft die Funktionalität zwischen den Ebenen aufgeteilt wird, finde ich beim Stacking viel reizvoller, dass sich damit große Caches mit niedriger Latenz realisieren lassen. Wenn du schon einen Cache-Die unter deinen Core-Die schiebst, warum verwendest du nicht die Zellen unterhalb des L2 nicht als L2-Erweiterung? Dann hättest du statt 4MB L2 z.B. 12MB mit guter Latenz. Ich mein, in ganz ferner Zukunft wird man vielleicht auch CPU-Kerne auf mehrere Ebenen verteilen, damit die einzelnen Chipteile "näher" zusammenliegen. Register-Files, die keinen Platz im Design verbrauchen, weil sie einfach eine Ebene tiefer liegen und von überall erreichbar sind.

Genauso glaube ich nicht, dass bei Zen mit 30% mehr IPC den L1 stark erhöhen kann. Das erhöht die Latenz bei so gut wie jeder Operation und in der Praxis sind diese Ladebefehle ja auch verkettet, dass diese nicht parallel OOO ausgeführt werden können (z.B. Lade Pointer, Lade Element, addiere x und das ist dann ein Array Element das wieder geladen wird.
Bei Sunny Cove was es afaik so, dass zwar der L1 einen Takt langsamer war aber nicht wenn per Pointer auf ein Element zugegriffen wird.

Ich stecke nicht so tief in der Materie drin, aber wäre es irgendwie sinnvoll ein wenig primitive Rechenlogik am Cache anzubauen? Statt Loads und Stores zwischen Cache und Registern hätte man z.B. eine Inkrementier-Operation, die Daten aus dem Cache lädt, diese aber nicht in die Register schreibt, sondern am Cache eine Addition durchführt und das Ergebnis sofort wieder in den Cache schreibt?

[Skysnake]

Im Prinzip ja, aber nen increment ist jetzt nicht zwingend das Patadebeispiel denn das Ergebnis braucht man gleich uns increment ist super billig zu machen.

Wenn macht man Summen, Min/Max oder so Sachen. Das buzzword ist dann inmemory Compute.

Das kann man auch auf der Ebene der Caches machen, lohnt sich aber nur bedingt, da ja die Cores nah und mit niedrigen Kosten angebunden sind. Im Memory macht das mehr Sinn.

[fondness]

Schwer vorstellbar, dass AMD das so machen würde, wenn es nicht aufginge. 16C CCX, also gleiche (niedrige) Latenzen für alle Cores sind dann das Nonplusultra für Gaming für die nächsten fünf bis zehn Jahre und auch extrem effiziente Kernmonster-APUs mit monolithischem Die sind damit möglich.
Wenn dann noch die IPC extrem zulegt, wird es interessant, was Intel dem noch entgegensetzen will. :freak:

Du tust so, als ob Intel die Entwicklung eingestellt hätte. Zen5 ist noch ein Stück weg.

[Gipsel]

Eine mögliche Erklärung wäre, dass der L1 massiv wächst, um die Lücke zum L2 zu verkleinern. 32kB sind ein sehr guter sweet spot, weil man hier VIPT nutzen kann bei einer moderaten Assoziativität von 8. Würde man den auf 64kB verdoppeln, müsste man entweder die Assoziativität auch verdoppeln (= viel Verbrauch und etwas mehr Latenz) oder VIPT aufgeben (= deutlich mehr Latenz). Wenn man VIPT aufgibt, dann nur wenn man auch einen ordentlichen Sprung macht, z.B. auf 128kB oder 256kB. Anhand der L2-Latenz von bisherigen Designs muss man da aber mit einer Latenz von 7-8 Takten rechnen (Differenz zwischen L1 und L2 bei Nehalem bis Skylake), was schon eine massive Verschlechterung wäre. Um die aufzufangen bräuchte man im Kern selber auch nochmal Mechanismen, um Cache-Zugriffe zu minimieren. Nun sagt RGT, dass der L1 größer werden soll und weniger Latenz hat. Das ist imho totaler Quatsch, denn die L1-Caches sind für ihre Taktraten und Größen am absoluten Limit. Intel musste für Sunny Cove sogar auf 5 Takte hochgehen, weil 4 Takte bei 5Ghz, 48kB und 128B/Takt wohl nicht mehr zu halten war.

Dass AMD irgendwo den heiligen Cache-Gral herzaubert, mit dem plötzliche alle Caches schneller werden, glaube ich nicht.Oder es gibt einen zusätzlichen L0-D$ mit z.B. 4kB und nur 2 Takten oder sowas. Hitrate ist dann zwar nur mittelprächtig aber aus Performancesicht reicht es ja schon, wenn >70% der Zugriffe da hängen bleiben.
Auf Seiten des I$ gibt es ja quasi bereits einen L0 (den µOp-Cache) und woanders (bei GPUs) wurde schon gezeigt, daß auch schon ein sehr kleiner Registercache (die Register von GPUs sind ja massiv und haben am Ende auch mehrere Takte Zugriffslatenz) Performancevorteile (bzw. Stromersparnisse) bietet. Letzteres läßt sich zwar nicht direkt übertragen aber ist ja am Ende schon eine ähnliche Idee.

[robbitop]

Wäre es möglich, dass AMD ein ähnlichen Weg geht wie IBM? Dort wird der L2 Cache als virtueller L3 Cache über alle Kerne geteilt. Der lokale L2 ist schneller - also es gibt einen gewissen latency hit wenn man auf den L2 anderer Cores will aber man braucht keinen L3 mehr bei IBM.

Wenn bei Zen 5 der ccd auf den iod gestapelt wird, kann man auch schnellere Latenzen erwarten was dann widerum eröffnen könnten im IOD einen gesharten L3/L4 Cache für alle CCDs anzubieten der nich sinnvoll schnell ist (aber sicher langsamer als der heutige L3 aber mit einem virtuellen L3 als Zwischenstufe ggf sinnvoll).

[HOT]

Na ja, IBM legt einen Virtuellen L3 innerhalb aller L2 an. Das sieht ja jetzt erst mal nicht so aus. MMn sieht das eher so aus, als würde AMD X3D zum Standard machen. Einfach gestapelt: Träger -> IOD mit LLC in N6 -> 2 CCDs ohne L3, dafür aber unglaublich fetter, nicht unbedingt in N3, könnte auch N4X sein aus Kostengründen. Aus Leistungssicht ohne APU wäre das ja ok, da N4X sogar mehr leisten kann als N3 u.U. Ohne L3 kann man die Chipletgröße im Griff halten.

[Nightspider]

Ich könnte mir auch vorstellen das man den L2 on die halbiert aber dafür nochmal zusätzlich die doppelte Menge L2 mit auf den V-Cache Chip platziert.
Das reduziert die Latenzen doch ein gutes Stück.

Genauso könnte AMD den L3 on Die halbieren und den Großteil via V-Cache realisieren. Würde die Latenzen weiter verbessern. Stacking könnte bei Zen5 ja eventuell immer dazugehören.
Dadurch würde massiv Platz frei werden für µOp-Cache, Branch Prediction und den ganzen Kram (kenne mich da nicht so gut aus). Es gab ja auch schon Gerüchte das die Architektur deutlich breiter wird.
Dadurch könnte man die IPC sicherlich nochmal ein riesiges Stück anheben, gerade im Vergleich zu aktuellen Prozessoren.
Wenn die ~25-30% für jeweils Zen4 und Zen5 stimmen wäre das schon ein heftiger Wandel im Vergleich zu den 10 langweiligen Jahren die es gab und wo erzählt wurde, die IPC wird nicht mehr großartig ansteigen.

Technologisch scheint man ja zumindest in der Lage zu sein den Cache noch weiter deutlich zu vergrößern und die Latenzen sogar zu senken, durch mehr Lagen beim V-Cache.

V-Cache Gen2 oder Gen3 könnte in der 2. Dimension schrumpfen aber durch mehr Lagen anwachsen. -> bessere Latenzen -> mehr Cache

Das Problem wird vielleicht eher, wenn die Kerne selbst wachsen, bzw. die Architektur deutlich breiter wird, dann entfernen sich die Bereiche ja trotzdem vom Cache, außer man platziert die Kontaktierungen für den Stacked Cache mittiger in den Kernen aber dann würde der Cache über der Logic sitzen, was Probleme bei der Wärmeabfuhr verursacht. Man müsste den V-Cache dann auf die andere Seite des Logic-Chips bekommen.

[Skysnake]

Oder es gibt einen zusätzlichen L0-D$ mit z.B. 4kB und nur 2 Takten oder sowas. Hitrate ist dann zwar nur mittelprächtig aber aus Performancesicht reicht es ja schon, wenn >70% der Zugriffe da hängen bleiben.
Auf Seiten des I$ gibt es ja quasi bereits einen L0 (den µOp-Cache) und woanders (bei GPUs) wurde schon gezeigt, daß auch schon ein sehr kleiner Registercache (die Register von GPUs sind ja massiv und haben am Ende auch mehrere Takte Zugriffslatenz) Performancevorteile (bzw. Stromersparnisse) bietet. Letzteres läßt sich zwar nicht direkt übertragen aber ist ja am Ende schon eine ähnliche Idee.

Ist jetzt vielleicht nen epyc fail, aber genau das machen doch moderne CPUs schon lange. Die haben Schattenregister durch die Sie Dinge renamen können und so eben mehr in den Registern halten als eigentlich von der Architektur her möglich.

Die Details habe ich jetzt nicht im Kopf, aber zumindest bei einer nonx86 Architektur bin ich mir ziemlich sicher, dass die das machen.

[Der_Korken]

Oder es gibt einen zusätzlichen L0-D$ mit z.B. 4kB und nur 2 Takten oder sowas. Hitrate ist dann zwar nur mittelprächtig aber aus Performancesicht reicht es ja schon, wenn >70% der Zugriffe da hängen bleiben.

Reichen zwei Takte überhaupt für die Adressauflösung durch den TLB? Weil einen virtuellen Cache will man sich mit SMT bestimmt nicht antun. Außerdem wäre ein L0$ vom Namensschema her geschummelt, denn der shared L2 über das ganze CCX wäre nach alter Zählweise eigentlich ein L3$ :D.

Edit: Was ich bei den 7-8 Takten für einen hypothetischen 128-256kB-L1D nicht bedacht habe ist, dass die Adressübersetzung fertig sein muss, bevor man den Cache durchsuchen kann. Dadurch würde sich ein L0 vielleicht wirklich lohnen, weil man bei einem L0-miss dann wenigstens schon die physische Adresse kennt.

[iamthebear]

Ich stecke nicht so tief in der Materie drin, aber wäre es irgendwie sinnvoll ein wenig primitive Rechenlogik am Cache anzubauen? Statt Loads und Stores zwischen Cache und Registern hätte man z.B. eine Inkrementier-Operation, die Daten aus dem Cache lädt, diese aber nicht in die Register schreibt, sondern am Cache eine Addition durchführt und das Ergebnis sofort wieder in den Cache schreibt?

Eine kleine Addition hört sich viel einfacher an als es eigentlich ist. Diese dauert auch mehrere Takte.

Abgesehen davon:
Man will in der Regel nicht 1 Wert vom L3 lesen, nur eine Addition machen und wieder zurück in den L3 schreiben.
Wenn mit Daten vom L3 irgendetwas gemacht wird, dann wird das Ergebnis irgendwo im L1 abgelegt falls dieses nicht sowieso in einem Register stehen bleibt. In der Regel werden gerade berechnete Ergebnisse in den nächsten paar Codezeilen gleich wieder verwendet, oftmals gleich direkt danach.

Abgesehen davon:
In der Praxis werden Befehle nicht nacheinander ausgeführt. Es werden gleich um die 500 Befehle auf einmal geladen, es wird spekuliert wo der Code hinspringen wird und welche Befehle von welchen abhängen und dann werden so viele Befehle wie möglich gleich parallel ausgeführt oder falls dies nicht möglich ist zumindest alle verwendeten Variablen schon im Vorhinein auf Verdacht geladen.

Oder es gibt einen zusätzlichen L0-D$ mit z.B. 4kB und nur 2 Takten oder sowas. Hitrate ist dann zwar nur mittelprächtig aber aus Performancesicht reicht es ja schon, wenn >70% der Zugriffe da hängen bleiben.

Dann könntest du aber genauso gut sagen "L1 und L2 werden verkleinert, sind aber dafür schneller, L3 bleibt wie gehabt und es kommt ein zentraler L4 per Stacking dazu".

Die Frage ist jedoch, ob es etwas bringt die L1 Latenz zu senken. Das hat schon einen Grund warum dieser seit Jahren immer ca. dieselbe Größe hat nämlich weil es bis zu 4 Takten anscheinend noch möglich ist alle verwendeten Daten rechtzeitig vorzuladen.

Auf Seiten des I$ gibt es ja quasi bereits einen L0 (den µOp-Cache) und woanders (bei GPUs) wurde schon gezeigt, daß auch schon ein sehr kleiner Registercache (die Register von GPUs sind ja massiv und haben am Ende auch mehrere Takte Zugriffslatenz) Performancevorteile (bzw. Stromersparnisse) bietet. Letzteres läßt sich zwar nicht direkt übertragen aber ist ja am Ende schon eine ähnliche Idee.

Also ich weiß nicht, ob es generell viel Sinn macht die Konzepte von GPUs auf CPUs zu übertragen. Bei GPUs geht es um Performance/Transistor, bei CPUs geht es um single threaded Performance und man muss alles tun was möglich ist um selbst jegliche Parallelität im Code zu erkennen und auszunützen.

Wäre es möglich, dass AMD ein ähnlichen Weg geht wie IBM? Dort wird der L2 Cache als virtueller L3 Cache über alle Kerne geteilt. Der lokale L2 ist schneller - also es gibt einen gewissen latency hit wenn man auf den L2 anderer Cores will aber man braucht keinen L3 mehr bei IBM.

Wäre möglich allerdings muss ich sagen, dass mich die Latenzen von 19 Zyklen bei IBM da nicht wirklich überzeugt haben. ADL hat afaik 12 Zyklen für den L2.

Wenn bei Zen 5 der ccd auf den iod gestapelt wird, kann man auch schnellere Latenzen erwarten was dann widerum eröffnen könnten im IOD einen gesharten L3/L4 Cache für alle CCDs anzubieten der nich sinnvoll schnell ist (aber sicher langsamer als der heutige L3 aber mit einem virtuellen L3 als Zwischenstufe ggf sinnvoll).

Ich denke nicht, dass die Compute Dies irgendwo drauf gestapelt werden. Das ist beim Cache schon kritisch aber IO Die + Compute Die würde Hitzeprobleme geben.
Abgesehen davon: Was passiert dann mit 2 Compute Does wie dem 5950X?

Was die L3 Latenzen angeht:
Ich kann mich da an einen Win11 Bug erinnern durch den die L3 Latenz bei Ryzen von ca. 10ns auf 30ns hochgeschossen ist und man hat in Benchmarks kaum etwas gemerkt. Von daher sehe ich das nicht wirklich als tragisch an wenn da die Latenz etwas ansteigt.

Ich könnte mir auch vorstellen das man den L2 on die halbiert aber dafür nochmal zusätzlich die doppelte Menge L2 mit auf den V-Cache Chip platziert.
Das reduziert die Latenzen doch ein gutes Stück.

Und wie stellst du dir das genau vor den L2 in den V Caxhe zu stecken?

[Nightspider]

Und wie stellst du dir das genau vor den L2 in den V Caxhe zu stecken?

Extrem vereinfacht in etwa so:

https://abload.de/img/stacking1onjda.png

Bzw. könnte man den On-Die-Cache reduzieren durch 2 Lagen V-Cache, wodurch die Cache-Area auf dem CPU Chiplet kleiner ausfallen würde.
Und mit den Durchkontaktierungen (gelb) jeweils in der Cache Mitte für möglichst geringe Wege und Latenzen.:

https://abload.de/img/stacking32mk2x.png

Vielleicht geht das nicht weil der L2 dann zu weit entfernt wäre von der Logic, da kenne ich mich zu wenig aus.

Aber wenn man den L0/L1 etwas vergrößert, vielleicht kann man die Distanz zum deutlich größeren L2 kompensieren, der ja durchs Stacking auch geringere Latenzen hätte.

Wenn ich das hier aber so sehe, schein der L2 bisher auch primär am Rand zwischen Logic und L3 zu sitzen:

https://cdn.wccftech.com/wp-content/uploads/2020/11/AMD-Ryzen-5000-Zen-3-Desktop-CPU_Vermeer_Die-Shot_1-scaled.jpg

Edit:

Jetzt habe ich in Paint mal etwas hin und her geschoben. Sowas kann ich mir auch vorstellen. Alles unwichtige im CPU Chiplet in die Mitte unter den V-Cache Stapel und kein L2 und L3 auf dem CPU Chiplet sondern nur im V-Cache-Chip.

https://abload.de/img/stacking4rpjhk.png

Quasi 2 zusätzliche Reihen Kontaktierungsbereich nach dem L2 für den L3.

L2 mit 2 Flügeln (aufgeklapptes Buch) und L3 nur mit einem Flügel damit der Kontaktierungsbereich im Hauptchip nicht mit anderen Bereichen kollidiert.
Würde bei 2 Layern 4 fachen L2 bedeuten aber nur 2 fachen L3. Aber das ist jetzt auch nur eine Idee von Vielen die mir im Kopf wären.
Man könnte auch "einen Flügel" L2 Area auf dem Hauptchip vor dem L3 Kontaktierungsbereich setzen für 3 fachen L2 (1 Layer) oder 5 fachen L2 (2 Layer).

Oder man macht es noch verrückter und stapelt verschiedene V-Cache Chips. Die untere Lage mit L2+L3 und die obere Lage mit doppeltem L3.

https://abload.de/img/stacking5nxka8.png

Je mehr ich überlege, desto mehr Varianten fallen mir ein.

Falls an die Bereiche Global Memory Interconnect und System Management Unit nicht in die Mitte packen kann würden mir bestimmt auch andere Möglichkeiten einfallen.

Ich kann mir aber vorstellen, das der L2 viel mehr Verbindungen bräuchte wegen der höheren Datenrate und dadurch der Platzbedarf für die L2 TSVs deutlich höher wäre als beim L3.

Nagelt mich nicht darauf fest, das sind Gedankenspiele meinerseits.

[iamthebear]

Ich meine damit was ist an deinem gestckten L2 anders als an dem L3, der schon auf dem Die sitzt.
Die Latenzen der einzelnen Cachstufen sind vereinfacht erklärt dadurch bestimmt:
.) Wie groß der Cache ist (Faustregel doppelt so groß bedeutet 1 Takt höhere Latenz)
.) Mit wievielen Kernen werden die Daten geteilt
.) Die Latenz aller Cachestufen davor da die Caches nacheinander durchsucht werden

Wenn du jetzt 16MB L2 neben 64MB L3 stackst und beide mit allen Kernen teilst dann macht das relativ wenig Sinn, da der L2 dann nicht nennenswert schneller als der L3 sein wird.

[Skysnake]

Die Caches werden nicht zwingend seriel durchsucht. Das macht man "nur" um Energie zu sparen. Gibt/Gab aber auch CPUs die das nicht gemacht haben.

Die erhöhten Latenzen kommen von den Lookups ob die gesuchte Adresse im Cache liegt oder nicht.

[Der_Korken]

Bei Nightspiders Ansatz ist der L2 natürlich weiterhin privat. Wenn man den L2 stapelt, dann bleibt er von der Fläche her so klein wie bei Zen 3, kann aber z.B. auf 1,5MB wachsen. Keine Ahnung, ob das bei so kleinen Flächen schon einen Latenzvorteil bringen würde gegenüber einem planaren Cache. Beim L3 scheint es jedenfalls so zu sein, da hier der Latenzzuwachs durch den 3D-Cache extrem gering war. 1 Takt pro Verdopplung scheint mir bei Cachegrößen >1MB nicht mehr zu stimmen.

[HOT]

Nightspider

Wirklich interessante Gedanken. Aber ich würd eher sagen, dass die CCDs diesmal nur noch Logik und wenig Cache enthalten und sich das stacking umdreht. Beim X3D ist das Cache-Die nichts weiter als simpler Cache, extrem billig gemacht und produziert. Bei Zen5 wird das aber ein IOD sein, dass könnte dann die TSVs enthalten und nicht mehr das CCD. Das hätte auch den riesigen Vorteil, dass das CCD wieder direkt am Kühler, also an oberster Stelle, positioniert ist. Ich denke, das IOD wird fast sämtlichen Cache enthalten und wird dadurch auf ca. 200mm² anwachsen, damit wären auch sämtliche Anschlüsse und sämtliches I/O-Geraffel aus dem CCD raus. Die CCDs könnte man einfach darauf stapeln und dann das Ganze verlöten. Damit hätte man auch die Wärmeableitung da, wo sie hingehört.

[basix]

Ich sehe es nicht als sinnvoll an, die CCDs aufs IOD zu stapeln. Dadurch verliert man einen der grössten Vorteile von Zen: Einfache Skalierbarkeit. Zen 4 geht von 1-12 CCDs. Will man was ähnliches mit einem gestackten IOD haben, müsste man viele verschiedene IOD haben oder viele Dummy Die.

Ich sehe es als deutlich sinnvoller an, das Design ähnlich wie bei Zen 2-4 zu halten und Cache+IFOP mit einem Logic Die zu stacken. In letzerem sitzen die Cores.

[Complicated]

AMD könnte vielleicht das IOD mehr nach RDNA3 MCM mit dem IF$ gestalten um es skalierbar zu machen, ohne mehrere verschiedene IO-Dies. Keine Ahnung ob das für CPUs ebenfalls sinnvoll sein kann um CCDs zu skalieren. Aber vielleicht gibt es da etwas revolutionäres.

Könnte vielleicht auch eine alternative Erklärung für den gemeinsamen L2$ liefern.

[Tangletingle]

Weshalb sollten viel Dummy dice notwendig sein? Den Höhenunterschied kann man doch mit Resin ausgleichen.

Wenn es solche Chips geben sollte, dann wohl eher im mobilen Bereich.

[basix]

Du hast bei dir Cores und L2 auf einer Ebene und L3 auf einer anderen. Während bei Stacking oft die Funktionalität zwischen den Ebenen aufgeteilt wird, finde ich beim Stacking viel reizvoller, dass sich damit große Caches mit niedriger Latenz realisieren lassen. Wenn du schon einen Cache-Die unter deinen Core-Die schiebst, warum verwendest du nicht die Zellen unterhalb des L2 nicht als L2-Erweiterung? Dann hättest du statt 4MB L2 z.B. 12MB mit guter Latenz.

Kann man machen, ja. Und wäre gewissermassen aufgrund der kurzen Wegstrechekn auch sinnvoll. Ich sehe aber ein paar Probleme:
- Das gestackte Die mit den Cores wird recht klein, noch kleiner als eh schon (ich rechne mit ~50mm2 in N3 für 16C)
- Bandbreiten beim L2$ sind bei Zen etwa ~3x höher als beim L3$. Benötigt viele 3D-SoIC Verbindungen oder höhere Takt. Flächenbedarf? Stromverbrauch?
- Energieverbrauch Datentransfer On-Die vs. 3D-SoIC? Wegstrecke müsste deutlich kürzer sein, damit der Vorteil wirklich greift.

512kB -> 1MB ist ausserdem gar nicht so tragisch bezüglich Flächenverbrauch. L2$ Control & Tags benötigen gleich viel oder sogar etwas mehr Platz wie die 512kB SRAM. Im besten Fall benötigt der verdoppelt L2$ also nur 1.5x der Fläche.

Weshalb sollten viel Dummy dice notwendig sein? Den Höhenunterschied kann man doch mit Resin ausgleichen.

Und wieso macht man das mit dem Resin heute auch nicht? Oder hast du entsprechende Designs mal gesehen? Ich nicht. Egal ob CPU, GPU oder HPC Chips. Alles mit Interposer und Stacked Chips oder HBM verwendet entweder ein kaputtes "richtiges" Die oder ein Dummy Die. Einzig Substrat-basierte Designs wie Epyc scheinen ohne sowas auszukommen.

Ausserdem hat AMD selbst schon bei Zen 2 erklärt, dass Interposer für ihre Scalability und Performance Ansprüche nicht genügen. Viele CCDs benötigen viel Platz. Mit 3D-Stacking aufs IOD verschärft sich diese Problem nochmals massivst. Oder wie willst du 12 CCDs auf ein IOD stacken? Auch nur am Rand des IOD wird man bei vielen CCD einfach nicht genug Platz haben. Und dann noch mit all dem IO Zeug wie PCIe und DDR aus dem IOD raus? Quer dort durch, wo die CCDs allenfalls bereits den Platz belegen?
https://www.overclock.net/attachments/pioneering-chiplet-technology-and-design-for-the-amd-epyc-and-ryzen-processor-families-pdf.2517924/

Ne, AMD wird auch weiterhin bei einem zentralen IOD und Substrat-basierten IFOP Verbindungen festhalten. Dazu ist das Packaging der CPU günstiger. Dass man irgendwas am IOD oder den CCDs in sich selbst 3D-Stacked, ja (zum Beispiel den L3-Cache). Aber nicht dass man IOD+CCD stacked. Bei wenigen CCDs (z.B. 4 Stück) könnte man darüber sprechen. Das limitiert dann aber die Skalierbarkeit zwischen Dekstop -> Server deutlich. Und jetzt geht man bei Zen 4 von 8 -> 12 CCDs. Das ist doch ein deutlicher Fingerzeig entgegen den IOD+CCD 3D-Stacking Überlegungen.

[Nightspider]

Bei Nightspiders Ansatz ist der L2 natürlich weiterhin privat. Wenn man den L2 stapelt, dann bleibt er von der Fläche her so klein wie bei Zen 3, kann aber z.B. auf 1,5MB wachsen. Keine Ahnung, ob das bei so kleinen Flächen schon einen Latenzvorteil bringen würde gegenüber einem planaren Cache. Beim L3 scheint es jedenfalls so zu sein, da hier der Latenzzuwachs durch den 3D-Cache extrem gering war. 1 Takt pro Verdopplung scheint mir bei Cachegrößen >1MB nicht mehr zu stimmen.

Genau so meinte ich das. Die Dimensionen in meinen Bildern stimmen natürlich nicht, das war nur ein bisschen mit Paint zusammengebastelt.

Aber ich würd eher sagen, dass die CCDs diesmal nur noch Logik und wenig Cache enthalten und sich das stacking umdreht. Beim X3D ist das Cache-Die nichts weiter als simpler Cache, extrem billig gemacht und produziert. Bei Zen5 wird das aber ein IOD sein,

Es ist gut möglich, das unter den 3nm/4nm Zen5 Core Complex Die ein oder zwei Cache-Layer kommen und darunter oder dazwischen dann noch ein Chip mit diversen Controllern usw. sitzt aber da müssten wir uns noch Gedanken machen wie dein ein Prozessor mit 2 CCDs aussehen wird.

Eventuell wird dann ein Layer von der Größe verdoppelt, zB. der Controller/IO Layer und alle anderen Cache und Logic Layer werden daran gesetzt. Die GPU müsste dort ja dann auch noch rein, selbst wenn sie nur 4/8 CUs bekommt.

So in etwa könnte ich mir das vorstellen:

https://abload.de/img/stacking6t2jp3.png

Also das ist jetzt die Variante mit doppeltem Controller/IO Layer für die Variante mit 32 Kernen. (16 Zen5 + 16 Zen4)

Dass das teuer werden würde und schwierig in der Fertigung darüber brauchen wir nicht reden.
Ich halte das irgendwie auch nicht für die eleganteste Lösung aber ganz grob wird es vielleicht in Zukunft irgendwann in diese Richtung gehen.
Wäre nur ein viel zu extremer Schritt von Zen3D und wahrscheinlich auch Zen4D.

Ich schätze die L2/L3 Controller müssten schon auf dem CCD bleiben, sonst wird das mit den Latenzen meiner Meinung nach schwieriger und von der Aufteilung habe ich dann auch nichts sinnvolles mehr hinbekommen. Außer alles verschwimmt viel filigraner.
Aber so hab ich zB. das Problem das der L2 Controller näher an den Zen5 Cores wäre und die Zen4 Cores näher am L3 Cache Controller sitzen würden. Es kommt sich alles so ein bisschen in die Quere.

Der Controller-Layer könnte natürlich viel kleiner werden und mit SI-Dummies aufgefüllt werden an den Seiten. Es soll eigentlich nur grob eine Skizze sein wie ich mir das vorstellen könnte.

Edit:

Oder man verbindet zwei getrennte Controller Layer auf der Höhe eines Cache-Layers mit einer Bridge:

https://abload.de/img/stacking7v4jt4.jpg

Oder man man entwirft vom L3 Cache Layer eine doppelt so große Variante wo alle anderen Chips auf diesen L3 Cache Layer draufgestapelt werden.
Wenn der statt 30-40mm² dann 80mm² in N6 wäre, wäre das noch kostengünstig genug, da Redundanzen Fehler auffangen.

Möglichkeiten gibts imo viele. Welche davon jetzt am meisten Sinn macht werden AMDs Ingenieure sicherlich komplex simulieren lassen.

[HOT]

Interessante Sicht:
https://wccftech.com/amd-zen-5-cpus-tsmc-3nm-2024-2025-delay-rumor/

Klar verzögern sich viele Produkte, die durch die N3-Verzögerung keinen Fertigungsslot mehr bekommen können.

Jedoch ist es bei AMD eigentlich nicht der Fall gewesen, dass man aktuelle Fertigung für CPUs verwendet hat.
TSMCs N7 wird seit Frühjahr 2018 produziert, CPU kam im Juli 2019. N5 wird seit Frühjahr 2020 produziert, CPU kommt Q3 2022, wie es aussieht. TSMC hätte N3 ab Q3 2022 produziert (jetzt wirds ja Q4), AMDs CPU wäre dann fällig, bleibt man bei der 5 Q-Regel, Ende 2023. Das wäre für AMDs Verhältnisse sehr knapp gewesen mit einem N3-Zen5. Nicht unmöglich, aber doch unwahrscheinlich aus meiner Sicht. Ich denke, Zen5 könnte schon aus Kostensicht nie für N3 vorgesehen gewesen sein.

Eine andere Option für Zen5-Chiplets wäre mMn übrigens auch Samsung. Würde zeitlich zu 3GAE evtl ganz gut passen, wäre aber ein größeres Risiko für AMD gewesen. Aber am wahrscheinlichsten ist N4(X) - oder eben ein N3-Derivat aber dafür von Anfang an 6-7 Quartale bis Zen5. Da aber Zen5 schon Gegenstand vom Marketing ist, glaub ich nicht an sonderliche Verzögerungen. Allgemein ist das ein bisschen schwer abzuschätzen.

[Nightspider]

Halte ich an Hand der engen Kooperation von AMD und TSMC die letzten Jahre eher für unwahrscheinlich.
Zumal sich Intel ja auch erstmal unbeliebt gemacht hat bei TSMC. Bevor Intel AMD verdrängen hätte können mit viel Geld hätte TSMC bestimmt erstmal mit AMD gesprochen und nachverhandelt.

[Lehdro]

Was für ein Schwachfug. Warum sollte TSMC den Hauptkonkurrenten einer ihrer besten Kunden so krass bevorzugen, wenn genau dieser so schnell wieder weg sein wird wie er seine eigene Fertigung in den Griff kriegt?
Im Endeffekt schießt man sich dann für 1-2 Jahre für ein wenig mehr Profit komplett ins eigene Knie und geht noch das Risiko ein das AMD entweder abwandert oder sogar die Hufe komplett hochmacht wenn man sie am ausgestreckten Arm verhungern lässt fertigungstechnisch.
TSMC ist im Business für ihre Fairness bekannt, so einen Move traut man eigentlich nur Intel und NV zu. Zudem wird AMD sich auch langfristig Fertigungskapazität gesichert haben, ich würde wetten N3 Allokation ist bei AMD schon in trockenen Tüchern. Es wäre ziemlich fahrlässig von AMD, vor allem nach den Erfahrungen mit der 7nm Knappheit, hier nicht frühzeitig zuzuschlagen. AMD ist zudem schon VIP bei TSMC, anders als Intel die sich nur teuer einkaufen aber keine langfristige Perspektive bieten.

[HOT]

Interessante Punkte. Ich sehe in Intels N3-GPUs aber schon den Hauptgrund AMD bei N3 das Wasser abzugraben. Hinzu käme sicherlich auch noch BattleMage. AMD ist sicherlich ein guter TSMC-Kunde, aber bei Firmen, die extra Geld zahlen?

[Linmoum]

Wenn AMD sich schon vor Jahren entsprechende Kapazitäten gesichert hat, dann kommst du auch mit extra Geld nicht weit, wenn du dafür später dran bist.

[Nightspider]

aber bei Firmen, die extra Geld zahlen?

TSMC kassiert eigentlich im Moment eh schon massiv Geld und wird vom Staat gefördert und sind jetzt nicht dafür bekannt die Kunden auszunehmen.
Sie bleiben auch die Nummer 1 wenn sie AMD nicht von der Bettkante stoßen und AMD hat die letzten Jahre auch für viel Umsatz bei TSMC gesorgt.

[davidzo]

Interessante Punkte. Ich sehe in Intels N3-GPUs aber schon den Hauptgrund AMD bei N3 das Wasser abzugraben. Hinzu käme sicherlich auch noch BattleMage. AMD ist sicherlich ein guter TSMC-Kunde, aber bei Firmen, die extra Geld zahlen?

Nee, abgraben wird das auch nicht sein. Wenn AMD mit N3 geplant hat, dann wird man auch ausreichend Kapazitäten reserviert haben. Die kann TSMC dann nicht einfach an Intel umdisponieren. Ich glaube viel eher dass die Intel Kapazitäten eben zusätzliche Kapazitäten sind, die man über eine vor ein-zwei Jahren aufgestockte Scanner-Bestellung realisieren konnte. Intel wird das komplett vorfinanziert haben damit man kurz nach oder gleichzeitig zu Apple schon bei der Risk production dabei sein darf. AMD wird die Risk production überspringen und ganz nach plan erst in der Volume production dabei sein.

Vor Zen5 kommt sowieso noch Zen4C und im Desktop definitiv Zen4x3D und da kann man immer noch eine Zen4 XT Refresh-generation dazwischen schieben.
Zen4 wird einfach eine 2 Jahre lange Generation, genauso wie Zen1 für Ryzen1000 und Ryzen2000 hinhalten musste.

AMD braucht sich da auch überhaupt keine sorgen machen, denn Intel wird N3 nur im mobile bringen und bei GPUs. Und im mobile hat Intel einen dermaßen großen Effizienzrückstand, vor allem auch bei der GPU, dass AMD sich da auch mit der 5nm Phoenix APU keine sorgen machen muss.
Im Desktop sehen wir sowieso viel länger Intel 7 und Intel 4 CPUs und die sind mit N7 und N5 recht vergleichbar.
Und bei GPUs ist noch nicht einmal klar ob Intels Bemühungen nicht total floppen. Die Verspätungen sind ja bereits gigantisch. Wenn das so bleibt, dann sind Intels N3 Risk-Kapazitäten bloß für die kleine Meteorlake IGP und für ein paar testchips von Battlemage geeignet.

[Zossel]

Was für ein Schwachfug. Warum sollte TSMC den Hauptkonkurrenten einer ihrer besten Kunden so krass bevorzugen, wenn genau dieser so schnell wieder weg sein wird wie er seine eigene Fertigung in den Griff kriegt?
Im Endeffekt schießt man sich dann für 1-2 Jahre für ein wenig mehr Profit komplett ins eigene Knie und geht noch das Risiko ein das AMD entweder abwandert oder sogar die Hufe komplett hochmacht wenn man sie am ausgestreckten Arm verhungern lässt fertigungstechnisch.

TSMC denkt wahrscheinlich weiter als die typische dumpfe US-Butze die eigentlich nur bis zum nächsten Quartalsbericht denkt.
Mit AMD kann TSMC langfristig einfach mehr Anteile im X86 Markt abgreifen.

[TheAntitheist]

TSMC denkt wahrscheinlich weiter als die typische dumpfe US-Butze die eigentlich nur bis zum nächsten Quartalsbericht denkt.
Mit AMD kann TSMC langfristig einfach mehr Anteile im X86 Markt abgreifen.
warum hat denn TSMC ein Interesse, Anteile (AMDs Anteile wohlgemerkt) im x86 Markt zu gewinnen? Bitte gerne mal detailierter.

[Zossel]

warum hat denn TSMC ein Interesse, Anteile (AMDs Anteile wohlgemerkt) im x86 Markt zu gewinnen? Bitte gerne mal detailierter.

Umsatz und Gewinn ist das was Firmen im allgemeinen anstreben und antreibt.
Der Markt für X86 ist groß, also hat auch TSMC ein Interesse sich ein Stück vom Kuchen zu holen.

[iamthebear]

Einmal abgesehen ist der x86 Markt auch politisch sehr wichtig. Wenn der x86 Markt nicht beliefert werden kann hat ein Großteil der Weltwirtschaft ein ernsthaftes Problem. Das gibt eine gewisse Machtposition und sorgt dafür, dass man nicht in diversen Sanktionspaketen gefangen wird bzw. kann für den ein oder anderen politischen Kuhhandel genutzt werden.

Einmal abgesehen davon: Jeder Euro den AMD mehr Umsatz im x86 Markt macht ist ein Euro, den Intel nicht in die Forschung der nächsten Fertigungstechnologie stecken kann.

[basix]

Einmal abgesehen davon: Jeder Euro den AMD mehr Umsatz im x86 Markt macht ist ein Euro, den Intel nicht in die Forschung der nächsten Fertigungstechnologie stecken kann.

Oder noch einfacher: Umso mehr Euros AMD macht, desto mehr Euros für TSMC ;)

[TheAntitheist]

Ihr habt keine Argumente geliefert warum TSMC lieber Geld mit x86 Produkten machen sollte als mit anderen. Auch das Intel dadurch etwas weniger Umsatz macht ist vollkommen egal, die haben immer noch genug für RnD.
TSMC geht es nur darum Geld zu verdienen.

Das Werk was in den USA gebaut wird hat viel mehr Politische Bedeutung.
Wenn TSMC wirklich diese Branche so wichtig gewesen wäre, hätten sie AMD viel mehr Wafer gegeben. Haben sie aber nicht. TSMC wird neutral bleiben soweit wie möglich, denn DAS wollen die Kunden.

Und bis vor 2 Jahren hat doch sogar Intel TSMC mehr Umsatz beschert als AMD. Nvidia wurde ja auch mit "Kusshand" zurück geholt. Ist natürlich genauso ein Quatsch. Angebot und Nachfrage das ist alles.

[amdfanuwe]

Ihr habt keine Argumente geliefert warum TSMC lieber Geld mit x86 Produkten machen sollte als mit anderen.
Nicht lieber, sondern zusätzlich.
Es geht um Wachstum.
Zudem benötigt AMD einen HPC Prozess. Je mehr, um so billiger.
Apple, Qualcom, etc. benötigten ja eher Mobile Prozesse.
Mit einem kostengünstigen HPC Prozess wird man auch für weitere Kunden interessanter.
Letztendlich sieht man ja auch, welcher Wafermengen Intel umsetzt. Da kann man noch einiges abgreifen, wenns für AMD läuft.

[basix]

Ich habe noch eine Theorie zu Zen 5 & Zen 5c:
- 3D-Stacked, 3D_SoIC, ob Wafer-on-Wafer oder Chip-on-Wafer ist mir aber unklar
- N6 Base Die mit IO + 64MByte L3$ --> ~60mm2
- Zen 5 & 5c teilen sich das selbe Base Die
- Zen 5: 16C pro Chiplet / CCD / CCX (Unified L3$)
- Zen 5c: 32C pro Chiplet (halbierter L2$, halbierte AVX-Unit, etwas schlankere & Density optimiertere Cores)
- Zen 5/5c: Option für shared L2$? Jeweils 2-4x Cores sind als Cluster zusammengeschaltet

Big.Little:
- Wäre denkbar, aber kein muss
- Beispiel 1: Ryzen mit 1x Zen 5 CCD + 1x Zen 5c CCD
- Beispiel 2: EPYC mit 4x Zen 5 CCD + 4x Zen 5CCD

[HOT]

Maximal hat Zen5 12C pro Chiplet. 16C wäre Verschwendung. Man muss auch die Marktverhältnisse im Auge behalten. Eine CPU mit 12C (salvage dann 8C) wäre die Brot-und-Butter CPU in der Gen. Mit 2 Chiplets kommt man dann auf 16C und 24C, also perfekt um mit Intel zu konkurrieren.
Zudem: Zen5c wird meiner Theorie nach wieder komplett gleiche CPU nur dichteres Design, dann 16C pro Chiplet.

Wäre dann auf jeder Seite 6C, wieder Ring+ Design mit 48MB L3$. Stackt mit weiteren 64-96MB Cache im Basedie, was gleichzeitig IOD ist, halte ich für sicher.

[Linmoum]

N4 und N3 für Zen5 und "New Grounds-up Microarchitecture" in 2024:

https://cdn.videocardz.com/1/2022/06/AMD-ZEN-ROADMAP.jpg

https://images.anandtech.com/doci/17439/2022-06-09%2013_18_10.jpg

[aufkrawall]

Offenbar kein Wort zu shittle.BIG, herrlich. Hoffentlich zwingt das Intel weiterhin zu schnellen Billig-Varianten, die nur ein Bruchteil kosten. Andererseits hätte ich in 2-3 Jahren schon gerne mal mehr als nur acht echte Kerne...

[ryan]

Uff wenn sie jetzt schon nur vage von 2024 sprechen, muss man von mindestens H2 2024 ausgehen. Die 2 Jahres Kadenz wird Normalität.

[MSABK]

Uff wenn sie jetzt schon nur vage von 2024 sprechen, muss man von mindestens H2 2024 ausgehen. Die 2 Jahres Kadenz wird Normalität.

Passt würde ich sagen, diesen Herbst Zen4, Herbst 2023 Zen4X3D und Herbst 2024 dann Zen5.

[Linmoum]

Uff wenn sie jetzt schon nur vage von 2024 sprechen, muss man von mindestens H2 2024 ausgehen. Die 2 Jahres Kadenz wird Normalität.Unwahrscheinlich, da Strix Point auf der Notebook-Roadmap für 2024 angesetzt ist. APUs stellt AMD immer auf der CES Anfang des Jahres vor.

[Nightspider]

Uff wenn sie jetzt schon nur vage von 2024 sprechen, muss man von mindestens H2 2024 ausgehen. Die 2 Jahres Kadenz wird Normalität.

Könnte genauso gut Q1/Q2 2024 bedeuten.

2023 kommen Zen4D und Zen 4c. Gibt wenig Gründe Zen5 noch Ende 2023 reinquetschen zu wollen.

Das wäre schon 1 Jahr nach Zen4 gewesen.

[HOT]

Passt würde ich sagen, diesen Herbst Zen4, Herbst 2023 Zen4X3D und Herbst 2024 dann Zen5.
Nein, passt nicht.
Zen4 in N5 HPC September 22, Zen4D Release und Phoenix Point in N4 (bestätigt im Foliensatz) sicherlich Vorstellung zur CES, Zen4c in N4 Mitte 23 aber noch 1.HJ (lt. Foliensatz) und Zen5 in sicherlich N4X Frühjahr 24. Das passt. Sonst wäre Zen5 N3 geworden.

Zen5 CCDs werden mMn weiterhin 8C sein und in N4X gefertigt. Sie dürften zudem recht groß werden in N4X, sicherlich 90mm².
Strix Point ist echt schwer zu bewerten z.Zt., aber es sieht ein bisschen so aus, also wenn er ähnlich zu Phoenix Point werden könnte, also weiterhin monolithisch (in der Folie steht Advanced Node und RDNA3+) und Zen5c dürfte sicherlich N3e werden mit mindestens 2 CCX pro Chiplet.

[fondness]

Offenbar kein Wort zu shittle.BIG, herrlich. Hoffentlich zwingt das Intel weiterhin zu schnellen Billig-Varianten, die nur ein Bruchteil kosten. Andererseits hätte ich in 2-3 Jahren schon gerne mal mehr als nur acht echte Kerne...

Jup, das big.LITTLE-Gerücht bei AMD scheint sich nicht zu bestätigen.

[basix]

Big.Little macht für mich nur in einer Mobile APU Sinn: Zen 4/5c in der APU (8C), bei Bedarf ein Zen 4/5 Chiplet via IFOP dranflanschen. Aber auch dieses Konzept hat so seine Nachteile.

[robbitop]

Andererseits hat man ohne kompakte Kerne in MT Benchmarks potentiell Nachteile. Man kann pro mm2 nicht so viele Cores verbauen. Für die meisten Consumer in der Praxis irrelevant mi 16C und mehr. Aber Benchmarks wollen die IHVs auch nicht.

[Der_Korken]

Es kommt auch drauf an, wie viel die großen Kerne an Strom und Platz verbrauchen. Bei AMD war das im Desktop bisher völlig unnötig, weil man problemlos 16 Kerne mit moderatem Verbrauch anbieten konnte und das für >99% der Anwender völlig ausreichend war. Bei Intel haben bis Rocket Lake bereits 8 Kerne jedes Verbrauchslimit sprengen können. Schnell waren sie, aber mehr als 8 war sehr schwierig. Wenn Zen 5 trotz aller Verbreiterungen immer noch 16 Kerne in 140 (oder 170)W gepresst bekommt, dann ist der Nutzen der kleinen Kerne im Desktop auch hier sehr überschaubar. Höchstens vielleicht beim Platzverbrauch, wobei ich zwischen Zen 4C und Zen 5 da nicht gleich Faktor 4 erwarte wie bei Intel (und auch nicht mehr als Faktor 2 bei der Performance). Bei Mobile oder Server hat man viel weniger W/Core, da brauchen wir nicht drüber zu reden.

[BlacKi]

Big.Little macht für mich nur in einer Mobile APU Sinn: Zen 4/5c in der APU (8C), bei Bedarf ein Zen 4/5 Chiplet via IFOP dranflanschen. Aber auch dieses Konzept hat so seine Nachteile.was derzeitige spiele angeht machen die little cores keinen stich. alles was du per big little im desktop gesehen hast, war alderlake. nur hat alderlake das big little conzept verkackt. der einzigste vorteil war die flächenersparniss, was intel schon jetzt konkurenzfähiger macht, aber die hauptvorteile für kunden hast du noch garnicht sehen können.


ich meine, warum hat das steam deck zen2 cores bekommen. die zen2 cores sind erheblich kleiner und erheblich stromsparender.


ein zen5 design mit big 8/16 cores (chiplet nr.1) und 32 little zen2 cores Chiplet nr.2) mit unterschiedlichen voltages, könnten wahnsinnige effizienzgewinne einfahren.


keine ahnung ob raptor schon soviel besser wird was diesen teil angeht, es könnte sein, das der sockel hier limitiert, aber spätestens mit meteor wird man 2 verschiedene spannungsversorgungen einführen, die dann eine effizienzsteigerung zulassen.

[mboeller]

ich meine, warum hat das steam deck zen2 cores bekommen. die zen2 cores sind erheblich kleiner und erheblich stromsparender.


ehh... nö

ein ZEN2 und ein ZEN3 Chiplet sind fast gleich groß. Da ist nicht viel um

[Linmoum]

Ein Zen3 Core ist ~15% größer als ein Zen2 Core. Das ist aber lächerlich, da wir hier absolut von ~0.4mm2 reden.

Und wie kommst du darauf, dass ein Zen2 Core "erheblich" stromsparender ist?

AMD geht nicht auf big.LITTLE auf absehbare Zeit. Sofern sie es überhaupt tun sollten. Man kann auch einfach direkt PE-Cores bauen, ohne das zu trennen. Nur weil Intel das nicht gebacken kriegt, gilt das nicht auch für AMD.

[BlacKi]

wollt ihr mich verarschen? die zahl 3 kam kein einziges mal vor XD

[Zossel]

Man kann auch einfach direkt PE-Cores bauen, ohne das zu trennen.

Was sind PE-Cores?

[Der_Korken]

Als Intel erstmals big.LITTLE auf ihren Roadmaps gezeigt hat, kam mir auch der Gedanke, dass Zen 2 eigentlich der ideale little core ist: Braucht wenig Platz, ist effizient, skaliert unfassbar gut nach unten. Seitdem sind die Kerne aber nicht stark gewachsen. Zen 3 ist kaum größer und Zen 4 kommt wie es scheint hauptsächlich über den Takt. Summa summarum wird Zen 4 also weiterhin ein relativ schlanker Kern bleiben (den größeren L2 kann man ja wieder halbieren, wenn man den als little core nicht braucht), den man vermutlich auch über den Takt wieder gut nach unten skalieren kann.

Intel hat hier einfach viel stärker reincomitted: Golden Cove ist im Vergleich zu Zen 3 gigantisch, Strom- und Platzverbrauch waren nicht die primären Designziele. Auch dass Intel bei 8 P-Kernen bleibt und stattdessen die E-Kerne pusht, ist eine schlüssige Designentscheidung, wenn man die P-Kerne weiter kompromisslos auf Leistung trimmt und sich Effizienz und MT-Power über die E-Cores reinholt. Insbesondere wird auch die Architektur letzterer deutlich an Bedeutung gewinnen, mehr vielleicht noch als die P-Kerne.

Das heißt aber nicht, dass wie ähnliches nicht auch bei Zen 5 oder später sehen. Man sieht ja schon an Zen 4C, dass AMD ihr Portfolio für verschiedene Anwendungen diversifizieren will und da könnte irgendwann auch ein hybrider Ansatz gut ins Konzept passen.

[basix]

Passt würde ich sagen, diesen Herbst Zen4, Herbst 2023 Zen4X3D und Herbst 2024 dann Zen5.

Zen 5c muss vor Ende 2024 erscheinen. Und wird mMn definitiv später dran sein, siehe auch Zen 4c. Meine Einschätzung:
- Zen 4 = Herbst 2022
- Zen 4c = Frühjahr 2023
- Zen 5 = Frühjahr 2024
- Zen 5c = Herbst 2024

Jeweils 1.5 Jahre oder 18 Monate dazwischen.

Andererseits hat man ohne kompakte Kerne in MT Benchmarks potentiell Nachteile. Man kann pro mm2 nicht so viele Cores verbauen. Für die meisten Consumer in der Praxis irrelevant mi 16C und mehr. Aber Benchmarks wollen die IHVs auch nicht.

Verglichen mit Intels Big Cores sind die Zen 3 Cores recht kompakt ;)

Und wie Korken gesagt hat, Zen 4 wird vermutlich auch noch relativ kompakt bleiben.

Was sind PE-Cores?

Platinum Edition, natürlich. Siehe Radeon X850XT PE ;)

[Linmoum]

wollt ihr mich verarschen? die zahl 3 kam kein einziges mal vor XDUnd worauf zielte "warum hat das steam deck wohl zen2 cores" sonst ab? Eine andere Alternative als Zen3 bleibt gar nicht übrig. ;)

Was sind PE-Cores?Na was sind bei ADL P-Cores und was E-Cores? Richtig, getrennt. Und statt zu trennen und zu mixen bringt AMD einfach P und E in einem Kern unter. ;)

[robbitop]

@basix
aber lange nicht so kompakt die wie e cores. Und Zen 5 wird sicherlich deutlich zunehmen, wenn man jetzt auch breiter werden will.

[BlacKi]

Und worauf zielte "warum hat das steam deck wohl zen2 cores" sonst ab? Eine andere Alternative als Zen3 bleibt gar nicht übrig. ;)


das war auf das steam deck bezogen. und da machen die 15% vorteil vermutlich sinn. da man sonst threads zurückstecken müsste. und weil man die rohe power von zen3 nicht wirklich benötigt. wie ich die letzten tage festgestellt habe, skaliert zen3 trotz höhererem verbrauch nur 11% in anwendungen wie cinebench, nur über den großen cache kommt man dank der spiele auf eine allgemeine 19% ipc ausgangslage.


was zen 5 angeht, muss man ja nicht zen2 als littlecore nehmen. würde sich aber aus o.g. gründen anbieten.


das man die p von die e durch die verschiedenen chiplets trennt hätte diverse vorteile, man kann damit reine p core cpus bauen, und umgekehrt und natürlich auch mixen.



wenn man die p und die e auf das chiplet verteilt, dann wäre man ziemlich gebunden und müsste salvagen für abweichungen. es hätte natürlich den vorteil, einfacher zu kühlen zu sein. aber gleichzeitig würdest du dir wieder probleme mit den straflatenzen einhandeln, wenn die cpu wieder über 8core performance in spielen herausskalieren soll. das könnte man mit getrennten unterschiedlichen chiplets vermeiden.

[Gipsel]

was zen 5 angeht, muss man ja nicht zen2 als littlecore nehmen. würde sich aber aus o.g. gründen anbieten.Nicht wirklich, da man dann in das gleiche Problem mit den Befehlssätzen wie intel mit AlderLake reinläuft (oder man setzt drauf, daß das softwaretechnisch vom OS-Scheduler gelöst wird [aber da glaubt intel offenbar selber nicht dran, weswegen das in neueren ADL-Modellen per eFuse deaktiviert wird]).
Wie wäre es dagegen mit Zen4c? Da besteht vermutlich ein deutlich geringerer Mismatch bei den Befehlssätzen.

[fondness]

Im SteamDeck steckt ein Zen2, weil es etwas anderes als Quad gar nicht gibt. Für Zen3 extra ein Quad-Core-CCX zu designen wäre viel zu viel Aufwänd gewesen und 8 Kerne für das Steamdeck völlig overengineered.

[fondness]

@basix
aber lange nicht so kompakt die wie e cores. Und Zen 5 wird sicherlich deutlich zunehmen, wenn man jetzt auch breiter werden will.

Nicht so kompakt wie E-Cores, allerdings erheblich schneller und wohl sogar effizienter. Intels E-Cores sind vorallem klein, aber nicht besonders effizient.

Andererseits hat man ohne kompakte Kerne in MT Benchmarks potentiell Nachteile. Man kann pro mm2 nicht so viele Cores verbauen. Für die meisten Consumer in der Praxis irrelevant mi 16C und mehr. Aber Benchmarks wollen die IHVs auch nicht.

Es limitieren nicht die mm², es limitiert die Leistungsaufnahme. Zumal wir hier absolut über weniger mm² reden.

[Undertaker]

@basix
aber lange nicht so kompakt die wie e cores. Und Zen 5 wird sicherlich deutlich zunehmen, wenn man jetzt auch breiter werden will.

...und man verliert Effizienz, insbesondere bei Teillast. Auch bei Zen 5 wird es Designentscheidungen geben, bei denen Energie- und Flächeneffizienz zugunsten höherer Taktraten bzw. höherer Pro-Thread-Performance geopfert wird. Dieser Grundsatz dürfte auf jeden P-Core eines jeden Herstellers zutreffen. Bei einem E-Core kann ich bewusst auf solche Designentscheidungen verzichten und nahezu ausschließlich auf Energie- und Flächeneffizienz zum Boosten der MT-Performance gehen.

PS: Was natürlich nicht heißt, dass man die designsseitig hohe Energieeffizienz eines E-Cores durch Überfahren der Taktraten nicht auch komplett zerstören kann – dann kann ein P-Core im optimalen Betriebspunkt durchaus einem E-Core überlegen sein. Ändert aber nichts am Grundprinzip. :)

[robbitop]

Nicht so kompakt wie E-Cores, allerdings erheblich schneller und wohl sogar effizienter. Intels E-Cores sind vorallem klein, aber nicht besonders effizient.



Es limitieren nicht die mm², es limitiert die Leistungsaufnahme. Zumal wir hier absolut über weniger mm² reden.
Denke mal ein Stück weiter. RTL bringt jetzt 16E Cores. Zen 4 bleibt bei 16C. ARL legt nach und bringt 32E Cores. Da fällt die Verdopplung einfach leichter.

Außerdem könnte man, wenn die TDP limitiert, auch einfach einen besseren Betriebspunkt für die ECores wählen und einfach viel mehr davon verbauen. Die sind unter anderem so energieineffizient weil sie einfach zu hoch geprügelt werden. Unter 3 GHz wäre es sicherlich besser.
Dazu kommt auch noch folgendes Argument: Nur weil Intels jetzige E-Cores nicht beeindruckend sind in Bezug auf Perf/W heißt das nicht, dass E-Cores das nicht sein können grundsätzlich. Man schaue sich Apple an. Da ist die Performance-Schere zwischen E und P größer aber dafür sind die E Cores auch IIRC 6x so energieeffizient wie die P Cores.

...und man verliert Effizienz, insbesondere bei Teillast. Auch bei Zen 5 wird es Designentscheidungen geben, bei denen Energie- und Flächeneffizienz zugunsten höherer Taktraten bzw. höherer Pro-Thread-Performance geopfert wird. Dieser Grundsatz dürfte auf jeden P-Core eines jeden Herstellers zutreffen. Bei einem E-Core kann ich bewusst auf solche Designentscheidungen verzichten und nahezu ausschließlich auf Energie- und Flächeneffizienz zum Boosten der MT-Performance gehen.

PS: Was natürlich nicht heißt, dass man die designsseitig hohe Energieeffizienz eines E-Cores durch Überfahren der Taktraten nicht auch komplett zerstören kann – dann kann ein P-Core im optimalen Betriebspunkt durchaus einem E-Core überlegen sein. Ändert aber nichts am Grundprinzip. :)
Absolut - volle Zustimmung.

Endlich mal eine differenzierte Meinung als immer nur "E-Cores sind kacke". Ja, Intel's jetzige Implementierung in ADL ist kacke. Aber grundsätzlich muss das nicht heißen, dass das immer so sein muss. :)
Bei Apple und ARM funktioniert das super (ggf. auch weil man dort bewusst die Performance Schere etwas weiter öffnet). Und das Prinzip macht ja auch Sinn: the right tool for the right job. So kann man Cores für unterschiedliche Lastzustände und Betriebspunkte optimieren und kann die Performance - Power(W) Curve einfach viel breiter und effizienter abfahren. Hilft das den neusten Games, die bloß eine Hand voll Kerne brauchen? Nö. Aber im Mobile Bereich und auch für MT getriebene Anwendungen kann das sicherlich gut was bringen.

[HOT]

Andererseits hat man ohne kompakte Kerne in MT Benchmarks potentiell Nachteile. Man kann pro mm2 nicht so viele Cores verbauen. Für die meisten Consumer in der Praxis irrelevant mi 16C und mehr. Aber Benchmarks wollen die IHVs auch nicht.
Das würde ich stark bezweifeln. Aber Zen5 wird sehr sicher aussehen wie Zen4 nur mit neuen Chiplets.
Wenn AMD was Anderes machen sollte, dann sehr sicher danach. Zen4 und Zen5 sind mMn als eine Plattformgeneration zu sehen, das machen ja auch die Roadmaps deutlich. Auch das IOD wird man sehr sicher 2 Generationen verwenden, genau wie Bixby.

MMn ist ein Zen5-Chiplet dann weiterhin 8C, dann eben in N4X gefertigt und dürfte eben nur in der Logik, vllt. im L1$ größer sein, im Endeffekt steigt ein CCD dann von der Größe her eben von 70mm² auf knapp 90mm² an.

[Linmoum]

Also bei "new grounds-up microarchitecture" wäre meine erste Vermutung jetzt wahrlich nicht, dass Zen5 sicher wie Zen4 aussieht nur mit neuen Chiplets. :freak:

[w0mbat]

Im SteamDeck steckt ein Zen2, weil es etwas anderes als Quad gar nicht gibt. Für Zen3 extra ein Quad-Core-CCX zu designen wäre viel zu viel Aufwänd gewesen und 8 Kerne für das Steamdeck völlig overengineered.
+1

Sehe ich genauso. Der große Vorteil von Zen3 war ja gerade, dass nun alle 8 Kerne auf den selben L3 zugreifen können. Wenn man Zen3 jetzt wieder halbiert, ist da nicht nur extra Aufwand, sondern vernichtet den größen Pluspunkt von Zen3.

[davidzo]

Zen5 CCDs werden mMn weiterhin 8C sein und in N4X gefertigt. Sie dürften zudem recht groß werden in N4X, sicherlich 90mm².
Das ist doch sehr ins blaue geraten oder gibt es schon irgendwelche Leaks?

AMD könnte genau so gut bei Zen5 den Schritt gehen den Cache auf einen anderen DIE auszulagern, wie man es bei CDNA3 und vermutlich auch RDNA3 machen wird.
Wenn SRAM in N4 nicht gut skaliert, könnte man den auch auf ein N5 oder N6 DIE auslagern, am besten gleich mit dem i/o DIE zusammen und stattdessen 12 oder 16Kerne auf ein Compute DIE in unter 100mm2 quetschen.

Andererseits hat man ohne kompakte Kerne in MT Benchmarks potentiell Nachteile. Man kann pro mm2 nicht so viele Cores verbauen.
Naja, Zen2 und Zen3 sind noch sehr kompakt. fast 2/3 vom 81mm2 CCD ist der L3 Cache.
Zen2 Kerne sind ca. 3.8mm2 groß inkl. L2, vs 2,3mm2 bei Golden Cove mit anteiligem L2. Dafür leisten Zen2 Cores aber auch +40% mehr. Damit meine ich nicht IPC, sondern absolute Performance, da sie wesentlich höhere Taktraten erreichen als GMT. Und im Bereich zwischen 1,5 und 5Watt Powerbudget per Core ist Zen2 sogar deutlich effizienter als Gracemont.
https://chipsandcheese.com/2022/01/28/alder-lakes-power-efficiency-a-complicated-picture/

Ein interessanter Nebenaspekt von den ChipsandCheese Messungen ist aber der Voltage Floor bei AMD CPUs. Im Gegensatz zu AMD skaliert sowohl Gracemont als auch Golden Cove weiter sehr gut nach unten. Auf 1,4Ghz ist man am Effizientesten und lässt auch AMD hinter sich. Wobei das auch viel mehr ein Fertigungsaspekt sein kann als Architekturelle Gründe.

Wenn man die E-Cores ausschließlich auf ihrem effizientesten Betriebspunkt betreibt, nämlich bei 1,4Ghz und ca 0.6Watt/Core, könnte man die Energieeffizienz von Alderlake in MT workloads vervierfachen.
Rein theoretisch wäre man mit 64E-Cores im Sweetspot getaktet in der Lage den 12900K in Integer MT Workloads deutlich zu schlagen und das bei unter 65Watt.
Wobei Bandbreite und L3 Latenz dann sicher auch ein Problem werden und die Gamingleistung nicht vorhanden wäre.



Und wie kommst du darauf, dass ein Zen2 Core "erheblich" stromsparender ist?

Es ist leider nicht so einfach direkte Vergleiche zu finden, aber es gibt sowohl bei notebookcheck als auch hier im Forum (PES Suite) Hinweise darauf dass renoir einen niedrigeren voltage Floor hat, also besser nach unten skaliert, während Cezanne deutlich weniger schlecht nach oben skaliert. Ich schreibe nicht besser, weil Cezanne immer noch nicht besonders gut nach oben skaliert im vergleich zu Intel. Für den mobilen Usecase also wenn sehr niedrige Betriebspunkte angestrebt werden kann Renoir also effizienter sein.

[robbitop]

Also bei "new grounds-up microarchitecture" wäre meine erste Vermutung jetzt wahrlich nicht, dass Zen5 sicher wie Zen4 aussieht nur mit neuen Chiplets. :freak:
Jap. Da wird vieles im core selbst komplett neu sein. Das Interview bei Anand war offensichtlich. Und die Gerüchte sprechen auch dafür. Zen 5 wird mit hoher Wahrscheinlichkeit ein großer Schritt werden.

[amdfanuwe]

Zen 5 wird mit hoher Wahrscheinlichkeit ein großer Schritt werden.
Hoffen wir mal, dass der Schritt nicht in die falsche Richtung geht.

[Undertaker]

Naja, Zen2 und Zen3 sind noch sehr kompakt. fast 2/3 vom 81mm2 CCD ist der L3 Cache.
Zen2 Kerne sind ca. 3.8mm2 groß inkl. L2, vs 2,3mm2 bei Golden Cove mit anteiligem L2. Dafür leisten Zen2 Cores aber auch +40% mehr.

Für die prinzipielle Analyse der Thematik müssen wir wegkommen von einem Quervergleich über gänzlich verschiedene Architekturen, Fertigungsprozesse, Taktraten und Betriebspunkte. Andernfalls lässt sich nahezu jedes Ergebnis "hinbiegen". Für mich die entscheidende Frage: Könnte man einen Big Core wie Zen 2/3/4/5 durch ein Streichen des Design-Ziels "Pro-Thread-Performance" hinsichtlich Flächen- und Energieeffizienz verbessern? Und da wird die Antwort immer lauten: Ja. Ein CPU-Design steht immer vor einem Zielkonflikt zwischen verschiedenen Qualitätsparametern. Je mehr ich davon streichen kann oder zumindest wegpriorisiere, desto besser kann ich die anderen optimieren.

[Gipsel]

Zen2 Kerne sind ca. 3.8mm2 groß inkl. L2, vs 2,3mm2 bei Golden Cove mit anteiligem L2. Dafür leisten Zen2 Cores aber auch +40% mehr. Damit meine ich nicht IPC, sondern absolute Performance, da sie wesentlich höhere Taktraten erreichen als GMT. Und im Bereich zwischen 1,5 und 5Watt Powerbudget per Core ist Zen2 sogar deutlich effizienter als Gracemont.
https://chipsandcheese.com/2022/01/28/alder-lakes-power-efficiency-a-complicated-picture/

Ein interessanter Nebenaspekt von den ChipsandCheese Messungen ist aber der Voltage Floor bei AMD CPUs. Im Gegensatz zu AMD skaliert sowohl Gracemont als auch Golden Cove weiter sehr gut nach unten. Auf 1,4Ghz ist man am Effizientesten und lässt auch AMD hinter sich. Wobei das auch viel mehr ein Fertigungsaspekt sein kann als Architekturelle Gründe.Die Desktop-Versionen skalieren schlicht nicht so weit runter, weil es vermutlich dort als zweitrangig angesehen wurde, die Spannungen bei niedrigen Takten weiter abzusenken* (weswegen die Effizienz unterhalb einer bestimmten Schwelle nicht mehr besser wird, die Effizienzsteigerung wird dort quasi künstlich hart abgeschnitten). Aber im gleichen Artikel sehen die sich auch einen 4800H an, der dieses Verhalten nicht zeigt. Der ist aus Ernergieeffizienzsicht überall besser als Gracemont und das bei höherer Performance. Ich meine, Zen2 zeigt bei ~3,5GHz offenbar die Energieeffizienz von Gracemont irgendwo zwischen 1,5GHz - 2GHz (je nach Anwendung). Das ist gleicher Energieaufwand für eine Aufgabe bei deutlich mehr als doppelter Performance. :freak:
Gracemonts beste Energieffizienz wird laut deren Tests bei ~1,2GHz erreicht. Zen2 hat die gleiche bei 2,5-2,8GHz. Intel müßte also mindestens 3 mal so viele Gracemont-Kerne verbauen wie AMD Zen-Kerne, um zu konkurrieren. Und dann ist es längst nicht mehr flächeneffizient.

*: Das kann auch Wechselwirkungen mit Designentscheidungen haben, z.B. die Auslegung der LDOs für die unabhängige Spannungsanpassung der Kerne bzw. des L3-Caches. Punkt ist, es liegt wohl nicht am eigentlichen CPU-Kern.

[Leonidas]

...... (Frage hat sich erledigt)

[mboeller]

Im SteamDeck steckt ein Zen2, weil es etwas anderes als Quad gar nicht gibt. Für Zen3 extra ein Quad-Core-CCX zu designen wäre viel zu viel Aufwänd gewesen und 8 Kerne für das Steamdeck völlig overengineered.


und ich dachte immer es liegt einfach daran, dass "alle anderen" Konsolen ebenfalls ZEN2+RDNA2 haben.

[Leonidas]

Könnte man denken. Aber eine kleine Differenz auf CPU-Seite macht das Kraut nicht fett. Entwickelt wird letztlich auf die Eigenheiten der Gfx hin - nicht auf die Eigenheiten der CPU.

[basix]

Wie wäre es dagegen mit Zen4c? Da besteht vermutlich ein deutlich geringerer Mismatch bei den Befehlssätzen.
Laut AMDs Folien vom Financial Analyst Day sind Zen 4 & 4c ISA kompatibel

[robbitop]

Ich bin gespannt, was am Ende dann definitiv die Unterschiede zwischen C und nicht C sind. Wenn es deutlich anders wäre wären die Namen auch unterschiedlicher.

Ich kann mir vorstellen:
- weniger L2/3
- größeres ccx
- layout optmimierung auf Packdichte anstatt Takt

Core/uArch aber unverändert

[Gipsel]

Laut AMDs Folien vom Financial Analyst Day sind Zen 4 & 4c ISA kompatibelSchon, ging aber um die hypothetische Kombi Zen5 + Zen4c. Zen5 soll ja deutlich breiter werden.

[robbitop]

AMD hat ja auch Zen 5c angekündigt.

[Gipsel]

AMD hat ja auch Zen 5c angekündigt.Ja, beim FAD. Zen4c war schon länger bekannt und die Idee mit der Zen5 + Zen4c ist schon etliche Monate alt. Mit Zen5c im Mix sieht es jetzt wohl weniger wahrscheinlich aus.
Insgesamt sieht es bisher nicht unbedingt danach aus, als würde AMD auf dem Weg sein, unbedingt deutlich energieeffizientere Kerne zu integrieren, eher welche mit höherer Flächeneffizienz. Obwohl ja Zen5 deutlich breiter werden soll, also keine Ahnung, wie Zen5c ausgelegt wird. Da würde es sich eventuell anbieten, eine intern etwas schmalere aber voll ISA-kompatible Version mit deutlich niedrigerem Zieltakt (per anderer Auslegung des physischen Design) aufzulegen. Aber da müssen wir wohl noch ein wenig warten.

[Nightspider]

Ich bin mal gespannt wo die optimale Taktrate hinsichtlich Energieeffizienz bei Zen4 in N5 liegen wird.

N5 wird da schon für einen großen Sprung sorgen und in 2 Jahren geht es ja mit N4HPC und N3 weiter.


Phoenix als Rembrandt Nachfolger könnte auch in Regionen von 5,5 Ghz takten, was schon heftig ist für Laptops.

Da kann man sich schon fragen, wie ein hypothethisches SteamDeck 2 aussehen könnte, ob AMD nochmal Optionen mit 4 Kernen anbieten wird usw.

[HOT]

Phoenix Point ;).

[amdfanuwe]

ob AMD nochmal Optionen mit 4 Kernen anbieten wird usw.
4 Kerner in N6 heißt Mendocino.
Ähnlich Cesanne -> Lucienne wird es wohl auch einen 6/8 Core Rembrandt Nachfolger geben.
Phoenix Point soll Chiplet Based sein.
“Phoenix Point” innovations include the AIE inference accelerator, image signal processor, advanced display for refresh and response, AMD chiplet architecture, and extreme power management.
https://ir.amd.com/news-events/press-releases/detail/1078/amd-details-strategy-to-drive-next-phase-of-growth-across

[robbitop]

Meine Vermutung ist, dass das Steamdeck 2 einen 8 core SoC bekommt. Die 4c CCX sind seit Zen 3 Geschichte und außerdem kann man mit 8 Core performancenormiert nochmal niedrigere Taktraten nutzen. f~P^3.

IMO wären große Caches für GPU und CPU sinnvoll. Datentransfers machen bei modernen Chips einen wesentlichen Teil des Energiebudgets aus. Lokale Datentransfers sind deutlich sparsamer. Und da Bandbreite und Latenz besser sind, wird das Ganze taktnormiert auch schneller. Also könnte man Performancenormiert Taktraten reduzieren. Das gleiche gilt für mehr CUs.
Aber aus Kostengründen (das Deck soll ja billig sein) wird es vorerst wahrscheinlich keine besonders großen Cacches geben.
Ggf zu Zen 5, sofern man den LLC so einbinden kann, sass er von CPU und GPU genutzt werden kann und trotzdem gute Latenz hat. 32-64 MiB LLC/L3 für alles sollte schon gut helfen.

[prinz_valium_2]

Da Zen 5 frühsten Ende 2024 kommt, finde ich 4 Kerne auch unangemessen.
Es sind dann 8 Kerne und als salvage 6. Mehr als 2 defekt, sollte es nicht geben, bevor der ganze chip nutzlos ist.

Im kompletten Einsteigersegment, kann das natürlich anders aussehen.

[ryan]

Unwahrscheinlich, da Strix Point auf der Notebook-Roadmap für 2024 angesetzt ist. APUs stellt AMD immer auf der CES Anfang des Jahres vor.


Das hat nichts zu sagen. Sie würde es gerne so machen. Die Frage wäre erstmal, ob das überhaupt umsetzbar ist. Es gibt keinerlei Garantie auf eine jährliche Vorstellung für Anfang des Jahres. Vorstellen kann man natürlich immer viel.

Schon Rembrandt mit der heißen Nadel gestrickt gewesen für Anfang Januar. Rembrandt-U ist Stand mitte Juni gar nicht verfügbar und Rembrandt-H gibt es derzeit exklusiv nur von Asus und Razer.

[Thomas Gräf]

Solch Zen5 3D V-Cache wär sicherlich ein Träumchen.
Bis dahin könnte auch die neue DDR5 Plattform ausgereift sein, was IMC AGESA und Rev2 Bords samt BIOS betrifft. ;)

[w0mbat]

Da Zen5 aber eine von Grund auf neue Architektur ist und zudem wohl den Schritt zu 3D packaging macht, lieber auf Zen6 warten, wo das alles ausgereift ist ;)

[ryan]

Von Greymon55:


Last year I heard from the laptop oem that Strix Point was early 2024, but now it looks like it's been pushed back to mid-2024. Because desktops are always ahead of mobile, according to the early roadmap ZEN5 Desktop is at the end of 2023. But the latest road map says 2024.
https://twitter.com/greymon55/status/1536188951827865600

[HOT]

Da Zen5 aber eine von Grund auf neue Architektur ist und zudem wohl den Schritt zu 3D packaging macht, lieber auf Zen6 warten, wo das alles ausgereift ist ;)
Kann sein, halte ich aber für unwahrscheinlich. Ist schlichtweg nicht nötig und die Roadmap sieht explizit Zen5 mit VCache vor, also genau wie bei der Zen4-Generation.

Von Greymon55:



https://twitter.com/greymon55/status/1536188951827865600

Das passt ziemlich gut. Wenn Zen5 CPU im Frühjahr 2024 erscheinen sollte wird die APU sicherlich später veröffentlicht.

[Nightspider]

Naja V-Cache der 2. oder 3. Generation kann ja schon auf echtem 3D Packaging beruhen.

Weniger L3 im Compute Die und mehr L3 im Stack hatten wir ja auch schon als mögliche Option besprochen um mehr Platz für ein deutlich breiteres Design zu schaffen.


Das passt ziemlich gut. Wenn Zen5 CPU im Frühjahr 2024 erscheinen sollte wird die APU sicherlich später veröffentlicht.

Mit Raphael Mobile und mindestens einer richtigen weiteren APU ist AMD ja schon mal gut aufgestellt gegen Intel.

Phoenix @ N4 wird gut rocken und der Nachfolger wird dann in N3 wieder Intel unter Druck setzen, falls Intel nicht auch mit N3 kommen sollte.

[vinacis_vivids]

AMD Next-Gen Zen 5 CPUs Get Early Support Within HWiNFO
https://wccftech.com/amd-next-gen-zen-5-cpus-get-early-support-within-hwinfo/

Vermutlich werden die AI-Fähigkeiten, die bei Zen4 eingebaut worden noch weiter ausgebaut neben den üblichen Verbesserungen (Fertigung, Takt, Cache, Cores usw.)

[Badesalz]

[B]Vermutlich werden die AI-Fähigkeiten, die bei Zen4 eingebaut worden noch weiter ausgebaut
Das ist auch eine steile Story...

2 Leute von Zuckerberg und 1 von Gelsinger erzählen wie man PyTorch auf Intel durch bfloat16 Beine macht:
"Intel and Meta previously collaborated to enable bfloat16 on PyTorch, and the related work was published in an earlier blog during launch of Cooper Lake."
16.08.2022
https://pytorch.org/blog/empowering-pytorch-on-intel-xeon-scalable-processors-with-bfloat16/

09.11.2021
https://winfuture.de/news,126290.html

Blickt man kaum durch =)

[basix]

Was ist das Problem? Meta wird sicher auch sehr viele Intel CPUs installiert haben ;)

Zen 3 ist hinsichtlich Perf/$ und Perf/W halt einfach sehr gut verglichen mit Cooper Lake und Co. Da macht es für Meta Sinn, solche CPUs zu verwenden. Aber daneben werden sicher auch Intel CPUs eingekauft werden.
Und wenn man nicht spezifische ML/AI Workloads hat, benötigt man auch das Bfloat16 Gedöhns nicht. Mit Zen 4 wird sich das hinsichtlich ML/AI aber eh nochmals deutlich verbessern (AVX512, VNNI)

[vinacis_vivids]

Bei den AI Benchmarks bzw. Leistung macht es keinen Sinn auf Intel zu setzen. Dafür ist AMD einfach zu stark mit Zen4.
https://www.phoronix.com/review/amd-ryzen-7900x-7950x-linux/16

Die neue Zen4 uArch ist extrem potent im AI, NN usw. - wird mit Zen5 sicherlich weiter ausgebaut werden, ist ja der gleiche Sockel.

[Badesalz]

Es ist euch trotzdem klar, daß wir hier damit - in den aktuellen Nutzungsszenarios - zu 80% über devils tools reden? :wink:
Wir sollten uns lieber erfreulicheren Aspekten widmen :tongue:

KI hat ja keine großen Probleme mit Kernen. Um sich das genauer anschauen zu können fehlt halt der 7700x in der Riege. Ist eh so bisschen durcheinander alles. Mal ist nur der 12900 dabei, mal nur der 11900, mal beide... In absoluten Zahlen aber ist das halt wie aufgezeigt. Schon richtig.

[Badesalz]

Wieviele Infos gibt es schon zu Zen5 eigentlich? Wenn ich mir all die Benches und Skills aus dem Customerfeld :freak: so anschaue... Ich hab da bei den Ryzens nämlich so ein seltsamens Gefühl...

Ein CCD und 2 CCX halt, aber CCX1(F) ist 8c/8t. CCX2(R) ist zen5c mit 4c/8t. Und es gibt keine X3D mehr, da es nur noch V-Cache gibt.
CCX2 ist kaum langsamer pro Thread und Watt, zieht aber halt trotzdem weniger aus dem Sockel.

Das wäre für mich die schnellste Gamingkonfig :tongue: Je nach sonstige Zielgruppe könnte sich AMD aus den R und F CCX passend was zusammenstellen.

Schlecht? :usweet:

PS:
Beim Epyc dagegen bleiben die Modelle genauso wie aktuell. Jenachdem ob ein Genoa-Pendant noch Sinn macht.

[Der_Korken]

Infos gibts es praktisch keine, aber das wenige, was es gibt, widerspricht deiner 3D-Cache-only-Theorie:

https://www.forum-3dcenter.org/vbulletin/showpost.php?p=13026871&postcount=158

"New grounds-up microarchitecture" ist natürlich ein sehr dehnbarer Begriff, das kann alles und nichts heißen. Allerdings wurde ein großer Architektursprung afaik schon vor 2 Jahren in Gerüchten genannt und es wäre logisch, wenn man sich die bisherigen Evolution von Zen anguckt.

Das bedeutet aber auch, dass eine Prognose wie der Kern aussehen wird und performt unmöglich ist, weil wir keine Ahnung haben in welche Richtung das neue Design gehen wird. Im Gegensatz zu Bulldozer -> Zen 1 hat man auch keine Konkurrenzarchitektur (Intel von Sandy Bridge bis Skylake), von der aus man vielleicht was ableiten könnte. Breite Kerne + Mikro-Op-Cache + SMT + kleiner privater L2 + L1 write-back hat sich in der Praxis bewährt und war Bulldozer's CMT in allen Punkten überlegen. Das würde ich von Golden Cove gegenüber Zen 4 nicht unbedingt sagen.

Ansonsten munkelt man von 32 Kernen im Desktop und 256 Kernen im Server. Eigentlich spräche das nicht gerade für große, fette Cores, da der Verbrauch pro Kern deutlich gegenüber Zen 4 sinken müsste. Ein SLC (system-level cache) wurde auch mal erwähnt, aber das könnte ein reines APU-Ding sein.

[robbitop]

Breit ist nicht automatisch deutlich schneller. Das zeigen Samsungs M1-M3 Kerne und auch Intels Cove Kerne (die sind nicht langsam aber im vergleich zu den deutlich kleineren Zen Cores ist der Unterschied erstaunlich klein).
Aber: sie können schnell sein - siehe Apples P Cores. Die sind pro Takt wirklich irre schnell. Ich würde mich wundern, wenn Intel und auch AMD nicht langfristig in die Richtung gehen.

Was der Grund ist, warum Apples breite Kerne schnell und effizient sind und Samsungs M Cores es nicht waren ist die große Frage. Rein vom Blockschaltbild lässt sich das wahrscheinlich nicht ableiten sondern hat wahrscheinlich viel mehr mit den Details der physischen Implementierung zu tun.

[Badesalz]

Ich weiß den Thread nicht mehr :frown: aber wir haben das doch auf 3DC (!) imho recht gut herausgearbeitet warum der M1 so rasend schnell ist. Da warst du doch mit dabei (??)
War das nicht irgendwo in der Mac-Ecke hier?

@all
Die core- bzw. thread-flood bringt auf dem desktop nichts mehr. Die Benches mit 7-zip und Cinebench können sich die Testerlinge durch die Kimme ziehen. Das ist Kokolores.

[Der_Korken]

@robbitop

Ja, die Firestorm-Kerne von Apple waren schon ein Mysterium. Wobei die von den Specs her super fett waren (siehe Anhang, Quelle: https://drive.google.com/drive/folders/1W4CIRKtNML74BKjSbXerRsIzAUk3ppSG)

ROB und PRF sind mal eben jeweils doppelt so groß wie bei Zen 4, welcher in den Bereichen gegenüber Zen 3 gerade erst aufgebohrt wurde. ~630 zu 320 zu 256 beim ROB und ~800 zu 416 zu 352. Dazu 6x ALU und 4x VALU. Ersteres ist auch mal eben 50% mehr als Zen 1 bis 4. Bei Intel hatte ich das Gefühl, dass das Aufblähen dieser ganzen Buffer und Register sowohl die Kerngröße als auch den Verbrauch durch die Decke haben gehen lassen, aber Firestorm ist ja in dem Bereich noch extremer als die Cove-Kerne ohne dass das bei denen ein Problem war. Es hilft natürlich ungemein, dass Firestorm nur mit 3,2Ghz taktet, während AMD und Intel fast an der 6Ghz-Marke kratzen.

Trotzdem muss man die gesteigerte Breite auch erstmal auf die Straße bekommen, denn das Problem bei CPUs ist ja nicht, dass die ständig durch ihren ALU-Durchsatz limitiert wären, sondern dass man überhaupt genug unabhängige Instruktionen findet, die man parallel ausführen kann. Das passt natürlich bei Firestorm zum riesigen ROB, durch den man Unmengen ans Instruktionen in-flight halten kann.

Aber auch das kann nicht die Lösung sein, denn je weiter man vorausliest, desto mehr Branches muss man überlesen und dort "raten" wie gebrancht wird. Je weiter die Instruktion vom aktuellen program counter entfernt ist, desto wahrscheinlicher hat man auf dem Weg zu ihr einen branch mispredict drin und desto wahrscheinlicher hat man Energie verschwendet ohne Arbeit zu verrichten. Ich weiß nicht inwieweit es möglich ist oder vielleicht sogar schon gemacht wird, aber irgendwann müsste ein Kern eigentlich die kritischen Pfade ausrechnen, mit denen man die Branch-Bedingungen evaluieren kann. Das heißt: Man schaut sich anhand der Instruktionen an, welche von denen ich brauche, um den nächsten Branch auszuwerten. Diese werden priorisiert, damit sozusagen immer die so viele Branches wie möglich im Voraus korrekt berechnet sind. Die anderen Instruktionen holt man irgendwann nach, wenn der kritische Pfad mal lang ist oder ROB/Instruction window voll sind. Das ist so ein bisschen wie Projektplanung, wo man von der Deadline her einen Abhängigkeitsbaum aufstellt, welche Prozesse vor welchem anderen Prozess fertig sein müssen und man so ausrechnet, mit welchen Prozessen man anfangen sollte, um nicht in Verzug zu kommen durch eine lange Kette von nicht parallelisierbaren Prozessen, die den ganzen Zeitplan aufschiebt. Sowas ist in Hardware natürlich super schwer, da das ja zeitlich in Bruchteilen von CPU-Zyklen berechnet werden muss, selbst wenn es algorithmisch kein schweres Problem ist.

Interessanterweise ist der Load-Store-Teil relativ schmächtig im Vergleich zu Zen 3 und den Coves. Ich hatte bei M1-Release damals rumspekuliert, ob das vielleicht was damit zu tun haben könnte, dass die aktuelle ARM-ISA doppelt so viele logische Register hat wie x86. Dadurch können mehr Daten aus logischer Sicht (physisch sind ja eh mehr Register vorhanden) in den Registern gehalten werden und es gibt bereits auf Instruktionsebene weniger Loads/Stores. Damals hatte mir allerdings Gipsel widersprochen und auf die Stack Engines aktueller CPUs verwiesen. Wie die funktionieren weiß ich als Laie leider nicht, aber zumindest kann ich mir vorstellen, dass man Store-Load-Ketten wegoptimieren kann, wenn zwischen dem Store und Load niemand anders auf die Daten zugreift (d.h. man schreibt es nie in den Cache, sondern direkt ins Register, wo es nach dem Load eh landen würde).

Außerdem erwähnenswert ist, dass Firestorm satte 8 Decoder hat. Durch fixe Instruktionsbreiten ist es natürlich viel einfacher parallel zu decodieren, weil man die Startbytes der Instruktionen nicht erst noch vorberechnen muss. Allerdings scheint der Decode-Durchsatz bei Intel und AMD nicht so das Problem zu sein, wenn man den Analysen von chipsandcheese Glauben schenkt.

[basix]

@all
Die core- bzw. thread-flood bringt auf dem desktop nichts mehr. Die Benches mit 7-zip und Cinebench können sich die Testerlinge durch die Kimme ziehen. Das ist Kokolores.

Gibt Gerüchte, wo man Zen 1 mässige IPC Steigerung anstrebt. Das wäre dann das, was du und auch wir alle haben möchten ;)

Ich dachte vor einem Jahr oder so auch, Zen 5 kommt mit mehr Kernen (N3 und so, das Zen 3 CCD mit 8C in N7 war schon ziemlich klein). Wenn man aber wirklich 1.4...1.5x IPC und noch etwas Takt auf Zen 4 drauflegen kann, benötigen wir definitiv nicht mehr Kerne. Dann kann man beim Core Count bei dem bleiben, wo wir heute sind.

[Badesalz]

Ja genau ;) Und das:
https://dougallj.wordpress.com/2021/04/08/apple-m1-load-and-store-queue-measurements/

@basix
Das Prob ist einfach, daß man die Threads nicht auf die Straße bringen kann. Wo man das kann, sind das eben fertige statische Datenströme wo es daheim kaum eine Geige spielt wie schnell sie durch sind, selbst wenn man mit solchen eben zu tun hat. Das betrifft eigentlich weitgehend nur 3D-Artists...

Sonst ist der Sweetpoint auch aktuell noch nichtmal bei 16 Threads. Der Verwaltungsaufwand des aufgebröselten steigt irgendwann zu stark. Die ganzen Ideen auf die man schon seit Zen1 wartet und immer so ein Quark prophezeit, die bleiben auch 2022 aus. Es macht keinen Sinn sich da weiter Hoffnungen zu machen.
Es ist eher wahrscheinlich, daß dies eine prinzipielle Sache ist, die sich solange nicht ändern wird, solange wir die Ansätze (im Code) nicht grundlegend ändern. Ich sehe aber bis heute keine Kandidaten - auch keine theoretischen - die dem beikommen könnten.

Mal davon ab, daß es Leistung satt für alles gibt. Beim Zocken gibt es das erstmal wieder mit 4090 nicht. Realistisch gesehen kauft sowas aber eh keiner. 7800X3D ohne irgendein Gedöns drumheurm und gut ist.

Ich find meinen Vorschlag von davor irgendwie weiterhin extrem elegant (Leistung auf der Straße) wie auch effizient :tongue:

[Ravenhearth]

Wenn Zen 5 schon ~Anfang 2024 kommt, wird man vermutlich nur 4nm zur Verfügung haben. Wenn die IPC dann wirklich so stark zeigt und die Kerne wesentlich fetter werden, wird Zen 5 im Gegensatz zu Zen 4 die 170W TDP wohl brauchen...

[Badesalz]

Die Leute lernen jetzt schon dazu. Man möchte zwar nicht zwanghaft für die maximale Effizient die knapp 70W fahren ;) aber mehr als 125W sind auch Blödsinn.

Das wird sich auf Zen5 ähnlich übertragen. Egal mit wieviel Powertarget AMD den loslässt. Man wird daheim bestens mit <150W auskommen.

Das sind immernoch Welten zu den Dramen die Intel grad weiterhin veranstaltet. Wenn das noch weiter so geht brauchen sie bald einen 4000er Sockel, weil die Hälfte der Pins für Strom gebraucht wird...

[robbitop]

Ist natürlich immer die Frage welchen Betriebspunkt man will. So ziemlich jede uArch bei soziemlich jedem Fertigungsprozess kann effizient oder ein Schluckspecht sein. Wenn man alle Kerne auf 6 GHz haben will wird's wohl ein Schluckspecht. Ich bin mir aber ziemlich sicher, dass wenn man die TDP auf 95W limitiert da noch ein Großteil der Performance bei herumkommt und die Taktraten halt etwas leiden. Wie immer gilt P³~f

Zen 5 muss als uArch schon effizienter sein als Zen 4 da das in mobile und Server relevant ist. Also mehr Performance für gleiche Leistungsaufnahme oder gleiche Performance bei weniger Leistungsaufnahme.

[Badesalz]

"Etnhusiasten" fahren dann 125W :D

Ist zwar kein Vergleich zu den enthusiastischen 300W vom 13900K, aber gut: Der AMD-User ist es halt gewohnt kleinere Brötchen zu backen.

[robbitop]

Nach gusto würde ich sagen. Wer eine Wasserkühlung hat und jedes Prozent rausquetschen will wählt eine hohe TDP. Wer Effizienz will wählt eine niedrige TDP. Das kann man ja wirklich fein granular einstellen.

[Ravenhearth]

Zen 5 muss als uArch schon effizienter sein als Zen 4 da das in mobile und Server relevant ist. Also mehr Performance für gleiche Leistungsaufnahme oder gleiche Performance bei weniger Leistungsaufnahme.
Ich denke, das wird der Fall sein, aber auch, dass Zen 5 von höheren TDPs stärker profitiert als Zen 4. Also während der "8950X" bei 230W PPT deutlich schneller als der 7950X sein wird, wird der Vorsprung bei kleineren Werten vermutlich schrumpfen. Der 7950X verliert bei 142W PPT nur 5%, bei Zen 5 wird der Unterschied wahrscheinlich größer ausfallen, sodass sich die CPUs in der Effizienz etwas annähern.

[Badesalz]

Ich kann mir nicht vorstellen, daß AMD sowas haben will. Perf/Watt ist eine der Sachen auf welcher sie aktuell gut rumreiten können ;)

[robbitop]

Kommt auch auf die Coreanzahl an. Angeblich gibt es mit Zen 5 deutlich mehr Cores. Das kostet, sofern die arbeiten sollen, TDP.

[fondness]

Kommt auch auf die Coreanzahl an. Angeblich gibt es mit Zen 5 deutlich mehr Cores. Das kostet, sofern die arbeiten sollen, TDP.

Nicht wirklich relevant, man kann 8 Zen cores problemlos mit 10 W und weniger betreiben bei guter Performance. Immerhin laufen ganze socs mit 15 W. Was kostet sind absurde Spannungen für die letzten paar MHz.

[robbitop]

Absolut. Aber wenn man eine gewisse pro Thread Leistung erwartet braucht das eine gewisse Frequenz (bei gleicher uArch). Bei gleicher pro Threadleistung kosten n mal mehr Kerne nunmal n mal mehr Leistungsaufnahme. Siehe die großen Epyc CPUs.

[Badesalz]

Kommt auch auf die Coreanzahl an. Angeblich gibt es mit Zen 5 deutlich mehr Cores.Das gilt zu 100% für die Nachfolger von Bergamo und Siena. Für den Desktop ist das aber imho Blödsinn.
Schon der dickste 5000er Threadreaper (HED) ist das eigentlich und bereits sehr speziell, wenn er sich auf irgendeine Weise rentieren sollte.

Für den sonstigen Desktop ist das noch wesentlich unsinniger. Davon haben wir schlicht nichts.

[robbitop]

Nun irgendwas muss AMD machen um die MT Benchmarks nicht zu verlieren im Desktop. Intel wird immer mehr E Cores einbauen. Arrowlake soll bereits 32 haben. Ob sinnvoll oder nicht AMD kann nicht stur bei 16C bleiben.
Gerüchte sprechen von bis zu 32C SKUs im Desktop. Mal schauen.

[Complicated]

AMD hat mit Threadripper eine HEDT-Plattform für diese Usecases, im Gegensatz zu Intel. In den Desktops mehr als 16 Cores quetschen zu wollen ist wenig sinnvoll, wenn man sowieso schon mehr Kerne und eine dafür ausgelegte Plattform hat, die ebenfalls einen Refresh erhält in 2023.

[robbitop]

Es macht keinen Sinn. Aber was willst su machen wenn der Wettbewerber E Cores spamt und dir in MT Benchmarks wegläuft? Man schaue sich an was der 13600K in MT Benchmarks mit dem 7600X macht. Wenn Intel mit ARL 32 E Cores bringt hat man mit 16 Cores keine Chance mehr in den MT Benchmarks. Und man will Benchmarks - ob sinnvoll oder nicht - auf keinen Fall verlieren.

Was will AMD machen? Der Masse erzählen, dass das nichts bringt? Die Lemminge schauen auf die Benchmarks. Glaub mir man will da ganz sicher nicht abgehängt werden - ob sinnvoll oder nicht. Es schadet der Stärke der Marke und es reduziert den Wert den der User bereit ist auszugeben (bei Intel bekomme ich mehr Kerne).
Ich bin mir relativ sicher, dass AMD das nicht passieren lässt. Ich würde es mit den C Cores kontern. Mal schauen was AMD macht.

[dildo4u]

Für Gamer scheint das immer noch kein Argument zu sein, der 5800x3D scheint sich zur Zeit am besten von allen Modellen zu verkaufen.
Ein 5900x ist z.b billiger also zu wenig Nachfrage?

[Complicated]

AMD wird die Gamer versuchen mit dem Zen4-3D abzuholen und alle mit Multicore-Bedarf über 16 Kernen auf die Threadripper-Plattform zu bringen. In diese Lücke stößt Intel ja sehr "clever" im Moment, da der Aufpreis zu Threadripper für mehr Kerne nicht gering ist.

Nur ist das wohl nichts worauf AMD gerade reagieren muss. Schaut man sich das aktuelle Produktprotfolio der beiden an ist AMD mit AM4/TR4/AM5 vollständig mit Angeboten im Markt die mit Alder/Raptor konkurrieren. In 6 Monaten mit Zen43D und den neuen Threadrippern und APUs danach steht AMD auch gut aufgestellt da, 9 Monate vor Zen5 Release. Der Plattform-kompatibel sein wird. Ausser das abschalten der E-Cores habe ich hier noch keinen Vorteil für Gamer gesehen.

[robbitop]

Threadripper kann man vergessen. Gibt es nur noch bei den OEMs wird super spät releast und ist überteuert.

Schau dir selbst hier bei uns im Forum die Reaktionen auf RTL an. Und das sind noch die „informierten“ User. Bei den Lemmingen der Masse wird das nich krasser sein. Beispiel 13600K vs 7600X. Da wird der 7600X von Gamern kritisiert er habe zu wenig MT Leistung. Und das wird sich bei jeder Verdoppelung der E Cores verschlimmern. Noch reichen 16C. Ab ARL nicht mehr. Um Sinn oder Unsinn geht es bei den Lemmingen leider nicht. Da werden Benchmarks geguckt. Und dann muss man beim gleichen Preispunkt mithalten können. Und der Preispunkt mit vielen Cores geht seit RTL bei 350€ los. Und es wird schlimmer.
Ab Zen 5 wird man da reagieren. Ich bin mir da ziemlich sicher - ob sinnvoll oder nicht.

Muss man abwarten wer Recht hat. Ich würde mir jedenfalls an AMDs Stelle auch im Mainstream nicht die Butter vom Brot nehmen lassen und wenns nur MT Benchmarks sind.

[dildo4u]

Der 7600X ist einfach nur zu teuer der Chip ist winzig im Vergleich zum 13600k.
Ich denke nur einer dieser Chips hat das Potenzial auf 200€ im Abverkauf, der 7700X sollte sich dann bei 300€ einordnen.
AMD wollte mit dem Launch die Marge weiter steigern was natürlich schon wegen der allgemeinen Wirtschafts Lage wunschdenken ist.

[Complicated]

Hier in Foren wird schnell in die eine oder andere Richtung gejubelt. Selten ist da eine langfristige unternehmerische Sicht enthalten. Daher wird gerne etwas gefordert, was die Unternehmen nicht als nachhaltige Lösung ihrer Probleme sehen. Noch gar nicht so lange her, war der HEDT der geilste Shit, bis Threadripper Intel praktisch bis heute aus diesem Markt eliminiert hat. Jetzt ist das alles nur noch überteuerter Kram, den keiner braucht. Die reale Nachfrage nach diesen Systemen folgt diesen Forentrends eher nicht. Intel gräbt hier das untere Segment der TR-SKUs an, mit einem deutlich günstigeren Preis, für alle die nicht mehr PCIe-Lanes oder RAM-Channels benötigen für ihren Workload. Im Gaming spielt es keine Rolle.

[robbitop]

Die Nachfrage folgt der Wahrnehmung und dem P/L. Und auch die graue Masse schaut auf youtube Benchmarks oder hört wenigstens auf Empfehlung des jeweiligen Meinungsmultiplikators oder fragt jemanden im Bekanntenkreis der das tut. Und die Meinungsmultiplikatoren lassen so gut wie immer MT mit einfließen.

Würde das nichts bringen hätte Intel die E Cores nicht eingeführt. Deren Marketingleute sind sicherlich deutlich besser darin sowas einzuschätzen. Und laut Roadmap wird Intel immer stärker darauf zu setzen. E cores sind super billig.

[fondness]

Die Frage wo der praktische Nutzen ist darf natürlich trotzdem gestellt werden. Für Spiele bringen mehr wie 8C nach wie vor wenig bis nichts. Das dürfte sich aufgrund der Konsolen wohl auch nicht so schnell ändern. Nur für ganz wenige Anwendungen bringt die so viel beachtete MT-Leistung einen Vorteil. Aber klar wie schon gesagt, Marketingtechnisch sollte man das trotzdem nicht unterschätzen.

[HOT]

Die werden sicherlich den normalen TR wiederbeleben bei Bedarf und den dann auch zeitnah bringen. Mehr als 16C für Desktop zu erwarten ist aus meiner Sicht pure Traumtänzerei. Die werden einfach ein neues CCD in N4(X) bringen mit 8 Zen5 und fertig, das IOD bleibt eh dasselbe wie jetzt auch.
Aber das ist auch gar nicht anders nötig, ihr habt ja wieder ARL im Kopf. Das könnt ihr vergessen, da ARL eh erst der Zen6-Gegner wird. Vor 25 könnt ihr das einfach knicken.
ARL und MTL sind zwei komplette Generationen, nur LNL soll ne Ergänzung sein. Das heißt also, zum Jahreswechsel 23/24 kommt erst mal MTL, in 25 dürfte dann die ARL-Generation folgen. also hat AMD bei Zen5 doch auch überhaupt keinen Druck für mehr MT, da MTL-S ja eh wieder 8+16 haben wird.

Bis Zen6 geht alles weiter wie bisher, danach muss AMD wirklich dringend was an der CCD-Problematik tun. Man muss aus den 2 L3$es jetzt unbedingt einen machen, vielleicht einen virtuellen, indem man die CCDs aufs IOD stapelt oder ähnliches. Die Inter CCD-Kommunikation wird auf jeden Fall immer problematischer, je schneller die Dinger werden. Da muss nach Zen5 unbedingt was passieren. Vielleicht wirds ja auch ne komplett neue Topologie, dann kann man auch über Littles neu nachdanken. Aber bis Zen5 sollte man das einfach vergessen, das ist und bleibt Blödsinn.

[Complicated]

Die Nachfrage folgt der Wahrnehmung und dem P/L. Und auch die graue Masse schaut auf youtube Benchmarks oder hört wenigstens auf Empfehlung des jeweiligen Meinungsmultiplikators oder fragt jemanden im Bekanntenkreis der das tut. Und die Meinungsmultiplikatoren lassen so gut wie immer MT mit einfließen.

Würde das nichts bringen hätte Intel die E Cores nicht eingeführt. Deren Marketingleute sind sicherlich deutlich besser darin sowas einzuschätzen. Und laut Roadmap wird Intel immer stärker darauf zu setzen. E cores sind super billig.
Wir sind doch aber hier nicht in einem Marketing-Forum. Das was sich gut verkauft, muss ja technisch nicht immer eine Reaktion zur Folge haben. Da verschiebst Du gerade etwas die Pfosten bei der Argumentation. Weder Intel noch AMD können Ihre Strategie alle 6 Monate nach dem besten Marketing-Schachzug ausrichten, weil sich die Foristen langweilen und das nächste kontroverse Thema brauchen, um Ihrer Marke zu huldigen. Kann man natürlich mitmachen, fragt sich nur wieso.

[Nightspider]

Ihr denkt imo zu konservativ.

Die Packackingverfahren sind mittlerweile an einem Punkt, wo es imo keinen Sinn mehr macht so viel Cache in einem CPU Chip zu haben. Zen4c ist da nur der Anfang.
An diesem Punkt sollte man vielleicht bei Spekulationen aufhören Zen5 bzw. dessen CCD als einen Chip zu betrachten.

Cache im großen Stil (L3 vielleicht komplett) auslagern macht imo am meisten Sinn für Manycores.
Es gibt so viele Anwendungen die wenig von L3 profitieren bzw. so viel mixed workload, das nicht alle Kerne gleich viel Cache benötigen, wie bei Intels Ansatz.

>Theoretisch< könnte AMD schon jetzt noch ~4-5 Zen4 Kerne an das bisherige Chiplet "dranpappen" ohne den Chip massiv zu vergrößern, wenn man den L3 gleich groß behält. Das würde die MT Leistung massiv erhöhen in den Apps, die nicht so Cache-lastig sind und den Chip kaum 20-25% größer machen.

Ich glaube die Anzahl der Kerne ist weniger das Problem.

Wenn AMD den L3 halbieren würde, könnten sie pro Wafer 25% mehr CPUs belichten.
Selbst das Vierteln des L3s halte ich für denkbar, wie bei den APUs bliebe genug "Grundleistung" vorhanden, die dann mit V-Cache "unleashed" werden könnte.
Damit könnte AMD fast auf der gleichen Fläche 16 Kerne anbieten oder eben 8 viel breitere Kerne bauen.

Und optional wirds in Zukunft immer V-Cache geben, bis es noch bessere Methoden gibt.

Aktive Cache-Layer als "Interposer" für mehrere Chiplets sind vielleicht auch schon für 2024 denkbar.
Das AMD an aktiven Interposern forscht ist ja bekannt.

[robbitop]

Die Frage wo der praktische Nutzen ist darf natürlich trotzdem gestellt werden. Für Spiele bringen mehr wie 8C nach wie vor wenig bis nichts. Das dürfte sich aufgrund der Konsolen wohl auch nicht so schnell ändern. Nur für ganz wenige Anwendungen bringt die so viel beachtete MT-Leistung einen Vorteil. Aber klar wie schon gesagt, Marketingtechnisch sollte man das trotzdem nicht unterschätzen.
Ja Leute wie wir wissen das. Aber die Masse sind absolute Dullis. Da wird gekauft was empfohlen wird. Und mehr Kerne klingt mehr und mehr ist besser. Und die Reviews testen und gewichten es halt auch. Entsprechend hat es einen Einfluss (wie du ja auch einräumst).
Und sogar als informierter Forenleser finde ich den 13600K extrem attraktiv ggü den 7600X. Gleiche P Core anzahl die grob gleichschnell sind und on Top noch 8 E Cores. Da kann man Zeug im Hintergrund drauf parken und es wird wahrscheinlich sogar für threadheavy Games (siehe RT) gegen nur 6 Cores sogar was bringen. Allein deshalb würde ich aktuell in der Preisklasse tatsächlich eher den 13600K empfehlen. Bzw wenn dann eher den 5600 (ohne X) weil der einfach super bepreist ist und die Plattform billig ist.

[robbitop]

Die werden sicherlich den normalen TR wiederbeleben bei Bedarf und den dann auch zeitnah bringen. Mehr als 16C für Desktop zu erwarten ist aus meiner Sicht pure Traumtänzerei. Die werden einfach ein neues CCD in N4(X) bringen mit 8 Zen5 und fertig, das IOD bleibt eh dasselbe wie jetzt auch.
Aber das ist auch gar nicht anders nötig, ihr habt ja wieder ARL im Kopf. Das könnt ihr vergessen, da ARL eh erst der Zen6-Gegner wird. Vor 25 könnt ihr das einfach knicken.
ARL und MTL sind zwei komplette Generationen, nur LNL soll ne Ergänzung sein. Das heißt also, zum Jahreswechsel 23/24 kommt erst mal MTL, in 25 dürfte dann die ARL-Generation folgen. also hat AMD bei Zen5 doch auch überhaupt keinen Druck für mehr MT, da MTL-S ja eh wieder 8+16 haben wird.

Bis Zen6 geht alles weiter wie bisher, danach muss AMD wirklich dringend was an der CCD-Problematik tun. Man muss aus den 2 L3$es jetzt unbedingt einen machen, vielleicht einen virtuellen, indem man die CCDs aufs IOD stapelt oder ähnliches. Die Inter CCD-Kommunikation wird auf jeden Fall immer problematischer, je schneller die Dinger werden. Da muss nach Zen5 unbedingt was passieren. Vielleicht wirds ja auch ne komplett neue Topologie, dann kann man auch über Littles neu nachdanken. Aber bis Zen5 sollte man das einfach vergessen, das ist und bleibt Blödsinn.
Du vergisst die kleinen SKUs leiden bereits heute daran. Siehe 7600X vs 13600K. Dementsprechend gibt es bereits zeitnah Handlungsbedarf. Entsprechend müsste man alternativ für den gleichen Preis mehr Cores spendieren. Also der 8600X hätte dann 8 Cores.

Threadripper kann man vergessen. Viel zu teuer. Wenn Intel 8+32C im Mainstream anbietet bringt es nichts mit HEDT dagegen zu halten.
Wie man es auch dreht man muss in jeder SKU Kategorie in MT mit den Intel Pendants dagegenhalten können.

[robbitop]

Ihr denkt imo zu konservativ.

Die Packackingverfahren sind mittlerweile an einem Punkt, wo es imo keinen Sinn mehr macht so viel Cache in einem CPU Chip zu haben.
An diesem Punkt sollte man vielleicht bei Spekulationen aufhören Zen5 bzw. dessen CCD als einen Chip zu betrachten.

Cache im großen Stil (L3 komplett) auslagern macht imo am meisten Sinn für Manycores.
Es gibt so viele Anwendungen die wenig von L3 profitieren bzw. so viel mixed workload, das nicht alle Kerne gleich viel Cache benötigen, wie bei Intels Ansatz.

>Theoretisch< könnte AMD schon jetzt noch ~4-5 Zen4 Kerne an das bisherige Chiplet "dranpappen" ohne den Chip massiv zu vergrößern, wenn man den L3 gleich groß behält. Das würde die MT Leistung massiv erhöhen in den Apps, die nicht so Cache-lastig sind und den Chip kaum 20-25% größer machen.

Ich glaube die Anzahl der Kerne ist weniger das Problem.

Wenn AMD den L3 halbieren würde, könnten sie pro Wafer 25% mehr CPUs belichten.
Selbst das Vierteln des L3s halte ich für denkbar, wie bei den APUs bliebe genug "Grundleistung" vorhanden, die dann mit V-Cache "unleashed" werden könnte.

Und optional wirds in Zukunft immer V-Cache geben, bis es noch bessere Methoden gibt.

Aktive Cache-Layer als "Interposer" für mehrere Chiplets sind vielleicht auch schon für 2024 denkbar.
Das AMD an aktiven Interposern forscht ist ja bekannt.
Das Problem dürfte Latenz für den L3 sein. Je mehr Teilnehmer und je weiter weg desto langsamer wirds. Ggf für einen L4 sinnvoll.

[Complicated]

Aktive Cache-Layer als "Interposer" für mehrere Chiplets sind vielleicht auch schon für 2024 denkbar.
Das AMD an aktiven Interposern forscht ist ja bekannt.
Und dieses Jahr auch ein Patent dazu veröffentlicht hat. Genau da wird derzeit der Vorsprung entschieden oder verloren. Beim Interconnect und dem schnelleren/latenzärmeren anbinden der Chiplets. Durch Fertigung/Packaging/Stromreduzierung. Dass der IF in zwei Cchannels gesplittet wurde um ihn bei Bedarf bei halber Bandbreite laufen zu lassen, deckt weitere Custom-Usecases ab für geringeren Verbrauch bei der Transferleistung zwischen Chiplets.

Es macht aber auch Chiplet-verschränkte Topologien für den NoC möglich, die auf aktiven Interposern enorme Vorteile bieten und Platzersparnis bieten. Auch könnte es ein Mittel gegen die Hotspots sein, bei kleineren Dies.