Zen 5 (3/4 nm, 2024)

[HOT]

Warum gibt es so wenig µATX Bretter? Das würde einiges an Platinenfläche sparen.
Liegt doch auf der Hand, weil die wussten, dass P22 noch kommt.

[latiose88]

hm das ist aber ne merkwürdige Hedt Plattform,also es fehlen da irgendwie noch die 24 Kerner und so.Aber die werden ja nie kommen,also auch mit Zen 5 sind diese ja nicht in Sicht.

[amdfanuwe]

.Aber die werden ja nie kommen,also auch mit Zen 5 sind diese ja nicht in Sicht.
warum?

[latiose88]

na weil nix angekündigt worden ist für die Zukunft mit mehr als 16 P Kernen,es sei denn AMD ändert den aufbau mit den 8 Kern Chiplets oder setzt 3 Chiplets zusammen.Aber warum sollte das AMD machen weil ist ja dann Teurer als nur mit 2 zu machen.

[amdfanuwe]

na weil nix angekündigt worden ist für die Zukunft mit mehr als 16 P Kernen,es sei denn AMD ändert den aufbau mit den 8 Kern Chiplets oder setzt 3 Chiplets zusammen.Aber warum sollte das AMD machen weil ist ja dann Teurer als nur mit 2 zu machen.
Warum verkaufen sie denn mit 2?
Ist ja teurer als nur mit 1.

Wozu sollten sie das ankündigen? Ist noch weit hin bis ZEN 5.
Wart mal ab. Wenn AMD darin einen Markt sieht, werden sie es bringen.
Kostet AMD ja kaum etwas. Die Chiplets sind dann eh da und ob man nun 2x8 oder 2x16 oder 8 3D+16 macht da keinen großen unterschied, außer im Preis den AMD dafür verlangen kann.

[KarlKastor]

Da der B650 eine Art aufgebohrter X570 ist und sogar über die doppelte nutzbare Anzahl an PCIe Gen4 Lanes verfügt wie der alte Highend Chipsatz, wundert mich auch gar nicht wieso er das Preissegment des x570 beerbt.
Es sind einfach zwei teurere Optionen dazu gekommen.

Wovon redest du?
Der B650 hat 8x PCIe 4.0, 4x PCIe 3.0/SATA und 6x USB 3.2.
Der x570 hat 16x PCIe 4.0, 4x SATA und 8x USB 3.2.

Der x670 ist in etwa auf dem Niveau des X570.
Der B650 ist ein kleiner Mainstream Chip, da ist nichts großartig komplex.

[Oranje7]

Wovon redest du?
Der B650 hat 8x PCIe 4.0, 4x PCIe 3.0/SATA und 6x USB 3.2.
Der x570 hat 16x PCIe 4.0, 4x SATA und 8x USB 3.2.

Der x670 ist in etwa auf dem Niveau des X570.
Der B650 ist ein kleiner Mainstream Chip, da ist nichts großartig komplex.

AMD Folie sagt was anderes
https://pics.computerbase.de/1/0/5/2/3/9-e64d7d1f5d1d7873/article-640x360.3ea54a71.jpg

[KhanRKerensky]

Warum verkaufen sie denn mit 2?
Ist ja teurer als nur mit 1.

Wozu sollten sie das ankündigen? Ist noch weit hin bis ZEN 5.
Wart mal ab. Wenn AMD darin einen Markt sieht, werden sie es bringen.
Kostet AMD ja kaum etwas. Die Chiplets sind dann eh da und ob man nun 2x8 oder 2x16 oder 8 3D+16 macht da keinen großen unterschied, außer im Preis den AMD dafür verlangen kann.
Das Problem wird das Speicherinterface sein. Consumer und Server haben eins gemeinsam: Im Maximalausbau ein CCD pro Speicherkanal. Der limitierende Faktor wird also der Sockel/Platform sein. 24 Kerne wollen erstmal mit Daten gefüttert werden.

[amdfanuwe]

Das Problem wird das Speicherinterface sein. Consumer und Server haben eins gemeinsam: Im Maximalausbau ein CCD pro Speicherkanal. Der limitierende Faktor wird also der Sockel/Platform sein. 24 Kerne wollen erstmal mit Daten gefüttert werden.
Guter Punkt.
Das ist letztendlich ein Problem der Aufgabenstellung. Manche Aufgaben profitieren von hoher Speicherbandbreite, manche kommen mit weniger Speicherbandbreite hin.
Letztendlich gilt es einen Kompromiss zu finden.
Bei Bergamo werden 128c Cores ( 16 CCX ) mit 12 Kanal Speicher bedient.
Kann man nun argumentieren, dass die c-Cores langsamer sind und mit weniger Speicherbandbreite auskommen.
Gilt dann aber auch für eine Desktop Konfiguration von 8 + 16c.

Für ZEN 5 scheint AMD das Speicherbandbreitenproblem mit IF$ im I/O zu entschärfen. Dadurch können mehr Cores verbaut werden ohne das Speicherinterface zu vergrößern.

Hat man überwiegend Applikationen, die mangels Speicherbandbreite verhungern, bringen das mehr an Cores natürlich nichts.
Dann kann man auch zu kleineren CPUs greifen.

Also, 24 oder gar 32 Cores im Desktop würde ich nicht ausschließen, wird wie auch jetzt schon die 16 Cores nicht jedem eine entsprechende Mehrperformance bringen. Wer aber entsprechende Anwendungen hat, wird sich freuen.

P.S.:
Frage an die Profis: Wieviel IF$ wäre nötig um 2TB für Server abzudecken?

[HOT]

AMD Folie sagt was anderes
https://pics.computerbase.de/1/0/5/2/3/9-e64d7d1f5d1d7873/article-640x360.3ea54a71.jpg

Nö sagt sie nicht. Wir reden hier vom Chipsatz, nicht von AM5.

Der X570 hat bis zu 16 freie Lanes + 4 SATA (2 weitere waren oft shared, gerne aufgeteilt in 2 m.2 + 1 4x-Slot, 2 1x Slots und LAN+WLAN)
Der X670 hat bis zu 16 freie Lanes + 4 SATA (davon allerdings 4 3.0, welche für LAN/WLAN und 1x/2x-Slots draufgehen)

Sind also sehr ähnlich.

AM5 bringt 4 Lanes zusätzlich mit über die CPU.

amdfanuwe
Ich kann mir beim besten Willen nicht vorstellen, dass AMD das IOD ändert. Ich denke eher, dass die Chiplets miteinander verbunden werden und einen großen, virtuellen L3$ schaffen, den AMD IF$ nennen wird.

[davidzo]

Nö sagt sie nicht. Wir reden hier vom Chipsatz, nicht von AM5.

Der X570 hat bis zu 16 freie Lanes + 4 SATA (2 weitere waren oft shared, gerne aufgeteilt in 2 m.2 + 1 4x-Slot, 2 1x Slots und LAN+WLAN)
Der X670 hat bis zu 16 freie Lanes + 4 SATA (davon allerdings 4 3.0, welche für LAN/WLAN und 1x/2x-Slots draufgehen)

Sind also sehr ähnlich.

AM5 bringt 4 Lanes zusätzlich mit über die CPU.

amdfanuwe
Ich kann mir beim besten Willen nicht vorstellen, dass AMD das IOD ändert. Ich denke eher, dass die Chiplets miteinander verbunden werden und einen großen, virtuellen L3$ schaffen, den AMD IF$ nennen wird.


Afaik sind es jeweils nur 12 "freie" lanes, wenn man die x4 für den CPU uplink abzieht. AMD spricht bei x570 zwar auch manchmal von 16x lanes, aber eben nur 12x "flexible" - die letzten vier sind shared mit sata, außerdem werden dort die LAN Chips angebunden.
Aber in der Tat hat der B650 nur x8 nach 4.0 Standard, die anderen sind 3.0, hat also weniger Gesamtbandbreite als x570 mit 12x freien 4.0 lanes.
Allerdings hat bei AM5 die CPU 4x Lanes mehr und zwar sogar nach 5.0 Standard. In der Plattformübersicht bietet der B650 also gleichviel bzw. der B650E mehr.

Bandbreitentechnisch liefert AM5 + B650 also etwas mehr als ein x570 board, wenn man mal von den fehlenden SATA-Ports absieht. Es ist also verständlich dass die Platinen ähnlich aufwändig und teuer sind, wenn nicht sogar etwas teurer wenn es sich um die B650E Variante mit Gen5 handelt.

[Windi]

Wenn einem 4xSata reicht, dann hat der X570 16 PCIe Lanes und der B650 8 PCIe Lanes.
Ich sehe das schon fast als eine Halbierung des Chipsatzes an.

Als Ausgleich bietet AMD dann halt den X670, der gleiche zwei Chips in Reihe schaltet. Außerdem bietet die CPU bei AM5 diesmal mehr.

Die hohen Kosten der Mainboards können kaum durch die Chips der Chpsätze entstehen. Der P21 ist nicht wirklich übermäßig ausgestattet. Die Kosten kommen wohl eher von der CPU. DDR5 ist Pflicht. Und dazu kommen noch 28 PCIe Lanes, die mindestens 4.0 sein müssen aber häufig sogar 5.0 nutzen. Das treibt die Kosten für die Mainboards.


Es wird noch interessant was AMD beim P22 alles einsparen will, wenn es sich wirklich lohnen soll, dafür extra einen eigenen Chip aufzulegen.

[KarlKastor]

@davidzo
Schau dir doch einfach mal die Schaubilder an, dann brauchst du nicht rumraten. Es ist fast alles falsch was du sagst.

Auch auf die Plattform bezogen, liegt der x570 vor dem x650.

Die Plattform hat teilweise mehr Bandbreite durch PCIe 5.0, aber das rechtfertigt nicht so hohe Preise. Denn auch die Boards komplett ohne PCIe 5.0 sind teuer.

@Windi
Wie kommst du auf 28?
Und es müssen nicht alle 4.0 sein. Die Hersteller können die auch nur als 3.0 auslegen oder ganz weglassen. Wird ja auch teilweise gemacht.
Deswegen hilft auch ein neuer Chipset nicht wirklich. Der Promon21 ist ja klein. Die Hersteller könnten ja abgespeckte Boards damit bringen. Machen sie ja auch teilweise, nur spiegelt sich das nicht im Preis wieder.


Zum Beispiel das GIGABYTE B650M DS3H. 24 PCIe 4.0 und der Rest auch vom billigsten.
Kostet aber 175€.

[Windi]

@Windi
Wie kommst du auf 28?
Und es müssen nicht alle 4.0 sein.

Naja 28, wenn ich auch die 4 mitzähle, die normalerweise den Chipsatz anbinden. Sonst natürlich nur 24.

Ja, es müssen nicht alle 4.0 sein. Aber wenn man den Grafikkarten- und den ersten m.2 Slot nur mit 3.0 anbinden würde, werden sehr viele Kunden unzufrieden sein. Wenn man dann nur bei den übrigen 4 Lanes reduziert, wird das nicht viel Geld einsparen.

[basix]

Ich kann mir beim besten Willen nicht vorstellen, dass AMD das IOD ändert. Ich denke eher, dass die Chiplets miteinander verbunden werden und einen großen, virtuellen L3$ schaffen, den AMD IF$ nennen wird.

Das ist auch die Richtung, in die ich spekuliere. Insgesamt tendiert das dann in Richtung "Super-CCD", wo 1-6x CCD miteinander verschaltet werden können. 6 wäre das Maximum bei EPYC.

Der grosse Vorteil davon ist, dass man bestehende Siliziumfläche besser ausnutzt. In Zeiten von
immer teurer werdenden Nodes sehr vorteilhaft. Insbesondere Milan-X ist eigentlich recht verschwenderisch mit Cache.

[HOT]

Afaik sind es jeweils nur 12 "freie" lanes, wenn man die x4 für den CPU uplink abzieht. AMD spricht bei x570 zwar auch manchmal von 16x lanes, aber eben nur 12x "flexible" - die letzten vier sind shared mit sata, außerdem werden dort die LAN Chips angebunden.
Aber in der Tat hat der B650 nur x8 nach 4.0 Standard, die anderen sind 3.0, hat also weniger Gesamtbandbreite als x570 mit 12x freien 4.0 lanes.
Allerdings hat bei AM5 die CPU 4x Lanes mehr und zwar sogar nach 5.0 Standard. In der Plattformübersicht bietet der B650 also gleichviel bzw. der B650E mehr.

Bandbreitentechnisch liefert AM5 + B650 also etwas mehr als ein x570 board, wenn man mal von den fehlenden SATA-Ports absieht. Es ist also verständlich dass die Platinen ähnlich aufwändig und teuer sind, wenn nicht sogar etwas teurer wenn es sich um die B650E Variante mit Gen5 handelt.

Sag ich ja. Der X670 bietet 12 4.0 Lanes und 4 3.0 Lanes, die die beim ersten P21 noch SATA sind, sind beim 2. PCIE3. Also 12 für m.2 und Ports, der Rest für Geräte im Prinzip. Ist bei beiden Chipsätzen ähnlich. Der B650 ist ähnlch zum B550, die Plattform bietet nur eben einen m.2 mehr.

[latiose88]

@windi was ist mit AMD P22 ist das eine CPU von AMD die so heißt oder was anderes?
Ich kann namlich nix damit anfangen.


@basix
Achja das mit den super ccd, naja wäre gewiss ne steigerung aber viel zu dem jetzigen würde sich dennoch nicht mehr dran ändern.
Es sei denn du meinst alles was mehr als 3 ccd ist dann automatisch epic. 1-3 ist da noch mainstream bis gehobene Mittelklasse so meinst du das verstehe.
Wobei mit je mehr es ccd sind desto mehr steigt jedoch die latenz. Also von 1 zum 2 ccd ist ja schon höher als nur einen montolischen zu verwenden. Bei 3 und 4 steigt es bestimmt auf das doppelte oder so dann an.
L3 was damit könnte diesen Nachteil durchaus ausgleichen, aber halt nicht vollständig.

Aber gilt nur für die wo hohe Bandbreitenbedarf haben.

Für die wo keine hohe RAM, Festplatte oder L3 cachr bedarf haben sähe es aber dann anderst aus. Wie sieht es denn da dann aus. Für die wird es bestimmt auch noch eine Option geben wo die reine rohleistung der cpu entscheidend ist.

Weil wo es dann schon Eindeutigkeit bei 24 kernen gibt, wird es bestimmt auch bei 32 Kerner ebenso eindeutig sein.

Achja wie kann man die Grenze erkennen. Weil smt ist ja nicht sagend ob eine CPU Optimal ausgelastet wird oder nicht. Geht wohl nur wenn man die Anzahl der Kerne für die Software noch weiter reduziert um zu sehen ob es eine Leistung Einbruch gegeben hat. Feste Kerne mit ner bestimmten Anzahl wenn da sich nichts ändern hilft ja nur noch weiter zu reduzieren um ein Limit zu simulieren. Dann erkennt man wo die Grenze ist bis wann es da Ende mit Steigerung wäre. Oder macht sich da wer die Mühe die wäre grenze einer Software zu erkennen und was sagt die vorherige gen über zukünftige cpus dabei aus wie gut eine Software skalieren wird oder nicht?

[davidzo]

Sag ich ja. Der X670 bietet 12 4.0 Lanes und 4 3.0 Lanes, die die beim ersten P21 noch SATA sind, sind beim 2. PCIE3. Also 12 für m.2 und Ports, der Rest für Geräte im Prinzip. Ist bei beiden Chipsätzen ähnlich. Der B650 ist ähnlch zum B550, die Plattform bietet nur eben einen m.2 mehr.
Da ist nix ähnlich zum B650. Der B550 hat kein einziges PCI4.0 Lane und ist auch nur mit halber Bandbreite an die CPU angebunden. X570 und b650(non-e) sind sich viel ähnlicher was die Auslegung der Platine angeht (Layercount, low loss materialien, ggf. sogar retimer, etc).

[w0mbat]

AFAIK sind B650 und X670 beide mit x4 gen4 angebunden.

[Windi]

@windi was ist mit AMD P22 ist das eine CPU von AMD die so heißt oder was anderes?
Ich kann namlich nix damit anfangen.

Der P21 ist der Chip, auf den die Chipsätze B650(e) und X670(e) beruhen.
Der P22 soll dann der Chip für die günstigere B620 Platform sein.

[latiose88]

Achso nun gibt es also da auch noch Unterschridungen mit weniger auststung. Ist wohl dann ein kleinerer Chip. Bin gespannt wie die ganze Ausstattung sein wird und was die unterschiedlichen Hersteller damit so anstellen also was man da so noch herausholen kann.

Denn das entscheidet dann auch welches mainbaord ich in Zukunft kaufen werde und was nicht.

Mir legten doch halt welche nahe wenn ich so viele USB Anschlüsse brauche mir dann kein AMD 620 maimbard zu kaufen mit extra steck karte zu erweitern.
O wohl das ja günstiger ist als nur wegen dem mehr beim mainbaord auszugeben und sonst keine vorteile zu haben.

Weil der A620 ja nur dann 4-6 usb Anschluss hat und wenn man allerdings 10 braucht dann muss man gleich über 100 € mehr ausgeben.
Finde ich halt nicht richtig.
Und das Problem werde ich auch mit Zen 5 dann genauso haben. Die CPU wird nix an der Plattform dran ändern können.

[Complicated]

Ich denke jetzt ist der Zeitpunkt gekommen um zu verstehen, dass die Preise der Mainboards nicht durch AMD bestimmt werden und auch nicht Thema in diesem Thread sind. Auch sind die Kosten der Chipsets egal, da nur ein kleiner Teil der BOM von ASUS, Gigabyte und MSI.

Zen 5 ist jetzt schon Schuld, dass Du kein Mainboard für den von Dir gewünschten Preis, mit der von Dir gewünschten Ausstattung findest - na herzlichen Glückwunsch.

[amdfanuwe]

Ich kann mir beim besten Willen nicht vorstellen, dass AMD das IOD ändert. Ich denke eher, dass die Chiplets miteinander verbunden werden und einen großen, virtuellen L3$ schaffen, den AMD IF$ nennen wird.
Viel zu kompliziert und teuer.
Neues I/O ist ja wohl kein Problem.
Es ist ja das bestreben den Cache von den teuren Nodes weg zu bekommen.
Bei N31 sieht man eigentlich wohin es geht. Der IF$ beschleunigt die Speicherzugriffe, für jedes Speicherinterface ein kleiner IF$. Führt zu höherer Bandbreite des Speichers und ist in einem günstigen Node zu fertigen.
Die kleinen IF$ sind voneinander unabhängig, da muss nichts untereinander synchronisiert werden, und führen dazu das alle Cores, Beschleuniger, GPU etc. auf einen gemeinsamen Kohärenten Cache zugreifen können.
Im teurem Logic Node kann man den Cache verkleinern und hat mehr Platz für Logik.

ZEN4 ist für AM5 das was ZEN1 für AM4 war.
ZEN5 wird Änderungen bringen, wie auch ZEN2 damals alle überraschte mit dem Chipletdesign.

[CrazyIvan]

Für ZEN 5 scheint AMD das Speicherbandbreitenproblem mit IF$ im I/O zu entschärfen. Dadurch können mehr Cores verbaut werden ohne das Speicherinterface zu vergrößern.
[...]
P.S.:
Frage an die Profis: Wieviel IF$ wäre nötig um 2TB für Server abzudecken?
Aber außerhalb von Foren hat man bisher von der Theorie noch nichts gehört, oder? Also Twitterer, Youtuber, WTFTECH und Konsorten, oder habe ich das was verpasst?

Grundsätzlich macht das aber für mich mehr Sinn als ein virtueller Cache über mehrere CCD:
Mit IOD-Cache könnte man die Stern-Topologie beibehalten und müsste die IOD-to-CCD Verbindung lediglich verbreitern. Mit InFo-R sollte das wirtschaftlich darstellbar sein und auch etwas Latenz auf der Leitung reduzieren. Bei virtuellem Inter-CCD-Cache brauchst Du deutlich mehr direkte Verbindungen, oder pro Kanal noch einmal massiv mehr Brandbreite UND einen Höllen-Crossbar/Ring im IOD wegen des ganzen Cross-Talks.
Darüber hinaus kann so sicher schlecht skalierender Cache auf dem CCD reduziert werden, ohne gleich mit SoIC in den Mainstream runter zu müssen - im Vergleich zu InFo-R müsste das immer noch um Größenordnungen teurer sein.

Zu Deiner P.S.-Frage: Da fehlt eine Dimension in der Fragestellung. Wie viel Cache bei einer angenommenen Bandbreite von 1 TByte/s (wie bei N31) wird benötigt, um bei 2 TByte 12 Kanal DDR5 auf eine effektive Bandbreite von x zu kommen. Aber selbst wenn Du mir das X nennst, könnte ich es ehrlich gesagt nicht ohne Recherche zu den diversen IF-Cache-Berechnungen beantworten. ;)

[latiose88]

Zen 5 ist jetzt schon Schuld, dass Du kein Mainboard für den von Dir gewünschten Preis, mit der von Dir gewünschten Ausstattung findest - na herzlichen Glückwunsch.


Na da hast du aber was missverstanden.Wann habe ich denn Zen 5 die Schuld gegeben gehabt.Nur das zu Zen 5 Zeiten ich dann vor der selben Entscheidung stehen werde wie jetzt.Die CPU hat damit keine Schuld,der Sockel also der Untersatz wird sich nicht viel tuen.
Auch der Nachfolger also egal ob A620 oder A720 ,werden wohl die selben Probleme haben.Zu wenig USB Anschlüsse.Die drübere Chipsatz bzw Mainbarod kostet dann gleich das doppelte.ALso kann man sich nur zwischen günstig mit schlechtere Ausstattung oder sau Teuer aber dafür mehr als man eigentlich benötigt weil man dann mehr kriegt als man eigentlich braucht.
Das führt dann wiederum zu mehr Stromverbrauch durch das Mainbaord.
Ist alles nicht Optimal.Und das kommt dabei raus wenn man eigentlich 10 USB Anschlüsse braucht aber nur 4 USB Anschlüsse kriegt.

Man aber dann wegen dem das stärkere nehmen muss um 10 USB Anschlüsse hat.Dafür aber dann mehr PCI Express Anschlüsse und und und ,was man aber nicht benötigt.ALso man hat dann ne höhere idle Verbrauch beim Strom,ne höhere Anschaffungskosten und wenn es ganz blöd läuft sogar mehr Abwärme durch das Mainbaord.

Und das alles nur weil man 6 USB Anschlüsse mehr braucht.Ich finde wenigstens was dazwischen sollte es schon geben.

Und klar Geld kosten spielen auch ne Rolle.Es ist halt leider nicht für jeden Geldbeutel was dabei und auch nicht für jeden Nutzer,der nur eingeschränkte Funktion braucht.Oder sieht du Zen 5 als ganze Plattform etwa.Also ich sehe das nur als CPU,sorry.

Achja interessant wird auch wenn man auf CPU mit Onbaord geht,welche Optionen man da so alles haben wird.Ich weis die GPU wird bei Zen 5 nicht verbessert,muss sie ja auch nicht.

@CrazyIVAN:

Was ist denn dieses InFo-R ,ist das ne Software oder hast das was mit der CPU zu tuen?

[CrazyIvan]

InFo-R ist eine von TSMC stammende Technik, um Chiplets unter einander zu verbinden. Sie ist deutlich fortschrittlicher, aber auch teurer als die bei AMD seit Zen2 zum Einsatz kommende IFoP. Daher zählt sie allgemein zur Kategorie der Advanced Packaging Verfahren - wie eben auch SoIC zum Kontaktieren des L3 bei Zen3D. Sie wird beispielsweise bei den neuesten AMD GPUs auf Navi31 Basis verwendet.
Siehe
https://www.semianalysis.com/p/advanced-packaging-part-2-review
und
https://en.wikichip.org/wiki/amd/infinity_fabric

[amdfanuwe]

InFo-R i...
Scheint aber nicht zu teuer zu sein. D.h. die Vorteile rechtfertigen den Aufpreis und wohl billiger als EMIB bzw. EFOB.


Aber außerhalb von Foren hat man bisher von der Theorie noch nichts gehört, oder? Also Twitterer, Youtuber, WTFTECH und Konsorten, oder habe ich das was verpasst?

Ich denke nicht, dass du was verpasst hast.
Sollte mal meinen Gedanken Twittern, vielleicht wirds dann offiziell als Gerücht gehandelt :-)

Früher war der RAM noch schnell genug, da brauchte man keinen Cache.
Ich hatte damals noch einen 286, da konnte man den Cache auf dem Board durch SRAM aufrüsten.
Mit RDNA3 ist mir klar geworden, dass der IF$ nur für den jeweiligen Speicherkanal zuständig ist. Es werden im Cache von Channel A keine Daten von Channel B auftauchen. Daher keine Synchronitätsprobleme untereinander. Da alle über den IF$ auf den Speicher zugreifen kann es nicht passieren, dass ein Device Daten in den Speicher schreibt und im Cache alte Daten eines anderen Devices stehen. Der IF$ ist immer kohärent zum RAM.

Infinity FanOut Links für schnellen Datenaustausch zwischen Chips scheinen der Durchbruch zu sein nach teurem SI-Interposer und EMIB bzw. EFOB.
Damit ergeben sich neue Möglichkeiten.
Und nicht nur in 2 Dimensionen.
Bei MI300 vermute ich sowas ( oben Originalbild von TSMC):
82780

4 Base Dies, 3 mit je 2 GPU Chiplets und 1 x mit 3 CPU Chiplets.
82781

Ich sehe die Base I/O Dies als Gerüst für AMDs Baukastensystem.
Dadurch kann man einfach beliebige Logik Kombinationen als Accelerator wie MI300 oder als Chip für SP5/SP6 zusammenstellen.

Ersetzt AMD die Base Dies mit GPU durch Base DIEs mit CPU haben wir eine 96 Core CPU mit 128GB HBM.
Falls nicht eh schon vorhanden, ist auf den Base Dies genügend Platz für ein 12 Kanal Speicherinterface, alles Kompatibel zum Genoa Sockel.

2 Base Dies würden gut zu Siena passen.

Natürlich ist das nicht ganz billig, es werden daher auch noch Lösungen nach herkömmlichen Schema kommen.
Es kommt halt darauf an, welche Leistung man haben will bzw. braucht.

P.S.:
Ein Base Die käme nach meiner Rechnung auf 8 IF-Links für Logik, 56 PCIe, 3 DDR5 Channel, optional 2 HBM Interfaces.

Wäre interessant für eine HEDT Lösung.

OK, mal abwarten, wie Bergamo, Siena und MI300 aussehen werden.

[Zossel]

Aber außerhalb von Foren hat man bisher von der Theorie noch nichts gehört, oder? Also Twitterer, Youtuber, WTFTECH und Konsorten, oder habe ich das was verpasst?

Was macht "Twitterer, Youtuber, WTFTECH und Konsorten" glaubwürdiger?

[Zossel]

Ich hatte damals noch einen 286, da konnte man den Cache auf dem Board durch SRAM aufrüsten.

CPU-Cache kam erst später, >= 486.
IMHO gab es für 286'er noch RAM-Erweiterungen als ISA-Karte.

[HOT]

Viel zu kompliziert und teuer.
Neues I/O ist ja wohl kein Problem.
Es ist ja das bestreben den Cache von den teuren Nodes weg zu bekommen.
Bei N31 sieht man eigentlich wohin es geht. Der IF$ beschleunigt die Speicherzugriffe, für jedes Speicherinterface ein kleiner IF$. Führt zu höherer Bandbreite des Speichers und ist in einem günstigen Node zu fertigen.
Die kleinen IF$ sind voneinander unabhängig, da muss nichts untereinander synchronisiert werden, und führen dazu das alle Cores, Beschleuniger, GPU etc. auf einen gemeinsamen Kohärenten Cache zugreifen können.
Im teurem Logic Node kann man den Cache verkleinern und hat mehr Platz für Logik.

ZEN4 ist für AM5 das was ZEN1 für AM4 war.
ZEN5 wird Änderungen bringen, wie auch ZEN2 damals alle überraschte mit dem Chipletdesign.

Da liegst du glaub ich einfach komplett daneben. Es ist ja schon klar, dass man mehr Links pro CCD braucht für die nächste Servergeneration, genau darauf sollte man sich auch im Desktop konzentrieren, nicht auf solche Luftschlösser. Die werden die Anordnung auf dem Package ändern und die beiden CCDs miteinander verbinden und das Ganze mit dem jetzigen IOD kombinieren. Das ist ne super einfache Lösung, wenn man die CCDs und deren Firmware ja eh entsprechend anpasst für andere Märkte. Und das wird durchschlagend sein, weil das die CCX-Problematik entschärft, die seit Anfang der Zen-Ära besteht.

Ein neues IOD wird aber sehr sicher bei Zen6 kommen (und hier kommt mMn auch das Stacking ins Spiel), denn AMD wird ja offenbar ab Zen6 CXL-Memory unterstützen. Und genau da sehe ich auch den Knackpunkt für AM5 und ich denke sogar, dass AM5 hier wieder enden wird.

[amdfanuwe]

CPU-Cache kam erst später, >= 486.
IMHO gab es für 286'er noch RAM-Erweiterungen als ISA-Karte.
Nagel mich nicht fest, war ein 286 oder 386 Board bei dem ich auf dem Board ein paar SRAM Chips als Cache einstecken konnte.

[Complicated]

Ein neues IOD wird aber sehr sicher bei Zen6 kommen (und hier kommt mMn auch das Stacking ins Spiel), denn AMD wird ja offenbar ab Zen6 CXL-Memory unterstützen. Und genau da sehe ich auch den Knackpunkt für AM5 und ich denke sogar, dass AM5 hier wieder enden wird.
Das ist schon integriert in Epyc 4th Gen:
0c8yLr0Ixco

[robbitop]

Nagel mich nicht fest, war ein 286 oder 386 Board bei dem ich auf dem Board ein paar SRAM Chips als Cache einstecken konnte.
Ich glaube Zossel meint L1 Cache der auf der CPU ist. Externen SRAM auf Mainboards (als steckbare Dimms) gab es schon eher.

[Zossel]

Ich glaube Zossel meint L1 Cache der auf der CPU ist. Externen SRAM auf Mainboards (als steckbare Dimms) gab es schon eher.

DIMMs != SRAM.

Und früher war DRAM in DIL-Gehäusen üblich.
RAM in DIL-Gehäusen ist/war nicht zwingend SRAM.
Und an die frühen Businterface konnte man auch SRAM anschliessen, war sogar einfacher, allerdings war das kein Cache.

Hier mal was was in die Richtung geht, allerdings mit ECB-Bus: https://www.ndr-nkc.de/compo/memory/index.htm

[davidzo]

Cache on a Stick (COAST) mit SRAM auf einem steckbaren PCB unmittelbar neben dem CPU-Sockel gab es schon für Motorola Macintoshs, aber auch auf vielen Sockel3, 4, 5 und 7 motherboards. Der Cache-Slot ist der Vorgänger von Slot 1, bei dem man dann man einfach noch eine CPU mit auf den Cache stick geschoben hat.

Wenn man so will hatten wir schon mit dem damaligen Pentium II und III (Katmai) und dem späteren AMD Athlon (argon, pluto, orion) Prozessoren mit CPU-Chiplet und externem Cache. In diesem Falle L2 Cache mit meist 512KiB. Nur war der SRAM eben nicht im selben Package, sondern lediglich auf der gleichen CPU Platine. Mit Kernfrequenz konnte man den also nicht betreiben.

Der pentium Pro dürfte dagegen als echte Chiplet-CPU mit einzelnem CPU- und Cache DIE auf einem Package durchgehen. Das riesige Keramik Package war damals extrem teuer und noch heute sind die CPUs wegen des hohen Goldanteils gesucht. Für den Massenmarkt war das zu teuer, also kam der Slot1 und bekam einen Teiler für den Cachetakt.

[amdfanuwe]

Da liegst du glaub ich einfach komplett daneben.
Dito

Es ist ja schon klar, dass man mehr Links pro CCD braucht für die nächste Servergeneration, genau darauf sollte man sich auch im Desktop konzentrieren, nicht auf solche Luftschlösser. Die werden die Anordnung auf dem Package ändern und die beiden CCDs miteinander verbinden und das Ganze mit dem jetzigen IOD kombinieren. Das ist ne super einfache Lösung,...
Und ein CCD für Server bekommt 13 Links, damit man alle miteinander verbinden kann?
Oder ein Ringbus über alle CCDs?
Da baust du ganz schöne Luftschlösser.

Xilinx Programmable Network on Chip in die I/O Dies und die Chiplets mit 1-4 Links angebunden, je nach Bandbreitenbedarf.

.

Ein neues IOD wird aber sehr sicher bei Zen6 kommen (und hier kommt mMn auch das Stacking ins Spiel), denn AMD wird ja offenbar ab Zen6 CXL-Memory unterstützen. Und genau da sehe ich auch den Knackpunkt für AM5 und ich denke sogar, dass AM5 hier wieder enden wird.
Würfel nicht alles durcheinander.
CXL Memory wird schon mit Genoa unterstützt und arbeitet über PCIe.
Langsamer als lokaler DDR5, schneller als SSD, die auch über PCIe angebunden werden.
Hat nichts mit ZEN Core Architektur zu tun.

Sicher scheint erstmal, dass bei ZEN5 AIE als Beschleuniger dazu kommt.
Wird ja bei Phoenix getestet, wie sich solch eine Einheit im Alltag schlägt.
ZEN6 könnte dahin führen, dass Berechnungen generell in der AIE Engine ausgeführt werden und dadurch der Core entschlackt werden kann. Der braucht dann kein AVX, SSE etc. mehr.
Die Symbiose mit Xilinx dürfte erst mit ZEN6 so richtig durchschlagen.

Ich sehe da keine Zukunft einzelne Cores immer weiter mit Cache und speziellen Beschleunigern, die die halbe Zeit brach liegen oder wie bei Intel gar erst kostenpflichtig aktiviert werden müssen, aufzublasen.
Bei immer kostbarer werdenden Silizium lohnt es sich nur noch Fixed Funktion Beschleuniger einzubauen, die auch überwiegend genutzt werden.

Ich hab mal auf einem Xilinx Zinq, FPGA + ARM Core programmiert.
Funktionen im FPGA implementiert, die das Problem massiv parallel bearbeitet haben. Der ARM Core dient eigentlich nur zur Verwaltung und dem Datenaustausch mit PC.
Man muss sich davon lösen, dass die CPU der Mittelpunkt des PCs ist. Nicht umsonst bezahlt man mehr für die GPU als für die CPU, zumindest Gamer.

[amdfanuwe]

DIMMs != SRAM.

Und früher war DRAM in DIL-Gehäusen üblich.

So früh war es dann doch nicht bei mir.
War in etwa sowas:
82792
Oben rechts der teilbestückte Cache.

[Zossel]

So früh war es dann doch nicht bei mir.
War in etwa sowas:
82792
Oben rechts der teilbestückte Cache.

Vesa Local Bus war nicht die Zeit als 286'er aktuell waren.

[HOT]

Das ist schon integriert in Epyc 4th Gen:
https://youtu.be/0c8yLr0Ixco
Die Rede ist von Consumer-Markt. AMD will diesen Standard in den nächsten Generationen in den Desktop-Markt bringen und AM5 kann das noch nicht.

amdfanuwe
Der bekommt 3 oder 4 Links für ne komplexere Topologie. Und genau das macht es ja so einfach. Beim Server werden die Cluster größer und damit effizienter. Im Desktop fällt dafür dann die CCX-Problematik weitgehend weg, weil man die Latenzen zwischen den CCD drasdisch reduzieren kann und einen virtuellen Gesamtcache erzeugt, den man ja für die Cluster im Server eh schon benötigt. Zusätzlich werden auf einem CCD die L2$s offenbar durchlässig für die anderen Kerne mit einer ähnlichen virtuellen Cache-Technik, was weiterhin Latenzen reduziert.
Alles weitere bleibt wie gehabt, die L3$s sind weiterhin mit X3D bestückbar und man braucht keine weitere Technologie einbauen, außer der Änderung des Packages. Das Ganze bleibt für AM5 100% transparent.

[amdfanuwe]

Vesa Local Bus war nicht die Zeit als 286'er aktuell waren.
War dann wohl ein 386 mit verlöteter CPU als Billigboard. Bekannte freuten sich schon über ihren Pentium. Also 1992/93 rum.
Als armer Student war nicht mehr drin.
Waren noch Zeiten, als sich jedes Jahr die Speicherkapazität, CPU Leistung, Festplattengrößen etc. verdoppelten.

[robbitop]

DIMMs != SRAM.

Und früher war DRAM in DIL-Gehäusen üblich.
RAM in DIL-Gehäusen ist/war nicht zwingend SRAM.
Und an die frühen Businterface konnte man auch SRAM anschliessen, war sogar einfacher, allerdings war das kein Cache.

Hier mal was was in die Richtung geht, allerdings mit ECB-Bus: https://www.ndr-nkc.de/compo/memory/index.htm
Ist doch Banane wie das heißt - darum ging es überhaupt nicht. Der wesentliche Punkt war, dass es schon steckbaren SRAM für Mainboards gab vor dem 486er.

[amdfanuwe]

Die Rede ist von Consumer-Markt. AMD will diesen Standard in den nächsten Generationen in den Desktop-Markt bringen und AM5 kann das noch nicht.

Abgesehen davon, dass das Sache des I/O ist, da wird dann wohl ein neuer fällig, sehe ich nicht wozu das im Consumer Markt gut sein soll.


amdfanuwe ...

Ist ja nur noch ein Jahr.
Lassen wir uns überraschen was AMD letztendlich ausheckt.

[Complicated]

https://www.pcgameshardware.de/CPU-CPU-154106/News/AMD-CXL-in-drei-bis-fuenf-Jahren-auch-in-Desktop-Chips-1406043/
Sowohl AMD als auch Intel arbeiten gemeinsam mit weiteren Herstellern daran. Die Spezifikationen von CXL sind ein offener Standard, der vor allem als Cache zwischen der CPU, Arbeitsspeicher und anderen Beschleunigern wie Grafikkarten genutzt werden soll. Aufgrund des Protokolls ist die eigentliche Implementierung allerdings relativ kompliziert und erfordert entsprechend eine hardwareseitige Implementierung in den Komponenten. Die ersten CXL-fähigen Prozessoren sind AMDs Epyc Genoa und Intels Sapphire Rapids, die das Konzept um PCI-E 5.0 umsetzen.

[robbitop]

War dann wohl ein 386 mit verlöteter CPU als Billigboard. Bekannte freuten sich schon über ihren Pentium. Also 1992/93 rum.
Als armer Student war nicht mehr drin.
Waren noch Zeiten, als sich jedes Jahr die Speicherkapazität, CPU Leistung, Festplattengrößen etc. verdoppelten.
VLB wurde hauptsächlich in 486er Boards verbaut. Es gab auch 386/486 Kombiboards die das hatten. Könnte absolut sein, dass da in dem Board aus Kostengründen nur ein 386 drin steckte, denn 1992/93 waren 486er noch ziemlich teuer. Insbesondere die DX/DX2.

[latiose88]

@amdfanuwe
auf Beitrag 536 bezogen
Oh nein wenn das war ist dann wird das meiner software aber nicht schmecken.
Schon jetzt kann ich fast alle Beschleuniger wie mmx1-4 usw bei dem Videoumwandlungs Programm abschalten ohne das sich was an der Leistung ändert. Scheinbar braucht das programm keine mmx Funktion mehr.

Blöd ist nur das avx1 und avx2 keine Wirkung bei mir hat aber avx512 sehr wohl. Aber nur unter bestimmten Bedingungen sind diese möglich, nicht jedoch wenn man die eine Einstellung dann weg lässt dann hat avx512 keine Wirkung.

Dann bleibt nur noch ein Beschleuniger übrig. Und das hieße ja dann weniger Funktionen bzw Einheiten die beschleunigen könnten. Dann könnte ja die Anwendung sogar langsamer laufen wenn es blöd läuft. Die Software die ich verwende ist von 2018.
Der einzige Beschleuniger der wirklich maßig die Anwendung beschleunigt weil diese sonst super langsam wäre lautet bmi1 und lzcnt das aber nur ganz wenig hilft. Es sind also 2 Beschleuniger wo diese Software richtig abhängig ist. Ob diese Veränderung also der Anwendung juckt oder nicht das wird sich noch zeigen.

Wenn doch nicht ganz egal, dann freut es mich weil dann kommen da vielleicht noch massive Leistung noch auf das ganze zu.

Ich weiß das ist zwar noch hoffen weil h264 ist ja schon zu Tode optimiert aber solche Änderungen könnten wirkliche Wirkung auf diesen codec haben.

[amdfanuwe]

@amdfanuwe
auf Beitrag 536 bezogen
Oh nein wenn das war ist dann wird das meiner software aber nicht schmecken.

Keine Angst.
Man wird noch lange die Funktionen unterstützen. X86 lebt ja von der Kompatibilität.
Nur gbt es dann eben keine speziellen Fixed Function Einheiten für MMX, SSE etc. mehr in Hardware sondern der Code wird dann über die neuen flexiblen Einheiten ausgeführt.
Passiert das nicht eh schon?
wird ja nicht für jede Extension (
AES, AMD-V, AVX, AVX2, AVX512, FMA3, MMX(+), SHA, SSE, SSE2, SSE3, SSE4.1, SSE4.2, SSE4A, SSSE3, x86-64) ein Fixed Funktion Block verbaut sein.

[Zossel]

Ist doch Banane wie das heißt - darum ging es überhaupt nicht. Der wesentliche Punkt war, dass es schon steckbaren SRAM für Mainboards gab vor dem 486er.

SRAM ist nicht zwingend Cache.

Selbst der KIM-1 (ohne irgendwelchen Cache) aus dem Jahr 1976 hatte SRAM (1024×1):

http://www.zimmers.net/anonftp/pub/cbm/schematics/kim-1/kim.gif

[davidzo]

SRAM ist nicht zwingend Cache.

Selbst der KIM-1 (ohne irgendwelchen Cache) aus dem Jahr 1976 hatte SRAM (1024×1):

http://www.zimmers.net/anonftp/pub/cbm/schematics/kim-1/kim.gif

Ist es in den verlinkten Beispielen aber. Sowohl bei den SRAM Module auf dem mainboard beim 386 (meist 64kb), als auch bei dem späteren COAST - Steckkarten (256-512K) handelt es sich um direct mapped Cache.

[latiose88]

@amdfanuwe
Na ist noch nicht, es sei denn bei den ganzen threadripper ist das anderst als bei den ryzen. Aber das sind ja die selben cpus Chips. Der Aufbau ist ja noch nicht so, das kommt ja noch. Du schreibst als ob ich vor und Nachteile von der umstellung dann hätte. Das muss sich ja eh erst noch zeigen ob das so ist oder nicht in Zukunft. Ich werde auch in Zukunft welche finden die die neueren cpus haben wird.
Ich verfolge ein Ziel, will die Software bis an die Grenze bringen. Also will diese Software mit purer cpu leistung richtig pulverisieren. Viel hilft viel. Also mit roher cpu Leistung erschlagen kann man sagen. Wenn die Software nicht besser wird, muss es die CPU um ein vielfaches besser werden. So mein Motto. Bis wie weit ich bei der Software noch gehen kann das wird sich zeigen. Irgendwann wird der codec limitierten und es wird keine mehrleistung durch noch mehr cpu Leistung mehr geben. Auf das wird hingearbeitet.
Wie ich das mache, es wird keine neuere version mehr geben, Einstellung bleiben gleich all die vielen jahre und nur noch die CPU wird besser.

Das wird der Moment kommen. Wenn meine Berechnungen richtig liegen wird das Limit kommen wenn noch weitere 30 % mehrleistung vom 7950x oben drauf gelegt ist.
Warum das durch 2 anstatt ein Video umwandeln Gleichheitig steigt auch bei einem 16 Kerner etwas die Zeit wo es braucht nach oben. Nicht so krass wie bei einem 8 Kerner der die Zeit sich einfach verdoppelt aber immerhin.
Und darum kann ich mir das sehr gut vorstellen.

Ich weis auch das minimale und maximale Einstellung beim videoumwandeln nicht gleich sein können. Das ist Wunsch denken und hat mit der Realität nix mehr an hut.

Zen 5 könnte also sehr gut in die richtige Richtung des Limits kommen. Erst ab da hätte ich dann 40 % mehr leistung zum 5950x. Warten lohnt sich also sehr gut wie es scheint. Mal sehen was es wird.

[amdfanuwe]

Zu Deiner P.S.-Frage: Da fehlt eine Dimension in der Fragestellung. Wie viel Cache bei einer angenommenen Bandbreite von 1 TByte/s (wie bei N31) wird benötigt, um bei 2 TByte 12 Kanal DDR5 auf eine effektive Bandbreite von x zu kommen. Aber selbst wenn Du mir das X nennst, könnte ich es ehrlich gesagt nicht ohne Recherche zu den diversen IF-Cache-Berechnungen beantworten. ;)
OK, sehe das Problem.

Zwar sind die Anforderungen an den Cache für CPU und GPU unterschiedlich, ich würde aber auch mit ~16-32MB pro Kanal rechnen.
Wären dann ~10-20mm² pro Kanal.
Könnte mir gut vorstellen, dass beim Siena I/O damit experimentiert wird.

-------

Bei Siena irritiert mich, dass da von 64 ZEN 4 Cores geredet wird.
Dann müsste Siena 8 ZEN 4 Chiplets und entsprechend mindestens 8 IF-Links haben.
Mal sehen, ob Bergamo dann mit 2 x Siena I/O kommt und somit alle 8 ZEN 4c mit jeweils 2 IF anbinden kann, also 1 IF pro CCX.
Siena hat 96 PCIe Lanes, können 32 Lanes für den Interconnect zwischen den beiden I/O verwendet werden, wie bei MI 250 schon getestet.

[CrazyIvan]

Was macht "Twitterer, Youtuber, WTFTECH und Konsorten" glaubwürdiger?

Das war wirklich überhaupt nicht wertend gemeint und ich glaube auch, dass amdfanuwe das schon so verstanden hat. Der Punkt ist: Wenn einer der prominenteren Twitterer das einmal erwähnt haben sollte, dann besteht zumindest die theoretische Möglichkeit, dass er das aus Unternehmenskreisen erfahren hat.

Dass ich das sowohl als technisch sinnvoll, wie auch für wirtschaftlich darstellbar halte, habe ich ja bereits geschrieben - also keine Gegenrede von meiner Seite.

In meinen Augen klingt das eben auch deutlich einfacher ,als der von HOT propagierte und wohl von IBM implementierte/beschriebene Ansatz eines virtuellen Caches, der physisch auf n CCDs verteilt ist. Ist aber eher der Occam's Messer Ansatz

[CrazyIvan]

Bei Siena irritiert mich, dass da von 64 ZEN 4 Cores geredet wird.
Dann müsste Siena 8 ZEN 4 Chiplets und entsprechend mindestens 8 IF-Links haben.
Mal sehen, ob Bergamo dann mit 2 x Siena I/O kommt und somit alle 8 ZEN 4c mit jeweils 2 IF anbinden kann, also 1 IF pro CCX.
Siena hat 96 PCIe Lanes, können 32 Lanes für den Interconnect zwischen den beiden I/O verwendet werden, wie bei MI 250 schon getestet.
Was genau findest Du jetzt daran nicht schlüssig? Also falls man (leider) bei Bergamo bei IFoP bleiben sollte, dann IMHO genau so. Als Alternative bliebe sonst nur der klassische sIOD, den ich aus verschiedenen Gründen für unwahrscheinlicher hielte.

/edit: Und haben nicht MLID und Konsorten sogar behauptet, dass Siena auf Zen4c basiert?

[amdfanuwe]

/edit: Und haben nicht MLID und Konsorten sogar behauptet, dass Siena auf Zen4c basiert?
Das Zitat kam von mir, nicht von Zossel.

Mich irritiert, dass AMD auf den Folien bei
-Genoa: up to 96 "ZEN 4" Cores
-Siena: up to 64 "ZEN 4" Cores
-Bergamo: up to 128 "ZEN 4c" Cores
angibt.
https://www.computerbase.de/2022-06/amd-epyc-roadmap-genoa-x-siena-als-low-cost-64c-cpu-turin-mit-zen-5/

MLID bei seinem Leak zu Siena 4 CCD und 64 ZEN4c Cores angibt.
https://www.reddit.com/r/AMD_Stock/comments/yeh04b/mlid_amd_siena_zen_4c_full_leak_almost_zen_4_ipc/
Wenn ZEN 4c Chiplets mit 2 IF Links angebunden werden löst sich das auf: Siena I/O hat 8 IF und kann sowohl mit 4 CCD ZEN 4c als auch mit 8 ZEN 4 CCD bestückt werden. Gibt jeweils up to 64 Cores.
Sieht dann aus wie Milan.
Da man weniger ZEN 4c Chiplets für die gleiche Core Anzahl benötigt werden, könnte das etwas günstiger werden.

Dann kommen noch Angaben wie von https://www.semianalysis.com/p/amd-genoa-detailed-architecture-makes
Bergamo is for cloud-native workloads. The IO die and platform are shared with Genoa,
Siena can be thought of as 1/2 of Genoa or Bergamo from memory to core counts.

Das würde aber bedeuten, dass zumindest bei Bergamo die c CCDs nur mit einem IF angebunden sind da der Genoa I/O nur über 12 IF verfügt.

Also, da passt was nicht zusammen.

[OgrEGT]

Das Zitat kam von mir, nicht von Zossel.

Mich irritiert, dass AMD auf den Folien bei
-Genoa: up to 96 "ZEN 4" Cores
-Siena: up to 64 "ZEN 4" Cores
-Bergamo: up to 128 "ZEN 4c" Cores
angibt.
https://www.computerbase.de/2022-06/amd-epyc-roadmap-genoa-x-siena-als-low-cost-64c-cpu-turin-mit-zen-5/

MLID bei seinem Leak zu Siena 4 CCD und 64 ZEN4c Cores angibt.
https://www.reddit.com/r/AMD_Stock/comments/yeh04b/mlid_amd_siena_zen_4c_full_leak_almost_zen_4_ipc/
Wenn ZEN 4c Chiplets mit 2 IF Links angebunden werden löst sich das auf: Siena I/O hat 8 IF und kann sowohl mit 4 CCD ZEN 4c als auch mit 8 ZEN 4 CCD bestückt werden. Gibt jeweils up to 64 Cores.
Sieht dann aus wie Milan.
Da man weniger ZEN 4c Chiplets für die gleiche Core Anzahl benötigt werden, könnte das etwas günstiger werden.

Dann kommen noch Angaben wie von https://www.semianalysis.com/p/amd-genoa-detailed-architecture-makes



Das würde aber bedeuten, dass zumindest bei Bergamo die c CCDs nur mit einem IF angebunden sind da der Genoa I/O nur über 12 IF verfügt.

Also, da passt was nicht zusammen.

Das würde nur passen wenn der Genoa IO 16IF Links hätte von denen 12 bei Genoa und die 16 dann von Bergamo 128c genutzt würden...

[CrazyIvan]

Das Zitat kam von mir, nicht von Zossel.

Oh, Bitte um Entschuldigung, auch an Zossel. Keine Ahnung, wie das passiert ist.

Ja, jetzt habe ich Dich verstanden und würde meinen Senf nach Feierabend dazu geben ;)

[CrazyIvan]

Das würde nur passen wenn der Genoa IO 16IF Links hätte von denen 12 bei Genoa und die 16 dann von Bergamo 128c genutzt würden...

Hat er nicht, das habe ich extra mal mit Locuza erörtert:
82803

[KarlKastor]

Vielleicht ist auf der Slide Zen4 ganz allgemein gemeint. Also für SP6 dann nur 64 Zen4C oder 48 Zen4.
Wäre dann ja quasi halbiert.

[Complicated]

Ich glaube die Auflösung liegt im Narrow Mode der neuen IF:
https://www.servethehome.com/amd-epyc-genoa-gaps-intel-xeon-in-stunning-fashion/3/
https://www.servethehome.com/wp-content/uploads/2022/11/AMD-EPYC-9004-Genoa-Chiplet-Architecture-GMI3-Narrow-and-GMI3-Wide.jpg

https://www.servethehome.com/wp-content/uploads/2022/11/AMD-EPYC-9004-Genoa-Infinity-Fabric-Overview.jpg

[latiose88]

Ui es gibt neuigkeiten von Zen 4 Threadripper.

Achja apropo,mir ist schon aufgefallen habe mal den Aufbau von Zen 3 und Zen 4 angeschaut und die Einheiten bei der CPU sind auch weniger beim Frontend der CPU geworden.
Ich habe mir da den genauen Aufbau angeschaut und Zen 4 sind viel Einfacher schon Aufgebaut.
Scheinbar braucht es neben AVX und so nicht mehr wirklich viele EInheiten. Zen 5 wird also noch einfacher gehalten.Weil scheinbar je einfacher die CPU gehalten wird,desto mehr Platz kann man sparen und desto mehr Transistoren und so kriegt man dann unter.
Scheinbar sind immer mehr Instruktionen doch nicht so gut weil man dann das ganze nicht so gut Füttern kann also die ganze Pipline.
Aber naja kann mir ja egal sein,weil anscheinend machte es der Software von mir nix aus.
Dann stört mich die weitere Änderung auch nicht bei Zen 5.
Nur das man halt nicht beliebig stark den ganzen Aufbau vereinfachen kann.Irgendwann mal wird also eine Ryzen CPU beim Chip wieder wachsen,das ist sehr sicher,weil geht ja nicht anderst.
Auf jedenfall freut es mich ,das man doch noch Optionen hat.

[amdfanuwe]

Vielleicht ist auf der Slide Zen4 ganz allgemein gemeint. Also für SP6 dann nur 64 Zen4C oder 48 Zen4.
Wäre dann ja quasi halbiert.
Wäre ja OK, wenn bei Bergamo auch nur ganz allgemein ZEN4 Cores stände.
Vielleicht auch nur wieder der Praktikant.

Es geht aber um die IF-Links.

Nur wenn ZEN4 auch nur mit einem IF-Link angebunden würde, könnte man bei Bergamo den Genoa I/O verwenden und bei Siena reichten dann 4 IF-Links für 64 ZEN 4c Cores.
Wir wissen aber schon, dass ZEN4c mit halbem Cache arbeitet und dann noch halber Bandbreite?
Denke nicht, dass AMD die Leistung wegen 4 IF-Links nicht nutzt.
Von Milan hat man ja die Erfahrung mit 8 IF-Links, also keine technische Herausforderung.
Dann bleibt nur, dass Siena 8 IF-Links hat.
Dann kann man aber auch 8 ZEN4 Chiplets verbauen.
Also max 64Cores, egal ob ZEN4 oder ZEN4c.

Natürlich unter der Annahme, dass die IF-Links bei ZEN4 und ZEN4c gleich sind und ZEN4c kein anderes Package erfordert.

Dann unterscheidet sich Siena von Milan durch weniger Speicherinterfaces, und weniger PCIe Lanes. Dafür gibt es DDR5.

Nur für Bergamo dürfte sich ein eigener I/O nicht lohnen. Dann bleibt nur, dass AMD zwei Siena I/O für Bergamo nutzt um auf die nötigen Stückzahlen zu kommen. Dann könnte man Genoa aber auch mit 128 ZEN4 Cores ausstatten. Ich denke, das wird aber wegen der TDP nicht geschehen.

Genoa I/O ist die logische Fortsetzung des Milan I/O.
Mehr SI, mehr IF-Links, ein paar kleine Features.
Erst mal der sichere Weg für ein neues Produkt.
Hat sich durch die Hinzunahme von CXL halt etwas verzögert.

Siena I/O nur eine abgespeckte Version?
AMD wäre aber nicht AMD, wenn sie nicht wieder etwas neues ausprobieren.

Da spekuliere ich dann auf IF$ im I/O.
Gibt Bergamo die nötige Bandbreite damit die Cores nicht wegen Bandbreite verhungern und entschärft nebenbei die Problematik der geteilten Caches.
Eben ein globaler, kohärenter Cache. Nach Erfahrungen bei RDNA nun auch für CPU. Und wenn was nicht klappt, bleibt der IF$ abgeschaltet und man hat trotzdem ein Produkt.

Füe ZEN 5 hat man damit dann auch schon mal die Grundlage um den Cache in den Chiplets auf die neue Architektur zu optimieren.

Tik Tok


Und dann hält Lisa dieses Monster von MI300 in die Kamera.
82807
Hab mal 3 Chiplets auf einen Tile kopiert.

Man sieht, wieviel Platz bei SP5 ist.
Bergamo mit 2 x Siena I/O?
Next Step 1/2 Siena I/O + HBM für Next Generation?
Eine weitere Low Cost Platform mit einem MI300 I/O (3x Mem + 56 PCIe)?
2 mal I/O für Siena, 4 mal für Genoa Platform?
Back to the roots, diesmal mit Logik auf den I/O und HBM Option.
82808
Und alles viel schneller.
Später mal High End CPU mit 128 /256c Cores + HBM?

Praktisch mit einem I/O Die später mal alles von Low Cost bis Highest End erschlagen, 3, 6 12 RAM Kanäle, 2, 4, 8 Optionalen HBM, 56, 92, 128, 160(2P) PCIe, skalierender IF$.
CPU, GPU, FPGA, AI, Semicustom Compute Chiplets in beliebiger Kombination mit und ohne 3D Cache.

Günstige Varianten brauchen auch kein Stacking, reicht dann auch IFoP.
Durch das Chiplet Design kostengünstig auch in kleiner Serie.

MI 300 ist da nur der Start, das Gesellenstück. Mit der nächsten Generation und ZEN 5 könnte das richtig in Fahrt kommen.
2026 verdient AMD sich damit eine goldene Nase.

--------
Was sollen die kleinen Chiplets zwischen den HBM Stacks bei MI300?
Da spekuliere ich auf Treiber für die 128 PCIe Lanes.
Je nach Kombination der I/O Chiplets werden PCIe Lanes zur Verbindung untereinander genutzt. On Package benötigt man aber nicht die Treiberleistung. Also die benötigten PCIe Treiber in eigene Chiplets.
Spart Platz in den 4 I/O die über mindestens 224 PCIe/IF-Verbindungen verfügen müssten für 128PCIe Lanes + 96 Verbindungsleitungen untereinander, die ja keine dicken PHYs benötigen.

[amdfanuwe]

Ich glaube die Auflösung liegt im Narrow Mode der neuen IF:

Nicht ganz.
Bei ZEN4c sind 16 Cores zu versorgen, da wird man den Wide Mode benötigen um die gleiche Bandbreite zu haben wie bei den ZEN4 Chiplets im Narrow Mode.

Oder anders herum: ZEN4c per Narrow Mode angebunden würde die Bandbreite pro Core halbieren gegenüber ZEN4 Cores. Dazu noch halber Cache bei ZEN4c.
Ob das dann noch reicht?

[Complicated]

Nun, wenn Zen4c das Designziel im LowPower-Bereich hat, dann reicht bei 1-2 GHz weniger Takt auch die halbe Bandbreite womöglich. Da ist das Powerbudget womöglich der limitierende Faktor, noch vor der Bandbreite.

Edit:
https://www.hardwaretimes.com/128-core-amd-epyc-bergamo-process-spotted-3-1ghz-boost-clock-and-a-tdp-of-360w/
https://aqzrxtxcxr.cloudimg.io/www.hardwaretimes.com/wp-content/uploads/2023/01/Fl5We_iaMAAirjb.jpg?w=772
Interestingly, the Epyc 9754 has a TDP of 360W (same as 96-core Genoa), a considerable envelope for a 128-core processor with a peak boost clock of just 3.1GHz. The thermal design target may be shared with Genoa for compatibility reasons, but the ambient power draw should be slightly lower.

Sind dann doch nur 500 MHz weniger Takt, scheint aber auszureichen-

[davidzo]

Nicht ganz.
Bei ZEN4c sind 16 Cores zu versorgen, da wird man den Wide Mode benötigen um die gleiche Bandbreite zu haben wie bei den ZEN4 Chiplets im Narrow Mode.

Oder anders herum: ZEN4c per Narrow Mode angebunden würde die Bandbreite pro Core halbieren gegenüber ZEN4 Cores. Dazu noch halber Cache bei ZEN4c.
Ob das dann noch reicht?

Ich glaube Zen4c kommt pro Core durchaus mit weniger Bandbreite zurecht, da ja auch die Vektoreinheit deutlich abgespeckt ist (PS5 FPU).
Die volle Bandbreite wird im Moment nur bei reinen Vektorworkloads ausgelastet (AVX2, AVX512). Bei den meisten normalen Integer workloads ist die Speicherbandbreite pro Core nicht das Limit, da würde hingegen eine gesenkte Cache-Latenz helfen, bzw. mehr Takt.

Man sieht das ganz gut am 3990X vs 3995WX. Der 3990 ist in den meisten Workloads schneller obwohl er nur die Hälfte an Memory channels zur Verfügung hat. Die 200mhz baseclock bzw. 100mhz mehr Turboclock dagegen spürt man deutlich. Trotzdem verbraucht der 3995WX trotz identischer TDP von 280Watt in der Praxis im Schnitt mehr als der 3990X.

Wenn Floatingpoint code bisher das einzige war wo die DRAM-Bandbreite voll gebraucht wurde und Zen4c in diesem Bereich hinter Zen2 Niveau zurück fällt (die ps5 FPU ist kaum auf Zen1 niveau), dann wird man in Integer workloads wohl gut damit leben können wenn nur noch 40% der Bandbreite pro Core vorhanden ist gegenüber Genoa.

[latiose88]

hm ich dachte es geht um Zen 5,gehört Zen 4c etwa auch dazu?
Und die Zen4c ist das gegenüber der E Kerne bei Intel.Weis man da denn schon was und könnte Zen 5 auch so ne Mischung aus Zen 4c und Zen 5 sein,so das AMD ja mehr unterbringt als so bisher und wie viel Fläche kostet so ein Zen 4c,etwa die hälfte?
Weil wenn der Takt senken kann und damit auch weniger Bandbreit,kann man es ja im gegenzug auch breiter gestalten.So wie bei den Laptops es der fall ist.Wäre also auch ne Option um mit weniger Temperatur und geringeren Stromverbrauch zu gewährleistung.

Damit würde also AMD den Weg gehen wie bei Apple.Wäre durchaus auch eine Option wie man Zen 5 gestalten könnte.Wäre durchaus interessant wenn das so käme.

@davidzo
Ok interessant das gillt also auch für den L1,L2 und auch bei dem L3 Cache?
Weil ich habe nur sehr wenig AVX512 Arbeit ,weil da kommt nicht so viel an Leistung dabei rum wenn ich das Einschalte.Aber auch nur unter bestimmten Bedingung.Gibt es noch andere Worlaod wo stark der Cache Entscheidend ist also außer AVX?
Weil wenn das das Einzige ist,dann ist das doch sehr wenig wie ich finde.Und wie war das denn früher gewesen weil der Cache von L1,L2 war ja damals mal viel Größer als heute gewesen oder geizten die CPU Hersteller schon immer mit dem Cache also generell?

[Complicated]

Am Ende sind es auch nur +32 (+30%) Kerne gegenüber Bergamo und zeitgleich -20% Takt, bei selber Anbindung.

@davidso
Wie kommst Du auf abgespeckte FPU? Bisher habe ich überall gelesen, dass das selbe Instructionset zur Verfügung steht. nur der L2$ sei halbiert und alles dichter gepackt und daher niedriger beim max. Takt.

[davidzo]

@davidzo
Ok interessant das gillt also auch für den L1,L2 und auch bei dem L3 Cache?

Caches sind in erster Linie für Latenzreduktion verantwortlich. Die Bandbreite ist sekundär und würde auch nicht viel Diesize sparen fürchte ich. Von Zen2 auf Zen3 hat AMD die L3 Bandbreite pro Core halbiert, dafür aber die Größe verdoppelt. Die Hitrate ist dadurch in jedem Fall gestiegen und es gab keine Benchmarks wo zen2 besser war. Die Cache-Bandbreite ist also bei Zen3/4 ausreichend und die Performance wird eher unter der geringeren Hitrate leiden weil der L3 Cache halbiert wird.

Und wie war das denn früher gewesen weil der Cache von L1,L2 war ja damals mal viel Größer als heute gewesen oder geizten die CPU Hersteller schon immer mit dem Cache also generell?
Nein, eigentlich hat sich an der L1 cachegröße die letzten 20 Jahre nicht viel getan. Es gab schon immer architekturen mit nur kleinen 16kb caches oder größeren 64 oder 128kb L1s. Aber die Set size und Assoziativität hat sich meist stark verbessert, was der Energieffizienz und Auslastung zugute kommt. Der 256kb L2 Cache von Skylake ist zwar gleichgroß wie der vom Thunderbird Athlon K7 20 Jahre früher, aber wird viel effizienter verwaltet und hat eine vielfach größere hitrate und Bandbreite als selbst die 512bit großen barton oder 1mb großen Clawhammer L2 caches.
Außerdem muss ein cache mittlerweile viel höher takten und das erfordert ein anderes Design. Es wäre doch ärgerlich, wenn die Cores zum Beispiel 6Ghz mitmachen würden, der Cache aber bei 4,5Ghz schluss macht und man die CPU deshalb so ausliefern muss. Tigerlake/Willow Cove zum Beispiel hatte auch schon einen 1280kb L2 Cache genau wie Alderlake, ließ sich aber schlechter takten, weshalb Alderlake ein neues Cache Design mit brachte.


@davidso
Wie kommst Du auf abgespeckte FPU? Bisher habe ich überall gelesen, dass das selbe Instructionset zur Verfügung steht. nur der L2$ sei halbiert und alles dichter gepackt und daher niedriger beim max. Takt.
Die PS5 hat ja auch dasselbe Instructionset, nur brauchen viele Instructions halt 2 oder 4 cycles statt einem.

Es gab doch irgendwelche Gerüchte zur Bergamo FPU, oder verwechsle ich das gerade mit Mendocino der ja auch eine ps5 FPU haben soll?

[amdfanuwe]

Am Ende sind es auch nur +32 (+30%) Kerne gegenüber Bergamo und zeitgleich -20% Takt, bei selber Anbindung.

@davidso
Wie kommst Du auf abgespeckte FPU? Bisher habe ich überall gelesen, dass das selbe Instructionset zur Verfügung steht. nur der L2$ sei halbiert und alles dichter gepackt und daher niedriger beim max. Takt.
OK, könnte also reichen ein ZEN 4c Chiplet nur über einen IF-Link anzubinden.

abgespeckte FPU war hier mal ne Spekulation wie AMD ZEN4c kleiner bekommen könnte.

[CrazyIvan]

@davidzo
Sowohl bei Mendocino als auch Vor allem bei Zen4c ist das IMHO educated guessing - macht Sinn, aber so richtige Gerüchte aus dem Dunstkreis gab es IIRC nicht.

[amdfanuwe]

als so bisher und wie viel Fläche kostet so ein Zen 4c,etwa die hälfte?
...
Damit würde also AMD den Weg gehen wie bei Apple.Wäre durchaus auch eine Option wie man Zen 5 gestalten könnte.Wäre durchaus interessant wenn das so käme.
...

ZEN 4c soll halb so groß sein wie ZEN 4.
---
Ich warte eigentlich auch darauf, dass ein 24 Core Desktop CPU mit 8 Core 3d chiplet + 16 Core ZEN 4c vorgestellt wird.
Einfach weil AMD es könnte.
---

Du solltest dir darüber klar werden, wie ein Cache funktioniert.
Cache bringt nur etwas, wenn oft auf die gleichen Daten zugegriffen wird.
Also dauernde Tabellenzugriffe, Programmschleifen, sortieren...
Geht halt schnell, wenn die Tabelle, der Programmcode in den Cache passt.

Wenn Daten nur gelesen, etwas bearbeitet werden und das Ergebnis landet im RAM weil es für die weitere Bearbeitung nicht benötigt wird, bringt Cache kaum etwas.
Bei Daten die nicht in den Cache passen, werden diese in den RAM geschrieben und müssen bei Bedarf wieder aus dem RAM geladen werden.
Man kann seinen Programmcode ordentlich beschleunigen, wenn man solche Dinge beachtet.

Also z.B. nicht wild in einer großen Tabelle hin und her springen sondern eher in kleineren Stücken, die in den Cache passen, bearbeiten.
Man darf auch nicht vergessen, dass bei einem Datenzugriff immer eine komplette Cacheline (64 Byte) geladen wird. Ist also egal, ob nur 1 Bit oder 64 Byte bearbeitet werden.
Bei entsprechender Datenstruktur kann man die Lese- Schreibzugriffe also erheblich verringern.

[robbitop]

Ich glaube Zen4c kommt pro Core durchaus mit weniger Bandbreite zurecht, da ja auch die Vektoreinheit deutlich abgespeckt ist (PS5 FPU).
Ist das irgendwo bestätigt? IIRC war das nur ein vages Gerücht und dann gab es auch wieder Gerüchte es ist ein voller Zen 4 core nur mit weniger L3 Cache und mit higher density layuouting weil weniger Takt.

edit: wurde schon gefragt und keiner weiß was Genaues. :D

[latiose88]

@amdfanuwe
Ja gut scheine ich da wohl echt meine Probleme zu haben.Zen4c wird also kleiner beim Cache werden.Bei Zen 5 weis man ja nur das der L2 Cache kleiner wird.
Aber nur wie erkennt man nun das sich alles im Cache befindet und wann nicht?

Ich weis nur das beim 5700g mit 2 MB L3 vs 5800X mit 4MB je Core ein Leistungsunterschied gegeben hatte.
L3 Cache scheint also ab einer bestimmten größe doch ne Rolle zu spielen.

Achja sowas hier: Programmschleifen, sortieren ,macht doch auch so ein Codec wie H264 nur in kleinen Maßen. Wobei wenn man 2x das selbe Programm gleichzeitig startet und arbeiten lässt,geht das mit sicherheit nicht mehr alles in den Cache rein.Darum steigt auch von 1 auf zwei Programme(die selben) auch der Rambedarf von 100 auf 200MB.
Eines ist sicher 100MB passen nicht in den CPU Cache rein,weil dieser ja zu groß ist.Festplatten Zugriff wird bestimmt auch vom Prozessor zur Festplatte der Fall sein,wenn auch mit rund 64 Mb ebenso viel zu klein ist.Der Rest geht von Windows drauf.Am ende wird nur eine HDD mit 150MB/S belastet obwohl ne SSD ja schneller ist.
Das wundert mich aber doch sehr bei 2 Anwendung.Das würde ja 120 MB für 2 Programme heißen also 60 MB pro Programm.Das passt ebenso in keinem Einzigen CPU Cache rein.Also wird mit sicherheit ausgelagert.Es spielt also keine Rolle wie groß der CPU Cache ist,weil wenn zu klein,wird dieser ja eben nicht verwendet.

Bin gespannt wie Zen 5 das Problem lösen will,aber wenn ich schon was von L2 cache wird kleiner lese,habe ich da so meine Zweifel.
Wobei der L3 Cache ja alle Kerne gleichzeitig drauf zugreifen können.Bei L1 und L2 Cache hat jeder Kern so seinen feste Cache zur Verfügung.

Nun ich hoffe zumindest das die Verkleinerung nicht zu Leistungverluste führt bei Zen 5.

[Zossel]

Nein, eigentlich hat sich an der L1 cachegröße die letzten 20 Jahre nicht viel getan. Es gab schon immer architekturen mit nur kleinen 16kb caches oder größeren 64 oder 128kb L1s.
Ich biete einen 6 Byte großen Cache:
"Loop mode" which accelerates loops consisting of only two instructions, such as a MOVE and a DBRA. The two-instruction mini-loop opcodes are prefetched and held in the 6-byte instruction cache while subsequent memory read/write cycles are only needed for the data operands for the duration of the loop. It provided for performance improvements averaging 50%, as a result of the elimination of instruction opcodes fetching during the loop.
https://en.wikipedia.org/wiki/Motorola_68010

[basix]

Meldung von PCGH, dass Ryzen 8000 noch dieses Jahr erscheinen wird. Zen 4 Refresh oder Zen 5? Zen 5 halte ich eigentlich für unwahrscheinlich. Aber hiess es nicht Mal, dass Zen 4 wegen einiger CXL Features ein paar Monate nach hinten geschoben wurde? Das würde Zen 5 evtl. zulassen (+18 Monate zwischen Zen 4 & 5 in der "originalen" Planung). Zen 5 erwarte ich zudem eh in N4 und nicht N3(E).

https://www.pcgameshardware.de/CPU-CPU-154106/News/AMD-Ryzen-8000-Neue-Generation-Release-Gigabyte-1416232/

[robbitop]

Man darf nicht vergessen dass Zen 4 sich angeblich deutlich verzögert hatte. Ursprünglich sollte der angeblich Q1 2022 kommen. Wenn man annimmt dass Zen 5 aber keine Verspätung hatte, könnten theoretisch schon zeitlich enger als sonst zwei uArchs hintereinander kommen.

[Linmoum]

Zen5 ist offiziell auf jeder Roadmap für 2024 angekündigt. Da kommt nicht plötzlich noch dieses Jahr irgendwas. Entweder irgendein XT-Refresh (unwahrscheinlich, sowas braucht keinen riesigen Vorlauf und irgendwelche Kommunikation gegenüber Boardpartnern) oder Desktop-APUs. Zu 99% wahrscheinlich letzteres.

[robbitop]

Auf den Roadmaps sind grafisch Zen 5 links von 2024 angeordnet. Links ist die Vergangenheit. Ich würde sagen zumindest in der Grafik ist es weniger als eindeutig.

[Ramius]

Meldung von PCGH, dass Ryzen 8000 noch dieses Jahr erscheinen wird. Zen 4 Refresh oder Zen 5? Zen 5 halte ich eigentlich für unwahrscheinlich. Aber hiess es nicht Mal, dass Zen 4 wegen einiger CXL Features ein paar Monate nach hinten geschoben wurde? Das würde Zen 5 evtl. zulassen (+18 Monate zwischen Zen 4 & 5 in der "originalen" Planung). Zen 5 erwarte ich zudem eh in N4 und nicht N3(E).

https://www.pcgameshardware.de/CPU-CPU-154106/News/AMD-Ryzen-8000-Neue-Generation-Release-Gigabyte-1416232/

Da dürfte es sich doch am ehesten um Zen4c handeln.
Zen5 erwarte ich keinesfalls so früh.

[amdfanuwe]

Auf den Roadmaps sind grafisch Zen 5 links von 2024 angeordnet. Links ist die Vergangenheit. Ich würde sagen zumindest in der Grafik ist es weniger als eindeutig.
Das hatten wir doch schon ein paar mal. Die grafische Anordnung besagt gar nichts. Wenn AMD ZEN5 am 31.12.2024 vorstellt, ist die Roadmap erfüllt.
Mehr lässt sich da nicht ablesen.

[basix]

Das hatten wir doch schon ein paar mal. Die grafische Anordnung besagt gar nichts. Wenn AMD ZEN5 am 31.12.2024 vorstellt, ist die Roadmap erfüllt.
Mehr lässt sich da nicht ablesen.
Jop.

[...] Desktop-APUs. Zu 99% wahrscheinlich letzteres.
Guter Punkt

[ryan]

Das hatten wir doch schon ein paar mal. Die grafische Anordnung besagt gar nichts. Wenn AMD ZEN5 am 31.12.2024 vorstellt, ist die Roadmap erfüllt.
Mehr lässt sich da nicht ablesen.


Wäre Zen 5 wirklich für 2023 vorgesehen, hätten sie es eindeutig angeordnet. Haben sie nicht, weil erst 2024 möglich ist. Und überhaupt wüsste man es, hätte Andeutungen bekommen usw. Wir sind fast im April und es gibt von AMD nicht den leisesten Hinweis auf Zen 5 in diesem Jahr, von den üblichen Leakern auch nichts. Zen 5 dieses Jahr kannst du vergessen.

[amdfanuwe]

Wäre Zen 5 wirklich für 2023 vorgesehen, hätten sie es eindeutig angeordnet. Haben sie nicht, weil erst 2024 möglich ist. Und überhaupt wüsste man es, hätte Andeutungen bekommen usw. Wir sind fast im April und es gibt von AMD nicht den leisesten Hinweis auf Zen 5 in diesem Jahr, von den üblichen Leakern auch nichts. Zen 5 dieses Jahr kannst du vergessen.
Les nochmal, was ich geschrieben hab : Wenn AMD ZEN5 am 31.12.2024 ...

[Linmoum]

Auf den Roadmaps sind grafisch Zen 5 links von 2024 angeordnet. Links ist die Vergangenheit. Ich würde sagen zumindest in der Grafik ist es weniger als eindeutig.Dann nimm halt das hier:

https://images.anandtech.com/doci/17439/Zen5_678x452.jpg

Zen5 kommt erst nächstes Jahr. Was auch immer Gigabyte damit meinen will, das ist es nicht.

[ryan]

Les nochmal, was ich geschrieben hab : Wenn AMD ZEN5 am 31.12.2024 ...


Muss ich nicht, ist schon richtig so was ich schreibe. Es wird 2024 angegeben, weil Zen 5 eben erst 2024 kommt. Das ist schon Absicht von AMD.

[amdfanuwe]

Muss ich nicht, ist schon richtig so was ich schreibe. Es wird 2024 angegeben, weil Zen 5 eben erst 2024 kommt. Das ist schon Absicht von AMD.
Dann hatte ich deine Antwort auf mein Zitat wohl missverstanden.

[latiose88]

hm das sind also die Verbesserungen bei Zen 5,liest sich irgendwie wenig.Mehr befehle pro Sekunde ist ja aber zumindest besser als nix.Frond End ist sowas wie AVX,das wo halt mir nicht so viel Bringt.Ai und Maschine Lerning ist wohl für mehr Professionelle Programme gedacht.Da werde ich auch nicht wirklich davon Profitieren.Bleibt also nur das mit mehr Befehle pro Takt übrig.Das wird und da weis ich jetzt schon keine 20 % mehr Leistung bei mir sein gegenüber Zen 4.So viel zu richtig aufgemotzt.ALso ich sehe da nur höchstens 5% mehr Leistung zukommen.Sofern sich denn der CPU Takt nicht Massiv weiter nach oben geht.Bei Zen 4 war schon bei 5,1 ghz schluss gewesen.Also wenn da mehr als das rauskommen sollte,dann sollte da Allcore 5,5 ghz schon sein oder mehr.Dann sehe ich da 10 % da stehen.Allerdings will ich nicht das die CPU noch mehr als 200 Watt an Strom frisst,also kann man es schon mal vergessen.
Es sei denn AMD gelingt ein Kunststück,was ich eher wohl bezweifle.

Ich hoffe das dies ein Fake ist,weil ich kann es nicht glauben oder ich Erwarte da einfach zu viel von einer neuen Archetektur. Und wenn Zen 5 auch nicht viel bringt dann warte ich halt länger.Unter 40 % will ich nicht gegenüber dem Ryzen 9 5950x aufrüsten.Soll sich ja lohnen und weil halt 1300 € viel Geld ist.Das muss sich erst mal lohnen.Und vorallem nur wegen einer neuen CPU erst recht.

Vorallem Ram und PCI Express Profitiere ich schon mal kaum gegenüber aktuelles.Vielleicht gleich viele USB Anschlüsse aber nicht von mehr Sata Anschlüssen.Mainbaord habe ich also jetzt auch schon wenn ich wechseln würde 0 Gewinn.Dann bleibt am Ende nur die reine CPU Mehrleistung und dank Onbard GPU auch das Weglassen von Dedizierten GPU übrig.
Ich bleibe also auf einen gewissen Level einer GPU seid Jahren.Kein Raytracing und Full HD als Maximum .Habe also nicht vor in einer höheren Auflösung zu wechseln.
Wegen nur rein auf die CPU scheiterte es auch schon bei den Threadripper CPU schon.Und warum weil ich mich nur für die reine Leistung der CPU interessiert hätte.Aber aufgrund der geringen gesammt Vorteile ich es gelassen hatte.

So ist das halt wenn man nur Videoumwandeln als höchten Anspruch fest macht.Nur ein Workload das sehr speziell nur an bestimmten EInheiten interessiert ist.Aber klar mache ich nicht Tag und Nacht nur sowas. Der Gewinn von 5950x zu 7950x war schon mal mit 20 %(15% bei nur 142 Watt) schon mal ganz ok.Mag zwar sein das es von Zen 2 auf Zen 3 auch nur 13% mehrleistung war,aber insgesammt von einer anderen Plattform waren es 28% Mehrleistung gewesen.
Da muss also Zen 5 noch eine schippe oben drauf legen,weil so liest es sich einfach zu wenig.Und ja ich kann so hohe Ansprüche auch haben,das es sich wirklich lohnt.Ich habe jedoch kein Problem damit.Wenn ich also weiter warte,dann kann ich auf Zen 6 mit ddr6 drauf setzen.Habe zwar nach wie vor kein richtigen Mehrwert beim ram,laut berechnung hat ddr4 3600 auf ddr5 5200 bei mir 2-3 % Gewinn gebracht und von 5200 auf 6000 0% mehrleistung.
DDR6 wird da noch mehr drauf hauen.Dann kann ich wenigstens den kleinsten mit den besten Timings nehmen was es so gibt.Spare ich mir halt in Zukunft weiter Geld.

Sollte also da dann 16 Gb als unterste Standard werden,ist dieser dann auch dann Teuer.Oder 2x8 gb werden dann besser beim Preis sein.Ich brauche halt nach wie vor sehr wenig Ram.
Wenn ich bedenke wie viel hier mit 32 und 64 Gb herum laufen oder auf anderen Plattformen.Dann ist mein Anspruch es super niedrig.
Dafür kann ich dann halt wenn ich schon beim Ram und Mainbaord Ordentlich sparen kann,dann so richtig bei CPU mehr ausgeben,auch nicht schlecht.Mal sehen was für Vorteile ich noch so habe,außer auf die Onbaord GPU zu setzen.Ich sehe halt sonst leider keine Vorteile mehr,echt schade.

[Hypadaiper]

@Latiose88
Deine Texte sind wahnsinnig schwer zu lesen. Keine Interpunktion, keine Gliederung..Das wirkt eher als würde man in deinen Kopf blicken und den Gedanken beim ordnen zugucken.
Wenn man es aber dann geschafft hat sich durch deinen Text zu arbeiten, bereut man es am Ende dann doch. Was du dir manchmal für ein Zeug aus den Haaren ziehst. Du bewertest Zen5 ernsthaft daran, was auf einer Folie als Entwicklungsschwerpunkte genannt wird ? Die fantasierst dir da Prozentwerte zusammen die einfach gar keinen Sinn geben.

Ich will dich nicht verletzen oder dich im schlechten Licht darstellen lassen. Nicht jeder ist gleich tief in der Materie und ich komm mir oft selber dumm genug vor, wenn hier der ein oder andere mal einen DeepDive in bestimmte Themenbereiche gibt.
Wenn du dann mal nach technischen Erklärung fragst, zeigst du ja auch ein Interesse daran es zu verstehen. Da machen dich Texte wie der oben aber mega unglaubwürdig und lassen massiv an deiner Reife zweifeln.

Sorry, Sonntagsmorgen-Rant. Aber nach jetzt mehrtägigen Konsum deiner Posts musste das mal raus.

[robbitop]

Dann nimm halt das hier:

https://images.anandtech.com/doci/17439/Zen5_678x452.jpg

Zen5 kommt erst nächstes Jahr. Was auch immer Gigabyte damit meinen will, das ist es nicht.
Das ist eindeutig. Danke :up:

Um es klarzustellen glaube ich selbst auch nicht an Zen 5 in 23 aber die grafische Roadmap war uneindeutig. :)

[HOT]

Also es gäbe aus meiner Sicht nur eine einzige Option, wie das zustande kommen könnte, dass Zen5 noch dieses Jahr launchen würde:
1.) Der Launch wäre eh direkt Anfang 2024 geplant gewesen
2.) Die Rev.B0 ist so gut, dass man keine weiteren Metalspins benötigt
3.) AMD möchte Zen4 so schnell wie möglich ersetzen

In dem Falle könnte man den Launch auch so früh wie möglich machen und das ursprünglich geplante Lauchfenster minimal vorziehen.
Also: Sag niemals nie, aber das Ganze ist dennoch extrem unwahrscheinlich, weil die meisten ernsthaften Beobachter den Launch für frühestens Mitte Q2 2024 erwarten.

Kleiner Hinweis am Rande: Der Launch zum Jahreswechsel 23/24 würde ungefähr zum 5Q-Plan von AMD passen ;).
Nur Zen4 schied da ja aus, weil er noch 2 Metalspins brauchte, bevor er auf den Consumermarkt entlassen wurde.

[Complicated]

Ein witziges Detail: Wenn AMD Zen5 noch dieses Jahr launchen würde, müßten sie (sofern sie sich an ihre eigene neue Nomenklatur halten) die CPU der 7xxx-Serie zuordnen:

https://beebom.com/wp-content/uploads/2022/09/New-naming-scheme.jpg?w=640

The first number will denote the portfolio year. This means a 2023 AMD chip will start with 7, 8 for 2024, and so on.
Dagegen wären ganz sicher alle OEMs und das Marketing. Also meiner Meinung nach würde AMD eher Zen5 nach 2024 verschieben, selbst wenn sie ihn Ende 2023 launchen könnten.

[HOT]

Quark, das ist pures Marketing. Die machen einfach ne 8 nach vorne und fertig.

[Complicated]

Das Marketing hat keinen unerheblichen Einfluß auf den Launchtermin. Und niemand macht einfach etwas so. Ich wundere mich manchmal welche Unkenntnis über Entscheidungsprozesse in Unternehmen herrscht hier im Forum. Das Namensschema ist zentraler Bestandteil der OEM-Offensive bei AMD.

Ich denke wir sind uns einig, dass Zen5 in 2023 kein ernstzunehmendes Gerücht ist, und das aus allen Aspekten heraus.

[Trap]

Ein witziges Detail: Wenn AMD Zen5 noch dieses Jahr launchen würde, müßten sie (sofern sie sich an ihre eigene neue Nomenklatur halten) die CPU der 7xxx-Serie zuordnen
Da steht Model Year, also Modelljahr. Die sind doch völlig beliebig in der Zuordnung zum Kalenderjahr.

[HOT]

Natürlch. Es ist furzegal, ob da noch in 23 7 oder 8 steht, das stört keinen Menschen ;). Daran wird als letztes scheitern.

[amdfanuwe]

Das steht Model Year, also Modelljahr. Die sind doch völlig beliebig in der Zuordnung zum Kalenderjahr.
Nicht ganz.
Ist ja unten eindeutig zum Kalenderjahr zugeordnet.
Sagt jedoch nichts darüber aus, wann im Kalenderjahr die Modelle im Markt erhältlich sind.
Zudem gilt das eigentlich nur für Mobile, wo AMD die letzten Jahre immer zur CES im Januar die neueste APU vorstellte.

Ryzen, Radeon 7000er Serie gehören auch zum Portfolio für 2023, daran kann man sich orientieren. Das ZEN4 X-Varianten und Radeon 7900er schon letztes Jahr vorgestellt wurden, hat da keine große Relevanz. Bis das Portfolio komplett ist dauert es auch noch etwas.

|Serien Jahr|Desk. Serie|Desktop| Server
ZEN1|2017|1000| 04-07.2017|06.2017
ZEN+|2018|2000|04.2018
ZEN2|2019|3000|07-09.2019|08.2019
|2020|3000XT| 07.2020
ZEN3|2021|5000|11.2020-01.2021|03.2021
|2022|5000X3D|04.2022|
ZEN4|2023|7000|09.2022-04.2023|11.2022
ZEN5|2024|||Q2/2024?

Die 4000er hat man im Desktop übersprungen, wahrscheinlich weil man mit ZEN3 zu spät war für das Jahr und diese daher als 5000er Serie für 2021 brachte.
2022 brachten die Kapazitätsengpässe wegen Corona alles durcheinander.
Warhole geisterte durch die Gerüchteküche, letztendlich wurde nur ein 5800X3D sowie ein paar kleinere 5000er Varianten gelauncht.

Man sieht aber, dass Desktop vor Server gelauncht wird.
Ich meine irgendwo gelesen zu haben, Turin ZEN5 Server sei für Q2/2024 geplant. ZEN5 Desktop erwarte ich da in Q1/2024.
Letztendlich aber alles egal, da man eh warten muss bis es im Laden kaufbar ist.

[ilPatrino]

Desktop-APUs. Zu 99% wahrscheinlich letzteres.
für am5 haben die doch standardmäßig igp - denkst du, amd bringt die mobilen monolitischen auch für den desktop?

[bbott]

für am5 haben die doch standardmäßig igp - denkst du, amd bringt die mobilen monolitischen auch für den desktop?
Ja klar für bis 4-8 Kerne und höhere GPU bedarf, auch der Preis wird günstiger.

[mocad_tom]

Bitte richten sie die Aufmerksamkeit auf diese Seite:

https://www.kingston.com/de/memory/search/systemdevices?partid=KSM48E40BD8KM-32HM

Hier hat Kingston kompatible Mainboards für DDR5-4800 UDIMM ECC -Speichermodule aufgeführt.

Und hier ist das ASRock - Server 1U4LW-B650/2L2T
https://asrockrack.com/general/productdetail.asp?Model=1U2S-B650#Specifications

Und damit wird auch mal ganz offiziell damit geworben, dass Ryzen 7000 ECC richtig unterstützt. Das war nämlich nicht so ganz sicher. Einige Board-Hersteller haben sich nämlich mittlerweile dahingehend geäussert, dass man UDIMM ECC einsetzen kann, dass dieser RAM läuft, das ECC Feature an sich aber nicht aktiv genutzt werden kann.

Dann weiter in der Argumentationskette.
Als nächstes wird 48Gbyte UDIMM ECC rauskommen.
Es ist aber relativ schwierig diesen RAM schön anzusprechen.
Ich ärgere mich gerade mit einem Asus WS W680 und 2 Kingston 32GByte ECC Riegel rum.
Ich bekomme bei 1DPC und zwei Riegel eingesteckt nur DDR5-4200 zum Laufen.
Auf einem Supermicro X13SAE bekomme ich DDR5-4400.

Beim Asus WS W680 wenn ich nur einen Riegel einstecke bekomme ich DDR5-4800 (was der Riegel laut Spec auch hergeben sollte).

Nun meine Speku zu den Äusserungen von "Giga Computing":
Die neuen Ryzen 9 7900 / 7950 / 7900X3D / 7950X3D erhalten einen neuen vllt. geshrinkten IO-Die.

Sapphire Rapids hat mit einer Sache überrascht:
Sie haben schnellere ECC RDIMM-Riegel unterstützt - das kam komplett ohne Vorankündigung.

Ein zukünftiger Ryzen 9 7950X3D(nextGen?) könnte 96GByte UDIMM ECC mittels 1DPC bis zu DDR5-5200 unterstützen. (wenn ich dann 2DPC machen muss, dann geht es bei ECC massiv runter).

Dazu wird aber AMD am IO-Die / Memorycontroller Änderungen vornehmen müssen.

Ich sehe, dass Firmen wieder ihre Infrastruktur heimholen und da könnten solche vergleichsweise günstigen Plattformen richtige Goldgruben werden.
Ein Ryzen 9 7950X3D mit V-Cache auf beiden Compute-Die wäre ein Monster für Virtualisierung, weil man den langsameren ECC-Ram massiv entlasten würde.

Es gibt ja auch bei den Software-Lizenzen so ein Bonbon für einen genau 16-Kernigen Prozessor:
Windows Server 2022 Standard ist in der normalen Config für 16 Kerne gemacht.
Zwei Ryzen 9 7950X3D in jeweils zwei eigenen Gehäusen können sehr viel Arbeit verrichten.
Ein EPYC mit der gleichen Rohleistung kostet schnell mal das doppelte (bzw vierfache - ihr wisst was ich meine) (noch dazu wenn man dann die Lizenzkosten mitrechnet).

[latiose88]

@Hypadaiper
Naja ich weis das ich ins Chaos immer drifte.An der Intellegenz scheitert es auch bei mir nicht.Es liegt einfach daran das ich es nicht richtig Fomulieren kann.Ich kann das gedankliche nicht richtig kurz und Bündig schreiben.Es ist wie wenn ich da eine Blockade habe.Ich neige leider auch immer wie wenn ich nen Roman schreibe.Je mehr ich also schreibe desto schlimmer wird es.

Ich kann mich auch anstrengen wie ich will,die Leser erkennen leider nicht das ich mir da Mühe gebe,aber ich kann es eben nicht besser.In der Schule wurde ich auch immer dafür kritisiert.Verstehe also dein Kritik sehr wohl,ändert leider nix an mein Problem.

Und klar meine ich das Ernst,das sind doch Eckpunkte wo AMD auch aufzeigt was so erwartet wird sich zu Ändern bzw zu Verbessern.Ich habe ernsthaft erwartet die Liste sei Länger weil was von Massiver Veränderung geschrieben wurde.Aber dem scheint es wohl nicht zu sein.
Und ich habe eben sehr hohe Erwartungen an Zen 5,alles andere würde mich wohl Entäuschen.
Wenn ich also schon auf AM5 wechsel dann muss die CPU schon ne Ordentliche Leistung haben.
Das ist ja auch das Kernstück einer Plattform,neben dem Mainboard und so.Ich habe nun mal nur begrenzte Mittel an Geld zur Verfügung und muss da vorausschauend Handeln. Und das werde ich auch so machen.

Aber naja mehr als auf Zen 5 zu warten kann ich eh nicht.Die Günstigen Mainbaords kommen erst noch,Ram wird auch noch günstiger werden.Somit ist Zeit diese wo auf meine Seite steht.Ich halte also die Füße Still,lege Geld bei Seite und warte also die Zeit ab.
Genieße es also das sich mein Aufrüst Abstand vergrößert ganz einfach.

[Complicated]

Mein Tipp: Versuche Fragen zu stellen anstatt Zusammenhänge zu beschreiben, wie du sie verstehst. Das hilft dir kürzer zu formulieren und anderen fällt es leichter zu verstehen welche Infos dir fehlen. Falsche Theorien aus Unkenntnis helfen niemandem. (Zähl mal die Anzahl der Fragen deiner letzten 3 Beiträge ;) )

Edit: vermutlich wirst du dann auch feststellen, dass deine persönlichen Wünsche/Enttäuschungen und dein Use case im Kaufberatungsforum den richtigen Input bekommt.

[Zossel]

Ein Ryzen 9 7950X3D mit V-Cache auf beiden Compute-Die wäre ein Monster für Virtualisierung, weil man den langsameren ECC-Ram massiv entlasten würde.

"Schnelles" RAM mit ECC gibt es wahrscheinlich nicht weil man recht schnell merken würden das man Müll gekauft hat.

[davidzo]

Das Marketing hat keinen unerheblichen Einfluß auf den Launchtermin.
Die können den aus tatktischen gründen hinauszögern, aber vorziehen können die den nicht. Den frühstmöglichen Launchzeitpunkt liefert die Produktion und da kann keiner was dran ändern.


Ich denke wir sind uns einig, dass Zen5 in 2023 kein ernstzunehmendes Gerücht ist, und das aus allen Aspekten heraus.

Des Gerücht war ja auch nicht Zen5 zugeordnet. Es hieß lediglich dass da noch neue Prozessoren auf AM5 später im Jahr kommen.
Das wird wohl Phoenix Point für den Desktop sein. Es passt vom Zeitfenster zu den vergangenen APU Launches dass der mindestens ein halbes Jahr nach dem Mobile Launch in den Desktop kommt.

Phoenix ist eine "neuere" Generation als Raphael, da die IGP der RDNA3 µArch zugeordnet wird und ein zusätzlicher XDNA Coprozessor vorhanden ist. Außerdem ist die Fertigung mit N4 moderner, das allein reicht schon um daraus mindestens eiune Refresh Generation zu machen.
Im Gigabyte Leak war ja nur von Neueren Ryzen CPUs die Rede, nicht von schnelleren.

Mit 8 Kernen und starker IGP wäre Phoenix der Counter zu MTL-S gewesen. Vielleicht ist das sogar ein Hinweis darauf dass Intel doch noch irgendeine mainstream CPU im LGA1851 bringt die AMD glaubt countern zu müssen.

[mocad_tom]

@Zossel
>"Schnelles" RAM mit ECC gibt es wahrscheinlich nicht weil man recht
>schnell merken würden das man Müll gekauft hat.

Ich tüftle aktuell mit DDR5 ECC Ram rum für Workstations, bzw. für Server, die ich in unterschiedlichen Umgebungen ablösen will.

DDR5 ist schön für Server, weil Dual-Channel eigentlich bedeutet Quad-Channel.

Gleichzeitig verbietet sich aber dieser ganze OC-Kram bei ECC - trotzdem will aber z.B. das Asus WS W680 den ECC RAM overclocken und ich muss dem Board das zuerst abgewöhnen.
(von der Schachtel raus macht es scheiß)

Gleichzeitig gibt es aber jetzt nach und nach auch neuere offizielle JEDEC-Spezifikationen für ECC. Nur die Memory-Controller weder im Ryzen 9 7900 noch im Core i7 13700K können diese neueren offiziellen ECC Spezifkationen.

Sapphire Rapids wurde davon komplett weggekoppelt - Ryzen und Raptor Lake können unregistered ECC - Sapphire Rapids kann nur Registered ECC.

Wegen des Heimholtrends von Servern in das eigene Rack gibt es wieder Nachfrage nach diesen Kisten.

Schaut mal selber - Samsung Datacenter 4TB NVME / Samsung 870 QVO 8TB / Kingston DDR5 ECC-Ram - das Zeug ist aktuell "Dirt-Cheap".

Gleichzeitig läuft noch eine Gutschein-Aktion für Win Server 2022 Standard - das passt gerade wie Faust auf Auge.

[Complicated]

Die können den aus tatktischen gründen hinauszögern, aber vorziehen können die den nicht.
Was genau das ist, was ich schrieb.
Des Gerücht war ja auch nicht Zen5 zugeordnet. Es hieß lediglich dass da noch neue Prozessoren auf AM5 später im Jahr kommen.
Dies war der Kontext der letzten 2 Seiten:
Auf den Roadmaps sind grafisch Zen 5 links von 2024 angeordnet. Links ist die Vergangenheit. Ich würde sagen zumindest in der Grafik ist es weniger als eindeutig.

[Zossel]

@Hypadaiper
Naja ich weis das ich ins Chaos immer drifte

https://www.deepl.com/write

[davidzo]

Dies war der Kontext der letzten 2 Seiten:

Das ganze Gerede von Zen5 in 2023 wurde losgestoßen von Gigabytes Press Release. Dass es irgendwann auch mal ne folie gab wo zen5 nicht eindeutig in 2024 liegt soll das dann bestätigen. Finde ich sehr wackelig gegenüber dem Haufen an jüngeren und offiziellen Infos die auf 2024 deuten.


"Even though these new products are entry-level servers, CPU support does not end here and the AM5 platform is supported until at least 2025. In addition, the next generation of AMD Ryzen desktop processors that will come out later this year will also be supported on this AM5 platform, so customers who purchase these servers today have the opportunity to upgrade to the Ryzen 7000 series successor," wrote Gigabyte in its press release(opens in new tab).

Gerade das "In Addition" deutet doch daraufhin dass mit "later this year" nicht die nächsten highend Prozessoren gemeint sind, sondern midrange mit neuen Features.

[reaperrr]

Gerade das "In Addition" deutet doch daraufhin dass mit "later this year" nicht die nächsten highend Prozessoren gemeint sind, sondern midrange mit neuen Features.
Äh... nein.

"Even though these new products are entry-level servers, CPU support does not end here and the AM5 platform is supported until at least 2025. In addition, the next generation of AMD Ryzen desktop processors that will come out later this year will also be supported on this AM5 platform, so customers who purchase these servers today have the opportunity to upgrade to the Ryzen 7000 series successor," wrote Gigabyte in its press release(opens in new tab).

Ich weiß nicht wie gut dein Englisch sonst so ist, aber die Aussage von Gigabyte deutet absolut NICHT darauf hin, dass es nur um Midrange geht, sondern klar um den Ryzen 7K Nachfolger.
Und dass damit nur Phoenix gemeint ist, bezweifle ich stark, denn der wird entweder innerhalb des 7K-Portfolios als 7X00G kommen, oder wie Renoir Mobile-/OEM-only als 8X00G, und erst Strix Point wieder im Desktop als 9X00G.

Dass Gigabyte hier Mist geschrieben hat will ich ja gar nicht ausschließen, aber die markierten Aussagen deuten relativ klar auf Zen5 hin.

Und zumindest Gerüchte, dass Zen5 ähnlich schnell auf Zen4 folgen könnte wie Zen3 auf Zen2, gab es auch schon länger. Für einen 2023er Launch spricht zwar auch das nicht unbedingt, eher für Ende Q1/Anfang Q2 '24, aber wer weiß...
Zen4 war ein ganz neuer Prozess und eine neue Plattform mit neuem Speicher, ich gehe stark davon aus, dass Zen4 nur deshalb so lange gebraucht hat und die Zen5-Entwicklung zum Zen4-Launch schon viel weiter gewesen sein dürfte, als manche glauben.

[BavarianRealist]

...Und zumindest Gerüchte, dass Zen5 ähnlich schnell auf Zen4 folgen könnte wie Zen3 auf Zen2, gab es auch schon länger. Für einen 2023er Launch spricht zwar auch das nicht unbedingt, eher für Ende Q1/Anfang Q2 '24, aber wer weiß...

War es für Zen5 nicht von Anfang an unsicher, ob er auf N4 oder auf dem neuen N3 kommt (siehe auch Roadmap wo N4 und N3 steht)? Nachdem aber der N3 schon seit längerem kakt, könnte man bei AMD fühzeitig eine Art sichere Lösung auf N4 (hat man ja schon bei Phoenix) gewählt haben. Womöglich ist dann auf diese Weise manches etwas schneller abgelaufen als man geplant hatte, falls man auf N3 geht.

[amdfanuwe]

Ryzen 7000 series successor
ist alles, was nach Raphael kommt.
Zudem geht es um Einstiegsserver auf AM5 Basis. Da sagt Gigabyte nichts anderes, als das nach aktueller Ryzen 7000 mit Raphael noch mehr kommt.
Neben Phoenix kommt dieses Jahr auch noch ZEN4c. Vielleicht gibt es da auch was auf AM5, könnte für Server interessant sein. AMD setzt jetzt auch mehr auf Diversifizierung.
ZEN5 later this year würde ich da nicht reininterpretieren.

[reaperrr]

ist alles, was nach Raphael kommt.
Zudem geht es um Einstiegsserver auf AM5 Basis. Da sagt Gigabyte nichts anderes, als das nach aktueller Ryzen 7000 mit Raphael noch mehr kommt.
Neben Phoenix kommt dieses Jahr auch noch ZEN4c. Vielleicht gibt es da auch was auf AM5, könnte für Server interessant sein. AMD setzt jetzt auch mehr auf Diversifizierung.
ZEN5 later this year würde ich da nicht reininterpretieren.
Nein, Gigabyte sagt klar "next generation of AMD Ryzen desktop processors that will come out later this year".

Und sie sprechen von "successor" im Singular, also dem Nachfolger, nicht allen nachfolgenden Generationen (was ja auch erst recht nicht zur Aussage von 'später dieses Jahr' passen würde).

Bei Zen4c ist höchst fraglich, ob diese Kerne (von Phoenix2 abgesehen) im Desktop kommen, und wenn, dann handelt es sich dabei um keinen Nachfolger, da gleiche Architektur mit mehr Kernen, dafür aber Einsparungen bei Cache und Takt. Eher ne Art AM5-Value-Threadripper, wenn sie wirklich AM5-Modelle mit den 16c-Zen4c-CCDs bringen würden.

Ich versteh nicht, warum sich hier einige so schwer tun, die Gesamtaussage von Gigabyte einfach mal wörtlich so hinzunehmen, wie sie dort steht.
Das mit "later this year" ist natürlich extrem unwahrscheinlich wenn selbst AMD von 2024 spricht, aber warum hier dann krampfhaft versucht wird, die Aussagen so hinzudrehen, dass damit nicht Zen5 gemeint sein wird/kann/darf, verstehe ich nicht so ganz.

Dass Gigabyte irgendwas in den falschen Hals gekriegt hat ist absolut möglich, aber deren Aussage als solche ist eigentlich ziemlich unmissverständlich. Wahrscheinlich inhaltlich falsch, aber trotzdem sehr eindeutig in dem, was sie aussagt.

[basix]

"Next Generation" = Ryzen 8000 = 2023 Release

Welcher CPU-Kern das beinhaltet ist eigentlich irrelevant. Deswegen könnte das sehr wohl Phoenix sein. War bei den 4x00G APUs ja auch so.

[Complicated]

2023=7000
2024=8000
Das steht explizit auf AMDs Folie für die neue Benennung.
Könnte Gigabyte da ein Threadripper Derivat für AM5 gespoilert haben?

[davidzo]

Ich versteh nicht, warum sich hier einige so schwer tun, die Gesamtaussage von Gigabyte einfach mal wörtlich so hinzunehmen, wie sie dort steht.
Ich verstehe nicht wieso hier so wenige die Medienkompetenz haben Marketingaussagen zu interpretieren. Marketing versucht immer das Maximale anzukündigen und dabei so schwammig wie möglich zu bleiben dass man immer noch einen Rückzieher machen kann. Das Ziel ist immer das der Kunde sie falsch versteht und auf eine viel schnellere Entwicklung, viel höhere Leistung hofft etc. und zu diesem Ziel werden bewusst Sätze aneinander gereiht die sich eventuell auf unterschiedliche Dinge beziehen, sich aber auf den ersten Blick anders anhören.

Der erste Satz mit "supported bis 2025" bezieht sich natürlich auf Zen5, Zen5 refresh oder gar Zen6.
Der nächste Halbsatz ist auffällig durch das "In Addition". Eine neue CPU Gen mit einem neuen Leistungsniveau würde kein Marketingsprecher so einleiten. "In Addition" ist eine solche Einschränkung auf die man sich später zurückziehen kann falls ein Kunde sich beschweren würde.
Der Nebensatz kann mit "Ryzen 7000 successor" kann sich dann schon wieder auf den ersten Satz beziehen, denn durch "in Addition" hat man die "bis 2025 supported" Aussageaus dem ersten Satz ja geschickt mit diesem zweiten Satz verknüpft. Es kann also gut so gemeint sein dass sich alles ergänzende nicht auf die "next generation ryzen later this year" bezieht, sondern auf die weitere Plattformentwicklung bis 2025 die man am Anfang erwähnt hat.

Das ist schon eine sehr komische Formulierung, müsst ihr doch auch zugeben. Und erfahrene Marketing und PR-Leute machen so komische Formulierungen nie ohne triftigen Grund.
Das ist ein typischer Marketing-Täuschungsversuch und ihr seid alle drauf reingefallen. ;D

[robbitop]

2023=7000
2024=8000
Das steht explizit auf AMDs Folie für die neue Benennung.
Könnte Gigabyte da ein Threadripper Derivat für AM5 gespoilert haben?
Wobei ja Ryzen 7000 als Raphael 2022 releast wurde. Ggf. gibt es ja sowas wie bei Autos und anderen consumer goods wo es "Modelljahre" gibt, die dann nicht dem Kalenderjahr entsprechen.

[HOT]

Wobei ja Ryzen 7000 als Raphael 2022 releast wurde. Ggf. gibt es ja sowas wie bei Autos und anderen consumer goods wo es "Modelljahre" gibt, die dann nicht dem Kalenderjahr entsprechen.

Richtig und ganz nebenbei passen die Desktop-CPUs gar nicht in das Namensschema ;).

Aber ich denke des Rätsels Lösung wird einfach der Ryzen 7000 Pro sein, denn man wird den als "nächste Geenration" für professionellen Einsatz releasen. Vielleicht bekommen die Dinger ja tatsächlich ne neue Rev. des I/O-Chips für gefixten ECC-Support.

[Complicated]

Wobei ja Ryzen 7000 als Raphael 2022 releast wurde. Ggf. gibt es ja sowas wie bei Autos und anderen consumer goods wo es "Modelljahre" gibt, die dann nicht dem Kalenderjahr entsprechen.
Das war vor der Ankündigung des neuen Namensschemas - wieso werden denn Beispiele vor 2023 als Relevant gesehen?

[robbitop]

Bis auf ganz wenige Ausnahmen gilt das doch (zumindest dem Anschein nach) seit Anfang an. Es gab jedes Jahr für CPU oder APU eine neue Zahl am Anfang. Seit 2017. Es ist eigentlich nur Raphael und Rembrandt die 2 Zahlen in einem Jahr neu gebracht haben. Aber auch da könnte man sagen, dass Raphael deutlich später kam und schon zum Modelljahr 2023 gelten würde.

[HOT]

Das war vor der Ankündigung des neuen Namensschemas - wieso werden denn Beispiele vor 2023 als Relevant gesehen?
Wieso reitest du so auf dem Schwachsinn herum? Das ist pures Marketing, die machen sich die Welt wie sie ihnen gefällt, das kann man doch nicht so ernst nehmen.

[Complicated]

Weil es kein Schwachsinn ist, sondern ein entscheidendes Element für den Zugang zu den OEMs.
Du redest von purem Marketing und tust dabei so, als sei das kein wichtiges Element.

Wenn es dann um Benchmarks geht, die nur die 13% Retailkunden interessiert, dann wird dem "Halo"-Produkt eine Marktmacht zugestanden, die alles andere dominiert. Das halte ich für den größeren Schwachsinn aus Unternehmenssicht.

[HOT]

Das ist Unsinn. Als ob das die OEMs wirklich interessieren würde :freak:. Denen ist nur wichtig, dass man das verkaufen kann. Namen = Marketing, Punkt.

[amdfanuwe]

Ein witziges Detail: Wenn AMD Zen5 noch dieses Jahr launchen würde, müßten sie (sofern sie sich an ihre eigene neue Nomenklatur halten) die CPU der 7xxx-Serie zuordnen:

https://beebom.com/wp-content/uploads/2022/09/New-naming-scheme.jpg?w=640


witzig auch, dass keine non-X, X, XT, X3D erwähnt sind.
Also die Folie sagt nichts zu Desktop aus.

[HOT]

Die Folie ist nichts weitere als ne Rechtfertigung, dass Zen2 und 3 noch im Programm sind. Sobald man das nicht mehr baucht, ändert man einfach wieder alles.
Und klar, die nächste Generation wird auch wieder 8950X, 8900X, 8700X heißen und es ist völlig egal, wann die erscheinen.

[Complicated]

Das ist auch derzeit nur für Mobile offiziell. Doch OEMs, die beides machen, werden dies als Grundlage nutzen. Die Strategie und Entwicklung ist für den OEM-Chanel absehbar mit dem Start dieses Jahr, und meine fundierte Spekulation. Kann natürlich anders kommen, ist jedoch kein Marketing-Schwachsinn wie manch einer hier im reinen Schwarz/Weis denken argumentiert.

[Complicated]

Die Folie ist nichts weitere als ne Rechtfertigung, dass Zen2 und 3 noch im Programm sind. Sobald man das nicht mehr baucht, ändert man einfach wieder alles.
Was du nicht verstehst ist, dass dies die Vorbereitung ist, um eben dauerhaft 2-3 Generationen IP im selben Jahr zu releasen. Daher ist die Erwartung, dass dies wieder verschwindet weil es eine temporäre Situation kaschieren soll, der eigentliche Unfug. Chiplets und Custom werden das einfach nötig machen.

Edit: Da "Portfolio Year" nicht das Releasedatum bezeichnet, kann es sogar jedes Jahr zum knallhart Renaming ein und der selben SKU kommen, nur weil sie im nächsten Jahr noch im Portfolio ist. Die IP Generation ist dennoch jederzeit ersichtlich, aber eben an dritter Stelle der SKU-Bezeichnung.

[HOT]

Arf, ich hab nicht die Meinung, dass das wieder verschwindet :freak:. Ich versuche dir einfach nur zu erklären, dass das nicht weiter als ein Namenssystem ist und keinerlei Garantie auf Bestand hat, weil das pures Marketing ist.
Und ich find das ja sogar gut, absolut transparent zu machen, welche Architektur das jetzt ist, das wird ja damit auch deutlich. Du verstehst mich einfach nicht.
Du bist nur völlig auf dem Holzweg, dass dieses Namensschema irgendeinen Bestand hat. Hat es nicht. Wenn es AMD opportun ist, gibts halt ein neues.

[Complicated]

Ich verstehe dich, teile aber deine Meinung nicht, sondern sehe es anders.
Anhand deiner Argumentation sehe ich auch wenig Background, der mir signalisiert dass du einschätzten kannst was wichtig oder nicht wichtig ist rund um Marketing. Wenn du dann etwas von Holzweg erzählst, hinterläßt das entsprechend wenig Überzeugungskraft.
Wer glaubt da wird opportunistisch (was auch immer das definieren soll) halt mal was anderes gemacht, der hat diese Prozesse nicht kennen gelernt.

[Hypadaiper]

@Hypadaiper
Naja ich weis das ich ins Chaos immer drifte.An der Intellegenz scheitert es auch bei mir nicht.

Danke für diesen offenen und selbstreflektierten Kommentar.
Jetzt komm ich mir sogar ein bisschen wie der Arsch vom Dienst vor…
Zeigt schön, dass wir alle nur Menschen sind.

Danke, wirklich.

[iamthebear]

Aus technischer Sicht macht es durchaus Sinn 2-3 Generationen parallel laufen zu lassen.
Das Problem von AMD ist, dass man mit Zen4 mindestens einen 125mm² N6 IO Die und einen 70mm² N5 Compute Die braucht. Das passt für den typischen Gamingrechner ganz gut, ist für Bürorechner oder andere Entry Geräte deutlich überdimensioniert.

Bei Zen3 kann man mit beiden Dies auf einen billigeren Node gehen.

Oder falls man einen 4 Kerner bauen will setzt man gleich ein Zen2 CCX mit 4 Kernen ein statt ein 8 Kern Design zu beschneiden.

Das Namensschema ist jedoch komplett für die Tonne. Als Kunde istbes mir vollkommen egal wann eine CPU released wurde. Mich interessiert die Performance und die hängt von der Architektur ab.

[CrazyIvan]

Sehe das ganz genau so.
Es wird wie in der amerikanischen PKW Industrie: "Dodge Challenger 2023 Edition"
Änderungen: andere Chromleisten

[dildo4u]

MJr4o8qqAqA

[Thunder99]

Aus technischer Sicht macht es durchaus Sinn 2-3 Generationen parallel laufen zu lassen.
Das Problem von AMD ist, dass man mit Zen4 mindestens einen 125mm² N6 IO Die und einen 70mm² N5 Compute Die braucht. Das passt für den typischen Gamingrechner ganz gut, ist für Bürorechner oder andere Entry Geräte deutlich überdimensioniert.

Bei Zen3 kann man mit beiden Dies auf einen billigeren Node gehen.

Oder falls man einen 4 Kerner bauen will setzt man gleich ein Zen2 CCX mit 4 Kernen ein statt ein 8 Kern Design zu beschneiden.

Das Namensschema ist jedoch komplett für die Tonne. Als Kunde istbes mir vollkommen egal wann eine CPU released wurde. Mich interessiert die Performance und die hängt von der Architektur ab.
Im Notebook Bereich hat AMD genau damit angefangen. Intel recycelt auch Alderlake im Raptorlake Portfolio

[Windi]

Für den Massenmarkt sind eigentlich nur 6 und 8 Kerner interessant.
4 ist einfach etwas wenig und sieht auch schlecht aus.
12 ist hingegen etwas viel, dabei kommen noch die Probleme mit den 2 Chiplets.

Über den Takt kann AMD auch nicht viel machen. Die X- und Non X- Modelle liegen leistungstechnisch nicht all zu weit entfernt. Da kann man nicht noch weitere Modelle dazwischen quetschen. Noch weiter den Takt senken, macht auch keinen Sinn.
So hat AMD gerade einmal 4 Varianten für den Massenmarkt.
Wenn sie aber weiterhin die Vorgängermodelle verkaufen, können sie viel mehr Varianten anbieten und das Portfolio nach unten abrunden.

Das sie den alten Modellen dann neue Namen geben, ist sicherlich nützlich fürs Marketing. Für den Verbraucher natürlich etwas verwirrend.

[amdfanuwe]

Für den Massenmarkt, Internet, Streaming, etwas Office reichten auch 2 gute Kerne.
Was ist daran schlimm, alte Modelle ins neue Portfolio aufzunehmen und entsprechend ihrer Leistung ihnen einen neuen Namen und Preis zu geben?
Ist doch überschaubarer als wenn ich erst schauen muss, ob der neue 6 Kerner nicht gar besser als der alte 8 Kerner ist.
Oder haben die Geräte vor 1,2,3 Jahren nichts getaugt?

[latiose88]

ALso ich lese von Zen 5 2-300 mHZ mehr Takt.Würde also heißen Allcore Takt liegt dann bei 5,3-5,4 ghz. Dann noch hier und da kleine Verbesserung und aus den 15 % sind es dann am Ende dann 20% Mehrleistung in Multicore Leistung. So wie immer halt ,wieder mal 20 % Mehrleistung.Hätte mich auch gewundert wenn es aufeinmal mehr Leistung als bisher geben würde.Denn woher soll diese massive Mehrleistung herkommen.Ist halt auch unrealistisch.Das es auf einmal mehr als üblich geben wird.Ich würde mir ja auch wünschen das von Zen 4 auf Zen 5 30% und mehr an Leistung dabei rum kommt,aber mein Menschenverstand sagt mir das es nicht richtig ist.
Amd ist also auch an seine Grenzen der Optimierung angekommen.Aber wir werden ja sehen wieviel Leistung dabei rumkommen wird.Und diese 20% werden nur der Durschnitts Steigerung sein.Da wird es wie immer Programme geben die weniger Leistungssteigerung haben als die besten Programme.Diese 20 % Stellen also ne Anwendung dar wo am meisten davon Profitiert.

Meist ist bei meiner Anwendung mit Takt Erhöhung bei rund 13 % Schluss gewesen.Nur bei Zen 4 war dank des Massiven Taktsteigerung so eine hohe Leistung drinnen.
Bei gleichen Takt war dann bei rund 7 % IPC Steigerung schon Schluss.Die 2-3 % dank DDR5 muss man auch noch abziehen. Dann bleiben also nur noch rund 4 % durch IPC Optimierung übrig.
Wenn ich bedenke was so alles verändert wurde irgendwie ne sehr kleine Belohnung wie ich finde.
Aber bei Zen 5 wird weit weniger getan als bei Zen 4,also kann man mit weit weniger Plus schon Erwarten.Ich scheine wohl eine sehr hohe Anforderung bwz Anforderung an die noch kommenden CPUs zu haben.Meine Erwartung ist hoch und das hoffen auf so viel Leistung wie möglich.

Threadripper Zen 3 konnte auch nicht die Erwartungen Erfüllen.Klar kommt noch Zen 4 Threadripper aber ob die beim CPU Takt da so hoch gehen werden wie die bei der Mittelklasse,naja Erwarte da nicht so viel.Zen 2 zu Zen 3 Threadripper war mit nur 13 %.Ich hatte jedenfalls mit mehr Erwartet gehabt.Aber die Threadripper Zen 3 wurden von den 7950x geschlagen.Also Takt spielt ebenso eine Rolle,wobei zwischen 4,4 ghz zu 5,1 ghz nun auch kein riesen Taktunterschied ist.Wenn ich bedenke es tritt ja ein 16 vs 32 bzw 24 Kerne an.
Naja dann wird halt auf den Nachfolger gewartet.Ich gebe mich auf jedenfall nicht mehr mit nur 20 % zufrieden.Mein Leistungshunger ist also größer.

Wenn nun aber die Teuren CPUS auch nicht ausreichen,also keine CPU gibt die richtig mehrleistung hat,dann kann nur Zeit helfen.Es kostet alles sehr viel Geld,da muss man schon gut überlegt Einkaufen.

Wenn also das Videoumwandeln nicht wäre,dann hätte ich schon seid Jahren keinen hohen Bedarf.Da würden mir wohl maximal 8 Kerne völlig reichen.

Aber eines ist sicher,Spannend bleibt es auf jedenfall.Ich weis die LEistung vollkommen.Und wenn selbst ein Ryzen 7 7700x einen Ryzen 9 3950x schon bei der Multicore Leistung schlägt,dann kann die Zukunft nur noch spannend sein.Wohlgemerkt ich schreibe noch immer von der selben Anwendung.

Der Zen 5 8 Kerner wird gewiss auch meinen 5950x wohl schlagen das ist sicher.Aber gut was sind schon 3,8 GHZ Allcore Takt,das ist keine große Kunst mehr dann.

Nun dann Zen 5 bin ich zumindest ich jetzt schon bereit,aber erst 2024 ist es ja Spruchreif.

[Windi]

Für den Massenmarkt, Internet, Streaming, etwas Office reichten auch 2 gute Kerne.

Für den Low Cost Markt nimmt man am besten eine 4 Jahre alt APU. Die hat alles integriert und setzt auf eine ältere und günstigere Fertigung.
Ein moderner 2 Kerner dürfte hingegen Recht teuer werden. Es müssen ja nicht nur die 2 Kerne im neusten Fertigungsprozess gefertigt werden, sondern auch der ganze Rest, der locker dreiviertel der Fläche ausmacht. Man könnte natürlich auch auf Chiplets setzen, aber 2 Kerne Chiplets wären winzig und dazu kommen dann noch die Packaging Kosten.

[Complicated]

Das Namensschema ist jedoch komplett für die Tonne. Als Kunde istbes mir vollkommen egal wann eine CPU released wurde. Mich interessiert die Performance und die hängt von der Architektur ab.Wer das in den neuen Bezeichnungen nicht direkt in 5 sek erkennt, hat sich mit dem neuen Schema nicht beschäftigt. Da kann dann auch keiner mehr helfen, wenn der OnePager dafür nicht ausreicht es zu verstehen.
Für den Low Cost Markt nimmt man am besten eine 4 Jahre alt APU. Die hat alles integriert und setzt auf eine ältere und günstigere Fertigung.
Nicht alleine nur das, man schaue was AMD mit der Vega iGPU getan hat und welche Leistung die plötzlich als "alte IP" in den mobilen APUs bot, mit entsprechenden Anpassungen.

[Langlay]

Wenn nun aber die Teuren CPUS auch nicht ausreichen,also keine CPU gibt die richtig mehrleistung hat,dann kann nur Zeit helfen.Es kostet alles sehr viel Geld,da muss man schon gut überlegt Einkaufen.

Wenn also das Videoumwandeln nicht wäre,dann hätte ich schon seid Jahren keinen hohen Bedarf.Da würden mir wohl maximal 8 Kerne völlig reichen

Kein Mensch kauft sich einen Threadripper zum 1 Video gleichzeitig umzuwandeln. Ich geh jetzt mal davon aus, das du irgendwelche Video zu h.264 umwandelst weil sonst würde ja CPU Encoding keinen Sinn machen.

Auch Videokonvertierung skaliert nicht endlos mit mehr Kernen. Es ist zwar auch Auflösungsabhänig aber irgendwo bei ~16 Kernen ist meist Schluss mit der Skalierung. Mit einen Threadripper kannste dann halt mehr als einen Konvertierung gleichzeitig machen. Aber ein 64 Kern Threadripper wird halt nicht schneller als ein 16 Kern Ryzen sein wenn ich immer nur ein Video am Stück umwandel.


Je nach dem was man mit den Videos vor hat, könnte es interessant sein von h.264 auf h.265 o. AV1 zu wechseln und dann auf GPU Encoding umzusteigen. h.265/AV1 haben halt den Vorteil das sie bei gleicher Qualität weniger Bandbreite brauchen ergo die Files spürbar kleiner werden.

[Nightspider]

Zen 5 soll ja die größte Änderung in der µArch seit Zen 1 auffahren.

Wenn N4X um die 15% mehr Performance bringen soll könnte das in Kombination schon 20-30% mehr Leistung im Durchschnitt bringen.

Einige Anwendungen werden weniger von der IPC profitieren und manche Anwendungen werden wieder extreme Werte von >40% zeigen.

Das ist das, was wir in etwa grob erwarten dürfen meiner Meinung nach.

Vielleicht bekommen wir bei Zen5 ja auch 6X3D + 6X3D Kerne, für leistungshungrige Spiele, die mit vielen Kernen skalieren.

Die 6X3D +6C Variante bei Zen4 überzeugt ja eigentlich gar nicht nicht bisher.

Ich hätte ja mittlerweile gerne ein 10C Chiplet fürs Gaming mit V-Cache aber das werden wir nicht bekommen.

[reaperrr]

Wenn N4X um die 15% mehr Performance bringen soll könnte das in Kombination schon 20-30% mehr Leistung im Durchschnitt bringen.

N4X erkauft sich den "Performance"-Zuwachs gegenüber N4P mit massiv mehr Leakage, heißt, in N4X sind zwar höhere maximale Taktraten möglich, aber auf Kosten einer massiv verschlechterten Effizienz.

Ich gehe für Zen5 deshalb stark von N4P aus, weil N4X nur bei aufgedrehter TDP überhaupt seine Vorteile ausspielen kann und in mittleren und niedrigeren Takt-/TDP-Bereichen eher schlechtere Perf/W hätte.

N4X ist eher für "TDP relativ egal"-HPC-Produkte gedacht, und bringt auch nur 4% mehr "Performance"/Maximal-Takt ggü. N4P:
https://pr.tsmc.com/english/news/2895

[latiose88]

Kein Mensch kauft sich einen Threadripper zum 1 Video gleichzeitig umzuwandeln. Ich geh jetzt mal davon aus, das du irgendwelche Video zu h.264 umwandelst weil sonst würde ja CPU Encoding keinen Sinn machen.

Auch Videokonvertierung skaliert nicht endlos mit mehr Kernen. Es ist zwar auch Auflösungsabhänig aber irgendwo bei ~16 Kernen ist meist Schluss mit der Skalierung. Mit einen Threadripper kannste dann halt mehr als einen Konvertierung gleichzeitig machen. Aber ein 64 Kern Threadripper wird halt nicht schneller als ein 16 Kern Ryzen sein wenn ich immer nur ein Video am Stück umwandel..


Ja der Wahnsinn. Ich schreibe von den 24 und 32 kerner und du von gleich einem 64 Kerner. Diesen haben ich garnicht mal getestet gehabt nur bisher maximal 32 Kerner. Es reicht mir schon aus weil dieser ohne smt bei 75 % und mit smt bei rund 32 % an cpu auslastung gelegen war. Da wusste ich es macht dann auch keinen Sinn noch mehr kerne auszuprobieren. Wie gesagt ich verwende schon 2 x das selbe Programm aus. Ich weiß das sich ein 32 Kerner deutlich mehr von einen 16 Kerner absetzt. Aber dem ist ja nicht so.

Zumindest Zen 3 threadripper kostet smt keine Leistung mehr. Ich sehe einen 24 Kerner gleiche Leistung als ein 32 kerner an. Ich habe auch nur einen mit 24 kernen gefunden und keinen mit 32 kernen. Seid dem es keine threadripper sondern nur noch threadripper pro gibt war es das echt mit 32 Kerner und mehr. Die epyc sind ja sogar noch schlechter weil haben geringeren cpu takt.
Der threadripper pro 5965wx hat bei allcore 4,4 GHz ereicht mit allen 24 kernen.
Smt an und aus brachte kein Unterschied mehr. Früher also der non pro war mit smt aus und festen Zuordnung die CPU gleich schnell wie ein 32 Kerner gewesen. Aber nur bei mir.
Die anderen Tests im Netz sagen ja was anderes. Da gibt es ja auch massive Unterschiede.

Wenn es also sogar mit 2 Videos gleichzeitig schon zu dem Ergebnis kommt, dann ist es eindeutig.

Nächtes Jahr kommt zwar Zen 4 threadripper aber auch Zen 5 ryzen und dieser ist bei mir mit Sicherheit dann wieder schneller. Also solange das so ist, kann sich threadripper niemals wirklich absetzen. Es macht ja auch wenig Sinn da was zu investieren wenn diese ja 1 gen hinter her hinken.

Bestimmt wäre Zen 4 threadripper schneller, so 10 % wohl schon gegenüber dem Zen 4 ryzen. Aber naja ist halt zu wenig mehrleistung für den sehr hohen Preis.

Würde ich es jedoch so wie du machen wäre es wohl bei nur einem beim threadripper ohne smt bei rund 38 % und mit smt dann bei 19 % Auslastung.

Der rzyen 9 mit 16 kernen wäre dann bei 50% oder so 44 % und das ist halt dann einfach nix mehr. H264 lastet also sehr wenig die Kerne aus.

Bei 576i Auflösung am meisten. Bei 720p Aufnahmen senkt sich die Auslastung.

Ich dachte ja das bei höhere Auflösung die CPU last steigen würde. Dem ist jedoch nicht so. Bestimmt hat es was mit dem Format wo es vorliegt auch zu tuen. Ich habe da ein TV Aufnahme mit 720p vom ersten, zweiten oder Dritten Sender. Es steht da was von 4 reg frames und teilweise werden ja da sogar 7 b frames verwendet.die Bitrate ist so bei 12 MBit. Durch das umwandeln wird es bei mir wirklich weniger. So bei 2 MBit soweit ich weiß.

RAM Menge steigt bei höheren Auflösung von 128 MB auf 256 und teilweise auf 512 MB je Programm. So das ich mit 2 Programmen teilweise auf 1 GB RAM Verbrauch komme.
Bei dem mit geringer Auflösung komme ich dann so auf 256-512 MB maximaler ram Verbrauch. Nutze also noch nicht mal die 32 bit maximale 4 GB aus die ich könnte.

Ssd ist auch nicht stark belastet. Obwohl es direkt von ssd zu ssd umgewandelt wird.
Naja RAM scheint wohl auch nicht mehr so viel Leistung zu bringen.

Ich dachte anfangs ich könnte die CPU Leistung beeinflussen durch den ganzen Rest. Sogar eine CPU hat ne 4000 MHz RAM takt. Aber das hat alles keine wirkung.

Darum bin ich ja auch so stark auf cpu Leistung fixiert. Wenn der Rest nicht mehr mit spielen will dann hilft nur noch noch mehr CPU Leistung. Was anderes weis ich in Zukunft halt auch nicht.

Wenn CPU takt auch nicht mehr hilft dann wird ipc die einzige Rettung bei CPU Leistung nur noch sein. Ich setze also voll auf das und hoffe das die Anwendung da schon mit machen wird.

[Langlay]

Wie gesagt ich verwende schon 2 x das selbe Programm aus.

Da haben wir schon das Problem bei deinen Auflösung von 720p und kleiner ist das so zuwenig. Die ~16 Kerne lastet du in h.264 in 1080p+ aus, kleinere Auflösungen lasten weniger Kerne aus. Ergo du hast zu wenig Instanzen am laufen. Wenn du noch CPU Auslastung frei hast hast du zu wenig Instanzen gleichzeitig am laufen.


Nächtes Jahr kommt zwar Zen 4 threadripper aber auch Zen 5 ryzen und dieser ist bei mir mit Sicherheit dann wieder schneller. Also solange das so ist, kann sich threadripper niemals wirklich absetzen.

Dann hast du wieder zu wenig Instanzen am laufen. 2 Instanzen da langweilt sich der Threadripper doch tot.

Wenn ich einen Stattelschlepper und einen Porsche 911 mit einen Bierkasten belade und dann von München nach Hamburg fahre und feststelle der Porsche 911 ist das bessere Fahrzeug für den Job. Habe ich den gleichen Fehler gemacht wie du. Der Stattelschlepper kann halt 100 Bierkasten gleichzeitig transportieren der Porsche nur wenige dafür deutlich schneller.

[basix]

Für den Low Cost Markt nimmt man am besten eine 4 Jahre alt APU. Die hat alles integriert und setzt auf eine ältere und günstigere Fertigung.
Ein moderner 2 Kerner dürfte hingegen Recht teuer werden. Es müssen ja nicht nur die 2 Kerne im neusten Fertigungsprozess gefertigt werden, sondern auch der ganze Rest, der locker dreiviertel der Fläche ausmacht. Man könnte natürlich auch auf Chiplets setzen, aber 2 Kerne Chiplets wären winzig und dazu kommen dann noch die Packaging Kosten.

+1

Nicht ohne Grund leben & lebten Renoir/Lucienne, Barcelo, Cezanne und Rembrandt so lange. Phoenix vermutlich auch. Für low cost und Office Kisten gut genug, solange die beschleunigten Video Codecs noch stimmen.

[Nightspider]

Irgendwie kann ich mir nicht vorstellen, das der L2 bei Zen5 nochmal vergrößert wird ohne das der L3 pro CDD stark schrumpft. Der doppelt so große L2 hatte bei Zen4 schon nur einen sehr kleinen Impact auf die Performance und nimmt schon ziemlich viel Fläche ein.


Ich hoffe ja das AMD den L3 Cache beim Zen5 CDD halbiert und dafür 2-Layer V-Cache einsetzt. AMD könnte 32 MB im CCD haben und zwei mal 48MB (=96MB) für insgesamt 128 MB stacken.

Wie man sieht kann AMD selbst bei Zen4D günstigen den V-Cache in N7 fertigen.

Die Ersparnis durch N7 dürfte die Mehrkosten vom Packaging auffangen.

Der größte Vorteil wäre jedoch viel mehr Platz für Logik zu haben. Die CPU Kerne könnten rund 50% größer und damit deutlich breiter werden bei gleicher Chipgröße.

Und 2*48MB L3 in N7 dürfte sehr billig zu produzieren sein, während die Packagingkosten sich noch im Rahmen halten dürften.
Zwei SRAM Chips zu stacken dürfte einfach sein.

Resultat:

-leicht höhere Packagingkosten
-leicht höhere Kosten für SRAM
+50% Corespace
+16,66% SRAM
~kürzere Datenleitung zum L3.

[amdfanuwe]

Irgendwie kann ich mir nicht vorstellen, das der L2 bei Zen5 nochmal vergrößert wird ohne das der L3 pro CDD stark schrumpft.

Da Mi300 Infinity Cache mitbringt, denke ich, dass das auch bei ZEN5 der Fall sein wird.
16MB pro SI = 192MB IF$ im I/O dazu schnellere Anbindung der Chiplets an den I/O bringen ganz andere Anforderungen an den L3 und L2 mit.
Zudem würde durch den IF$ im I/O der Datenaustausch zwischen den Chiplets erheblich beschleunigt.
Für zusätzlichen 3D Cache auf dem Chiplet ist dann immer noch Platz.

Ist bestimmt keine leichte Aufgabe ein Optimum für die L2,L3,IF$ Größen zu finden, die den meisten Applikationen einen effizienten Betrieb erlauben.

[amdfanuwe]

Ein moderner 2 Kerner dürfte hingegen Recht teuer werden. Es müssen ja nicht nur die 2 Kerne im neusten Fertigungsprozess gefertigt werden, sondern auch der ganze Rest, der locker dreiviertel der Fläche ausmacht. Man könnte natürlich auch auf Chiplets setzen, aber 2 Kerne Chiplets wären winzig und dazu kommen dann noch die Packaging Kosten.
Ja, das Verhältnis zwischen Produktionskosten und Leistung muss stimmen.
Ein 4 Kerner wird minimal teurer, bringt aber die doppelte Leistung.
Daher lohnt es sich nicht im neuestem Fertigungsprozess nur wenige Kerne zu bringen.
Dali 2 Core 149mm² 14nm ( Picasso 4 Core 210mm² 14nm )
Mendocino 4 Core 100mm² 6nm ( Rembrandt 8 Core 210mm² 6nm )
Phoenix2 2+4c <100mm² 4nm ?? ( Phoenix 8 Core 178mm² 4nm )

[Nightspider]

Da Mi300 Infinity Cache mitbringt, denke ich, dass das auch bei ZEN5 der Fall sein wird.

MI300 setzt auf 2.5D und echtes 3D Stacking.

Würde AMD bei Zen5 komplett auf echtes 3D Stacking setzen, bräuchte man deutlich höhere Packaging-Kapazitäten.

TSMC baut zwar solche Advanced Packaging Fabs und ich würde mir wünschen das AMD schon bei Zen5 darauf setzt aber ich sehe das eher ab Zen6 kommen.

Würde man auf echtes 3D Stacking setzen müsste AMD auch nicht mehr auf 8C Chiplets setzen. Man könnte kleinere 4C Chiplets viel flexbibler stacken, die sich mehr wie ein monolithischer Chip verhalten würden, während die Cores gleichzeitig deutlich wachsen könnten und der L3 komplett ausgelagert wäre.

Ich denke da wären die Leaks schon durch die Decke gegangen, wenn AMD so einen großen Sprung machen würde.

Erstmal muss das alles bei MI300 funktionieren und die Kapazitäten dafür reichen.

[Skysnake]

Ich denke das wird ein gutes Jahr für AMD mit spannenden Produkten.

Was weiß man denn aktuell offiziell bzw inoffiziell bezüglich zen4 vs zen4c?

[amdfanuwe]

MI300 setzt auf 2.5D und echtes 3D Stacking.

was meinst du damit?
3D Stacking kann vieles sein. InFO_PoP, Intel Foveros, oder eben Metal on Metal wie bei 3D-VCache.
Beim MI300 kommt m.M. nach InFO_PoP zur Anwendung.
Ist die billigste Variante, keine TSV im Base Die nötig.
Ohne HBM könnten die Chiplets auch seitlich an die Base Dies angebracht werden.
Also 3D Stacking ist bei ZEN5 nicht notwendig.
IF$ hat auch nichts mit L3 zu tun. IF$ cached das SI und stellt für die angeschlossene Logik mehr Bandbreite zur Verfügung und ist zugleich kohärent und unified für alle Kerne.

[amdfanuwe]

Ich denke das wird ein gutes Jahr für AMD mit spannenden Produkten.

Was weiß man denn aktuell offiziell bzw inoffiziell bezüglich zen4 vs zen4c?
Offiziell:
16 Core vs 8 Core bei gleicher Größe, halber L3 Cache pro Core, gleicher Befehlssatz, geringerer Turbotakt.
Kommt demnächst mit Bergamo.

inoffiziell: nichts

[basix]

Meine Speku zu Zen 5:
- 8C pro CCD, ähnliche Anordnung von Cores und Cache wie bei Zen 3/4
- Deutlich tiefere Reorder Buffer etc. --> Fetterer Core
- Grösserer L1$
- Grösserer MicroOp Cache
- L2$ ohne Änderung
- L3$ ohne Kapazitätsänderung, aber auf eigener Clock Domain und Entkoppelt vom Core Takt (ähnlich wie es Intel schon seit Sandy Bridge(?) macht)
- Taktraten ~6 GHz Core, ~5 GHz L3-Cache
- V-Cache ohne Takt-Regression beim Core
- Neue Accelerators (was? z.B. AI)
- 2x CCD können zusammengeschaltet werden und bilden ein "16C-Super-CCD" --> RDNA3 mässige "Infinity Links". Shared L3$ zwischen den zwei CCD
- Entkoppelter L3$ eines der Schlüssel für das Zusammenschalten zweier CCD (CCD0 <-> CCD1)

[amdfanuwe]

- Entkoppelter L3$ eines der Schlüssel für das Zusammenschalten zweier CCD (CCD0 <-> CCD1)
Was machst du mit den anderen 10-14 CCDs bei EPYC?

[latiose88]

Da haben wir schon das Problem bei deinen Auflösung von 720p und kleiner ist das so zuwenig. Die ~16 Kerne lastet du in h.264 in 1080p+ aus, kleinere Auflösungen lasten weniger Kerne aus. Ergo du hast zu wenig Instanzen am laufen. Wenn du noch CPU Auslastung frei hast hast du zu wenig Instanzen gleichzeitig am laufen.


Hm wenn das stimmt müsste ja 720p mehr Kerne Auslasten oder beeinflusst der Deinterlacer also auch die Kernauslastung sehr?
Ich dachte immer das dieser nur 1 Kern Nutzen könnte.Ohne diesen Interlacer habe ich echt weniger Kernauslastung.Er wirkt sich bei höherer Auflösung auch mehr aus wenn man den weglässt.Sonst würde es keinen Sinn machen das 576i mehr Kerne Auslastet als mit den 720p.Oder übersehe ich da was?

[latiose88]

Was machst du mit den anderen 10-14 CCDs bei EPYC?

Ich wüsste schon wie man das machen kann,mit Gitter Art.Man könnte dann so wie ein Spinnen Netz die Restlichen miteinander verbinden und so damit eine Flexiblität machen.Damit könnte dann jeder Chiplet mit einem anderen Chiplet auch viel schneller zusammen Arbeiten weil eben gleicher Weg.Wobei wie es wohl nun das ganze gemacht wird,ob das dann ein Unterschied dann macht,wer weis.

[basix]

Was machst du mit den anderen 10-14 CCDs bei EPYC?

bei 12-16 CCDs gibt es total 6-8 2er Grüppchen ;)

Es sollen ja nicht alle Cores so verbunden werden, nur max. 2x CCDs.

[latiose88]

das war ja doch beim ersten Epyc bzw Threadripper auch so gewesen das nicht alle Kerne so zusammen gehangen waren.Durch ein blöden Umweg was sie nehmen mussten,verlor es Leistung und die Latenzen stiegen massiv.Ist also keine gute Idee es bei Zen 5 so zu machen.

[Skysnake]

Offiziell:
16 Core vs 8 Core bei gleicher Größe, halber L3 Cache pro Core, gleicher Befehlssatz, geringerer Turbotakt.
Kommt demnächst mit Bergamo.

inoffiziell: nichts

Ok, also die gleichen out of order Windows usw?

[amdfanuwe]

Ok, also die gleichen out of order Windows usw?
da offiziell nur von einer dense Library und halben Cache geschrieben wird, kann ich nur spekulieren, dass an der Architektur nichts wesentlich überarbeitet wurde.
Ist aber eh nicht mein Interessengebiet. Mich interessiert mehr das große Ganze als interne Details. Und ich kann auch nur mit dem Spekulieren, was ich im Internet lese und aus meiner Beruferfahrung her herleite.

Edit:
Mein Gedanke ist halt: ZEN4 dient der Einführung der neuen Platform, da hat man erst mal sicher was im Markt und eine Plattform auf der man Entwickeln kann.
Für ZEN4c hat man dann keinen Stress, dient auch eher der Kosteneinsparung. Bei gleicher Chipletgröße kann AMD die Kerne nahezu zum halbem Preis anbieten. Dazu IF$ im I/O für ordentlich Bandbreite.
Siena als günstigere Alternative. Ich schätze, Siena wird trotz kleinerem SI und nur 4 ZEN4c Chiplets kaum langsamer sein als Milan 64 Core ZEN3. Aber billiger.
ZEN5 mit neuer Architektur auf das neue I/O mit IF$ abgestimmt.

Ich bin da aber auch auf die nächsten APUs gespannt. Geht AMD da Apples weg? Eine 8 Core APU mit IF$, 32GB on Package und 3D Cache scheint mir interessant.

[Skysnake]

Mir geht es auch nur um den Abgleich von dem was im Netz rumgeistert. ;)

[basix]

das war ja doch beim ersten Epyc bzw Threadripper auch so gewesen das nicht alle Kerne so zusammen gehangen waren.Durch ein blöden Umweg was sie nehmen mussten,verlor es Leistung und die Latenzen stiegen massiv.Ist also keine gute Idee es bei Zen 5 so zu machen.

Du hast mich missverstanden. Bei Zen 5 bleibt es beim IOD + CCD Konzept. Bei Zen 3 wurden 8x CCDs mit dem IOD verbunden, bei Zen 4 ganze 12x CCDs. Bei Zen 5 werden es 12-16x CCDs sein, ebenso ans IOD angeschlossen. Der Unterschied wäre aber, dass 2x CCDs eine Gruppe bilden die von aussen wie ein einzelnes grosses 16C "Super-CCD" aussehen. Möglich gemacht durch Infinity Links wie bei RDNA3. Dadurch erreicht man hohe Bandbreite, niedrige Latenz und hohe Energieffizienz beim koppeln der CCDs. Für 1 TByte/s sollte diese Verbindung nur ~4W benötigen (0.5pJ/bit), was absolut im Rahmen liegt.

Ich habe mal was dazu aufgezeichnet, wie z.B. ein 16C Ryzen aussehen würde. Bei Epyc ist es dann einfach so, dass es mehr als eine einzelne 2er Gruppe geben würde, sondern 6-8x Gruppen

[amdfanuwe]

Für 1 TByte/s sollte diese Verbindung nur ~4W benötigen (0.5pJ/bit), was absolut im Rahmen liegt.

Wo bekommst du das TByte/s her, wenn doch nur 2 DDR5 SI am I/O hängen? Die bringen grad ~100 GB/s und die Latenz verringert sich auch nicht.
Dazu das Problem die L3$ kohärent zu halten.

[iamthebear]

Irgendwie kann ich mir nicht vorstellen, das der L2 bei Zen5 nochmal vergrößert wird ohne das der L3 pro CDD stark schrumpft. Der doppelt so große L2 hatte bei Zen4 schon nur einen sehr kleinen Impact auf die Performance und nimmt schon ziemlich viel Fläche ein.

Mit nur 16MB L3 würde die Gamingperformance um geschätzt 20% einbrechen. Damit wäre VCache für den Gamingmarkt quasi Pflicht d.h. Minimum 500 Euro.
Für Bürorechner mit 4-6 Kernen ist die aktuelle Konstruktion sowieso zu teuer. Das müssen Zen2/3 abdecken.

Ich hoffe ja das AMD den L3 Cache beim Zen5 CDD halbiert und dafür 2-Layer V-Cache einsetzt. AMD könnte 32 MB im CCD haben und zwei mal 48MB (=96MB) für insgesamt 128 MB stacken.…

AMD hat doch schon 32MB L3 im CCD. Halbieren würde 16MB bedeuten.
Bei 2 Lagen würden sich die thermischen Probleme aber auch verdoppeln und die Kosten wohl auch. Das Teure am VCache ist nicht der Die selbst (33mm² N6 für 64MB kosten ca. 5$) sondern das Stacking bzw. die Defekte die durch das Stacking entstehen.
Umgekehrt denke ich, dass der Performancegewinn von 96MB auf 128MB relativ gering sein dürfte. Selbst 48MB drauf zu stacken würde schon reichen.

Der größte Vorteil wäre jedoch viel mehr Platz für Logik zu haben. Die CPU Kerne könnten rund 50% größer und damit deutlich breiter werden bei gleicher Chipgröße.

Dafür muss man die Kerne pro Lage VCache um 10% niedriger takten.
Ich denke bei Zen6 in N6 kann man sich darüber noch einmal Gedanken machen aber bei Zen5 (Desktop) macht das noch wenig Sinn.[/quote]

Da Mi300 Infinity Cache mitbringt, denke ich, dass das auch bei ZEN5 der Fall sein wird.
16MB pro SI = 192MB IF$ im I/O dazu schnellere Anbindung der Chiplets an den I/O bringen ganz andere Anforderungen an den L3 und L2 mit.
Zudem würde durch den IF$ im I/O der Datenaustausch zwischen den Chiplets erheblich beschleunigt.
Für zusätzlichen 3D Cache auf dem Chiplet ist dann immer noch Platz.

Ist bestimmt keine leichte Aufgabe ein Optimum für die L2,L3,IF$ Größen zu finden, die den meisten Applikationen einen effizienten Betrieb erlauben.

Diese Überlegung hatte ich auch schon. Allerdings würde ich GPUs hier nicht als Vorbild sehen, da die Situation dort komplett anders ist. GPUs haben eine massiv parallele Architektur wodurch die Latenzen ziemlich irrelevant sind und rein der Durchsatz zählt.

Wenn man den L3 in den IO Die verlagern will, so müsste man:
a) Den L2 deutlich vergrößern z.B. auf 4MB/Kern
b) Die Latenz der Die zu Die Kommunikation verringern
c) Die Bandbreite zwischen CCD und IO vergrößern

Dafür hätte man folgende Vorteile:
.) Bei 2 CCDs oder mehr (Datacenter) kann der L3 von allen Kernen gemeinsam genutzt werden
.) Scheduling wäre einfacher
.) L3 ist zur Gänze am günstigeren Node
.) Man hat weniger thermische Probleme da der IO Die nicht so warm wird
.) Man kann im Fall einer APU den Cache auch durch die GPU nutzen

[Nightspider]

Wo bekommst du das TByte/s her, wenn doch nur 2 DDR5 SI am I/O hängen? Die bringen grad ~100 GB/s und die Latenz verringert sich auch nicht.
Dazu das Problem die L3$ kohärent zu halten.


Er spricht ja bestimmt von der Bandbreite zwischen den beiden gekoppelten CCDs.

Wobei AMD vielleicht auch gleich alle CCDs per Infinity Link an einen IO Die koppeln könnte.
Da würde die Latenz schon ein gutes Stück sinken, denke ich, weil die Chips dann direkt aneinander liegen würden.

Mit nur 16MB L3 würde die Gamingperformance um geschätzt 20% einbrechen. Damit wäre VCache für den Gamingmarkt quasi Pflicht d.h. Minimum 500 Euro.

Wenn AMD dafür die IPC gewaltig erhöhen könnte, dank +50% Space für die Kerne, dann könnte man damit noch immer vor Zen4 landen bei der Gaming Performance, wobei das stark aufs Spiel und die Abhängigkeit vom Cache abhängen würde.
Mit Rembrandt konnte man ja auch super Spiele anfeuern.
Die Kosten für das Packaging werden ja auch fallen in den kommenden Jahren.


Bei 2 Lagen würden sich die thermischen Probleme aber auch verdoppeln

Über dem Cache gibt es keine thermischen Probleme, würde ich jetzt mal behaupten. An der Schicht über den Cores würde sich nichts ändern.

(33mm² N6 für 64MB kosten ca. 5$) sondern das Stacking bzw. die Defekte die durch das Stacking entstehen.
Umgekehrt denke ich, dass der Performancegewinn von 96MB auf 128MB relativ gering sein dürfte. Selbst 48MB drauf zu stacken würde schon reichen.


Sind die 5$ aus der Luft gegriffen oder soll das der reale Preis sein? Je höher die IPC und der Takt steigt, desto mehr Cache wird im Laufe der Zeit benötigt, erst recht wenn der L3 bei Zen5 vom Takt entkoppelt und niedriger takten würde.
Ich denke mal 2 Lagen SRAM zu stacken ist noch relative einfach und nicht so kostenintensiv.

[Complicated]

Du hast mich missverstanden. Bei Zen 5 bleibt es beim IOD + CCD Konzept. Bei Zen 3 wurden 8x CCDs mit dem IOD verbunden, bei Zen 4 ganze 12x CCDs. Bei Zen 5 werden es 12-16x CCDs sein, ebenso ans IOD angeschlossen. Der Unterschied wäre aber, dass 2x CCDs eine Gruppe bilden die von aussen wie ein einzelnes grosses 16C "Super-CCD" aussehen. Möglich gemacht durch Infinity Links wie bei RDNA3. Dadurch erreicht man hohe Bandbreite, niedrige Latenz und hohe Energieffizienz beim koppeln der CCDs. Für 1 TByte/s sollte diese Verbindung nur ~4W benötigen (0.5pJ/bit), was absolut im Rahmen liegt.

Ich habe mal was dazu aufgezeichnet, wie z.B. ein 16C Ryzen aussehen würde. Bei Epyc ist es dann einfach so, dass es mehr als eine einzelne 2er Gruppe geben würde, sondern 6-8x Gruppen
Was du mit den Gruppen beschreibst, wäre eine zusätzliche Node-Ebene. Wohl die schlechteste Lösung für das NoC.
Das Mesh wird alle CCDs gleichwertig einbinden.

[basix]

Wo bekommst du das TByte/s her, wenn doch nur 2 DDR5 SI am I/O hängen? Die bringen grad ~100 GB/s und die Latenz verringert sich auch nicht.
Dazu das Problem die L3$ kohärent zu halten.

Der L3$ der 2er Gruppe wäre "Unified". Inkl. Kohärenz. Deswegen die höhere Bandbreite zwischen den CCDs. Der Witz der 2er Gruppe wäre ja gerade, dass es gegen aussen wie ein einzelnes 16C CCD aussehen würde. Das ist die Grundidee.

Der "Remote"-L3$ des anderen CCD wird zusätzliche Latenz aufweisen, ganz klar. Keine Ahnung, evtl. 15ns anstatt 10ns. Reduzierte L3$-Taktfrequenz inkl. Entkopplung von der Core-Frequenz ist hier eine Massnahme, was den Sync der zwei L3$-Partitionen vereinfachen sollte.

Was du mit den Gruppen beschreibst, wäre eine zusätzliche Node-Ebene. Wohl die schlechtesten Lösung für das NoC.
Das Mesh wird alle CCDs gleichwertig einbinden.
So wie ich mir das vorstelle und oben beschreibe eben nicht. Die 2er Gruppe wäre gegen aussen nicht anders als ein einzelnes CCD. Die "Ungenauigkeit" hinsichtlich etwas erhöhter L3$ und Core-to-Core Latenz, wenn aufs Remote-CCD zugegriffen werden muss, ist natürlich vorhanden. Da muss sich AMD was einfallen lassen, um die Differenz möglichst gering zu halten damit es eben nicht zu einer zusätzlichen Node Ebene führt. Oder der Effekt der zusätzlichen Latenz zumindest vernachlässigt werden kann.

[Nightspider]

Ich denke bei Zen6 in N6 kann man sich darüber noch einmal Gedanken machen aber bei Zen5 (Desktop) macht das noch wenig Sinn.


Ich hoffe das man bei Zen6 deutlich weiter sein wird und die Kerne auf einem Base Die sitzen.

Irgendwann muss man halt auch den teureren Schritt beim Packaging wählen.

Die Prozess Nodes werden von Gen zu Gen deutlich teurer und der 0815 Konsument kauft eh schon seit Jahren gefühlt kein highend mehr, weil es zu teuer geworden ist.

Ab einem bestimmten Punkt ist es sinnvoller etwas tiefer in die Tasche zu greifen für das Packaging.

TSMC stampft nicht umsonst die Advanced Packaging Fabs aus dem Boden. Wer das nicht nutzen wird, wird verlieren.

[HPVD]

Maybe Zen 5 based Epyc will already support a first version of MR-DIMMs (multi-ranked buffered DIMMs)
which (theoretically) multiply the memory bandwidth
without more channels and/or higher frequencies.

This is becoming a new open JEDEC Standard
see https://www.tomshardware.com/news/amd-advocates-ddr5-mrdimms-with-speeds-up-to-17600-mts
https://wccftech.com/amd-jedec-working-on-ddr5-mrdimm-adoption-as-an-open-standard-up-to-17600-mbps-memory-speeds-by-203x/
https://www.linkedin.com/feed/update/urn:li:share:7046995582770450432/

and comparable to Intels/sk-hynix MCR DIMM
https://www.computerbase.de/2022-12/ddr5-mcr-dimm-sk-hynix-bringt-mit-renesas-und-intel-schnellsten-server-ram/

edit: hmm falsche Sprache...

[basix]

Prinzipiell DDR, einfach auf Rank Ebene. Finde ich eine smarte Lösung, auch wenn ich nicht ganz verstehe wie das mit den physischen Leitungen dann aufgeht.

[Der_Korken]

Langfristig wären mehr als 8 Kerne mit gemeinsamen Cache bzw. schnellem Datenaustausch schon sinnvoll. Aktuell hat ein 7800X3D noch genügend Rechenpower, aber darüber hinaus haben zwei CCDs bei der aktuellen Architektur dann doch einige Nachteile. Entweder hebt man die CCX-Größe auf z.B. 12 Kerne an oder man verändert die Speicherhierachie, z.B. der erwähnte L3 im IOD (L1 und L2 wachsen dann massiv mit, eventuell bietet sich beim L2 ein IBM'sches sharing der L2-Slices an?).

[Nightspider]

Entweder hebt man die CCX-Größe auf z.B. 12 Kerne an oder man verändert die Speicherhierachie, z.B. der erwähnte L3 im IOD (L1 und L2 wachsen dann massiv mit, eventuell bietet sich beim L2 ein IBM'sches sharing der L2-Slices an?).

Oder man klatscht eine "beliebig" große Anzahl an Kernen in 4er oder 6er Grüppchen per 3D Stacking auf einen Base Die und dieser Manycore Chip verhält sich wie ein einziger, monolithischer Chip.

Dürfte nicht mehr lange dauern imo.

Irgendwann wird man sicherlich auch HBM4 oder ähnliches aufs Package klatschen als Zwischenstufe vor dem RAM. AMD hat ja jetzt schon Probleme 96 Kerne mit Bandbreite zu versorgen. Apple bietet bis 128 GB LPDDR5 mit arschviel Bandbreite in einem f*cking Laptop.

Bin mir jetzt aber nicht sicher, ob die Anwendungen, die viel RAM Bandbreite benötigen auch immer im gleichen Maße von V-Cache profitieren.


Zur Erinnerung:
AMD lässt für den Premium Markt jetzt in den kommenden Monaten schon solche Monster fertigen:

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

Und da sitzen 3 Zen4 Chiplets eventuell auch schon auf einem gemeinsamen Base Die.

TSMCs Advanced Packaging Fab AP2C ist seit dem zweiten Halbjahr letzten Jahres in Betrieb. Da dürften gerade die Linien für die Massenproduktion komplexer Designs hochgefahren werden.

Und weitere Fabs folgen

[basix]

EPYC in der heutigen Form hat zwei riesige Vorteile verglichen mit MI300:
- Skalierbarkeit
- Kosten

Ein Beschleuniger kann viel einfacher auf eine mehr oder minder einzelne SKU getrimmt werden. Bei Server-CPUs brauchst du von 8-96C alles. Die Anforderungen sind einfach anders. Und gerade die seit Zen 2 eingeführte Bauweise mit IOD und N-mal CCDs ist für normale Serveranwendungen einfach optimal skalierbar und gleichzeitig kosteneffizient.

Wo ich dir aber beipflichten kann:
MI300 ist wohl die Basis von AMDs "XPU (Intel-Sprech) (https://www.servethehome.com/intel-announces-it-is-ending-traditional-hpc-platforms/)". Man hat 4 Tiles und kann die beliebig konfigurieren (1-4x Tiles von CPU, GPU, FPGA, AI-Accelerator, ... in beliebiger Kombination). Durch die Base-Tiles wird das an eine einheitliche Infrastruktur angebunden (SP5-Sockel mit 12x DDR5 Channels, 160x PCIe 5.0x Lanes sowie neu 8x HBM3-Stacks obendrauf). Das ist aber nicht ein Ersatz für normale EPYC CPUs, dazu ist das Konstrukt viel zu teuer. Nicht jeder braucht so viel Compute, SRAM oder HBM. Dafür sind immer noch normale MCM CPUs mit IOD + CCD da.

[Hatstick]

Lohnt sich denn nicht, eigene Fabs zu bauen und die Herstellung von A bis Z in eigener Hand zu haben oder stelle ich mir das zu leicht vor?

[amdfanuwe]

Wenn man den L3 in den IO Die verlagern will, so müsste man:
a) Den L2 deutlich vergrößern z.B. auf 4MB/Kern
b) Die Latenz der Die zu Die Kommunikation verringern
c) Die Bandbreite zwischen CCD und IO vergrößern

Dafür hätte man folgende Vorteile:
.) Bei 2 CCDs oder mehr (Datacenter) kann der L3 von allen Kernen gemeinsam genutzt werden
.) Scheduling wäre einfacher
.) L3 ist zur Gänze am günstigeren Node
.) Man hat weniger thermische Probleme da der IO Die nicht so warm wird
.) Man kann im Fall einer APU den Cache auch durch die GPU nutzen
Nicht den L3 in das I/O. IF$ in das I/O.
Du musst den Caches einer Datenverbindung zuordnen, die diese entlasten sollen.
IF$ entlastet das SI, L3 auf Chiplet entlastet den Datentransfer zwischen Chiplet und I/O. L1/L2 entlasten den Zugriff einzelner Kerne auf den L3.
Die Latenz der Die zu Die Kommunikation ergibt sich doch aktuell daraus, dass die Daten erst in das RAM geschrieben werden und dann das andere Die diese lesen kann. Es kann ja nicht von einem L3 auf einen anderen L3 zugegriffen werden.
IF$ würde das doch ordentlich beschleunigen.
An der Bandbreite wird mit 2 Links pro CCD ja schon gearbeitet.
Also durch höhere Bandbreite und IF$ im I/O kann man den L3 verkleinern, größere L2 helfen den einzelnen leistungsfähigeren Cores besser unter Dampf zu bleiben. Das muss alles ausgeglichen sein, sonst verhungern die Kerne oder es steht ungenutzte Bandbreite zur Verfügung, die die Kosten hoch treibt. Letztendlich immer ein Kompromiss.
Beim Speicherinterface stößt man an die Grenzen, jetzt schon 12 SI bei Genoa, die wissen kaum noch, wie sie die Dimms unterbringen sollen.
Im Desktop hat man 2 SI und die Kerne werden schneller. Größere Caches sind aber teuer. Da macht es schon Sinn den Engpass SI durch IF$ zu erweitern und dadurch die anderen Caches zu entlasten.
Die Vorteile hast du ja aufgezählt.

[Nightspider]

Lohnt sich denn nicht, eigene Fabs zu bauen und die Herstellung von A bis Z in eigener Hand zu haben oder stelle ich mir das zu leicht vor?

Nein, du stellst dir das viel zu leicht vor. Für Intel sind die Fabs sogar zum Klotz am Bein geworden.

TSMC hat das KnowHow über 40 (?) Jahre lang aufgebaut und haben Intel in den letzten 10 Jahren in mehreren Bereichen überholt.

Was glaubst du wie lange das dauern würde, wenn eine Firma bei 0 anfangen würde?

Ganz China hängt 10 Jahre zurück, wenn sie eigene Belichtungsmaschinen selber bauen müssten und beim Packaging siehts bestimmt genauso übel aus.
China hat die Industrie mit Geld beworfen aber es war nur ein Tropfen auf dem heißen Stein. Aus Geld wird nicht plötzlich Knowhow.

Das ist aber nicht ein Ersatz für normale EPYC CPUs, dazu ist das Konstrukt viel zu teuer.

Es geht ja nur um die Möglichkeiten und Vorteile durch Advanced Packaging.

Und einige Tiles lassen sich über mehrere Generationen wiederverwenden, wodurch Entwicklungszeit und Geld gespart wird - das sagt sogar AMD.

[Complicated]

Der L3$ der 2er Gruppe wäre "Unified". Inkl. Kohärenz. Deswegen die höhere Bandbreite zwischen den CCDs. Der Witz der 2er Gruppe wäre ja gerade, dass es gegen aussen wie ein einzelnes 16C CCD aussehen würde. Das ist die Grundidee.

Der "Remote"-L3$ des anderen CCD wird zusätzliche Latenz aufweisen, ganz klar. Keine Ahnung, evtl. 15ns anstatt 10ns.
Eben. Das aussehen nach aussen wie ein 16er CCD ist unnötig komplex und macht alle Vorteile zunichte. Da gibt es paper, welche die Nachteile beschreiben und als schlechtere Lösung nachweisen.

Die Zukunft geht eher in Richtung Double Butterfly Mesh bei höherer Komplexität. Und in höheren Preislagen aktive Silizium Interposer mit Routing Beschleunigern bei steigendem Corecount. Vor allem betrachtet man die immer noch bestehenden Engpässe bei Substraten, könnte der aktive Interposer wieder schneller eine Rolle spielen.

https://www.eecg.toronto.edu/~enright/micro14-interposer.pdf

[amdfanuwe]

EPYC in der heutigen Form hat zwei riesige Vorteile verglichen mit MI300:
- Skalierbarkeit
- Kosten

Man hat 4 Tiles und kann die beliebig konfigurieren (1-4x Tiles von CPU, GPU, FPGA, AI-Accelerator, ... in beliebiger Kombination). Durch die Base-Tiles wird das an eine einheitliche Infrastruktur angebunden (SP5-Sockel mit 12x DDR5 Channels, 160x PCIe 5.0x Lanes sowie neu 8x HBM3-Stacks obendrauf). Das ist aber nicht ein Ersatz für normale EPYC CPUs, dazu ist das Konstrukt viel zu teuer. Nicht jeder braucht so viel Compute, SRAM oder HBM. Dafür sind immer noch normale MCM CPUs mit IOD + CCD da.
Durch die 1-4x Tiles bestückbar mit verschiedenen Logik Dies ist das doch auch gut skalierbar.
Nimm den HBM weg, dann ist auch Platz an den Seiten für die Logik Dies und kein stacking notwendig. wird dann wieder günstiger.
Wenn man zukünftig auf IF$ geht, braucht man auch den Platz im I/O dazu.
12 * 16MB machen ca. 120mm² aus. Aus Yield Gründen kann es da schon sinnvoll sein auf mehrere gekoppelte I/O zu gehen statt auf einen großen wie bei Rome bis Genoa.
Man hat ja auch noch Siena demnächst, braucht dann eben nur 2 i/O statt 4 wie bei MI300 für SP5.
Vielleicht kommt ja noch eine kleine Plattform mit einem I/O, 3SI etc.
MI300 wird durch HBM und Stacking teuer, das ist ein High End Produkt. Muss ja nicht der gleiche Aufbau für alle SKUs sein.

Edit: was man bei MI300 sieht, ist der vergossenen Tile, bedeutet ja nicht, dass der Base Die auch so groß ist. Ich würde ein Base Die eher auf 150-200mm² schätzen ( 400mm² Genoa I/O / 4 + IF$ + weitere IF-Links).

Lohnt sich denn nicht, eigene Fabs zu bauen und die Herstellung von A bis Z in eigener Hand zu haben oder stelle ich mir das zu leicht vor?
Ja.
Siehe Intel.

Es ist besser auf spezialisierte Firmen auszulagern. Wenn es da dann noch mehrere gibt ist man flexibel in der Preisverhandlung und kann auch zur Konkurrenz gehen, wenn die Leistung nicht mehr stimmt.
Sieht man ja auch an Nvidia, dass die mal gerne bei Samsung fertigen lassen.

[amdfanuwe]

Vor allem betrachtet man die immer noch bestehenden Engpässe bei Substraten,
AMD meint, sie hätten da keine Engpässe mehr.
Sonst würden sie auch kaum billig Prozessoren rausgeben ( 5600G, 5600 )

[Der_Korken]

Nicht den L3 in das I/O. IF$ in das I/O.
Du musst den Caches einer Datenverbindung zuordnen, die diese entlasten sollen.
IF$ entlastet das SI, L3 auf Chiplet entlastet den Datentransfer zwischen Chiplet und I/O. L1/L2 entlasten den Zugriff einzelner Kerne auf den L3.
Die Latenz der Die zu Die Kommunikation ergibt sich doch aktuell daraus, dass die Daten erst in das RAM geschrieben werden und dann das andere Die diese lesen kann. Es kann ja nicht von einem L3 auf einen anderen L3 zugegriffen werden.
IF$ würde das doch ordentlich beschleunigen.


Was ist denn der Unterschied zwischen einem L3 und einem IF$? Im Grunde nur der Name. Der IF$ auf den GPUs könnte genauso gut L3 heißen und ein IF$, den man zusätzlich zum L3 auf den CPU-CCDs noch auf den IOD packt, könnte genauso gut L4 heißen. Der Grund warum man ihn doch als L3 auslegen könnte, wäre dass ein L4 nochmal deutlich größer als der L3 auf den CCDs sein muss, um überhaupt einen Vorteil zu bieten abseits der Kommunikation. Würde man den L4 z.B. nur 32MB groß machen, wäre die Hitrate weit unter 50%, denn alles was in 32MB passt hat jeder CCD sowieso schon gecached.

Chips and cheese hat für RDNA2 mal u.a. Cache-Hirates gebencht (Link (https://chipsandcheese.com/2023/02/19/amds-rdna-2-shooting-for-the-top/)) und der L1, welcher mit 128kB kleiner ist als die L0-Caches unter ihm (5x32kB) hat in allen Szenarien eine extrem schlechte Hitrate. Beim Beispiel von Raphael müsste ein L4 auf dem IOD also mindestens 64MB groß sein, damit er überhaupt was bringt, eher 128MB. Wird der L3 gestackt, verschiebt sich der breakeven für den L4 noch weiter nach oben. Man muss auch bedenken, dass es viel Latenz kostet etliche Cache-Stufen hintereinander zu durchsuchen. Auf den 10ns-L3-Lookup auf dem CCD würde dann noch ein 15ns-L4-Lookup auf dem IOD erfolgen, bevor im RAM geguckt wird. Heißt: Die Speicherlatenz steigt um 15ns an. Wenn die Hitrate des L4 dann nicht gut ist, würde man im Schnitt sogar Leistung verlieren statt gewinnen.

Imho ist es deswegen denkbar, dass man die L3-Ebene auf den IOD verschiebt, damit man nicht soviel redundanten Cache hat. Bei Epyc stellt sich das natürlich anders dar, da ein zentraler L3 viel mehr Clients hat und somit auch eine viel schlechtere Latenz. Hier würde man sich vielleicht darauf beschränken einen L3 pro Quadranten zu haben, der nur 3-4 CCDs bedienen muss.

Eben. Das aussehen nach aussen wie ein 16er CCD ist unnötig komplex und macht alle Vorteile zunichte. Da gibt es paper, welche die Nachteile beschreiben und als schlechtere Lösung nachweisen.


Den Einwand verstehe ich nicht so richtig. Der Vorschlag von basix klang für mich eher so, als würde man das Gegenteil machen wie bei Zen 2: Statt zwei CCX auf einem Die, ist ein CCX jetzt über zwei Dies verteilt. Dadurch verringert sich in der übergeordneten Ebene die Komplexität der Topologie, weil nur noch halb so viele CCX vorhanden sind. Wie man die auf dem IOD verbindet ist dafür irrelevant.

[Complicated]

Die zusätzliche Ebene ist der schlechtere Tradeoff. Die 2CCX auf einem Die sind ebenfalls in 1x 8 Core CCX überführt worden um dies zu optimieren. Warum sollte man diesen Rückschritt machen, wenn es bessere Lösungen gibt?

[Complicated]

Was ist denn der Unterschied zwischen einem L3 und einem IF$? Im Grunde nur der Name. Der IF$ auf den GPUs könnte genauso gut L3 heißen und ein IF$, den man zusätzlich zum L3 auf den CPU-CCDs noch auf den IOD packt, könnte genauso gut L4 heißen.
IF$ ist shared L1 Cache. Das ist nicht vergleichbar mit zusätzlichem L3 Cache.

Aus dem Patent:
• "We propose shared L1 caches in GPUs. To the best of our knowledge, this is the first paper that performs a thorough characterization of shared L1 caches in GPUs and shows that they can significantly improve the collective L1 hit rates and reduce the bandwidth pressure to the lower levels of the memory hierarchy."

[Windi]

Es wird wahrscheinlich eh wieder so werden, das Apple mindestens ein Jahr Vorsprung vor AMD bei den neusten TSMC Technologien haben wird.

Schon heute nutzt Apple modernere Packaging Methoden als AMD um ihre großen APUs zu realisieren.

Also erwarte ich beim Packaging erst größere Änderungen bei Zen 6.
Vielleicht kommen bei Zen 5 die kleinen Silizium Brücken zwichen den Chiplet, die Apple momentan nutzt.

[Der_Korken]

Der Vorteil wäre, dass innerhalb eines solchen 16er CCX der L3-Cache effizienter genutzt wird, weil man Redundanzen und Schreibkonflikte vermeidet. Und die Zugriffe auf den IOD werden theoretisch geringer, was Strom spart.

Ob es eine zusätzliche Ebene ist, ist für mich gar nicht so klar, da man theoretisch die beiden L3-Ringe von zwei CCDs aufschneiden und per IF-Link(s) aneinanderhängen kann. Das verschlechtert erstmal nur die durchschnittliche L3-Latenz eines 16er CCX, aber das ist ja keine zusätzliche Ebene. Habe ich noch andere Nachteile übersehen?

[Complicated]

Das ist ja kein 16er CCX, den er beschrieben hat. Es sind 2x8er CCX von denen nur einer im NoC hängt und der zweite über den ersten mit einem weiteren Hop angesprochen würde. Dies wäre für 50% aller Cores ein zusätzlicher Hop bei jedem Zugriff! Und wenn Daten von einem der entfernten Cores zum anderen muss, also auch für 50% der Cores, sind es sogar 2 zusätzliche Hops.

Und mit zwei L3 Ringen hast Du dann Intels aktuelle Limits wieder. Infinity Link ist auch eine P2P Verbindung wie PCIe. Da kannst du nicht 2 L3 Caches miteinander verbinden als Pools. Du brauchst ein NoC das die kürzesten Verbindungen mit der geringsten Hop Zahl ermöglicht.

[amdfanuwe]

Was ist denn der Unterschied zwischen einem L3 und einem IF$? Im Grunde nur der Name.
Nein.
Der IF$ ist einem Speicherkanal zugeordnet. Dadurch gibt es auch keine Probleme mit der Kohärenz zwischen den einzelnen IF$.
Hat man doch bei RDNA3 gesehen.

Dadurch ließe sich auch der I/O problemlos in mehrere kleinere gekoppelte I/O aufteilen.
Bei einem L4 im I/O wäre das schwer möglich, da dann wieder die Kohärenz zwischen den einzelnen L4 auf den I/O Tiles sichergestellt werden muss.

IF$ ist eben kein dicker Cache der alle Anfragen abfängt, wie es L2/L3 auf ihrer Ebene machen.
IF$ cached nur das zugehörige SI.
Vielleicht nicht ganz so effektiv wie ein dicker L4, dafür skalierbar, unified, kohärent und einfacher im Aufbau.
Im Prinzip eine simple Technik und man wundert sich, dass das nicht schon länger eingeführt wurde anstatt die SI immer nur zu vergrößern.
83343

[Der_Korken]

Das ist ja kein 16er CCX, den er beschrieben hat. Es sind 2x8er CCX von denen nur einer im NoC hängt und der zweite über den ersten mit einem weiteren Hop angesprochen würde. Dies wäre für 50% aller Cores ein zusätzlicher Hop bei jedem Zugriff!

[...]

Infinity Link ist auch eine P2P Verbindung wie PCIe. Da kannst du nicht 2 L3 Caches miteinander verbinden als Pools.

OK, jetzt verstehe ich es.

Nein.
Der IF$ ist einem Speicherkanal zugeordnet. Dadurch gibt es auch keine Probleme mit der Kohärenz zwischen den einzelnen IF$.

Eigentlich ist das die normale Funktionsweise eines Caches. Ein Cache ist in Cache-Sets aufgeteilt und innerhalb der Sets kann jede Cache-Line an beliebiger Stelle stehen. Haben die Cache-Sets eine Größe von n Lines, ist er n-fach-assoziativ.

Der L3 von Zen 4 z.B ist 16-fach-assoziativ, d.h. ein Cache-Set ist 16*64Byte (Cache Line Size) = 1kB groß. Also sind es insgesamt 2^15 = 32768 Cache-Sets. Da jeder Speichercontroller einem bestimmten phyischen Adressbereich zugeordnet ist, kann ich das so arrangieren, dass jedem Speichercontroller entsprechend Cache-Sets zugeordnet werden, die die jeweiligen (phyischen) Speicheradressen beinhalten können. Gäbe es weniger Cache-Sets als Speicherkanäle, hättest du mit deiner Aussage Recht, aber in der Praxis ist es natürlich massivst andersrum.

[amdfanuwe]

Da jeder Speichercontroller einem bestimmten phyischen Adressbereich zugeordnet ist,
Wird der nicht interleaved betrieben? Da wird es schon schwieriger mit der assoziativität.
OK, bin da kein Fachmann in Sachen Cache.
Ich belass es dabei und lass mich überraschen, was AMD letztendlich bringt.

[basix]

Der Vorteil wäre, dass innerhalb eines solchen 16er CCX der L3-Cache effizienter genutzt wird, weil man Redundanzen und Schreibkonflikte vermeidet. Und die Zugriffe auf den IOD werden theoretisch geringer, was Strom spart.

Jep und Jep. Und man behält die CCD Fläche gering, da man da bei 8C bleibt.


Ob es eine zusätzliche Ebene ist, ist für mich gar nicht so klar, da man theoretisch die beiden L3-Ringe von zwei CCDs aufschneiden und per IF-Link(s) aneinanderhängen kann. Das verschlechtert erstmal nur die durchschnittliche L3-Latenz eines 16er CCX, aber das ist ja keine zusätzliche Ebene.
Das wäre eben auch mein Gedankengang. Ein zusätzliche Ebene gibt es bei diesem Konzept nicht. Ob es dann 2x gekoppelte Ringe sind oder wie man das auch löst, ist mal nicht relevant. Und wie hoch der Latency Hit ist, wenn man auf den "Remote-L3$" zugreift, ist mir unbekannt. Kann zwischen 2-10ns alles sein.

Ach ja, und man könnte das CCD mit nur geringem Overhead an eine APU flanschen ;) (APU = IO, iGPU, 4-8 Zen 4c/5c Cores).

Das ist ja kein 16er CCX, den er beschrieben hat. Es sind 2x8er CCX von denen nur einer im NoC hängt und der zweite über den ersten mit einem weiteren Hop angesprochen würde. Dies wäre für 50% aller Cores ein zusätzlicher Hop bei jedem Zugriff! Und wenn Daten von einem der entfernten Cores zum anderen muss, also auch für 50% der Cores, sind es sogar 2 zusätzliche Hops.
Falsch. Jedes CCD ist direkt mit dem IOD/NoC verbunden. Nichts mit zusätzlichen Hops. Siehe mein Schaubild: https://www.forum-3dcenter.org/vbulletin/showthread.php?p=13272760#post13272760
- 1x CCD = 1x IFOP Link
- 2x CCD = 2x IFOP Link

Der Infinity Link dient einzig folgendem Zweck:
- Shared L3$
- Verkürzte Core-To-Core Kommunikation zwischen den CCDs, da nicht über IOD gewandert werden muss

Durch die 1-4x Tiles bestückbar mit verschiedenen Logik Dies ist das doch auch gut skalierbar.
Nimm den HBM weg, dann ist auch Platz an den Seiten für die Logik Dies und kein stacking notwendig. wird dann wieder günstiger.
Das Problem ist, dass man immer alle 4 Tiles benötigt, wenn man das volle IO-Programm für SP5 haben will. Das ist inhärent teurer, als wenn ich einen z.B. einen normalen 32-64C EPYC verwenden will, weil der für meine Anwendung ausreicht. Natürlich kann man das ähnlich Siena auf 2 Tiles beschränken. Dies ist aber wiederum deutlich teurer als Siena...

Solange man den zusätzlichen stacked Cache und/oder HBM nicht benötigt, ist es einfach zu teuer und ohne Vorteile.

[Complicated]

- 2x CCD können zusammengeschaltet werden und bilden ein "16C-Super-CCD" --> RDNA3 mässige "Infinity Links". Shared L3$ zwischen den zwei CCD
Du kannst nicht beides haben. Jeder CCD seine eigene Anbindung oder den Super-CCD mit gemeinsamem L3.

Dein Schaubild zeigt das selbe wie es mit 2x 4er CCX auf einem CCD war. Die Verbesserung bestand in dem 8er CCX pro CCD. Skaliert du das nun, kommen alle überwundenen Nachteile zurück und zusätzlich bleibt der Platzverbrauch für die 8-Kern CCX Interconnects.

[basix]

Dann kläre mich bitte auf, wieso dem so sein soll. Was sind denn die technischen Gründe, wieso man den Cache nicht sharen kann und trotzdem jedes CCD direkt mit dem IOD verbunden ist?

[Complicated]

Hab es eben in meinem Beitrag ergänzt.

[Der_Korken]

Wird der nicht interleaved betrieben? Da wird es schon schwieriger mit der assoziativität.
OK, bin da kein Fachmann in Sachen Cache.
Ich belass es dabei und lass mich überraschen, was AMD letztendlich bringt.

Interleaved würde viel Sinn machen. Man muss natürlich die Cache-Verwaltung mit der RAM-Verwaltung abstimmen, aber letztlich kann ich mir beim Cache aussuchen welche der Adressbits ich für die Zuweisung zu Cache-Sets verwende. Natürlich sollte die Granularität des Memory-Interleaving nicht kleiner als eine Cache-Line sein, aber ich glaube da hätte man ganz andere Probleme, wenn man das so machen würde.

Ansonsten sieh es mal so: Bei Intels Ringbus muss, sobald ein Kern eine Anfrage an den L3 sendet, auch schon anhand der Adresse erkennbar sein, in welchem L3-Slice man suchen muss. Könnte die Adresse in jedem L3-Slice liegen, müssten bei Raptor Lake 12 Cache-Slices sequenziell durchsucht werden. Um das innerhalb von 50 Takten zu schaffen, dürfte es pro Slice nur 4 Takte dauern - für 3MB. Das kann offensichtlich nicht stimmen. Edit: Und parallel durchsuchen kann auch nicht sein, denn dann hätte ich bei jeder L3-Anfrage 12 parallele Zugriffe. Wenn jeder Teilnehmer eine Anfrage sendet, wären das 144 Anfragen. Der Durchsatz des Caches müsste quadratisch mit der Anzahl der Teilnehmer steigen, um diese Flut bewältigen zu können.

[basix]

Hab es eben in meinem Beitrag ergänzt.
Ich weiss was du meinst. Bei Zen 1 hatte man den direkten Link zwischen den CCX aber nicht. Bei Zen 1 musste alles via CCM über den SDF, welcher mit ~DRAM Takt lief. Latenz >100ns laut Anandtech Core-to-Core Latency Test. Bandbreite konnte ich auf die schnelle nicht rausfinden, viel mehr als DRAM-Bandbreite aber wohl nicht. Bei Zen 5 wäre Infinity Link und SDF voneinander entkoppelt und die zwei CCX würden direkt via Infinity Link miteinander kommunizieren. Davon bekommt der SDF auf dem IOD gar nichts mit. Für den IOD sieht das Konstrukt wie ein einzelnes grosses Unified CCX mit 16C aus, welches mit 2x IFOP angebunden ist (siehe z.B. neu Zen 4 EPYC mit "GMI3-Wide (https://www.semianalysis.com/p/amd-genoa-detailed-architecture-makes)" Anbindung).

Der direkte Infinity Link kann gegenüber dem SDF bei Zen 2+ zudem deutlich performanter sein, da 1 vs. 2 Hops, viel breiter und potentiell höher getaktet sowie ohne den restlichen SDF Overhead (Logik usw.). Man wird nicht die Performance eines "richtigen" 16C CCX erreichen, aber näherungsweise wohl schon.

Edit:
Hier ein Typ, der die Core-to-Core Bandbreite bei Zen 1 gemessen hat. Sind anscheinend ~14 GByte/s bei hohem Latenzzuwachs.
https://dpzmick.com/posts/2020-05-10-ryzen-memory.html

Das sollte via breitem und kurzem Infinity Link heutzutage doch deutlich fixer klappen.

[amdfanuwe]

Solange man den zusätzlichen stacked Cache und/oder HBM nicht benötigt, ist es einfach zu teuer und ohne Vorteile.
Welchen stacked Cache?
Kann ja auch mehrere I/O Dies geben. Je nach gewünschten Chiptyp.
Single Chip wie bei Genoa.
kleine I/O mit IF$, skalierbar.
Und entsprechend I/Os skalierbar mit HBM Interface für MI300 und weitere HPC Chips.

Wird sich AMD schon ausrechnen, mit welchen I/O Varianten sie den größten Gewinn machen.
Es ist zumindest mal sicher, dass AMD Variantenreicher wird.

Xilinx darf man auch nicht vergessen.
83351

Da besteht auch Bedarf an entsprechenden Platformen mit HBM, PCIe, DDR.

Lisa zeigte ja schon, wo es hingeht
83352

Oh, scheinen auch wieder 4 I/O Base Tiles zu sein.

[Complicated]

Ich verstehe auch was du meinst. Nur dieser Part ist so nicht umsetzbar, sondern führt zu dem was ich beschrieb

Bei Zen 5 wäre Infinity Link und SDF voneinander entkoppelt und die zwei CCX würden direkt via Infinity Link miteinander kommunizieren.
Du kannst SDF nicht vom IF-Link entkoppeln:The two CCX's (https://en.wikichip.org/w/index.php?title=amd/cpu_complex&action=edit&redlink=1) are directly connected to the SDF plane using the Cache-Coherent Master (CCM) which provides the mechanism for coherent data transports between cores.
https://en.wikichip.org/w/images/thumb/8/8f/amd_zeppelin_sdf_plane_block.svg/400px-amd_zeppelin_sdf_plane_block.svg.png
https://en.wikichip.org/wiki/amd/infinity_fabric

Das was ich beschrieb tritt dann eben ein. Das ersetzten des SDF ist IMHO kaum möglich ohne ein vollständig anderes Konstrukt für das Management des Interconnects und I/O. Einfach mit IF-Links ist es nicht getan.

[basix]

Das was ich beschrieb tritt dann eben ein. Das ersetzten des SDF ist IMHO kaum möglich ohne ein vollständig anderes Konstrukt für das Management des Interconnects und I/O. Einfach mit IF-Links ist es nicht getan.

Klar braucht es da etwas neues. Ist aber immerhin die 5. Zen Generation und die erste "Totalüberholung" des Zen-Designs ;)

Ein Zusammenschalten von mehreren CCDs wäre für alle Folgegenerationen wertvoll. Bei Zen 5 sind es evtl. nur max. 2x CCDs. Bei Zen 6 aber evtl. 4 usw.
Und allenfalls ist dieser Overhaul des Cache-Systems ebenfalls ein Vorbereiten auf "True 3D-Stacked" CCDs, wo IO + L3$ unten liegen und die Core-Chiplet(s) obendrauf kommen.

[Complicated]

Wahrscheinlicher ist, dass AMD den IF$ auf CPUs überträgt. Das ist der logische nächste Schritt. Dadurch wird die gemeinsame L1 Hitrate verbessert und der Druck auf L2 und L3 reduziert und dadurch effizienter bei der Nutzung und auch beim Stromverbrauch. Den L3$ unter den CCDs zu plazieren würde dies auch optimieren.
Ein MCD mit IF$ unter den CCD (Unified L1$) und den L3$-Die darunter, wäre meine Vermutung. MCDs lassen sich über CCDs hinweg skalieren.
Damit vermeidet man diese Clusterung von CCDs vollständig. Anstatt mehr Daten über L3 zu verschieben, rückt das näher an die CPU in L1 und L2. Und vor allem entwickelt man funktionierendes iterativ, anstatt zurück zu fallen auf Lösungen, die auch die Konkurrenz wieder in Reichweite bringt.

[robbitop]

Der IF$ ist doch ein LLC bei rdna2/3 der jeweils an den IMC gekoppelt ist.


Bild:
https://www.servethehome.com/wp-content/uploads/2021/08/HC33-AMD-RDNA-2-New-Cache-Hierarchy.jpg

Ansonsten noch


To avoid memory bandwidth bottlenecks, RDNA 2 gets an extra level of cache. AMD dubs this “Infinity Cache”, and internally refers to it as MALL (memory attached last level).

https://chipsandcheese.com/2023/02/19/amds-rdna-2-shooting-for-the-top/


Der ist doch um Größenordnungen langsamer (Latenz). Wie soll das der L1 Cachehitrate helfen?

Aus dem Chipsandcheese Artikel:
L1 Latency: 25 ns
IF$ Latency: 148 ns


—————————————————
IMO zu einem komplett geteilten Cache bei Zen 5:
sobald man vom CCX runter muss, wird es von der Latenz her langsamer (es sei denn das geschieht vertikal und nicht über eine fabric). Mit modernerem Packaging und räumlichen Zusammenrücken von den Chiplets und einem schnelleren Interconnetcs kann man ggf auch noch was machen.
Ggf packt man ja das IOD unter die CCX und könnte so den Cache räumlich schön nah dran behalten und dann über eine extra möglichst schnelle Interconnect mit so wenig wie möglich hops.

Meine Spekulation: Ggf behalten sie das Cachesystem ja auch einfach so bei. Es ist kein schlechter Kompromiss aus Geschwindigkeit und Größe. Aber man macht den L1 größer. Und dazu den ROB, den uOp Cache, die decoder breiter und ggf noch mehr Breite in execution. Nach dem Vorbild der modernen Apple Cores.

[latiose88]

hm ok also damit verbessert AMD dann die Hitrate,verstehe.Ab wieviel Missrate kann man von kaum vorhanden Sprechen,etwa bei 0,10 oder erst bei noch weniger Missrate?
Und was heißt das denn auf die Leistung,also sprich was sagt es denn über die Leistung aus oder heißt das ,das es eher weniger vom L1 Cache Profitiert als gedacht?

Hm ähm was ist denn bei CPU denn ROB,etwa auch die Bandbreite.Uop ist soweit ich weis der Allzweck Register oder irre ich mich da.Beim Decoder der sortiert doch die ganzen Befehle nicht wahr? Dann kann der noch viel effizienter das ganze sortiert und es noch besser Umsetzen,auch nicht schlecht.Execution sind doch bei CPU so Einheiten wie Transistoren.Naja ob AMD diese Breiter macht bei Zen 5,mal sehen.Da bin ich mir ja nicht ganz sicher.

[Complicated]

IF$ ist hier gut zusammengefasst.
https://www.reddit.com/r/Amd/comments/j609v7/amd_infinity_cache_patent_and_white_paper_details/

Hier ein Video das die Funktionsweise beschreibt:
CGIhOnt7F6s

Das Video stammt von einem der Autoren. Das zugehörige Paper zum nachlesen: https://adwaitjog.github.io/docs/pdf/sharedl1-pact20.pdf

[robbitop]

Also ich sehe den eigentlichen (von AMD mit rdn2 offiziell vorgestellt und beschriebenen) Infinity Cache weder in dem Video noch in dem Reddit post (auch wenn da der Begriff aber überhaupt nicht der Kontext dazu fällt). Da geht es anscheinend darum die L1 Caches von den CUs über ein Mesh mit den L1 aller anderen CUs in einer GPU zu verbinden. Je nach Anzahl der hops wird das aber Latenz kosten - was bei GPUs aber durch die hohe Anzahl an Threads in Flight nicht so schlimm ist wie bei CPUs.
Der IF$ wie von AMD vorgestellt ist doch aber ein separater Cache der an der Infinity Fabric und den IMCs hängt und eher ein Last Level Cache ist.

Ich habe den Eindruck, dass das von dir angesprochene Patent unabhängig davon ist und etwas anderes ist.

Btw werden L1 Caches in aktuellen rdna 2/3 GPUs überhaupt schon geshart? Das wäre mir neu. Patente gibt es ja viele….Das heißt erstmal nicht zwangsweise, dass Dinge so (oder überhaupt schon) umgesetzt sind.
Im Chipsandcheese Artikel sieht es für mich eher so aus als wenn der L1 pro WGP exklusiv ist.

[iamthebear]

Wenn AMD dafür die IPC gewaltig erhöhen könnte, dank +50% Space für die Kerne, dann könnte man damit noch immer vor Zen4 landen bei der Gaming Performance, wobei das stark aufs Spiel und die Abhängigkeit vom Cache abhängen würde.

Wenn schon bei den Vorgängern 16MB L3 stark limitieren dann wird das mit noch schnelleren Kernen kaum besser werden.
Was man auch nicht unterschätzen darf: Die Spiele entwickeln sich auch weiter und brauchen immer mehr L3. Das hat man z.B. gut bei den CB Reviews des 5800X3D gesehen. Bei den ersten Reviews waren es noch 15% Vorsprung auf den 5800X. Mit dem neuen Benchmarkparkour dann auf einmal um die 30%. Ähnlich verhält es sich mit ADL vs. Comet Lake.

Über dem Cache gibt es keine thermischen Probleme, würde ich jetzt mal behaupten. An der Schicht über den Cores würde sich nichts ändern.

Der VCache liegt auch bereits jetzt schon nur über dem L3 und trotz 10% weniger Takt ist die Temperatur immer noch sehr kritisch.
Du hast Recht über den Kernen reicht zwar eine zusätzliche Schicht an Dummy Silizium aber diese muss doppelt so dick sein.

Sind die 5$ aus der Luft gegriffen oder soll das der reale Preis sein? Je höher die IPC und der Takt steigt, desto mehr Cache wird im Laufe der Zeit benötigt, erst recht wenn der L3 bei Zen5 vom Takt entkoppelt und niedriger takten würde.
Ich denke mal 2 Lagen SRAM zu stacken ist noch relative einfach und nicht so kostenintensiv.

Ein N6 Wafer kostet um die 10K und hat ca. 70K mm². Damit gehen sich von der Fläche her um die 2K VCache Dies aus. Yields sind nahe 100% und Verschnitt am Rand auch zu vernachlässigen.
Was bei so kleinen Dies eine Rolle spielt sind die Scribe Lines, da man die Dies ja auch schneiden muss aber das wird mit noch kleineren Dies ja schlimmer statt besser.

Nicht den L3 in das I/O. IF$ in das I/O.
Du musst den Caches einer Datenverbindung zuordnen, die diese entlasten sollen.
IF$ entlastet das SI, L3 auf Chiplet entlastet den Datentransfer zwischen Chiplet und I/O. L1/L2 entlasten den Zugriff einzelner Kerne auf den L3.
Die Latenz der Die zu Die Kommunikation ergibt sich doch aktuell daraus, dass die Daten erst in das RAM geschrieben werden und dann das andere Die diese lesen kann. Es kann ja nicht von einem L3 auf einen anderen L3 zugegriffen werden.
IF$ würde das doch ordentlich beschleunigen.

Etwas weniger L2 und einen kleinen pro CCD gesharten L3 zu verbauen ist auch eine Möglichkeit. Das würde dann bedeuten z.B. 2MB L2 und 16MB L3.
Die Frage ist jedoch ob das bei mehreren CCDs viel Sinn ergibt, da man sich damit eben auch die ganzen Schedulingprobleme aufhalst und ein exklusiver L2 wirkt nach außen hin auch wie ein L3 solange alle Kerne gleichmäßig ausgelastet sind.

Beim Speicherinterface stößt man an die Grenzen, jetzt schon 12 SI bei Genoa, die wissen kaum noch, wie sie die Dimms unterbringen sollen.
Im Desktop hat man 2 SI und die Kerne werden schneller. Größere Caches sind aber teuer. Da macht es schon Sinn den Engpass SI durch IF$ zu erweitern und dadurch die anderen Caches zu entlasten.
Die Vorteile hast du ja aufgezählt.

Bei den ganz großen Datacenter CPUs (laut Gerüchten 192 Zen5c Kerne) ist es wahrscheinlich sinnvoller gleich auf HBM oder ähnliche Technologien zu setzen. Dann gibt es wie bei SR 64GB HBM der als L4 Cache fungiert.

[amdfanuwe]

Etwas weniger L2 und einen kleinen pro CCD gesharten L3 zu verbauen ist auch eine Möglichkeit. Das würde dann bedeuten z.B. 2MB L2 und 16MB L3.

Muss halt alles aufeinander abgestimmt sein.

Die Frage ist jedoch ob das bei mehreren CCDs viel Sinn ergibt, da man sich damit eben auch die ganzen Schedulingprobleme aufhalst

Schedulingprobleme sollten durch IF$ eher abnehmen. Gibt dann nicht mehr die Strafzeiten, wenn von einem auf ein anderes CCX gewechselt wird.
Jetzt muss man ja auch darauf achten die Threads möglichst in einem CCX laufen zu lassen, da ändert sich doch nichts daran.

Bei den ganz großen Datacenter CPUs (laut Gerüchten 192 Zen5c Kerne) ist es wahrscheinlich sinnvoller gleich auf HBM oder ähnliche Technologien zu setzen. Dann gibt es wie bei SR 64GB HBM der als L4 Cache fungiert.
Bisher wurden sozusagen 8 Kerne von einem SI bedient.
Rome, Milan 8 SI ~204GB/s max 64 Kerne ~3,2 GB/s/Kern
Genoa bringt ~460 GB/s mit 12 SI und 96 Kerne. ~4,8 GB/s/Kern
Bergamo 12 SI + IF$ ? mit 128 Kerne > 3,6GB/s/Kern
Siena 6SI + IF$ ? max 64 Kerne > 3,6GB/s/Kern
Siena sollte damit trotz kleinerem SI schneller als Milan werden.

MI300 zeigt ja schon, das AMD ein Design mit 8 HBM3 Stacks, 128GB mit ~6 TB/s bringen wird. Selbst mit 256 Kerne käme man da auf ~23GB/s/Kern.
Sollte man schon was mit anfangen können.

[Complicated]

Ich habe den Eindruck, dass das von dir angesprochene Patent unabhängig davon ist und etwas anderes ist.

Btw werden L1 Caches in aktuellen rdna 2/3 GPUs überhaupt schon geshart? Das wäre mir neu. Patente gibt es ja viele….Das heißt erstmal nicht zwangsweise, dass Dinge so (oder überhaupt schon) umgesetzt sind.
Im Chipsandcheese Artikel sieht es für mich eher so aus als wenn der L1 pro WGP exklusiv ist.
Ich denke du hast da recht. Danke für den Hinweis. Bei mir ist der Eindruck entstanden, dieser Shared L1 ist eine der Teilkomponenten, die dem zusätzlichem LLC zuarbeitet und Teil des IF$. Ich schau mal ob ich raus finde wo ich das falsch verknüpft habe. Vielleicht aus CDNA -Papers oder ein widerlegte Spekulation die ich verpaßt hatte.

Für den Bereich CPU würde ja einfach noch mehr L3-Cache nichts bringen, wenn dies alles wäre was den IF$ ausmacht.

Danke für das korrigieren. :up:

[HOT]

Die werden mMn die CCDs einfach miteinander latenzarm verbinden und den LLC über beide CCDs hinweg adressieren. Das ist denke ich mal das "Cache Redesign". Dann kann man das erste CCD mit VCache ausstatten und man hätte überall viel mehr Cache - oder es würde sich evtl. lohnen beide CCDs zu VCachen, dann hätte man eben extra-wahnsinnig-viel Cache. Die Anbindung zum IOD wird sich bei Zen5 nicht ändern, erst bei Zen6 würde ich mit weitren Stacking-Schritten rechnen.

[robbitop]

So eine Art Virtual L4 Cache (angelehnt an IBMs Virtual L3 Cache der sich aus Zugriff auf andere L2 Cache Segmente ergibt)? Klingt nicht uninteressant. Dank INFO-R kann man die Chiplets schneller anbinden und auch näher zusammenrücken. Wenn es einen separaten Link gibt, der deutlich schneller ist, könnte man noch in sinnvollen Regionen landen (bis dato hat die IF da immer einen Strich durch die Rechnung gemacht). Ich würde tippen sub 40 ns. Ggf. auch sub 30 ns. Aber dann darf die IF nicht im Spiel sein.

Entsprechend hätte man bis zur Obergrenze des L3 pro CCD seine ~10 ns und dann darüber ~30-40 ns.

Allerdings hat man normalerweise größere Sprünge zwischen zwei Cachestufen als nur Faktor 2. Bei einem Cachemiss würde obige Idee wieder Performance kosten weil die Gesamtmemorylatenz höher ist. Damit sich das lohnt müsste mMn der L4 eigentlich größer sein.

[Der_Korken]

Ich könnte mir die IBM-Idee eher auf CCD-Ebene vorstellen. Der L2 wird deutlich vergrößert (z.B. auf 2-3 MB), dafür entfällt aber der reguläre L3. Stattdessen werden - abhängig vom Last-Szenario - die fremden L2-Slices verwendet, um die aus dem eigenen L2 verdrängten Cache-Lines zu cachen und auch dort wieder anzufragen. Das private L2-Slice wäre dann wie bisher inklusiv bzgl. der privaten L1-Caches. Auf diese Weise hätte AMD

1. Mehr schnellen privaten Cache
2. Weniger "wertvolle" Chipfläche für Cache verwendet
3. Das Gerücht über den shared L2 pro CCD würde sich so bewahrheiten.

Bei 16-24MB L2 pro CCD wären 96-128MB L3-Cache auf dem IOD schon sehr ordentlich für zwei CCDs. Ich weiß nur nicht wie gut die Implementierung der dynamisch verwendeten L2-Slices funktioniert. Jeder Kern muss sich auf irgendeine Weise Platz im eigenen Slice sichern können, wenn er benötigt wird, sonst hat man gegenüber dem bisherigen L3 keinen Latenz-Vorteil. Gleichzeitig muss schnell klar sein, wohin ein L2-Slice seine Daten hin verdrängt bzw. wo er danach sucht, denn einfach immer in allen fremden Slices zu suchen wäre viel zu langsam und ineffizient. Und wenn alle Kerne ausgelastet sind, sollten fremde Slices am besten gar nicht benutzt werden, weil sich die Kerne sonst nur gegenseitig die Daten aus dem Cache werfen. Hier kann man noch L2-Miss direkt auf den IOD gehen.

[robbitop]

Die neusten leaks sind vom gesharten L2 wieder zurückgerudert. Will nichts heißen aber entsprechend sinkt die Wahrscheinlichkeit damit etwas.
Wer weiß ob das für Gamingworkloads ideal ist. IBMs Clientel hat ja schon doch andere Applikationen.
Und wie gesagt: Cache der nicht im gleichen Die ist, ist deutlich langsamer. Aktuell hat man mit VCache 96 MiB Cache der ~10 ns schnell ist. Da wäre 128 MiB off die mit bestenfalls 30-40 ns (und dazu müsste man schon einiges umkrempeln damit er überhaupt so schnell werden würde) eher ein downgrade. Das müsste dann schon deutlich fetter sein, damit ein so langsamer Cache ein upgrade wäre.

Insgesamt finde ich die Cachestruktur so schlecht nicht, wie sie ist. Insbesondere mit VCache. Ich kann mir aber gut vorstellen, dass Zen 5 den L1 vergrößert (und ansonsten einfach in allen Aspekten des Kerns fetter/breiter wird). Das wäre mein persönlicher Tip. Klar: konventionell/langweilig. Aber bisher sind die wirklich ausgefeilten Dinger entweder eine Ente gewesen (reverse SMT, SMT4x) oder waren irgendwie nicht gut (CMT bei Bulldozer z.B.). Aber andererseits gabs auch schon ein paar Überraschungen wie Chiplets und VCache. Mal schauen. Ich bin in der Hinsicht trotzdem relativ konventionell für Zen 5. :)

Den L2 Cache von Raptorlake kann man schon bewundern. Mit nur 16 Cycles ist er nicht so viel langsamer als Zen 4s 14 Cycles aber doppelt so groß. Ggf. etwas, was AMD sich in späteren Zen Iterationen überlegen könnte. Mein Bauchgefühl sagt, dass AMD mit L2 Cache Größe relativ konservativ ist und von den neu eingeführten 1 MiB so schnell nicht weg gehen wird. Bei Zen brauchte es immerhin bis zu Zen 4 um das von 512 kiB auf 1024 kiB zu vergrößern.

[mksn7]

...dieser Shared L1 ... Vielleicht aus CDNA -Papers oder ein widerlegte Spekulation die ich verpaßt hatte.


Bei Hopper wird das genannt. Da kann auf den L1 cache Inhalt fremder SM's zugegriffen werden, aber ich glaube nicht alle SMs untereinander, sondern nur innerhalb einer Unterstruktureinheit (TPC? GPC?). Ich hab bisher noch keinen konkreten Fall gesehen wo das einen großen Vorteil hatte (hab aber auch noch nicht so intensiv geschaut), aber bei einer Messung war plötzlich das L2 cache Datenvolumen kleiner als es sein sollte, was ich als Folge des L1 cache sharings interpretiere. Ich denke dass das L1 cache interconnection network nicht soviel schneller (=Bandbreite, Latenz hab ich nicht getestet) ist als der L2 cache selbst, daher muss ich noch genauer nachdenken was da ein konkretes Szenario mit Nutzen sein könnte.

[Der_Korken]

Und wie gesagt: Cache der nicht im gleichen Die ist, ist deutlich langsamer. Aktuell hat man mit VCache 96 MiB Cache der ~10 ns schnell ist. Da wäre 128 MiB off die mit bestenfalls 30-40 ns (und dazu müsste man schon einiges umkrempeln damit er überhaupt so schnell werden würde) eher ein downgrade. Das müsste dann schon deutlich fetter sein, damit ein so langsamer Cache ein upgrade wäre.


Das war auch weniger als Upgrade gedacht, als vielmehr eine Umstrukturierung. Der V-Cache hat den Nachteil, dass man eigentlich beide CCDs stacken muss, bzw. dass man so komische Effekte drin hat, wo z.B. ein 7900X3D in Spielen langsamer läuft als ein 7800X3D, weil ersterer nur 6 statt 8 Kerne am großen Cache hat. Mit einem einzelnen V-Cache "in der Mitte" hätte man beide Probleme nicht. Ob die Latenz wirklich bei 30-40ns landet, muss man auch erstmal sehen, denn im Gegensatz zu Sapphire Rapids wäre die Topologie viel einfacher: Keine Zwischenhops zwischen L2 und L3, sondern nur eine Direktverbindung, Leserichtung immer gleich, Cache immer am gleichen Ort.


Insgesamt finde ich die Cachestruktur so schlecht nicht, wie sie ist. Insbesondere mit VCache. Ich kann mir aber gut vorstellen, dass Zen 5 den L1 vergrößert (und ansonsten einfach in allen Aspekten des Kerns fetter/breiter wird).

Mein Bauchgefühl ist eher, dass wenn man den L1 anfasst, man diesen auch deutlich d.h. auf mindestens 2x128kB vergrößert, um die Nachteile des wegfallenden VIPT besser zu verteilen. Dafür wären 1MB L2 aber wieder zu klein, d.h. man man hätte lieber 2MB. Das kostet aber wieder Fläche und macht den L3 weniger effektiv. Daher mein Gedankengang, dass man den L3 deswegen in der Topologie ein Stück nach oben zieht.

[amdfanuwe]

Mit einem einzelnen V-Cache "in der Mitte" hätte man beide Probleme nicht.
Bei ZEN4c und 5c mit 2CCX wäre das vielleicht als gemeinsamer Cache auf dem CCD interessant.

Wie sieht das eigentlich mit AIE aus?
Bekommt das jeder Kern als Erweiterung wie avx, oder wird das pro CCX gehandhabt?
Oder eher doch pro CCD oder gar im I/O wie GPU?

[Nightspider]

Bei den ersten Reviews waren es noch 15% Vorsprung auf den 5800X.

Ganz ganz großer Denkfehler. Die Spiele haben sich nicht mal schnell innerhalb eines Jahrs geändert. Schon gar nicht wegen dem Erscheinen der X3D CPUs.

Die letzten Benchmarks enstanden mit CPU limitierten Grafikkarten, bei den alten Tests war man oft im GPU Limit.

2. Faktor:

Spiele gehen oft mit 3D Cache in den Szenarien ab, wo man bereits viele fps hat. Das lässt die avg_fps stark nach oben driften.

Es gibt Spiele die viel stärker in den Szenen vom Cache profitieren, wo eh nix los ist aber da wo die CPU unter heavy load ist, bringt der Cache weniger weil da die Leistung der Architektur fehlt. Hab ich in vielen Benchmarks gesehen.

Und die aktuelle GPU Gen lässt die entsprechenenden Spiele in den entsprechenden high_fps Bereichen eben verstärkt nach oben driften, wo man es eigentlich eh nicht braucht.
Deswegen sollte man noch verstärkter auf die 1% lows zu achten.

[robbitop]

Das war auch weniger als Upgrade gedacht, als vielmehr eine Umstrukturierung. Der V-Cache hat den Nachteil, dass man eigentlich beide CCDs stacken muss, bzw. dass man so komische Effekte drin hat, wo z.B. ein 7900X3D in Spielen langsamer läuft als ein 7800X3D, weil ersterer nur 6 statt 8 Kerne am großen Cache hat. Mit einem einzelnen V-Cache "in der Mitte" hätte man beide Probleme nicht. Ob die Latenz wirklich bei 30-40ns landet, muss man auch erstmal sehen, denn im Gegensatz zu Sapphire Rapids wäre die Topologie viel einfacher: Keine Zwischenhops zwischen L2 und L3, sondern nur eine Direktverbindung, Leserichtung immer gleich, Cache immer am gleichen Ort.
Naja oder man stackt den Cache zukünftig mal unter die CCDs. Ja man verliert 10% Takt aber gewinnt doch häufig genug mehr Performance. Und ggf kann man den Effekt noch etwas reduzieren künftig. Insbesondere, wenn man den unter den CCD stackt.



Mein Bauchgefühl ist eher, dass wenn man den L1 anfasst, man diesen auch deutlich d.h. auf mindestens 2x128kB vergrößert, um die Nachteile des wegfallenden VIPT besser zu verteilen. Dafür wären 1MB L2 aber wieder zu klein, d.h. man man hätte lieber 2MB. Das kostet aber wieder Fläche und macht den L3 weniger effektiv. Daher mein Gedankengang, dass man den L3 deswegen in der Topologie ein Stück nach oben zieht.
Naja die Verdopplung des L2 Caches hat laut AMDs Folie fast nichts gebracht. Insofern könnte man auch die Inklusion eines 2x 128 kiB L1 Cache vertragen ohne große Nachteile zu haben.

So extrem viel Pressure scheint der doppelte L2 vom L3 jedenfalls nicht zu nehmen. Insofern ist ein richtig großer und gleichzeitig schneller LLC schon sinnvoll und kann nicht wirklich durch ein wenig größere L1/L2 ersetzt werden.

[Nightspider]

Du hast Recht über den Kernen reicht zwar eine zusätzliche Schicht an Dummy Silizium aber diese muss doppelt so dick sein.


Nein, mann kann die V-Cache Slices doch beliebig abschleifen.

Die Industrie kann locker 8-16 Chips übereinander stapeln.

2 Slices sind hauchdünn, wenn entsprechend abgeschliffen. Und so fett wie die Si Dumper sind über den Kernen ist, würden bestimmt auch mehr als 2 Slices in die gleiche Höhe passen, trotz weiterer Si "Abdeckplatte" darüber.

[Der_Korken]

Naja oder man stackt den Cache zukünftig mal unter die CCDs. Ja man verliert 10% Takt aber gewinnt doch häufig genug mehr Performance. Und ggf kann man den Effekt noch etwas reduzieren künftig. Insbesondere, wenn man den unter den CCD stackt.


In dem Moment, wo man CCD oben und Cache unten hat, könnte man sich auch fragen, ob man dabei nicht auch zwei CCDs auf einen Base-Die mit Cache stacken kann. Und dann wiederum könnte man sich fragen, ob man auf diese Weise nicht einen gemeinsamen LLC für zwei CCDs hinbekommt, der trotzdem gute Latenzen (<= 20ns) hat.

Ansonsten gehen die 10% imho nicht wegen der Hitze verloren, sondern durch die Takt/Spannungsbeschränkung des Cache-Dies. Ansonsten könnte man die 3D-Modelle doch einfach so hoch takten lassen bis sie ins Templimit laufen (wie bei quasi allen Zen 4 bei vollem PPT) statt künstlich irgendeine Taktgrenze zu ziehen. Würde man sich generell von den absurden Boost-Spannungen verabschieden und z.B. einfach bei 1,2V aufhören, wären für mich Temps auch kein Problem mehr bei gestackten Designs. Die letzten Punkte im Cinebench ST sind halt teuer.

[latiose88]

@Nightspider

Ist mir auch schon aufgefallen.Es kommt ja auch auf die Missrate an.Von L1 zu L2 wenn die schon neidrig ist,dann ist diese bei L2 auch so.Ich habe Kerne wirklich relativ gut ausgelastet,durch das sank allerdings die Abhängigkeit von Cache,Ram und Festplatte Massiv nach unten.Wobei bis zu einen gewissen Level der Ran auch noch ne satte steigerung gebegeben hatte,ab da jedoch nicht mehr.Und bei über 90 % CPU Auslstung,da sieht es dann auch anderst aus also bei den meisten.Nur wie kann man das Problem denn so umgehen,das der Ball wieder bei Bandbreite wichtig ist machen?

[robbitop]

Die Takt/Spannungsbegrenzungen kommen von dem Bedenken der Temperatur. Und die widerum vom höheren thermischen Widerstand.

Und ja mehrere CCDs auf ein IOD wäre eine Möglichkeit. Allerdings ist VCache vor allem so schnell bei der Größe weil die Entfernung super niedrig ist weil es nur in Z Richtung geht und weil es keine zusätzliche Logik gibt. Wenn man auf einen IOD stapeln würde und etwas habem wollte, was beide ccds nutzen können geht es auch schon wieder in X/Y Richtung. Und man braucht sicherlich auch nich eine Logik damit beide ccds auf diesen zugreifen können ohne sich in die Wuere zu kommen. Da kommt garantiert in Summe schon nochmal Latenz oben drauf. Ggf sogar signifikant. Aber wie gesagt - wenn es groß genug ist, wäre das ggf eine sinnvolle Lösung für L4 Cache. Aber dann darf es schon etwas mehr sein.

Ich tippe darauf, wenn sowas kommt, dann ggf etwas später. Kann mich aber natürlich auch irren.

[davidzo]

Und wie gesagt: Cache der nicht im gleichen Die ist, ist deutlich langsamer.

Ich denke auch dass wenn der L2 geshared ist, dann nur innerhalb eines CCX, so wie bisher der L3.


Insgesamt finde ich die Cachestruktur so schlecht nicht, wie sie ist. Insbesondere mit VCache.
(...)

Den L2 Cache von Raptorlake kann man schon bewundern. Mit nur 16 Cycles ist er nicht so viel langsamer als Zen 4s 14 Cycles aber doppelt so groß.


Die Cachestruktur ist die große Stärke von Zen3 und 4. Cheese and Chips hat das mal durchleuchtet und festgestellt das AMD auf jeder Stufe besser war als Golden Cove. Insbesondere der L3 ist eine Stärke - und das schon ohne V-Cache.
Und der L2 von Raptorlake ist imo nichts besonderes, das könnte AMD auch. Da sich Cache 2dimensional auf dem DIE verteilen lässt steigt die Leitungslänge nur sqrt{2}, also Faktor 1,41. 16ns im vergleich zu unter 10ns bei AMD sind also nicht beeindruckend. Gleichzeitig steigt die Hitrate mit einer Verdopplung eben auch nur um diesen Faktor, danach gehts eh zum L3 und bei diesem hinkt Intel erheblich hinterher.

Mit einem einzelnen V-Cache "in der Mitte" hätte man beide Probleme nicht. Ob die Latenz wirklich bei 30-40ns landet, muss man auch erstmal sehen

Das sollte definitiv drin sein. 40ns, das Niveau hat bereits Broadwell mit langsamen eDRAM und C4 Bumps geschafft. Wenn AMD tatsächlich diesmal auf UCIe oder ähnliches setzt anstatt einfachem flipchip, dann sollte auch wesentlich mehr drin sein.


Mein Bauchgefühl ist eher, dass wenn man den L1 anfasst, man diesen auch deutlich d.h. auf mindestens 2x128kB vergrößert, um die Nachteile des wegfallenden VIPT besser zu verteilen. Dafür wären 1MB L2 aber wieder zu klein, d.h. man man hätte lieber 2MB. Das kostet aber wieder Fläche und macht den L3 weniger effektiv. Daher mein Gedankengang, dass man den L3 deswegen in der Topologie ein Stück nach oben zieht.

Eben, Den L3 irgendwann auszulagern weil der nicht mehr skaliert liegt auf der Hand und ist der eigentliche Sinn von heterogenen Chiplet Packaging. Außerdem würde das die thermischen und elektrischen Nachteile des Stackings lösen. Der i/o + Cache-DIE ist thermisch kaum beansprucht und der Cache kann mit einer eigenen Voltage Domain arbeiten.

Allerdings wird der eigentliche CPU-DIE dann irgendwann zu klein um noch genügend bumps unter zu bringen. Also wird es sogar nötig sein ein wenig mehr Fläche beim L1 und L2 zu verbraten.

Naja oder man stackt den Cache zukünftig mal unter die CCDs.

Glaube ich nicht. Wichtiger als Thermals ist nämlich power delivery. Und solange man die dann nicht von oben macht kriegt man gar nicht die nötige Leistungsdichte zustande. Backside power delivery kommt zwar auch irgendwann, aber bis dahin müssen sie noch einige Probleme mit parasitärer capacitance, leitungslängen etc. lösen. Und die Datenleitungen müssen ja auch irgendwo durch, durch den Cache ist sicher auch nicht kostenlos.


So extrem viel Pressure scheint der doppelte L2 vom L3 jedenfalls nicht zu nehmen. Insofern ist ein richtig großer und gleichzeitig schneller LLC schon sinnvoll und kann nicht wirklich durch ein wenig größere L1/L2 ersetzt werden.
Einen richtigen LLC gibts bei AMD ja gar nicht. Der L3 ist nur pro CCX, also kein LLC.
Jetzt wo AMD mit MI-300 demnächst schon GPU und CPU Chiplets in einem Sockel mixt wäre es echt langsam mal an der Zeit für ZEN5 auch einen echten LLC einzuführen der vor dem DRAM sitzt und eine fette Crossbar mit jede Menge Bandbreite hat. Da würden vor allem auch die Mobil-CPUs mit IGPs / APUs massiv von profitieren.

[amdfanuwe]

Jetzt wo AMD mit MI-300 demnächst schon GPU und CPU Chiplets in einem Sockel mixt wäre es echt langsam mal an der Zeit einen echten LLC einzuführen der vor dem DRAM sitzt und eine fette Crossbar mit jede Menge Bandbreite hat. Da würden vor allem auch die Mobil-CPUs mit IGPs / APUs massiv von profitieren.
Kommt doch. Nennt sich Infinity Cache und ist für MI300 bestätigt.
83369

[davidzo]

Eben deshalb habe ich ja auf Mi-300 angespielt, weil es den dort ja geben soll. Ob das sich auch auf Zen5 abfärbt ist aber unklar.
Infinity Cache ist aber eben auch nur ein Marketingname und das dort eine Marketingfolie, ob das Cachesystem auch voll unified, also ein globaler LLC ist wissen wir nicht, obwohl es so sehr danach aussieht. Es wird schon einen Grund haben wieso AMD als CPU- und GPU-Hersteller einen LLC seit über 10 Jahren nicht angefasst hat, trotz der HSA Bemühungen.

[Complicated]

Wegen HSA. Da war die Kohärenz über L2 mit RMB und FCL schon etabliert. LLC muss AMD nicht für unified Memory nutzen, da es lediglich ein Victim des L2 ist.

[CrazyIvan]

Eben deshalb habe ich ja auf Mi-300 angespielt, weil es den dort ja geben soll. Ob das sich auch auf Zen5 abfärbt ist aber unklar.
Infinity Cache ist aber eben auch nur ein Marketingname und das dort eine Marketingfolie, ob das Cachesystem auch voll unified, also ein globaler LLC ist wissen wir nicht, obwohl es so sehr danach aussieht. Es wird schon einen Grund haben wieso AMD als CPU- und GPU-Hersteller einen LLC seit über 10 Jahren nicht angefasst hat, trotz der HSA Bemühungen.
Eigentlich muss der unified sein, auch wenn er physisch verteilt ist. Der sitzt ja direkt auf den MCs und der Speicher ist ja ganz offiziell unified.

[Complicated]

https://www.anandtech.com/show/18721/ces-2023-amd-instinct-mi300-data-center-apu-silicon-in-hand-146b-transistors-shipping-h223
https://images.anandtech.com/doci/18721/2022-06-09%2013_46_36.jpg
The key advantage of AMD’s design, besides the operational simplicity of putting CPU cores and GPU cores on the same design, is that it will allow both processor types to share a high-speed, low-latency unified memory space. This would make it fast and easy to pass data between the CPU and GPU cores, letting each handle the aspects of computing that they do best. As well, it would significantly simplify HPC programming at a socket level by giving both processor types direct access to the same memory pool – not just a unified virtual memory space with copies to hide the physical differences, but a truly shared and physically unified memory space.

[Complicated]

Hier sind gute Folien über die Iterationen der Infinity Architektur und Ausblick auf Zen5:
https://www.servethehome.com/amd-technology-roadmap-from-amd-financial-analyst-day-2022/
https://www.servethehome.com/wp-content/uploads/2022/06/AMD-FAD-2022-AMD-Infinity-Architecture.jpg

https://www.servethehome.com/wp-content/uploads/2022/06/AMD-FAD-2022-4th-Gen-AMD-Infinity-Architecture.jpg

UCIe wird der zukünftige Interconnect Standard, von Intel eingebracht in das Konsortium:
https://www.anandtech.com/show/17288/universal-chiplet-interconnect-express-ucie-announced-setting-standards-for-the-chiplet-ecosystem


https://images.anandtech.com/galleries/8123/UCIe_Briefing%20Presentation%20FINAL_05_575px.jpg

[davidzo]

Wegen HSA. Da war die Kohärenz über L2 mit RMB und FCL schon etabliert. LLC muss AMD nicht für unified Memory nutzen, da es lediglich ein Victim des L2 ist.
Ja, bei Kaveri gabs schon Kohärenz im L2. Latenzen waren halt nicht so pralle und die Anwendungen die das nutzen hat man auch nie gefunden.


Der sitzt ja direkt auf den MCs und der Speicher ist ja ganz offiziell unified.
Ist das gesichert dass der Cache auf MC bzw. MCDs sitzt? Bisher weiß ich nur von I/o
bzw. Base-DIEs, compute DIEs und Top-DIEs (sind das sie compute DIEs oder nochmal ein cache-DIe?). Der Rest ist imo alles Spekulation.
Und die Verknüpfung mit Zen5 sehe ich noch nicht.
Es ist möglich dass Mi-300 auch zen5 inspiriert hat, aber ein Zusammenhang bei der memory Architektur ist bisher nur Wunschdenken.

... direct access to the same memory pool – not just a unified virtual memory space with copies to hide the physical differences, but a truly shared and physically unified memory space.
Ja dass das bei Mi-300 der Fall ist hatten wir ja schon geklärt, aber gilt das auch für Zen5? Und die Rede ist hier nur von Memory, nicht unbedingt Cache.

[latiose88]

Also ich kenne ein Programm das Kohärenz im L2 verwendet. Aber genau darum ist die missrate auch so gering. Dise scheint wohl dazu zu sorgen das diese sehr niedrig gehalten werden. Heißt xmedia recode und dank das, ist es sehr gering. Dadurch ist es auch eine sehr geringe latenz. Durch das steigt mit mehr cache eben auch die Leistung nicht mehr an. Andere würden wohl da richtige Steigerungen haben. Nur das halt nicht. Ram ist auch mit 2 % eigentlich ja nix. Diese Funktion was du geschrieben hast, scheint dies alles zu bewirken. Hat also auch was gutes wie ich finde dabei.

[Complicated]

Und die Rede ist hier nur von Memory, nicht unbedingt Cache.Wie soll das eine ohne das andere sinnvoll funktionieren?

[HOT]

Zen5 Consumer wird denke ich noch kein CXL unterstützen, das würde einige Probleme lösen, das wird erst mit Zen6 kommen. Dann wären alle Caches und Speicher kohärent, soweit man das will. CXL3 ist sehr interessant für GPUs und SSDs, damit würde es sehr viel leichter auf dem PC direkt von der SSD in den VRAM zu streamen beispielsweise und der CXL-Controller wäre dann in Hardware in der CPU und würde diese Aufgaben übernehmen. Das hat alles wahnsinns Potenzial. Bei Zen5 würde ich aber nur erwarten, dass man den L3$ per Software und einer schnellen Anbindung zwischen den CCDs Kohärent hält, bis zu 4 CCDs also Clustern. MMn wäre das mit recht wenig Aufwand mit für AMD vorhandenen Technologien den nächsten Schritt gehen. Die L1 und L2 Caches werden Core-Exklusiv bleiben mMn. Das wird nicht die IBM-Lösung werden. Man könnte den den L3$-Cluster so betrachten, aber eigentlich ist das ja nur, als wäre das ein monolithischer Block zu sehen, wie bei RDNA3.

[CrazyIvan]

@davidzo
Hast recht! Das hatte ich jetzt wieder mit N31 durch einander gehauen :redface:

[basix]

Hier sind gute Folien über die Iterationen der Infinity Architektur und Ausblick auf Zen5:
https://www.servethehome.com/amd-technology-roadmap-from-amd-financial-analyst-day-2022/
https://www.servethehome.com/wp-content/uploads/2022/06/AMD-FAD-2022-AMD-Infinity-Architecture.jpg

https://www.servethehome.com/wp-content/uploads/2022/06/AMD-FAD-2022-4th-Gen-AMD-Infinity-Architecture.jpg

Die letzte Folie zu Infinity Fabric 4th Gen zeigt sehr schön, dass die MI300 Plattform vermutlich faktisch "Vollmodular" ist. Ich erwarte riesige FPGAs und dedizierte AIE-Inferencing-Accelerators im selben Formfaktor :)

[amdfanuwe]

Ist das gesichert dass der Cache auf MC bzw. MCDs sitzt? Bisher weiß ich nur von I/o
bzw. Base-DIEs, compute DIEs und Top-DIEs (sind das sie compute DIEs oder nochmal ein cache-DIe?). Der Rest ist imo alles Spekulation.

Bei RDNA3 sind die MCD mit Cache in 6nm, GCD 5nm.
Da das Base Die bei MI300 auch 6nm ist, macht es keinen Sinn dort MCDs zu verwenden. Würde den Verbrauch erhöhen und keinen Vorteil bieten solange keine Packages mit unterschiedlicher SI Anzahl vorgestellt werden.
Top Dies sind 5nm Compute Dies. Die könnten nochmals 3D-VCache haben. Ob das für die geplanten Anwendungen aber sinnvoll ist...

Immo alles Spekulation so lange nichts auf dem Tisch liegt.

[Complicated]

@basix
Dazu gibt es auch schon Details. Da tut sich nochmals etwas rund um XDNA mit "Local Distributed Memory" und den AI Engines auf den neuen ACAP FPGAs:
https://forum.planet3dnow.de/index.php?threads/amd-xdna-ryzen-ai.467994/post-5435223

[Tarkin]

Tenstorrent hatte gestern ein Live-Event ...

siehe: https://www.youtube.com/@tenstorrentinc/streams

und da wurde eine äußerst interessante Folie gezeigt:

Man gibt die Core Performance von Zen 5 mit +30% ggü. Zen 4 Core an.

[00-Schneider]

Ich bin mal gespannt, ob man bei Zen 5 die X3D wieder erst später bringt.

[Complicated]

Tenstorrent hatte gestern ein Live-Event ...

siehe: https://www.youtube.com/@tenstorrentinc/streamsich habe mir den Stream noch nicht komplett angeschaut, doch die SPEC2017INT Werte für Sapphire Rapids weichen doch sehr stark von den hier gemachten Benches ab. Die Performance liegt eigentlich deutlich hinter Genoa.


https://www.servethehome.com/wp-content/uploads/2023/01/Intel-Xeon-Platinum-8490H-and-Platinum-8480-SPECrate2017_int_base-Estimated-Result-List.jpg


Daher trau ich auch den anderen Zahlen dort nicht. Da stimmt etwas nicht.

[HPVD]

Tenstorrent hatte gestern ein Live-Event ...

siehe: https://www.youtube.com/@tenstorrentinc/streams

und da wurde eine äußerst interessante Folie gezeigt:

Man gibt die Core Performance von Zen 5 mit +30% ggü. Zen 4 Core an.

@Tarkin spannend, könntest Du vielleicht noch den deeplink zu der Stelle im Video angeben? (also einfach die Zeitangabe nennen / direkt im link mit anhängen)

Kann es leider nicht finden und der Kontext also das davor und danach wäre sehr interssant...

[robbitop]

Ich bin mal gespannt, ob man bei Zen 5 die X3D wieder erst später bringt.
Irgendein rumor sagte, dass X3D bei Zen 5 wesentlich eher kommen wird, wenn nicht sogar schon zum Launch.
Bei Zen 4 hat es ja schon deutlich kürzer gedauert zum X3D als bei Zen 3.

Am Ende kann es aber natürlich sein, dass sie ihn absichtlich später launchen, sofern Zen 5 schnell genug ist, um souverän auf Platz 1 zu stehen. Dann hätte man noch etwas in der Hinterhand.

Hot take / aber meine eigene Ansicht (die man sicher anders sehen kann):
Ich finde es mittlerweile schade, hart erarbeitete Leistung der uArch durch Wartezyklen auf den Speicher einzubremsen. Der VCache (bzw ein großer, schneller LLC bzw niedrige mittlere accesslatency die daraus limitiert) ist IMO eher sowas wie ein Enabler - macht die Performance konsistenter und erlaubt den Kernen ihr Potenzial auszufahren.
Eine CPU ohne VCache fühlt sich deshalb an als wäre sie limitiert. Entsprechend wäre ich auch immer auf ein X3D Modell aus. Entsprechend wäre es am besten X3D zum Launch in Zukunft zu haben.

[Complicated]

Ich denke, dass AMD das mit Zen5 machen wird, ich hatte es auch schon für Zen4 spekuliert. Möglicherweise war AMD sich noch nicht sicher, ob die 3DV Modelle tatsächlich so im Markt angenommen werden, dass sie als Top-Empfehlung gelten. Wenn das Mindset bei Gamern 3DV bevorzugt, wird AMD diese als erste Desktop SKUs bringen. Dies wäre mit Zen5 optimal, da AM5 eine dann im Markt etablierte Plattform ist und die Kosten für den Unterbau und RAM kleiner und die Auswahl größer ist. Nimmt man hinzu, dass 2023 noch als schwieriger Markt gilt und somit eine Erholung in 2024 erwartet wird, dann hat sich AMD gut positioniert wenn die Nachfrage wieder anzieht.

[basix]

ich habe mir den Stream noch nicht komplett angeschaut, doch die SPEC2017INT Werte für Sapphire Rapids weichen doch sehr stark von den hier gemachten Benches ab. Die Performance liegt eigentlich deutlich hinter Genoa.


https://www.servethehome.com/wp-content/uploads/2023/01/Intel-Xeon-Platinum-8490H-and-Platinum-8480-SPECrate2017_int_base-Estimated-Result-List.jpg


Daher trau ich auch den anderen Zahlen dort nicht. Da stimmt etwas nicht.

Deine Werte sind MT. Die anderen von Tarkin sind "Rate 1", also ST. Hier ST Werte von Anandtech für Zen 4 und Alderlake:
https://www.anandtech.com/show/17585/amd-zen-4-ryzen-9-7950x-and-ryzen-5-7600x-review-retaking-the-high-end/11

[Der_Korken]

Tenstorrent hatte gestern ein Live-Event ...

siehe: https://www.youtube.com/@tenstorrentinc/streams

und da wurde eine äußerst interessante Folie gezeigt:

Man gibt die Core Performance von Zen 5 mit +30% ggü. Zen 4 Core an.

Wenn man den ca. 5% höheren Takt abzieht (rechts ~4Ghz vs ~3,8Ghz), sind das cs. 24% mehr IPC in 1T. Klingt realistisch. Ob der Takt bei den Desktop-Modellen steigt, wird man sehen, denn bei Genoa war der Taktsprung gegenüber Milan deutlich kleiner als bei Raphasel vs Vermeer. Da könnten die 5% Takt auch einfach nur das Aufbrauchen von vorhandenen Reserven sein.

[Sunrise]

Ich wäre sogar schon soweit zu sagen, dass ich einen non-X3D Zen5 garnichtmehr kaufen würde, denn die X3D sind preislich wirklich stark runtergegangen.

Aber gut, ich bin auch nicht immer auf Schnäppchen aus, wenn für mich das Gesamtpaket passt. Bei über 650 EUR spring ich dann allerdings auch ab.

[basix]

@Tarkin spannend, könntest Du vielleicht noch den deeplink zu der Stelle im Video angeben? (also einfach die Zeitangabe nennen / direkt im link mit anhängen)

Kann es leider nicht finden und der Kontext also das davor und danach wäre sehr interssant...

https://youtu.be/SupjLqPbFpY?t=2540

[CrazyIvan]

Hot take / aber meine eigene Ansicht (die man sicher anders sehen kann):
Ich finde es mittlerweile schade, hart erarbeitete Leistung der uArch durch Wartezyklen auf den Speicher einzubremsen. Der VCache (bzw ein großer, schneller LLC bzw niedrige mittlere accesslatency die daraus limitiert) ist IMO eher sowas wie ein Enabler - macht die Performance konsistenter und erlaubt den Kernen ihr Potenzial auszufahren.
Eine CPU ohne VCache fühlt sich deshalb an als wäre sie limitiert. Entsprechend wäre ich auch immer auf ein X3D Modell aus. Entsprechend wäre es am besten X3D zum Launch in Zukunft zu haben.

Ich gebe Dir vollkommen recht und ich gehe noch einen Schritt weiter: V-Cache wird bei AMD in einer künftigen Generation nicht allein einer X3D-SKU vorbehalten bleiben. Vielmehr wird es integraler Bestandteil des BIG-Parts des hybriden Designs. Nicht erst fett ab dem Front-End, sondern bereits bei den Caches.
Mit Zen4c ist der Anfang in die andere Richtung bereits gemacht.
Die Spreizung bei Fläche pro Kern geht inkl. V-Cache dann in Richtung Faktor 3-4 - ähnlich wie derzeit bereits bei Intel. Dafür dürfte die Spreizung hinsichtlich Energieeffizienz bzw. V-f-Curve deutlich größer sein (als bei Intel). Dann macht es auch wirklich Sinn, nicht zeitkritische Background-Workloads wie Cloud-Sync, AV-Scan, etc. auf diese Kerne auszulagern, denn sie sparen Energie im Sinne von "Mehr Saft im Akku nach Abschluss der Aufgabe".

[latiose88]

diese Spreizung was du schriebst,macht es aber die wo die vollen Kerne wirklich Auslasten aber dann wieder schlechter,weil die sind dann ja voll im Nachteil dann.Da wird sich AMD wohl auch noch gedanken drüber machen oder werden die Zukunftigen CPUS etwa noch kleiner?

[Langlay]

diese Spreizung was du schriebst,macht es aber die wo die vollen Kerne wirklich Auslasten aber dann wieder schlechter,weil die sind dann ja voll im Nachteil dann.Da wird sich AMD wohl auch noch gedanken drüber machen oder werden die Zukunftigen CPUS etwa noch kleiner?


https://abload.de/img/giphyckdx6.gif

[latiose88]

https://abload.de/img/giphyckdx6.gif
Das bezog sich auf dem Text von CrazyIvan.Mit dem Cache und dem ganzen.Kann sich auch zum schlechten für manche Programme Entwickeln ,die es zuvor auch gepasst hatte.Habe ich ja bei minimalen Settings beim H264 schon bei Zen 4 gemerkt gehabt.So hatte ich mit dem 5950x 30 Sekunden und der 7950x schaffte nur noch 32 Sekunden in der Zeit fertig zu werden.Oben rum ist er jedoch schneller geworden,aber ganz unten schlechter.
Das meinte ich ,ist nur als Beispiel gewesen.

[robbitop]

Ich gebe Dir vollkommen recht und ich gehe noch einen Schritt weiter: V-Cache wird bei AMD in einer künftigen Generation nicht allein einer X3D-SKU vorbehalten bleiben. Vielmehr wird es integraler Bestandteil des BIG-Parts des hybriden Designs. Nicht erst fett ab dem Front-End, sondern bereits bei den Caches.
Mit Zen4c ist der Anfang in die andere Richtung bereits gemacht.
Die Spreizung bei Fläche pro Kern geht inkl. V-Cache dann in Richtung Faktor 3-4 - ähnlich wie derzeit bereits bei Intel. Dafür dürfte die Spreizung hinsichtlich Energieeffizienz bzw. V-f-Curve deutlich größer sein (als bei Intel). Dann macht es auch wirklich Sinn, nicht zeitkritische Background-Workloads wie Cloud-Sync, AV-Scan, etc. auf diese Kerne auszulagern, denn sie sparen Energie im Sinne von "Mehr Saft im Akku nach Abschluss der Aufgabe".
Wie meinst du das? Big Cores hätten dann vcache und little cores nicht?
Nach meinem Verständnis ist ein großer Cache energieeffizienz steigernd da Speicherzugriffe lokal weniger Energie kosten als im RAM. Wenn die little Cores keinen VCache häben, die big cores aber schon schiebt das mMn beide von der Energieeffizienz eher zusammen weil die P Vores dadurch energieeffizienter werden und die E Cores ohne vcache eben nicht. :)

[NC]

Wie meinst du das? Big Cores hätten dann vcache und little cores nicht?
Nach meinem Verständnis ist ein großer Cache energieeffizienz steigernd da Speicherzugriffe lokal weniger Energie kosten als im RAM. Wenn die little Cores keinen VCache häben, die big cores aber schon schiebt das mMn beide von der Energieeffizienz eher zusammen weil die P Vores dadurch energieeffizienter werden und die E Cores ohne vcache eben nicht. :)Isoliert betrachtet kann ein big core, auch bei Intel, effizienter sein. Zum einen wenn er nicht im absoluten Limit betrieben wird und zum anderen, wenn der Core schneller mit einem Task fertig ist (also nicht den dauer Durchschnittsverbrauch betrachtend, sondern für eine Aufgabe)
Little kommt zum Zuge wenn das System an sich am Limit ausgelastet ist und du mit möglichst wenig Transistoren/Energie Einsatz noch "extra performance" willst. Dann könnten Threads ausgelagert werden die wenig von Caches und viel Rechenleistung profitieren und die Big Cores mit viel Caches können sich 100% der Zeit auf die Hochlastthreads konzentrieren.

big.little ist wirklich nur eine Wette dass es im Desktopbereich solche "mixed workloads" gibt. Bei Servern die für einen sehr spezifischen workload gekauft werden sind nur big oder nur little mit unter effizienter. Genau so ob mit oder ohne V-Cache.

Desktop big.little sind da auch anders als Mobile.

[robbitop]

Das ist mir alles schon klar. Aber Cache hat uArch unabhängig den gleichen Effekt. Durch höhere Hitrate weniger Energie für Datentransfers.


Ansonsten ist P/E bei Intel bisher nicht so implementiert, um die Energieeffizienz zu maximieren. Wie das geht, sieht man an den Apple SoCs. Da sind die E Cores wirklich mit einer breiten Spreizung zu den P Cores ausgelegt. Und die sind zwar langsamer aber brachial energieffzienter.

Bei Intel wirkt es eher so, dass man versucht hat, maximale MT Leistung pro mm2 zu holen bei noch relativ hoher ST Leistung pro E Core. Dafür sind die aber dann auch nicht effizient.
MMn sind das keine E Cores im klassischen Sinn.

Bei sehr gut parallelen workloads geht das Rezept auch auf. Aber sobald auch mal was performancekritisches (im Sinne von „kritischer Pfad“) passiert, bremsen die E Cores eher aus. Siehe hwub review dazu.
Ich würde im Desktop glaube ich 16 echte Cores dieser Mischung mit den „E Cores“ vorziehen. Im Laptop würde ich hingegen aus Gründen des Powerenvelopes ein P/E Konzept mit echten E Cores gut finden. So wie man es auch in Apples M Cores in den Macbooks findet.

[CrazyIvan]

@NC
Deine Aussage zu BIG.little und Servern unterschreibe ich genau so.

@robbitop
Ja, in meinen Augen wird V-Cache bei AMDs BIG-Cores in der Zukunft Standard, bei little-Cores im Desktop/Mobile-Markt jedoch eher nicht.
Und mit dem Einzelaspekt hinsichtlich Energieeffizienz hast Du auch recht, mir ging es jedoch um das Gesamtbild:


BIG.little ist in meinen Augen im Desktop/Mobile-Markt Imperativ. Das liegt ganz einfach daran, dass in diesen Märkten ein sinnvoller Kompromiss für eine statistische Verteilung von Workloads gefunden werden muss, die in der Spanne von Single-threaded, lightly-threaded, rather-heavy-threaded und embarrasingly-parallel liegen. Hinzu kommen zeitkritische Workloads vs. nicht-zeitkritische Workloads. Letztere sollten idealerweise mit der geringstmöglichen Menge an Joules abgearbeitet werden.
Bei Intel ist erkennbar, dass dieser Kompromiss vielleicht gar nicht unbedingt bei 8 großen Kernen liegt, sondern womöglich darunter. Die haben mit Sicherheit Heerscharen von Analysten, die für die nächste Generation anscheinend auf die Zahl 6 gekommen sind.
Je weniger große Kerne man verbaut, desto breiter wird man die in einem definierten Budget-Rahmen auch machen können. Und dazu zählt neben der Breite des Front-Ends, der Ausführungseinheiten, der OoO-Ressourcen, etc. pp. eben auch der vorgelagerte Cache. Davon werden Gamer, wie auch verschiedenste Productivity-Zielgruppen gleichermaßen profitieren.
Intels Kardinalfehler seit Alder Lake besteht in zweierlei Aspekten: Man taktet die *mont-Kerne so hoch, dass sie aus ihrem Effizienzfenster fallen und damit den eigentlichen Zweck eines little-Cores nicht erfüllen - nämlich signifikant weniger Joule für eine gegebene Aufgabe zu verbrauchen, als der große Bruder (jaja, aber die Fläche). Und zum Zweiten das Nichtvorhandensein einer eigenen Spannungsversorgung, was Aspekt Nummer 1 nochmals verstärkt. Beide Fehler wird AMD vermutlich nicht begehen.
PHX2 wird AMDs Testballon und ich bin schon mordsmäßig gespannt, wie der sich in Bezug auf obige Punkte darstellen wird. Ausgehend von diesem ersten Schritt wird AMD hinsichtlich Fläche (Kosten pro Kern), Energieeffizienz und Performance die Kerntypen weiter aufspreizen - und V-Cache ist eben ein Aspekt in der Gesamtrechnung.


P.S.
Bevor sich jemand am Wording hochzieht: Auch wenn ich es nicht an jeder Stelle genau so formuliert habe, ist alles obige ein IMHO, basierend auf educated guessing - schließlich sind wir hier im Speku-Forum ;)

[robbitop]

Wobei das „big“/„little“ mit den C Cores von AMD weniger konsequent umgesetzt ist. Man spart etwas L3 Cache, optimiert das layout auf Dichte statt Takt und fährt bessere Betriebspunkte.
Echte E Cores wie bei Apple wären da schon was.

[CrazyIvan]

Ja, aber wir wissen auch, dass Zen im Grunde seit Zen2 ein sehr stark auf Effizienz getrimmtes Design ist. Zen4c sehe ich als Fork, ab dem große und kleine Kerne auch bei AMD stark divergieren werden.
Muss ja nicht jeder wie Intel agieren, und grundverschiedene Architekturen mit unterschiedlicher ISA zusammenschmeißen.
Apple ist natürlich weiterhin der Klassenprimus - keine Frage.

[robbitop]

Naja man kann Kerne auf Effizienz für verschiedene Betriebsbereiche trimmen. Zen ist effizient im Bereich von vielleicht 2-10W pro Core. Darunter und darüber sinkt die Energieeffizienz. Entsprechend ist es natürlich eine Auslegungsfrage für welchen Bereich man effizient sein sill. Universell geht das nicht.
Die E Cores Bei Apple sind dann wahrscheinlich besonders energieffizient zwischen ein paar hundert mW und 1-2 tausend mW pro Kern. Also weit genug weg gespreizt von den P Cores.
Das ist sicherlich gerade für Backgroundtasks energieeffizient. Für mibile ideal.
Naja mal abwarten ob Zen 5c mehr Unterschied zu Zen 5 zeigt als Zen 4 zu 4c. :)