Zen 4 (Raphael, Phoenix & Genoa, 5 nm, AM5, DDR5, PCIe 5.0, Ende 2022)

[Unicous]

LOL, Hörensagen. Der war gut. Ein Typ der pampig reagiert wenn man seine Quellen anzweifelt bzw. seine Videos löscht wenn man ihn anzählt ist doch kein "guter" Leaker. Ich kann auch Google Translate anschmeißen und das dann als exklusive leaks ausgeben. Ich habe um ehrlich zu sein keinen Bock das Ganze aufzudröseln, weil ihr nicht daraus lernt und immer wieder eine neue Kuh durch das Dorf treibt. Den blinden Hahn zum Propheten zu machen weil es mal ein Korn aufgesammelt hat und deswegen laut herumkrakeelt scheint wohl für euch kein Problem zu sein.

[Ex3cut3r]

Ganz dumme Frage, aber wer braucht wirklich AM5, wenn jemand wie ich, nen 5950x am laufen hat?

Mir erschließt sich der Sinn für den Moment nicht :confused:

10% bessere Min-FPS, wo sich wieder alle dran aufgeilen :rolleyes:

Imo sind wir CPU-seitig von AMD doch sehr gut versorgt, von daher erschließt sich mir eine neue CPU, Board, Ram nicht wirklich - sorry

Ich sehe das ehrlich gesagt genau so. Zen 3 ist schnell genug als Gamer für diese Konsolen Gen. Notfalls nochmal DDR4 Tuning betreiben, dann kommen nochmal bis zu 30%+ on Top.

Lieber das Geld in ne GPU, Monitor, SSD stecken (wenn wieder Normalität herrscht) als in CPU, DDR5 und MB. Wovon du in 95% der Fälle gar nix merken wirst. Daher vollkommen langweiliige Produkte (für mich jedenfalls) da kein Interesse besteht. Ich wechsele als Gamer doch nicht jedes Jahr CPU, Board und RAM gegeben falls, ich glaube ich spinne. Da frage ich mich schon....die Hypnose der Firmen scheint auf viele wirklich gut zu wirken. ;D

[Nightspider]

Du meinst weil Jaguar+30% IPC am PC 2014 für genügend FPS in CPU intensiven Games wie Battlefield 4 gereicht hätte? :rolleyes:
Zumal die Konsolen in dieser Gen viel näher am PC takten.


Für die meisten wird das sicherlich reichen aber wer von Zen2 kommt ist besser bedient auf Zen4 zu wechseln denn Zen4 wird nun mal viel besser als Zen3.

[Ex3cut3r]

KA, was du BF5 hast. Das Game gibt es nicht mal. Wird wahrscheinlich wieder gut mit Kernen skalieren. Zen 4 ist komplett unnötig. Wenn man Zen 2 oder Zen 3 ab 8C/16 mit DDR4 Tuning betreibt. Frametimes stimmen, da gut genug Thread da sind. Die 20-30 mehr FPS im CPU Limit (BF5) jucken mich nicht. Wieder 600€ in CPU, Board, RAM zu stecken. Dazu 4K und 1440p machen die Mehrheit der Auflösungen aus. Bei BF4 waren noch 1080p der Standard. Dazu hatten die meisten Gamer Kern Krücken wie nen typischen i5 ohne HT. Mit Ryzen sind die Zeit der Thread Krücken zum Glück vorbei, wenn der Game Hersteller mindestens 10 Threads richtig auslastet, braucht man keine Angst mehr haben.

[rentex]

Er hat 850+ für seine CPU ausgegeben und will daher nicht, dass gleich etwas schnelleres raus kommt. Ist eine Prestige Sache.

Mir gehts auch a bissl so mit meinem 5900er. ;)
An 30% glaube ich bei Spielen ehrlich gesagt nicht. 20% wären schon sensationell.

Mir ist es wurst, ob ZEN 4 20% schneller wird.
Ich freu mich eher, das AMD nen guten Lauf hat und die Fähigkeit besitzt, solche Geschosse zu releasen!
Hätte jemand vor 6 Jahren behauptet, das se so durchstarten, hätte ich deren Aktien gekauft.

[w0mbat]

Was ist das denn für eine komische Diskussion hier? Könnt ihr die bitte auslagern oder so, hat ja nichts mit Zen4 zu tun.

Sorry, aber mit dieser Einstellung aka "meine alte CPU reicht noch, warum soll nächstes Jahr eine neue kommen?" hat man mMn nichts im 3DC zu suchen :ugly:

Was für eine absurde Position...

[Cyberfries]

Die Beweispflicht gilt in beide Richtungen.
Bei MLID sammeln sich über alle drei Hersteller hinweg zuviele Fehlinformationen an um ernstgenommen zu werden.

Redgamingtech berichtete vom Infinity Cache am 11.9.20, MLID erst am 1.10.20.
Im gleichen Zug "korrigierte" MLID einige seiner Falschaussagen mit der Behauptung, AMD hätte "verschiedene" Modelle getestet.
Und er hat gleich neue Falschbehauptungen in Bezug auf 10gb N21 und "geleakte Preise" dargelegt.
Die übrigen genannten Infos waren schon seit Monaten bekannt.

Am 17.6.2020 wurde von MLID ein 448bit-SI, maximal 72CU und Wasserkühlung für N21 geleakt.
Und noch etwas früher sprach er von 70CUs, 427mm² und HBM.
Immer bedenken: 80CUs waren sind seit 2019 bekannt, alles sonst waren Erfindungen der "Leaker".

[THEaaron]

KA, was du BF5 hast. Das Game gibt es nicht mal. Wird wahrscheinlich wieder gut mit Kernen skalieren. Zen 4 ist komplett unnötig. Wenn man Zen 2 oder Zen 3 ab 8C/16 mit DDR4 Tuning betreibt. Frametimes stimmen, da gut genug Thread da sind. Die 20-30 mehr FPS im CPU Limit (BF5) jucken mich nicht. Wieder 600€ in CPU, Board, RAM zu stecken. Dazu 4K und 1440p machen die Mehrheit der Auflösungen aus. Bei BF4 waren noch 1080p der Standard. Dazu hatten die meisten Gamer Kern Krücken wie nen typischen i5 ohne HT. Mit Ryzen sind die Zeit der Thread Krücken zum Glück vorbei, wenn der Game Hersteller mindestens 10 Threads richtig auslastet, braucht man keine Angst mehr haben.

Am besten wir hören alle auf CPUs zu kaufen. Wir haben das Endgame mit Zen3 erreicht. Rofl.

[Ex3cut3r]

Haben wir auch. Zen 2 ist ausreichend für diese Konsolen Gen. Zen 3 + DDR4 Tuning ist optimal. Wenn ihr schon wieder 700€ investieren wollt, bitte. Von mir aus. Die Firmen danken es euch. ;D

Denkt auch schön daran, gleich noch den schönen DDR5 "Anfagnbonus" zu zahlen. Wir reden hier von 400-500€ für nen 32GB DDR5 5200 Kit mit Samsung Chips. Das Optimum 6400 Mhz wird sogar nochmal teurer. Viel Spaß mit euren 20% mehr im CPU Limit, die man in 95% niemals merken wird. :crazy:

[Nightspider]

Die Diskussion ist auch dämlich.
Es ist noch nicht mal ein NextGen Spiel auf dem PC erschienen aber Ex3cut3r meint ein aktueller Prozessor reicht aus. Laut ihm müsste ja sogar ein 5600X mit 6 Kernen ausreichen.

2014 hatte ein typischer PC Prozessor (4770K) ca. 4 mal so viel pro Kern Leistung wie ein PS4 CPU Kern.
Heute hat der schnellste Prozessor "nur" ~74% mehr pro Kern Leistung als die PS5.
Ob das die LowLevelAPIs ausgleichen können müssen wir erstmal abwarten.

Schließlich werden die Games bei den Konsolen eher auf 60fps optimiert und am PC wollen wir uns doch nicht mit 60fps zufrieden geben in einem competitiven Shooter.
Also ich würde erstmal die ersten NextGen Spiele abwarten, bevor ich hier Aussagen raushaue.

Ich wette bei der BF6 Beta (angeblich) im nächsten Monat werden einige blöd dreinschauen, bei den CPU Anforderungen.

Zen 2 ist ausreichend für diese Konsolen Gen.:

Weil Jaguar CPUs am PC 2014 auch ausgereicht haben? Troll weiter.

[Platos]

Fortschritt ist doch immer gut? Es ist ja niemand "gezwungen" extra nur wegen einer einzigen CPU Generation aufzurüsten (auch nicht 2,3 oer 4 Generationen).

Aber je mehr Leistung, desto weniger Stromverbrauch. Man könnte also auch in kleinerem Formfaktor irgendwann PS5 Leistung haben. Also Fortschritt=immer gut (wobei Fortschritt nicht = mehr Leistung ist sondern mehr Leistung pro Watt und Dollar).

Weil Jaguar CPUs am PC 2014 auch ausgereicht haben? Troll weiter.

Das ist nicht mal ansatzweise zu vergleichen. Jaguar CPUs waren schon damals scheisse und dazu kommt noch, dass die letzte Generation keine 120FPS gesehen hat (wollte man also am PC 120FPS, musste man mindestens die doppelte Perfomance haben quasi). Diese Generation gibts aber 120FPS bei den Konsolen. Man muss also "nur" mehr GPU Power haben, aber nicht deutlich viel mehr CPU Leistung (zumal ja die Taktraten bei den Konsolen sowieso niedriger sind wie bei Zen2 Desktop CPUs).

Also für 144Hz sollte Zen3 locker reichen und Zen2 vermutlich auch schon, weil die deutlich höher getaktet sind am PC (8-Kerner).

Naja, es sei denn aufgrund der SSDs der Konsolen steigt die CPU Last am PC an.

[Nightspider]

Das ist nicht mal ansatzweise zu vergleichen. Jaguar CPUs waren schon damals scheisse und dazu kommt noch, dass die letzte Generation keine 120FPS gesehen hat (wollte man also am PC 120FPS, musste man mindestens die doppelte Perfomance haben quasi). Diese Generation gibts aber 120FPS bei den Konsolen.

Hast du die gleiche Kristallkugel wie Executer? ;D

https://www.gamepro.de/artikel/ratchet-clank-rift-apart-60fps,3361379.html


Also für 144Hz sollte Zen3 locker reichen und Zen2 vermutlich auch schon, weil die deutlich höher getaktet sind am PC (8-Kerner).

Klar reichen die für stabile 30-60fps ;D

Alles darüber hinaus müssen wir abwarten.

Und Windows10, Denuvo und die Treiber werden von deinem Netzteil beschleunigt oder wie?

[aufkrawall]

Und Windows10, Denuvo und die Treiber werden von deinem Netzteil beschleunigt oder wie?
Konnte man denn bisher den Eindruck gewinnen, dass DX12 auf der Konsole eine wesentlich bessere CPU-Performance als auf dem PC schafft (Nvidias Treiber-Schwäche in zumindest einigen Titeln mal ausgeklammert)?

[Nightspider]

Nutzt überhaupt jemand DX12 auf den Konsolen? Damit habe ich mich nicht auseinandergesetzt.
Die Spiele wurden vorher schon hardwarenah programmiert, mit DX12 kann es ja fast nur schlechter von der Effizienz laufen. Eventuell vereinfacht DX12 nur manche Programmierarbeit bei Xbox Series Spielen bzw. deren Portierung zum PC. Letzteres ist wahrscheinlich der Hauptgrund für DX12 für die Xbox Series.

Eventuell verschiebt ein Mod mal die Diskussion in einen eigenen Thread mit dem Titel.
"Welche CPU Anforderungen sind von anspruchsvollen NextGen Portierungen zu erwarten?"

Wenn ich mich nicht irre hat die PS5 auch eigene Hardware für die SSD Rechenarbeit. Am PC muss das auch alles die CPU übernehmen.

[THEaaron]

Sony hat ne eigene API. MS nutzt seit der Xbox one DX12 afaik.

[Platos]

Hast du die gleiche Kristallkugel wie Executer? ;D

https://www.gamepro.de/artikel/ratchet-clank-rift-apart-60fps,3361379.html


Und du weisst jetzt woher, dass das Spiel im CPU Limit hängt?

Im Gegensatz dazu gibts genug Spiele, die auf der PS5 mit über 100 FPS laufen. Aber mach doch was du willst :D Für diese Märchenstunden-Disskussionen hier in dem Thread, habe ich sowieso keine Zeit

[Nightspider]

Was hat denn das mit CPU Limit zu tun? Wenn ein Spiel für 60fps programmiert wird wird die übrige CPU Rechenleistung eben auch für mehr Effekte (Physik, Partikeleffekte usw usw) genutzt.

Und Rift Apart hat in manchen Szenen hunderte bewegende Objekte/Figuren.

Glaubst du da liegt jetzt haufen CPU Leistung bei Rift Apart oder anderen 60fps Titeln brach, nur weil die GPU auf 100% läuft?



Im Gegensatz dazu gibts genug Spiele, die auf der PS5 mit über 100 FPS laufen. Aber mach doch was du willst :D Für diese Märchenstunden-Disskussionen hier in dem Thread, habe ich sowieso keine Zeit

Spiele die auf den Jaguar Kernen mit 30fps liefen? Was eine Kunst. :rolleyes:

[Ex3cut3r]

Die Diskussion ist auch dämlich.
Es ist noch nicht mal ein NextGen Spiel auf dem PC erschienen aber Ex3cut3r meint ein aktueller Prozessor reicht aus. Laut ihm müsste ja sogar ein 5600X mit 6 Kernen ausreichen.

2014 hatte ein typischer PC Prozessor (4770K) ca. 4 mal so viel pro Kern Leistung wie ein PS4 CPU Kern.
Heute hat der schnellste Prozessor "nur" ~74% mehr pro Kern Leistung als die PS5.
Ob das die LowLevelAPIs ausgleichen können müssen wir erstmal abwarten.

Schließlich werden die Games bei den Konsolen eher auf 60fps optimiert und am PC wollen wir uns doch nicht mit 60fps zufrieden geben in einem competitiven Shooter.
Also ich würde erstmal die ersten NextGen Spiele abwarten, bevor ich hier Aussagen raushaue.

Ich wette bei der BF6 Beta (angeblich) im nächsten Monat werden einige blöd dreinschauen, bei den CPU Anforderungen.



Weil Jaguar CPUs am PC 2014 auch ausgereicht haben? Troll weiter.

Das ist doch alles gar nicht vergleichbar, was mal früher war. Seit Zen 1/2 hat man genug Threads als PCler. Warum sollten die Entwickler endlich mal vernünftig für wenigstens 8C/16T programmieren?

Aber bitte, wie ich schon sagte, wer meint wegen 20% am ende Mehrleistung im CPU Limit und nur da, so eine gewaltige Summe von mindestens 700€ zu investieren bitte, der soll das tun. Ich finds einfach nur lächerlich, wegen jeden Prozent, gleich wieder den halben PC "aufzurüsten" Aber das muss man AMD lassen, irgendwie machen Sie einiges richtig im Marketing, dass jetzt jeder Gamer meint, jeden Zen mitnehmen zu müssen.

[Nightspider]

Dir ist schon klar das es hier im Forum viele und außerhalb des Forums noch mehr Besitzer eines Zen2 6Kerners gibt?

Oder sollen jetzt alle auf einen Zen2 oder Zen3 Prozessor mit 12 Kernen wechseln?

Hat ein 5600x deiner Meinung nach auch genügend Threads?

[Der_Korken]

Was ist das denn für eine Diskussion hier? Zen 4 braucht keiner, weil Zen 3 schnell genug ist? Ist ja schön und gut für die, die schon einen Zen 3 haben. Ich bin noch mit Zen 1 unterwegs und würde gerne Zen 4 kaufen, weil ich immer gerne auf doppelte Leistung aufrüste und mir das Upgrade auf Zen 3 nicht groß genug ist (bzw. ich mehr als 8 Kerne nicht sinnvoll nutzen kann, sonst würde ich mir einen 5900X kaufen). Mehr ST-Leistung kann man immer nutzen. Es gibt ja auch noch eine Welt außerhalb von Spielen.

[ChaosTM]

30% mehr IPC wäre grandios. Der dumme Flightsimulator 2020 kann davon gar nicht genug kriegen. Besserung ist da auch nicht in Sicht. DX12 hilft lt. den Entwicklern nur marginal..

[Zossel]

Wenn ich mich nicht irre hat die PS5 auch eigene Hardware für die SSD Rechenarbeit. Am PC muss das auch alles die CPU übernehmen.

Es wird eh langsam Zeit das X64 HW bekommt die gängigen Kompressionsverfahren Huffman-Coding, RLE bzw. LZ* unterstützt.

Für Spiele kann man das in die GPU packen, das spart Bandbreite.

[Blediator16]

https://youtu.be/gqAYMx34euU?t=2324

Lisa Su
"we will be ready to start production on our highest end products with 3d chiplets by end of this year "

EDIT:

https://www.forum-3dcenter.org/vbulletin/showthread.php?p=12695449#post12695449

[amdfanuwe]

Gehört in den ZEN 3 Thread.

[Nightspider]

Ob Zen4 dann vom Release an gleich mit Stacked Cache Optionen kommen wird?

Sonst hätte ja Zen3+ schon ""die Hälfte"" vom Vorsprung aufgefressen.

Wenn die +20-28% IPC bei Zen4 stimmen und dann nochmal 15% durch den stacked Cache dazukommen würde und eventuell 200-300Mhz mehr dann wären das fast 50% mehr ST(!!!!) Leistung gegenüber Zen3.

Holy... :ugly:

[amdfanuwe]

Mal abwarten. Cache hilft ja nicht bei allen Applikationen.
Bei den ausgewählten Spielen bringt es zwischen +4% bis +25%.
Bei Anwendungen eventuell gar nichts.
Bleiben wir erst mal bei den durchschnittlichen +20% für ZEN4.

[w0mbat]

Ich könnte mir gut vorstellen, dass die Zen4 CCDs weniger cache haben, weil der dann in Form eines stacks oben drauf kommt. Also zB Zen4 CCD mit nur 16MB L3 cache (oder noch weniger) und dann 64MB+ einfach oben drauf.

[HOT]

Glaub ich nicht. Der wird genau so 32MB wie jetzt auch, nur eben 15% dichter. Hinzu käme dann noch ein Cache-Stack-Die in N6, das von der Packdichte her sehr gut passen dürfte. Zen4 wird die gleiche Cache-Größe bei L3 haben wie Zen3. Bei L1 und L2 sieht das anders aus, hier erwarte ich durchaus größere Caches. Und bei Zen5 kommt dann noch ein L4 hinzu.

[basix]

Zen 4 Release Q4? Bei CB gibt es eine Roadmap von SoIC 3D-Stacking, welches 5nm-on-5nm in Q3-2022 als Qualification anzeigt (7nm-on-7nm Q4-2021, wo ja die Zen 3 X3D Produktion starten soll).
https://www.computerbase.de/2021-06/tsmc-3d-packaging-ist-das-naechste-grosse-ding/

Was sich auch daraus ergibt (Speku): 3D-SoIC funktioniert nur mit Chips im selben Node? Würde bedeuten, dass man den SRAM auch in 5nm herstellen müsste. Würde ich schade finden, da man SRAM besser im 6/7nm Node belassen würde (Kosten, 5nm Waferkapazität)

[Zossel]

Wie könnte wohl das Ding für den Atombombencomputer aussehen? Die Datenströme sollten ja über möglichst wenige Chiplets gehen um möglichst wenig Energie für zum datenschaufeln zu verbrauchen.

TSMC hat bis zu 8 HBM Stacks in einem Package für 2021 angekündigt: https://www.anandtech.com/show/16036/2023-interposers-tsmc-hints-at-2000mm2-12x-hbm-in-one-package Das wäre bis 128Gbyte HBM pro Package.
Der Vector-Rechner von NEC sieht so aus: https://en.wikichip.org/wiki/nec/microarchitectures/sx-aurora

Wohin setzt man die Interconnects? Eigenes IO-DIE? Auf den Vector-Chip? Vieleicht ein eigenes DIe nur mit PHYs?
Wohin die IF? Eigenes IO-DIE? Auf den Vector-Chip?

Was wäre eine sinnvolle Anordnung?

[HOT]

Noch ein Hinweis, dem Ian von Anandtech nachgegangen ist:
Warum kann das Stack-Cache-Die doppelt soviel Cache auf der gleichen Fläche unterbringen wie die Cache-Fläche der CPU?
Der N7, der für das Cache-Die genutzt wird unterscheidet sich von dem der CPU, denn für die CPU wird N7 logik-optimiert eingesetzt und beim Cache-Subdie eine Cache-optimierte Variante. So kommt es, dass das Subdie doppelt soviel Cache auf die gleiche Fläche bekommt trotz gleichen Prozesses.
Es ist also überhaupt nicht klar, welche Fertigungsprozesse künftige Stack-Caches haben werden, da sich die Packdichte für reine Cache-Dies eh unterscheidet. AMD kann durchaus den Cache in N6 produzieren und die CPU in N5. Ich halte Cache-Dies in N5 aufgrund des schlechten Preis/Leistungsverhältnisses in N5, da sich die Packdichte ja kaum verbessert ggü. N7, für sehr unwahrscheinlich.

[Nightspider]

Wäre naheliegend.

Das MCD von RDNA3 soll ja auch in 6nm kommen und wird viel Cache besitzen.
Würde mich nicht wundern wenn das MCD V-Cache benutzt um Kosten und Latenz klein zu halten.

[w0mbat]

Mein Ziel wäre ein logic-die ohne L3 cache und ein reines cache-die, das man stacked.

[Zossel]

Noch ein Hinweis, dem Ian von Anandtech nachgegangen ist:
Warum kann das Stack-Cache-Die doppelt soviel Cache auf der gleichen Fläche unterbringen wie die Cache-Fläche der CPU?

IMHO (irgentwo gelesen) ist das on-top "gestackte" Die ein reines SRAM-Array, die Ansteuerung des SRAM-Arrays ist auf dem CPU-Die.

SRAM besteht nicht nur aus Flip-Flops, es braucht auch Logik zur Ansteuerung.

[basix]

Mein Ziel wäre ein logic-die ohne L3 cache und ein reines cache-die, das man stacked.

Wäre von der Flächennutzung her ideal, verursacht aber Probleme bei Hotspots und/oder Datenleitungen zum Logic Die. Realistischer ist, dass ein minimaler L3$ + Kontrolllogik auf dem Logic-Die bleibt und man den V-Cache särker in die Höhe baut. 8-hi ist anscheinend möglich. Da kann man den L3$ auf den Logic-Die halbieren und erhält als Maximum immer noch 16 + 256MB Cache.

Siehe dazu auch meinen Post im Zen 3 Thread: https://www.forum-3dcenter.org/vbulletin/showpost.php?p=12697595&postcount=421

IMHO (irgentwo gelesen) ist das on-top "gestackte" Die ein reines SRAM-Array, die Ansteuerung des SRAM-Arrays ist auf dem CPU-Die.

SRAM besteht nicht nur aus Flip-Flops, es braucht auch Logik zur Ansteuerung.
Da hast du Recht, keine Kontrolllogik auf dem SRAM-Die. Siehe CB News, Update 2: https://www.computerbase.de/2021-06/3d-v-cache-technology-amd-stapelt-l3-cache-bei-ryzen-auf-192-mbyte/

[Erbsenkönig]

Bitte entschuldigt die blöde Frage, aber ich bin dahingehend überhaupt nicht informiert: Ist Zen4 jetzt die erste richtige Neuauflage, sprich neuer Sockel und DDR5, oder kommt das erst später?

[JVC]

"Zen 3+" = AM4
Zen 4 = AM5

M.f.G. JVC

[w0mbat]

Wäre von der Flächennutzung her ideal, verursacht aber Probleme bei Hotspots und/oder Datenleitungen zum Logic Die. Realistischer ist, dass ein minimaler L3$ + Kontrolllogik auf dem Logic-Die bleibt und man den V-Cache särker in die Höhe baut. 8-hi ist anscheinend möglich. Da kann man den L3$ auf den Logic-Die halbieren und erhält als Maximum immer noch 16 + 256MB Cache.
Ja, die Kontrolllogik sollte immer noch auf dem CCD sein, das macht Sinn. Aber stell dir mal einen Zen3 mit zB nur 8MB L3$ vor, darauf dann zwei 16MB Stapel. Insg. hätten man mit 40MB L3$ immer noch mehr als zuvor, das CCD wäre aber deutlich kleiner = es passen mehr auf den wafer und das yield ist höher. Das kleine L3$ die (<10mm²) wäre auch extrem billig.

[amdfanuwe]

3D-SoIC funktioniert nur mit Chips im selben Node?
Kann ich mir nicht vorstellen. Der Automat preßt da 2 Siliziumstücke zusammen. Wie die belichtet wurden ist der Maschine egal.
Das Problem wird da eher die Design Software sein, die momentan nur 7nm mit TSV und Kontaktelementen unterstützt.

Mein Ziel wäre ein logic-die ohne L3 cache und ein reines cache-die, das man stacked.
Da unterscheidest du dich eben von einer Entwicklungsabteilung. Dort werden mehrere Varianten überlegt, diese Simuliert, einige noch getestet und letztendlich das oprimale Verfahren Produziert.
Nur dumm, wenn die entscheidenden Ideen nicht dabei sind oder der Chef das Genie nicht leiden kann und dessen Visionen torpediert oder die Firmenpolitik nichts revolutionäres erlaubt.

[basix]

Aber stell dir mal einen Zen3 mit zB nur 8MB L3$ vor, darauf dann zwei 16MB Stapel. Insg. hätten man mit 40MB L3$ immer noch mehr als zuvor, das CCD wäre aber deutlich kleiner = es passen mehr auf den wafer und das yield ist höher. Das kleine L3$ die (<10mm²) wäre auch extrem billig.

Ungefähr so stelle ich mir das auch vor ;)

Ich frage mich aber, ob sie bei so kleinen Chips dann die Scribe Line verringern. Weiss da jemand was dazu?

Kann ich mir nicht vorstellen. Der Automat preßt da 2 Siliziumstücke zusammen. Wie die belichtet wurden ist der Maschine egal.
Das Problem wird da eher die Design Software sein, die momentan nur 7nm mit TSV und Kontaktelementen unterstützt.

Designtools ist sicher ein Argument. Aber ich habe eher an "richtige" technische Hürden gedacht. Evtl. verwendet man andere Materialien auf N5 und N7, was z.B. Wärmeausdehnungskoeffizienten beeinflusst. Bei SoIC sehe ich dort wenig Spielraum, deutlich weniger als bei Micro Bumps.

[Der_Korken]

Es ist also überhaupt nicht klar, welche Fertigungsprozesse künftige Stack-Caches haben werden, da sich die Packdichte für reine Cache-Dies eh unterscheidet. AMD kann durchaus den Cache in N6 produzieren und die CPU in N5. Ich halte Cache-Dies in N5 aufgrund des schlechten Preis/Leistungsverhältnisses in N5, da sich die Packdichte ja kaum verbessert ggü. N7, für sehr unwahrscheinlich.

Hier liest sich das so, als ob gemischte Stacks gar nicht geplant sind:

https://www.computerbase.de/2021-06/tsmc-3d-packaging-ist-das-naechste-grosse-ding/

Da stehen nur N7-on-N7 und N5-on-N5 auf der Roadmap. Wäre natürlich schade, denn für Zen 4 wäre N7-on-N5 ideal.

[amdfanuwe]

Hans de Vries zählt 24070 TSV auf dem ZEN3 Chiplet.
https://twitter.com/HansDeVriesNL/status/1400027736199081989

[basix]

Hier liest sich das so, als ob gemischte Stacks gar nicht geplant sind:

https://www.computerbase.de/2021-06/tsmc-3d-packaging-ist-das-naechste-grosse-ding/

Da stehen nur N7-on-N7 und N5-on-N5 auf der Roadmap. Wäre natürlich schade, denn für Zen 4 wäre N7-on-N5 ideal.

So habe ich das eben auch verstanden. Und wie du sagst, wäre 6/7N-on-5N optimal für den Cache (zumindest aus unserem Laienverständnis).

Edit:
Geht man all-in mit 8-hi, 64MByte pro V-Cache Slice und 12 CCDs bei Zen 4 EPYC, erhält man total 6528 MByte oder 6.5 GByte an L3$ :D Und das auf total ~4700mm2 Siliziumfläche ;)

Sind sie völlig verrückt und gehen auf 12-hi (was TSMC mal angeteasert hat), landet man bei 9600 MByte oder 9.6 GByte L3$ bei total ~6400mm2 Siliziumfläche :D

[Gipsel]

Geht man all-in mit 8-hi, 64MByte pro V-Cache Slice und 12 CCDs bei Zen 4 EPYC, erhält man total 6528 MByte oder 6.5 GByte an L3$ :D Und das auf total ~4700mm2 Siliziumfläche ;)

Sind sie völlig verrückt und gehen auf 12-hi (was TSMC mal angeteasert hat), landet man bei 9600 MByte oder 9.6 GByte L3$ bei total ~6400mm2 Siliziumfläche :DAMD will vermutlich immer noch CPUs verkaufen, keine SRAM-Stacks mit ein wenig Computing irgendwo noch drangeflanscht :lol:. Und ich weiß nicht wie viele Kunden man noch hätte, bei den Preisen (50k, 100k?), die man für sowas aufrufen würde. Obwohl... :rolleyes:

=============================

Hans de Vries zählt 24070 TSV auf dem ZEN3 Chiplet.
https://twitter.com/HansDeVriesNL/status/1400027736199081989Es war die ganze Zeit vor unseren Augen! :freak:

[basix]

Für bestimmte HPC oder ML/AI Anwendungen kann sich das schon lohnen. RAM ist ja oftmals der grösste Kostenfaktor in einem System und nicht die CPU. Die Cache Slices an sich sollten relativ günstig sein (klein, hoher Yield). Wenn der SoIC Prozess noch bezahlbar ist und man die 7nm Fertigungskapazität hat, wieso nicht?

Mehr lohnen tut es sich dann noch in Richtung GPUs, wo man eh schon zuwenig Bandbreite hat und ML/AI massiv von Bandbreite profitiert (CDNA2/3).

[Zossel]

AMD will vermutlich immer noch CPUs verkaufen, keine SRAM-Stacks mit ein wenig Computing irgendwo noch drangeflanscht

Es gab ja mal den Witz das Intel eigentlich ein Hersteller von RAM ist und irgendwann gemerkt hat das man RAM teurer verkaufen kann wenn man eine CPU mit einbaut :-)
(Intel hat mit DRAM angefangen)

Im Moment scheinen AMD und TSMC den besseren Lauf zu haben wenn man sich anschaut was für Mengen an RAM in den Produkten verbaut werden.

[CrazyIvan]

Uiuiui, Gamers Nexus will bereits im März 2020 ein paar sehr interessant anmutende Folien zugespielt bekommen haben:
https://videocardz.com/newz/amd-raphael-zen4-am5-presentation-from-march-2020-leaks-out

Vor allem die Folie zum schematischen Aufbau sieht für mich authentisch aus. Neues IOD in 7nm und integrierter Navi2 GPU. DDR4/5 war ja bereits bekannt. Neuer Interconnect zwischen IOD und CCD.
Was die Folie mit Raphael auf AM4 bedeuten könnte, habe ich noch nicht verstanden.

[CrazyIvan]

Möglicherweise bringt AMD Zen 4 parallel auf AM5 und AM4? Welchen Sinn würde das für sie machen? Aufrüstwillige abgreifen, die nicht gleich die ganze Plattform wechseln wollen?

[amdfanuwe]

Was die Folie mit Raphael auf AM4 bedeuten könnte, habe ich noch nicht verstanden.
Da wollte wohl nur einer schnell den Systemaufbau verdeutlichen und hat in alten Folien editiert.

edit: Blödsinn gelöscht.
Rembrandt soll DDR 5 haben, Vermeer hat keine Displayausgänge, Cezanne hat nur PCIe 3.0.
Bleibt eigentlich nur, dass als Sockel AM4 Anschlußplan zu sehen und Raphael zu streichen.

[CrazyIvan]

@amdfanuwe
Entweder das, oder schlicht und ergreifend das, was dasteht: Raphael auch auf AM4. Verstehe mich nicht falsch, ich glaube da auch nicht wirklich dran. Aber am Ende kann es AMD doch egal sein, ob die Mobo-Hersteller Geld verdienen. Und nicht jeder ist so scharf auf DDR5 wie manch einer hier.
Darüber hinaus ist die Folie ja auch sehr alt. Vielleicht überlegte man Anfang 2020 noch, Raphael eher und deshalb zu erst auf AM4 zu bringen. Womöglich werden wir das nie erfahren.

[Der_Korken]

Die Pläne können sich auch geändert haben durch die Entwicklung des V-Caches. Für Raphael auf AM4 wäre womöglich ein neuer IOD nötig, wenn es Änderungen am GMI gab. Wenn aber der V-Cache besser funktioniert als erwartet, dann ist AMD ein Zen 3-Refresh mit mehr Cache und etwas mehr Takt vielleicht gut genug als Konter gegen Alder Lake und vor allem schneller verfügbar. Raphael kommt dann direkt mit AM5, DDR5 und V-Cache in N5 (Q3 2022 laut TSMC Roadmap).

[prinz_valium_2]

Hoffen wir es.
Dann gehen die 6000er auch noch auf AM4

[Leonidas]

Ist Zen4 jetzt die erste richtige Neuauflage, sprich neuer Sockel und DDR5, oder kommt das erst später?

In Bezug auf die Plattform: Ja, Zen 4 bringt eine Plattform mit neuem Sockel AM5 und DDR5-Support.
Rein CPU-technisch sind natürlich schon Zen 2 und Zen 3 richtige "Neuauflagen", nur eben weiterhin auf derselben AM4-Plattform.

[HOT]

Rein theoretisch wäre auch möglich den Cache-Zen3 schon auf AM5 zu bringen, wenn Rembrandt ja denselben Sockel schon nutzt. Das würde natürlich voraussetzen, dass das neue IOD schon fertig ist und nicht erst bei Zen4. Dass es sich hierbei nicht um die XTs handeln soll würde diese These eigentlich unterstützten. Im Grunde kann man sich so ein komplettes Lineup bauen, 6800 und 6900 als Zen3+Cache+ neues IOD, 6300-6700 dann einfach Rembrandt ungecached. Raphael ersetzt dann genau diese paar CPUs und bekommt ein neues 6nm-Cache-Die mit 15% weniger Fläche, was dann zum 15% geschrumpften Cache des Durango-CCDs von Raphael passen würde. Man würde dann einfach alles, was Mainstream bis High-End ist mit den APUs abdecken und fertig.

[CrazyIvan]

@HOT
Die Nutzung der Zen 3 CCDs in Verbindung mit dem CIOD von Raphael kann man mit hoher Wahrscheinlichkeit ausschließen, da sich der Interconnect zwischenzeitlich geändert hat und nicht abwärtskompatibel sein dürfte.

[Leonidas]

Vegeta @ Twitter:
https://twitter.com/Broly_X1/status/1401861684403204103

RDNA3 and ZEN4 will be launched around the same time.
RDNA3 will tape out later this year.
Q4 2022

[basix]

Ist vermutlich ja auch im selben N5HPC Prozess ;)

[maximus_hertus]

Dann lohnen sich ja die Zen3 3D CPUs ab Januar 2022 ja doch. Immerhin gut 9 Monate dann bis zum Zen4.

RDNA3 wäre, wenn überhaupt, wohl eher nur kurz vor nVidia dran.


Ohne Alderlake wären das jetzt echt unspannende 12-15 Monate ;) Wobei, so lange man eh nichts kaufen kann, ist es eh egal ^^

[Platos]

9 Monate nennst du "sich lohnen" ? Zumal die Knappheit vermutlich beschissene Verfügbarkeit bedeutet. Bei Zen4 dürfte sie besser sein, das die Konsolen nicht auf 5nm wechseln und die Kapazitäten bis dann noch zusätzlich wachsen.

[amdfanuwe]

Zumal die Knappheit vermutlich beschissene Verfügbarkeit bedeutet.
Zumindest bei CPU ist schon fast alles wieder gut verfügbar. Wenn die Kids wieder in die Schule dürfen und der Homeoffice Notebookbedarf demnächst nachläßt, ist es mit der Knappheit vorbei. Außer die Miner kaufen weiter wie Blöd GPUs auf.

[basix]

9 Monate nennst du "sich lohnen" ?

Wenn man eine bestehende AM4 Plattform nochmals updaten will, wieso nicht. Klar könnte AM5/Zen 4 einiges drauflegen. Die Plattform wird aber mit guter Wahrscheinlich teurer sein und Board + RAM muss man neu kaufen. Zudem die Kinderkrankheiten einer Plattform ausbaden usw.

[Leonidas]

Zen 3 XT/+/3DVC wird auch lange den Portfolio-Unterbau von Zen 4 darstellen, sprich die billigen Plätze belegen. Denn Zen 4 dürfte anfänglich wie Zen 3 nur als Spitzen-Modelle herauskommen.

[Hammer des Thor]

Hallo, was haltet ihr von meiner Idee, dass AMD bei Zen 4 den stacking-cache zur feinen Produktdiverfizierung nutzen könnte? Da ja z.B. die Unterschiede beim 3600/3060X und 3700X/3800x nur durch die Takte sehr klein sind mache ich einen Vorschlag:
7600 6 Kerne ohne stack also mit 32MB L3, 7600X dann plus 1 stack = 64 MB L3, 7700X 8 Kerne plus 1 stack = 64 MB L3, 7800X 8 Kerne + 2 stacks = 96 MB L3, 7900X 12 Kerne plus 3 stacks = 256 MB L3 und 7950 16 Kerne plus 4 stacks = 320 MB L3?

[Nightspider]

zur feinen Produktdiverfizierung

Du meinst Produktdifferenzierung?


7600 6 Kerne ohne stack also mit 32MB L3, 7600X dann plus 1 stack = 64 MB L3

Ein 1 Layer Stack mit 32MB kannst du schon mal vergessen. Wegen popeligen 32MB wird man nicht den Aufwand betreiben.

Und man wird wahrscheinlich nicht so schnell 3 oder 4 Stacks im Consumer Bereich sehen.

Selbst 2 Stacks mit jeweils 64 MB SRAM kosten schon einiges an Waferfläche. Das würden Enthusiasten vielleicht gerade noch bezahlen aber darüber hinaus wird der Nutzen zu klein und die Kosten zu groß.

Also nehmen wir mal an ein 5800X mit +64MB kostet 75 Euro extra und eine +128MB Version kostetn 150 Euro mehr als die Standard-Version, dann würden wahrscheinlich die meisten zur kleineren Version greifen und nur Enthusiasten zu der großen Variante greifen.
Und ja natürlich kann und wird man das wohl zur Differenzierung einsetzen. Auf sowas hatte ich ja schon seit Broadwell bei jeder Generation gehofft aber Intel sah da wohl keinen Bedarf.
Dabei sieht man ja mittlerweile wie viel Leistung der eDRAM von Broadwell noch gebracht hat.

Wahrscheinlich werden die CPUs mit V-Cache auch besser altern als die normalen CPUs. Daher: werden später im Gebrauchthandel auch höher gehandelt, selbst nach Jahren.

[basix]

Die Produktdifferenzierung findet ja vermutlich bei Zen 3 (XT) statt: Ryzen 9 bekommt den V-Cache. Ryzen 3,5,7 nicht.

Bei Zen 4 kann das auf Ryzen 7 runterrutschen, wird somit aber immer noch den teureren Modellen im Portfolio vorbehalten bleiben. Für AMD wäre Ryzen 5 -> Ryzen 7 mit V-Cache ein geniales Upselling Argument. Anstatt einen Ryzen 7600XT wird es dann ein 7800XT, weil schneller in Games und einigen Anwendungen.
Das Upselling Argument hat man bei Zen 3XT mit Ryzen 9 auch schon, für viele wird dieser Sprung her aber zu gross sein (zu teuer). Bei Ryzen 7 liegt deutlich weniger dazwischen.

[HOT]

Geht das irgendwo hervor, dass nur Ryzen9 den Cache bekommt? Das ergibt für mich einfach keinen Sinn.
Ich denke vielmehr, dass man den Cache ins Ryzen 6 Portfolio einbauen wird. Da gibts halt die CPUs mit Cache (>=8C) und es gibt Rembrandt für den Rest (<=8C).

Also
69x0 -> 2 CCD+Cache
6800 -> 1 CCD+Cache
6300-6700 -> Rembrandt und Barcelo mit und ohne IGP und/oder man behält Vermeer bei.

Zen4 ersetzt dann einfach die großen Varianten mit 79x0 und 7800. Ich denke, dass AMD auch deswegen auf die x800-Nummer geweselt ist beim 5800X, denn das wird ab jetzt die 1 CCD-Variante mit Cache werden und alles darunter hat keinen Cache.

Ohne dicken 8C im Portfolio setzt man sich Intels Atacken unnötig aus, mit dem 8C ist man auf der sicheren Seite. Die CPU wird der Hit bei Spielern.

[Der_Korken]

Ich denke auch, dass man über den Cache eine Produktdifferenzierung vornehmen wird, da das auch deutlich sinnvoller ist als SMT abzuschalten (Intel) oder das PPT zu erhöhen, was in der Praxis fast keinen Leistungszuwachs generiert (AMD, 3800X).

Man muss aber sehr aufpassen, dass man die eigene Produktpalette nicht zu sehr kannibalisiert. Für Sechskerner sehe ich z.B. keinen V-Cache, weil das für AMD wahrscheinlich teurer herzustellen ist als ein Achtkerner (die Yields der Chiplets dürften extrem gut sein). Der Achtkerner wird aber mittelfristig dem Sechskerner mit Cache überlegen sein. Interessant wird der Cache erst, sobald weitere Kerne keinen praktischen Nutzen mehr bringen. Ein Achtkerner mit Cache macht z.B. Sinn, weil es imho auch mittelfristig kaum Spiele geben wird, wo sich ein substantieller Gewinn durch mehr als 8 Kerne einstellen wird. Allerdings kannibalisiert man dadurch auch die Modelle mit mehr Kernen aber ohne Cache. 8 Kerne + V-Cache sind billiger herzustellen als 12 Kerne ohne V-Cache (1xCCD+1xCache vs 2xCCD) aber trotzdem für die meisten Anwender schneller, weil die 4 zusätzlichen Kerne unterm Strich weniger bringen. D.h. oberhalb von 8 Kernen sind Modelle ohne Cache dann ziemlich obsolet. Also wäre ein konsistentes Line-Up z.B.

6600(X) - 6 Kerne ohne Cache
6700(X) - 8 Kerne ohne Cache
6800(X) - 8 Kerne mit Cache
6900(X) - 12 Kerne mit Cache
6950(X) - 16 Kerne mit Cache

Was ich mir aber auch vorstellen könnte ist, dass man die Stacking-Technologie nutzt, m die Fläche des Haupt-CCDs zu reduzieren. Man könnte den L3 z.B. auf 16MB schrumpfen, weil man sowieso mindestens einen bis maximal zwei 32MB-Layer draufstackt mit dann ingesgesamt 48MB oder 80MB. Dadurch würde die L3-Latenz vielleicht wieder auf Zen-2-Niveau sinken. Ganz langfristig wird man das ganze vielleicht auch mit dem L2 machen und den L3 als System-Level-Cache auf den IOD verschrieben.

[Hammer des Thor]

gelöscht

[Nightspider]

6600(X) - 6 Kerne ohne Cache
6700(X) - 8 Kerne ohne Cache
6800(X) - 8 Kerne mit Cache
6900(X) - 12 Kerne mit Cache
6950(X) - 16 Kerne mit Cache


So eine Aufstellung hätte ich auch erwartet und würde eigentlich auch am meisten Sinn ergeben.

[amdfanuwe]

Ich denke eher, dass es um die Verringerung des Energieverbrauchs bei der Datenübertragung zwischen Chiplet und I/O gehen wird.
Aktuell verbraucht der I/F auf dem Träger zwischen 1-2 pJ/Bit. Mit Bridges (EMIBs) ließe sich der Verbauch auf ~0,2 pJ/Bit senken, mit stacked Anbindung an den I/O auf 0,05 pJ/bit.
Bei der Anbindung der Chiplets besteht noch Einsparpotenzial das man besser bei den Cores nutzen kann.

[Nightspider]

Der Punkt ist eventuell auch einer der Gründe warum Zen4 (Raphael) auch für die mittelgroße Laptops kommen soll.

Die Effizienz wird durch 5nm verbessert und V-Cache treibt die Effizienz weiter nach oben.

Und wie es aussieht werden um die ~4 CUs im IO Die sitzen.

[amdfanuwe]

Der Punkt ist eventuell auch einer der Gründe warum Zen4 (Raphael) auch für die mittelgroße Laptops kommen soll.

Für Laptops, AiO, embedde macht es auch Sinn wie beim M1 16 GB DRAM mit auf das Package zu setzen. Gibt nochmal ein paar W Einsparung und erleichtert das Boardlayout.

Hauptsache die langweiligen Jahre der Eintönigkeit sind erst mal vorrüber und es bleibt spannend.

[basix]

So eine Aufstellung hätte ich auch erwartet und würde eigentlich auch am meisten Sinn ergeben.

Ich auch, aber evtl. erst bei Zen 4 und nicht Zen 3XT (wo allenfalls nur die 2x CCD SKUs den V-Cache bekommen --> Vermutung). Hängt schlussendlich von Alderlake ab und wie AMD beim Vergleich von Zen 3XT und Zen 4 ihr Portfolio aufbauen wollen. Zen 4 muss ja was neues bieten ;)

Aber sonst macht damit der 6800X verglichen mit 6700X erst wirklich Sinn, wenn beide 8 Kerne haben. Der 3800X(T) war ja sinnfrei.

[Platos]

Ja, Erweiterbarkeit noch weiter zu zerstören ist immer gut ;)

[|MatMan|]

6600(X) - 6 Kerne ohne Cache
6700(X) - 8 Kerne ohne Cache
6800(X) - 8 Kerne mit Cache
6900(X) - 12 Kerne mit Cache
6950(X) - 16 Kerne mit Cache

Ich hoffe, dass es nicht so kommt. Die 12- und vor allem die 16-Kerner sind schon teuer. Durch den extra Cache würden sie noch teurer. Je ein non-X Modell (oder wie auch immer benannt) ohne Cache und damit zu einem günstigeren Preispunkt würde ich auf jeden Fall sinnvoll finden.

[Der_Korken]

Ich hoffe, dass es nicht so kommt. Die 12- und vor allem die 16-Kerner sind schon teuer. Durch den extra Cache würden sie noch teurer. Je ein non-X Modell (oder wie auch immer benannt) ohne Cache und damit zu einem günstigeren Preispunkt würde ich auf jeden Fall sinnvoll finden.

Ich übersetze das mal in: "Hoffentlich wird Zen 4 nicht zu schnell, denn sonst wird es auch teurer" :D

Ob du mehr Performance für mehr Geld oder weniger Performance für weniger Geld bekommst, ist doch egal. Eigentlich sind CPU-Preise in gewisser Weise Schall und Rauch. Ein 5950X braucht so wenig Silizium, dass er sicherlich auch für unter 300$ noch gewinnbringend verkauft werden könnte. Wie viel AMD letztlich verlangen wird, hängt von Preis und Performance von Alder Lake ab.

[|MatMan|]

Ich übersetze das mal in: "Hoffentlich wird Zen 4 nicht zu schnell, denn sonst wird es auch teurer" :D
Das sehe ich gar nicht so. Wenn der Preis mit der Performance steigt, finde ich das ziemlich uninteressant. P/L muss auch steigen, und das nicht nur "auf dem Papier", sondern spürbar. Klar, solange man durch die Fertigung limitiert ist, wird das nicht der Fall sein, aber das bleibt ja hoffentlich nicht ewig so. Was soll denn dagegen sprechen, wenn ein 16-Kerner ohne Cache billiger ist als der 12-Kerner mit Cache? Für beide gibt es Anwendungsfälle.

Für die 16-Kerner ist ADL eh keine Konkurrenz, das hat also nix mit Intel zu tun.

Ach und neben Perf/$ erhoffe ich mir von Zen4 auch deutliche Perf/W Steigerung, vor allem im Teillastbereich. Ich habe sowohl von Zen2 als auch Zen3 einen 16-Kerner und beide finde ich bei wenig CPU Last ziemlich enttäuschend. Selbst bei nur 10-15% Auslastung lassen die schon ~100W durch. Komplett idle ist super, Volllast auch, aber dazwischen waren Zen1 und Zen1+ deutlich effizienter.

[HOT]

Mit Cache werden die 12-16C sehr teuer, das seh ich auch so.

[r3ptil3]

Mit Cache werden die 12-16C sehr teuer, das seh ich auch so.

Ich sehe schon eine Art AMD FX Revival Anno 2003, wobei das dann keine 800 Euro mehr sind, sondern das Doppelte.

[Zossel]

Ich tu das mal in diesen Thread: https://www.phoronix.com/scan.php?page=news_item&px=AMD-Kernel-Engineers-June-2021

Bemerkenswert finde ich die Stellen bzgl. Networking und Scheduler.

[CrazyIvan]

Ich tu das mal in diesen Thread: https://www.phoronix.com/scan.php?page=news_item&px=AMD-Kernel-Engineers-June-2021

Bemerkenswert finde ich die Stellen bzgl. Networking und Scheduler.
Sehr schön.

[basix]

Scheduler ist halt wichtig aifgrund der CCDs. Und dann noch mehr bei Zen 5 ;)

[Zossel]

Scheduler ist halt wichtig aifgrund der CCDs. Und dann noch mehr bei Zen 5 ;)

Ich tippe und hoffe auf etwas mehr Phantasie bei möglichen Big/Little Konzepten und möglichen heterogenen Cores.

[Nightspider]

ssds im 5.0 standard wird es noch lange nicht im gaming pc geben. das dauert noch weitere 4-5 jahre.

Samsung kündigt enterprise SSD mit 5.0 für das 2. Quartal 22 an:

https://www.computerbase.de/2021-07/pm1743-samsung-plant-erste-pcie-gen5-ssd-fuer-q2-2022/

Wird nicht lange dauern bis es auch 5.0 M.2 SSDs gibt.

[w0mbat]

Ende 2022/Anfang 2023 dann ne "990 Pro"?

[Unicous]

Silicon Motion sampled "Consumer" Controller in der zweiten Jahreshälfte 2022, Endprodukte werden 2023 erwartet. SM ist afaik Marktführer, von daher würde ich mal schätzen, dass es 2022 kaum PCIe 5.0 fähige SSDs auf dem Markt geben wird.

[Leonidas]

AMDs Zen 4 kommt im Desktop mit maximal 16 CPU-Kernen, aber höherer TDP
https://www.3dcenter.org/news/geruechtekueche-amds-zen-4-kommt-im-desktop-mit-maximal-16-cpu-kernen-aber-hoeherer-tdp

[fondness]

AMDs Zen 4 kommt im Desktop mit maximal 16 CPU-Kernen, aber höherer TDP
https://www.3dcenter.org/news/geruechtekueche-amds-zen-4-kommt-im-desktop-mit-maximal-16-cpu-kernen-aber-hoeherer-tdp

AMD "erlaubt" also ein bisschen mehr Mutli-Therading-Leistung. Da der 16 Kerne und der 8 Kerne aktuell dieselbe TDP haben, wurde da natürlich bisher massiv Leistung liegen gelassen mangels Konkurrenz. Ist wohl einfach billiger wie ein dritten Chiplet.

[Brillus]

AMD "erlaubt" also ein bisschen mehr Mutli-Therading-Leistung. Da der 16 Kerne und der 8 Kerne aktuell dieselbe TDP haben, wurde da natürlich bisher massiv Leistung liegen gelassen mangels Konkurrenz. Ist wohl einfach billiger wie ein dritten Chiplet.

Die Frage ist auch würde 3. Chiplett ohne mehr TPD was bringen.

[HOT]

AMDs Zen 4 kommt im Desktop mit maximal 16 CPU-Kernen, aber höherer TDP
https://www.3dcenter.org/news/geruechtekueche-amds-zen-4-kommt-im-desktop-mit-maximal-16-cpu-kernen-aber-hoeherer-tdp
Das IOD wird 3 Ports haben, daher die Gerüchte mit 24 Cores. Dafür wird das Package aber nicht ausgelegt sein, das wird 2 CCD+ein GFX -Die anbinden.

[basix]

Das IOD wird 3 Ports haben, daher die Gerüchte mit 24 Cores. Dafür wird das Package aber nicht ausgelegt sein, das wird 2 CCD+ein GFX -Die anbinden.

Ist auch meine Vermutung. Schliesst aber ein zweites Package ohne iGPU nicht aus, welches allenfalls nachgereicht werden könnte.

[fondness]

Das IOD wird 3 Ports haben, daher die Gerüchte mit 24 Cores. Dafür wird das Package aber nicht ausgelegt sein, das wird 2 CCD+ein GFX -Die anbinden.

GFX ist im I/O-Die integriert.

[HOT]

GFX ist im I/O-Die integriert.
glaub ich keine Sekunde. Das ergibt überhaupt keinen Sinn.

[Locuza]

glaub ich keine Sekunde. Das ergibt überhaupt keinen Sinn.
Es ergibt wesentlich mehr Sinn, als ein dedizierter GFX-Chip.

[basix]

Wenn das gesamte Ryzen Portfolio eine iGPU bekommen soll UND 6/7nm beim IOD verwendet wird: Ja, dann macht es mehr Sinn. mMn ist hier die Hauptfrage, welcher Prozess für das IOD verwendet wird. Ich glaube nämlich nicht, dass man die ganze IP von RDNA2 auf 12LP+ oder so zurückporten würde.

Vorteil von 12LP+ wäre, dass man vermutlich recht viel IP vom bestehende IOD wiederverwenden könnte und natürlich kostengünstiger wäre. 6/7nm beim IOD sehe ich nur, wenn Fokus auf maximale Effizienz und eben iGPU gelegt wird.

Edit:
Man kann das 170W TDP Gerücht auch so verstehen: 3x GMI Ports, max. 24C. Hier lohnt sich die erhöhte TDP dann wirklich. Bis 16C bleibt geht es evtl. auf 120W TDP und zudem mit iGPU, aber letztere ebenfalls als Chiplet inkl. allem Display IO auf einem separaten Package-Design.

[HOT]

Seh ich auch so. Ich bezweifle ebenfalls, dass das IOD in 6/7nm erscheint. Das wird schon 12LP+ sein für die Desktop-Varianten.

[Locuza]

Ich habe keine Zweifel an der Echtheit der geleakten Zen4-Folien.
Der I/O soll letztendlich in 6nm hergestellt werden bei TSMC (die Folien sprachen von 7nm, aber auf Basis der Gerüchteküche und TSMCs Angabe bzgl. der 6nm-Produktionsanteile wird der I/O wahrscheinlich in 6nm hergestellt).
Die 6nm Prozesstechnologie würde aber im Prinzip nichts für die Analog-Technik tun, I/O für USB, PCIe und GMI-PHYs wäre im Prinzip gleich groß.
Das Einzige was mächtig skalieren würde, wäre die digitale Logik in der Mitte vom aktuellen I/O-Die.
Es würde sich ein leeres Umfeld bilden, die iGPU könnte man praktisch "umsonst" integrieren, weil Platz da ist.
Das Ganze fördert natürlich auch die Effizienz, anstatt ständig Signale über das PHY und über das Package zu bringen, läuft das Ganze innerhalb eines Chips ab.

[basix]

Keine Frage ist 6nm die technologisch überlegene Variante. Je nach Preispunkt von 6nm und der Chiplet Integration auf dem Package evtl. nichtmal (gross) teurer. Wenn ich als Kunde wählen dürfte, würde ich auch lieber 6nm nehmen ;)

Edit: Sind die APU DDR4 Phy nicht deutlich kompakter als beim Ryzen IOD?

[Complicated]

Es ergibt wesentlich mehr Sinn, als ein dedizierter GFX-Chip.
glaub ich keine Sekunde. Das ergibt überhaupt keinen Sinn.
Das muss kein entweder/oder sein - ein GPU-Controller mit kleiner iGPU auf jedem CCX könnte gewollt sein und Vorteile bieten bei der Anbindung eines GPU-Chiplet oder mehreren. Möglicherweise auch eine dGPU, wenn vorhanden, mit einbeziehen.

[BavarianRealist]

Ich habe keine Zweifel an der Echtheit der geleakten Zen4-Folien.
Der I/O soll letztendlich in 6nm hergestellt werden bei TSMC (die Folien sprachen von 7nm, aber auf Basis der Gerüchteküche und TSMCs Angabe bzgl. der 6nm-Produktionsanteile wird der I/O wahrscheinlich in 6nm hergestellt).
Die 6nm Prozesstechnologie würde aber im Prinzip nichts für die Analog-Technik tun, I/O für USB, PCIe und GMI-PHYs wäre im Prinzip gleich groß.
Das Einzige was mächtig skalieren würde, wäre die digitale Logik in der Mitte vom aktuellen I/O-Die.
Es würde sich ein leeres Umfeld bilden, die iGPU könnte man praktisch "umsonst" integrieren, weil Platz da ist.
Das Ganze fördert natürlich auch die Effizienz, anstatt ständig Signale über das PHY und über das Package zu bringen, läuft das Ganze innerhalb eines Chips ab.

Genau so sehe ich das auch: für ein "klassisches" I/O-Die dürfte selbst 12nm schon pad-limited sein. Die Verlustleistung dürfte weitgehend reine "Treiberleistung" der Busse sein. Womöglich gibt es schon deshalb bisher nicht mal ein überarbeitetes I/O-Die in 12nm+. Womöglich hat das aktuelle I/O-Die schon so viel ungenutzte Die-Fläche, sodass sogar hier eine iGPU in 12nm+ eine Art Optimierung der Nutzung der Diesize werden könnte, im kommenden I/O-Die sogar noch viel mehr, weil dieses ja noch viel mehr Pins erhalten wird, sodass es alleine von daher größer wird.

Nachdem die bisherige iGPU von Picasso wohl kaum 80sqmm hat und es mit Monet eine 12nm+APU geben soll, könnte eine 8-12CU-iGPU mit um die 100sqmm selbst in 12nm+ möglich sein.

Ein kleinerer Prozess macht meines Erachtens auch nur Sinn, wenn echt richtig viel zusätliche Logik auf das I/O-Die kommt, also ein großer L4-Cache (macht das Sinn?) oder eben eine iGPU.

[y33H@]

Der 5800X holt aus seinen 142W auch nicht so dolle was raus, das sei angemerkt.

[BlacKi]

Es würde sich ein leeres Umfeld bilden, die iGPU könnte man praktisch "umsonst" integrieren, weil Platz da ist.
das mag sein, aber nur wenn man unbedingt eine igpu haben will. ansonsten macht das keinen sinn auf 6nm zu gehen. und ich frage mich warum man unbedingt eine igpu braucht. das einzigste was ich mir vorstellen könnte wäre, das man zukünftig auf alle monolithische dies verzichten will aka renoir usw. dann würde man aber verhältnismäßig große gpus in die desktops bauen die keiner braucht.

[HOT]

Die 6nm sind für ein IOD im Serverbereich sicherlich sinnvoll, aber im Desktop?

[basix]

Max. JIGGAHERTZ!!11elf! :D

[BavarianRealist]

Eine wichtige Überlegung ob Chiplets oder monolithisches Die:

Die Kommunikation zwischen den Dice verbraucht ungleich mehr Einergie, als wenn die Komponenten im selben Die sind. Für Low-Power-Anwendungen wären damit nur Chiplet-Lösungen sinnvoll, die entweder wenig zusätzlich Die-to-Die-Kommunikation haben (d.h. die jeweiligen Chiplets müssen große L3 besitzen) oder dass man damit Komponenten herein holt, die sonst sowieso noch weiter weg wären, also iGPU statt dedizierter GPU.

Insofern geht meines Erachten daher der Weg dahin, dass sich Notebook-APUs und Desktop-Komponenten (CPUs, GPUs aber auch APUs) im grundsätzlichen Aufbau immer mehr unterscheiden dürften: im Inhalt und daher bereits auch mehr und mehr im Sockel bzw. der Plattform. Im Ergebnis kann damit eine iGPU für Desktop dann auch ruhig in 12nm+ erscheinen, womöglich sogar alle APUs oberhalt von 35Watt, also auch die H-Versionen von Notebooks.

Das würde dann bereits andeuten, dass AMD für 12nm+ eine GPU entwickelt, also wohl RDNA2, sodass es dann auch nicht mehr weit ist, auch die Zen3-Kerne in so ein Teil zu integrieren, sodass man neben einem I/O-Die in 12nm+ mit iGPU auch schon fast die monolitische APU (=Monet) hat.

Oder anders: nimmt man von der monolithischen Monet-APU die CPU weg und platziert dafür mehr andere Kontroller drauf, hat man das neue I/O-Die in 12nm+ mit iGPU...

[BavarianRealist]

Die 6nm sind für ein IOD im Serverbereich sicherlich sinnvoll, aber im Desktop?

Was soll hier ein kleinerer Prozess bringen, wp das Ding wieviele Pins hat? 4000 oder sogar noch viel mehr? Auch in 12nm dürfte da schon viel ungenutzte Silizumfläche drin sein.

[Der_Korken]

Irgendwie weiß ich nicht so recht, was ich von 16C und 170W TDP halten soll. Wenn man die TDP so interpretiert wie bisher, dann würde das PPT bei knapp 230W liegen und das für gerade mal 16C trotz 5nm. Oder anders rum: Hätte man Zen 4 in 7nm gebracht, hätte man für den voll ausgefahrenen 16-Kerner vielleicht an die 350W gebraucht (1.5x Effizienz durch 5nm mal so grob eingerechnet) bzw. ein auf 5nm geshrinkter 5950X würde bei gleicher Leistung <100W rauskommen. So viel schneller kann Zen 4 gar nicht, dass es diesen Verbrauch rechtfertigt.

Gut, AMD hat in der Vergangenheit oft sehr unsinnig konfigurierte Chips gebracht, wo der Verbrauch einfach stupide auf das Maximum hochgeschraubt wurde, was eine Plattform irgendwie hergab, um noch das letzte Prozent Leistung rauszuholen (3800X, aber im Prinzip auch der 5800X). Insofern könnte man sagen, dass ein potenzieller 6950X auch mit 140W laufen würde, aber mit 230W schafft man nochmal 300Mhz Baseclock mehr bzw. 400 Punkte mehr im Cinebench. Aber warum sollte man das tun? Hat man Angst vor Intel? Warum dann nicht einfach 24C bringen, wenn man es kann? Mehr TDP bringt in heutigen Spielen sowieso keine Performance, sondern die siehst du nur in schweren MT-Anwendungen, aber genau die würde man mit 24C ja dominieren.

Oder das Modell ändert sich auf AM5 und es gilt TDP = PPT. Dann wären 170W wieder relativ harmlos und nur ein kleiner Schub, um den 16-Kerner etwas mehr vom 12-Kerner abzugrenzen. Wobei ich selbst da immer noch etwas "enttäuscht" von der Effizienz wäre, wenn man trotz 5nm mehr braucht als Zen 3.

[BavarianRealist]

das mag sein, aber nur wenn man unbedingt eine igpu haben will. ansonsten macht das keinen sinn auf 6nm zu gehen. und ich frage mich warum man unbedingt eine igpu braucht. das einzigste was ich mir vorstellen könnte wäre, das man zukünftig auf alle monolithische dies verzichten will aka renoir usw. dann würde man aber verhältnismäßig große gpus in die desktops bauen die keiner braucht.

Ich hatte mich schon stets gefragt, weshalb es bis heute kein neues I/O-Die für Desktop gibt? Das 120sqmm-12nm-Die zu erneuern dürfte doch verhältnismäßig günstig sein. Als Antwort fiele mir nur ein, dass das geplante I/O-Die einfach nicht fertig wurde bzw. keine Vorteile für Vermeer gebracht hätte. Hat es womöglich an USB4 gehakt...?

Trotzdem soll es jetzt einen 570S-Chipsatz geben, der viel weniger Energie verbraucht? Handelt es sich hierbei um das eigentlich für Vermeer geplante neue I/O-Die, das aber nicht rechtzeitig fertig wurde? Wenn das Die als Chipset soviel weniger Energie verbraucht (12nm+ statt 12nm?), warum nimmt man es dann nicht auch als I/O-Chiplet?

Meine Spekulation: nachdem man gesehen hat, dass Rocket-Lake keine Konkurrenz ist, hat man sich bei AMD womölgich dazu entschieden, nicht so weit zu springen, um sich hier noch etwas aufzuheben und die "alten" Matisse-CPUs nicht zu schnell zu entwerten. Dann dürfte das neue I/O-Chiplet womöglich zusammen mit den stacked-3D-Cache erscheinen, um den Sprung zu vergrößern und die neuen CPUs entsprechend teurer vermarkten zu können?

[basix]

@Korken: Gerüchte sprechen von 3 GMI Links --> Wer weiss, 170W nur für 20+ Core Modelle?

@Bavarian:
X570S ist meines Wissens ein X570 mit optimierter Firmware.

[HOT]

Jo da ist gar nix neu. Aber Agesa 1202 verhalten sich meines Wissens nach alle X570 wie X570S. Es gibt kein neues IOD für Desktop, weil es nicht nötig war. Und der Stromverbrauch durch den GMI-Link? Rly? Ich würd sagen, es gibt ein neues IOD in 12nm und ein winziges GFX-Chiplet in 6 und ein dazu passendes Package. Die TDP wird bei AM5 sicherlich völlig neu interpretiert werden könnt ich mir vorstellen. Das ist ja ne komplett neue Plattform. Aber wir werden es ja sehen, da ja schon Rembrandt AM5 werden soll.

[Distroia]

Wir sollten nicht vergessen, dass Zen 4 zum ersten mal seit langer Zeit wieder in einem HPC-Prozess gefertigt wird, was den Sweet-Spot nach oben verschieben dürfte. Da bringt mehr Leistungsaufnahme vielleicht wieder mehr als vorher. Könnte mir weit über 4 Ghz All-Core für 16 Kerne gut vorstellen.

[Lehdro]

Irgendwie weiß ich nicht so recht, was ich von 16C und 170W TDP halten soll.
Ich schon. Man geht wieder auf TDP = PPT und schon erklärt sich das. Oder die TDP die da getwittert wurde, ist eben schon ein interpretiertes PPT, auch möglich.

Früher war es halt:
65W TDP = 88W PPT
95W TDP = 129W PPT
105W TDP = 142W PPT
Jetzt neu:
125W TDP = 170W PPT

Gerade der 3950X und der 5950X wären noch mit 170W PPT im gewissen Maße sinnvoll gewesen, was im Endeffekt tatsächlich ein verdoppelter single CCD Prozessor wäre. Die ersten beiden TDP Stufen sind dann single CCD CPUs, die anderen beiden die dual CCD CPUs, schön abgestuft.

[Locuza]

[...]
Edit: Sind die APU DDR4 Phy nicht deutlich kompakter als beim Ryzen IOD?
Für das PHY-Design für HBM2 zwischen Vega10 (14nm GloFo) und Vega20 (7nm TSMC) habe ich praktisch die gleichen ~11mm² gemessen:
https://pbs.twimg.com/media/Ea-jJs1XQAAXeYW?format=jpg&name=large
https://pbs.twimg.com/media/Ea-3KleWkAAWf-U?format=jpg&name=4096x4096

Beim 12nm I/O-Die lande ich für die ganze PHY-Fläche bei ungefähr 15.71mm², während es beim 7nm Renoir-Chip um die 14.97mm² sind:
https://abload.de/img/io-vs-renoiramkj8.jpg

Die shot Quelle ist wie üblich Fritzchens Fritz/OC_Burner:
https://www.flickr.com/photos/130561288@N04/

Das muss kein entweder/oder sein - ein GPU-Controller mit kleiner iGPU auf jedem CCX könnte gewollt sein und Vorteile bieten bei der Anbindung eines GPU-Chiplet oder mehreren. Möglicherweise auch eine dGPU, wenn vorhanden, mit einbeziehen.
Es muss aus Finanzieller Sicht Sinn ergeben.
Jedes Design braucht Entwicklungsressourcen, Validierung und muss dann extra produziert werden, getestet und gelagert.
Man kann zwar eine Menge wiederverwerten, aber ich sehe da keine Motivation dahinter iGPUs und noch dedizierte GFX-Chiplets zu bauen.


[...]
Nachdem die bisherige iGPU von Picasso wohl kaum 80sqmm hat und es mit Monet eine 12nm+APU geben soll, könnte eine 8-12CU-iGPU mit um die 100sqmm selbst in 12nm+ möglich sein.

Ein kleinerer Prozess macht meines Erachtens auch nur Sinn, wenn echt richtig viel zusätliche Logik auf das I/O-Die kommt, also ein großer L4-Cache (macht das Sinn?) oder eben eine iGPU.
Die Transistordichte bei 12nm LP+ soll um relativ geringe 15% höher ausfallen können, dass würde am Ende den Chip vermutlich doch nennenswert aufblähen, wenn man iGPU + Media Engines + Display Controller und PHYs unterbringen möchte.

Falls Monet wirklich in 12nm LP+ erscheint, wäre das ein interessantes Produkt und wirtschaftlich gesehen müsste es bedeuten, dass 7nm/6nm nach wie vor relativ teuer sind.

Allgemein ist es interessant das zu vergleichen, aber letztendlich hat sich AMD für 6/7nm für das I/O-die bei Raphael entschieden.

-------

L4$ auf dem I/O-Die ergibt aus meiner Sicht keinen Sinn.
Bei Cache-Misses müsste man dann ständig zum I/O-Die, um die L4-Stufe abzufragen, dass verbraucht dann dank Off-Chip Kommunikation schön Strom und dürfte auch nicht latenzarm über das Package umzusetzen sein.
Insgesamt ergibt es Sinn es genauso umzusetzen, wie es AMD bisher macht.
Große lokale Caches bei den CPUs und danach direkt zum I/O-Die und Systemspeicher.


das mag sein, aber nur wenn man unbedingt eine igpu haben will. ansonsten macht das keinen sinn auf 6nm zu gehen. und ich frage mich warum man unbedingt eine igpu braucht. das einzigste was ich mir vorstellen könnte wäre, das man zukünftig auf alle monolithische dies verzichten will aka renoir usw. dann würde man aber verhältnismäßig große gpus in die desktops bauen die keiner braucht.
Die Frage wurde bei einem AMA Intel gestellt, wieso gibt es nur 8-Kerne und eine iGPU?
Hätte man nicht lieber die iGPU entfernen können und 10-Kerne verbauen?
Laut Intel ist es im Businessbereich nahezu Pflicht eine iGPU zu haben, selbst bei Desktop-Produkten.

Die Motivation für 6nm ist wahrscheinlich die bessere Energieeffizienz die sich zumindest für die digitale Logik ergeben würde und die Möglichkeit eine iGPU Flächengünstig zu integrieren, um mehrere Marktsegmente ansprechen zu können.


Ich hatte mich schon stets gefragt, weshalb es bis heute kein neues I/O-Die für Desktop gibt? Das 120sqmm-12nm-Die zu erneuern dürfte doch verhältnismäßig günstig sein. Als Antwort fiele mir nur ein, dass das geplante I/O-Die einfach nicht fertig wurde bzw. keine Vorteile für Vermeer gebracht hätte. Hat es womöglich an USB4 gehakt...?

Trotzdem soll es jetzt einen 570S-Chipsatz geben, der viel weniger Energie verbraucht? Handelt es sich hierbei um das eigentlich für Vermeer geplante neue I/O-Die, das aber nicht rechtzeitig fertig wurde? Wenn das Die als Chipset soviel weniger Energie verbraucht (12nm+ statt 12nm?), warum nimmt man es dann nicht auch als I/O-Chiplet?

Meine Spekulation: nachdem man gesehen hat, dass Rocket-Lake keine Konkurrenz ist, hat man sich bei AMD womölgich dazu entschieden, nicht so weit zu springen, um sich hier noch etwas aufzuheben und die "alten" Matisse-CPUs nicht zu schnell zu entwerten. Dann dürfte das neue I/O-Chiplet womöglich zusammen mit den stacked-3D-Cache erscheinen, um den Sprung zu vergrößern und die neuen CPUs entsprechend teurer vermarkten zu können?
Ich denke es ist immer eine Kosten/Nutzen-Frage, die aus Konsumentensicht immer etwas zu optimistisch eingeschätzt wird, für Refreshes oder Verbesserungen.

Letztendlich war es ja nicht wirklich notwendig einen neuen I/O-Die bis jetzt zu bauen.
Und USB4 soll bei Raphael nach wie vor nicht inkludiert sein.

Wie andere schon angemerkt haben, ist der 570S-Chipsatz der gleiche Chip, es sollten nur Firmware-Optimierungen enthalten sein, die das Strommanagement verbessern und den Verbrauch senken.

Ich bin mir jetzt gar nicht sicher, ob bei Vermeer nicht auch Optimierungen beim I/O-Die vorgenommen wurden, nicht physische, aber was die Softwareregulierung davon angeht.

_______

AMD ist ja nach wie vor kein Ressourcen-Monster.
Die haben für ihre Klasse aber sehr viele Projekte am laufen.
Für Milan gab es dann doch Änderungen am Server-IOD, für Trento soll es dann auch nochmal einen speziellen IOD geben, danach kommt Genoa.
Für AM5 braucht es ein neues client IOD.
Daneben hatte man all die Jahre die custom Deals für Konsolen, eine Zusammenarbeit mit Samsung für RDNA2-Anpassung.

Und die Leute die für die physische Designimplementierungen zuständig sind und Chipvalidierung betreiben, gibt es nicht endlos viele.

[Nightspider]

Raphael kommt auch für Notebooks.

Wenn das kein großes Argument für 6nm IOD mit RDNA2 ist dann weiß ich auch nicht.

[basix]

Und USB4 soll bei Raphael nach wie vor nicht inkludiert sein.

Ist das wirklich so? Wäre extrem schade. Bei den APUs scheint es ja dabei zu sein?

Raphael kommt auch für Notebooks.

Wenn das kein großes Argument für 6nm IOD mit RDNA2 ist dann weiß ich auch nicht.

170W @ Notebook? :D Oder was stellst du dir da vor? >8C + dGPU und im Idle/Desktop die iGPU? AMD hat doch da ihre Zero Core Power oder wie das heisst bei den GPUs (gab da doch noch was zusätzliches, wenn man zwei GPUs im Crossfire betrieben hatte)

[Nightspider]

Dank 5nm wird so oder so mehr Leistung pro Watt herauskommen als bei Zen3.

Mit V-Cache könnte man zudem noch "brutalere" Raphael Varianten auf den Laptopmarkt loslassen.

Und für die CPU lastigen Anwendungen reicht oft schon eine IGP. Dann darf die CPU auch mehr schlucken.

Wir reden hier natürlich nicht von Ultrabooks.

[basix]

Klar, 35+W und aufwärts. Wäre eigentlich gar nicht schlecht, denn dann kann man die APU bei 8C belassen. Intel wird ja bei Alder Lake mit 8+8C kommen. Da ein 16C Zen 4 dagegenzuhalten wäre schon nicht so unklug. Zusammen mit einer RDNA3 Karte als Kombo gäbe das was ganz schönes ;)

Edit:
USB4 wäre da mMn aber dann auch für das IOD Pflicht.

[Der_Korken]

Ich schon. Man geht wieder auf TDP = PPT und schon erklärt sich das. Oder die TDP die da getwittert wurde, ist eben schon ein interpretiertes PPT, auch möglich.

Es sind schon jeweils die TDP-Werte:

https://twitter.com/patrickschur_/status/1415254514677043205?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1415254 514677043205%7Ctwgr%5E%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Fwww.computerbase.de%2F2021-07%2Famd-cpu-geruechte-raphael-bleibt-bei-16-kernen-aber-bekommt-170-watt%2F

The exact TDP numbers for Raphael are 65, 95, 105, 120 and 170 W.

Da hier die alten TDP-Stufen und nicht die PPT-Stufen aufgelistet sind, sieht es für mich erstmal so aus, als wäre das kein 20%-Sprung von 142 auf 170W, sondern von 105 auf 170W, plus die ~35%, die das PPT dann bisher über der TDP lag.

Wir sollten nicht vergessen, dass Zen 4 zum ersten mal seit langer Zeit wieder in einem HPC-Prozess gefertigt wird, was den Sweet-Spot nach oben verschieben dürfte. Da bringt mehr Leistungsaufnahme vielleicht wieder mehr als vorher. Könnte mir weit über 4 Ghz All-Core für 16 Kerne gut vorstellen.

Die Frage ist nur, ob man einen höheren Sweet-Spot überhaupt will. Die Gamer sind eigentlich die einzigen, die da wirklich von profitieren. Notebook- und Server-Modelle können gar nicht effizienz genug sein. Jahrelang haben sich die AMD-ler über die Intel Schluckspechte lustig gemacht, aber wenn ein 16C-Zen 4 wirklich über 200W ziehen sollte, dann erscheint ein Alder Lake mit 8+8 Kernen und 125W TDP plötzlich ziemlich effizient (selbst wenn er insgesamt etwas langsamer wird). Und Apple hat mit dem M1 sowieso schon gezeigt wie die Reise hingeht bzw. hingehen sollte. Ich persönlich bin vom Teillast-Verbrauch meines 5900X fast schon enttäuscht. Der hat bei ST-Last schon gerne 60W Package Power, also viermal so viel wie eine 15W-APU mit 8C unter Volllast zieht.

[Nightspider]

Theoretisch:

Wenn es ein 6nm IO Die wird mit 3 Ports und man dort noch einen kleinen RDNA3 Chiplet heranhängen könnte und AMD es schafft so eine 5nm Kombination noch Jahresende 2022 auf die Straße zu bringen hätte Intel nix mehr zu lachen.

Und NV würde auch blöd dreinschauen weil man so schnell keine 5nm Laptop-Lösungen aufbieten könnte.

Das wäre ein brutales AMD Ökosystem. Aber irgendwie glaube ich immer noch nicht daran das man ein RDNA3 Chiplet so einfach an das Zen4 IOD hängen kann/wird.

Ich bleibe da eher konservativer bei meiner Erwartungshaltung. Mit V-Cache und Zen4 hat AMD eh schon zwei gefährliche Waffen in der Pipeline.

[basix]

An ein RDNA3 Chiplet glaube ich auch nicht. Passt von der Timeline irgendwie nicht. iGPU wird mMn definitiv RDNA2. Für mehr Power oder Raytracing Leistung gibt es dGPU.

[BavarianRealist]

@Locuzza: Danke für die Bilder, die zeigen, dass man bei den Controllern keine Flächen-Vorteile mehr aus einem Shrink zu ziehen scheint.

@I/O und Kosten:
Nach dem was ich so gelesen habe, soll ein 12nm-Wafer so bei 3.500€ liegen, ein 7nm/6nm-Wafer aber bei 9.500$ (mit zustätzliche steigender Tendenz, weil TSMC hier die Preise sogar erhöhen will).

@Effizienz:
Soweit ich das verstanden habe, sind kleinere Prozesse bei den aktiven Vorgängen effizienter (kleinere Strecken, geringere Kapazitäten), haben aber höhere Leckströme, weil alles näher beieinander. Für aktive Cores, die ständig gefordert werden (CPU-, GPU-Cores) machen kleinere Prozesse also immer Sinn. Aber für alles Andere würde eher das Gegenteil gelten. Sobald auch die Cores nur selten oder wenig gefordert werden, würde ein kleinerer Prozess die Effizienz dann eher verschlechtern.

@Monet in 12nm+:
Für ultra-low-Power-APUs, die wenig gefordert sind und häufig im Idle sind, verwendet AMD bisher schon ältere Prozesse: hier kommt es neben niedrigen Kosten auch auf niedrige idle-Power (=niedrige Leckströme) an, sodass dann Monet in 12nm+ Sinn ergäbe.

Und wenn ich all das zusammen nehme, was ich heute hier gelesen habe, bezweifle ich sehr stark, dass es ein I/O-Chiplet in 6nm/7nm geben dürfte, es sei denn für geringe Stückzahlen, wo es eher darauf ankommt, dieses aus einem bestehenden Design (z.B. Rembrandt) ohne großen Design-Aufwand schnell und einfach zu erhalten, ohne auf dessen Herstellungkosten achten zu müssen.

[maximus_hertus]

Könnte es nicht einfach sein, dass sich AMD die AM5 Plattform nach oben offen hält und daher die 120W bzw. 170W Spezifikation erstellt hat?

Sprich, der Tweet müsste dann lauten: The exact TDP numbers for AM5 are 65, 95, 105, 120 and 170 W.

Welche Raphael Modelle kommen und welche TDP sie haben, wird wohl nichtmal AMD heute wissen. Sie wollen wohl nur vorbereitet sein (für alle Eventualitäten).

Ist Zen 5 auch AM5? Falls ja, ist es doppelt sinnvoll sich Optionen offen zu halten.

[Locuza]

Ist das wirklich so? Wäre extrem schade. Bei den APUs scheint es ja dabei zu sein?
[...]
Laut den geleakten Folien ja, was auch nicht völlig überraschend ist, denn USB4 mit 40Gbps (5GB/s) benötigt ein relativ großes Controller- und PHY-Design.
Zur Orientierung kann man sich die benötigte Fläche bei Tiger Lake anschauen, welcher Thunderbolt4 verbaut mit 40Gbps pro Port, wovon es insgesamt 4 Stück gibt:
https://pbs.twimg.com/media/EfpZwjcWsAA1Y6G?format=jpg&name=large

Rembrandt soll laut Patrick Schur zwei 40Gbps Ports für USB4 verwenden:
https://twitter.com/patrickschur_/status/1308484619097042945

[...]

@I/O und Kosten:
Nach dem was ich so gelesen habe, soll ein 12nm-Wafer so bei 3.500€ liegen, ein 7nm/6nm-Wafer aber bei 9.500$ (mit zustätzliche steigender Tendenz, weil TSMC hier die Preise sogar erhöhen will).

@Effizienz:
Soweit ich das verstanden habe, sind kleinere Prozesse bei den aktiven Vorgängen effizienter (kleinere Strecken, geringere Kapazitäten), haben aber höhere Leckströme, weil alles näher beieinander. Für aktive Cores, die ständig gefordert werden (CPU-, GPU-Cores) machen kleinere Prozesse also immer Sinn. Aber für alles Andere würde eher das Gegenteil gelten. Sobald auch die Cores nur selten oder wenig gefordert werden, würde ein kleinerer Prozess die Effizienz dann eher verschlechtern.

@Monet in 12nm+:
Für ultra-low-Power-APUs, die wenig gefordert sind und häufig im Idle sind, verwendet AMD bisher schon ältere Prozesse: hier kommt es neben niedrigen Kosten auch auf niedrige idle-Power (=niedrige Leckströme) an, sodass dann Monet in 12nm+ Sinn ergäbe.

Und wenn ich all das zusammen nehme, was ich heute hier gelesen habe, bezweifle ich sehr stark, dass es ein I/O-Chiplet in 6nm/7nm geben dürfte, es sei denn für geringe Stückzahlen, wo es eher darauf ankommt, dieses aus einem bestehenden Design (z.B. Rembrandt) ohne großen Design-Aufwand schnell und einfach zu erhalten, ohne auf dessen Herstellungkosten achten zu müssen.
https://twitter.com/chiakokhua/status/1306437988801486848

Die Frage ist wie sehr man dem Report glauben schenken kann, es fliegen auch andere Zahlen herum, die auch häufiger mal nach oben oder nach unten korrigiert worden sind.

Es ist entsprechend schwer abzuschätzen, wie das aussieht.
Wir reden hypothetisch dann auch über einen Vergleich von 12nm LP+ bei GloFo vs. 6nm TSMC in H2 2022.


@ Effizienz:

Es gibt viele Möglichkeiten, um mit Leakage und der Current-Density umzugehen.
Würden die Designer das nicht jede Generation elegant lösen, müssten wir ja schon seit Generationen eigentlich einen immer größeren Idle-Verbrauch haben, wegen immer größerem Static-Leakage.
Dies ist soweit ich sehe nicht der Fall.

@ Monet in 12nm+:

Was bei Monet relativ überraschend ist, ist der Aufwand den man dafür betreiben würde.
Die 12nm LP+ Waferkosten müssen deutlich geringer sein, als 6/7nm, auch in ein paar Jahren, wenn das vom Band laufen soll und das Marktvolumen muss natürlich entsprechend groß sein, um davon nennenswert zu profitieren.
Denn die Entwicklungskosten stehen dem Ganzen gegenüber.
AMD muss Leute abstellen, welche die Zen3 und RDNA2 IP praktisch neu designen und in 12nm LP+ implementieren, mit völlig anderen Designrules und Prozesseigenschaften.
Wenn es so kommt, wären die Entscheidungsgründe und Resultate interessant zu begutachten.

Sunny Cove in 14nm bei Rocket Lake war schon eine sehr Interessante Sache im Vergleich zu den 10nm Sunny Cove-Kernen in Ice Lake.

[amdfanuwe]

Welche Raphael Modelle kommen und welche TDP sie haben, wird wohl nichtmal AMD heute wissen. Sie wollen wohl nur vorbereitet sein (für alle Eventualitäten).
Das wissen die schon ziemlich genau. Die ersten Testchips dürften schon im Labor werkeln. Zumindest die 5nm Spezifikationen sind bekannt und dann können sie sich ausrechnen, wieviel ihr Design schluckt.

5nm bietet 2 Optionen: Gleicher Takt bei weniger Verbrauch oder mehr Takt bei gleichem Verbrauch gegenüber 7nm.
AMD wird wohl auf mehr Takt gehen bei gleichem Verbrauch.
Aktuell:
5800 8x3,8GHz
5900 12x3,7GHz
5950 16x3,4GHz

Mit 170W könnte es auch einen ~16x3,7GHz geben, geht halt bei AM4 wegen Begrenzung auf 105W nicht.

Von der GPU weiß man auch noch nichts. Das können 3CU im I/O sein, die kaum Leistung benötigen wie bisher vermutet.
Ebensogut könnte AMD auch eine mGPU inklusive eigenem Speicher mit 80W bei den 6 und 8 Kernern mit auf das Package packen.
Wär was für Mobile und e-Sports.

Jedenfalls wird keiner gezwungen die 170W auch auszunutzen.
Der 3700x 65W war ja auch beliebter als der 3800X 105W.

[Linmoum]

Das wissen die schon ziemlich genau. Die ersten Testchips dürften schon im Labor werkeln. Zumindest die 5nm Spezifikationen sind bekannt und dann können sie sich ausrechnen, wieviel ihr Design schluckt.Das ist doch aber nicht wirklich die Frage. Nvidia hätte die 3090 theoretisch auch mit 450W default launchen können. Haben sie aber nicht.

Was möglich ist, ist im Prinzip ziemlich egal. Relevant ist einzig, was am Ende als Produkt vom Hersteller auf den Markt geworfen wird. Da es den Zwischenschritt mit Zen3 und V-Cache geben wird, dürfte Zen4 noch auf sich warten lassen. Und jetzt schon zu wissen, was am Ende für TDP-Klassen launchen werden, ist schlicht nicht möglich. Das wird sich selbst AMD bis zuletzt offenhalten.

Das mit AM5 aber mehr möglich sein wird als mit AM4, dürfte offensichtlich sein. Ich gehe fest davon aus, dass 16C auf AM5 auch nicht das Maximum sein werden. Alleine deswegen wird man schon mehr Spielraum nach oben wollen.

[amdfanuwe]

@ Monet in 12nm+:

Seh ich nicht so kritisch. Die Konsolendesigns sind durch, da hat man nun wieder Manpower frei.
Die Logikdesigns ZEN3 und RDNA2 existieren und die Portierung wird vorwiegend von der Software erledigt. Da es bei dem Chip nicht auf optimale Performance oder Flächenbedarf ankommt, dürfte sich der Aufwand in Grenzen halten.
Bei 4 Core und ein paar CUs dürfte der Chip vorwiegend aus I/O bestehen, lohnt nicht in einem kleinerem Prozess.
Dann hat AMD noch die Abnahmeverpflichtung bei GloFo.
Über die Abnahmemenge mach ich mir auch keine Sorgen. Eine Preissache und für Embedded, POS Terminals, Chromebooks dürfte der Chip schon reichen.
Was steckt eigentlich in den Fahrkartenautomaten an jeder Straßenbahnhaltestelle oder Bahnhöfen, in den Geldautomaten, den Kassensystemen im Einzelhandel, den Geldspielautomaten, Infoterminals und den vielen anderen Geräten die man so achtlos benutzt?
Immer mehr Geräte nutzen einen Touchscreen als Benutzerinterface und spielen Werbung in den Pausen ab. Da reicht kein kleiner 8Bit Microcontroller mehr.

[amdfanuwe]

Und jetzt schon zu wissen, was am Ende für TDP-Klassen launchen werden, ist schlicht nicht möglich.
Blödsinn

[LasterCluster]

ExecutableFix:

That 170W isn't a normal TDP value. 120W is the max for the normal

170W TDP seems to only be for a special variant, not the normal CPUs for sure

Wenn Intel mehr Threads liefert, muss AMD zumindest unten mehr bieten. Dann gibt es halt schon 16 oder 14 Kerne als 7900x mit 120 Watt und einen Super selektierten 7950x mit 170 um die 950 Marke warm zu halten. Wird halt ne CPU wie damals der 1800x, die auch niemand wirklich brauchte

[Cyberfries]

Wenn es ein 6nm IO Die wird mit 3 Ports ...

Muss es sein, dass HOTs Märchen von wegen AM5-IOD = 1/4 * SP5-IOD weiter ernstgenommen wird?

In Bezug auf die Konfiguration ist Zen 4 eher langweilig, weiter 2ccd+iod, 4-16 Kerne und keine ungeraden Zahlen.
Bei Zen 5 munkelt man von Big-little auf 3nm, ich denke mal 16-Zen5 Kerne + 16-Zen4 Kerne.
Es sollte reichen mit Zen4 eine Stufe abzusenken (r5 8c, r7 12c), mit 170w als Plan B wenn Raptor Lake schneller wird als gedacht.

Wenn Intel mehr Threads liefert...

Selbst Raptor Lake soll nur 32Threads liefern. Ein Alder Lake i5 mit 6+4c bietet 16Threads, würde zu einem 8c-Zen4-i5 passen.

[fondness]

Viele vergessen auch, dass es bei AMD auch noch Threadripper gibt. AMD kann kein Interesse daran haben, die Mainstream-Plattform noch attraktiver zu machen. Wer mehr Kerne will kann schon heute bis zu 64C/128T haben. Mit Zen 4 dann wohl mindestens 96C/192T. Da ist Intel nicht mal mehr auf die Spielfeld soweit sind sie abgeschlagen. Von daher macht es für AMD wenig Sinn bei Raphael mehr als 16C zu liefern.

[basix]

Threadripper ist eine ganz andere Klientel: Viel CPU, viel Speicher/Bandbreite und viel IO. Da sind ganz andere Anwendungsfälle dahinter.

[Nightspider]

Ich frag mich halt auch wie viel Prozent der AM5 Plattform Besitzer wohl mehr als 16 Kerne kaufen würden.

5%? 10%?

Und dafür muss AMD für die restlichen 90-95% den größeren IOD zahlen? Oder macht der 3. Kanal so wenig extra Die Area aus?

Würde halt auch einschätzen das man diese wenigen Leute mit Threadripper zu versorgen weiß.

5nm wird teuer und die CCDs scheinen etwa gleich groß zu bleiben. Eine CPU mit 3 CCDs würde auf jeden Fall >1000 Euro kosten.
So viel Interessenten kann es dafür ja kaum geben.

[ChaosTM]

Die typischen "ich muss unbedingt das beste haben oder gar nichts"
3% vielleicht ?

[rentex]

Ja, es wären wenige.

[BavarianRealist]

Ich frag mich halt auch wie viel Prozent der AM5 Plattform Besitzer wohl mehr als 16 Kerne kaufen würden.

5%? 10%?

Und dafür muss AMD für die restlichen 90-95% den größeren IOD zahlen? Oder macht der 3. Kanal so wenig extra Die Area aus?




Vermutlich wird man wohl erst mal mit einem IOD beginnen, das eben nur zwei Chiplets zu lässt, vor allem wenn es jetzt heißt, "maximal 16 Cores".
Aufgrund der aktuellen Wafer-Knappheit kann man sich vermutlich auch bei AMD aktuell keine unnötig großen Dice leisten und konzentriert sich so womöglich auf die in der Abwägung sinnvollere Option.

Wenn wirklich ein Bedarf für 3 Chiplets später entstünde, könnte man ja ein neues IOD für 3 Chiplets immer noch auflegen.

[Sunrise]

Viele vergessen auch, dass es bei AMD auch noch Threadripper gibt. AMD kann kein Interesse daran haben, die Mainstream-Plattform noch attraktiver zu machen. Wer mehr Kerne will kann schon heute bis zu 64C/128T haben. Mit Zen 4 dann wohl mindestens 96C/192T. Da ist Intel nicht mal mehr auf die Spielfeld soweit sind sie abgeschlagen. Von daher macht es für AMD wenig Sinn bei Raphael mehr als 16C zu liefern.
Hinzu kommt, dass man nicht vergessen darf, es sind aktuell immerhin noch 16 MT-fähige Kerne (32 Threads), die erstmal ausgelastet werden müssen im typischen Consumer-Umfeld. Wenn AMD die IPC stark erhöht bei weiterhin sehr moderater TDP, haben sie den besten Grundstein für Zen5 schon gelegt.

16C war aber für AMD super, denn das hat neue Preisstrukturen ermöglicht, und auch Hardcore-Gamer/-Benutzer angesprochen und der Aufwand war für AMD sehr gering. Wer mehr will (Threadripper/Epyc) muss auch beträchtlich (Plattform) mehr bezahlen, und das können sie aktuell auch verlangen.

Nebenbei hat AMD auch kein Interesse mehr daran, unwirtschaftlich zu arbeiten, deshalb werden sie versuchen, die Margen besonders hoch zu halten oder zu erhöhen. Zusammen mit der begrenzten Kapazität, trotz Chiplets, braucht man eine maximal performante Basis und die wird AMD ziemlich sicher gefunden haben, auch wenn "wieder nur 16 Kerne" natürlich erstmal bei einigen, die sich vor allem an Zahlen hochziehen (und das Hirn schon beim Lesen deaktiviert haben), sicher wieder Diskussionen auslösen werden, die ich mir gerne ersparen würde.

[Leonidas]

Fertigung von "Zen3D" wird vorbereitet, Release angeblich sogar noch 2021:
https://www.3dcenter.org/news/hardware-und-nachrichten-links-des-23-juli-2021

[Linmoum]

Noch mal ein paar Renderbilder von exe, diesmal vom Sockel.

https://twitter.com/ExecuFix/status/1420804718863978496

[NC]

Fertigung von "Zen3D" wird vorbereitet, Release angeblich sogar noch 2021:
https://www.3dcenter.org/news/hardware-und-nachrichten-links-des-23-juli-2021
Ist Zen3D schon eine Abart von Zen 4 ?

[Nightspider]

Nein. Das ist Zen 3 mit zusätzlichem Cache.

[HPVD]

Genoa mit Zen 4: Umfangreiche Details zu AMDs nächster Server-CPU
aus Gigabyte Hack:
https://www.computerbase.de/2021-08/genoa-mit-zen-4-umfangreiche-details-zu-amds-naechster-server-cpu/

[Loeschzwerg]

Verschiedene Größen und Abmessungen zu Sockel SP5:
https://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=76480&stc=1&d=1629191883

Quelle: https://twitter.com/KittyYYuko/status/1427547398121746432

Edit: OK, zu langsam ^^

[Zossel]

https://www.computerbase.de/2021-08/genoa-mit-zen-4-umfangreiche-details-zu-amds-naechster-server-cpu/

Details zu Zen 4 preis: 12 CPU-Dies inklusive AVX-512 werden geboten

[w0mbat]

Dass AVX-512 support kommt war klar, aber hoffentlich nicht in einem Takt.

[davidzo]

https://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=76481&stc=1&d=1629196594
https://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=76482&stc=1&d=1629197182


https://twitter.com/TtLexington/status/1427455179188809733

Das sieht sehr nach denselben mountingholes wie bie AM4 aus.

Nur merkwürdig dass man weiter diese Kunststoffbrücke mit Nasen verbaut, dabei haben dich selbst die amd boxed heatsinks mittlerweile Schraubenmontage. Könnte man echt mal weglassen ;D
- Die Backplate hält ja auch so, jetzt wo der LGA Rahmen draufgeschraubt ist.


BTW, jetzt mit den zusätzlichen Zeichnungen ergeben auch die Cutouts im IHS Sinn.
- LGA braucht einen gewissen Rand als Auflagefläche für den Rahmen der die CPU im Sockel runterdrückt.
- Dadurch geht Fläche für die MCM DIEs / Chiplets verloren, der Sockel müsste also größer sein als ein PGA, was keinen Sinn macht.
- Um Platz zu schaffen hat AMD also die solid Caps auf der CPU Vorderseite in den Randbereich verlegt und dort Aussparungen im IHS geschaffen.
Der Anpressdruck ist trotzdem gegeben, da an den beiden Kanten noch etwas vom IHS stehen bleibt, damit der Retention frame dort runterdrücken kann. Bei Intel drückt der Frame auch nur an zwei Stellen, das sollte also auch bei AM5 reichen.
- Möglicherweise ist AM5 aufgebaut wie ein Epyc sockel, also ohne Fenster in der Mitte, wie das die Intel Desktop LGA Sockel alle haben. Das macht den Sockel einfacher und erhöht die Pin density, allerdings ist dann auch kein Platz für solid Caps direkt unter dem DIE. Das erklärt möglicherweise die gut bevölkerte Oberseite.
- Obwohl der Sockel und retention Frame ziemlich flach sind, ist das CPU-Package selbst echt fett. Also entweder AMD will weiterhin dicke schwere Kupfer-IHS verbauen, oder man schafft schonmal platz für mehr DIE-Stacking.

[basix]

Zen 4 sagt: Viel Spass bei Delidding :D

[davidzo]

Zen 4 sagt: Viel Spass bei Delidding :D

Jo, mit seitlichem Verschieben wie beiden üblichen Delid-Tools wird das nichts mehr. Aber prinzipiell ist das doch so offen gut zugänglich.

Ich kann mir vorstellen dass man einfach rundherum die kleinen Kupferstege von der Seite aus wegdremelt und dann den "loosen" IHS in der Mitte ablötet. Das hat den Vorteil dass die Auflageflächen für den Retention Frame stehen bleiben. Kann gut sein dass man den Kühlerboden dann aber noch bearbeiten muss damit der nicht nur auf dem retentionframe aufliegt sondern direkt auf dem DIE.
Aber mal ehrlich, Delidding war bei CPUs mit verlötetem IHS noch nie das große Ding. Bringt eh nicht viel solange man keine WLP austauschen kann.

[basix]

Bei AMD CPUs hat es sich ja nicht wirklich gelohnt und wenn jetzt der Aufwand nochmals deutlich steigt (oder einfach auch deutlich heikler bezüglich Zerstörung der CPU ist), wird das wohl eher nicht mehr praktiziert werden.

[Zossel]

Dass AVX-512 support kommt war klar, aber hoffentlich nicht in einem Takt.

Eigentlich hat AMD das Powermanagement und die dazu passenden Takte/Frequenzen zur Zeit ziemlich gut im Griff, und wenn die Bandbreiten zu den Caches passen sollten will ich die Hoffnung nicht aufgeben das es den Takt nicht so heftig runter zieht wie bei Intel.

Das AVX-512 Support kommt war mir nicht klar.

[basix]

War schon lange in den Gerüchtekuchen so am brodeln aber nie ohne etwas mit Hand und Fuss. An Single Cycle AVX-512 glaube ich allerdings nicht. Der Nutzen ist in den allermeisten Anwendungen nicht vorhanden oder man profitiert fast mehr von den zusätzlichen Instruktionen als von der doppelten FPU-Breite.

Mit AVX-512 sinkt bei vielen Anwendungen auch die Perf/W. Hier ein Test von Phoronix: https://www.phoronix.com/scan.php?page=article&item=rocket-lake-avx512&num=1
Nur bei einem CPU-Miner war der AVX-512 Vorteil wirklich vorhanden. Eine wirklich sinnvolle Applikation ist das aber nicht ;)

Bei vielen anderen Benchmarks sind es 0...15% oder gar eine Regression.
Bei y-Cruncher ist es mal wieder mehr: https://www.computerbase.de/2021-07/intel-core-i7-11700k-amd-ryzen-7-5800x-test/2/#diagramm-test-y-cruncher-single
Ebenso bei 3D Particle Movement, 6x Speedup zwischen 10700K und 11700K ist aber eher den Instruktionen zu verdanken als roher Vektor Power: https://www.anandtech.com/show/16495/intel-rocket-lake-14nm-review-11900k-11700k-11600k/7

Dennoch: Für extra FP64 / Vektor Performance gibt es CDNA. Für Code Kompatibilität und Edge Cases gibt es Dual Cycle AVX512. Ansonsten eher verschwendete Chipfläche.

Edit:
Apropos Chipfläche. Das CCD soll 72mm2 gross werden. Das ist ziemlich fett für 5nm. Der doppelte L2$ wird sicher etwas Platz benötigen (5-6mm2). Zen 4 L2$ + L3$ benötigen aber zusammen in N5P gleichviel oder gar etwas weniger Fläche als heute bei Zen 2/3. Ich habe es mal grob überschlagen und komme auf etwa 50mm2 für alles ausser den Cores. (72-50)/8 = 2.75mm2 pro Core. Das ist nur einen Ticken kleiner als Zen 2 in 7nm (2.87mm2, Locuza) und etwa 85% der Grösse eines Zen 3 Cores (3.24mm2, Locuza). Zen 4 wird also deutlich fetter, das ist mal klar. Grössere L1/uop Caches?

[davidzo]

Apropos Chipfläche. Das CCD soll 72mm2 gross werden. Das ist ziemlich fett für 5nm. Der doppelte L2$ wird sicher etwas Platz benötigen (5-6mm2). Zen 4 L2$ + L3$ benötigen aber zusammen in N5P gleichviel oder gar etwas weniger Fläche als heute bei Zen 2/3. Ich habe es mal grob überschlagen und komme auf etwa 50mm2 für alles ausser den Cores. (72-50)/8 = 2.75mm2 pro Core. Das ist nur einen Ticken kleiner als Zen 2 in 7nm (2.87mm2, Locuza) und etwa 85% der Grösse eines Zen 3 Cores (3.24mm2, Locuza). Zen 4 wird also deutlich fetter, das ist mal klar. Grössere L1/uop Caches?

Ist die Frage ob man mit einem größeren L1 etwas gewinnen kann und das nicht einfach nur eine regression der Latenzen bedeutet. Vlt. nur eine kleine Steigerung des L1D Caches auf 48 oder 64kbyte analog zu den Cove Cores?

Was man im Frontend macht, keine Ahnung. decoder von x4 auf x6 vergrößern, µop cache vergrößern, abschaltbare Doppel-decoder wie bei den Mont-Kernen einführen, keine Ahnung was da PPA technisch Sinn macht.

Das erste Bottleneck was mir einfällt sind die 6x dispatch zwischen frontend und execution. Sowohl Frontent mit µop$ als auch das Backend können mehr Instructions per clock.
Was danach auch auf jeden Fall vergleichsweise unterdimensioniert ist, sind Register entries und der Reorder Buffer. Apple und Intel haben viel größere oOo Windows.
Aktuell ist die Architektur in der Int-Execution 10 wide. Man könnte 12 wide gehen mit einer zusätzlichen Alu und Agu, wenn das Frontend das liefern kann. Hieße dann mindestens 8x dispatch und entsprechend mehr integer scheduler, integer register etc.

Load/Store hat man bei Zen3 erst aufgestockt, aber anscheinend ist das auch ne Schraube gewesen die nicht soviel Energie+Diefläche kostet.

Die 6x Table walkers für L2$ misses haben viel gebracht um den riesigen L3 cache erst gut nutzbar zu machen, daher wird es hier eine Steigerung geben analog zum Cachezuwachs.

Floatingpoint Ressourcen werden mit Sicherheit auch aufgestockt, das waren ja auch die ersten Gerüchte zu Zen4, doppelt so breite FPU. Aber das kann leicht viel Diefläche und Power kosten.

[Der_Korken]

Da es auch schon Gerüchte gab, dass Zen 4 bei der nächsten Iteration als Little-Core weiterexistieren soll, hätte ich gar keine so große Verbreiterung erwartet. Große Umbauten eigentlich auch nicht, denn dafür war ja eigentlich Zen 3 da. Bisher waren die Kerne bei AMD relativ klein und sparsam aber trotzdem auf so schnell wie die von Intel. Wenn ich dann lese, dass AMD massiv in die Breite baut, habe ich ein wenig Angst, dass der Verbrauch massiv steigt, also Perf/W kaum besser wird als bei Zen 3 in 7nm. Genoa hat zwar 12 statt 8 Chiplets, allerdings war in dem Leak, der erstmals ein Genoa-Mockup mit 12 Chiplets zeigte, afaik auch von 320-400W TDP die Rede. Also kaum weniger Watt pro Core.

Bezüglich der Caches: Dadurch dass Cache-Stacking bis zum Zen-4-Launch einigermaßen erprobt sein wird, hätte ich erwartet, dass der L3 auf dem Main-Die zurückgebaut wird, um stattdessen standardmäßig zu stacken. Zum Beispiel 16MB auf dem teuren 5nm-Die und dann noch 32MB auf einem 7nm-Cache-Chiplet bzw. 24MB, weil 16MB@5nm etwas kleiner ausfallen als 16MB@7nm. Bei 72mm² kann man aber wohl eher davon ausgehen, dass die 32MB L3 bleiben werden. Mehr macht eigentlich keinen Sinn, weil das latenztechnisch und auch 5nm-kapazitätstechnisch gegenüber Stacking imho die schlechtere Wahl ist und mehr als 80-96MB L3 macht auch keinen Sinn, weil das unglaublich viel Fläche kostet für vermutlich kaum noch Ertrag. Dann schon lieber den Cache höher stacken. Was ich da schon gefragt hab ist, ob man nicht auch zusätzlichen L2 auf ein Cache-Chiplet packen kann. Räumlich gesehen müsste das Chiplet nur etwas in die Breite wachsen und man braucht weitere TSVs zwischen den L2-Blöcken. 2-3MB L2 könnten sicherlich auch reinhauen. Apples M1 hat z.B. 12MB shared L2 mit 4-5ns Latenz. Zen 3 hat zwar nur 2,5-3ns L2-Latenz, dafür aber nur 1/24 der Kapazität (1/6 pro Kern).

Die Größe des L1 ist auch eine spannende Frage. Apple bietet 128kB mit 3 Takten Latenz bei 3,2Ghz. Das wären auch Zen-3-Taktraten hochgerechnet ca. 4,5 Takte. Allerdings müsste AMD für so einen Schritt entweder auf virtually-index-physically-tagged verzichten oder die Assoziativität auch vervierfachen (auf 32-fach!), was wahrscheinlich unglaublich viel Strom kostet. Apple hat das Problem nicht, weil die Pagesize bei ARM 16kB statt 4kB groß ist. Keine Ahnung, ob man das bei x86 so einfach ändern kann.

[davidzo]

Keine Angst, dass AMD bei Zen4 weiter in die Breite geht ist reine Spekulation auch von mir aus.
Es könnte genau so gut sein dass man stattdessen nur den Cache verdoppelt. Wobei das SRAM Scaling zwischen N7 und N5 viel schlechter ist als das logic scaling. Wie du schon sagst wäre Stacking und ein günstigerer prozess für die cache chiplets also vllt. sogar günstiger.
Und man muss sich natürlich auch fragen woher der Power-Increase kommt, wenn nicht durch die Breite. - Taktraten?

Die kosteneffektivste Methode von Stacking ist Wafer on Wafer. Also ein N7 cache Wafer auf einem N5 Logik wafer und erst danach werden die Chips auseinandergeschnitten. Das würde auch noch zu den aktuellen Renderbildern und dem Gigabyte Leak passen, aber sehr wahrscheinlich ist es nicht. Momentan sieht alles nach 12 CCX Chiplets + I/O DIE aus.


Bzgl. L1 page size. x86 definiert nur 4kb und 4mb page sizes und 2mb mit PAE.
Alles andere verbraucht massiv TLB ressourcen.
Ein Wechsel oder eine Ergänzung von x86 auf 8 16 oder 32kb page sizes wäre möglich, aber nur im Datacenter bzw. dort wo man das gaze Software Ökosystem anfassen kann.
Also rechne ich eher mit einem neuen Trick. Einer page size extension wie PAE oder so, die das ganze langsam über das nächste Jahrzehnt verteilt einführt.
Oder AMD oder Intel finden einen Trick wie man die page tables und den TLB clutter effektiver managen kann.
Das ganze wirkt mir aber sehr Aufwändig nur um den L1 zu vergrößern. Stattdessen kann man auch einfach versuchen die Latency zum L2 und L3 zu verbessern, oder die Hitrate durch bessere cache policy erhöhen.

[MiamiNice]

Ich schon. Man geht wieder auf TDP = PPT und schon erklärt sich das. Oder die TDP die da getwittert wurde, ist eben schon ein interpretiertes PPT, auch möglich.

Früher war es halt:
65W TDP = 88W PPT
95W TDP = 129W PPT
105W TDP = 142W PPT
Jetzt neu:
125W TDP = 170W PPT



Da liest man was von 170W auf 16 Kernen bei 5nm und freut sich einen Ast das es endlich voran geht und dann liest man Deinen Post der Stillstand suggeriert ;D

[basix]

Floatingpoint Ressourcen werden mit Sicherheit auch aufgestockt, das waren ja auch die ersten Gerüchte zu Zen4, doppelt so breite FPU. Aber das kann leicht viel Diefläche und Power kosten.

Hmm, würde eine Verdoppelung der AVX2-Einheiten Sinn machen? Dann hat man neben "vollem" AVX-512 Durchsatz auch verdoppelten AVX2 Durchsatz. Davon würde deutlich mehr SW profitieren. Ist dann aber ziemlich Vektor-Heavy das ganze.

Gab es nicht bei Zen 3 das Gerücht, dass FP um +50% schneller werden soll, ohne dass mehr Execution Units dazu kommen? Edit: Mein Gedächtnis trügt nicht (FP IPC Gain ist so aber auch nicht eingetroffen): https://www.techspot.com/news/83347-zen-3-rumored-flaunting-monumental-ipc-gains-early.html

[davidzo]

Man muss nicht gleiche eine Verdopplung der execution ports vornehmen um den Durchsatz zu verbessern.

Zen3 hat z.B. die Dispatchrate von 4 auf 6 erhöht, die floating point register vergrößert, mehr instructions in flight ermöglicht und einzelne instructions die multiple cycles brauchten beschleunigt (Fmac von 5 auf 4 cycles).

+50% sind das nicht, aber gute +20% kamen da im specFP schon bei heraus.

Eventuell könnte man aber auch nur die load/store Breite auf 2x 256bit zu erhöhen, nicht aber die execution ports. Ians zen3 µarch analyse klingt bereits so als wenn Zen3 2x256bit FP loads kann, aber nur 1x 256bit stores.

the peak bandwidth is still only achieved through 2 256b loads coming from the FP/SIMD pipelines. Stores similarly have been doubled in terms of concurrent operations per cycle, but only on the integer side with 2 64b stores, as the FP/SIMD pipes still peak out at 1 256b store per cycle.

https://www.anandtech.com/show/16214/amd-zen-3-ryzen-deep-dive-review-5950x-5900x-5800x-and-5700x-tested/4

[Linmoum]

Da es auch schon Gerüchte gab, dass Zen 4 bei der nächsten Iteration als Little-Core weiterexistieren soll, hätte ich gar keine so große Verbreiterung erwartet. Große Umbauten eigentlich auch nicht, denn dafür war ja eigentlich Zen 3 da. Bisher waren die Kerne bei AMD relativ klein und sparsam aber trotzdem auf so schnell wie die von Intel. Wenn ich dann lese, dass AMD massiv in die Breite baut, habe ich ein wenig Angst, dass der Verbrauch massiv steigt, also Perf/W kaum besser wird als bei Zen 3 in 7nm. Genoa hat zwar 12 statt 8 Chiplets, allerdings war in dem Leak, der erstmals ein Genoa-Mockup mit 12 Chiplets zeigte, afaik auch von 320-400W TDP die Rede. Also kaum weniger Watt pro Core.Wie viel W/Core hat denn aktuell so ein 64C Milan wenn man IO-Power mal ausklammert? Gibt's/gab's da konkrete Messungen für? Ich weiß, AT hatte das mal für Vermeer gemacht, aber da liegt man logischerweise ja sowieso deutlich drüber.

Die max. 400W TDP für Genoa kann man nach dem Gigabyte-Leak als gesichert ansehen, allerdings reden wir hier dann auch von über 120W (!) allein an IO-Power. 12 Speicherkanäle, DDR5 und 128 Lanes PCIe 5.0. Das wird logischerweise ordentlich reinhauen.

Da wären wir dann abzüglich dessen bei ~280W und 96C, das sind ~2,92W/C. Bei fast 100C wäre das schon beachtlich.

[Der_Korken]

Die kosteneffektivste Methode von Stacking ist Wafer on Wafer. Also ein N7 cache Wafer auf einem N5 Logik wafer und erst danach werden die Chips auseinandergeschnitten. Das würde auch noch zu den aktuellen Renderbildern und dem Gigabyte Leak passen, aber sehr wahrscheinlich ist es nicht.


Interessant. Wie realistisch ist es, dass man Teile des Cores auch stackt (also nicht für Zen 4, sondern allgemein)? Zum Beispiel Register-Files, µ-Op-Cache, L1-Caches, etc.? Dadurch würde der Kern in der Fläche schrumpfen, die Wege würden kürzer und man hätte größere SRAM-Blöcke mit gleichbleibend kleiner Latenz bzw. kurzen Leitungen. Übertreiben kann man es natürlich nicht, weil TSVs viel klobiger als Logik sind und natürlich das Wärmeproblem für den unteren Chip bzw. das Stromversorgungsproblem für den oberen Chip bleibt.


Das ganze wirkt mir aber sehr Aufwändig nur um den L1 zu vergrößern. Stattdessen kann man auch einfach versuchen die Latency zum L2 und L3 zu verbessern, oder die Hitrate durch bessere cache policy erhöhen.

Ich habe keine Ahnung wie stark aktuelle Architekturen von mehr L1 profitieren würden. Ich lese mir nur gerne Interviews wie die vor kurzem mit Jim Keller durch und der sagte sinngemäß, dass "predictability" der größte bottleneck wäre bei aktuellen CPUs. Damit kann natürlich auch branch prediction gemeint sein. Beim L2 wird latenzmäßig nichts zu holen sein, sonst hätten Intel/AMD schon längst <12 Takte gebracht. Die L1-Latenz kommt zur L2-Latenz ja immer dazu, d.h. eigentlich sind es "nur" 8 Takte.

Steigt eigentlich die Assoziativität des Caches bei Stacking? AMD verdreifacht ja den L3, aber dadurch geht es nicht mehr mit 16-facher Assoziativität auf. Ist er dann 48-fach? Wenn ja, wäre das theoretisch eine Option für einen größeren L1 (ohne an den Pagesizes was zu ändern).


Eventuell könnte man aber auch nur die load/store Breite auf 2x 256bit zu erhöhen, nicht aber die execution ports. Ians zen3 µarch analyse klingt bereits so als wenn Zen3 2x256bit FP loads kann, aber nur 1x 256bit stores.

Bei so breit angebundenen Caches frage ich mich, ob man dem INT- und dem FP-Block nicht getrennte Data-Caches geben sollte. INT mit 32kB, 4 Takte, 256bit Durchsatz, FP mit 64kB, 5-6 Takte, 512bit Durchsatz. Dadurch hätte man die L1-Größenlimitierung ein wenig umgangen, kann den L1-INT schmal und latenzarm halten, während der L1-FP breit sein kann auf Kosten der Latenz. Es besteht natürlich die Gefahr, dass doppelt gecached wird und dass man synchronisieren muss, aber wie oft greifen INT-ALUs auf Ergebnisse von FP-ALUs zu und umgekehrt?

Wie viel W/Core hat denn aktuell so ein 64C Milan wenn man IO-Power mal ausklammert? Gibt's/gab's da konkrete Messungen für? Ich weiß, AT hatte das mal für Vermeer gemacht, aber da liegt man logischerweise ja sowieso deutlich drüber.


Ich kenne auch nur die Werte von Anandtech. Sind so Pi*Daumen ca. 100W. Der Nachtest mit dem Gigabyte-Board hatte etwas weniger IO-Verbrauch. Allerdings würde sich die Rechnung für Zen 4 verschlechtern, wenn der IO-Verbrauch konstant bleibt und der Mehrverbrauch ausschließlich von den Kernen kommt.

https://www.anandtech.com/show/16778/amd-epyc-milan-review-part-2/3


Da wären wir dann abzüglich dessen bei ~280W und 96C, das sind ~2,92W/C. Bei fast 100C wäre das schon beachtlich.

Milan hat ca. 180W bei 64C (hab jetzt nicht bei AT den Durchschnitt berechnet, nur geschätzt), was ebenfalls unter 3W/Core wäre. Dafür dass Zen 4 aber mal eben den 5nm-Vorteil mit dabei hat, wäre das Perf/W-technisch schon echt mau. 1,5x Perf/W könnte man mit auf 5nm geshrinkte Zen-3-Kerne sicherlich erwarten, das müsste Zen 4 dann erstmal reinholen.

[CrazyIvan]

Sehr interessante Diskussion!
Dazu mein Senf:
Ich tippe auch auf eine Verbreiterung des TLB, um das OoO Window zu vergrößern. Beim Backend sehe ich keinen massiven Bedarf.
Zu Perf/W: Sowohl Zen2 als auch Zen3 sind auf einen Sweet Spot bei 1,5 bis 2w pro Kern designt. Das wird sich dank 96C auch bei Zen4 kaum ändern. Der Core selbst wird an Perf/W zulegen, was aber durch den Interconnect mehrheitlich wieder aufgefressen wird. Daher wird Perf/W bei AMD nur bei den SoCs steigen und bei den Chiplets erst dann wieder signifikant zulegen, wenn man endlich den Interconnect wechselt. Das muss dann hoffentlich bitte mit Zen5 endlich mal passieren (Info-LSI & Co. FTW).

[mboeller]

IDafür dass Zen 4 aber mal eben den 5nm-Vorteil mit dabei hat, wäre das Perf/W-technisch schon echt mau. 1,5x Perf/W könnte man mit auf 5nm geshrinkte Zen-3-Kerne sicherlich erwarten, das müsste Zen 4 dann erstmal reinholen.

laut anandtech sind es aber nur 20% Power oder 15% Performance Unterschied zw. 7nm und 5nm

https://www.anandtech.com/show/12727/tsmc-details-5-nm-process-tech-aggressive-scaling-but-thin-power-and-performance-gains

selbst die 5nm HP Variante wird da nicht viel besser sein.

[Leonidas]

Wo finde ich denn genaue Angaben zur Größe von Core, L2 & L3 sowie CCD bei Zen 2/3 - damit ich nachvollziehbar machen kann, das der Zen-4-Kern wirklich so fett sein muß?

Und ist eine Vergrößerung des L3 aus dem Spiel?

[y33H@]

Matisse / Zen 2 = 74 mm² (CCD) + 125 mm² (IOD)
Vermeer / Zen 3 = 81 mm² (CCD) + 125 mm² (IOD)

https://www.golem.de/news/ryzen-generationen-im-test-wie-amd-die-zenvolution-gelungen-ist-2012-152678.html

[CrazyIvan]

@y33H@
Nice try. Aber da stehen entweder keine Angaben zu Flächen einzelner Bestandteile oder tl;dr

[CrazyIvan]

@Leo
Man glaubt es kaum, aber PCGH hatte da mal was.
https://www.pcgameshardware.de/CPU-CPU-154106/Specials/Ryzen-3000-X570-Die-Shot-Analyse-1342015/amp/

[KarlKastor]

Wo finde ich denn genaue Angaben zur Größe von Core, L2 & L3 sowie CCD bei Zen 2/3 - damit ich nachvollziehbar machen kann, das der Zen-4-Kern wirklich so fett sein muß?

Und ist eine Vergrößerung des L3 aus dem Spiel?
https://mobile.twitter.com/Locuza_/status/1327343660476866560/photo/1

Die Bilder von Locuza helfen wohl am ehesten weiter.

[basix]

Jepp. Hier zu Zen 2: https://www.youtube.com/watch?app=desktop&v=uxepYjo662s

Und sonst sind auch die anderen Videos von Locuza interessant oder die Ausführungen auf seiner Twitter-Seite.

Wo finde ich denn genaue Angaben zur Größe von Core, L2 & L3 sowie CCD bei Zen 2/3 - damit ich nachvollziehbar machen kann, das der Zen-4-Kern wirklich so fett sein muß?
Die Zen 2/3 Werte sind in 7nm. Da muss man das auf N5P extrapolieren:
- Logik = 1.8x
- SRAM = 1.3x
- I/O & Analog = 1.2x

Wikichip liefert jeweils gute Artikel dazu: https://fuse.wikichip.org/news/3398/tsmc-details-5-nm/ sowie https://en.wikichip.org/wiki/5_nm_lithography_process
Manche gehen auch von 1.35x und 1.3x für SRAM und Analog aus: https://semiwiki.com/semiconductor-manufacturers/intel/280519-iedm-2019-tsmc-5nm-process/

Da man SRAM und Logik beim kern nicht trennen kann: Ich nehme jeweils etwas in der Mitte (und die max. Density wird eh selten erreicht). Also ca. 1.5x für den Core, 1.3x für SRAM und 1.2x für IO. Daraus ergibt sich dann ein grobe Schätzung für N5P. Betonung auf grob.


Und ist eine Vergrößerung des L3 aus dem Spiel?
Wurde nirgends erwähnt. Und würde ich auch nicht erwarten. 4MB/Core sind bereits ziemlich viel und für alles andere gibt es V-Cache.

[HOT]

Selbst wenn bei N5 der Cache nur 15% schrumpft (und damit kaum weniger als in N6 benötigt) wird man bei den 32MB bleiben. Man wird mMn einfach wieder ein 64MB-Die in N6 basteln, das kostet ja nicht viel, und das wieder darauf stacken, sodass man für die High-End-CPUs wieder den Cache-Huckepack hat mMn.
Es ist kostentechnisch mit Sicherheit blöder, für alle das separate Cache-Die zu basteln, als die 32MB einfach zu integrieren, das Die ist ja trotzdem winzig.
Also wird man bei den 32MB bleiben für den Mainstream (oder was salvagen) und ab dem 7800X wieder 96MB integrieren.

Also:
7600/7700 -> 32MB L3
7800 -> 96MB L3
7900/7950 -> 192MB L3
Evtl. 7960 -> 288MB L3

Es soll ja 2 IOD geben, eines mMn mit iGFX und eines mMn mit 3 Ports. TR für Zen4 wäre dann ab 32 Kerne zu haben, das passt also sehr gut.

[davidzo]

Zen3 --> Dieshrink auf 5nm (x1.8 / x1.3 / x1.2)

Pro core
Core 3.2mm --> 1.8mm2 (1.8x Scaling)
L2 0.8mm2 --> 0.62mm2 (1.3x Scaling)
L3 4.5mm2 --> 3.5mm2 (1.3xScaling)

Pro Chiplet: ∑ = 81mm2 ∑ = 58,3mm2
8x Cores = 25.6mm2 --> 14,3mm2
8x L2 = 6.4mm2 --> 5mm2
8x L3 = 36mm2 --> 28mm2
1x IFlink 13mm2 --> 11mm2 (1.2x Scaling)

Wie man sieht verschiebt sich die Flächenaufteilung noch weiter in Richtung Cachelastig, da das Scaling hier mit am schlechtesten ist.
Wenn der Cache nicht wächst, sondern stattdessen die Cores die restliche Fläche einnehmen, dann wäre das massiv und würde die Logic Area verdoppeln, von 14.3mm2 auf 27,3mm ausgehend von den 72mm2 Diefläche.

Alternativ denkbar wäre auch dass AMD Density opfert um damit massiv die Taktraten zu erhöhen, analog zu dem was Intel seit Jahren macht, nur in Kombination mit einem Nodeshrink und dadurch keiner massiven TDP Explosion.

Möglich auch dass man den L3 Cache gar nicht mitskaliert damit die in N7 entwickelten Cache Dies von Vermer X3D da noch drauf passen. Es sind ohnehin nur 8mm2 unterschied, das macht den Kohl nicht fett und der größere DIE verbessert unter Umständen das thermische Verhalten und das packaging.

Ich rechne auch fest mit einem Upgrade der IFlinks. Das ist nach wie vor ein Scalingproblem für die Server-CPUs und wird mit mehr CCX nur gravierender. Möglicherweise verwendet AMD bei Zen4 also auch mehr DIE-Area für den Interconnect.

[HOT]

Man wird den Cache einfach akzeptieren. Dann schrumpft der Cache halt nicht und es wird weiterhin Cache-lastiger.
Der Rest wird natürlich entsprechend dichter werden, also in so weit, in dem es HPC-optimiert bleibt natürlich. Man erreicht hier natürlich keine SoC-Packdichten.

Ein neues Cache-Die in N6 kostet quasi nix zu designen, das ist nur Cache. Klar wird man den dann nicht in N7 weiterproduzieren. Das N7-Cache-Die endet mMn mit dem Ende des Vermeer X3D und der endet sobald Raphael X3D verfügbar ist.

Bezüglich der Internas mMn wird man Dinge sehen, die schon Zen3 zugeordnet wurden, die FPU wird einen 3. Strang bekommen, also 50% mehr werden, AVX 512 gibts eh nur in 2 Passes.
Der L1$ wird sicherlich wieder größer werden mMn und der L2$ dann auch. Wieviel sehen wird dann, aber den L1$ aufzurüsten, darum wird man schlichtweg nicht herumkommen, wenn man mehr IPC will. Auch bei den Int-Einheiten wird man etwas aufrüsten mMn, da wird sicherlich 1-2 ALUs mehr geben.

Zen5 hingegen ist wie der Sprung von Skylake auf .cove zu sehen. Auch hier wird AMD Big/Little nutzen, weil die Zen5 einfach riesig werden. Zen1-4 haben die gleiche DNA, Zen5 wird mMn was ganz neues.

[KarlKastor]

Den Cache als extra Die zu stacken wird wohl damit noch interessanter werden.
Genauso little Kerne mit deutlich weniger L2.
Für MT Performance werden mehr Kerne vorteilhafter sein als ein dicker Cache. Nur für nicht (gut) parallelisierbare Anwendungen wird man das brauchen. big.little vielleicht gar keine so blöde Idee.

[basix]

Wie man sieht verschiebt sich die Flächenaufteilung noch weiter in Richtung Cachelastig, da das Scaling hier mit am schlechtesten ist.
Wenn der Cache nicht wächst, sondern stattdessen die Cores die restliche Fläche einnehmen, dann wäre das massiv und würde die Logic Area verdoppeln, von 14.3mm2 auf 27,3mm ausgehend von den 72mm2 Diefläche.

Du hast den verdoppelten L2$ vergessen ;) Also 14.3 auf 22.3mm2. Wäre aber immer noch +56% ausgehend von Zen 3. Auch wenn das Core Scaling nur bei 1.5x landet (wegen den ganzen L1/uOp Caches) wären es immer noch 17.1 auf 22.3mm2 und somit +30%. Wie man es dreht und wendet, Zen 4 wird deutlich fetter. War prinzipell aber auch bei Zen 2 zu 3 zu sehen (ca. +20% grössere Cores).

[davidzo]

Du hast den verdoppelten L2$ vergessen

Ist das gesichert? Ich dachte das ist ein uraltes gerücht aus 2020 genau wie SMT4, dem man nicht unbedingt glauben schenken muss.

L4 ist auch so ein Gerücht, möglicherweise auf dem IO-Die der Epycs. Der Fokus von AMD soll ja bei Zen4 auf Bandbreite liegen (damit können aber auch die 12 DDR5 channel gemeint sein, das ist immerhin ein großes Upgrade).

[HOT]

Den Cache als extra Die zu stacken wird wohl damit noch interessanter werden.
Genauso little Kerne mit deutlich weniger L2.
Für MT Performance werden mehr Kerne vorteilhafter sein als ein dicker Cache. Nur für nicht (gut) parallelisierbare Anwendungen wird man das brauchen. big.little vielleicht gar keine so blöde Idee.
Bei AMD ist das aber was anderes. Zen4 sind ja keine Atoms. Die haben SMT und werden auf 5GHz takten. Das ist nicht vergleichbar mit den Intels.

davidzo
L4 ist bei 96MB L3 pro CCX uninteressant. Das ist was für Genoa. Erst mal sollte man sicherlich eher davon ausgehen, dass X3D in die 2. Generation geht mit Zen4 und deshalb erst mal ähnlich ausfällt.

[basix]

Gesichert ist der grössere L2$ nicht, das stimmt. Intel, Apple, usw. gehen alle auf grössere L2$. Auch ein Indiz, mehr aber nicht.

Naja, was soll der L4$ bringen? Auf dem IO-Die sehe ich den Vorteil grad nicht im Vergleich zum Aufwand und vor allem, da man den L3$ wenn man will auf bis zu 576MByte vergrössern könnte. Falls es eine iGPU mit "L4$" aka IF$ geben soll, dann bin ich bei dir.

Mehr Bandbreite bekommt man mit DDR5 automatisch, auch im Desktop. Deswegen wird auch die IOD zu CCD Verbindung mehr Bandbreite liefern müssen.

[Der_Korken]

Da liest man was von 170W auf 16 Kernen bei 5nm und freut sich einen Ast das es endlich voran geht und dann liest man Deinen Post der Stillstand suggeriert ;D

Wo ist mehr Verbrauch denn ein Fortschritt? Wer auf ineffiziente, bis zur Kotzgrenze geprügelte Kerne steht, kann doch bereits jetzt das PPT auf >200W hochsetzen.

laut anandtech sind es aber nur 20% Power oder 15% Performance Unterschied zw. 7nm und 5nm

Oha, das war mir gar nicht bewusst. Ich kannte nur die ungefähren Skalierungen bei der Fläche und bin dann davon ausgegangen, dass der Verbrauch in ähnlichem Maße abnimmt. Dann wäre gleicher Verbrauch pro Kern gegenüber Zen 3 wieder OK, da die IPC angeblich um 25% steigen soll (beim Takt wird sich voraussichtlich nicht viel tun). Das wäre gegenüber einem Zen 3 @80% Verbrauch zwar noch kein Fortschritt bei Perf/W, aber man bekommt +25% ST-Performance ohne Perf/W-Regression.


Naja, was soll der L4$ bringen? Auf dem IO-Die sehe ich den Vorteil grad nicht im Vergleich zum Aufwand und vor allem, da man den L3$ wenn man will auf bis zu 576MByte vergrössern könnte. Falls es eine iGPU mit "L4$" aka IF$ geben soll, dann bin ich bei dir.

Vier Cache-Stufen sind ziemlich viel, weil die nacheinander durchsucht werden müssen. Ich könnte mir nur vorstellen, dass man langfristig, also z.B. bei Zen 5 einen großen L3 auf den IO-Die setzt, der von allen CCDs und einer iGPU genutzt werden kann. Dafür lässt man den L3 auf den CCDs weg und bohrt stattdessen den L2 deutlich auf und stackt diesen. Zum Beispiel 2MB L2 pro Kern auf dem Base-Die und nochmal 4 MB pro Kern draufgestackt. Von 6 bis 32MB wäre man natürlich langsamer als Zen 3, dafür von 512kB bis 6MB deutlich schneller (4-5ns vs. 10-11ns) und oberhalb der L3-Größe von Zen 3 natürlich auch. Die L3-Latenzen fallen natürlich deutlich schlechter aus, allerdings muss man hier einberechnen, dass auf den CCDs eine Cache-Stufe weniger durchsucht werden muss (CCD wird ~6ns schneller verlassen) und der Interconnect womöglich wie bei RDNA3 über die Chipbrücke erreicht wird, die vielleicht auch nochmal ein paar ns spart.

[davidzo]

laut anandtech sind es aber nur 20% Power oder 15% Performance Unterschied zw. 7nm und 5nm

Daten von ... warte ... 2018 :freak:

Semiwiki scheibt von 30% weniger Power @ ISO speed: https://semiwiki.com/semiconductor-manufacturers/tsmc/282339-tsmc-unveils-details-of-5nm-cmos-production-technology-platform-featuring-euv-and-high-mobility-channel-finfets-at-iedm2019/

Das deckt sich mit der wikichip Tabelle und alles andere wäre auch eine herbe Enttäuschung für einen fullnode Sprung.
Btw, ab N5 hat TSMC auch COAG (wohl mit ein Faktor für das 1,84x scaling) und Silizium-Germanium für High mobility Channels.

N5P bringt nochmal 15% weniger Power als N5 bei Iso speed. Sind also 41% Power reduction zwischen N7 und N5P. Vom Zeitfenster könnte AMD schon N5P nutzen.

Btw, was einem bei N5 sofort ins Auge springt sind die extremely Low VT Transistoren mit 25% mehr performance @ ISO Voltage.
Dazu die neuen three-fin standard cells für weitere 10% performance.

7 Ghz here we come!


Könnte tatsächlich sein dass hier die ganzen Scalingeffekte bei draufgehen: Einfach fettere High performance Transistoren für die Cores.
Cache Skaliert sowieso nicht so gut und der Rest geht für mehr IF Bandbreite drauf um die 6-7Ghz Cores zu füttern.




Vier Cache-Stufen sind ziemlich viel, weil die nacheinander durchsucht werden müssen. Ich könnte mir nur vorstellen, dass man langfristig, also z.B. bei Zen 5 einen großen L3 auf den IO-Die setzt, der von allen CCDs und einer iGPU genutzt werden kann. Dafür lässt man den L3 auf den CCDs weg und bohrt stattdessen den L2 deutlich auf und stackt diesen.

Macht eher für Epyc Sinn, wo man eh einen riesigen i/o die mit den 12x DDR5 channels hat und viel von der Interonnect Bandbreite profitiert.

L2 vergrößern macht keinen Sinn. Sieht man ja bei Tigerlake. 2,5x soviel Cache wie Icelake für gerade mal 3% IPC Increase.
Schon gar nicht per stacking, da das die assoziativität nicht erhöht und die Latenzen womöglich nach oben treibt. Zudem wären die Cache-DIEs viel zu winzig so dass der Wafer dann zur Hälfte aus scribelines besteht.


Wo ist mehr Verbrauch denn ein Fortschritt? Wer auf ineffiziente, bis zur Kotzgrenze geprügelte Kerne steht, kann doch bereits jetzt das PPT auf >200W hochsetzen.
Bringt bei AMD nicht soviel, da die 5Ghz Wall immer noch da ist (bzw. je nach einzelner corequalität 4.5 - 5,1ghz). Bei Threadripper und Epyc mag das mehr effekt haben als im desktop, aber erstmal Chagall abwarten...

[y33H@]

Nice try. Aber da stehen entweder keine Angaben zu Flächen einzelner Bestandteile oder tl;dr
Leonidas fragte (auch) nach CCD.

[robbitop]

Zumindest bis dato gilt: alles was außerhalb des CCX ist, hat einen recht großen Latency hit weil es über die IF muss. Da kommt man dann schnell in den Bereich, wo sich der Cache nicht mehr lohnt.

Intels Golden Cove scheint, was geleakte Benchmarks angeht ja ordentlich schneller geworden zu sein als seine Vorgänger. IIRC lag man da bei +25-30% vor Zen 3.
Da muss man schon ordentlich drauf legen. Andererseits impliziert die Nennung von Zen 4D als little core, dass Zen 4 richtig fett wird.
Zen 3 wurde was die typischen großen Checkpoints angeht sind ja kaum aufgebohrt (L1/L2 OOO window, decoder breite, backend breite etc). Vor allem wenn man es mit den Veränderungen seit Skylake in den Coves vergleicht. Dafür war der speedup schon ziemlich groß. Da hat das Redesign eben abseits dieser Punkte mehr gebracht als man denken würde. Insbesondere was Hitrate/Reuse angeht.

Andererseits zeigt Cezanne, dass die Performance von Zen 3 auch ein gutes Stück vom L3 abhängt. Cezanne scheint mit seinen 16 MiB L3 ein gutes Stück abgeschlagen von Vermeer zu liegen und eher bei Matisse zu liegen.

Die Frage ist aber dennoch, wann und ob und wie sehr der Zeitpunkt kommt, an dem man wirklich in die Breite gehen muss.
Bei Cove sah es erst so aus als wenn es kaum was bringt - aber ggf. hat man mit Golden Cove ja nun auch andere Flaschenhälse beseitigt so, dass dieser nun auch mehr aus seiner Breite machen kann.

Es bleibt spannend und natürlich ist jede uArch immer eine lokale Optimierung.

Es wird wirklich spannend zu sehen, was AMD mit Zen 4 vorhat bevor man auf big/little mit Zen 5 umschwenkt.


L2 vergrößern macht keinen Sinn. Sieht man ja bei Tigerlake. 2,5x soviel Cache wie Icelake für gerade mal 3% IPC Increase.
Beziehst du dich auf die Ergebnisse von Ian mit SPEC?
Die Frage ist, ob SPEC vom Workload her so sehr von gesteigerter Hitrate profitiert. Leider kann man Tigerlake aktuell in keinem Desktop verbauen und mit einer dGPU kombinieren und mit normierten Frequenzen und Timings bspw in Spielen vergleichen. In der Regel bringt Hitrate da am Meisten.

[Cyberfries]

Sollte nicht allein die Integration von avx512 die Kerne um einiges anwachsen lassen?
Da könnte der Flächengewinn schnell aufgefressen werden.

Könnte natürlich auch ein Mechanismus sein für das Big Core - Little Core Prinzip,
wenn das bei Zen5s little Cores einfach entfallen kann. Eventuell auch eine Option für mobile?
Oder ist die Integration viel zu tiefgehend?
Zu Skylake /x gabs doch dieses schöne Bild: https://mobile.twitter.com/Locuza_/status/1324077339920207873/photo/1

[Brillus]

Sollte nicht allein die Integration von avx512 die Kerne um einiges anwachsen lassen?
Da könnte der Flächengewinn schnell aufgefressen werden.

Könnte natürlich auch ein Mechanismus sein für das Big Core - Little Core Prinzip,
wenn das bei Zen5s little Cores einfach entfallen kann. Eventuell auch eine Option für mobile?
Oder ist die Integration viel zu tiefgehend?
Zu Skylake /x gabs doch dieses schöne Bild: https://mobile.twitter.com/Locuza_/status/1324077339920207873/photo/1

Kommt drauf an ob man nur den Befehlssatz supportet ( und dann die Befehlen in mehreren Durchläufen berechnet) oder auch die Breite erhöht.

[robbitop]

Die Frage ist, ob es unbedingt single cycle sein muss. Es gibt bis dato nicht so viele Anwendungen, bei denen das große Vorteile bringt. Entsprechend könnte man es der Kompatibilität halber implementieren aber zunächst mit dual cycle. Und später, wenn/falls es deutlich mehr Vorteile in der Realworld gibt, kann man es ja single cycle machen.

[Leonidas]

Zen3
L3 4.5mm2

Woher stammt die Angabe? Die zur Größe des L3 von Zen3 fehlt mir bisher noch. Und zum I/O-Part von Zen3.

[KarlKastor]

Bei AMD ist das aber was anderes. Zen4 sind ja keine Atoms. Die haben SMT und werden auf 5GHz takten. Das ist nicht vergleichbar mit den Intels.

Kannst du das genauer ausführen? Ich weiß weder was du mitteilen möchtest noch kann ich erahnen was das mit meinem Post zu tun haben könnte.

[basix]

Woher stammt die Angabe? Die zur Größe des L3 von Zen3 fehlt mir bisher noch. Und zum I/O-Part von Zen3.

Man kann es ausmessen ;) 80.7mm2 für das gesamte CCD
https://wccftech.com/amd-ryzen-5000-zen-3-vermeer-undressed-high-res-die-shots-close-ups-pictured-detailed/

[HPVD]

zu dem AVX-512 Support ist ja eigentlich nicht nur die Fragen,
- ob es in einem Durchlauf abgearbeitet wird oder in mehreren,
- ob/wie stark die Leistungsaufnahme steigt / Frequenz sinkt
sondern auch noch
- welches Subset denn unterstützt wird.

Bei Intel ist das abhängig von der CPU ja sehr unterschiedlich, siehe Tabelle auf:
https://en.wikipedia.org/wiki/AVX-512#CPUs_with_AVX-512

[Screemer]

Könnte man technisch die Vektorberechnungen von avx256/512 auf die GPU der apus auslagern? Prinzipiell sind die ja Vektorrechner mit hoher Leistung.

[HPVD]

Bin grade recht erstaunt, wie oft AVX-512 tatsächlich genutzt wird/werden kann:
https://docs.computecanada.ca/wiki/Modules_avx512

Obs immer nen großer Vorteil ist damit aber natürlich nicht gesagt...

[aufkrawall]

In libdav1d bringt es für 10 Bit video tatsächlich einen gigantischen Unterschied. Allerdings fehlen dem Pfad für AVX2 mitunter ähnliche mögliche Optimierungen, sodass ein 1:1 Vergleich technisch unfair sein kann. Ändert aber natürlich nichts an der praktischen Situation, dass es auf der CPU mit AVX512 viel schneller läuft.
Tesseract bekommt demnächst auch AVX512-Optimierungen. Mal gucken, ob sich das da wiederholt. Ich nutze das tatsächlich (un)regelmäßig und bei einigen hundert Seiten wär ein Performanceboost schon nett.

[davidzo]

Woher stammt die Angabe? Die zur Größe des L3 von Zen3 fehlt mir bisher noch. Und zum I/O-Part von Zen3.
Hatte Locuza ausgemessen: https://mobile.twitter.com/Locuza_/status/1327343660476866560/photo/1

Iopart = uncore / Rest ergibt sich aus der Summe der Cores + Cache und der DIEgröße.



Beziehst du dich auf die Ergebnisse von Ian mit SPEC?
Die Frage ist, ob SPEC vom Workload her so sehr von gesteigerter Hitrate profitiert. Leider kann man Tigerlake aktuell in keinem Desktop verbauen und mit einer dGPU kombinieren und mit normierten Frequenzen und Timings bspw in Spielen vergleichen. In der Regel bringt Hitrate da am Meisten.
Genau die.
Allerdings habe ich auch noch keine anderen Benchmarks gesehen wo die IPC wirklich untersucht wurde. Die ca. 20prozentigen performance Gains lassen sich auch mit den gesteigerten Taktraten erklären. Intel macht uns das zusätzlich schwierig durch die Anhebung der TDP.

[Der_Korken]

L2 vergrößern macht keinen Sinn. Sieht man ja bei Tigerlake. 2,5x soviel Cache wie Icelake für gerade mal 3% IPC Increase.
Schon gar nicht per stacking, da das die assoziativität nicht erhöht und die Latenzen womöglich nach oben treibt. Zudem wären die Cache-DIEs viel zu winzig so dass der Wafer dann zur Hälfte aus scribelines besteht.


Dass Willow Cove nicht sehr stark profitiert hat, ist ein guter Punkt, allerdings hat sich auch die L3-Latenz um 9 Takte verschlechtert, was den L2-Vorteil im Durchschnitt wieder auffressen könnte. Beim Stacking sollten sich die Latenzen gerade nicht erhöhen. Zumindest hat AMD damit geworben und imho ist das auch DAS Killerfeature, um das memory subsystem in Zukunft schneller zu bekommen. 96MB planarer L3 hätte durch seine riesige Fläche vielleicht schon so schlechte Latenzen, dass er im Schnitt (Hitrate vs. Latenz) gar nicht schneller als 32MB wäre.

Die Größe der Cache-Chiplets darf nicht zu klein sein, das stimmt. Ich habe mit meinem gestackten L2 ja nur etwas rumgesponnen. Wobei 8x2MB L2 gar nicht kleiner wären als 1x32MB L3, wenn man sich den Flächenverbrauch auf Vermeer anguckt (man stackt den L2 natürlich nicht einzeln, sondern für alle Kerne zusammen (wodurch die natürlich nebeneinander angeordnet sein müssen)). Und um noch etwas weiterzuspinnen: Wenn man schon einen Stack hat, der den mittleren Teil des CCDs überspannt, könnte man ihn auch verlängern und als Brücke zum IOD verwenden, sodass er auch noch etwas L3 enthält und somit auf jeden Fall groß genug wäre.

zu dem AVX-512 Support ist ja eigentlich nicht nur die Fragen,

[...]

- welches Subset denn unterstützt wird.

Bei Intel ist das abhängig von der CPU ja sehr unterschiedlich

Wenn man es für die Kompatiblität implementiert, ein möglichst großes Subset. Diese vielen Sub-Erweiterungen, die Intel eingeführt und chaotisch supportet bzw. nicht supportet, sind fürchterlich. Wenn es nach Linus Torvalds ginge, würde AVX512 gar nicht kommen ;)

Könnte man technisch die Vektorberechnungen von avx256/512 auf die GPU der apus auslagern? Prinzipiell sind die ja Vektorrechner mit hoher Leistung.

Das stelle ich mir schwierig vor, denn die Instruktionen wandern durch die Pipeline der CPU und es müssen dependencies aufgelöst werden, welche Instruktion wann dran ist und wer auf Daten von wem wartet. Auch die Daten lagen in den L1- und L2-Caches. Die Instruktionen und Daten quer über den Chip an eine iGPU zu schicken, kostet wahrscheinlich mehr Strom als lokal eine Vector-Unit zu nutzen, die nicht ganz so auf Breite spezialisiert ist wie eine GPU.

RDNA hat außerdem Waves mit 32 FP32-Instruktionen, was einer Breite von 1024 bit entspricht. Man müsste also immer zwei volle AVX512-Instruktionen zusammenpacken, damit eine SIMD-Unit überhaupt vollen Durchsatz erreichen kann. Und dann sind die einzelnen Komponenten nicht immer single precision, sondern auch mal double precision, d.h. die GPU bräuchte ALUs mit 1:2 DP.

[davidzo]

2mb l2 pro core wäre eine Vervierfachung. Das halte ich für völlig unrealistisch, denn da gehen die Latenzen und der Verbrauch durch die Decke. Du bräuchtest ja 32fache Assoziativität um den wirklich zu nutzen und einen gigantischen TLB.

Außerdem wären es dann zusammen mit den 512kb im Basedie sogar 2,5Mb.

Nee, bei sinnvollen cachegrößen für den L2 ist ein stacked Die einfach zu klein.
Zudem bezweifle ich das man die Regel dass die Latenz nicht steigt für den stacked L3 einfach so auf den L2 übertragen kann. Schließlich liegt fast eine zehnerpotenz an Latenz dazwischen. AMD wird den Ondie L3 an die Fähigkeiten des off DIE L3s angepasst haben, nicht umgekehrt. Das mag auch eine Erklärung für die merkwürdige Regression bei der L3 Latenz sein (neben den 32mib unified cache statt 2x16) gegenüber Zen2.
Bei so nahen caches wie L2, die so wenig Fläche belegen und nah dran sein müssen, macht es echt mehr Sinn die on DIE zu haben und nicht in einem anderen chip.

Btw, der TLB ist jetzt schon zu klein für den gigantischen L3, Ian hatte da jede Menge merkwürdige TLB Misses gemessen in seiner Zen3 Analyse.
Der wird auf jeden Fall wachsen mit Zen4.


Und was die Willowcove Latenzverschlechterung angeht: Du hast recht, es liegt an den schlechteren Latenzen dass die Performance kaum durchschlägt. Aber das ist nunmal der Tradeoff von größeren L2 Caches. Größer = höhere Latenz. Das wird AMD auch nicht anders machen können, von zen2 zu zen3, also 2x16mb L3 auf 1x32mb waren das eine 7 cycle Regression.
Zumal die Assoziativität ebenfalls steigen muss und ohne Latenzregression geht der Verbrauch definitiv durch die Decke und gff. leidet auch die Taktbarkeit der Cores darunter.

[Der_Korken]

Warum muss die Assoziativität beim L2 immer mit steigen? 8-fach pro 512KB ist ja kein Naturgesetz. Skylake hatte z.B. eine Regression von 8-fach auf 4-fach bei gleichbleibenden 256KB. Und beim L3 hat AMD die Assoziativität auch nicht mit erhöht mit der Größe. Der 2MB große L2 (auf dem Base-Die, die Stacks kommen noch dazu!) macht in meiner Theorie natürlich nur Sinn, wenn der L3 auf den IOD wandert und die L2-Missrate nach unten gedrückt werden muss, um nicht so oft auf den IOD zu müssen. Ob man durch Stacking wirklich so einfach die Größe erhöhen kann ohne dass die Latenz steigt, wird man sehen müssen, aber wenn es geht, wäre es imho reizvoll eine Quasi-L3-Größe mit Quasi-L2-Latenzen zu haben. Vielleicht shared man den L2 dann zwischen zwei oder vier Kernen. So wie ein CCX, nur kleiner und auf L2-Ebene.

[HOT]

Wie gut das mit den 2MB L2 war hat man bei Bully gesehen :freak:. Nein, man wird moderat bleiben um keine Latenz zu verlieren.

[KarlKastor]

@Der_Korken
Warum sollte der L3 auf den IO-Die?
AMD hat doch jetzt gezeigt, wie sie einen riesigen L3 Cache mit guten Latenzen hinbekommen. Warum sollte man da was zum negativen ändern?

[Der_Korken]

Wie gut das mit den 2MB L2 war hat man bei Bully gesehen :freak:. Nein, man wird moderat bleiben um keine Latenz zu verlieren.

Was haben 2MB L2-Cache mit den Fails von Bulldozer zu tun? Natürlich verschlechtert sich die Latenz, aber wenn man es gut macht, hält es sich im Rahmen. Willow Cove hat gerade erst von 512kB auf 1,25MB erhöht und gerade mal einen Takt Latenz verloren.

@Der_Korken
Warum sollte der L3 auf den IO-Die?
AMD hat doch jetzt gezeigt, wie sie einen riesigen L3 Cache mit guten Latenzen hinbekommen. Warum sollte man da was zum negativen ändern?

Weil der L3 vielleicht nicht gebraucht wird, wenn man den L2 "kostenlos" groß genug bekommt. Der L3 auf dem IO-Die wäre dann ein System Level Cache, der auch von einer iGPU mitbenutzt werden könnte. Sowas wurde für Zen 5 mal als Gerücht genannt. Eigentlich gehört das hier gar nicht mehr rein, denn für Zen 4 wird garantiert nichts an der L2/L3-Aufteilung geändert.

[RitterRost]

Weil der L3 vielleicht nicht gebraucht wird, wenn man den L2 "kostenlos" groß genug bekommt. Der L3 auf dem IO-Die wäre dann ein System Level Cache, der auch von einer iGPU mitbenutzt werden könnte. Sowas wurde für Zen 5 mal als Gerücht genannt. Eigentlich gehört das hier gar nicht mehr rein, denn für Zen 4 wird garantiert nichts an der L2/L3-Aufteilung geändert.

Was ist denn dann in dem riesigen IOD vom Server Zen4 drin?

(Sorry, wenn das hier schon beantwortet wurde, aber diese IOD-Größe [über 300mm^2 wenn ich mich recht entsinne] finde ich unglaublich)

[HOT]

Was haben 2MB L2-Cache mit den Fails von Bulldozer zu tun? Natürlich verschlechtert sich die Latenz, aber wenn man es gut macht, hält es sich im Rahmen. Willow Cove hat gerade erst von 512kB auf 1,25MB erhöht und gerade mal einen Takt Latenz verloren.

[...]
Na ein schwer unbalanciertes Cache-System was eben ein Desaster war performancetechnisch. Und das wird es bei Zen4 nicht geben. Man behält den 8C CCD bei und deshalb ist auch klar, dass der L3 im Die bleibt. 1MB L2 ist ausreichend als Upgrade, wie du schon erwähnst ist Intel auch nicht über 1,25MB gegangen. Das macht man natürlich wegen der Latenz, Intel scheint da einfach das Optimum gesucht haben. AMD wird sicherlich auch keine höhere Latenz in Kauf nehmen für 2MB L2.

[KarlKastor]

Sapphire Rapid bekommt ja 2 MB. Da wird man dann sehen, wie die Latenz aussieht.

[basix]

Ist halt mehr auf Throughput / ML ausgelegt und die grossen Caches dämpfen den Bedarf nach DRAM-Bandbreite. Alderlake hat deutlich mehr Bytes/Flop.

[Der_Korken]

Was ist denn dann in dem riesigen IOD vom Server Zen4 drin?

(Sorry, wenn das hier schon beantwortet wurde, aber diese IOD-Größe [über 300mm^2 wenn ich mich recht entsinne] finde ich unglaublich)

Der IOD von Rome/Milan ist sogar 400mm² groß. Ein großer Teil davon sind die ganzen PHYs für 8 DDR4-Channel und 128 PCIe-Lanes. Bei Genoa sollen es ja 12 Channel werden und eventuell PCIe 5.0 statt 4.0. Insofern ist der neue IOD schon ein Fortschritt, der nicht unbedingt zu erwarten war, da die genannten Sachen kaum von kleineren Fertigungsprozessen profitieren und somit nur wenig schrumpfen.

[RitterRost]

Der IOD von Rome/Milan ist sogar 400mm² groß. Ein großer Teil davon sind die ganzen PHYs für 8 DDR4-Channel und 128 PCIe-Lanes. Bei Genoa sollen es ja 12 Channel werden und eventuell PCIe 5.0 statt 4.0. Insofern ist der neue IOD schon ein Fortschritt, der nicht unbedingt zu erwarten war, da die genannten Sachen kaum von kleineren Fertigungsprozessen profitieren und somit nur wenig schrumpfen.

Dass PHYs größer sind, habe ich schon gehört. Aber, dass sie so riesig sind - krass.
Danke für die Info.

[Der_Korken]

Dass PHYs größer sind, habe ich schon gehört. Aber, dass sie so riesig sind - krass.
Danke für die Info.

Hier sieht man es mal visuell: https://www.techpowerup.com/news-tags/EPYC?page=3#g266287-2

Innen drin ist natürlich auch noch Logik und es gibt sicherlich auch Spielraum PHYs kompakter zu designen (die DDR4 PHYs bei Renoir/Cezanne sind deutlich größer als z.B. bei Tiger Lake). Aber ja, die Dinger sind in Summe verdammt groß im Vergleich zu den Kernen, die die eigentliche Arbeit verrichten.

[robbitop]

Genau die.
Allerdings habe ich auch noch keine anderen Benchmarks gesehen wo die IPC wirklich untersucht wurde. Die ca. 20prozentigen performance Gains lassen sich auch mit den gesteigerten Taktraten erklären. Intel macht uns das zusätzlich schwierig durch die Anhebung der TDP.
Deshalb wäre es phantastisch, wenn man TGL auch im Desktop verbauen könnte und takt- und latenznormiert mal nachmessen könnte. Insbesondere mit Spielen.

Die Frage ist, ob man den Wert von Änderungen immer an dem Nutzen in bestimmten uArchs festmachen muss. Ggf. gibt/gab es andere Flaschenhälse, so dass die Änderung noch nicht zur Geltung gekommen ist.
Die Coves hat man sehr viel breiter gemacht ohne viel Nutzen z.B. Nun scheint Golden Cove doch ein gutes Stück schneller zu sein - ggf. weil andere Bottlenecks behoben worden sind.

Was den Cachewachstum bei Intel angeht - meine persönliche Spekulation ist, dass Intel die Cores sukzessive bereit gemacht hat für den Weggang vom Ringbus zu einer skalierbareren und potenziell langsameren Fabric.
Das kann schon mit ADL soweit sein (8+8 Cores) - oder aber danach mit Raptor Lake (8+16 Cores).

edit: ADL wahrscheinlich doch noch Ringbus:
https://www.forum-3dcenter.org/vbulletin/showpost.php?p=12767185&postcount=5955

[HOT]

https://www.techpowerup.com/285771/no-pcie-gen5-for-raphael-says-gigabytes-leaked-socket-am5-documentation

So wird AM5 aussehen. Das heißt natürlich nicht, dass die CPUs auch so aussehen ;).
Aus dem Gigabyte-Leak.

[Locuza]

Chips and Cheese hat sich die Gigabyte-Dokumente bezüglich Zen4 genauer angeschaut:
https://chipsandcheese.com/2021/08/23/details-on-the-gigabyte-leak/

Zen4 bring erstaunlich wenig Änderungen an den Kernstrukturen:
Structure Zen 4 Zen 3 Notes
L1 data, L1 instruction 32 KB 8-way 32 KB 8-way No change
L2 1 MB 8-way 512 KB 8-way 2x sets
L3 16 or 32 MB 16-way 16 or 32 MB 16-way No change
L1 ITLB 64 entry fully associative 64 entry fully associative No change
L2 ITLB 512 entry 4-way 512 entry 4-way No change
L1 DTLB 72 entry fully associative 64 entry fully associative Slight increase
L2 DTLB 3072 entry 12-way 2048 entry 8-way 50% increase

L1 DTLB wird ein bisschen vergrößert, der L2 DTLB immerhin um 50%, ansonsten sind die anderen Kernstrukturen die gleichen.
Der L2$ wird, wie es schon seit längerem in der Gerüchteküche herumfliegt, auf 1MiB pro Kern verdoppelt.

Wenn sie es richtig deuten, dann hat Zen4 nach wie vor "nur" 4 Integer-ALUs.

Neu dagegen sind viele AVX512-Instruktionen.

Es gibt viele Details bezüglich der I/O-Systeme, CXL wird bei Genoa unterstützt, Gen-z.
Einige Taktraten wurden hochgeschraubt.
Und mehr im Link oben.

[basix]

Kann man eigentlich einschätzen, wie schädlich dieser Gigabyte Leak für AMD ist?

[fondness]

Sieht also tatsächlich nach single 512-bit FMA aus, das erklärt zumindest die Die-Size.

[HOT]

Das ist glaub ich schon ziemlich heftig. Da ist ja der Geist ein jahr zu früh aus der Flasche.

[Locuza]

Es ist immer noch offen, wie AMD AVX512 umsetzt.
Also, ob der Datencache 64 Bytes (512-Bit) pro Leitung schafft oder bei 32 Bytes (256-Bit) bleibt.
Bei den FP ALUs ist es auch noch offen, ob bei AMD alle FMA-Einheiten 512-Bit schaffen oder nur eine.
Spekuliert wird z.B. über Port-Fusion, ähnlich wie bei Intel, wo 2x256-Bit zusammengelegt werden, um 1x512-Bit zu berechnen.

Der einzige was man scheinbar ausschließen kann ist, dass AMD AVX512-Bit wie damals AVX256-Bit (AVX1/2) bei Zen1 umsetzt, wo eine 256-Bit Instruktion in zwei 128-Bit Operationen gesplittet wurde, wo eine Hälfte in einem Takt berechnet wurde und die andere dann im nächsten.
Für Speicheroperationen soll es 64 Bytes(512-Bit) für micro ops geben, also kein Splitting.

[amdfanuwe]

Kann man eigentlich einschätzen, wie schädlich dieser Gigabyte Leak für AMD ist?
Einschätzen wohl kaum. Bisher liest man ja eigentlich noch nichts besonderes.
Schaut man zurück, dual Core, Quad Core, IGP, da konnte Intel mit zusammengeklebten Chips AMD zuvorkommen weil AMD dieses frühzeitig ankündigte.
ZEN 2 Chiplets, IF-Cache, 3D V-Cache haben uns und wohl auch die Konkurrenz ziemlich überrascht.

Wieweit der Gigabyte Diebstahl sich negativ für AMD auswirkt hängt davon ab, was da an zukunftsweisenden Technologien noch drinsteht und veröffentlicht wird.
Würde mich auch nicht wundern, wenn Intel für die Daten schon entsprechende Summen geboten hat.

[Nightspider]

Hieß es nicht mal das AVX512 eigentlich sinnlos und überflüssig wäre?

[HOT]

Das haben die nur wegen Servergeschichten.

[Locuza]

Hieß es nicht mal das AVX512 eigentlich sinnlos und überflüssig wäre?
Es gibt zwei Betrachtungsweisen bzw. Komponenten in der Richtung.

Eine Komponente sind die 512-Bit breiten Vektoren und alles was dann damit zusammenhängt, um das zu realisieren, 512-Bit breite Register, große FP ALUs, usw.
Das ist ein Aspekt der viel HW kostet und wo man argumentieren kann, dass so etwas in der CPU nicht bestens aufgehoben ist und man sich dann doch lieber Gedanken um GPU-Computing machen sollte, die eben explizit für breite Vektormathematik ausgerichtet sind.
Trotzdem ist es so, dass man von breiten Vektoren auch bei CPUs profitieren kann, denn es ist großer Unterschied, ob man CPUs oder GPUs verwendet.
Bei CPUs hat man pro Kern wahnsinnig viel Cache im Vergleich zu GPU Units, die Arbeitsgranularität ist viel feiner ist, man hat niedrigere Latenzen, die Out-Of-Order-Maschinerie und ein viel allgemeineres und breites Angebot was den Software-Stack und die Programmierung angeht.

Die andere Komponente sind die neuen Features, außerhalb der reinen Hardwarebreite.
Z.B. 32 Vektorregister mit denen man direkt arbeiten kann, anstatt 16.
Es gibt neue Mask-Register und viele neue Instruktionen, insgesamt kann man damit viele Anwendungsbereiche beschleunigen und das Ganze stellt echten Fortschritt dar.

Viele würden sich wünschen, dass man die zweite Komponente bekommen kann, mit nativen 128-Bit oder 256-Bit Umsetzungen, ohne über 512-Bit Aspekte nachdenken zu müssen.

[Der_Korken]

Prinzipiell finde ich es nicht schlimm, wenn AMD keine große Umbauten an der Cache-Hierachie macht und auch das Backend nicht verbreitert, sofern dann ein entsprechend kleiner und effizienter Kern herauskommt. Die Die-Size deutet aber auf etwas ganz anderes hin. Ich hoffe, dass das nicht alles in AVX512 reingebuttert wurde, da das zumindest für Consumer reine Verschwendung wäre. Selbst wenn man die entsprechenden Transistoren einfach abschalten würde, ziehen sich die Nachteile auch auf Non-AVX512-Teile durch, z.B. dann wenn die L1-Bandbreite verdoppelt wurde. Das gab es nicht umsonst in Hinblick auf Latenz und Verbrauch, aber für "normale" Instruktionen bringt es quasi nichts. Ich empfand die Versteifung Intels auf AVX512 immer als kleinen Trumpf für AMD, die den Kram einfach ignoriert und dafür bei den Kern-Kompetenzen (pun intended^^) gepunktet haben. Das wäre so ein bisschen ein Bulldozer-Moment, wo Intel ihre Marotte (damals Hochfrequenz-Design) nach Jahren abgelegt hat und dafür AMD damit anfing, um ebenfalls damit auf die Schnauze zu fallen.

Andererseits ist ja nicht ausgeschlossen, dass der Kern nicht noch anderweitig aufgebohrt wurde: Mehr Register, größeres OoO-Window, breiteres Frontend, größere Scheduler, etc. Wobei es natürlich schwer wird aus 4 INT-ALUs noch viel rauszuholen. Zen 1 hatte ja schon 4 davon und Zen 3 holt mal eben 40% mehr Leistung aus denen raus. Wenn das nochmal 25% mehr werden (so wurde mal gemunkelt), muss man sich wirklich fragen, was die Ingenieure bei Zen 1 eigentlich gemacht haben. Da hätte man ja quasi 1,5 INT-ALUs einfach weglassen können.

[Gipsel]

Andererseits ist ja nicht ausgeschlossen, dass der Kern nicht noch anderweitig aufgebohrt wurde: Mehr Register, größeres OoO-Window, breiteres Frontend, größere Scheduler, etc. Wobei es natürlich schwer wird aus 4 INT-ALUs noch viel rauszuholen.Bei einer durchschnittlichen IPC von wohl immer noch unter 2 bei z.B. SPEC-CPU halte ich solche Statements für verfrüht. Man packt im Prinzip mehr ALUs dazu, weil man damit in ein paar Situationen einen gewissen Vorteil ziehen kann (was außerhalb dieser Situationen und somit im Durchschnitt eher wenig bringt) und das eventuell als einfacher ansah, als aus den vorhandenen Einheiten durch andere Maßnahmen allgemein mehr Performance zu extrahieren. Aber solche Abwägungen können sich ändern (mehr Kenntnisse, höheres Transistorbudget, andere Prozesse und sowas).
Zen 1 hatte ja schon 4 davon und Zen 3 holt mal eben 40% mehr Leistung aus denen raus. Wenn das nochmal 25% mehr werden (so wurde mal gemunkelt), muss man sich wirklich fragen, was die Ingenieure bei Zen 1 eigentlich gemacht haben. Da hätte man ja quasi 1,5 INT-ALUs einfach weglassen können.Auch der K7 hatte vor 22 Jahren schon 3 INT-ALUs. Kannst ja auch mal gegen den vergleichen. ;)
Normalerweise gibt es immer mal Peaks bei Instruktionsrate. Mit mehr Einheiten macht man diese Peaks höher, aber wenn man eine effiziente Möglichkeit findet, die Zeiten zwischen den Peaks zu minimieren bzw. dort mehr Instruktionen pro Takt abzuarbeiten, kann das sehr viel bringen. Nur in sehr wenigen hochoptimierten Codes stößt man konsistent und hart an das Limit der begrenzten Anzahl von Einheiten.

[Locuza]

@ Der_Korken

Zen1 war zu sehr großen Teilen eine neue völlige neue Mikroarchitektur bzw. ein neues Fundament, welches AMD mit den damals beschränkten Ressourcen auf den Markt gebracht hat, mit 14nm als Target.
Mit 7nm gibt es ein massiv größeres Transistorenbudget, was sich durch die ganze Architektur ,im Vergleich zu Zen1, zieht.
Viel besseres Frontend und stärkeres Backend, denn um die 4 Integer ALUs herum passiert ja eine ganze Menge.
Zen3 stellt auch eine neue Architektur dar, erfindet aber viel selektiver das Rad neu.
Vieles wurde recycled, der I/O die, die GMI2-Verbindungen zum I/O-die, das SRAM-Design vom L1D$, der L2$ ist fast der gleiche wie bei Zen2, welcher schon das Design davor bei Zen1 zu großen teilen übernommen hat und auf 7nm umgesetzt.
"Lediglich" Kern und L3$ ist zu großen Teilen neugestaltet, mit vermutlich größeren Entwicklungsressourcen, relativ zur Vergangenheit.
Bei Zen1 musste man fast alles neu aufbauen, Kern, Cache-Designs, SoC-Infrastruktur mit dem ganzen I/O-Kram, usw.

Das der neuste 7nm-Kern mit deutlich größeren BTBs, doppelt so großem Op$, größeren TLBs, mehr AGUs und Scheduling-Ports dann bei Integer-Aufgaben trotz 4 INT ALUs mehr leistet, ist dann nicht so überraschend.
Wobei historisch gesehen der Sprung natürlich heftig ausfällt, im Vergleich dazu gab es nur Baby-Schritte bei der Bulldozer-Linie.

[CrazyIvan]

Bei Chips & Cheese haben die aber kein Wort zur Größe des Reorder Buffer verloren. Nicht, dass ich mir von der Einzelmaßnahme Wunder erwarte, aber eine deutliche Vergrößerung läge im allgemeinen Trend und würde sicher einen Teil des gestiegenen Budgets erklären. Oder wurde der im Artikel nur anders bezeichnet?

[Zossel]

Bei einer durchschnittlichen IPC von wohl immer noch unter 2 bei z.B. SPEC-CPU

Die Kisten brauchen auch ALUs zum spekulieren.

[fondness]

Das tut man schon lange nicht mehr AFAIK, viel zu viel verbrannte Energie.

[Locuza]

Bei Chips & Cheese haben die aber kein Wort zur Größe des Reorder Buffer verloren. Nicht, dass ich mir von der Einzelmaßnahme Wunder erwarte, aber eine deutliche Vergrößerung läge im allgemeinen Trend und würde sicher einen Teil des gestiegenen Budgets erklären. Oder wurde der im Artikel nur anders bezeichnet?
Dazu gab es keine Angaben, ebenso wenig für die Größe der Branch Target Buffer, der Scheduler-Queue-Größe auf der INT und FP-Seite und wie viele Einträge das Register-File jeweils hat.
Es fehlen natürlich auch alle Details bezüglich Frontend, wie groß ist der Op$? (gleich vermutlich), wie viele Decoder gibt es, Ports im Backend, etc.

Es ist noch eine Menge offen.

[Zossel]

Das tut man schon lange nicht mehr AFAIK, viel zu viel verbrannte Energie.

Beziehst du dich auf meinen Post?

[basix]

Hieß es nicht mal das AVX512 eigentlich sinnlos und überflüssig wäre?

In vielen Fällen schon. Gewisse Insruktionen beschleunigen aber gut und allenfalls gibt es noch AMX obendrauf. Was ich aber denke: Man will bei Zen 4D die selben Instruktionen wie auf Zen 5 verfügbar haben.

Edit:
Noch zum grossen Zen 4 Core, evtl. ist er gar nicht so dick: https://chipsandcheese.com/2021/08/23/details-on-the-gigabyte-leak/
Zen 4 in Genoa (server) form supports up to 12 channels of DDR5-5200. To increase bandwidth available to a single CCD, it seems AMD has opted to add more IF links to each CCD. ‘Narrow mode’ may be a way to save even more power by disabling one of the IF links when high bandwidth isn’t required

[Gipsel]

Die Kisten brauchen auch ALUs zum spekulieren.Zur IPC zählen nicht nur ALU-Instruktionen und außerdem kann man versuchen, öfter mal richtig zu spekulieren. Das steigert die Energieeffizienz und die Performance (auch ohne mehr ALUs).

====================

Das tut man schon lange nicht mehr AFAIK, viel zu viel verbrannte Energie.Also spekulieren tut man schon noch. tendentiell gar mehr als früher. Man achtet nur mehr darauf (vor Allem aus Stromspargründen), nicht ständig höchstwahrscheinlich sinnlosen Kram zu machen.

[Ramius]

Da ca. alle 6 - 10 Takte ein Sprungbefehl kommt muss die CPU immer spekulieren ob der Sprung genommen wird oder nicht. Andernfalls müsste die CPU viele Takte warten bis die korrekte Sprungadresse berechnet wurde.

[CrazyIvan]

Das schon. Oftmals gibt es aber auch downstream jede Menge Befehle, die mit dem Sprung nix zu tun haben. Hier hilft ein großer ROB und natürlich entsprechende weitere Ressourcen wie Queues, um möglichst viel Schmontz vorziehen zu können.

[Badesalz]

@Locuza
Ich bin selbst natürlich auch recht vorsichtig was Dahingeschiedene schwadronieren, aber gleich... "mistake"? :wink:
https://www.newsy-today.com/former-chief-engineer-of-intel-told-what-is-wrong-with-the-company-and-how-to-fix-it/

Hieß es nicht mal das AVX512 eigentlich sinnlos und überflüssig wäre?Ja. Und das ist auch richtig. Ähnlich den SSE "Versionen", wäre man mit einem nachgeschobenen AVX 2.1 besser bedient gewesen.

Diesen Mist gab es ursprünglich nur um NV zu ärgern. Ein sinnloses Unterfangen aus der Zeit als Xe noch halb in der Schwebe war. Kann man auch machen, wenn man aus irgendeinem Grund keine GPU haben will - wie beim A64FX für Fugaku - aber das ist halt schon recht speziell.
Recht speziell, braucht man im Server nicht und im Desktop auch nicht.

[Leonidas]

Zen 4 Termin-Vorhersagen:
https://www.3dcenter.org/news/hardware-und-nachrichten-links-des-28-september-2021

[Skysnake]

Weiß man durch die Gigabyte Leaks eigentlich inzwischen wie es mit RAM etc weiter geht?

[iamthebear]

Software die Vektorarithmetik verwendet lässt sich so gut wie immer auch sehr zu parallelisieren.
Hier muss man sich natürlich die Frage stellen, ob es Sinn macht für Befehle, die nur von einer Hand voll Anwendungen sporadisch genutzt werden die Kerne sie extrem aufzublähen und sich Probleme wie potentiell schnell ansteigenden Energieverbrauch einzuhandeln.
Oder ob es nicht sinnvoller ist stattdessen wie bei Intel ein paar Little Cores zu verbauen, die dann nicht nur Vektoroperationen sondern jegliche Software beschleunigen können, die gut parallelisierbar ist.

[CrazyIvan]

Zumal man Vektorberechnungen doch sowieso eher auf der GPU macht, oder gibt es da wichtige Einschränkungen, von denen ich nichts weiß?

[basix]

Wenn es nur Half-Rate AVX-512, sollte sich die Vektoreinheit ja nicht wirklich aufblähen. Dafür hätte man ein erweitertes Instruktions-Set.

[HOT]

Davon würde ich ausgehen. Zen4 kann AVX512 so gut wie Zen1 AVX2 kann.

[HPVD]

...wobei "Half-Rate AVX-512" nicht wirklich halbe Leistung heißen muss,
da ja die "Breiten Einheiten" iaR mehr elektrische Leistung brauchen (AVX < AVX2 < AVX-512) und daher aufgrund des Powerbudgets / und oder der erreichten Temperaturen die Taktfrequenz gesenkt wird (extrem bei Intel...)

=> aus einer "Half-Rate AVX-512" Implementierung könnte durchaus 70% einer full rate Implementierung rauskommen...

edit: und das in Kombination mit der im Vergleich zu Intel deutlich höheren Kernanzahl (und damit auch höheren Anzahl an AVX-512 Ausführungseinheiten..),
könnte das dann zwar keinen absoluten Vorteil bei der Ausführung von AVX-512 Code gegenüber Intel bedeuten aber einen Mühelosen Gleichstand :-D

[Ramius]

Zumal man Vektorberechnungen doch sowieso eher auf der GPU macht, oder gibt es da wichtige Einschränkungen, von denen ich nichts weiß?

Welche CPU führt denn Vektorberechnungen auf der GPU aus?
Meines Wissens gibt es bisher keine solche CPU (würde auch voraussetzen, dass eine CPU eine GPU enthält).

Vektorrechnungen führt man nicht auf der GPU aus, weil es viel zu lange dauern würde die Daten zu der GPU zu schicken, dort verarbeiten zu lassen und die Ergebnisse wieder zurück zu schicken. Bis dahin hat die CPU das Ergebnis schon längst selbst berechnet.

[mczak]

...wobei "Half-Rate AVX-512" nicht wirklich halbe Leistung heißen muss,
da ja die "Breiten Einheiten" iaR mehr elektrische Leistung brauchen (AVX < AVX2 < AVX-512) und daher aufgrund des Powerbudgets / und oder der erreichten Temperaturen die Taktfrequenz gesenkt wird (extrem bei Intel...)
Es gibt auch noch einen anderen Grund wieso in der Praxis Half-Rate Einheiten schneller als 50% sind. Weil in der Praxis ist es relativ schwierig alle Einheiten auszulasten, gerade auch bei Float-Befehlen die relativ hohe Latenzen haben. z.B. bei 2 FMA-Einheiten bei einer Latenz von 3 Takten braucht es immer 6 FMA-Befehle die voneinander unabhängig sind um die Einheiten auszulasten (SMT hilft da natürlich auch) - da aber die obere und untere Hälfte eines FMA-Befehls unabhängig sind verringert sich die Anzahl nötiger unabhängiger Befehle um die volle Auslastung zu erreichen bei Half-Rate Einheiten automatisch um die Hälfte. (Ausnahmen sind Befehle bei denen die obere und untere Hälfte voneinander abhängig sind, typischerweise sind das shuffle-Geschichten.). In der Praxis ist also die Auslastung von Half-Rate Einheiten höher als bei Full-Rate Einheiten.

[HPVD]

Es gibt auch noch einen anderen Grund wieso in der Praxis Half-Rate Einheiten schneller als 50% sind. Weil in der Praxis ist es relativ schwierig alle Einheiten auszulasten, gerade auch bei Float-Befehlen die relativ hohe Latenzen haben. z.B. bei 2 FMA-Einheiten bei einer Latenz von 3 Takten braucht es immer 6 FMA-Befehle die voneinander unabhängig sind um die Einheiten auszulasten (SMT hilft da natürlich auch) - da aber die obere und untere Hälfte eines FMA-Befehls unabhängig sind verringert sich die Anzahl nötiger unabhängiger Befehle um die volle Auslastung zu erreichen bei Half-Rate Einheiten automatisch um die Hälfte. (Ausnahmen sind Befehle bei denen die obere und untere Hälfte voneinander abhängig sind, typischerweise sind das shuffle-Geschichten.). In der Praxis ist also die Auslastung von Half-Rate Einheiten höher als bei Full-Rate Einheiten.

interessant! Danke für den Background.

[basix]

Half-Rate AVX512 hätte ausserdem noch einen weiteren Vorteil: Zen 4D. Der soll bei Zen 5 ja als Little Core auftreten. Aufgeblähte Vektoreinheiten sind da nicht förderlich. Inkl. AVX512 Support, kann man den bei Zen 5 ebenfalls bringen und aktiviert lassen. Intel muss AVX512 bei Alderlake deaktivieren, da Gracemont kein AVX512 kann.

Potentiell hat Zen 5 dann Full-Rate AVX512, AMX and whatsoever.

[HOT]

Full Rate sicher nicht, hat ja auch keine Intel-CPU abseits von Skylake X oder?

[basix]

Icelake, Cascade Lake, Tiger Lake, Rocket Lake, und in Zukunft Sapphire Rapids. Theoretisch auch die Golden Cove Kerne in Alderlake.

Edit:
Im Serverumfeld ist AVX512 schon lange verbreitet. Ob es nun Full-Rate AVX512 sein muss? Nö. Aber wer weiss, was für HPC noch so relevant ist. AMX scheint mir deutlich interessanter als AVX512 zu sein und profitiert ebenfalls von zusätzlicher Vektorbreite.

[Nightspider]

Mir fällt es schwer mir vorzustellen, das man das big.LITTLE Prinzip bei Zen5 auch in die EPYC Reihe bringen will.

Strebt Intel das für HPC an?

[robbitop]

Gerade dort gibt es doch sehr viele Workloads die paralellisierbar sind. Entsprechend kann man bei gleichem Power Budget mehr Rechenleistung verbauen, da mehr Perf/W.

[Nightspider]

Dafür gibts doch GPUs die das besser können.

Wenn man sich so einige News ansieht ist das Verhältnis von CPUs zu GPUs pro Server oft 1:4 oder etwas in der Richtung.

[fondness]

Mir fällt es schwer mir vorzustellen, das man das big.LITTLE Prinzip bei Zen5 auch in die EPYC Reihe bringen will.

Strebt Intel das für HPC an?

Intel bringt zumindest soweit bekannt nur big cores im Server-Segment. Solange man bei den littles kein AVX-512 hat, macht was anderes wohl auch keinen Sinn. Außerdem hätte man dann natürlich im Server auch das Problem, dass man unterschiedlich schnelle Core hat, stelle ich mir bsw. bei virtuellen Maschinen spannend vor.

[basix]

Mir fällt es schwer mir vorzustellen, das man das big.LITTLE Prinzip bei Zen5 auch in die EPYC Reihe bringen will.

Strebt Intel das für HPC an?

Wenn AMD die selben Chiplets für Ryzen und EPYC verwenden will, wird es aber zwangsläufig darauf hinauslaufen. Kann natürlich sein, dass das AMD in Zukunft nicht mehr so handhabt. Bei Intels Sapphire Rapids ist noch nichts von Big.Little zu sehen. Was danach kommt, weiss ich nicht.

Wie fondness angedeutet hat, sind diese unterschiedlichen Cores dann interessant / eine Herausforderung bezüglich SW-Support, Virtualisierung usw.

Dafür gibts doch GPUs die das besser können.

Wenn man sich so einige News ansieht ist das Verhältnis von CPUs zu GPUs pro Server oft 1:4 oder etwas in der Richtung.

CPU Parallelisierbarkeit != GPU Paralleisierbarkeit. Auf der CPU laufen oftmals viele einzelne kleinere Tasks, welche eine begrenzte Parallelisierbarkeit mitbringen und/oder latenzkritisch sind. Das können Webservices, Container, Virtualisierte Geschichten usw. sein. Auf der GPU läuft bevorzugt ein einziger oder ein paar wenige Task, welche sich dafür sehr stark paralellisieren lassen. Das sind einfach nicht die selben Anwendungen. Will man einzelne unabhängige Tasks mit begrenzter Parallelisierbarkeit nebeneinander laufen lassen, dann ist die CPU die deutlich bessere Wahl. Und hier kämen dann die vielen Cores ins Spiel.

Bezüglich GPU Parallelisierbarkeit ist eine breite AVX512/AMX Einheit die deutlich fragwürdigere Geschichte als mehr Cores zu haben. AVX2 hat sich eigentlich sehr weit verbreitet, hier scheint der Nutzen doch einigermassen gross zu sein. Ab irgendeiner Vektorbreite/Parallelisierbarkeit ist dann aber die GPU deutlich im Vorteil. Dennoch sind die AVX512/AMX Befehlssätze interessant und bringen zum Teil einen deutlichen Boost.

[Skysnake]

Dafür gibts doch GPUs die das besser können.

Wenn man sich so einige News ansieht ist das Verhältnis von CPUs zu GPUs pro Server oft 1:4 oder etwas in der Richtung.

Das ist aber ne ganz andere Liga an Parallelität...

GPU: Anzahl ALUs x 4-16 = 25.000-125.000
CPU: Cores x FP-Pipes x SIMD Breite x 1-6 = 500-6.000

Da liegt etwa eine Größenordnung dazwischen

[Nightspider]

Wenn Genoa mit 96 Kernen kommt hat sich die Kernzahl aber auch innerhalb weniger Jahre fast verdreifacht. Und Server haben ja tendenziell dutzende Cluster.

Wäre vielleicht auch im Interesse von AMD und Intel mehr große CPU Kerne zu verkaufen.

Könnte mir da vielleicht eher gewisse Stromsparmechanismen vorstellen, wenn der Server mal nicht auf 100% läuft aber dann nur mit wenigen Little Cores.

Kann da aber nur spekulieren. Nach dem großen Kernzuwachs aktuell kann ich mir nur schwer vorstellen das man da irgendwie nochmal doppelt so viele Little Cores benötigt
bzw. sinnvoll verwenden kann. Gerade wenn es schwierigerer wird die Last optimal zu verteilen, zwischen den Cores.

[Thunder99]

Kerne die nicht benötigt werden sind doch bereits abgeschaltet

[CrazyIvan]

Welche CPU führt denn Vektorberechnungen auf der GPU aus?
Meines Wissens gibt es bisher keine solche CPU (würde auch voraussetzen, dass eine CPU eine GPU enthält).

Vektorrechnungen führt man nicht auf der GPU aus, weil es viel zu lange dauern würde die Daten zu der GPU zu schicken, dort verarbeiten zu lassen und die Ergebnisse wieder zurück zu schicken. Bis dahin hat die CPU das Ergebnis schon längst selbst berechnet.
Das hast Du falsch veratanden. Ich meine natürlich, dass Vektorberechnungen komplett von der GPU ausgeführt werden - nicht im Tandem mit der CPU. Im Grunde ist eine GPU ein Vektorprozessor, nur eben ein massiv paralleler. So der Grundgedanke von GPGPU (Cuda & Co.).
Wie in nachfolgenden Beiträgen erwähnt, macht das aber anscheinend nicht in jedem Fall Sinn, da nicht jeder Vektor-Workload per definitionem massiv parallelisierbar zu sein scheint (bin da nicht so bewandert).
Nichtsdestotrotz war AVX IMHO von Intel schon ein Stück weit dazu gedacht, GPGPU im Markt für Großrechner abzuwehren.

[Lehdro]

Wenn AMD die selben Chiplets für Ryzen und EPYC verwenden will, wird es aber zwangsläufig darauf hinauslaufen. Kann natürlich sein, dass das AMD in Zukunft nicht mehr so handhabt.
Wieso? Man baut Zen4 und Zen5 auch in einzelne CCDs. Der neue little Core CCD von Zen4 bleibt dann einfach dem Desktop vorbehalten und EPYC in Gen5 kriegt halt nur Zen 5 CCDs. Oder sollen Zen5 + Zen4 plötzlich auf dasselbe CCD? Das widerspricht doch dem eigentlichen Chipletdenken...

[Der_Korken]

Oder sollen Zen5 + Zen4 plötzlich auf dasselbe CCD? Das widerspricht doch dem eigentlichen Chipletdenken...

Nicht unbedingt. Wenn man die Chiplets so aufbaut wie Intels Alder Lake, dann kann man im Desktop kleine und große Kerne immer mitskalieren. Sonst bräuchtest du für das kleinste Modell schon immer zwei Chiplets, nämlich eins mit großen und eins mit kleinen Kernen. Letzteres könnte vor allem viel zu klein werden als dass es sich lohnt solche Chips zu fertigen. Es sei denn du packst gleich 16 Stück von den kleinen Kernen drauf. Dann schon lieber 8 von jeder Sorte auf ein Chiplet, damit man zusätzlich noch Threads ohne große Umwege Threads von einer Sorte auf die andere verschieben kann.