RDNA3 (Navi 3X, Radeon RX 7000 Serie, tlw. Chiplets, 5/6 nm, 2022)

[Leonidas]

3DC News-Index-Liste zu RDNA3 bzw. Navi 3X:
https://www.3dcenter.org/news/amd-rdna3

Was bisher bekannt ist:
- steht auf AMD-Roadmaps (https://www.3dcenter.org/news/aktualisierte-amd-roadmaps-zeigt-zen-4-im-consumer-bereich-nicht-vor-dem-jahr-2022) im Zeitrahmen bis (einschließlich) 2022
- Navi 31 als erster Chip gerüchteweiser aufgetaucht
- gerüchteweiser Chiplet-Design aka MultiChip-Ansatz

[Leonidas]

Neue Details von Komachi nach "Winterschlaf":

4. NV3X GCD/MCD means probably Graphics Complex Die/Memory Complex Die of Navi 3X (Navi 31).

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

[HOT]

Das ist nicht mehr Navi. RDNA3 wird was völlig neues sein. Ich würd N31 definitiv bei RDNA2 einordnen, dafür ist die Gerüchtelage schon zu alt. Die Chiplets widersprechen dem auch gar nicht.

[Leonidas]

Vielleicht danach. Aber auf den offiziellen Roadmaps (https://www.3dcenter.org/news/aktualisierte-amd-roadmaps-zeigt-zen-4-im-consumer-bereich-nicht-vor-dem-jahr-2022) wird es eindeutig "Navi 3X" und "RDNA3" genannt. Das dürfte man kaum noch ändern - auch weil Namen Schall und Rauch sind.

[HOT]

Ups, das ist mir entgangen. Hatte nicht den Eindruck, dass AMD hier so auf dem Gas steht.
Aber Chiplets sind das evtl. gar nicht. Wenn man nur den Speichercomplex abtrennt, erlaubt man sich eben modulare Speicherkonfigurationen, also HBM oder GDDR6 für dasselbe Design.

[Leonidas]

Denke ich mir auch. Die Namen sagen eigentlich nur, das Speicher+Interface oder gar nur der Speicher abgetrennt sind. Den Compute-Part rührt man dabei nicht an, das ist nicht MultiChip in dem Sinne, das man viele Chiplets rechnen lassen kann. Allerdings basiert diese These auch nur auf dieser Namenswahl, welche derzeit allein gerüchteweise besteht.

[Der_Korken]

Wenn man bedenkt, dass bei N10 die eigentlichen CUs+Frontend gerademal 60% des Dies ausmachen und der ganze IO-Kram bei 5nm eher noch mehr als weniger Platz einnehmen wird, würde es schon helfen, wenn man CUs+Frontend auslagert. Dadurch halbiert man die Diesize schon fast und kann den Memory-IO-Die in einem anderen Prozess fertigen, wenn sie der neuste dort nicht lohnt.

[AffenJack]

Wenn man bedenkt, dass bei N10 die eigentlichen CUs+Frontend gerademal 60% des Dies ausmachen und der ganze IO-Kram bei 5nm eher noch mehr als weniger Platz einnehmen wird, würde es schon helfen, wenn man CUs+Frontend auslagert. Dadurch halbiert man die Diesize schon fast und kann den Memory-IO-Die in einem anderen Prozess fertigen, wenn sie der neuste dort nicht lohnt.

Jupp, allerdings wirst du eigentlich nen ordentlichen Perf/W Nachteil haben, wenn du die Bandbreite Zwischen IO und Computechip schaffen musst. Off-Die Datenleitungen kosten nunmal Energie.

Für mich macht das am meisten Sinn, wenn man beim IO Die 3d Stacking nutzen würde. Eins der Probleme beim Stacking ist die Wärme die abgeführt werden muss. Indem man den Ram aber auf den IO Die stackt, umgeht man das Problem. Der Computedie, der die meiste Wärme produziert, kann dann normal gekühlt werden und heizt nicht den Ram auf.

[fondness]

Danke für den neuen Thread. Dass RDNA1 und RDNA2 in einem Thread behandelt werden, erhöht nicht gerade die Übersicht^^. Vielleicht könnte man das bei der Gelegenheit auch splitten?

[dargo]

- gerüchteweiser Chiplet-Design aka MultiChip-Ansatz
Wird höchste Zeit, dass sowas auch bei GPUs kommt. Ich weiß zwar immer noch nicht wie das performancemäßig ohne Nachteile funktionieren soll, lasse mich aber gerne überraschen.

[Leonidas]

Danke für den neuen Thread. Dass RDNA1 und RDNA2 in einem Thread behandelt werden, erhöht nicht gerade die Übersicht^^. Vielleicht könnte man das bei der Gelegenheit auch splitten?


Schaffen wir glaube ich nicht mehr. Ist zu lang geworden. Müssen wir nun durch ;)

[HOT]

Jupp, allerdings wirst du eigentlich nen ordentlichen Perf/W Nachteil haben, wenn du die Bandbreite Zwischen IO und Computechip schaffen musst. Off-Die Datenleitungen kosten nunmal Energie.

Für mich macht das am meisten Sinn, wenn man beim IO Die 3d Stacking nutzen würde. Eins der Probleme beim Stacking ist die Wärme die abgeführt werden muss. Indem man den Ram aber auf den IO Die stackt, umgeht man das Problem. Der Computedie, der die meiste Wärme produziert, kann dann normal gekühlt werden und heizt nicht den Ram auf.
Ach das ist doch lächerlich. Bei dem was GPUs verbrauchen fallen die Interconnects nicht ins Gewicht.

[dargo]

Wenn man bedenkt, dass bei N10 die eigentlichen CUs+Frontend gerademal 60% des Dies ausmachen und der ganze IO-Kram bei 5nm eher noch mehr als weniger Platz einnehmen wird, würde es schon helfen, wenn man CUs+Frontend auslagert. Dadurch halbiert man die Diesize schon fast und kann den Memory-IO-Die in einem anderen Prozess fertigen, wenn sie der neuste dort nicht lohnt.
Soll bei RDNA3 nur ein Chiplet kommen und der ganze IO-Kram ausgelagert werden? Ich hatte jetzt an ein Multi-Chiplet-Design gedacht. Aber gut... selbst ersteres würde schon einiges bringen.

[unl34shed]

https://www.3dcenter.org/news/hardwa...-7-august-2020

Der Link geht nicht https://www.3dcenter.org/news/hardware-und-nachrichten-links-des-7-august-2020

Ach das ist doch lächerlich. Bei dem was GPUs verbrauchen fallen die Interconnects nicht ins Gewicht.

Sehe ich ähnlich, wenn man die Power Consumption von HBM2 nimmt sollte man für 1TB/s <10W im I/O brauchen. Sicherlich ein Nachteil, aber nicht wirklich Gravierend. Setzt aber auch ein Interposer voraus.

Die große Frage ist halt wie viel Bandbreite braucht es zwischen Compute Die und Memory Die.

https://www.extremetech.com/wp-content/uploads/2016/02/NV-HB.png


Für mich macht das am meisten Sinn, wenn man beim IO Die 3d Stacking nutzen würde. Eins der Probleme beim Stacking ist die Wärme die abgeführt werden muss. Indem man den Ram aber auf den IO Die stackt, umgeht man das Problem. Der Computedie, der die meiste Wärme produziert, kann dann normal gekühlt werden und heizt nicht den Ram auf.

Speicher auf dem I/O Die wäre sicher praktisch, aber dafür müsste der I/O Die denke ich deutlich größer ausfallen als nötig und dann kann man meiner Meinung nach auch ein active Interposer nehmen.

[AffenJack]

Sehe ich ähnlich, wenn man die Power Consumption von HBM2 nimmt sollte man für 1TB/s <10W im I/O brauchen. Sicherlich ein Nachteil, aber nicht wirklich Gravierend. Setzt aber auch ein Interposer voraus.

Die große Frage ist halt wie viel Bandbreite braucht es zwischen Compute Die und Memory Die.


Du brauchst auf jeden Fall die gleiche Bandbreite wie sonst auch. Du musst ja die ganze Bandbreite weiterleiten oder meinst, dass man vll sogar mehr braucht?

10W hören sich jetzt erstmal wenig an, aber so eine x700 Karte sollte so eine Bandbreite in 2 Jahren fast haben. Die 5700 hat 180 TDP und 135W GPU Power, wenn ich es recht in Erinnerung habe. 7% mehr GPU Power ist in Zeiten, wo man jedes Fünkchen Effizienz sucht schon eine Menge.

Speicher auf dem I/O Die wäre sicher praktisch, aber dafür müsste der I/O Die denke ich deutlich größer ausfallen als nötig und dann kann man meiner Meinung nach auch ein active Interposer nehmen.

Das stimmt, das könnte ein Problem sein.

[Leonidas]

Der Link geht nicht https://www.3dcenter.org/news/hardware-und-nachrichten-links-des-7-august-2020



Gefixt.

[ChaosTM]

Yeah - 48GB Titan incoming - 3990 .. oder eher 4990

[Cyberfries]

Speicherinterface und I/O auszugliedern klingt erstmal sinnvoll, wenn man bedenkt, dass diese Bereiche fast die Hälfte der Fläche einnehmen.
Wenn aber für jede GPU ein eigener solcher I/O/Speicher-Die benötigt wird, eher unangenehm.
Als kleinste Größe 128bit, für den größten Chip 3-4 davon, dann schleppe ich möglicherweise 2-3mal unnötigen I/O mit.
Wirklich charmant wäre das natürlich, wenn auf einen I/O/Speicher-Die HBM gestapelt wäre.

[HOT]

Vor allem kann man das IOD dann wieder einfach bei GloFo billig in 12LP+ fertigen lassen. Das profitiert ja eh nicht von 7nm oder weniger.

[Der_Korken]

Jupp, allerdings wirst du eigentlich nen ordentlichen Perf/W Nachteil haben, wenn du die Bandbreite Zwischen IO und Computechip schaffen musst. Off-Die Datenleitungen kosten nunmal Energie.


Das stimmt, aber irgendwelche Kompromisse muss man machen. Wenn man durch das Splitten den Compute-Die etwas breiter bauen kann, weil sich Yields verbessern oder man den IO-Die einen Prozess größer fertigen kann, spart man vielleicht mehr ein als der Interconnect kostet. Man würde dafür natürlich einen Interposer brauchen, damit man überhaupt auf die selbe Geschwindigkeit wie der VRAM kommt.

Soll bei RDNA3 nur ein Chiplet kommen und der ganze IO-Kram ausgelagert werden? Ich hatte jetzt an ein Multi-Chiplet-Design gedacht. Aber gut... selbst ersteres würde schon einiges bringen.

Ja, ich dachte an ein Chiplet. Man würde wie gesagt die GPU fast in zwei Hälften teilen. Den Compute-Chip weiter zu splitten wird sehr schwierig, denn anders als bei CPUs rechnen die CUs nicht alle komplett unabhängig vor sich hin, sondern es gibt ein zentrales Frontend, wo alles zusammenläuft. Alle CUs rechnen am selben Frame, greifen auf die selben Daten zu, tauschen Ergebnisse aus, etc. Ich will nicht ausschließen, dass es nicht irgendwann doch so gemacht wird, aber man müsste schon die Architektur von Grund auf darauf auslegen, dass die Berechnung gesplittet wird mit minimaler Kommunikation zwischen den einzelnen Teilen. Bei den HPC-Chips wird das sicherlich zuerst kommen und bei den Gaming-Chips wenn dann erst später.

Speicherinterface und I/O auszugliedern klingt erstmal sinnvoll, wenn man bedenkt, dass diese Bereiche fast die Hälfte der Fläche einnehmen.
Wenn aber für jede GPU ein eigener solcher I/O/Speicher-Die benötigt wird, eher unangenehm.

Da jede GPU ein anders dimensioniertes Speicherinterface braucht (nicht wie bei CPUs, wo von 4 bis 16 Cores alles Dualchannel ist), müsste man wohl immer Paare von IO- und Compute-Dies entwerfen, ja. Der Vorteil wäre trotzdem, dass man die Teile unabhängig voneinander entwickeln und möglicherweise austauschen kann. Zum Beispiel könnte man für den Compute-Die refreshen, aber den IO-Die behalten, weil sich die Speichertechnologie gleich geblieben ist.

[LasterCluster]

Speicherinterface und I/O auszugliedern klingt erstmal sinnvoll, wenn man bedenkt, dass diese Bereiche fast die Hälfte der Fläche einnehmen.
Wenn aber für jede GPU ein eigener solcher I/O/Speicher-Die benötigt wird, eher unangenehm.
Als kleinste Größe 128bit, für den größten Chip 3-4 davon, dann schleppe ich möglicherweise 2-3mal unnötigen I/O mit.
Wirklich charmant wäre das natürlich, wenn auf einen I/O/Speicher-Die HBM gestapelt wäre.

Das Ding heißt aber nicht I/O-Die, sondern wahrscheinlich Memory Complex Die. Dementsprechend könnte der Graphic Complex Die auch die zentrale Einheit sein inkl. Video-Output (und PCIe Input?).

Du bringts mich da auf eine Idee: Bei GPUs gibts mehrere MCDs zu je einem GCD und nicht ein IOD mit mehreren CCDs

[unl34shed]

Und welchen Vorteil sollte das haben?

[reaperrr]

Das Ding heißt aber nicht I/O-Die, sondern wahrscheinlich Memory Complex Die. Dementsprechend könnte der Graphic Complex Die auch die zentrale Einheit sein inkl. Video-Output (und PCIe Input?).

Wahrscheinlicher ist, dass der so heißt, weil der auch 'Memory' beinhaltet, ob nun HBM oder was anderes.

[LasterCluster]

Und welchen Vorteil sollte das haben?

Im Großen und Ganzen die gleichen Vorteile wie IOD+n*CCD. Nur das bei GCD+n*MCD der Datenaustausch zwischen den CUs on-die stattfinden kann.

[LasterCluster]

Wahrscheinlicher ist, dass der so heißt, weil der auch 'Memory' beinhaltet, ob nun HBM oder was anderes.

Schließt sich ja nicht aus. Ein HBM-MCD und ein GDDR-MCD. Und schon gibt es sowas wie N10 und N12 zum Preis von einem GCD.

[unl34shed]

Im Großen und Ganzen die gleichen Vorteile wie IOD+n*CCD. Nur das bei GCD+n*MCD der Datenaustausch zwischen den CUs on-die stattfinden kann.


Naja du sparst aber nur etwas Fläche auf dem Compute Chip indem du ein Interface gegen ein anderes tauschst, bei HBM dürften die die Ersparnis sogar gleich Null sein und du hast sogar höhere Kosten wegen dem zweiten Die.

Auch ist die Frage die ich mir stell, wie relevant ist der Datenaustausch zwischen zwei Shader Engines wirklich? In N10 hängen die einzelnen Shader Engines ja eh hinter ihrem eigenen L1 Cache. Von daher dürfte es eher Sinn ergeben, zwischen L2 und L1 den Cut zu machen und prinzipiell dann die Compute Dies aus ein oder zwei Shader Engines mit je 16-20CUs zu bauen, der Rest im IO die und dann den L1 erhöhen.


https://hexus.net/media/uploaded/2019/6/5493cd81-a4da-4432-ad28-c73bd1f37f53.PNG
https://hexus.net/media/uploaded/2019/6/3af2863e-d5a3-40d5-8757-252ae540215b.PNG

[LasterCluster]

Naja du sparst aber nur etwas Fläche auf dem Compute Chip indem du ein Interface gegen ein anderes tauschst, bei HBM dürften die die Ersparnis sogar gleich Null sein und du hast sogar höhere Kosten wegen dem zweiten Die.


Hast du dieses Problem nicht bei jeder Aufteilung?

In N10 hängen die einzelnen Shader Engines ja eh hinter ihrem eigenen L1 Cache. Von daher dürfte es eher Sinn ergeben, zwischen L2 und L1 den Cut zu machen und prinzipiell dann die Compute Dies aus ein oder zwei Shader Engines mit je 16-20CUs zu bauen, der Rest im IO die und dann den L1 erhöhen.

Der Cache shrinkt doch am besten und sollte deswegen bei den CUs und dem moderneren Prozess bleiben.

[mboeller]

ich glaube nicht, dass es sich beim I/O um einen Chip handelt. Eher ein aktiver Interposer. Die Präsentationen zu den CDNA Varianten hatten zumindest immer einen Interposer anstelle eines I/O-Chips.

[Der_Korken]

Auch ist die Frage die ich mir stell, wie relevant ist der Datenaustausch zwischen zwei Shader Engines wirklich? In N10 hängen die einzelnen Shader Engines ja eh hinter ihrem eigenen L1 Cache. Von daher dürfte es eher Sinn ergeben, zwischen L2 und L1 den Cut zu machen und prinzipiell dann die Compute Dies aus ein oder zwei Shader Engines mit je 16-20CUs zu bauen, der Rest im IO die und dann den L1 erhöhen.

Wenn du zwischen L1 und L2 trennst, bräuchtest du aber einen Extra-Chip für Frontend und L2. Vorausgesetzt, du schaffst das, hast du wieder neue Probleme, denn beide Sachen müssen aber mit der Anzahl der CUs mitskalieren. Du hast dann einen CU-Die, einen Frontend-Die und einen IO-Die. Und alles muss mit allem skalieren, d.h. wenn man die Anzahl der CU-Dies variabel mit 1 bis 4 wählt, dann sind entweder die 4 CU-Dies hoffnungslos frontend-limitiert oder der Frontend-Die muss so groß sein, dass er 4 CU-Dies füttern kann, was ihn aber für kleine GPUs zu teuer macht. Also braucht man für alle Leistungsklassen wieder eigene Frontend-Dies.

Wenn dann müsste das Frontend auf mehrere Dies verteilt sein und so arbeiten können, dass es parallel an einem Frame arbeiten kann ohne viel Daten unter den Dies austauschen zu müssen. Dass AMD mit dem L1$ eine Zwischenstufe eingeführt und Nvidia beim A100 den L2$ gesplittet hat, könnten in so eine Richtung deuten, aber es wird definitiv schwieriger werden als bei den CPUs.

[Zossel]

Hast du dieses Problem nicht bei jeder Aufteilung?


Jedes "Compute"-Die bekommt eigenes RAM per z.b. HBM.
Jedes "Compute"-Die berechnet einen Teil der angezeigten Fläche.
Der RAM der "Compute"-Dies wird für Geometriedaten, Texturen, etc. ondemand gesynct.
Das IO-Die macht PCIe, Videodecode, RamSync, Displayport, etc.
Einiges wird man trotzdem doppelt rechnen müssen.

[LasterCluster]

Jedes "Compute"-Die bekommt eigenes RAM per z.b. HBM.
Jedes "Compute"-Die berechnet einen Teil der angezeigten Fläche.
Der RAM der "Compute"-Dies wird für Geometriedaten, Texturen, etc. ondemand gesynct.
Das IO-Die macht PCIe, Videodecode, RamSync, Displayport, etc.
Einiges wird man trotzdem doppelt rechnen müssen.

Nicht vergessen: Die Dinger heißen GCD und MCD, nicht IOD und CCD. Bei dir wäre dann quasi MCD=CCD und GCD=IOD, wenn ich es richtig verstanden habe, da "Jedes Compute-Die [...] eigenes RAM [bekommt]", oder?

[AffenJack]

Auch ist die Frage die ich mir stell, wie relevant ist der Datenaustausch zwischen zwei Shader Engines wirklich? In N10 hängen die einzelnen Shader Engines ja eh hinter ihrem eigenen L1 Cache. Von daher dürfte es eher Sinn ergeben, zwischen L2 und L1 den Cut zu machen und prinzipiell dann die Compute Dies aus ein oder zwei Shader Engines mit je 16-20CUs zu bauen, der Rest im IO die und dann den L1 erhöhen.


Das macht kein Sinn. Erstens hat LasterCluster recht, dass du den Cache auf dem kleineren Prozess haben willst, da er gut shrinkt und 2tens erhöhst du die Bandbreite des benötigten Interconnects dann gleich mal 2-3x und bist statt bei 10W vll bei 30W für den Interconnect. Zusätzlich kommt dann noch die erhöhte Latanz dazu. Es hat nen guten Grund wieso auch bei Zen der L3 natürlich bei den Cores ist und nicht bei IO, das dürfte sich bei GPUs auch nicht ändern.

[Cyberfries]

Du bringts mich da auf eine Idee: Bei GPUs gibts mehrere MCDs zu je einem GCD und nicht ein IOD mit mehreren CCDs

Ja, logisch, eben das habe ich beschrieben?
Das GCD zu zerreißen erscheint mir weniger sinnvoll.
Sind diese Bezeichnungen (MCD / GCD) eigentlich gesichert, oder anders gefragt: Wo kommen die Namen her?

[LasterCluster]

Ja, logisch, eben das habe ich beschrieben?
Das GCD zu zerreißen erscheint mir weniger sinnvoll.
Sind diese Bezeichnungen (MCD / GCD) eigentlich gesichert, oder anders gefragt: Wo kommen die Namen her?

Sorry, hab ich nicht zu 100% gesehen. Diese Bezeichnungen sind wohl das einzige "sichere" und kommen von

https://twitter.com/KOMACHI_ENSAKA/status/1291796703767457792

[mboeller]

ich bin mir jetzt nicht sicher, ob ich es richtig gerechnet habe, aber zwischen dem L1-Cache und dem L2-Cache bei RDNA sind zB. bei 2250MHz ca. 72GB/sec (4 x 64bit x 2250MHz).

Die neue IF-Architektur soll die 4,5-fache Bandbreite von PCIE-3.0 erlauben, also 16 x 4,5 = 72GB/sec ...

das passt also ganz gut zusammen.

https://www.anandtech.com/show/15596/amd-moves-from-infinity-fabric-to-infinity-architecture-connecting-everything-to-everything

jetzt müsste man nur noch die Latenz verstecken können ...

[unl34shed]

Ein vorweg, ich gehe wenn es Compute Dies gibt davon aus, dass man sie wie bei Zen entsprechend mehrfach an einen IO Die anschließt. Und der I/O Die dann entsprechend wie bei Ryzen und Epyc unterschiedlich groß ausfällt.

Hast du dieses Problem nicht bei jeder Aufteilung?

Prinzipiell ja, aber anders könnte man in einem gemeinsamen IO Die noch zusätzlich Display Controller, PCIe Phy, L2 Cache, Video Engine, {ggf. noch Geometry-, Command Processor und ACEs} unterbringen. Das macht bei N10 zusammen ca. die hälfte des Chips aus. Die Frage ist wie viel schlechter hier die Effizienz der einzelnen Module wird, wenn man sie nicht shrinkt. Beim I/O sollte es egal sein.

Der Cache shrinkt doch am besten und sollte deswegen bei den CUs und dem moderneren Prozess bleiben.

Jain, in einem gemeinsamen IO Die mit L2 Cache dient der L2 als Coherenter Cache für die GPU und man spart sich dadurch die Synchronisation der einzelnen Dies (unnötige off-chip Transfers).

Wenn du zwischen L1 und L2 trennst, bräuchtest du aber einen Extra-Chip für Frontend und L2. Vorausgesetzt, du schaffst das, hast du wieder neue Probleme, denn beide Sachen müssen aber mit der Anzahl der CUs mitskalieren. Du hast dann einen CU-Die, einen Frontend-Die und einen IO-Die. Und alles muss mit allem skalieren, d.h. wenn man die Anzahl der CU-Dies variabel mit 1 bis 4 wählt,...

Ich stelle mir das wie oben vor, mehrere I/O Dies die auch das Frontend beinhalten. Je nach Leistungklasse fallen diese dann kleiner oder größer aus. Und mit 4 Chips sollte man das ganze Lineup abdecken können und dabei vom günstigeren Prozess der I/O Dies und bessere Yield bei den CU Dies profitieren.

[lowend: 128bit GDDR6, 1CU I/F] vielleicht nicht notwendig wegen APUs
entry: 256bit GDDR6, 2CU I/F
midrange: 384-448bit GDDR6, 4CU I/F
highend: HBM2/e/3 what ever, 6CU I/F

Nagelt mich auf den Zahlen nicht fest, nur ein Beispiel.

Das macht kein Sinn. Erstens hat LasterCluster recht, dass du den Cache auf dem kleineren Prozess haben willst, da er gut shrinkt und 2tens erhöhst du die Bandbreite des benötigten Interconnects dann gleich mal 2-3x und bist statt bei 10W vll bei 30W für den Interconnect. Zusätzlich kommt dann noch die erhöhte Latanz dazu. Es hat nen guten Grund wieso auch bei Zen der L3 natürlich bei den Cores ist und nicht bei IO, das dürfte sich bei GPUs auch nicht ändern.

Meiner Meinung nach würde ein gesplitteter L2, also pro GCD mehr Probleme bereiten und den Bandbreitenbedarf weiter hoch treiben, da du zwischen den L2 Caches syncen musst. Bei RDNA1 ist der L1 Read-only und dient rein als puffer, geschrieben wird in den L2. Also perfekt um hier zu trennen, gesynct wird automatisch für alle GCDs im L2. Ich sehe hier keinen 2-3x höheren Bandbreitenbedarf.

Mit der Latenz sollten die GPUs eh schon umgehen können, die Daten müssen nur nach kommen.

ich bin mir jetzt nicht sicher, ob ich es richtig gerechnet habe, aber zwischen dem L1-Cache und dem L2-Cache bei RDNA sind zB. bei 2250MHz ca. 72GB/sec (4 x 64bit x 2250MHz).

Das sind 64Byte -> 576GB/s. Im Architecture Guide für RDNA1 wird der L2 Cache mit einer Banbreite von 1,95TB/s angegeben müsste die Summe der Bandbreite zum L2-L1 und zum L2-Speicher sein, beides vermutlich bidirektional.



Generell glaube ich bei MCM GPUs, dass wir diese erster bei CDNA sehen werden.

[AffenJack]

ich bin mir jetzt nicht sicher, ob ich es richtig gerechnet habe, aber zwischen dem L1-Cache und dem L2-Cache bei RDNA sind zB. bei 2250MHz ca. 72GB/sec (4 x 64bit x 2250MHz).

Die neue IF-Architektur soll die 4,5-fache Bandbreite von PCIE-3.0 erlauben, also 16 x 4,5 = 72GB/sec ...
.

Du denkst die 72Gb/s sind die Bandbreite, die du zum L2 brauchst? Das klingt um mindestens den Faktor 10 zu langsam. Dann brauchst du auch keinen schnellen Ram. Nur zum Vergleich, da ich von AMD keine zahlen habe.
Ein Turing T4 schafft zb real 1,2 TB/s L2 Cache Bandbreite bei 320 GB/s Speicherbandbreite.


Meiner Meinung nach würde ein gesplitteter L2, also pro GCD mehr Probleme bereiten und den Bandbreitenbedarf weiter hoch treiben, da du zwischen den L2 Caches syncen musst. Bei RDNA1 ist der L1 Read-only und dient rein als puffer, geschrieben wird in den L2. Also perfekt um hier zu trennen, gesynct wird automatisch für alle GCDs im L2. Ich sehe hier keinen 2-3x höheren Bandbreitenbedarf.

Ich meinte auch nicht im Vergleich zu gesplittetem L2, sondern im Vergleich zum IO-Die. Das splitten ist so natürlich auch ein Problem. Das macht das ganze bei GPUs ja auch so kompliziert.


Das sind 64Byte -> 576GB/s. Im Architecture Guide für RDNA1 wird der L2 Cache mit einer Banbreite von 1,95TB/s angegeben müsste die Summe der Bandbreite zum L2-L1 und zum L2-Speicher sein, beides vermutlich bidirektional.


So, mit 1,95 TB/s sind wir auch hier bei der 4fachen Bandbreite zum L2 im Vergleich zum Ram, ähnlich wie die Messungen beim Nv T4. Nur mal hochskaliert auf GPUs mit 1Tb/s -> 4Tb/s L2 benötigte Bandbreite sind wir einfach schon bei ~40W Verbrauch durch den Interconnect (1pJ/Bit, 2x Effizienz von IF). Das sprengt dir jede Ersparnis, die du in irgendeiner Form durch mehrere Dies kriegen kannst. Daher glaube ich nicht an L2 auf dem IO Die.

[mboeller]

Das sind 64Byte -> 576GB/s. Im Architecture Guide für RDNA1 wird der L2 Cache mit einer Banbreite von 1,95TB/s angegeben müsste die Summe der Bandbreite zum L2-L1 und zum L2-Speicher sein, beides vermutlich bidirektional.



die 72GB/s sind für jeden L2-Cache, davon gibt es 16 (siehe Schaubild oben), also in Summe 1152 GB/sec

passt es dann besser?

[AffenJack]

die 72GB/s sind für jeden L2-Cache, davon gibt es 16 (siehe Schaubild oben), also in Summe 1152 GB/sec

passt es dann besser?

Könnte durchaus hinkommen.

[unl34shed]

So, mit 1,95 TB/s sind wir auch hier bei der 4fachen Bandbreite zum L2 im Vergleich zum Ram, ähnlich wie die Messungen beim Nv T4. Nur mal hochskaliert auf GPUs mit 1Tb/s -> 4Tb/s L2 benötigte Bandbreite sind wir einfach schon bei ~40W Verbrauch durch den Interconnect (1pJ/Bit, 2x Effizienz von IF). Das sprengt dir jede Ersparnis, die du in irgendeiner Form durch mehrere Dies kriegen kannst.

Faktor 4 L2 zu RAM Bandbreite passt ja auch meiner Meinung Nach. Der L2 muss mit Voller Geschwindigkeit mit dem RAM kommunizieren können (lesen und schreiben) und diese Daten auch zum L1 weiterleiten bzw davon empfangen können, um kein Flaschenhals zu sein.
512 GB/s RAM -> Memory Controller <-> 512 GB/s RX + 512 GB/s TX = 1TB/s <-> L2 <-> 512 GB/s RX + 512 GB/s TX = 1TB/s <-> L1

Aber die komplette L2 Bandbreite interessiert nicht. Interessant für den Interconnect ist nur L1-L2 und damit in etwa die RAM Bandbreite, seperate RX/TX Leitungen sollte bei einem bidirektionalen Interface nicht notwendig sein.

[unl34shed]

die 72GB/s sind für jeden L2-Cache, davon gibt es 16 (siehe Schaubild oben), also in Summe 1152 GB/sec

passt es dann besser?

Nein, das sind 64 byte per Cycle (clock) und davon 4 verbindungen, da es 4 L1 Caches bei Navi10 gibt.
-> 64 Byte * 2,25GHz*4 = 576GB/s

16 Way bedeutet, dass der L1 Cache 16 Unabhängige Read/Write Ports hat und parallel beschrieben/gelesen werden kann. An diesen 16 Ports hängen dann unter anderem die L0 Caches der CUs

[Cyberfries]

Derzeit wird ein AMD Patent viel durch die sozialen Medien gereicht über "ADAPTIVE CACHE RECONFIGURATION VIA CLUSTERING".
https://www.freepatentsonline.com/y2020/0293445.html
Teils wird eine Verbindung gesucht zu dem spekulierten "Infinity Cache", was aber mehrheitlich abgelehnt wird.

Die Twitter-Nutzer Nerdtech und Devilfish hatten zuletzt eine Diskussion über dieses Patent im Zusammenhang mit RDNA3.
Nerdtech: There is a very interesting patent just published from AMD's graphics division. Note that it was filed awhile ago,
and this kind of novel cache adaptation feature could be very useful for RDNA 2 and beyond. More thoughts soon.
Devilfish: It's not what you think it is.
Nerdtech: Do enlighten us all, please.
Devilfish: Remember what RDNA3 does and why does L1 even exist?
Nerdtech: RDNA 3 isn't here anytime soon, so no I don't remember what it does. If you are assuming
GPU chiplets don't need a more efficient shared L1 (within a single shader array), then we have to disagree.
Devilfish: They need shared L1$ per several shader arrays for reasons more than obvious.
Nerdtech: Depends on how the chiplets are designed to split the monolithic GPU into smaller partitions.
Devilfish: It's painfully obvious how.
Nerdtech: I won't pretend to be a high level GPU engineer, so it's not entirely obvious to me,
besides the modularity of the shader engine + 2 array design already in RDNA1 being fit for a chiplet.
Devilfish: It's not just fit, it's intended to evolve into it.
Nerdtech: Yes, I covered this back in 2016 and 2017 in my vids discussing chiplet GPUs as the future with Navi innovations,
back when it was an unpopular opinion, with all the typical "you can't do it for GPUs, bcoz complexity, yo!"
Devilfish: You still can't do it for GPUs without expensive 3D packaging which is what AMD has a boner for.

Kurz zusammengefasst und interpretiert:
- Die Aufteilung in L0/L1/L2-Cache von RDNA soll eine Vorbereitung auf Multi-Die sein.
- Dabei soll je Graphics Die eine Shader-Engine (also min. zwei Shader-Arrays mit jeweils eigenem L1$) Platz finden.
- Graphics-Dies werden nicht neben, sondern auf den Memory-Dies (mit dem L2$) platziert.
- Das angesprochene Patent kümmert sich um die Verwaltung des L1$ zwischen den Shader-Arrays.
Wie gesagt: Eigene Interpretation ist dabei, das Patent habe ich selbst nicht durchgearbeitet.

Auf den ersten Blick ergibt das Sinn.
Eine Stapelung sorgt dafür, dass kein Interposer über den Unmengen an Daten rauschen notwendig ist.
Ein zwischen den Arrays frei verwaltbarer L1$ scheint auch sinnvoll, doch warum nicht den L1$ direkt der Shader Engine zuordnen?
L0/L1/L2 als Vorbereitung für RDNA3 würde größere Umbauarbeiten bei RDNA2 im Bereich Cache eher ausschließen.
Zum Thema Die-stapeln: Muss ja nicht wie bei HBM sein, an sich würde doch auch die Streichholzturm-Methode gehen, oder?
Das würde die Hitze-Thematik entschärfen.
Ein bis zwei längliche Memory-Die, quer oben drauf zwei bis vier längliche Graphics-Die.

[Gipsel]

16 Way bedeutet, dass der L1 Cache 16 Unabhängige Read/Write Ports hat und parallel beschrieben/gelesen werden kann. An diesen 16 Ports hängen dann unter anderem die L0 Caches der CUs"16way" bezeichnet die Assoziativität des Caches, nicht die Anzahl der Ports.

[unl34shed]

Stimmt, hab ich irgendwie falsch verstanden...

[Berniyh]

Ich poste es mal noch hier rein, in der Hoffnung, dass sich die RDNA3/Navi3x Diskussion evtl. eher hierher verschiebt:
https://www.reddit.com/r/Amd/comments/j06xcd/number_of_cus_of_navi_23_navi_31_van_gogh_cezanne/

Demnach hätte Navi 31 die gleiche Konfiguration (80 CU in 4×2×10 Aufteilung) mit 16 TCCS und damit wahrscheinlich 16 Speicherkanälen (sofern sich nicht mehrere Speicherkanäle einen Cache teilen).

[HOT]

Das verunmöglicht mMn die Chiplet-Variante. Ich würd eher darauf tippen, dass AMD die CUs bei N3x aufbohrt um erheblich umfassenderes RT zu ermöglichen. 80CUs mit der neuen Config dürfte in 5nm auch 250-350mm² werden, das zusammen als MCM mit einem I/O-Die gepaart würde den bisherigen Gerüchten durchaus entsprechen würde.

[Cyberfries]

Da Raytracing bei AMD in Konkurrenz steht, es keine eigenen RT-Einheiten gibt, müsste für eine
Verbesserung entweder die Anzahl an CUs steigen oder eben doch gesonderte RT-Einheiten.
Bei 80CUs ist Ersteres raus, sofern N31 der leistungsstärkste Chip ist.

Ausgehend von N10/xBox würden bei 80CUs in 340mm² etwa 120mm² an L2$/Interface/IO
auf das MCD entfallen und 220mm² auf das GCD, in 5nm entsprechend weniger.
(340mm², da RDNA2-Flächen noch unbekannt, ist eh nur ein Rechenexempel)
Einen gestapelten Chip mit unter 200mm² und 300watt zu kühlen... "ambitioniert".
Spricht auch eher gegen N31 als Speerspitze.

edit: Da zuletzt je Generation etwa +50% Leistung dazu kam, sollte RDNA3 eher
Richtung 120CU tendieren. 6SE à 10WGP oder 4SE à 15WGP?

[HOT]

80CUs in 5nm könnten durchgängig auf 2,5GHz laufen, soll N22 ja in 7nm schon tun, und werden sicherlich noch weitere Verbesserungen mitbringen, 30% mehr als N21 kann man also sicherlich erwarten. gepaart das ganze mit einem Universal-I/O-Chip, der 384Bit GDDR möglich macht oder eben HBM. Die verbesserten RT-Ansätze zu erörtern ist sicherlich sinnvoll. Es gab doch mal ne Aussage, dass AMD RT jetzt ernster nimmt.

Interessant ist i.Ü. auch, dass AMD es offenbar nicht für sinnvoll hält, mehr als 5 WGPs pro Pipeline zu verbauen. Das passt aber auch sicherlich gut zur veranschlagten Pipecleaner-Größe.

MMn ist es ziemlich klar, dass AMD bei N21 noch einen draufsetzt und die 5nm einfach ausnutzt um erster zu sein in möglichst vielen Bereichen.

Übrigens kann es noch einen weiteren Grund geben, nämlich, dass ein 384Bit Interface bei einem evtl. kleineren 200mm²-5nm-Chip einfach nicht sinnvoll ist und in einen anderen Chip ausgelagert werden muss.

[dargo]

80CUs in 5nm könnten durchgängig auf 2,5GHz laufen, soll N22 ja in 7nm schon tun...
Wie schön, dass das schon bestätigt ist. :freak: Deine Spekulationen neigen immer zu sehr zum Optimismus. ;)

[HOT]

SOLL

[Gipsel]

Da Raytracing bei AMD in Konkurrenz steht, es keine eigenen RT-Einheiten gibt, müsste für eine
Verbesserung entweder die Anzahl an CUs steigen oder eben doch gesonderte RT-Einheiten.RDNA2 hat dedizierte Intersection-Einheiten (die können nichts Anderes und liegen ohne RT brach) für das hardwarebeschleunigte Raytracing. Insofern gibt es sehr wohl "eigene RT-Einheiten".

[Cyberfries]

Insofern gibt es sehr wohl "eigene RT-Einheiten".

Die Einheiten sind Teil der CUs, nicht separat davon, es gibt keine speziellen "RT-CUs".
Entweder Texture oder RT, nicht beides, steht in Konkurrenz zueinander, das wollte ich aussagen.

[Gipsel]

Die Einheiten sind Teil der CUs, nicht separat davon, es gibt keine speziellen "RT-CUs".Und bei nV sind die "RT-Cores" Teil der SMs (jeder SM hat einen und der hängt am L1-Cache des SM wie die Intersection-Einheiten bei AMD am L0 der CU hängen [die Cacheorganisation mitsamt Numerierung der Level ist unterschiedlich]). Und?
Dies macht übrigens auch absolut Sinn, müssen doch sowieso Daten mit den Recheneinheiten da ausgetauscht werden (trifft ein Strahl irgendwas, muß der Shader für die getroffenen Fläche ausgeführt werden).
Entweder Texture oder RT, nicht beides, steht in Konkurrenz zueinander, das wollte ich aussagen.Auch bei nV konkurrieren Textureinheiten und RT-Cores prinzipiell um Bandbreite. Ist jetzt nicht der große Unterschied. Bei AMD wird etwas mehr Hardware gemeinsam genutzt, was den Hardwareaufwand reduziert. Ob und wieviel das an Performance kostet, kommt vermutlich stark auf die Situation an und es ist noch nicht mal gesagt, daß das im Normalbetrieb (Textureinheiten laufen längst nicht immer am Anschlag) eine wesentliche Einschränkung darstellen wird.

[mboeller]

RDNA2 hat dedizierte Intersection-Einheiten (die können nichts Anderes und liegen ohne RT brach) für das hardwarebeschleunigte Raytracing. Insofern gibt es sehr wohl "eigene RT-Einheiten".


oder sie haben vielleicht so was gemacht:

3D Rasterization–Unifying Rasterization and Ray Casting (https://www.researchgate.net/publication/228373400_3D_Rasterization-Unifying_Rasterization_and_Ray_Casting)

Ist zwar nur Raycasting, aber der Intersection-Test selbst sollte zumindest sehr ähnlich funktionieren (denke ich...)

[Gipsel]

oder sie haben vielleicht so was gemacht:

3D Rasterization–Unifying Rasterization and Ray Casting (https://www.researchgate.net/publication/228373400_3D_Rasterization-Unifying_Rasterization_and_Ray_Casting)

Ist zwar nur Raycasting, aber der Intersection-Test selbst sollte zumindest sehr ähnlich funktionieren (denke ich...)Extrem unwahrscheinlich. Es widerspräche allen bisher verfügbaren Informationen.

[mksn7]

Wenn ich das richtig sehe auch nur für primary rays? In Spielen wird momentan alles mögliche gemacht mit Raytracing, aber keine primary rays.

[RLZ]

oder sie haben vielleicht so was gemacht:
Sicher nicht. Die First Intersection werden weiterhin rasterisiert werden, bis ihr an Anteil an den Gesamtkosten so klein ist, dass es nicht mehr relevant ist, ob man sie raytraced oder nicht. Da sind wir sicher noch ein paar GPU Generationen weg.Und selbst dann wird man den Rasterisierer aus Kompatibilitätsgründen eingebaut lassen.


Weiß eigentlich jemand ungefähr wieviel Die-Fläche für die Rasterizer draufgeht?

[Berniyh]

Erste Navi 31 Infos gab es ja aus der discovery binary die mit dem Treiber für OS X mitgeliefert wurde:
https://www.reddit.com/r/Amd/comments/j06xcd/number_of_cus_of_navi_23_navi_31_van_gogh_cezanne/?utm_source=share&utm_medium=web2x&context=3

stblr hat noch ein bisschen weiter gegraben und zudem auch den Output von seinem Skript für die einzelnen Chips hochgeladen:
https://www.reddit.com/r/Amd/comments/j7bpzs/an_update_on_navi_2x_firmware/

Geht jetzt hauptsächlich um Navi 2x, aber auch der Output für Navi 31 ist dabei:
http://ix.io/2A5f
binary_signature: 0x28211407
version_major: 1
version_minor: 1
binary_checksum: 26761
binary_size: 1344
table_list[0]:
offset: 60
checksum: 0x6131
size: 1048
table_list[1]:
offset: 1108
checksum: 0x0262
size: 100
table_list[2]:
offset: 1208
checksum: 0x0131
size: 136

signature: 1396985929
version: 2
size: 1048
id: 1588324766
num_dies: 1
die_id: 0
die_offset: 140

die_id: 0
num_ips: 52

ATHUB #0 2.1.0
CLKA #0 11.0.3
CLKA #1 11.0.3
CLKA #2 11.0.3
CLKA #3 11.0.3
CLKA #4 11.0.3
CLKA #5 11.0.3
CLKA #6 11.0.3
CLKA #7 11.0.3
CLKA #8 11.0.3
CLKA #9 11.0.3
CLKB #0 11.0.3
DBGU_NBIO #0 3.0.0
DF #0 3.7.1
DFX #0 5.0.0
DFX_DAP #0 2.0.0
DMU #0 3.0.0
FUSE #0 11.0.5
GC #0 11.0.0
HDP #0 5.0.3
MMHUB #0 2.1.0
MP0 #0 11.0.7
MP1 #0 11.0.7
NBIF #0 3.3.0
OSSSYS #0 5.0.3
PCIE #0 6.5.0
PCS #0 4.8.0
PCS #1 4.8.0
PCS #2 4.8.0
PCS #3 4.8.0
PCS #4 4.8.0
SDMA0 #0 5.2.0
SDMA1 #0 5.2.0
68 #0 5.2.0
69 #0 5.2.0
SMUIO #0 11.0.6
SYSTEMHUB #0 2.3.0
THM #0 11.0.5
UMC #0 8.7.0
UMC #1 8.7.0
UMC #2 8.7.0
UMC #3 8.7.0
UMC #4 8.7.0
UMC #5 8.7.0
UMC #6 8.7.0
UMC #7 8.7.0
USB #0 4.8.0
UVD/VCN #0 3.0.0
UVD/VCN #1 3.0.1
WAFLC #0 4.8.0
XGMI #0 4.8.0
XGMI #1 4.8.0

table_id: 17223
version_major: 1
version_minor: 1
size: 100
num_se: 4
num_wgp0_per_sa: 5
num_wgp1_per_sa: 0
num_rb_per_se: 4
num_gl2c: 16
num_gprs: 1024
num_max_gs_thds: 32
gs_table_depth: 32
gsprim_buff_depth: 1792
parameter_cache_depth: 1024
double_offchip_lds_buffer: 1
wave_size: 32
max_waves_per_simd: 16
max_scratch_slots_per_cu: 32
lds_size: 64
num_sc_per_se: 1
num_sa_per_se: 2
num_packer_per_sc: 4
num_gl2a: 4
num_cus (computed): 80
unknown0: 10
unknown1: 16
unknown2: 80

Interessant ist bei erst mal der Parameter GC.
Bei Navi 21:
GC #0 10.3.0

GC scheint also die GPU ID zu sein. Diese ist – wie von Komachi schon gemutmaßt – bei Navi 31:
GC #0 11.0.0
Navi 3x/RDNA3 läuft also bei AMD wohl wirklich als 11. GPU Gen und nicht – wie RDNA und RDNA2 – als 10.

Übrigens sind alle(!) anderen Parameter in der Ausgabe identisch zu Navi 21.
Das legt die Vermutung nahe, dass es sich bei Navi 31 (in der Form wie in dieser Binary angegeben) um eine Art Entwicklungsplattform oder Prototypen für RDNA3 handelt?

[Leonidas]

https://twitter.com/Underfox3/status/1317821015314006017

In MICRO2020, researchers presented LADM, a holistic locality-aware data management system designed to operate on massive logical GPUs composed of multiple discrete devices, which are themselves composed of chiplets.
https://www.microarch.org/micro53/papers/738300b022.pdf

https://pbs.twimg.com/media/EknWyPEXIAAXZ9G?format=jpg&name=large

[why_me]

Ist das hier nicht OT? Einer der Autoren: "David Nellans NVIDIA"

[Leonidas]

Es ist ja doppelt OT, weil ich nicht denke, das Navi 3X schon mit mehreren Core-Chiplets anrückt. Aber da es so selten was zum Thema Multi-GPU aus der Software-Entwicklung gibt ...

[HOT]

[...]

GC scheint also die GPU ID zu sein. Diese ist – wie von Komachi schon gemutmaßt – bei Navi 31:
GC #0 11.0.0
Navi 3x/RDNA3 läuft also bei AMD wohl wirklich als 11. GPU Gen und nicht – wie RDNA und RDNA2 – als 10.

Übrigens sind alle(!) anderen Parameter in der Ausgabe identisch zu Navi 21.
Das legt die Vermutung nahe, dass es sich bei Navi 31 (in der Form wie in dieser Binary angegeben) um eine Art Entwicklungsplattform oder Prototypen für RDNA3 handelt?


Dass alle anderen Parameter identisch sind würde für meine Theorie sprechen, dass N31 ein reines Einzelstück ist. Besseres RT erfordert neue CUs und die erfordern einen neuen Befehlssatz aber der Rest des Chips kann ja "gleich" bleiben, dann aber vielleicht in N5.

[basix]

Mir kam gerade etwas in den Sinn bezüglich RDNA3. Die Idee basiert auf RDNA2 :D

N22 soll 40 CUs haben, N21 80 CUs. Das ist 2x und ein viel grösserer Abstand als normalerweise. Für N31 sollen es ebenfalls 80 CUs sein und Chiplets sind im Gespräch. Nun meine Idee: RDNA2 ist vom Aufbau her eine Vorstufe von RDNA3 und somit dessen Chiplets.

MCD = Memory Controller (2048b HMB2e oder 384b GDDR6) + I/O + Multimedia --> 6nm
GCD = 40 CUs, 2 Shader Engines --> 5nm


Hier gäbe es wieder den 2x Abstand zwischen 1 und 2 Chiplets. Mit (32), 36 und 40 CU Chiplets könnte man wieder einen ähnlichen SKU Stack aufbauen:

(32), 36, 40, (64), 72, 80 CUs
~140-300W

Desweiteren würde ich von doppelter FPU Leistung pro CU ausgehen, siehe Ampere. Das Chiplet wäre dann in N5P grob geschätzt ca. 120-140mm2 gross.

Der kleinste Chip wäre dann wieder monolithisch @ 5nm und 24 CU in ca. 140mm2 und GDDR6 anstatt HBM.

[Nightspider]

Frage:

Früher gabs ja schon QuadCores die aus zwei DualCore Chips bestanden.

Wieso hat man Chiplets nicht schon früher bei Grafikkarten getestet? Was waren die größten Probleme und Hindernisse?

Sind Chiplets jetzt bald erst möglich wegen dem Infinity Fabric? Weil ich kann mir nicht vorstellen das es früher nur an der Bandbreite zwischen den Chips gefehlt hätte.

Oder gingen die großen Firmen davon aus das Chiplets mehr Nachteile haben also Vorteile und haben es nie so detailliert ausgetestet wie AMD dies scheinbar vor einigen Jahren tat?

[Brillus]

Frage:

Früher gabs ja schon QuadCores die aus zwei DualCore Chips bestanden.

Wieso hat man Chiplets nicht schon früher bei Grafikkarten getestet? Was waren die größten Probleme und Hindernisse?

Sind Chiplets jetzt bald erst möglich wegen dem Infinity Fabric? Weil ich kann mir nicht vorstellen das es früher nur an der Bandbreite zwischen den Chips gefehlt hätte.

Oder gingen die großen Firmen davon aus das Chiplets mehr Nachteile haben also Vorteile und haben es nie so detailliert ausgetestet wie AMD dies scheinbar vor einigen Jahren tat?
Der Bandbreitenbedarf zwischen den Chips wäre massive höher als bei CPUs. Wobei mich der Cache hoffen lässt das AMD weiter ist. Sprechen da von besserer Datenlokalität. Genau das braucht man fpr Chiplets.

[Cyberfries]

Wieso hat man Chiplets nicht schon früher bei Grafikkarten getestet? Sind Chiplets jetzt bald erst möglich wegen dem Infinity Fabric?

Chiplets im Sinne von zwei Chips nebeneinander sollten immer noch ziemlich unmöglich sein.
Der gewaltige Bedarf an Daten der über die Infinity Fabric wandert und gewaltig viel Energie schluckt,
verringert sich auch durch Infinity Cache nicht, das hilft nur bei Daten die vom Chip runter müssen.

Sinn ergibt das ganze nur, wenn Chips so kombiniert werden, dass keine Daten über die IF müssen.
Sprich: 3D-Stacking mit GCD (Graphics Compute Die) auf MCD (Memory Complex Die mit SI und I$)

[davidzo]

Der Bandbreitenbedarf zwischen den Chips wäre massive höher als bei CPUs. Wobei mich der Cache hoffen lässt das AMD weiter ist. Sprechen da von besserer Datenlokalität. Genau das braucht man fpr Chiplets.

Der Cache ändert erstmal überhaupt nichts an der Chip to Chip Komunikation, eher im Gegenteil macht neue Probleme. Mehrere Compute Dies nebeneinander hätten genau das Zen1 Problem, dass Teile des VRAM nur über Infinity Fabric ansprechbar wären. Außerdem willst du nicht dass die Caches synchronisiert werden weil das zuviel Bandbreite kostet, mit dem Ergebnis dass die Daten Dupliziert abgelegt werden und 2x 128mb sind demnach ganz nach Zen2 manier eben nicht 256mb mit doppelter bandbreite sondern bleiben eben nur 2x 128mb für jeweils die Hälfte der CUs des Gesamtpackages.

Gerade nachdem wir jetzt mit Zen3 gesehen haben wohin die Reise bei AMD geht macht das keinen Sinn dass man nochmal sowas pullt :rolleyes:


Chiplets im Sinne von zwei Chips nebeneinander sollten immer noch ziemlich unmöglich sein.
Der gewaltige Bedarf an Daten der über die Infinity Fabric wandert und gewaltig viel Energie schluckt,
verringert sich auch durch Infinity Cache nicht, das hilft nur bei Daten die vom Chip runter müssen.

Sinn ergibt das ganze nur, wenn Chips so kombiniert werden, dass keine Daten über die IF müssen.
Sprich: 3D-Stacking mit GCD (Graphics Compute Die) auf MCD (Memory Complex Die mit SI und I$)

Exakt, das macht am meisten Sinn.
2D verfahren wie Info LSI bieten für GPUs einfach zu wenig Bandbreite, weniger contact points und größere Leistungslänge. Daher macht es Sinn erst bei 3d stacking eine GPU damit zu bauen. Aktuelle Verfahren mit Speicher direkt auf dem Die sind wiederum thermisch nicht für highend GPUs geeignet. Den Cache mit SI nach unten macht also am meisten Sinn, dann kann der Compute Die gut gekühlt werden. Gleichzeitig spart man eine Menge Diefläche weil man i/o features die schlecht skalieren auf den Base Die packt. Für den basedie könnte TSMCs 12nm genutzt werden oder GFs 14nm oder gar 7NP wie bei N21 und dann eben den Compute Die in einem neuen EUV verfahren.

Das einzige was dann stutzig macht ist das Gerücht dass Navi31 ebenfalls nur 80CUs bekommt. Das macht als Nachfolger von N21 irgendwie wenig Sinn wenn man nur genau soviele Rechneneinheiten hat. Für einen midrange / mobile Chip wäre das logisch, halbierte Diefläche, gff. sogar größerer cache und noch weniger off chip memory (128bit=), trotzdem 80CU.

Aber da es ein Highend Chip ist muss da noch irgendwas neben den 80CUs versteckt sein von dem wir nichts wissen. Dedizierte RT Einheiten? Noch höher taktendes Design? Compute Die in 5nm und dadurch mehr Takt?

[ChaosTM]

CO-Prozessor :D

[Brillus]

Der Cache ändert erstmal überhaupt nichts an der Chip to Chip Komunikation, eher im Gegenteil macht neue Probleme. Mehrere Compute Dies nebeneinander hätten genau das Zen1 Problem, dass Teile des VRAM nur über Infinity Fabric ansprechbar wären. Außerdem willst du nicht dass die Caches synchronisiert werden weil das zuviel Bandbreite kostet, mit dem Ergebnis dass die Daten Dupliziert abgelegt werden und 2x 128mb sind demnach ganz nach Zen2 manier eben nicht 256mb mit doppelter bandbreite sondern bleiben eben nur 2x 128mb für jeweils die Hälfte der CUs des Gesamtpackages.

Gerade nachdem wir jetzt mit Zen3 gesehen haben wohin die Reise bei AMD geht macht das keinen Sinn dass man nochmal sowas pullt :rolleyes:




Exakt, das macht am meisten Sinn.
2D verfahren wie Info LSI bieten für GPUs einfach zu wenig Bandbreite, weniger contact points und größere Leistungslänge. Daher macht es Sinn erst bei 3d stacking eine GPU damit zu bauen. Aktuelle Verfahren mit Speicher direkt auf dem Die sind wiederum thermisch nicht für highend GPUs geeignet. Den Cache mit SI nach unten macht also am meisten Sinn, dann kann der Compute Die gut gekühlt werden. Gleichzeitig spart man eine Menge Diefläche weil man i/o features die schlecht skalieren auf den Base Die packt. Für den basedie könnte TSMCs 12nm genutzt werden oder GFs 14nm oder gar 7NP wie bei N21 und dann eben den Compute Die in einem neuen EUV verfahren.

Das einzige was dann stutzig macht ist das Gerücht dass Navi31 ebenfalls nur 80CUs bekommt. Das macht als Nachfolger von N21 irgendwie wenig Sinn wenn man nur genau soviele Rechneneinheiten hat. Für einen midrange / mobile Chip wäre das logisch, halbierte Diefläche, gff. sogar größerer cache und noch weniger off chip memory (128bit=), trotzdem 80CU.

Aber da es ein Highend Chip ist muss da noch irgendwas neben den 80CUs versteckt sein von dem wir nichts wissen. Dedizierte RT Einheiten? Noch höher taktendes Design? Compute Die in 5nm und dadurch mehr Takt?

Wo hätte man bei Chiplets das Zen1 Problem? Das hätte man bei MCM. Auch der Grundvwarum das bei Zen2 Chiplets sind.

Und sonst lies mal nochmal nicht der Cache hilft sondern das mit dem Cache eingezogene höhere Datenlokalität = weniger Daten kopieren zwischen Einheiten.

[Elite_Warrior]

AMD Radeon Codename Schema war ja immer, dass die chronologisch nach Start der Entwicklung zugewiesen werden. N31 ist nur der Erste. (Warum eigentlich nicht 30?). Ein größerer könnte noch folgen.

[Brillus]

AMD Radeon Codename Schema war ja immer, dass die chronologisch nach Start der Entwicklung zugewiesen werden. N31 ist nur der Erste. (Warum eigentlich nicht 30?). Ein größerer könnte noch folgen.
Gibt ja immer mal Lücken. Potentiel wurde einfach ein früher ganz früh Abgesägt weil es nicht gepasst hat.

[Nightspider]

2D verfahren wie Info LSI bieten für GPUs einfach zu wenig Bandbreite, weniger contact points und größere Leistungslänge. Daher macht es Sinn erst bei 3d stacking eine GPU damit zu bauen. Aktuelle Verfahren mit Speicher direkt auf dem Die sind wiederum thermisch nicht für highend GPUs geeignet. Den Cache mit SI nach unten macht also am meisten Sinn, dann kann der Compute Die gut gekühlt werden. Gleichzeitig spart man eine Menge Diefläche weil man i/o features die schlecht skalieren auf den Base Die packt. Für den basedie könnte TSMCs 12nm genutzt werden oder GFs 14nm oder gar 7NP wie bei N21 und dann eben den Compute Die in einem neuen EUV verfahren.

Das einzige was dann stutzig macht ist das Gerücht dass Navi31 ebenfalls nur 80CUs bekommt. Das macht als Nachfolger von N21 irgendwie wenig Sinn wenn man nur genau soviele Rechneneinheiten hat. Für einen midrange / mobile Chip wäre das logisch, halbierte Diefläche, gff. sogar größerer cache und noch weniger off chip memory (128bit=), trotzdem 80CU.

Aber da es ein Highend Chip ist muss da noch irgendwas neben den 80CUs versteckt sein von dem wir nichts wissen. Dedizierte RT Einheiten? Noch höher taktendes Design? Compute Die in 5nm und dadurch mehr Takt?

Hmmm. Also ist kein Chiplet-Design wie bei Zen3 zu erwarten.

Stacking erwarte ich ehrlich gesagt aber auch nicht für RDNA3. Selbst wenn der Cache-IO-Chip unten liegen würde hätte man in etwa die doppelte Wärmdichte wenn das Package nur noch die halbe Fläche einnimmt. Die 250-300W musst du dann halt aus ~~200-250mm² rausbekommen.
Theoretisch ginge auch das, eventuell mit Flüssigmetall-WLP wie bei der PS5.

Dann halte ich Chiplets, verbunden mit Fan-out wafer-level packaging aber für am ehesten wahrscheinlich. Damit sollte man riesige Bandbreiten ermöglichen können.

80 CUs würden pro Chiplet in 5nm schon eher Sinn ergeben, weil der Chip dann relativ klein wäre und man sehr gute Yields hätte.

Eine GPU mit 2*80CU Chiplets halte ich zumindest nicht für unmöglich in 5nm. Vor allem wenn der ganze IO-Kram ausgelagert wird.

[basix]

2D verfahren wie Info LSI bieten für GPUs einfach zu wenig Bandbreite, weniger contact points und größere Leistungslänge. Daher macht es Sinn erst bei 3d stacking eine GPU damit zu bauen. Aktuelle Verfahren mit Speicher direkt auf dem Die sind wiederum thermisch nicht für highend GPUs geeignet. Den Cache mit SI nach unten macht also am meisten Sinn, dann kann der Compute Die gut gekühlt werden. Gleichzeitig spart man eine Menge Diefläche weil man i/o features die schlecht skalieren auf den Base Die packt. Für den basedie könnte TSMCs 12nm genutzt werden oder GFs 14nm oder gar 7NP wie bei N21 und dann eben den Compute Die in einem neuen EUV verfahren.

Das einzige was dann stutzig macht ist das Gerücht dass Navi31 ebenfalls nur 80CUs bekommt. Das macht als Nachfolger von N21 irgendwie wenig Sinn wenn man nur genau soviele Rechneneinheiten hat. Für einen midrange / mobile Chip wäre das logisch, halbierte Diefläche, gff. sogar größerer cache und noch weniger off chip memory (128bit=), trotzdem 80CU.

Aber da es ein Highend Chip ist muss da noch irgendwas neben den 80CUs versteckt sein von dem wir nichts wissen. Dedizierte RT Einheiten? Noch höher taktendes Design? Compute Die in 5nm und dadurch mehr Takt?

Hier eine mögliche Lösung für dein Problem ;) https://www.forum-3dcenter.org/vbulletin/showpost.php?p=12478630&postcount=16835

Und wieso sind 80 CU ein Problem? Entweder sind es 2x 80CU mit 2x GCD oder AMD geht den Ampére Weg: 2x FP32 Leistung pro CU. Letzteres halte ich für wahrscheinlicher.

[Cyberfries]

Bei N21 @505mm²: GCD ca. 280mm², MCD ca. 220mm².
GCD auf 5nm geshrinkt für ähnliche Chipgrößen, da darf nicht wesentlich mehr als 200w bei rauskommen.
Von 250w (6800) ausgehend:
15% weniger durch 5nm, kommt gerade so hin mit 215w, sollte noch gehen.

Dann bleibt noch Platz obenrum für einen N32 mit 300w und 350mm². 120CUs an 5SE?
50% mehr Einheiten entspricht auch dem üblichen 50% Leistungszuwachs je Generation.

Oder AMD findet einfach so nochmals 50%...

[basix]

Ich würde behaupten, das du mehr auf den GCD auslagern musst. Der Infinity Cache hat den grossen Nutzen, die Offchip Bandbreite zu reduzieren. Das würde man hier wollen.

Also eher GCD = 400mm2 und MCD = 120mm2. Und damit das richtig Sinn macht, den GCD noch zweiteilen. 400mm2 sind wieder relativ gross. Mit 2x 200mm2 hat man kleinere Chips, höheren Yield und gleich noch kleinere SKUs mitabgedeckt (was heute N22 ist). Man kann GCD sehr gut binnen als auch salvagen (siehe Zen 2/3) als auch den MCD salvagen (192b vs. 256b, 1x GCD angeschlossen anstatt 2x GCD)

[Cyberfries]

Ja? Offchip ist das Stichwort, wieso sollte ich den I$ ins GCD packen?
Der I$ hängt nach derzeitigem Wissen am SI, Interfaces skaliert schlecht -> MCD.
GCD/MCD = 3d gestapelt, da ist Traffic zwischen GCD und MCD kein so großes Thema.

Oder bist du wieder bei Chiplets im Zen2-Stil?
Das wäre das falsche Thema, dass AMD stapeln will ist bekannt.

[basix]

Klar beim stapeln würde ich das auch so machen wie du sagst. Nur sehe ich das noch nicht bei RDNAx, vielleicht eher bei CDNAx. Und ja ich wäre beim Zen2/3 Ansatz. Der macht bei Consumer Produkten viel mehr Sinn, da man damit den Produktstack relativ einfach skalieren kann und dabei Kosten spart. Der Stack geht von 200-1000$ und 20-80 CUs. Bei HPC und somit CDNA gibt es diesen Stack nicht oder nur sehr begrenzt. Es gibt z.B. von Volta im Datacenter nur einen Ausbau: 5120 Shader / 4096b. Hier macht Stacking als Startpunkt viel mehr Sinn, neben den hohen Kisten. Ob es dan nur 2 chips gestacked sind oder mehrere Stacks ist dan eine Evolutionsfrage.

[JVC]

RDNA ist einfach "geil", so wie ZEN :)
Mal schauen wie lange das so läuft für AMD.
Ich gönne ihnen den Moment auf jeden Fall.

M.f.G. JVC

[Cyberfries]

Kepler_L2 hat zwei kleine Häppchen getwittert (hier (https://twitter.com/Kepler_L2/status/1321614628309372930) und hier (https://twitter.com/Kepler_L2/status/1322433607001088001)), wovon vor allem die Aussage,
dass bereits N31 Engineering Sample im Umlauf sind bemerkenswert ist.

Was wir bisher zu RDNA3/N31 wissen (glauben) ist:
Konfiguration vergleichbar, wenn nicht identisch (https://www.reddit.com/r/Amd/comments/j06xcd/number_of_cus_of_navi_23_navi_31_van_gogh_cezanne/) zu N21
Läuft bei AMD als neue, elfte GPU-Generation (https://www.forum-3dcenter.org/vbulletin/showpost.php?p=12457509&postcount=58)
Erscheinungsdatum noch vor Ende 2022 (https://pics.computerbase.de/9/1/7/9/2/35-1080.be55a337.jpg),
Fertigung in einem "Advanced Node", vermutlich TSMC 5nm (https://www.forum-3dcenter.org/vbulletin/showpost.php?p=12480834&postcount=1577)
Falls Kepler_L2 und die CTEE vertrauenswürdig sind, ist N31 in Q4 2021 möglich,
mit Fertigung in TSMC 5nm, was zu 15% Mehrleistung oder 30% Minderverbrauch (https://www.tsmc.com/english/dedicatedFoundry/technology/5nm.htm) führt.
Außerdem zeichnet sich mehr und mehr ein Multi-Chip-Design ab.

Das wäre ein klarer Zeitvorsprung gegenüber Hopper, geht es in dem Tempo weiter,
könnte Hopper sich bereits mit N4x konfrontiert sehen.
Etwas pessimistischer:
Da AMDs DLSS-Alternative erst für 2021 angekündigt ist, könnte diese auch erst mit N31 bereit sein.

[fondness]

AMD scheint die Schlagzahl wie in der CPU-Abteilung enorm anzuheben. Unfassbar, wie man es schafft wie der Phoenix aus der Asche aus eine fast Pleite gegen zwei eigentlich übermächtige Gegner derart zu reüssieren. Die RnD Budgets von AMD lagen zu Zeiten der Zen&RDNA-Entwicklung bei geradezu lächerlich 200mio pro Quartal. Selbst heute noch geben NV und Intel ein Vielfaches von AMD aus. Da sieht man mal wieder, wie wichtig ein gutes Management ist.

[stinki]

Ich denke auch, wir werden Navi31 in Q4/2021 sehen.
Das wird AMDs Pipe-Cleaner für N5, wie es VegaII für N7 war.
Bin sehr gespannt wie sie den neuen Prozess für das GCD nutzen werden, ob für mehr Takt, Architektur-Änderungen oder sonstige Verbesserungen.

[HOT]

Kepler_L2 hat zwei kleine Häppchen getwittert (hier (https://twitter.com/Kepler_L2/status/1321614628309372930) und hier (https://twitter.com/Kepler_L2/status/1322433607001088001)), wovon vor allem die Aussage,
dass bereits N31 Engineering Sample im Umlauf sind bemerkenswert ist.

Was wir bisher zu RDNA3/N31 wissen (glauben) ist:
Konfiguration vergleichbar, wenn nicht identisch (https://www.reddit.com/r/Amd/comments/j06xcd/number_of_cus_of_navi_23_navi_31_van_gogh_cezanne/) zu N21
Läuft bei AMD als neue, elfte GPU-Generation (https://www.forum-3dcenter.org/vbulletin/showpost.php?p=12457509&postcount=58)
Erscheinungsdatum noch vor Ende 2022 (https://pics.computerbase.de/9/1/7/9/2/35-1080.be55a337.jpg),
Fertigung in einem "Advanced Node", vermutlich TSMC 5nm (https://www.forum-3dcenter.org/vbulletin/showpost.php?p=12480834&postcount=1577)
Falls Kepler_L2 und die CTEE vertrauenswürdig sind, ist N31 in Q4 2021 möglich,
mit Fertigung in TSMC 5nm, was zu 15% Mehrleistung oder 30% Minderverbrauch (https://www.tsmc.com/english/dedicatedFoundry/technology/5nm.htm) führt.
Außerdem zeichnet sich mehr und mehr ein Multi-Chip-Design ab.

Das wäre ein klarer Zeitvorsprung gegenüber Hopper, geht es in dem Tempo weiter,
könnte Hopper sich bereits mit N4x konfrontiert sehen.
Etwas pessimistischer:
Da AMDs DLSS-Alternative erst für 2021 angekündigt ist, könnte diese auch erst mit N31 bereit sein.
Hört sich realtistisch an. AMDs DLSS wird aber nicht von Generationen abhängig sein, das ist ne reine Software-Sache. MMn wird das ab N10 funktionieren. Man wird den erst mal über der aktuellen Generation platzieren und dann über 22 hinweg weitere Produkte releasen mMn. Man sieht ja auch bei N2x, dass der Launchzeitraum über ein 3/4 Jahr zu laufen scheint bis N24.

[Berniyh]

Ich denke auch, wir werden Navi31 in Q4/2021 sehen.
Das wird AMDs Pipe-Cleaner für N5, wie es VegaII für N7 war.
Bin sehr gespannt wie sie den neuen Prozess für das GCD nutzen werden, ob für mehr Takt, Architektur-Änderungen oder sonstige Verbesserungen.
Vega 20 war aber Compute und nicht Desktop. ;)
(Ja, ich weiß, dass die VII auch daraus entstanden ist, aber die war zu 99% vorher nicht geplant, sondern eher aus der Not heraus geboren, da sich Navi 10 verzögerte.)

Ich würde auch eher CDNA2 als Pipe Cleaner für N5(+/e) erwarten, da diese Chips dann eh nächstes Jahr vom Band laufen müssen für die diversen Supercomputer Projekte die AMD in Planung hat.

[stinki]

Vega 20 war aber Compute und nicht Desktop. ;)
(Ja, ich weiß, dass die VII auch daraus entstanden ist, aber die war zu 99% vorher nicht geplant, sondern eher aus der Not heraus geboren, da sich Navi 10 verzögerte.)

Ich würde auch eher CDNA2 als Pipe Cleaner für N5(+/e) erwarten, da diese Chips dann eh nächstes Jahr vom Band laufen müssen für die diversen Supercomputer Projekte die AMD in Planung hat.

Ich könnte mir vorstellen, das der CDNA2 Chip schon recht groß werden dürfte in N5x. Da könnte sich ein geshrinkter 80CU RDNA3 Chip (GCD) von der Größe her vielleicht eher anbieten. Aber kurz danach wird dann bestimmt schon der CDNA2 Chip und dann Zen4 kommen.
Und CDNA2 könnte ja auch ein Chiplet Design sein.

[Berniyh]

Ich könnte mir vorstellen, das der CDNA2 Chip schon recht groß werden dürfte in N5x. Da könnte sich ein geshrinkter 80CU RDNA3 Chip (GCD) von der Größe her vielleicht eher anbieten. Aber kurz danach wird dann bestimmt schon der CDNA2 Chip und dann Zen4 kommen.
Und CDNA2 könnte ja auch ein Chiplet Design sein.
Eben, CDNA2 könnte Chiplet sein und evtl. auch schon das erste "echte" Chiplet Design. Bei RDNA3 gibt es ja Vermutungen, dass auch schon erste Teile separiert werden, aber es ist unklar, ob es z.B. mehrere Compute Chiplets + IO gibt oder quasi sowas wie die 8C Zen 2 (also Auftrennung in nur 2 Chiplets).
Bei CDNA2 könnte das evtl. einfacher sein, da hier die Datenlokalität typischerweise höher ist.
Und damit wäre dann auch das Argument der Größe hinfällig.

bzgl. Navi 31 bin ich immer noch etwas überrascht, dass wir dazu überhaupt Daten haben. Insbesondere, dass Daten zu dem Chip im Treiber vorliegen und zu Navi 24 aber nicht.
Und natürlich auch, dass die Daten dann weitgehend identisch zu Navi 21 sind.
Das muss irgendeinen spezifischen Grund haben, in dem Sinne, dass Prototypen davon für irgendeinen Kunden schon evaluiert werden (in welcher Form auch immer), denn warum sollte man das sonst im Treiber bereits integrieren, wenn der Chip noch mind. ein Jahr weit weg ist?
(Andererseits lagen auch die Daten zu Navi 21 wohl schon 2019 vor, es hat nur keiner nachgesehen …)

[TheAntitheist]

Hört sich realtistisch an. AMDs DLSS wird aber nicht von Generationen abhängig sein, das ist ne reine Software-Sache. MMn wird das ab N10 funktionieren. Man wird den erst mal über der aktuellen Generation platzieren und dann über 22 hinweg weitere Produkte releasen mMn. Man sieht ja auch bei N2x, dass der Launchzeitraum über ein 3/4 Jahr zu laufen scheint bis N24.
bei Nvidia ist DLSS auch eine Software "Lösung", die aber duch die Tensor Cores beschleunigt wird. Könnte Nvidia auch auf den Shadern laufen lassen, aber die Tensor Kerne können es eben 10x so schnell? Dies verbessert auf jeden fall die Frametimes.

[basix]

bzgl. Navi 31 bin ich immer noch etwas überrascht, dass wir dazu überhaupt Daten haben. Insbesondere, dass Daten zu dem Chip im Treiber vorliegen und zu Navi 24 aber nicht.
Und natürlich auch, dass die Daten dann weitgehend identisch zu Navi 21 sind.
Das muss irgendeinen spezifischen Grund haben, in dem Sinne, dass Prototypen davon für irgendeinen Kunden schon evaluiert werden (in welcher Form auch immer), denn warum sollte man das sonst im Treiber bereits integrieren, wenn der Chip noch mind. ein Jahr weit weg ist?
(Andererseits lagen auch die Daten zu Navi 21 wohl schon 2019 vor, es hat nur keiner nachgesehen …)

Der erste Chip braucht immer mit Abstand am meisten Vorlaufzeit, auch beim Treiber und der restlichen Software. Und dass die Konfiguration gleich zu N21 ist, ist auch sinnvoll (z.B. wenn N31 einfach ein aufgetrennter N21 ist). Ich denke, bei N21 lernen/lernten sie viel über das Verhalten bezüglich Infinity Cache, was für Optimierungen bei N31 Gold wert ist.

Was ich bei N31 aber glaube: 2x GCD = 80 CUs (40 CUs pro GCD, kein N32 da durch N31 mit nur 1x GCD abgedeckt), also eigentlich wie bei Zen 2/3. Sowie verdoppelte FP32 Leistung pro CU wie bei Ampere. Durch RT, Denoiser und temporales Upsampling usw. wird der Compute-Anteil / Arithmetik-Last steigen verglichen mit Rasterizer Last. Da wird zusätzliche Rechenleistung viel bringen. An Tensor Cores glaube ich irgendwie noch nicht, höchstens Tensor Cores Light (z.B. 4x FP16 Beschleunigung verglichen mit FP32).

[Berniyh]

Der erste Chip braucht immer mit Abstand am meisten Vorlaufzeit, auch beim Treiber und der restlichen Software.
Natürlich, aber doch nicht in veröffentlichten Treibern, dafür hat man interne Branches. ;)

[basix]

Da hat der Praktikant einfach nicht aufgepasst :D

[[MK2]Mythos]

AMD visiert für RDNA3 wieder über 50% bessere P/W ggü RDNA2 an

https://www.notebookcheck.com/RDNA-3-AMD-verspricht-eine-50-Prozent-bessere-Performance-pro-Watt-fuer-Radeon-RX-7000.503794.0.html

[Der_Korken]

Mit 5nm im Rücken wird das diesmal aber wesentlich einfacher sein als bei RDNA2.

[dargo]

Mythos;12496592']AMD visiert für RDNA3 wieder über 50% bessere P/W ggü RDNA2 an

https://www.notebookcheck.com/RDNA-3-AMD-verspricht-eine-50-Prozent-bessere-Performance-pro-Watt-fuer-Radeon-RX-7000.503794.0.html
Schade... dann also erst eine Verdoppelung der RDNA2 Leistung mit RDNA4? 150% der Performance von RX 6900XT in 300W klingt nicht so besonders spannend für Ende 2021. Aber gut... warum soll es AMD besser gehen als Nvidia? Beide kochen nur mit Wasser. :tongue:

[basix]

Mythos;12496592']AMD visiert für RDNA3 wieder über 50% bessere P/W ggü RDNA2 an

https://www.notebookcheck.com/RDNA-3-AMD-verspricht-eine-50-Prozent-bessere-Performance-pro-Watt-fuer-Radeon-RX-7000.503794.0.html

Lest das originale Interview, das sollte man generell bei solchen News machen. Da werden oft Aussagen aus dem Kontext gerissen oder fehlinterpretiert. Nirgends wird etwas von +50% Effizienzsteigerung gesagt. RDNA3 soll beim Design ebenso wie RDNA2 stark auf gesteigerte Energieeffizienz fokussieren. Nur das und genau das hat der Rick Bergman gesagt. Wie viel Verbesserung verglichen zu RDNA2 steht dort nirgends.

[Leonidas]

Underfox @ Twitter:
This new method for scheduling instructions of a shader program for a GPU with a fixed number of registers has great potential to significantly improve the performance of future AMD GPUs based on RDNA3.
https://twitter.com/Underfox3/status/1328871431623602176

[=Floi=]

@ dargo
man sollte erstmal RDNA2 genauer ansehen und dann abwarten, wenn rdna3 wirklich da ist.
Man sieht ja an NV, dass eine alleinige effizienzsteigerung durch krempel (RTX) oder der schieren masse an einheiten auch verpuffen kann.

[dargo]

@ dargo
man sollte erstmal RDNA2 genauer ansehen und dann abwarten, wenn rdna3 wirklich da ist.

Das sowieso. Ich sags mal so... ich wäre verdammt überrascht wenn AMD Ende 2021 eine 300W Grafikkarte mit Faktor 1,8-2.0 von RX 6900XT bringen würde. Das wäre sensationell.

[mboeller]

Das sowieso. Ich sags mal so... ich wäre verdammt überrascht wenn AMD Ende 2021 2020 eine 300W Grafikkarte mit Faktor 1,8-2.0 von RX 6900XT 5700XT bringen würde. Das wäre sensationell.

habs mal korrigiert :biggrin:

Bis auf die 300/225W sind wir doch alle extrem überrascht wie gut AMD gegenüber Nvidia aufgeholt hat. Und das im gleichen 7nm Prozess wie die 5700XT

[dargo]

Mit N21 vs. N10 ist das doch überhaupt nicht vergleichbar. AMD hatte bei RDNA1 gar nicht vor gehabt im High-End bzw. Enthusiast-Bereich mitzuspielen. Erst mit dem Nachfolger von N21 wird man sehen wie gut AMD weiter steht.

[HOT]

Nach den Informationen, dass SRAM nur 20% schrumpft, aber die Kosten um >20% steigen werden bei N5, allerdings RDNA3 auch weiterhin monolithisch sein soll (bis auf I/O) - und der Tatsache geschuldet, dass es offenbar den N31 sogar schon gibt, würde ich mal den Launch auf Frühjahr bis Sommer 2022 in N6, nicht N5, einschätzen. Das passt einfach hervorragend zeitlich zum N6-Launchfenster bei AMD (von Mitte 2021 bis Mitte 2022) und N6 ist der logische Prozess für RDNA3 in seiner kolportierten Konfiguration mMn. Für N5 wird man generell Chiplets benötigen, um die Kosten im Griff zu halten, das wäre dann also nur was für RDNA4.

[woodsdog]

Nach den Informationen, dass SRAM nur 20% schrumpft, aber die Kosten um >20% steigen werden bei N5, allerdings RDNA3 auch weiterhin monolithisch sein soll (bis auf I/O) - und der Tatsache geschuldet, dass es offenbar den N31 sogar schon gibt, würde ich mal den Launch auf Frühjahr bis Sommer 2022 in N6, nicht N5, einschätzen. Das passt einfach hervorragend zeitlich zum N6-Launchfenster bei AMD (von Mitte 2021 bis Mitte 2022) und N6 ist der logische Prozess für RDNA3 in seiner kolportierten Konfiguration mMn. Für N5 wird man generell Chiplets benötigen, um die Kosten im Griff zu halten, das wäre dann also nur was für RDNA4.

Ein Chip kann entweder monolithisch sein... ODER Teile z.B. in ein I/O-Die auslagern. Beides zusammen geht aber nicht. Just sayin. :wink:

[Nightspider]

Schade... dann also erst eine Verdoppelung der RDNA2 Leistung mit RDNA4? 150% der Performance von RX 6900XT in 300W klingt nicht so besonders spannend für Ende 2021. Aber gut... warum soll es AMD besser gehen als Nvidia? Beide kochen nur mit Wasser. :tongue:

Wenn man zwei Chiplets hätte, die näher am Sweetspot laufen und nicht wie RDNA2 extrem weit oben takten, könnte man da auch (deutlich?) mehr als +50% an Leistung herausholen, bei 2*80 CUs.

[Neurosphere]

Ich finde +50% innerhalb eines Jahres wären schon verdammt gut. NV hat jetzt ~+40% geschafft in zwei Jahren.

[JVC]

"Chiplet Aufbau" ... oder klingelt da was falsch in meinen Ohren ?
Aber keine Ahnung ob sie 2 Dies überhaupt schon koppeln können...
(die Dies der CPUs sind schon verdammt eben, könnte man fast "Blech" drauf legen)

M.f.G. JVC

[robbitop]

Ich bin bei Chiplets auch skeptisch. Braucht zusätzliches I/O pro Chip (chiplets wachsen) und jedes Bit, was den Chip verlässt, kostet auch mehr Energie. Insbesondere je länger die Strecke.
Gerade bei GPUs müsste, damit es transparent zu einer 3D Anwendung läuft eine ganze Menge an Daten rein und raus aus dem Chip. Heute ist ein großteil des Energiebedarfs getrieben durch Datentransfers und genau deshalb fokussieren sich beide IHVs auf Datenlokalisierung.

Das mag für Compute anders aussehen (wesentlich weniger Interdependenz der Workloads) und für CPUs auch. Aber 3D Workloads sind in der Hinsicht leider wirklich... schwierig.

Stacking würde den Effekt sicherlich etwas lindern - aber dann hat man sicherlich schnell thermische Schwierigkeiten sobald Compute auf mehrere Layer verteilt würde.

[Platos]

Ich glaube jetzt auch nicht, dass man das zeitnah sehen wird. Ist ja auch überhaupt nicht nötig momentan.

Das wäre extrem teuer und würde auch extra Chipfläche kosten. Die Chiplets sind natürlich kleiner, aber der Stromverbrauch dann auch höher. Wie man den Datenverkehr löst, ist ungewiss. Das ist sicherlich nicht einfach zu entwickeln. Solange die Fertigung noch so gut läuft bei TSMC, sehe ich keinen Grund auf Chiplets umzusteigen. 5nm läuft gut und 3nm kommt auch bald. Da sehe ich keinen Grund für AMD, dass sie gezwungen sind, auf Chiplets zu wechseln.

Bei den CPUs tun sie das auch nur, weil sie so eine enorme Kernanzahl wirtschaftlich erbringen können. Bei GPUs hat es gar keine Notwendigkeit. Das Kerne-Rennen gibt es bei GPUs gar nicht. Die (2-) jährlichen 30-50% Fortschritte funktionieren soweit ganz gut mit normalen Fertigungsverbesserungen und Architekturweiterentwicklung. Es gibt keinen Grund für Chiplets.

Chiplets bei CPUs gibt es wie gesagt nur, weil AMD ansonsten aufgrund der benötigten Fläche niemals wirtschaftlich 32/64 Kerne hätte bieten können. Bei GPUs gibt es dieses Problem wie gesagt nicht. Auch hat (wie alle wissen) das Chiplet-Design auch nachteile bei der Latenz. Ich wüsste nicht, warum AMD das auch noch "künstlich" bei GPUs einbauen sollte, wenn es nicht mal nötig ist.

Ich denke nicht, dass wir bis 3nm Chiplets sehen werden (zumindest nicht so, wie man sich das vorstellt mit quasi 2 GPU-DIEs und einem I/O-Chip.). Und eine Staplung halte ich für unmachbar für nahe Zukunft (wirtschaftlich und in Massenproduktion. Das hatten wir ja schon im Zen4 Thread es ist gerade mal im Forschungsstadium).

Solange es nicht nötig ist, wird man das m.M.n nicht sehen (im Gaming Bereich. X-tausend Dollar teure GPUs sind wieder was anderes und als erstes wird das sowieso dort angewandt werden - ihr könnt also gleich noch 1-2 Generationen oben drauf legen, in der ein Chiplet-Design im Gaming nicht eingesetzt wird).

Aber: Wie wärs mit einer Abstimmung so rein aus Spass? Wer macht sich den Spass? "In wie vielen Generationen in der Zukunft wird AMD bzw. nvidia (für Gaming-Grafikkarten) ein Chiplet-Design antreten?". Auswahlmöglichkeiten sind dann 1-5 Generationen bei jeweils AMD und nvidia, falls so viele möglich sind. Evtl. könnte man es auch an Fertigungsprozesse knüpfen wie z.B "frühestens nach 3nm" oder "erst ab 3nm" usw.

[davidzo]

Ich glaube jetzt auch nicht, dass man das zeitnah sehen wird. Ist ja auch überhaupt nicht nötig momentan.

Das wäre extrem teuer und würde auch extra Chipfläche kosten. Die Chiplets sind natürlich kleiner, aber der Stromverbrauch dann auch höher. Wie man den Datenverkehr löst, ist ungewiss. Das ist sicherlich nicht einfach zu entwickeln. Solange die Fertigung noch so gut läuft bei TSMC, sehe ich keinen Grund auf Chiplets umzusteigen. 5nm läuft gut und 3nm kommt auch bald. Da sehe ich keinen Grund für AMD, dass sie gezwungen sind, auf Chiplets zu wechseln.

Bei den CPUs tun sie das auch nur, weil sie so eine enorme Kernanzahl wirtschaftlich erbringen können. Bei GPUs hat es gar keine Notwendigkeit. Das Kerne-Rennen gibt es bei GPUs gar nicht. Die (2-) jährlichen 30-50% Fortschritte funktionieren soweit ganz gut mit normalen Fertigungsverbesserungen und Architekturweiterentwicklung. Es gibt keinen Grund für Chiplets.

Chiplets bei CPUs gibt es wie gesagt nur, weil AMD ansonsten aufgrund der benötigten Fläche niemals wirtschaftlich 32/64 Kerne hätte bieten können. Bei GPUs gibt es dieses Problem wie gesagt nicht. Auch hat (wie alle wissen) das Chiplet-Design auch nachteile bei der Latenz. Ich wüsste nicht, warum AMD das auch noch "künstlich" bei GPUs einbauen sollte, wenn es nicht mal nötig ist.

Ich denke nicht, dass wir bis 3nm Chiplets sehen werden (zumindest nicht so, wie man sich das vorstellt mit quasi 2 GPU-DIEs und einem I/O-Chip.). Und eine Staplung halte ich für unmachbar für nahe Zukunft (wirtschaftlich und in Massenproduktion. Das hatten wir ja schon im Zen4 Thread es ist gerade mal im Forschungsstadium).

Solange es nicht nötig ist, wird man das m.M.n nicht sehen (im Gaming Bereich. X-tausend Dollar teure GPUs sind wieder was anderes und als erstes wird das sowieso dort angewandt werden - ihr könnt also gleich noch 1-2 Generationen oben drauf legen, in der ein Chiplet-Design im Gaming nicht eingesetzt wird).

Aber: Wie wärs mit einer Abstimmung so rein aus Spass? Wer macht sich den Spass? "In wie vielen Generationen in der Zukunft wird AMD bzw. nvidia (für Gaming-Grafikkarten) ein Chiplet-Design antreten?". Auswahlmöglichkeiten sind dann 1-5 Generationen bei jeweils AMD und nvidia, falls so viele möglich sind. Evtl. könnte man es auch an Fertigungsprozesse knüpfen wie z.B "frühestens nach 3nm" oder "erst ab 3nm" usw.

Ja, compute auf mehrere Dies zu verteilen nur um den yield zu erhöhen macht keinen Sinn, das hatten wir schon vor ein paar Seiten bemerkt.

Das spricht allerdings nicht dagegen I/O, UVD, Cache oder anderes Zeugs auszulagern. Dann kann man günstigere Prozesse wählen für Zeug das schlecht skaliert und optimierte Prozesse für den jeweiligen Teil. Zusamengeflickt wird das dann mit Stacking, Interposer, Info oder EMIB. Thermisch muss das gar nicht problematisch werden solange das Compute Die eben oben ist.

Intel hat genau diese Strategie ja schon für XE ja auch schon angekündigt. Das ist zwar auch eine Datacenter GPU, bzw. MultiGPU setup mit ohnehin viel off-chip verbindungen, routing etc. Aber ich wüsste nicht wieso man bei einer Gaming GPU, die viel weniger off-Chip bandbreite und connectivity braucht nicht auch einzelne Teile abtrennen könnte.

Bandbreite und Energieeffizienz scheint nicht das Problem zu sein wenn man auf aktive Interposer oder EMIB setzt. Schließlich will Intel bei Aurora / Ponte Vecchio ganze 16 GPU Tiles mit einem gigantischen Rambo Cache verbinden, der wiederrum mit Xe Link chips verbunden ist die an die CPUs per CXL angebunden sind.
Wenn so ein externer Cache DIE für ganze 16 GPUs möglich ist, dann wäre es doch ein leichtes den cache für eine einzelne GPU anzubinden?

Ein sparsamer Base-Die in 14/28nm mit GDDR SI, 512mb Cache, PCIe, UVD etc. alles mit TSVs über den ganzen DIE verteilt und 300-500mm2. Obendrauf ein 250mm kleiner Compute Die in 5nm mit 80CUs bei 3-3.5Ghz.

[basix]

Ja, compute auf mehrere Dies zu verteilen nur um den yield zu erhöhen macht keinen Sinn, das hatten wir schon vor ein paar Seiten bemerkt.

Das spricht allerdings nicht dagegen I/O, UVD, Cache oder anderes Zeugs auszulagern. Dann kann man günstigere Prozesse wählen für Zeug das schlecht skaliert und optimierte Prozesse für den jeweiligen Teil. Zusamengeflickt wird das dann mit Stacking, Interposer, Info oder EMIB. Thermisch muss das gar nicht problematisch werden solange das Compute Die eben oben ist.

Ich sehe folgende Umsetzungsmöglichkeiten für Chiplets (I/O, Speicherinterface, VCN usw. ausgelagert):

3D Stacking (Chip on Chip)
3D Stacking + Interposer (1x MCD, x-mal 3D-Stacked GCD)
Chiplets à la Zen (1x MCD, 2x GCD) auf Substrat

Ersteres ist die Deluxe Performance Lösung, lässt sich aber nicht so einfach skalieren. Letzteres hat ggü. 3D-Stacking Nachteile bei Stromverbrauch und man benötigt zusätzliches I/O, hat aber Vorteile bezüglich Kosten und Skalierbarkeit. Die 3D-Stacking Variante mit Interposer kombiniert das beste aus beiden Welten, ist aber technologisch gesehen nochmals deutlich aufwändiger.

Man kann es auch so sehen: Chiplets machen nur Sinn, wenn man Performance, Stromverbrauch und/oder Kosten verbessern kann. Bei 3D-Stacking sehe ich vor allem die Kosten als grössten Nachteil. Performance und Effizienz wird sicher steigen, aber nicht um Welten (erwarte ich zumindest nicht). Interposerlösungen sind einfach aufwändiger und teurer.
Bei der Zen-Variante sehe ich eine Nullnummer bei Stromverbrauch, positive Effekte bei Performance und massive Vorteile bezüglich Kosten. Und gerade letzter Punkt setzt sich aus mehreren Punkten zusammen:

Design: 1x MCD und 1x GCD; GCD mit z.B. 200mm2; bei monolithisch und 3D-Stacking muss man mehr und grössere Chips designen, was teurer ist. Vorteil Zen-Variante
Fertigung: Umso geringer die Chipgrösse, desto geringer die total anfallenden Kosten pro mm2. Umso kleiner die Chips, desto einfacher sind sie zu fertigen und desto früher kann man auf einen neuen Top Notch Node wechseln (Zeitvorteil). Ausserdem schlägt Economy of Scale bei höherer Stückzahl positiv zu. Vorteil Zen-Variante
Fertigungskapazität: Top Notch Prozesse bei TSMC sind zu 100% ausgebucht. MCD kann z.B. in 6nm gefertigt werden. Unentschieden
Logistik: Umso mehr identische Chips hergestellt werden, umso einfacher gestaltet sich die Logistik (Fracht, Lagerung, usw.). Je nach Nachfrage des Marktes kann man relativ schnell den Chipstrom zwischen 1x oder 2x GCD Varianten hin-und hersteuern, die 3 Monate Durchlaufzeit in der Factory entfallen bei solchen Steuermassnahmen. Vorteil Zen-Variante
SKU-Gestaltung: Mit Zen-a-like Chiplets kann man das Portfolio mit nur zwei relativ kleinen Chips sehr breit abdecken (z.B. 28-80 CUs). Man kann also sofort den Produktstack zwischen 250-1000$ anbieten. Das geht bei 3D-Stacking nur mit Interposer. Vorteil Zen-Variante.
Time to Market: Siehe Fertigung und SKU-Gestaltung. Man kann früher auf einen neuen Prozess wechseln und hat früher ein breites Portfolio am Markt. N22 ist später als N21. GA104 ist später als GA102 usw. das hätte man mit Chiplets nicht mehr.


Ich sehe ausserdem anhand N21 und N22 Indizien für eine Zen-a-like Umsetzung: 40 CUs vs. 80 CUs -> N21 hat doppelte CUs, Aufteilung in 40 CU Cluster auf dem Chip. 192bit vs. 256bit -> Beim gemeinsam genutzten MCD kann man Salvageing betreiben aber ist nahe genug beieinander. Das einzig unschöne ist der Split des Infinity Caches auf 2 GCDs. Den IF$ aufs MCD zu packen macht mMn aber keinen Sinn.

Eine Verbesserung der Zen-a-like Lösung wäre, wenn man den I/O-Part des GCDs und IF$ 3D-Stacked und nur noch die CUs und Shaderengine obendrauf packt. Dann werden die Chips noch kleiner und man kann einen günstigeren Prozess für den IF$ Die verwenden. Mit RDNA3 ist das wohl aber noch zu früh ;)

[aufkrawall]

Das spricht allerdings nicht dagegen I/O, UVD, Cache oder anderes Zeugs auszulagern.
Kann mir nicht vorstellen, dass das für Video-Wiedergabe oder sonstige Niedriglast-Szenarien nicht der GAU für die Effizienz wäre.

[basix]

Kann mir nicht vorstellen, dass das für Video-Wiedergabe oder sonstige Niedriglast-Szenarien nicht der GAU für die Effizienz wäre.

Vielleicht musst du es umgekehrt betrachten: Shader Engines und CUs werden ausgelagert. Für Videowiedergabe usw. ändert sich im Vergleich zu heute also gar nichts. Niedriglast auf den CUs kann ein Thema / Problem sein, das sieht man ja auch an Zen. Bei Videowiedergabe, Browsing usw. sehe ich aber weniger das Problem. Man sollte eher mal die VRAM-Takt Problematik in den Griff bekommen. Die gibt es schon seit RV770 immer mal wieder je nach GPU, auch bei N21.

Und noch zum IO Auslagern: Nvidia hat doch zum Teil einen NVIO-Chip gehabt, welcher doch Displayansteuerung usw. beinhaltet hat?

[Cyberfries]

Irgendeine Form von Multi-Die-Design wird wohl kommen müssen, allzuviel Fläche wird sich bei 5nm nicht einsparen lassen.
TSMC wirbt zwar mit Faktor 1,8x, bei einem unbekannten Prozess wird man aber nicht ans Limit gehen können.
Siehe N10 (41mio Tr/mm²) vs N21 (51). Die HPC-Variante für +25% frisst auch nochmals Packdichte.
Reiner N21-compute-shrink bei ca. 200-250mm²? Einige Architektur-Änderungen und man ist wieder bei ca. 280-300mm².
Dann noch den Inf$ aufblähen oder das SI - 500+mm² im brandneuen 5nm-Prozess? - uff

An mehrere GCDs nach Zen1-Vorbild glaube ich aber nicht.
Ja, die SEs sind symmetrisch um GCP/ACEs/L2$/usw. aufgebaut, doch das ist nichts neues, sondern üblich.
mMn kein Hinweis auf Zen1-Chiplets, Schließlich müssten nicht nur SEs aufgeteilt werden/doppelt vorhanden sein,
sondern eben auch GCP/ACEs/L2$/usw. Das erscheint mir nicht besonders sinnvoll.

Und damit bleibt eig nur ein Zen2-Chiplet-Design oder 3D-stapeln.
Das MCD mit 192mb-Inf$ (16x 12mb) könnte in 7nm bei etwa 280mm² landen,
das liegt ziemlich nahe meiner obigen Schätzung von 280-300mm² für ein 5nm-GCD.

[davidzo]

3D Stacking (Chip on Chip)

Ersteres ist die Deluxe Performance Lösung, lässt sich aber nicht so einfach skalieren.


3D Stacking ist ein etabliertes und sehr kosteneffizientes Massenverfahren bei der Flash Speicherherstellung. Praktisch jeder aktuelle Nand nutzt massiv 3D Stacking mit TSVs. Nach unten kommt ein Logikdie mit dem PHY und oben drauf werden die Nand Chips gestapelt. TSMC ist da gewissermaßen Late-comer drin, hat das aber genau für Massenproduktion in 2021 angekündigt. Das passt total zum Zeitplan für N3x.
Für zwei Logikdies ist das was den TSV pitch angeht nicht so regelmäßig, sollte aber mit dem richtigen tooling auch kein Problem sein.


https://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=72846&stc=1&d=1607684004

- AMD hat angekündigt dass man sowohl 2.5D Stacking (Cowos, Info) als auch echtes 3D Stacking (WoW) ab 2020-21 nutzen wird .
- Praktisch Intels gesamtes GPU Lineup für 2021 und 22 basiert auf 2.5D und 3D stacking.
- Apple ist bereits ein massiver User von TSMCs Info und kombiniert in Zukunft TSVs und TOVs in einem Package.
- Nvidia hat dazu zwar keine technischen public roadmaps, wird aber als bisher prominenter 2.5D User sicher auch mit dabei sein wenn TSMC etwas neues anzubieten hat.

Alle machen das jetzt. Es wäre also eher eine Überraschung wenn wir es nicht sehen.
Ich tippe auf WOW, denn das aligned sich zeitlich genau mit 5nm und lässt die größten Performancegewinne zu.


Bei 3D-Stacking sehe ich vor allem die Kosten als grössten Nachteil. Performance und Effizienz wird sicher steigen, aber nicht um Welten (erwarte ich zumindest nicht). Interposerlösungen sind einfach aufwändiger und teurer.


Du verwechselst da gerade eine Interposer Lösung (2.5D) mit einer echten 3D Lösung. Wie kommst du darauf das es viel teurer wäre? Es wird weniger Silizium benötigt als bei einem Interposer.



Fertigung: Umso geringer die Chipgrösse, desto geringer die total anfallenden Kosten pro mm2. Umso kleiner die Chips, desto einfacher sind sie zu fertigen und desto früher kann man auf einen neuen Top Notch Node wechseln (Zeitvorteil). Ausserdem schlägt Economy of Scale bei höherer Stückzahl positiv zu. Vorteil Zen-Variante

Das war vielleicht zu Anfang von 7nm und bei CPUs so. Aber siehst du bei 7nm irgendwelche Anzeichen dass die Yields bei GPUs schlecht sind? Im Gegenteil, die scheinen bei AMD stabiler zu sein als bei Nvidia, da man generell weniger salvaged.
Ich glaube diese Sache mit dem Die unter 100mm2 halten um den Yield zu verbessern war eine einmalige Sache, die man eigentlich schon bei Zen3 hätte beenden können. Was man aber nicht gemacht hat um die infrastruktur weiter zu nutzen. Aber letztendlich würde eine single oder dual chip lösung bei einem ausgereiften Prozess Kosten sparen beim Packaging.
Bei GPUs gibt es viel mehr Salvage Optionen als bei einer CPU. Zumal eine Epyc CPU gigantisch wäre und viele Fehler auch im SI, PCIe, IF etc. hätte.
Insofern finde ich ist der Zen-alike Ansatz nicht auf GPUs übertragbar.



Time to Market: Siehe Fertigung und SKU-Gestaltung. Man kann früher auf einen neuen Prozess wechseln und hat früher ein breites Portfolio am Markt. N22 ist später als N21. GA104 ist später als GA102 usw. das hätte man mit Chiplets nicht mehr.

Bloß weil der Compute Die schon fertig ist musst du trotzdem noch ein neues package bzw. Redistribution Layer entwickeln. Ob der packaging aufwand soviel weniger zeit benötigt als die Masken für einen kleineren chip? :rolleyes:

[davidzo]

Kann mir nicht vorstellen, dass das für Video-Wiedergabe oder sonstige Niedriglast-Szenarien nicht der GAU für die Effizienz wäre.

Eher nicht. Gerade wenn es nicht die höchste Density sein muss gibt es sehr effiziente low power Prozesse zur Auswahl.
Der B550 Chipsatz wird auch nur in 55nm gefertigt und hat trotzdem mit 5W eine viel geringere TDP als der X570 mit 11Watt in 14nm.

[aufkrawall]

Man sollte eher mal die VRAM-Takt Problematik in den Griff bekommen. Die gibt es schon seit RV770 immer mal wieder je nach GPU, auch bei N21.

Der ist aber nicht das Problem, weshalb die 6800 XT bei 4k-Wiedergabe 50W säuft. Entscheidende Teile des Chips scheinen da viel zu schlecht zu idlen. Warum sollte man ausgerechnet durch das Zerpflücken des Chips Einsparungen erzielen, wenn sich bei Zen das komplette Gegenteil abzeichnet und es andere GPU-Hersteller für monolithische Designs wesentlich besser hinbekommen?

[robbitop]

Das Problem mit 3D Stacking ist IMO nicht die Machbarkeit für Multi Compute Dies. Das wurde ja schon in Serienprodukten bewiesen. Zuletzt von Intel mit Lakefield und nächstes Jahr mit Alder Lake.

Das Problem ist wohl eher thermischer Natur. Intel hatte ja einen Compute, einen IO Die und einen DRAM Die gestackt. Und laut Architecture Day war das Layout hier schon eine Herausforderung die Hotspots so untereinander zu verschieben, dass nicht mehre übereinander sind. Und das bei nur einem Compute die (wo die Verteilung der Wärmeenergie ja sicherlich deutlich weitreichender als bei einem I/O Die ist).
Wenn man jetzt mehrere Compute dice stapeln würde, gäbe es da sicherlich schnell Engpässe aus thermischer Sicht. Vereinfacht gesagt wenn 80% der Fläche eines compute dies "heiß" ist, gibt es nicht genug Fläche um das zu verschachteln.

Hier muss sich sicherlich noch einiges tun in Bezug auf Wärmetransport der unteren dice, eh das wirklich sinnvoll machbar ist.

[HOT]

Aber ein I/O-Die, dass in 12nm gefertigt würde und sonst nur noch den I$ enthält erzeugt sowenig Verlustleistung, dass das wohl das erste Produkt werden könnte, bei dem das sinnvoll machbar ist. Darauf könnte man dann das Compute-Die in 5 oder 6nm stapeln. Für RDNA3 wäre das ne elegante Lösung - den schwarzen Peter sehe ich da wieder eher bei der Kühlerkonstruktion, denn da darf ja lange nicht soviel Anpressdruck herrschen. Das dürfte das einzige echte Hindernis bei der Massenkompatibilität des Verfahrens darstellen. Das dürfte nur sinnvoll mit dem Einsatz von Flüssigmetall gehen.

aufkrawall
wenn nur noch Teile des I/O-Chips laufen und der Compute-Chip größtenteils in Tiefschlaf gelegt wird ändert sich an der Problematik gar nichts. Ob das dann Chiplets sind ist total egal. AMD müsste aber diese Baustelle bei so einem Konzept sowieso angehen, was sicherlich eine gute Sache wäre, weil das ein Fortschritt zum Status Quo wäre, Chiplets hin oder her.

[robbitop]

Ja das wäre eher machbar. Aber das ginge wohl auch noch vernünftig in 2,5D o.Ä.

[Platos]

Wenn der Stromverbrauch nicht (je nach Situation) extrem steigen soll, müsste bei einer Auslagerung (von was auch immer), wirklich gestapelt werden (das wäre zumindest aus Perfomancesicht das sinnvollste). Je grösser die Distanzen werden, desto schlimmer werden die Nachteile. Und von daher wird der Compute-Die sicherlich noch einige Jahre monolithisch bleiben.

Und nochmals: Bisher gibt es keine Gründe, da die Fertigungssprünge nicht extrem klein ausfallen. Abgesehen davon reichen +30%. Es gibt zuerst noch einen Refresh oder ähnliches, was wieder niedrigere Perfomance hat (von nvidia). Zumindest kann man davon ausgehen, wenn man die Vergangenheit betrachtet.

[AlterSack]

gab es bei einem der zukünftigen prozesse bei tsmc (3nm oder 5nm) nicht eine
begrenzung der fläche pro DIE? ...lag irgendwo bei 400-500mm².
insofern hat sich das thema monolithisch für die grösseren gpu
demnächst ohnehin erledigt.

[basix]

gab es bei einem der zukünftigen prozesse bei tsmc (3nm oder 5nm) nicht eine
begrenzung der fläche pro DIE? ...lag irgendwo bei 400-500mm².
insofern hat sich das thema monolithisch für die grösseren gpu
demnächst ohnehin erledigt.

Soweit ich weiss bei 3nm, da man HiNA Belichter benötigt. Ansonsten müsste man EUV Multipatterning anwenden, was sehr teuer ist. HiNA ist aber für 3nm vermutlich noch nicht verfügbar, evtl. wird TSMC da etwas tricksen.
“High-NA is likely to be used starting with the 2nm node,”
Man kann aber immer noch grössere Chips produzieren via "Stitching". Das reduziert aber die WPH von anscheinend 180 auf 135, was die Kosten nach oben treibt.
For this, chipmakers must resort to a technique called stitching. This involves the process of exposing one part of a pattern with one mask and then exposing the next part with a second mask. Then, the masks are stitched together and printed on the wafer.

This is a complex process, which reduces the throughput to 135 wph. But to meet the 135 wph spec, ASML has devised a stocker unit for the system. The system exposes the first half-field on all wafers in a single lot. It stores the wafers in an onboard stocker. Then, it exposes the second half-field.

To get around the problem, you can develop chips with smaller die sizes. Another solution is chiplets. In chiplets, you have a library of smaller die, which are then assembled and connected in an advanced package.
https://semiengineering.com/multi-patterning-euv-vs-high-na-euv/

Lösung für diese Kostenprobleme: Kleinere Chips und Chiplets.

Edit:
3D Stacking ist ein etabliertes und sehr kosteneffizientes Massenverfahren bei der Flash Speicherherstellung. Praktisch jeder aktuelle Nand nutzt massiv 3D Stacking mit TSVs. Nach unten kommt ein Logikdie mit dem PHY und oben drauf werden die Nand Chips gestapelt. TSMC ist da gewissermaßen Late-comer drin, hat das aber genau für Massenproduktion in 2021 angekündigt. Das passt total zum Zeitplan für N3x.
Für zwei Logikdies ist das was den TSV pitch angeht nicht so regelmäßig, sollte aber mit dem richtigen tooling auch kein Problem sein.
Ich behaupte, das MCM Packaging immer günstiger in der Herstellung sein wird als 3D-Stacking. Das Substrat kostet keine Welt, der Prozess ist ewigs lang gereift und man bekommt Chip-Oberfläche zur Kühlung. Natürlich wäre der Bestfall, wenn man PCIe, Display, UVD, IF$ auf einem Bottom-Die hat und nur noch CUs und Shader Engines auf dem Top Die. Damit hast du zwar eine sehr performante Lösung und die Chips sind klein, dennoch muss man für jedes Marktsegment zwei neue Chips auflegen. Und diese Designkosten werden mit den kleineren Nodes immer höher. Mit 1x MCD + 2x GCD bekommt man aber diese Skaleneffekte und die Herstellung ist günstiger. Und dass man bei einer GPU TB/s zwischen Die und nicht GB/s übertragen will, macht die Sache mit den TSVs deutlich aufwändiger ;)

Was allenfalls etwas schwieriger ist, ist das generelle GPU-Design / Architektur: Last auf 2 Chiplets verteilen und allenfalls aufgesplitteter IF$. Vor allem letzteres ist schade bei einem Dual GCD Design.

Du verwechselst da gerade eine Interposer Lösung (2.5D) mit einer echten 3D Lösung. Wie kommst du darauf das es viel teurer wäre? Es wird weniger Silizium benötigt als bei einem Interposer.
Nö, ich weiss ganz genau was ich geschrieben habe. Ein Interposer kostet je nach Grösse keine 10$. Wie viel kosten die Zusatzaufwände für 3D? Dazu findet man keine anständigen Zahlen. Aber alles was noch nicht lange erprobt ist, kostet mehr Geld (Entwicklungskosten, teure Prozesschritte, Yield Nachteile, usw.)


Das war vielleicht zu Anfang von 7nm und bei CPUs so. Aber siehst du bei 7nm irgendwelche Anzeichen dass die Yields bei GPUs schlecht sind? Im Gegenteil, die scheinen bei AMD stabiler zu sein als bei Nvidia, da man generell weniger salvaged.
Ich glaube diese Sache mit dem Die unter 100mm2 halten um den Yield zu verbessern war eine einmalige Sache, die man eigentlich schon bei Zen3 hätte beenden können. Was man aber nicht gemacht hat um die infrastruktur weiter zu nutzen. Aber letztendlich würde eine single oder dual chip lösung bei einem ausgereiften Prozess Kosten sparen beim Packaging.
Nein, die Yields sind gut. Aber eine 60CU N21, 160b N22 usw. deuten nicht darauf hin, dass sie zu gut sind ;)


Bei GPUs gibt es viel mehr Salvage Optionen als bei einer CPU. Zumal eine Epyc CPU gigantisch wäre und viele Fehler auch im SI, PCIe, IF etc. hätte.
Insofern finde ich ist der Zen-alike Ansatz nicht auf GPUs übertragbar.
Bei GPUs und CPUs gibt es genau gleich viel Salvaging. GPUs wie auch CPUs haben verschiedene Die je nach Marktsegment (z.B. Intel XCC, HCC, MCC Dies, Unterschied zwischen Consumer und HEDT, usw.). AMD hat es nun bei den CPUs geschafft, via Chiplets den gesamten Produktstack abdecken zu können. Das wäre bei GPUs genau gleich attraktiv und man könnte auch bei den GPUs die totale Siliziumfläche erhöhen. Einfach weil es bezahlbar wäre. Bei GPUs wird aber viel mehr Bandbreite benötigt, was Chiplets schwieriger in der Umsetzung macht. Mit den IF$ spart man aber deutlich an Bandbreite, somit rückt das langsam in die Nähe des machbaren. Stell dir vor, AMD müsste nur noch zwei relativ kleine Chips entwickeln. Im Extremfall mit 2x HBM-Stacks anstatt GDDR6 und 4x GCD. Mit dieser Aufteilung könnte man den gesamten Markt von Low End bis High End mit zwei relativ günstigen Chips abdecken. MCD wie GCD kann man gut salvagen und hätte sehr gute Yields.


Bloß weil der Compute Die schon fertig ist musst du trotzdem noch ein neues package bzw. Redistribution Layer entwickeln. Ob der packaging aufwand soviel weniger zeit benötigt als die Masken für einen kleineren chip? :rolleyes:
Ein Package ist mMn einfacher zu designen als neue Chips ;) Und wenn ich das Beispiel von oben nehme: 1x Package für den gesamten Produktstack, 2x kleine Chips. Sicher der geringere Designaufwand verglichen mit heute 3-4 Chips von klein bis ziemlich gross. Und bei Time-to-Market meine ich z.B. auch, dass man mit kleineren Chips deutlich früher anständige Yields erreicht. Somit kann man sich einen Zeitvorteil ggü. der Konkurrenz erarbeiten.

3D-Stacking kann immer noch kommen. Man splitted das GCD nämlich in IF$ und Shader Engines auf. Dann sind wir schon bald bei dem X3D aus den AMD-Folien ;)

Falls du magst, kann ich auch deine Ideen/Ansichten mit meinen kombinieren:
Base Die mit I/O und IF$. Zwischen den Produktsegmenten skaliert man nur den IF$ sowie die SI-Breite. Cache sollte mit relativ wenig Design-Aufwand skalierbar sein und durch Redundanz ist der Yield von Cache sehr gut. Obendrauf auf diesen Base Layer kommen dann aber einzelne Chiplets mit z.B. einer einzelnen Shader Engine + CUs. Hier hat man zwar etwas erhöhte Designkosten für mehrere Base Die, aber man kann den IF$ zusammenhalten.

[Platos]

Kann mal jemand was verlinken bezüglich maximaler Diesize von 400-500m^2 in 3nm ?

[amdfanuwe]

Kann mal jemand was verlinken bezüglich maximaler Diesize von 400-500m^2 in 3nm ?
In today’s 0.33 NA tool, the lens supports 4X magnification with a maximum exposure field size of 26mm x 33mm.

In high-NA, though, the anamorphic lens supports 8X magnification in the scan mode and 4X in the other direction. Increasing the image magnification from 4X to 8X boosts the resolutions and reduces the shadowing effects.

But increasing the magnification also cuts the image field size to one half. ...
This mainly involves larger die sizes.
https://semiengineering.com/multi-patterning-euv-vs-high-na-euv/
Also aktuell max. 26mm x 33mm = 858mm²
Mit High Aperture nur noch die Hälfte = 429mm²

[amdfanuwe]

Nein, die Yields sind gut. Aber eine 60CU N21, 160b N22 usw. deuten nicht darauf hin, dass sie zu gut sind ;)

Muß nicht nur am Yield liegen. Nicht alle fehlerfreien Chips packen die gewünschten hohen Frequenzen bzw. haben die nötige Effizienz.
Sieht man auch an den niedrigeren Takten bei der 6800 mit 60CU N21.
Was da nicht mehr verwurschtelt werden kann ist wirklich nur noch Schrott.

[basix]

Für mich gehört Takt zum Yield. Total Yield = Verwendbare Chips und nicht fehlerfreie Chips. Und umso kleiner der Chip, desto geringer ist der Anteil welcher den Zieltakt nicht erreicht.

[LasterCluster]

Für mich gehört Takt zum Yield. Total Yield = Verwendbare Chips und nicht fehlerfreie Chips. Und umso kleiner der Chip, desto geringer ist der Anteil welcher den Zieltakt nicht erreicht.

Damit hättest du dann sowas wie einen bedingten bzw relativen Yield: %-Zahl der Dies, die einen bestimmten Takt nicht mehr schaffen sind "fehlerhaft". Das hat dann aber zunehmend weniger mit objektiven Eigenschaften des Prozesses, sondern mehr mit den Anforderungen/Möglichkeiten des Marktes zu tun. Und die sind bei N21 als Hi-End eben so, dass man möglichst viele Top-Dies haben will, weil jedes % Perfomance ein Vielfaches an Preisplus ermöglicht (siehe 6900XT, 3090).

Und alle relativ gesehen mangelhaften Dies bekommt man in diesem Segment immer noch für gutes Geld unter.

Fazit: Die 6800 ist mehr ein Ergebnis der BWL als der Technik.

[basix]

Yield hat immer mit BWL und Marktanforderungen zu tun, die Technik dahinter erlaubt einfach entsprechend gute oder schlechte Ausbeute ;) Rein technisch machbar ist viel, aber bei weitem nicht alles ist wirtschaftlich. Und wenn es nicht wirtschaftlich ist, ist es mittel- bis langfristig nicht tragbar.

Es gibt ja immer wieder Beispiele, wo SKUs im Schnitt mit viel zu viel Spannung betrieben werden. Das ist ebenfalls Yield-Optimierung.

Schlussendlich gibt es beim Yield zwei mögliche Arten von Ausschuss: Defekte Chipteile (Fatal Failure) oder technische Parameter werden nicht erreicht. Fatal Failures kann man deaktivieren (teildeaktivierte SKUs). Den Takt kann man entweder reduzieren (weniger teuere SKU) oder die Spannung anheben um den Zieltakt dennoch zu erreichen (bei modernen GPUs: Power Limit relativ hoch ansetzen --> Ampere anyone?). Klappt beides nicht = Ausschuss. Ein hoher "Funktionsfähigkeits Yield" (alle Funktionseinheiten des Chips funktionieren) muss gar nichts bedeuten, wenn die Hälfte der Chips nur auf 50% des Zieltaktes kommen. Der Yield wäre dann einfach scheisse. Und genau dieser Failure-Mode ist vor allem am Anfang neuer Lithographie-Prozesse vermutlich deutlich dominanter als dass 50% aller Chips Totaldefekte aufweisen.

Wenn man den Chipfläche reduziert (Chiplets) wird automatisch der Anteil der Chips steigen, welche voll funktionsfähig sind oder den Zieltakt erreichen (oder kann sogar höhere Taktraten als sonst anbieten). Und genau das erlaubt es, deutlich früher auf neue Prozesse umzusteigen. Mit 100mm2 Chiplets hat man deutlich früher gute Yields. Bei ausgereiften Prozessen ist der Unterschied dann nicht mehr so dramatisch. Aber der Zeitvorteil, früh auf Bleeding Edge umzusteigen, ist ein Konkurrenzvorteil. Und das wiederum bedeutet höhere Marktanteile als auch Profite. Und schon sind wir von der Technik wieder zurück bei BWL ;)

Und die sind bei N21 als Hi-End eben so, dass man möglichst viele Top-Dies haben will, weil jedes % Perfomance ein Vielfaches an Preisplus ermöglicht (siehe 6900XT, 3090).
Was man mit Chiplets deutlich einfacher erreicht, da man deutlich aggressiver Binning betreiben kann. Es gab ja ein Paper, wo man +10% Takt rein über das stärkere Binning erreichen konnte. Das und die erhöhte Wirtschaftlichkeit ist der Grund, wieso ich auf mehrere Chiplets (GCD) pro GPU tendiere. Spaltet man einfach den MCD ab, gewinnt man nicht so viel (ausser man verwendet das selbe MCD für alle GPUs von Top to Bottom).

[dargo]

Ist RDNA3 noch für Ende 2021 oder eher Q1-Q2 2022 geplant?

[amdfanuwe]

Laut Roadmap bis Ende 2022. Wenns früher kommt, freu dich, erwarte es aber nicht.
Wenns dumm läuft, Vorstellung Q4 2022 und kaufbar zu vernünftigen Preisen Mitte 2023.

[AffenJack]

Ist RDNA3 noch für Ende 2021 oder eher Q1-Q2 2022 geplant?

Noch? RDNA3 war doch immer für 2022 angesetzt. Einzig paar Träumer hier haben von 2021 geträumt.

Wie amdfanuwe schon schreibt würde ich mir nichtmal mit H1 2022 sicher sein. Allerdings denke ich schon, dass beide Hersteller versuchen werden in H1 zu kommen.
Aber es fehlen ja auch noch 3 N22, N23 und N24 die erstmal erscheinen müssen.

[ZeXes]

Ich gehe mal wieder schwer von einer Ankündigung auf der E3 aus, 2022 natürlich.

Release dann so um Sept.-Okt. 2022.

[Piefkee]

AMD chiplet GPU Patent
https://twitter.com/davideneco25320/status/1345134261737762816?s=21
https://www.freepatentsonline.com/y2020/0409859.html

A chiplet system includes a central processing unit (CPU) communicably coupled to a first GPU chiplet of a GPU chiplet array. The GPU chiplet array includes the first GPU chiplet communicably coupled to the CPU via a bus and a second GPU chiplet communicably coupled to the first GPU chiplet via a passive crosslink. The passive crosslink is a passive interposer die dedicated for inter-chiplet communications and partitions systems-on-a-chip (SoC) functionality into smaller functional chiplet groupings.

> For example, in some embodiments, the GPU chiplets may be constructed as pentagon-shaped dies such that five GPU chiplets may be coupled together in a chiplet array.

[fondness]

Die nächste Bestätigung für ein Chiplet Design mit RDNA3.

[amdfanuwe]

Patente gibt es viele. Könnte sich auch nur für CDNA rechnen und RDNA bleibt erst mal monolithisch.
RDNA braucht ja auch Video und Media Einheiten. Wäre etwas verschwenderisch die auf jedem Chiplet zu haben.

[HOT]

Da würd ich eher sagen für RDNA4.

[ZeXes]

Ich gehe auch von RDNA4 aus.

Bei NVIDIA hat man schon gehört, dass man Hopper nach 2024 verschoben hat, welches auch auf ein Chipletdesign setzen soll.

Ich gehe schwer davon aus, dass auch AMD in diesem Zeitraum seine erste GPU auf Chipletbasis veröffentlichen wird. Würde mich gar nicht wundern, wenn RDNA4 auch die Grundlage für PS5 Pro und Xbox Series Z ( ;) ) wird.

Aber schon schön zusehen, dass der Fortschritt nicht schläft und alle wirklich auf Hochtouren arbeiten, um die maximale Leistung den Kunden zu bieten.

[basix]

Patente gibt es viele. Könnte sich auch nur für CDNA rechnen und RDNA bleibt erst mal monolithisch.
RDNA braucht ja auch Video und Media Einheiten. Wäre etwas verschwenderisch die auf jedem Chiplet zu haben.

Bei RDNA3 gibt es ja Gerüchte zu MCD und GCD Aufteilung der GPU ähnlich wie es bei Zen 2/3 läuft. Video und Media Einheiten kämen natürlich auf das MCD (von welchem es nur 1x pro GPU hat).

Für mich sieht es aber auch mehr nach CDNA aus. Da könnte man die Einheiten symmetrisch auf 4 Chiplets aufteilen (z.B. je 4x PCIe Lanes pro Chiplet). Oder man macht einen aktiven Interposer oder so, welcher I/O übernimmt. Fig.6 illustriert noch, dass es ein Master-Slave Konzept gibt. Eines der Chiplets wird als "Primary GPU Chiplet" bezeichnet, welches mit der CPU verbunden ist. Das macht vor allem bei CDNA Sinn. Die anderen 3 Chiplets wären dann direkt mit den anderen GPUs im HPC-Verbund verbunden. Da die PHYs bei PCIe und xGMI dieselben sind, kann man alle Chiplets mit den gleichen I/O Funktionalitäten ausstatten. Damit liesse sich auch der Yield erhöhen: Ist der PCIe Controller futsch, nimmt man das Chiplet als xGMI GPU-zu-GPU Die. Das selbe vice versa wenn der xGMI Controller futsch ist.

Und wer es bemerkt hat: Die Chiplets tragen einen L3 --> Infinity Cache ;) Der HBX Crosslink scheint überhalb des Caches die Einheiten zu verbinden, womit alle Chiplets den gesamten Cache und das gesamte Speicherinterface verwenden können (was logisch sein sollte). Wenn man noch dort wo der HBX in der Grafik ist den Schnitt für 3D-Stacking macht, kann man den L3$ und Memory Controller auf ein Base Die auslagern. Evtl. nicht bei CDNA2 und RDNA3 aber möglicherwiese bei deren Nachfolgern.

[HOT]

CDNA könnte man auch gut so desginen, da die ja keine Display-Geschichten haben und das Ganze gut wie ein NUMA-Node aufgebaut werden kann, ähnlich wie bei Zen1. Intel scheint es ja auch so zu machen und angeblich soll Hopper ja auch ähnlich aussehen.
Bei RDNA dürfte mittelfristig eher eine ähnliche Aufteilung wie bei Zen2/3 anstehen, also separates I/O+Display-ctrl-Die mit 1-2 Chiplets.

[prinz_valium_2]

RDNA3 kommt Q3/Q4 2022
RDNA4 2025 (dank chiplet Design aber vllt auch etwas eher und nicht spät im Jahr)


RDNA2 ist ja gerade mal Q1 2021 wirklich erschienen
Wird Zeit sich von neuer Technik jedes Jahr zu verabschieden. Bin gespannt wie lange die Smartphone Hersteller das noch machen. Auch da ist es bald nicht mehr sustainable

[HOT]

Glaub ich nicht. Offenbar gibts das Ding evtl. schon in Silizium, das dauert nie im Leben so lange. N31 ist schon seit Frühjahr 2020 bekannt und dass das Ding 80CUs hat seit Herbst. Realistischer ist Anfang 2022. Ich denke, dass AMD hier weiterhin modular arbeitet im Design, was kürzere Zyklen mit weniger Änderungen ermöglicht. Dafür spricht auch der kaum veränderte Befehlssatz zu N2x. Die sind auf der Jagd und hauen mMn jetzt schneller Chips raus. AMD wird hier auch einen 5 Quartale-Zyklus anstreben, das hatte sich bei CPUs ja sehr bewährt. Also würde N31 in Q1 2022 erscheinen, RDNA4 (vermutlich in modularen Chiplets) dann Q2 2023.
Zum Vergleich: N21 ist seit Herbst 2019 bekannt, dass er 80 CUs hat seit Anfang des Jahres.

[prinz_valium_2]

Dann ist es nichts anderes als der Sprung zwischen Zen und Zen+

Minimalste Architekturänderungen und im selben Prozess. Also mehr Marketing Name als alles andere.

Ansonsten erst sehr spät.

[HOT]

Zen+ ist identlich mit Zen1, da gibts keine starken Änderungen, das ist ne neue Revision mit neuer Fertigung und (damit) niedrigere Latenzen AFAIK. Das ist schon ein Sprung, aber größer als das. Man wird sich erheblich mehr auf RT konzentrieren, die restlichen Änderungen werden mMn überschaubar bleiben. AMD baut halt ein, was man bis dahin entwickelt hat und gießt das in Silizium. Gegen den DA102 wird das mMn nicht reichen, aber dafür sind die Entwicklungzyklen vllt. kürzer.

[Brillus]

Da würd ich eher sagen für RDNA4.

Hört sich in der Form noch nach IO + Compute an das wurde ja schon so für RDNA3 spekuliert also kann es schon auch früher kommen.

[SKYNET]

Noch? RDNA3 war doch immer für 2022 angesetzt. Einzig paar Träumer hier haben von 2021 geträumt.

Wie amdfanuwe schon schreibt würde ich mir nichtmal mit H1 2022 sicher sein. Allerdings denke ich schon, dass beide Hersteller versuchen werden in H1 zu kommen.
Aber es fehlen ja auch noch 3 N22, N23 und N24 die erstmal erscheinen müssen.

könnte mir vorstellen das AMD evtl. noch nen dicken chip auf RDNA2 ende dieses jahr raushaut... 128CUs oder sowas :uponder:

[Neurosphere]

könnte mir vorstellen das AMD evtl. noch nen dicken chip auf RDNA2 ende dieses jahr raushaut... 128CUs oder sowas :uponder:

Bei der derzeitigen Liefersitu müsste man das Produkt dann nicht mal wirklich bringen:freak:

[SKYNET]

Bei der derzeitigen Liefersitu müsste man das Produkt dann nicht mal wirklich bringen:freak:

steht auf nem anderen blatt... langt das man "offiziel" was hat, das die leistungskrone inne hat... mehr interessiert den DAU nicht, hersteller XYZ hat das schnellste produkt, dann müssen auch alle anderen produkte von diesem hersteller das beste sein... :freak:

[Neurosphere]

https://www.computerbase.de/2021-01/patent-amd-gpu-chiplet-design/

Das nochmal zu dem was vorige Seite gepostet wurde.

Ich finde es interessant das man den Weg zur Kommunikation über den Cache gehen will. Es wirkt fast so als wäre der Infinity Cache von RDNA2 eine Evolution auf dem Weg dort hin.

Jetzt aber mal was am Rande was ich gerade deswegen nachgeschaut habe. Als ich damals das Video zur
Vorstellung von RDNA 2 live gesehen habe, hat Laura Smith mit ziemlicher Sicherheit was zu RDNA 3 gesagt. Ich hab grad versucht das nochmal zu finden, aber es fehlt in dem Video das man auf Youtube finden kann:

https://youtu.be/oHpgu-cTjyM?t=524

Jetzt sieht man es nur im Hintergrund. Ich bin mir aber ziemlich sicher das sie damals gesagt hat das man auch schon mit RDNA3 gut im Zeitplan wäre und sich großes erhofft. Danach kam erst ihr wink zurück zu RDNA2 und an Herkelman. Wurde da was bearbeitet? Oder unterliege ich grad dem Mandela Effekt?!?

Edith sagt: Ok, hab ich wohl nur geträumt. Gibt ja zum "Glück" genügend live Reaktion Mitschnitte...

[Platos]

Interessant ist vor allem, dass anscheinend eine "Haupt-GPU" und mehrere "Neben-GPUs" in diesem Ansatz die Idee sind.

Ich frage mich allerdings, was diese Haupt-GPU ist. Ist das auch eine GPU mit CUs usw. oder ist das nur eine Art Controller, die die Aufgaben den jeweiligen Unter-GPUs zuweist? Wenn's nicht nur eine Art Controller ist, warum gibt es dann eine Haupt-GPU bzw. was macht die denn?

[dargo]

Lese den CB-Artikel dann weißt du es.

[Platos]

Da steht nur, dass das Hauptchiplet unter anderem für die Aufteilung der Rechenlast zuständig ist. Da steht nicht, was sie sonst noch so macht. Steht auch nicht, inwiefern sich das Hauptchiplet von den anderen unterscheidet.

Aber gut, das mit den CUs für das Hauptchiplet habe ich überlesen. Aber vermutlich wird das Hauptchiplet trotzdem noch eine Art controller integriert haben.

Wie das genau aussieht, würde mich interessieren. Steht nicht da.

[gedi]

Ihr redet so weit in die Zukunft - das Design wurde erst patentiert, wie lange dauert es bis es spruchreif wird (?) - > 6 Jahre :confused:

[Linmoum]

Man fängt doch nicht erst mit dem forschen bei Einreichung eines Patents an, das geschieht schon deutlich früher. Was ja auch logisch ist, auf welcher Grundlage will man sich sonst Dinge patentieren lassen?

Davon ab ist das auch schon von Mitte 2019, eingereichte Patente werden nur erst 18 Monate später öffentlich gemacht.

[robbitop]

IMO muss dazu auch noch moderne Packaging Technologie (stacking, SI etc) genutzt werden. Die angepasste Topologie inkl Caches allein reicht vermutlich nicht um die erhöhten Transferkosten (joules/bit) zu kompensieren. Es bleibt wirklich spannend. :)

[gruntzmaker]

Also ich hoffe, dass wir bald mal etwas Neues zu Fidelity FX Super Resolution sehen. Aber mangels KI Kernen wird das wahrscheinlich ein etwas besseres CAS werden oder Checkerboard Rendering.

In Cyberpunk 2077 macht ja zumindest CAS ziemlich viel her.

[robbitop]

IIRC wurde mal berichtet, dass es nicht auf AI aufsetzt. Entsprechend würde ich auch auf konventionelle temporale Rekonstruktion tippen. ZB Checkerboarding.

[Platos]

Und der Stroverbrauch. Wie auf der Hauptseite von Leonidas erwähnt, wird der Stromverbrauch dadurch sicherlich nicht sinken, sondern steigen.

D.h man kann nicht einfach einen hypothetischen 1000mm2 Die in 5-6 Chiplets aufteilen und dann in Consumergrafikkarten verbauen. Dazu wäre der Stromverbrauch einfach zu hoch.

Durch ein Chiplet-Design wird sich also nicht mehr Perfomance ergeben (bei selbem Stromverbrauch), sondern lediglich die Produktionskosten mindern. Der Stromverbrauch wird aber weiterhin ein Problem sein. Man kann schliesslich nicht einfach beliebig viele Chiplets produzieren, dann hat man irgendwann eine 1kW gpu. Für Proffesionelle Anwendung vlt, aber nicht für Gaming-Grafikkarten.

Eine Ausnahme sind vlt. solche Begrenzungen, wie bei 3nm TSMC, wo die Dies max. um die 400mm2 sein dürfen. Da könnte man dann vlt. doch noch mittels Chiplet-Ansatz bis auf 600-800mm2 hochgehen vom Stromverbrauch her gesehen.

Allerdings wird sich noch zeigen, ab wann ein Chiplet-Design nötig ist. Die ersten 2 Grafikkartengenerationen in 3nm werden es sicherlich nicht nötig haben, auf Chiplets zu setzen. Für die erste sollte die Fläche noch reichen und in der 2. gibts wie immer einfach ein Refresh. Und die 3. Generation könnte dann schon wieder in 2nm gefertigt werden. Also mal sehen, wann es nötig wird.

AMD wird mit RDNA 3 auch erst 2022 in 5nm kommen und man kann davon ausgehen, dass AMD mindestens 2 Grafikkartengenerationen in 5nm verbringt. Also wird 3nm vermutlich frühestens 2024 ein Thema sein und somit 2025 ein 3nm Refresh kommen. Somit wird meiner Meinung nach erst frühestens 2026 ein Chiplet-Ansatz überhaupt nötig sein.

Seit Pascal kamen schliesslich erst immer 2 Jahre später eine neue Generation mit viel mehr Leistung. Das wird sich in Zukunft sicherlich nicht wieder verkürzen.

[|MatMan|]

Man fängt doch nicht erst mit dem forschen bei Einreichung eines Patents an, das geschieht schon deutlich früher. Was ja auch logisch ist, auf welcher Grundlage will man sich sonst Dinge patentieren lassen?
Patentiert werden in erster Linie Ideen, die kann man zu jedem Zeitpunkt der Forschung haben (auch wenn man gerade an was ganz anderem arbeitet). Bevor man etwas entwickelt, sollte man eigentlich eine Idee haben, wie man das Problem lösen möchte. Die Idee sollte also schon eher früh da sein.

Ein Patent sagt übrigens überhaupt nichts darüber aus, dass das, was patentiert wurde, auch funktioniert. Das muss man nicht nachweisen!

[Nightspider]

IMO muss dazu auch noch moderne Packaging Technologie (stacking, SI etc) genutzt werden. Die angepasste Topologie inkl Caches allein reicht vermutlich nicht um die erhöhten Transferkosten (joules/bit) zu kompensieren. Es bleibt wirklich spannend. :)

Muss ja nicht stacking sein, FAN-OUT WAFER-LEVEL PACKAGING sollte die Transferkosten deutlich verbessern, wenn ich das nicht falsch verstanden habe.

Und der Stroverbrauch. Wie auf der Hauptseite von Leonidas erwähnt, wird der Stromverbrauch dadurch sicherlich nicht sinken, sondern steigen.

Man kann durch Chiplets halt viel eher auf einen neuen Fertigungsprozess wechseln und gleichzeitig die Kosten im Rahmen halten.

-> höhere Effizienz und mehr Geschwindigkeit

Wie bei Zen 2 mit bis zu 16 Kernen für einen super Preis, bei überlegener Effizienz

[Linmoum]

Patentiert werden in erster Linie Ideen, die kann man zu jedem Zeitpunkt der Forschung haben (auch wenn man gerade an was ganz anderem arbeitet). Bevor man etwas entwickelt, sollte man eigentlich eine Idee haben, wie man das Problem lösen möchte. Die Idee sollte also schon eher früh da sein.

Ein Patent sagt übrigens überhaupt nichts darüber aus, dass das, was patentiert wurde, auch funktioniert. Das muss man nicht nachweisen!Eine solche Patentanmeldung ist aber genauso wenig Resultat einer Idee nach drei Tagen brainstorming und das war es. Patentanmeldungen sind nicht nur stupide einfache Ideen, da steckt viel mehr dahinter. Muss es ja grundsätzlich auch, wenn man etwas patentieren lassen will. Stichwort u.a. Stand der Technik.

Funktionalität ist eine andere Geschichte, aber gerade bei technischen Erfindungen oftmals der Hintergedanke.

[Platos]

Man kann durch Chiplets halt viel eher auf einen neuen Fertigungsprozess wechseln und gleichzeitig die Kosten im Rahmen halten.

-> höhere Effizienz und mehr Geschwindigkeit

Wie bei Zen 2 mit bis zu 16 Kernen für einen super Preis, bei überlegener Effizienz

Ja, siehe dazu auch Leonidas' News vom 5. Januar. Sowas ähnliches habe ich auch geschrieben.

[robbitop]

Ich finde, dass man Zen nicht als Vergleich nennen kann. Bei CPUs ist die Interdependenz und somit Core-to-Core Communication um Größenordnungen geringer. Entsprechend ist auch die Steigerung des Energiebedarfs dadurch vergleichsweise geringer.
Und selbst dort sah man gesteigerten Energiebedarf. APUs sind aus diesem Grund nach wie vor monolithisch von AMD.

Es ist nunmal so in Natur und Technik, dass alles seine Vor- und Nachteile hat. Vorteile werden durch Nachteile bezahlt. Man muss entsprechend balancen und trade-offs eingehen, damit das Endergebnis (zumindest in den Kernkriterien) deutlich besser ist.

Ich kann mir gut vorstellen, dass time-to-market + risk + cost besser werden. Aber performance pro W (wenn man sich das prozess- und architekturnormiert anschauen würde) wohl ggf nicht. Aber man kann die Lücke ggf so klein machen (Caches, Topologie, neue packaging technologien und prozess shrinks), dass das Endergebnis ggf. irgendwann mal so interessant wird, dass man darauf setzen kann.
Ich bin hier noch etwas skeptisch, dass dieser Punkt für 3D Grafik schon kurzfristig erreicht werden soll. Mittel bis langfristig ist das natürlich ein anderes Thema und hängt stark von den Innovationen (auch in Bezug auf Kosten und thermische Herausforderungen beim Stacking zB) ab, die noch kommen.
Aktuell pappt man einen Chip auf ein organisches Package. Das ist einfach und günstig. Silicon Interposer, Stacking etcpp erhöht zunächst mal die Kosten. Aber auch bei diesen Technologien sind Fortschritte in Bezug auf Kosten (durch technischen Fortschritt und Skaleneffekte) zu erwarten.

[Nightspider]

Ich finde, dass man Zen nicht als Vergleich nennen kann. Bei CPUs ist die Interdependenz und somit Core-to-Core Communication um Größenordnungen geringer. Entsprechend ist auch die Steigerung des Energiebedarfs dadurch vergleichsweise geringer.
Und selbst dort sah man gesteigerten Energiebedarf.

AMD plant die high bandwidth Anbindungen ja auch immer weiter zu verbessern und effizienter zu gestalten.
Und Interposer oder Fan Out Wafer Level Packacking würden den zusätzlichen Energiebedarf der Off-Chip Kommunikation stark abfedern.

Ich glaub mit FO-WLP würde sich die Kommunikation viel eher so verhalten, als wäre es ein ganzer Chip. Wenn zwischen den Chiplets kein Platz wäre und die Verdrahtung aufgedampft wird (+Lithographie),
fast so wie zusäzliche Layer in einem Chip selbst.
Aber vielleicht ist die Technik auch noch zu teuer für solch große Chiplet Gruppen in Masse.

https://images.anandtech.com/doci/15596/IF%20v1.jpg

[robbitop]

Ja mal sehen, wann das soweit ist, damit es in Massen günstig herstellbar ist, so dass es auch in günstigen consumer produkten noch vorteile bringt.

[vinacis_vivids]

Ja mal sehen, wann das soweit ist, damit es in Massen günstig herstellbar ist, so dass es auch in günstigen consumer produkten noch vorteile bringt.

Dann hast du genug Geld und steigst um oder was? 😂👌

[robbitop]

Dann hast du genug Geld und steigst um oder was? 😂👌
Ich weiß nicht, was das mit mir persönlich zu tun hat. Einkommen ist für mich persönlich kein Bottleneck für so etwas wie PC Hardwarekäufe. Aus Prinzip vermeide ich, Dinge zu konsumieren, die kein gutes P/L oder aber auch Kosten/Nutzen Verhältnis haben. Ich denke, das ist nicht der schlechteste Ansatz. ;)

Aber darum geht es ja hier nicht. Mir ging es eher um die Voraussetzung, damit GPU Chiplets im 3D Grafik Massenmarkt die unterm Strich bessere Lösung gegenüber monolitischen Ansätzen sind.

[vinacis_vivids]

Also wenn du das, was du schreibst, auch halbwegs auf dein eigenes Leben anwendest, dann bin ich ja eher verwundert wieso du noch nicht umgestiegen bist 😂

[|MatMan|]

Eine solche Patentanmeldung ist aber genauso wenig Resultat einer Idee nach drei Tagen brainstorming und das war es. Patentanmeldungen sind nicht nur stupide einfache Ideen, da steckt viel mehr dahinter. Muss es ja grundsätzlich auch, wenn man etwas patentieren lassen will. Stichwort u.a. Stand der Technik.

Funktionalität ist eine andere Geschichte, aber gerade bei technischen Erfindungen oftmals der Hintergedanke.
Doch, eigentlich sollte man nach dem Brainstorming direkt die Patentanmeldung machen. In großen Firmen gibt es dafür eine extra Abteilung (bei AMD gibt es das sicherlich auch). Der / die Erfinder müssen nicht viel mehr als die Idee und die Ansprüche / Claims liefern, den Rest macht zum Großteil die Abteilung. Das eigentliche Patent schreibt eh ein Patentanwalt, damit die Formulierung / Sprache auch passt. Ziel eines Patents ist es, Mitbewerber auszugrenzen, deshalb muss man da so schnell wie möglich sein. Sobald irgendjemand auf dieselbe Idee gekommen ist und das z.B. bei der Hot Chips als mögliche zukünftige Entwicklung aufführt, kann man es nicht mehr patentieren, da ja schon veröffentlicht.

Wenn du es erst quasi fertig entwickelst, testest ob es funktioniert und dann ein Patent schreibst, ist das Risiko viel zu groß, dass es schon jemand anders patentiert hat und somit die ganze Arbeit umsonst war.

Interpretiert nicht zu viel in Patente. Es ist teilweise hanebüchen was alles patentiert ist oder wie winzig manchmal die Erfindungshöhen sind.

[robbitop]

Also wenn du das, was du schreibst, auch halbwegs auf dein eigenes Leben anwendest, dann bin ich ja eher verwundert wieso du noch nicht umgestiegen bist ��
Du schreibst in Rätseln.

Doch, eigentlich sollte man nach dem Brainstorming direkt die Patentanmeldung machen. In großen Firmen gibt es dafür eine extra Abteilung (bei AMD gibt es das sicherlich auch). Der / die Erfinder müssen nicht viel mehr als die Idee und die Ansprüche / Claims liefern, den Rest macht zum Großteil die Abteilung. Das eigentliche Patent schreibt eh ein Patentanwalt, damit die Formulierung / Sprache auch passt. Ziel eines Patents ist es, Mitbewerber auszugrenzen, deshalb muss man da so schnell wie möglich sein. Sobald irgendjemand auf dieselbe Idee gekommen ist und das z.B. bei der Hot Chips als mögliche zukünftige Entwicklung aufführt, kann man es nicht mehr patentieren, da ja schon veröffentlicht.

Wenn du es erst quasi fertig entwickelst, testest ob es funktioniert und dann ein Patent schreibst, ist das Risiko viel zu groß, dass es schon jemand anders patentiert hat und somit die ganze Arbeit umsonst war.

Interpretiert nicht zu viel in Patente. Es ist teilweise hanebüchen was alles patentiert ist oder wie winzig manchmal die Erfindungshöhen sind.

Das ist sicherlich grundsätzlich richtig. Allerdings gab es gerade bei Grafik und AMD aktuell 2x Gegenbeispiele, die mir auf Anhieb einfallen. Die RT Beschleunigung in den TMUs (für Ray Casting) und den Infinity Cache. Beide Patente kamen zwar vor Release - aber nicht Jahre vorher.

[|MatMan|]

Das ist sicherlich grundsätzlich richtig. Allerdings gab es gerade bei Grafik und AMD aktuell 2x Gegenbeispiele, die mir auf Anhieb einfallen. Die RT Beschleunigung in den TMUs (für Ray Casting) und den Infinity Cache. Beide Patente kamen zwar vor Release - aber nicht Jahre vorher.
Ohne mir die beiden Patente genauer angeschaut zu haben, muss man stark unterscheiden, wann ein Patent erteilt, offengelegt oder angemeldet wurde. Für die Firma ist das Datum der Anmeldung maßgeblich (ab da läuft der Schutz, wenn es erteilt wird), dann hat das Patentamt Zeit zum Prüfen. 18 Monate nach der Anmeldung veröffentlicht das Patentamt in Deutschland das Patent (auch wenn die Prüfung noch nicht abgeschlossen ist, aber auch nicht früher). D.h. zumindest in Deutschland muss man auf den Zeitpunkt, zu dem ein Patent öffentlich wurde 1,5 Jahre (+ etwas Vorbereitung) drauf rechnen, um zu dem Zeitpunkt zu kommen, wann die Erfinder die Idee in etwa hatten. Ich weiß nicht wie die Fristen in den USA sind, aber sicherlich grob ähnlich. 1,5 - 2 Jahre sind in der Chipentwicklung schon ne Menge.

Und generell gibt es natürlich auch viele sinnvolle Patente, nicht nur Gedankenspiele.

[Leonidas]

Navi 31 Gerüchte:
https://www.3dcenter.org/news/hardware-und-nachrichten-links-des-22-januar-2021

Navi31 working silicon exists since early 2020.
Nothing I can confirm 100% now, but from what I know Navi 31 is a 80 CU chiplet and top SKU has 2 of them.

[mironicus]

Red Gaming Tech deutete an, daß die nächste RDNA3-Topkarte wohl um den Faktor 2,5 schneller sein soll als die RX 6900 XT. :D

[horn 12]

Nun, da möchte ich nicht den Preis kennen.
Wenn AMD ganz oben mitspielt, auch sicher 1300 bis 1500 Euro...
Mit Corona dann wenn noch immer mitläuft über 2000 Euro

[HOT]

Wird wohl so aufgebaut sein wie Matisse, I/O komplett ausgelagert mitsamt Teile des Frontendes und I$. Ansonsten kann ich mir kann ich mir das so kaum vorstellen.

[Iscaran]

80 CU pro Chiplet erscheint mir bisserl extrem.

Hätte eher 40 CU Chiplets erwartet. Navi2x ist ja schon so "halb-"Chiplettig aufgebaut. Die beiden 40er CUs sind über den Infinity Cache zu einem Chip verbunden.

Daher hätte ich erwartet, wird AMD im ersten "Chiplet" Schritt das beibehalten, nur eben die Kontroll-Logik/Infinity Cache komplett "verlagern" und verändern, so daß man dann eben die bisherigen (leicht angepassten) 40er CU als Chiplets dranlöten kann.

Demnach wäre die Top GPU evtl. so was wie 4x40 CU, 3x40 für high-end, 2x40 für "Refresh", und 1x40 für "low end".

[Cyberfries]

Oder weder 2x 80 noch 4x 40....

I don't think a design with 10240 cores can reach the perf goal
https://twitter.com/kopite7kimi/status/1352930006234591232

Sollte das bedeuten, dass die CU-Anzahl deutlich über 160 liegen soll? Oder 128ALUs je CU?
Chiplets sollten auch nicht zu klein werden, ~80mm² für Zen2 sind schon sehr gering.

[Der_Korken]

Alles oberhalb von doppelter N21-Performance halte ich für Quatsch. Erstens sind solche Sprünge mittlerweile die absolute Ausnahme und zweitens orientiert sich die Leistung letztendlich an dem, was die Effizienz hergibt. RDNA3 soll wieder 50% auf RDNA2 drauflegen, vermutlich größtenteils durch 5nm. Viel mehr wird es auch nicht, denn AMD hat gerade erst +50% aus dem selben Prozess, d.h. nur aus der Architektur rausgeholt. Da sind die tiefhängenden Früchte erstmal gepflückt, weitere Verbesserungen werden schwer.

RDNA2 hat auch nicht die 2,5- oder 3-fache Leistung gegenüber RDNA1 gebracht, auch wenn sich einige Leute das zusammenphantasiert haben mit verdoppelten CUs + 30% Takt + 15% IPC und 100% perfekter Skalierung. Die 6900XT istca. doppelt so schnell wie die 5700XT bei 33% mehr Verbrauch, also alles im Rahmen der +50% Effizienz. Würde man umgekehrt nun 160 CUs für RDNA3 erwarten, dann müsste der Verbrauch wieder um 33% steigen (=400W) und dann haben wir die Leistung aber noch gar nicht verdoppelt, weil die Leistung eben nicht perfekt mit Recheneinheiten skaliert. Die 6900XT braucht trotz doppelter Einheiten erheblich mehr Takt als die 5700XT um auf die doppelte Leistung zu kommen.

[mironicus]

Das wird NVidia gar nicht übertreffen können. :)

Genau wie mit der Bandbreite. Früher hat AMD geklotzt mit 512 Bit-Interfaces und HBM2-Speicher und jetzt verwenden sie den günstigsten GDDR6-Speicher und haben nur ein 256 Bit-Interface und sind konkurrenzfähig während NVidia den teureren und stromhungrigeren Speicher verwendet. Eine riesige Wende. :)

[vinacis_vivids]

Ausgehend von Navi 21 XTX
Vollausbau Navi31 Spekulazius
80CUs x 4 = 320CUs
5120SP x4 =20480SP
Coretakt ~ 2,25 Ghz
fp32 ~ 92,160 Tflop/s :eek:
Damit öffnet man die Tür für 8K Gaming.

Den L2 und den infinity Cache wird AMD sicher auch ausbauen
L2 Cache = 16MB
L3 Cache = 512MB (infinity Cache)

Speichersystem kann sogar 256bit breit bleiben und weiter mit 16GB pro SI bestückt werden. Dann landen wir bei 1024bit Busbreite und 64GB GDDR6(X)?
=> unwahrscheinlich, dass 64GB GDDR6(X) auf einer Platine gelötet werden, wie wir jetzt schon bei Nvidia 24GB sehen, also spricht alles für HBM SI.

Wenn wir uns den Speicher anschauen, hat die Radeon VII mit 4096bit das breiteste Interface und 1024GB/s die höchste Bandbreite im consumer Bereich.

Bei Navi31 wird sicherlich der HBM²E verwendet.

Spekulazius Speicher Navi 31
Speicher SI = 4096bit (4x 1024bit)
4x 8GB HBM²E stacks = 32GB HBM²E
Taktrate = 1200Mhz
Bandbreite = 1228GB/s

32GB weil die für Gamer völlig reichen, schön platzsparend und energiesparend, weil man will ja alles auf einer Platine bekommen und die 300-350W nicht überschreiten.

P.S.:
Ich kaufen mir eine :tongue:

Navi31 ist in der GPU uArch sowas wie "Zen" in der CPU uArch. Freut euch auf die Zukunft ;D

[Nightspider]

4+1 Chiplets? Blödsinn...

80 CU pro Chiplet erscheint mir bisserl extrem.

Hätte eher 40 CU Chiplets erwartet.

Was ist daran extrem? Was willst du mit zwei 40 CU Chiplets? Welchen Sinn soll das haben?

Vor allem in 5nm. Die Chiplets wären winzig, gerade weil der ganze IO Kram und Videoencoder usw ausgelagert sind.

[Der_Korken]

RDNA2 hat auch nicht die 2,5- oder 3-fache Leistung gegenüber RDNA1 gebracht, auch wenn sich einige Leute das zusammenphantasiert haben


Vollausbau Navi31 Spekulazius
80CUs x 4 = 320CUs
5120SP x4 =20480SP
Coretakt ~ 2,25 Ghz
fp32 ~ 92,160 Tflop/s :eek:

[...]

L2 Cache = 16MB
L3 Cache = 512MB (infinity Cache)

[...]

Dann landen wir bei 1024bit Busbreite und 64GB GDDR6(X)?

Genau das meinte ich :usad:

[Nightspider]

https://twitter.com/kopite7kimi/status/1352930006234591232

Sollte das bedeuten, dass die CU-Anzahl deutlich über 160 liegen soll? Oder 128ALUs je CU?
Chiplets sollten auch nicht zu klein werden, ~80mm² für Zen2 sind schon sehr gering.

Nein, das heißt einfach das keine 160 RDNA2 CUs reichen würden.

Die CUs müssen breiter sein, eine höhere IPC besitzen.

Ihr müsst auch mal sehen das die CUs in Navi21 vielleicht gerade mal ein Drittel der Fläche einnehmen. Der Infinity Cache nimmt bestimmt auch bald ein Drittel ein und der ganze IO und Video Kram den Rest.

Bei RDNA3 könnt ihr drauf wetten das die CUs ein gutes Stück größer werden. Alleine schon um die Effizienz zu verbessern.

Wie Korken schon richtig schreibt ist der Stromverbrauch ein limitierender Faktor.
Die Frage ist ob man bei den Topmodellen noch mehr Strom verballern lässt und Richtung 400W marschiert.

Auf jeden Fall kann man die Chiplets besser im Sweetspot betreiben, muss man aber nicht.

Wenn RDNA3 mit 5nm weiterhin so gut beim Takt skaliert wie RDNA2 in 7nm dann wird man alleine beim Takt schon 15-20% herausholen.
Dann braucht die IPC nur wenig steigen um mit 160 CUs auf den Faktor 2 bis 2,5 zu kommen.

[fondness]

RDNA3 soll wieder 50% auf RDNA2 drauflegen, vermutlich größtenteils durch 5nm.

Dazu gibt es noch keine Aussage.

[Sunrise]

80 CU pro Chiplet erscheint mir bisserl extrem.

Hätte eher 40 CU Chiplets erwartet. Navi2x ist ja schon so "halb-"Chiplettig aufgebaut. Die beiden 40er CUs sind über den Infinity Cache zu einem Chip verbunden.

Daher hätte ich erwartet, wird AMD im ersten "Chiplet" Schritt das beibehalten, nur eben die Kontroll-Logik/Infinity Cache komplett "verlagern" und verändern, so daß man dann eben die bisherigen (leicht angepassten) 40er CU als Chiplets dranlöten kann.

Demnach wäre die Top GPU evtl. so was wie 4x40 CU, 3x40 für high-end, 2x40 für "Refresh", und 1x40 für "low end".
IMHO nimmt man eher zwei 80er Chiplets um ein Performance-Ziel (min. 70-100% schneller) zu erreichen, statt 4x40. Das Zweite wäre bei der Verdrahtung auch viel komplexer und die 40er Chiplets wären unter 5nm wohl viel zu klein, wenn man bedenkt, dass da dann wirklich nur noch die CUs drin sind.

Mal davon ab, dass so ein Konzept ja vollkommen neu ist und die Kontrolllogik auch nicht unerheblich sein wird.

[Iscaran]

Was ist daran extrem? Was willst du mit zwei 40 CU Chiplets? Welchen Sinn soll das haben?

Vor allem in 5nm. Die Chiplets wären winzig, gerade weil der ganze IO Kram und Videoencoder usw ausgelagert sind.

So winzig auch wieder nicht. Mit der aktuellen Fertigung sind die 40 CUs AFAIK so ca 98 mm^2 groß. der ganze I/O kram ist da noch nicht mit drin. Das sind wirklich nur die Core-Einheiten.

mit 5nm sind wir dann um wieviel Prozent in der Fläche besser ? 33% ?

=> 97.8/1.33 = 74 mm^2.

Passt doch ziemlich gut für ein Chiplet. Der Core-Die mit dem I/O kram und Infinity Cache wäre dann 230mm^2/1.33 = ca 170 mm^2 groß.

4x74 + 170 = 466 mm^2 für das ganze Ding (sehr grob überschlagen)

[fondness]

Viele unterschätzen glaube ich auch, wie klein die CUs sind im Vergleich zum restlichen Chip. Bei Navi21 machen die CUs grob geschätzt 1/3 vom Chip aus, sofern der veröffentliche Die-Shot akkurat ist. Das liegt natürlich auch am großen Cache. Bei 536mm² Die Fläche wären das also ca. 176mm² für 80CUs in 7nm. In 5nm wird man da für 80CUs nur etwas über 100mm² landen. Vermutlich wird am Chiplet auch etwas Kontrollogik landen, sodass es dann trotzdem mehr sein wird, aber nur zur Einordnung.

[Iscaran]

IMHO nimmt man eher zwei 80er Chiplets um ein Performance-Ziel (min. 70-100% schneller) zu erreichen, statt 4x40. Das Zweite wäre bei der Verdrahtung auch viel komplexer und die 40er Chiplets wären unter 5nm wohl viel zu klein, wenn man bedenkt, dass da dann wirklich nur noch die CUs drin sind.

Genau das ist ja der Punkt, wenn man wirklich auf Chiplets geht, dann ist (zumindest bis zu einem gewissen "geometrischen" Limit die Verdrahtung etc. kein Ding.

Ich nehme an, man wird die Verdrahtung über den Inf.Cache machen - an den dann der Kontroll und I/O Die drangebunden ist. Dann ist es nur noch ein Frage der Geometrie wieviel Chiplets man drumherum Anordnen kann. Das wird nicht wirklich komplexer als bei Zen. Und genau damit hat AMD schon ziemlich viel Erfahrung.

[Nightspider]

mit 5nm sind wir dann um wieviel Prozent in der Fläche besser ? 33% ?


TSMC gibt Faktor 1,84 bei der Dichte an.

Was willst du denn mit Chiplets die so klein sind?

Wie bereits gesagt wurde steigt der Verdrahtungsaufwand ja nur unnötig extrem an.
Deswegen wird es auch erstmal nur 2 Logik Chiplets geben.

Die Frage ist auch ob der Infinity Cache im IO Chiplet landen wird. Denn dadurch wird der Weg ja wieder länger.
Bei Zen 2 und Zen 3 hast du ja auch den L3 Cache nicht im IO Die.

[Sunrise]

So winzig auch wieder nicht. Mit der aktuellen Fertigung sind die 40 CUs AFAIK so ca 98 mm^2 groß. der ganze I/O kram ist da noch nicht mit drin. Das sind wirklich nur die Core-Einheiten.

mit 5nm sind wir dann um wieviel Prozent in der Fläche besser ? 33% ?

=> 97.8/1.33 = 74 mm^2.

Passt doch ziemlich gut für ein Chiplet. Der Core-Die mit dem I/O kram und Infinity Cache wäre dann 230mm^2/1.33 = ca 170 mm^2 groß.

4x74 + 170 = 466 mm^2 für das ganze Ding (sehr grob überschlagen)
33% ist viel zuwenig. Offiziell für SRAM bzw. sehr simpler Logik sind es laut TSMC (5nm vs. 7nm) ein Faktor von 1.84x, also dann eher 0,84. Das ist zwar unrealistisch, aber man wird auf jedenfall um die 50-60% bessere Dichte erreichen.

PS: Nightspider war schneller.

[davidzo]

Oder weder 2x 80 noch 4x 40....


https://twitter.com/kopite7kimi/status/1352930006234591232

Sollte das bedeuten, dass die CU-Anzahl deutlich über 160 liegen soll? Oder 128ALUs je CU?
Chiplets sollten auch nicht zu klein werden, ~80mm² für Zen2 sind schon sehr gering.


80CU für Navi31 ist docheigentlich durch die Treiberleaks schon confirmed?!

Wenn der Chip dann auch in 5nm kleiner ist und 50% energieeffizienter, machen 2 Chiplets für die Top SKUs einfach am meisten Sinn. Mehr ist für einen relativ kurzen Generationensprung einfach nicht realistisch in bezug auf Formfaktor, Power etc.

Alles oberhalb von doppelter N21-Performance halte ich für Quatsch. Erstens sind solche Sprünge mittlerweile die absolute Ausnahme und zweitens orientiert sich die Leistung letztendlich an dem, was die Effizienz hergibt. RDNA3 soll wieder 50% auf RDNA2 drauflegen, vermutlich größtenteils durch 5nm. Viel mehr wird es auch nicht, denn AMD hat gerade erst +50% aus dem selben Prozess, d.h. nur aus der Architektur rausgeholt. Da sind die tiefhängenden Früchte erstmal gepflückt, weitere Verbesserungen werden schwer.

Naja, an den CUs hat man bei RDNA2 praktisch nichts gemacht, nur BVH Traversal fähig gemacht und das SI und cachesystem radikal erneuert. Ich fände es eher erwartbar dass man diesmal dort die low hanging fruits absammelt, gerade weil man das bei der letzten Architektur noch nicht gemacht hat. Ich erwarte also durchaus einen IPC Schub pro CU für Navi31.


RDNA2 hat auch nicht die 2,5- oder 3-fache Leistung gegenüber RDNA1 gebracht, auch wenn sich einige Leute das zusammenphantasiert haben mit verdoppelten CUs + 30% Takt + 15% IPC und 100% perfekter Skalierung.

Vorsichtig, ich würde nicht davon ausgehen das sich solche frühen Targets wie jetzt bei Navi31 auf letztendliche Gaming-Skalierung beziehen. Die theoretische Leistungssteigerung, die bei optimaler Programmierung, Auflösungswahl, etc. auch abrufbar ist und die praktische die sich in einem Launch Benchmark-parcour aus z.T. Jahre alten Spielen ergibt, sind zwei paar Schuhe. Solche Vorab-Infos beziehen sich wohl kaum auf Launch-review Benchmark parcours, sondern wohl eher auf theoretische Hochrechnungen. Dafür wären die Treiber gar nicht ready um solche Aussagen zu machen. Selbst mit sehr guter FPGA Simulation bekommst du da nur ein sehr theoretisches Bild von der IPC.

Und da ist Navi21 sehr wohl 2,2-2,5mal schneller als Navi10.


Die 6900XT istca. doppelt so schnell wie die 5700XT bei 33% mehr Verbrauch, also alles im Rahmen der +50% Effizienz. Würde man umgekehrt nun 160 CUs für RDNA3 erwarten, dann müsste der Verbrauch wieder um 33% steigen (=400W) und dann haben wir die Leistung aber noch gar nicht verdoppelt, weil die Leistung eben nicht perfekt mit Recheneinheiten skaliert. Die 6900XT braucht trotz doppelter Einheiten erheblich mehr Takt als die 5700XT um auf die doppelte Leistung zu kommen.

5700XT auf 6900XT war im selben Node.
Aber ja, ich erwarte auch nicht dass zwei 80CU 5nm Chiplets + MCD sparsamer sind als ein 80CU Chiplet in 7nm.
Allerdings kann man von 5nm schon +50% Effizienz und leicht höhere Taktraten erwarten. Nicht zu vergessen geht ein Großteil der Energie aktueller GPUs für den Speichercontroller und das breite SI drauf. Mehr Infinitycache on Chip/Chiplet ist also eine einfache Methode um die Energieeffizienz weiter zu steigern.

Toll wäre wenn AMD außerdem die Raytracingleistung auf CU-Ebene anhebt, dann würde das gepaart mit dem Mehrtakt schon reichen um mehr als die doppelte Leistung aus 160CUs vs 80Cus zu holen. Im Gegensatz zu Geforce Ampere skaliert Navi21 schon jetzt besser pro CU und sehr gut mit dem Takt.

[Nightspider]

Das wird nicht wirklich komplexer als bei Zen.

Dann hätten wir schon lange GPU mit Chiplets. ;)

33% ist viel zuwenig. Offiziell für SRAM bzw. sehr simpler Logik sind es laut TSMC (5nm vs. 7nm) ein Faktor von 1.84x, also dann eher 0,84. Das ist zwar unrealistisch, aber man wird auf jedenfall um die 50-60% bessere Dichte erreichen.

PS: Nightspider war schneller.

Er meinte wohl mit 33% die Flächenersparnis.

Wäre bei Scaling 1,84x eine Ersparnis von 45,86%.


Vorsichtig, ich würde nicht davon ausgehen das sich solche frühen Targets wie jetzt bei Navi31 auf letztendliche Gaming-Skalierung beziehen. Die theoretische Leistungssteigerung, die bei optimaler Programmierung, Auflösungswahl, etc. auch abrufbar ist und die praktische die sich in einem Launch Benchmark-parcour aus z.T. Jahre alten Spielen ergibt, sind zwei paar Schuhe. Solche Vorab-Infos beziehen sich wohl kaum auf Launch-review Benchmark parcours, sondern wohl eher auf theoretische Hochrechnungen. Dafür wären die Treiber gar nicht ready um solche Aussagen zu machen. Selbst mit sehr guter FPGA Simulation bekommst du da nur ein sehr theoretisches Bild von der IPC.

Und da ist Navi21 sehr wohl 2,2-2,5mal schneller als Navi10.

Guter Punkt.


Nicht zu vergessen geht ein Großteil der Energie aktueller GPUs für den Speichercontroller und das breite SI drauf. Mehr Infinitycache on Chip/Chuplet ist also eine einfache Methode um die Energieeffizienz zu steigern.


Welcher Fertigungsprozess würde denn eurer Meinung nach für das IO Die in Frage kommen?
Bei günstigerem und effizienteren Fertigungsprozess könnte man eventuell das SI ja wieder etwas breiter machen und würde etwas Die Area sparen.
Nicht auf das Niveau von RDNA1 aber vielleicht bräuchte man dann nicht mehr 30% des Platzes nur für den Infinity Cache.

[Der_Korken]

Dazu gibt es noch keine Aussage.

https://www.thestreet.com/investing/amds-rick-bergman-talks-about-current-and-next-gen-cpus-and-gpus

Ja, ist schon etwas reininterpretiert von der Seite, aber da habe ich das mit den 50% für RDNA3 zumindest her.

Viele unterschätzen glaube ich auch, wie klein die CUs sind im Vergleich zum restlichen Chip. Bei Navi21 machen die CUs grob geschätzt 1/3 vom Chip aus, sofern der veröffentliche Die-Shot akkurat ist. Das liegt natürlich auch am großen Cache. Bei 536mm² Die Fläche wären das also ca. 176mm² für 80CUs in 7nm. In 5nm wird man da für 80CUs nur etwas über 100mm² landen. Vermutlich wird am Chiplet auch etwas Kontrollogik landen, sodass es dann trotzdem mehr sein wird, aber nur zur Einordnung.

Dass die CUs selbst wenig Platz brauchen, ist natürlich richtig, aber das heißt ja noch lange nicht, dass die Leistung leicht gesteigert werden kann, indem man den CU-Anteil am Chip einfach erhöht. Zum einen läuft man in Auslastungsprobleme (Fiji) und auch in Bandbreitenprobleme, d.h. der Infinity Cache muss zwingend mitwachsen. AMD hat mit RDNA eine 180-Grad-Wende gemacht, weg vom Rohleistungsmonster, hin zu einer guten Auslastung der Recheneinheiten.

Naja, an den CUs hat man bei RDNA2 praktisch nichts gemacht, nur BVH Traversal fähig gemacht und das SI und cachesystem radikal erneuert. Ich fände es eher erwartbar dass man diesmal dort die low hanging fruits absammelt, gerade weil man das bei der letzten Architektur noch nicht gemacht hat. Ich erwarte also durchaus einen IPC Schub pro CU für Navi31.


Auf Transistorebene hat AMD durchaus einiges gemacht, die Taktraten sind deutlich höher bzw. die benötigte Spannung für gleiche Taktraten deutlich geringer.

Vorsichtig, ich würde nicht davon ausgehen das sich solche frühen Targets wie jetzt bei Navi31 auf letztendliche Gaming-Skalierung beziehen. Die theoretische Leistungssteigerung, die bei optimaler Programmierung, Auflösungswahl, etc. auch abrufbar ist und die praktische die sich in einem Launch Benchmark-parcour aus z.T. Jahre alten Spielen ergibt, sind zwei paar Schuhe.


OK, das ist ein guter Punkt. Allerdings hatte ich wie oben beschrieben den Eindruck, dass AMD seit RDNA ihre Lektion über Rohleistungsmonster gelernt hat und sich mehr drauf konzentriert, auch in der Prais mehr Leistung aus ihren Chips rauszuholen.

[Nightspider]

Eine Übersicht der Effizienzssteigerungen aller Generationen wäre mal interessant.
Müsste nur irgendwie genormt sein, weil es ja abhängig davon ist bei welchem Takt man misst.

[Iscaran]

Er meinte wohl mit 33% die Flächenersparnis.

Wäre bei Scaling 1,84x eine Ersparnis von 45,86%.


Ja genau. Dann rechnen wir eben mit 46% ersparnis

Basierend auf den 98 mm^2 für 40 CUs in N21
=> 98/1.46 = 67 mm^2

Das ist doch nicht "winzig". OK Riesig ist es auch nicht aber die CPU-Teile bei den Zens sind doch auch nur 70-80 mm^2
oder stimmen die angaben hier nicht ?
https://www.reddit.com/r/Amd/comments/9uskmh/zen_2_die_size/

[Nightspider]

Je nachdem was man als winzig definiert aber es macht halt keinen Sinn.

Die Yields sind bei CPUs aber wichtiger als GPUs weil man problemloser einzelne Cus bei Grafikchips abschalten kann und die GPUs meistens nach den CPUs in einen neuen Fertigungsprozess kommen.

GPUs waren schon immer größer als CPUs.

[Iscaran]

Ja der ganze GPU Die ist ja dann 4*67 + den I/O /SI- und Core Bereich.
Bei N21 sind das auch immerhin 150mm^2 dazu noch der IC mit 100m^2.

Selbst wenn wir diese auch mit 46% schrumpfen sind das ca 100mm^2 + 68mm^2

Und der IC wird bei einem 4x40 Chiplet vermutlich auch ca x2 größer werden müssen, womit man wieder bei 68*2 + den I/O-SI-Corelogic-Teil von mindestens 100mm^2 ist. (

Der Corelogic/IO-Teil wird vermutlich sogar relativ zu N21 größer ausfallen, da er ja ein paar Aufgaben übernehmen muss.

4*67 + mind. 100 + 136mm^2 = 504 mm^2 Die und da sind "ungechippedte" Zwischenbereiche zwischen den Komponenten noch gar nicht eingerechnet. Wobei ich annehmen würde, dass man die Lücken, Restfläche mittels des ICs zukleistert.

Der Vorteil liegt auf der Hand 80 CU-Chiplets sind zu groß um damit die Produktkategorie bis ins Low-end abzudecken. Mehrere unterschiedliche CU-Chiplets aufzulegen kostet aber wieder Geld...für extra Masken und Fertigunsdesign etc.
Aber mit einem 40 CU Chiplet, das zudem bereits auf N21 "aufbauen" kann hat man eine Win-Win-Situation.

Mit 4x40 hat man den Enthusiast Chip. Mit 3x40 den Performance chip mit 2x40 legt man einen "Refresh" der 6800/6900 hin. mit 1x40 legt man den low-end Bereich auf.

Weitere Abstufungen kann ja mittels Teildeaktivierung der CUs bilden.

Evtl. Sieht man ja auch ein 48CU Chiplet. Das aber praktisch NIE voll genutzt wird (z.B. max 40 von 48 CUs genutzt).

[Nightspider]

Der Low-end Bereich wird ganz einfach mit den Chips abgedeckt, die auch in Laptops verbaut werden, also mit monolithischen Chips. Siehe Renoir.

[amdfanuwe]

Mit 4x40 hat man den Enthusiast Chip. Mit 3x40 den Performance chip mit 2x40 legt man einen "Refresh" der 6800/6900 hin. mit 1x40 legt man den low-end Bereich auf.

Und für jeden Bereich gibt es ein eigenes IO-Die? Wäre doch ziemlich verschwenderisch den IO mit dickem SI auch im low-end Massenmarkt einzusetzen.

[davidzo]

Eine Übersicht der Effizienzssteigerungen aller Generationen wäre mal interessant.
Müsste nur irgendwie genormt sein, weil es ja abhängig davon ist bei welchem Takt man misst.

Wenn du Marketing magst kannst du dir mal AMDs Projekt 25x20 anschauen. Das geht wenigstens bis Renoir: https://www.anandtech.com/show/15881/amd-succeeds-in-its-25x20-goal-renoir-zen2-vega-crosses-the-line-in-2020


Btw, ich finde Navi31 ist doch jetzt schon sehr deutlich:
- Wir haben Treiberleaks die auf 80CU/chiplet hindeuten, bei weitgehend identischer Konfiguration wie Navi21.
- Es geistern die Namen GCD / Graphics Complex Die und MCD Memory Complex Die herum.
- Navi21 benötigt für 80CUs nur 512gb/s off Chip um gut zu skalieren. In 5nm kann man mehr IF$ verbauen und den Offchip Bandbreitenbedarf noch weiter senken. Man kommt da fast in CPU Regionen, schon jetzt ist Navi21 L3cache +256bit gut vergleichbar mit einem Epyc Cache + 8ch SI was die bandbreite angeht. Und Latenz ist wohl egal für GPUs, insbesondere wenn man schnellen onchip cache hat.


Kombiniert man das mit der Langzeit-Strategie von AMD und Technologie die wir aus dem CPU-Bereich kennen sowie dem Datacenter, dann läuft das auf eine recht klare Auflösung hin:
- Navi31 basiert auf der Infinity Architecture. Bisherige Infinity Fabric Links hatten nicht genug Bandbreite. Aber da sich die IF-link Bandbreite ca. alle 2 Jahre verdoppelt hat und gleichzeitig mit RDNA2 und Infinitycache der Offchip Bandbreitenbedarf gesunken ist, kommt nun in 2021-22 der Zeitpunkt wo es für Gaming GPUs tauglich wird.
- Cache Coherency bzw. shared memory ist AMDs Langzeit Entwicklungsprojekt. HSA, lange angekündigt und mit vielen Partnern gestartet hat sich letztendlich in Infinity Fabric materialisiert. Und das wird nicht nur von den APUs genutzt um ihre GPU anzubinden, sondern auch im Datacenter.
- Die Instinct Mi-60 hat bereits einen Infinity Fabric Link mit 100gbps (bi direktional?)
- Bei Apples Vega II pro Duo sind es immerhin 86gb/s (wird hier PCIgen3 genommen oder nur ein link?)
- In der Radeon Pro VII sind immerhin beide IF links mit 168gb/s verfügbar.
- Vega20 ist afaik Infinity Fabric 2.0 basiert, was auf PCIeGen4 basiert und ca. 30% schneller ist als PCIeGen4.
- Laut Datacenter Präsentation soll Infinity Fabric 3.0 ca. 20% schneller sein als PCIe Gen5. Das wären für ein Link ca. 200-300gb/s
- Für ein 80CU Chiplet bräuchte man also 2x Links um eine Bandbreite um die 500gb/s zu erreichen.
- Kurioserweise hat bereits Navi21 einen Infinity Fabric + cache controller der Zwischen den 128MB IF$ und den beiden xGMI Links liegt.
- Die xGMI Infinity Links in Navi21 liegen in der Consumervariante brach
- Die Navi21 xGMI Links dürften der Version IF Gen2 entsprechen, also maximal 100gb/s pro Link schaffen wie bei Vega20.
- verdoppelt man die Bandbreite pro Link kommen wir langsam in den Bereich der Bandbreite die auch Navi31 für 80CUs benötigt.
- TSMC mag bei der Prozessdichte etwas zu viel Marketing betreiben, aber der N7 Prozess ist schon jetzt der non-EUV Prozess mit der besten packdichte für SRAM Zellen, zumal zusätzlich noch 6T Zellen verfügbar sind die AMD auch extensiv nutzt. TSMC ist bei der SRAM Packdichte (0,027) weit vor Intel 10nm (0,032) und Samsung 8nm, insofern macht das für AMD nur Sinn diesen Vorteil auszunutzen.
- In 5nm Baut TSMC den SRAM Vorteil aus und bietet mit 0,017-0,019 nochmal kleinere SRAM Zellen während alle vergleichbaren Prozesse bei SRAM eher stagnieren.
- Man darf also damit rechnen dass AMD den InfinityCache in 5nm noch weiter ausbaut.

https://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=73820&stc=1&d=1611508018
https://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=73821&stc=1&d=1611508103
https://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=73817&stc=1&d=1611507841
https://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=73818&stc=1&d=1611507841
https://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=73819&stc=1&d=1611508018


Ich rechne daher mit einem ähnlichen Aufbau:

GCD:
- ca. 200mm2 @ 5nm TSMC
- 80CU Chiplets wie Navi21 nur ohne SI, VCE, PCIe
- 128-256mb IF$
- 2x-4x Infinity Fabric Links mit 400-800gb/s
- 2,5-3,2 Ghz
- TDP ca. 100Watt

MCD:
- ca. 150mm2 @ 12FDX GF
- SI, VCE, PCIe Gen5
- 256-384bit GDDR6
- 4x-8x Infinity Fabric Links mit 800-1600gb/s
- TDP ca. 50Watt

Package:
- TSMC Info-LSI 2.5D ohne Interposer
- 2x GCD +1x MCD
- 1x GCD + 1x MCD


Daraus kann man dann gut zwei SKUs bauen, analog zu Matisse und Vermeer single CCD und dual CCD Prozessoren.

Rest Refresh navi22, 23, 24.

BTW, hatte gehört Navi23 oder 24 seien gar nicht 7nm TSMC. Eventuell nimmt AMD hier nochmal 12nm GF oder 14/10/8nm Samsung um die Kapazitäten zu schonen?

[Nightspider]

Klingt soweit schlüssig, guter Beitrag.

Ich hoffe mal das AMD und NV in Zukunft auch endlich den Strombedarf bei Verwendung von mehr als 1 oder 2 Monitoren in den Griff bekommen.
Vielleicht hilft da ein IO-Chip im LP Prozess.


BTW, hatte gehört Navi23 oder 24 seien gar nicht 7nm TSMC. Eventuell nimmt AMD hier nochmal 12nm GF oder 14nm Samsung um die Kapazitäten zu schonen?

14nm Samsung würde doch wenig Sinn machen oder?
Was wäre mit Samsung 12nm,8nm und 7nm?

Wenn AMD die Kapazitäten schon vor 1~1,5 Jahren gebucht haben sollte würde das ja nicht den aktuellen Engpässen bei Ampere kollidieren.
Und wenn die Navi 23 und 24 erst im 2. Quartal kommen wäre das ja weit genug in der Zukunft für 7nm EUV bei Samsung oder?

Kommt bei GloFo eigentlich nochmal was nach 12nm? :ugly:

[amdfanuwe]

Navi 24 als Testchip für Samsungs eigene SOC mit Navi iGPU?

[reaperrr]

Kommt bei GloFo eigentlich nochmal was nach 12nm? :ugly:
Was Performance-Prozesse angeht: Nein. Denen war die Entwicklung von 7nm usw. zu teuer für das voraussichtliche Volumen.

Maximal kommt nach 12LP+ noch ein 12LP++ oder 11LP, aber das sind dann alles nur weitere Optimierungen der gleichen Grundlage ohne gravierende Änderungen. GloFo konzentriert sich ansonsten auf SOI (22FDX, 12FDX) und ältere Prozesse (die für manche Zwecke auch heute noch ausreichen und deshalb entsprechend nachgefragt werden, ohne noch Unsummen an R&D zu schlucken).

[robbitop]

Glofo scheint auf fd-soi Prozesse für IoT und Analogtechnik/Modems umgestiegen zu sein. Bleeding Edge konnte man kaum mithalten und in der Regel nicht genug Marge machen, damit unterm Strich etwas dabei herausgekommen ist. 22FDX jetzt und 12FDX in ~2 Jahren.
GF ist im Prinzip raus aus dem Rennen für HP Prozessen.

Keine Ahnung ob die FDX Prozesse nicht auch was für IODs wären. Da ist vieles I/O was eh praktisch nicht mit Shrinks skaliert. FD SOI könnte da zumindest bei der Leistungsaufnahme helfen.
Außerdem könnte man dank SOI auch 1T SRAM verbauen. Damit bekommt man massiv mehr Speicherdichte hin. Ggf ist das für einen IOD für GPUs ja interessant?

@Stromverbrauch Dualmonitor. Nicht ideal aber im Desktop doch fast egal.

[Lehdro]

@Stromverbrauch Dualmonitor. Nicht ideal aber im Desktop doch fast egal.
Da dieselben GPUs aber auch im Notebookmarkt eingesetzt werden, ist das aber sehr ärgerlich. Da stört die Leistungsaufnahme bei mehreren Monitoren (was dann fast zwangsläufig eh stationär ist -> kein Akkubetrieb) auch, allerdings ist der primäre Störfaktor die daraus entstehende Abwärme. Da die passive Kühlleistung arg limitiert ist kann das im reinen Desktopbetrieb ein Ende der Ruhe bedeuten, da die Lüfter ab und an für Abkühlung sorgen müssen, weil sich der Grafikspeicher zu sehr aufheizt. Das kann ich so zumindest vom Dell G5 15 SE mit RX5600M berichten, dort tritt der Fall nämlich auf, da der GDDR6 die ganze Zeit auf vollem Takt läuft, sobald externe Monitore angeschlossen werden.

[robbitop]

Das ist in dem Fall natürlich unschön- das kann ich nachvollziehen.

[Unicous]

GF konnte nicht mithalten, weil die Hochwohlgeborenen aus dem Nahen Osten nicht checken, dass Halbleitertechnologie nicht automatisch zur eierlegenden Wollmilchsau wird wenn man einmal den Futtertrog füllt und eine Schale Wasser hinstellt.

Das war die einzige Strategie die man noch verfolgen konnte, weil ATIC bzw. Mubadala nicht bereit sind mehrere Milliarden pro Jahr in das Unterfangen zu pumpen. Die Fab in China wurde ja auch letztes Jahr einstampft. Die hätte mindestens 10 Milliarden Dollar gekostet.
GF wurde von seinen Geldgebern auf Lebenserhaltung umgestellt und die ersten Fabs wurden auch schon verkauft.
Es fehlt nicht an Expertise, GF hat sogar ein weitreichendes Lizenzabkommen mit TSMC, es fehlt vor Allem an Geld. Viel Geld. Vielen, vielen Milliarden.

FD-SOI dürfte dafür im Übrigen zu teuer sein vom Kosten/Nutzen-Faktor. Der/die Chips wären viel zu groß und können auch in Zukunft nicht auf ein akzeptables Maß geshrinked werden, weil GF nicht in 7nm o.ä. investiert und die Waferkosten sind im Vergleich zu 16/14/"12"nm ähnlich hoch. Zudem ist 12FDX eh missing in action und das noch für eine längere Zeit so scheint es.

[Hakim]

@Stromverbrauch Dualmonitor. Nicht ideal aber im Desktop doch fast egal.

Mir persönlich ist das wichtig, bei mir läuft der PC oft Tagelang, da will ich net unnötig nonstop ~30W mehr verbrauchen statt die 30w mehr unter Volllast.

[Nightspider]

Dualmonitor geht ja mittlerweise fast aber bei 3 Monitoren wird es übel.

[robbitop]

Naja die Investoren haben ~10 Jahre Geld in GF gepumpt. Irgendwann will man als Investor auch mal Return sehen. Das hat GF halt nicht geschafft. Dann wurde das Geld abgedreht.

Die IODs sind doch zum Großteil IO. Das shrinkt eh praktidch nicht. Entsprechend sollte 22 FDX von der Größe nicht im Nachteil sein. Sollte Cache gebraucht werden ist 1T SRAM auf 22fdx sicherlich konkurrenzfähig ggü 6/8T auf modernen Prozessen.

——-

Mir persönlich ist der erhöhte Idleverbrauch von delta 30W oder so komplett egal. Bezogen auf die Gesamtstromrechnung und den Anteil der Nutzungsdauer im Idle sind das Peanuts.

[Unicous]

Nein, sie haben lediglich Geld für das laufende Geschäft bereitgestellt und nicht als eine langfristige Investitionen verstanden.

Einen Prozess zu entwickeln, zur Marktreife zu bringen und dann daraus ein Produkt zu machen verschlingt Abermilliarden und das war ATIC/Mubadala von Anfang an nicht bereit zu investieren. Sie verstehen das Geschäft nicht. Das hat nichts mit ROI Ansprüchen zu tun und man sollte diese Inkompetenz seitens Mubadala auch nicht schönreden. Es wurde spätestens als AMD ausstieg (das war vor bereits 8 Jahren) klar, dass sie keinen blassen Schimmer von dieser Investition haben und dachten, sie würden den Halbleitermarkt beherrschen wenn sie einmalig ein paar Milliarden Öl-Dollar investieren. Ein Jahr zuvor hatten sie noch großspurig Milliarden versprochen und clever, smart und vorausschauend wie sie sind eine eigene Fab in Abu Dhabi in Aussicht gestellt. Das ist verpufft, genau wie die Milliarden die sie investieren wollten. ;)
Diese Milliarden vor 8-9 Jahren hätten der ausschlaggebende Zünder sein können, GF zu "retten". Stattdessen haben sie den Hahn zugredreht und lieber das Geld wie gießkannenartig in joint ventures und startups gegossen.

Nicht dabei vergessen darf man, dass ihre eigenen Leute in den Vorstand gepflanzt haben (5 der 10 Mitglieder sind Teil von Mubadala ohne Halbleiter-Background, der Rest vor Allem Finanz-/Investmentheinis) und Personalentscheidungen beeinflussen. Die Leute sind natürlich nicht dumm, aber haben eben auch keine Ahnung vom Halbleitergeschäft.

GF hatte das Potential zu einem global player in direkter Konkurrenz zu TSMC und Samsung, es fehlte allein der (finanzielle) Wille und die Vision und wie gesagt ein generelles Verständnis was das Halbleitergeschäft ausmacht.

Wir steuern auf ein Duopol zu, ich bin nicht überzeugt, dass Samsung mittelfristig die Kurve bekommt.


edit:

Wie groß bzw klein, denkst du denn wäre ein IOD Chip@22FDX, wenn das Ding jetzt schon riesengroß ist?:confused:

Nur noch mal zur Info: Der "Ryzen" IOD ist 125mm² groß und der "Epyc" IOD ist gigantische 416mm² groß. Daraus werden jetzt nicht automatisch 800mm², weiß jetzt auf die Schnelle nicht wie das skalieren würde, aber dennoch wäre das kein kleiner Chip der zudem auch Platz auf dem Package verbraucht. Und zudem ist FinFET keine Stromverschwendertechnologie, im Gegenteil. ;)

[reaperrr]

Sollte Cache gebraucht werden ist 1T SRAM auf 22fdx sicherlich konkurrenzfähig ggü 6/8T auf modernen Prozessen.

Ob das auch auf Taktbarkeit für höhere Performance-Ansprüche zutrifft, da bin ich gelinde gesagt skeptisch.

Aber ich gehe fest davon aus, dass die Igenieure von AMD mehr Ahnung von dem Thema haben als wir. Wenn die für den NextGen-IO-Die TSMC N7 statt eines GloFo-Prozesses nehmen sollten, werden die gute Gründe dafür haben.

[HOT]

Ist doch quatsch auf 22fdx zu setzen, wenn man 12lp+ nutzen kann. 12fdx braucht eh noch bis weit in 22 hinein. Ein weiteres Hindernis ist der Vertrag mit St Micro, der FDSOI auf die Dresdener Werke beschränkt. Ich halte FDSOI für das IOD für Quatsch.

Als Weiteres denke ich, dass das IOD mehr sein muss als nur I/O, da müssen Teile des Frontendes rein um nicht in die Probleme zu laufen, die bisherige Multi GPU Systeme haben. Das Ganze muss transparent als Einheit funktionieren, sonst kann man das gleich lassen. AMD plant da nicht umsonst so enorm viel Entwicklungsarbeit rein, wenn die Grafik Chiplets schon seit Anfang 20 existieren gibt's da keinen großen Architektusprung im Sinne vom reinen RDNA, aber eben offenbar beim Ausbalancieren der Chips, Träger und Latenzen.

[robbitop]

Ob das auch auf Taktbarkeit für höhere Performance-Ansprüche zutrifft, da bin ich gelinde gesagt skeptisch.

Aber ich gehe fest davon aus, dass die Igenieure von AMD mehr Ahnung von dem Thema haben als wir. Wenn die für den NextGen-IO-Die TSMC N7 statt eines GloFo-Prozesses nehmen sollten, werden die gute Gründe dafür haben.
Schau dir die PowerCPUs an. Die nutzen das seit vielen Jahren als L3 Cache. Bei sehr hohen Taktraten. ~5 GHz.
Der FD-SOI Prozess kommt ja von IBM. Genau diese Kombination wurde ja schon mehrfach umgesetzt.



Wie groß bzw klein, denkst du denn wäre ein IOD Chip@22FDX, wenn das Ding jetzt schon riesengroß ist?:confused:

Nur noch mal zur Info: Der "Ryzen" IOD ist 125mm² groß und der "Epyc" IOD ist gigantische 416mm² groß. Daraus werden jetzt nicht automatisch 800mm², weiß jetzt auf die Schnelle nicht wie das skalieren würde, aber dennoch wäre das kein kleiner Chip der zudem auch Platz auf dem Package verbraucht. Und zudem ist FinFET keine Stromverschwendertechnologie, im Gegenteil. ;)

Soweit ich das verstanden habe, haben analoge Schaltungen völlig andere Randbedingungen als digitale. Bei I/O ist halt viel Analogkram dabei.
FinFET ist sehr gut für hohe Taktraten für digitale Schaltungen, damit der Verbrauch im Rahmen bleibt. FD-SOI ist für Analogkram wohl extremst gut um den Verbrauch zu senken. Und wie gesagt, skaliert Analogkram praktisch nicht mit der Fertigungsstruktur. Entsprechend würde ich keine große Erhöhung der IOD Größe annehmen.

Zumal man nicht vergessen darf:
GF's 12 nm ist 14 nm optimiert - Flächeneinsparungen gab es zumindest bei Ryzen 2000 und Polaris 30 keine. Und deren 14 nm wiederum ist 20 nm mit FinFETs und nur leichter Steigerung der Dichte. 22FDX hat IIRC in Bezug auf Dichte auch ein gewisses Tuning bekommen. IMO sind die nicht so extrem weit voneinander entfernt.

Die "nm" sind ja leider kein echter Indikator mehr für Dichte und Performance.


Ist doch quatsch auf 22fdx zu setzen, wenn man 12lp+ nutzen kann. 12fdx braucht eh noch bis weit in 22 hinein. Ein weiteres Hindernis ist der Vertrag mit St Micro, der FDSOI auf die Dresdener Werke beschränkt. Ich halte FDSOI für das IOD für Quatsch.

Als Weiteres denke ich, dass das IOD mehr sein muss als nur I/O, da müssen Teile des Frontendes rein um nicht in die Probleme zu laufen, die bisherige Multi GPU Systeme haben. Das Ganze muss transparent als Einheit funktionieren, sonst kann man das gleich lassen. AMD plant da nicht umsonst so enorm viel Entwicklungsarbeit rein, wenn die Grafik Chiplets schon seit Anfang 20 existieren gibt's da keinen großen Architektusprung im Sinne vom reinen RDNA, aber eben offenbar beim Ausbalancieren der Chips, Träger und Latenzen.
Es bewertet ja niemand die Wahrscheinlichkeit sondern nur die Möglichkeit dieses Szenarios.
7 nm ist teuer und schlecht verfügbar. Allerdings ändert sich das sicherlich in 2022.
Aber: wenn genug Analogkram und genug Cache auf dem IOD sein soll, dann kann man seine Vorteile in den Bereichen ausspielen um den Teil der dann wirklich rein Logikteil ist auszugleichen. Kann mir gut vorstellen, dass man da auch Cache haben will.

[AlterSack]

Mir persönlich ist der erhöhte Idleverbrauch von delta 30W oder so komplett egal. Bezogen auf die Gesamtstromrechnung und den Anteil der Nutzungsdauer im Idle sind das Peanuts.

Dies könnte sich demnächst ändern, wie sich wahrscheinlich (leider)
noch wesentlich mehr ändern wird.
https://www.heise.de/tp/features/Die-Stromversorgung-ist-massiv-gefaehrdet-5030116.html

Elektronikbauteile scheinen auch mehr und mehr Mangelware
zu werden ...und das auf längere Sicht. Die Diskussionen
ob Teil A 10 Frames mehr schafft als Teil B sind wohl bald irrelevant.
..sind sie teilweise schon jetzt, wenn ich mir Verfügbarkeit und Preise ansehe.

[robbitop]

Dann ist Multimonitorverbrauch aber das kleinste Problem, was wir haben werden. ;)

[HOT]

Schau dir die PowerCPUs an. Die nutzen das seit vielen Jahren als L3 Cache. Bei sehr hohen Taktraten. ~5 GHz.
Der FD-SOI Prozess kommt ja von IBM. Genau diese Kombination wurde ja schon mehrfach umgesetzt.

das ist nicht korrekt, IBM hatte seiner Zeit PDSOI entwickelt und lange eingesetzt. Zuletzt kombinierte IBM FF mit PDSOI IIRC. FDSOI ist eigentlich eine Entwicklung von STM, wurde aber von vielen Firmen unterstützt IIRC. Die haben einen Deal mit GloFo zur Mitnutzung der Werke und dafür darf GloFo FDSOI anbieten. Das beschränkt sich soweit ich weiss aber auf Dresden. Wir sind da grad mal auf 22FDX, 12FDX dauert wohl noch bis Ende 22. 12LP+ ist erheblich leistungsfähiger als das.


Soweit ich das verstanden habe, haben analoge Schaltungen völlig andere Randbedingungen als digitale. Bei I/O ist halt viel Analogkram dabei.
FinFET ist sehr gut für hohe Taktraten für digitale Schaltungen, damit der Verbrauch im Rahmen bleibt. FD-SOI ist für Analogkram wohl extremst gut um den Verbrauch zu senken. Und wie gesagt, skaliert Analogkram praktisch nicht mit der Fertigungsstruktur. Entsprechend würde ich keine große Erhöhung der IOD Größe annehmen.

Zumal man nicht vergessen darf:
GF's 12 nm ist 14 nm optimiert - Flächeneinsparungen gab es zumindest bei Ryzen 2000 und Polaris 30 keine. Und deren 14 nm wiederum ist 20 nm mit FinFETs und nur leichter Steigerung der Dichte. 22FDX hat IIRC in Bezug auf Dichte auch ein gewisses Tuning bekommen. IMO sind die nicht so extrem weit voneinander entfernt.

Die "nm" sind ja leider kein echter Indikator mehr für Dichte und Performance.

Flächeneinsparungen gab es deshalb nicht, weil AMD die Masken nicht verändert hat. Klar spart 12LP Fläche. 12LP+ ist aber nicht mehr nur ein optimerter 14LPP sondern eine Weiterentwicklung, die zu 12LP noch mals 15% Fläche spart. Analogschaltungen können aber alle Prozesse. Ich sehe keinen Grund, warum man hier FDSOI vorziehen sollte, 12LP+ ist da erheblich leistungsfähiger, erst recht wenn Cache und iGPU enthalten ist. (Zen4 steht mit RDNA3 in der Roadmap, es gibt also eine kleine integrierte GPU.)

Es bewertet ja niemand die Wahrscheinlichkeit sondern nur die Möglichkeit dieses Szenarios.
7 nm ist teuer und schlecht verfügbar. Allerdings ändert sich das sicherlich in 2022.
Aber: wenn genug Analogkram und genug Cache auf dem IOD sein soll, dann kann man seine Vorteile in den Bereichen ausspielen um den Teil der dann wirklich rein Logikteil ist auszugleichen. Kann mir gut vorstellen, dass man da auch Cache haben will.
Ich glaub auch nicht, dass AMD das IOD in N7 fertigen wird. Entweder bleibt man bei 12LP+ oder man wird N6 dafür einsetzen wegen RDNA3, wobei ich aber 12LP+ für wahrscheinlicher halte, billiger und besser verfügbar. Und für Desktop ist es egal ob die GPU ein paar W mehr zieht.

[Nightspider]

Könnte man auch 1-2 LP CUs in den IO Chip packen damit im Idle und Windows die Compute Chiplets komplett abgeschaltet werden können?

[Zossel]

Könnte man auch 1-2 LP CUs in den IO Chip packen damit im Idle und Windows die Compute Chiplets komplett abgeschaltet werden können?

Ja bitte, denn ich brauche keine externe GPU.

[robbitop]

das ist nicht korrekt, IBM hatte seiner Zeit PDSOI entwickelt und lange eingesetzt. Zuletzt kombinierte IBM FF mit PDSOI IIRC. FDSOI ist eigentlich eine Entwicklung von STM, wurde aber von vielen Firmen unterstützt IIRC. Die haben einen Deal mit GloFo zur Mitnutzung der Werke und dafür darf GloFo FDSOI anbieten.
Power9 ist auf 14 nm FD-SOI
https://www.eetasia.com/teardown-a-look-at-ibm-power9s-micro-architecture/

IIRC war Power8 aber 22 FD-SOI. Finde da aber auf die schnelle leider nichts.

PD-SOI hat man sehr lange genutzt. AMD ebenfalls. IIRC ist IBM aber irgendwann auf FD-SOI umgestiegen.


Flächeneinsparungen gab es deshalb nicht, weil AMD die Masken nicht verändert hat. Klar spart 12LP Fläche. 12LP+ ist aber nicht mehr nur ein optimerter 14LPP sondern eine Weiterentwicklung, die zu 12LP noch mals 15% Fläche spart. Analogschaltungen können aber alle Prozesse. Ich sehe keinen Grund, warum man hier FDSOI vorziehen sollte, 12LP+ ist da erheblich leistungsfähiger, erst recht wenn Cache und IGPU enthalten ist.

Ich glaub auch nicht, dass AMD das IOD in N7 fertigen wird. Entweder bleibt man bei 12LP+ oder man wird N6 dafür einsetzen wegen RDNA3.
Die IODs sind aber nur normales 12LP oder? Und man nutzt IIRC die gleiche Maske wie 14nm. Von dem IOD gab es eine 14 nm Version und eine 12 nm Version IIRC.

[HOT]

Ja bitte, denn ich brauche keine externe GPU.

Es dürften mMn 2 RDNA3-WGPs werden, also 4 CUs.

Power9 ist auf 14 nm FD-SOI
https://www.eetasia.com/teardown-a-look-at-ibm-power9s-micro-architecture/

IIRC war Power8 aber 22 FD-SOI. Finde da aber auf die schnelle leider nichts.

PD-SOI hat man sehr lange genutzt. AMD ebenfalls. IIRC ist IBM aber irgendwann auf FD-SOI umgestiegen.

22nm war definitiv noch PDSOI, aber 14HP war echt FDSOI. Das ändert aber nix daran, dass GloFo mit STM verbunden ist für FDSOI, nicht mit IBM. Meine Aussage ist nach wie vor korrekt.


Die IODs sind aber nur normales 12LP oder? Und man nutzt IIRC die gleiche Maske wie 14nm. Von dem IOD gab es eine 14 nm Version und eine 12 nm Version IIRC.
Die jetzigen Bixbys sind 12LP, geplant waren die in 14LPP, also sind deren Masken auch ohne Flächenvorteile für 12LP designt worden.

[robbitop]

Nungut - aber zumindest ist bewiesen, dass 1T SRAM mit hohen Taktfrequenzen auf FD-SOI möglich ist dank Power8. Auch wenn das nicht genau der Prozess ist.
Da GF ja einiges an IBM's Personal und Process RnD und Patente gekauft hat, wird da sicherlich auch Erfahrung aus dem Bereich mit dabei sein und man wird das Rad nicht neu erfinden.
Mit PD-SOI ist es ja über Generationen bewiesen worden.

[HOT]

Keine Ahnung wie da die Vertragsstrukturen sind ;). Ist aber auch egal, für Cache wird man eh SRAM verwenden, wenn das nötig ist. Ist für N31 hypothetisch das IOD in 12LP+ gefertigt, hätte man noch den Bonus, dass dieser Prozess Cache besonders sparsam betreiben kann. Wenn man hier ein 400mm² Die in 12LP+ nutzt mit 192MB Cache, 384Bit GDDR6 und etwas Frontendlogik nebst entsprechend breiter Links für die GCDs, könnte man mit TSMCs Technik darauf theoretisch 2 200mm² 80-CU-Dies pflanzen. Größer sind die ja nicht in N5, eher kleiner. Die selbst maskieren dann die höheren Lantenzen mit 16MB L2$ und gut ists. Jedenfalls kann ich mir das in meinem laienhaften Verständnis so ausmalen :D.

[mboeller]

https://fuse.wikichip.org/news/3383/ibm-doubles-its-14nm-edram-density-adds-hundreds-of-megabytes-of-cache/

https://fuse.wikichip.org/news/956/globalfoundries-14hp-process-a-marriage-of-two-technologies/4/

[HOT]

Also man kann ausschließen, dass das IOD in 14HP gefertigt wird ;). 22FDX hat ganz andere Prioritäten. 14HP ist ein völliger Exot und ein FinFET + FDSOI-Mischprozess. Total High-Porformance und total teuer.

[Unicous]

@robbitop

Du verbreitest leider sehr viel FUD. "Analogkram" skaliert sehr wohl noch nur eben deutlich schlechter als 'der Rest".

Q.E.D.:

https://fuse.wikichip.org/wp-content/uploads/2019/10/tsmc-n5-overview.png
TSMC says that its 5-nanometer process is 1.84x denser than its 7-nanometer node. TSMC also optimized analog devices where roughly 1.2x scaling has been achieved.
https://fuse.wikichip.org/news/3398/tsmc-details-5-nm/

Das ist an sich ein gutes Ergebnis, aber liegt aber eben auch deutlich unter dem Wert der bei "Logik" erzielt wird und daher wäre es nicht wirtschaftlich.

Hier ein Wert von Samsung zu 10nm im Vergleich zu 14nm:
https://pics.computerbase.de/7/5/7/6/4/article-630x354.15e95c19.jpg
https://www.computerbase.de/2016-12/foundry-samsung-10-nm-lpe-lpp/

10% des gesamten Scaling gehen auf Analog und 10% auf "I/O", das ist im Vergleich extrem gering (wobei 10nm auch nur ein kleiner node shrink ist), deswegen ist es auch hier sinnlos einen IOD zu produzieren. Womit wir aber zum Ursprung zurückkommen. Ich finde leider keine Zahlen, würde aber schätzen, dass zwischen 22FDX (der ja im Grunde noch auf 28nm basiert) und 14nm/12nm dennoch ein deutlicher Unterschied besteht, der dazu führt, dass der Chip deutlich größer wäre. Das hätte wie ich bereits sagte auch Auswirkungen aufs Package. FD-SOI macht Sinn für kleine in Masse gefertigte IoT Chips und spezialisierten "Analogkram", das heißt aber nicht automatisch, dass es ein guter Prozess für IOD Chips wäre. Das weiß offensichtlich auch AMD, sonst hätten sie den Prozess nicht gewählt (abgesehen von der gegenseitigen Verpflichtung von GF Chips zu kaufen).

[robbitop]

@robbitop

Du verbreitest leider sehr viel FUD. "Analogkram" skaliert sehr wohl noch nur eben deutlich schlechter als 'der Rest".



FUD steht für: Fear, Uncertainty and Doubt, auf Verunsicherung oder Abschreckung abzielende Kommunikations-Strategie.

Schon ein harter Vorwurf...
Jeder kann sich mal irren (wobei diese extrem unterproportionale Skalierung, die du zeigst, so gering ist, dass lediglich das Wörtchen “quasi“ fehlt - es skaliert quasi nicht) und in einem Forum darf man auch mal einen saloppen Begriff wie „Analogkram“ start analoge Schaltungen verwenden. Mit FUD per Definition hat das nichts zu tun. Zumal nichteinmal die Intension dahintersteckte, wissentlich Dinge zu verbreiten, die nicht stimmen.

Ich empfehle dir, über deine Art der Kommunikation zu reflektieren. Man kann andere in vernünftigem Ton korrigieren, ohne ihnen FUD vorzuwerfen.

Inhaltlich: danke für die Information. Es ist hilfreich zu wissen, dass analoge Schaltungen (wenn auch stark unterproportional) ebenfalls mit Prozessshrinks schrumpfen.

[Unicous]

Du hast jetzt über mehrere Seiten falsche Behauptungen aufgestellt denen ich immer wieder widersprochen habe und du hast dennoch weiter deine unbewiesene Meinung verbreitet. Du hast dir auch nicht die Mühe gemacht, deine Behauptungen zu belegen sondern im Gegenteil sogar mit Halbwahrheiten und unbelegten Annahmen vom tollen FD-SOI Prozess gesprochen der perfekt für "Analogkram" ist und deswegen auch super für IOD-Chips passt.

Das ist FUD. Und selbst als ich dir mühsam Beweise heraussuche, weil du dazu nicht in der Lage bist, versuchst du diese kleinzureden. 20% von 7nm auf 5nm ist enorm (deswegen hat TSMC es auch explizit aufgezählt) und du redest von "quasi". Du streitest über Semantik obwohl es gar keinen Raum dafür gibt.

Ich bin mir ziemlich sicher, dass wir eine ähnliche Diskussion zu "Analogkram" und I/O schon mal geführt hatten.

Fazit aus all dem: Wenn du Behauptungen aufstellst solltest du sie auch mit Quellen belegen können und dich nicht beleidigt fühlen wenn man das Wort FUD nutzt und vor allem nicht die geteilten Fakten deines Gegenübers kleinreden weil sie konträr zu deiner Meinung verlaufen.:rolleyes:

[Gratzner]

und vor allem nicht die geteilten Fakten deines Gegenübers kleinreden
Also Du hast ja bisher auch einige gefühlte "Fakten" rübergebracht oder, um es in deinen Worten zu sagen, nur FUD erzählt.


https://fuse.wikichip.org/wp-content/uploads/2019/10/tsmc-n5-overview.png
https://fuse.wikichip.org/news/3398/tsmc-details-5-nm/
Das ist an sich ein gutes Ergebnis, aber liegt aber eben auch deutlich unter dem Wert der bei "Logik" erzielt wird und daher wäre es nicht wirtschaftlich.


Ich finde leider keine Zahlen, würde aber schätzen, dass zwischen 22FDX (der ja im Grunde noch auf 28nm basiert) und 14nm/12nm dennoch ein deutlicher Unterschied besteht, der dazu führt, dass der Chip deutlich größer wäre.

Ja, was den nun? Erst sagst Du, das Analog und IO kaum skaliert mit neuen Fertigungsverfahren und daher unwirtschaftlich ist und dann auf einmal liest Du große Flächenersparnisse heraus und sagst 22FDX ab, weil ja der half-node, den man gegenüber 14nm/12nm zurückhängt, "so viel" Fläche kostet.
Außerdem, was soll den daran schlimm sein, wenn 22FDX auf 28nm basiert? Heutzutage basieren alle neuen Prozesse auf vorherige Prozesse. Es wird kein Prozess mehr von Grund auf neu entwickelt.

Hier ein Wert von Samsung zu 10nm im Vergleich zu 14nm:
https://pics.computerbase.de/7/5/7/6/4/article-630x354.15e95c19.jpg
https://www.computerbase.de/2016-12/foundry-samsung-10-nm-lpe-lpp/

10% des gesamten Scaling gehen auf Analog und 10% auf "I/O"
ÄÄÄÄÄÄhmmmm, da steht nur da, das die von einen Chip mit 50% Logik, 30 Speicher und jeweils 10% Analog und IO ausgehen, da steht nicht woher die Skalierung kommt...

FD-SOI macht Sinn für kleine in Masse gefertigte IoT Chips und spezialisierten "Analogkram"

Auch wieder so ein gefühlter Fakt? Wo steht den da, das es nur für spezialisierten "Analogkram" gut ist? FD-SOI bringt z.B.: ein wesentlich besseres SNR mit. Für welchen "Analogkram" soll denn das nicht oder nur wenig gut sein? Und dann macht FD-SOI nicht nur Sinn für kleine, in der Masse, gefertigte IoT-Chips. Die Hersteller bewerben das für IoT, weil sie dort die größten Wachstumschancen wittern. SOI-Prozesse wurden schon früher auch regulär für state-of-the-art consumer Prozessoren eingesetzt, siehe ein Absatz weiter unten.

Das weiß offensichtlich auch AMD, sonst hätten sie den Prozess nicht gewählt (abgesehen von der gegenseitigen Verpflichtung von GF Chips zu kaufen).
Also AMD hat in der Vergangenheit schon mehrmals SOI Prozesse gewählt, z.B.: für K8.
Für ein IO-Die wird das ausschlaggebende die Kosten sein. Und da macht SOI Probleme. SOI wird entweder mit zwei Wafern hergestellt oder aber mit irgendwelche Ionenimplantation, welche nicht nur zusätzliche Kosten für Maschinen, sondern auch zusätzliche Defekte im elektrisch aktiven Bereich, welche nicht alle ausheilen, mitbringen.


Fazit aus all dem: Wenn du Behauptungen aufstellst solltest du sie auch mit Quellen belegen können
Würde ich gerne mal zurückgeben.

und dich nicht beleidigt fühlen wenn man das Wort FUD nutzt und vor allem nicht die geteilten Fakten deines Gegenübers kleinreden weil sie konträr zu deiner Meinung verlaufen.:rolleyes:
Achso, Du findest es also OK, wenn andere Leute (nach deiner Meinung) falsch liegen, gleich unhöflich und polemisch zu werden.

[HOT]

Was arbeitest du dich daran ab? Ein 28nm-Derivat wird AMD definitiv nicht nutzen, wenn man schon 12LP nutzt :freak:.
Die FDSOI-Prozesse sind raus und Ende. 12LP+ wäre ideal für den Zweck eine IOD geeignet.

[Gratzner]

Wo steht das 22FDX ein 28nm Derivat ist? Selbst wenn, was wäre daran so schlimm? Die Halbleiterentwicklung ist iterativ, falls Du das noch nicht mitbekommen hast... Der Punkt war ja nicht, ob man unbedingt 22FDX einsetzt (die Leute, die nicht so sehr unter Dunning-Kruger leiden, haben halt nicht den Anspruch so supertolle Vorhersagen zu machen), sondern das die SOI-Prozesse super Vorteile bieten, z.B.: 0,4V wird für GF 22FDX angegeben ggü. 0,7V für 7NM TSM -> macht grob überschlagen Faktor 3 weniger im Stromverbrauch, wenn man Milchmädchenrechnungsmässig den R konstant lässt. Dadurch kann man Analogkram und (teile) des IO viel kleiner machen (weil weniger Leistung abkönnen muss), und das sogar mit einem schlechter klingenden Namen im Fertigungsverfahren. Dem Analogkram interessiert sich teilweise gar nicht, was die kleinst-möglichen Strukturen sind. Da geht es um andere Sachen (z.B.: relative Toleranzen, SNR). Da bietet FD-SOI ganz zufälligerweise massiv Vorteile

[Unicous]

Für etwaige "Fakten" zu FD-SOI und "Analogkram" solltest du robbitop befragen.:rolleyes:

Darüber hinaus hast du uns jetzt auch nicht näher an die Realität gebracht außer willkürlich ein paar buzz words wie SNR in den Raum zu werfen statt mir ein paar harte Fakten ins Gesicht zu knallen.:freak:

22FDX hängt nicht nur einen half node zurück keine Ahnung was das für ein Halbwahrheit verbreitest. Ich habe im Übrigen nichts darüber gesagt, dass es "schlimm" wäre. Das wird ja immer wilder hier?

FD-SOI ist ein spezielle Technologie der zwischen bleeding edge und den tried and true Prozessen wie 28nm und 40nm steht. Das hier eine Nische bedient wird sollte auch allein dem Fakt geschuldet sein, dass TSMC, Samsung und andere Produzenten keinen SOI-Prozess anbieten und GF als einziger Anbieter mit einem vergleichsweise geringen output eine kleine und überschaubare Kundschaft bedient.

Ich hoffe du wirst mich hier postwendend eines Besseren belehren und mir harte Zahlen offenlegen, was für ein krasser Mainstream-Prozess 22FDX doch ist und wie sich die Kunden darum reißen Kapazität bei GF zu ordern.:wink:

Das mit dem Samsung Bild habe ich vermutlich falsch interpretiert, mea culpa.
Ein Glück ist es keine große Sache, denn TSMC bei 5nm verspricht, dass "Analogkram" im Vergleich zu 7nm bis zu 20% skaliert.:wink:

Und ja AMD hat in der Vergangenheit, die nun mittlerweile fast 8 Jahre zurückliegt auf SOI-Prozesse gesetzt und ist dabei mehr oder minder auf die Nase gefallen. Nicht nur war 32nm eine Blamage, auch 45nm war im Vergleich zu Intel nicht gut genug um einen Wettbewerbsvorteil zu erlangen. Dafür war man geplagt von schier endlosen Problemen, die nicht nur Produktverschiebungen verantwortlich waren sondern auch dazu führten, dass die Produkte nicht konkurrenzfähig waren, weil zu teuer und schlechte Ausbeute. Als 32nm einigermaßen gezähmt war, hatte die Konkurrenz schon längst einen neuen Prozess mit revolutionärer Fertigungstechnologie in petto.

(FD-)SOI ist teuer (wie du selbst zugibst) und für AMD momentan nicht zweckmäßig. Wir reden hier nicht von Intel, die aus lauter Verzweiflung Southbridge Chips und Pentiums in 22nm herstellen müssen. AMD hätte theoretisch die Option bei Samsung und TSMC fertigen zu lassen sie haben also genug Optionen, sie haben Zugriff auf FD-SOI. Sie nutzen ihn nicht. Und ich bezweifele sehr stark dass sie in ca. zwei Jahren 12FDX nutzen, denn es gibt keinerlei wirtschaftliche Anreize dafür. Bis dahin ist vermutlich 7nm bzw, dessen konstenoptimierte Derivate, ein Prozess der ähnlich wie 28nm und jetzt 14/16nm von einem größeren Markt genutzt werden kann, weil die Vorteile die anfänglich immensen Investitionskosten übertrumpfen und TSMC und Co. ihre Fabs die nicht sofort umgerüstet werden auslasten will.


edit: "(die Leute, die nicht so sehr unter Dunning-Kruger leiden, haben halt nicht den Anspruch so supertolle Vorhersagen zu machen)" raushauen und dann mit buzzwords und willkürlichen Prozesscharakteristiken um dich schlagen.:freak:

[reaperrr]

Was mir in der ganzen Diskussion zu kurz kommt:

Nur weil ein neuerer Prozess im Bereich Analog/IO keine Verbesserungen im Bereich der Fläche bringt, heißt das noch lange nicht automatisch, dass er keine elektrischen Verbesserungen bezgl. Verbrauch/Taktbarkeit bringt.

Bestes Beispiel ist ja gerade der I/O-Die von Matisse/Vermeer: Der war ja nicht von vornherein in 12LP, sondern zunächst 14LPP und wurde relativ kurz vor Release noch auf 12LP "geshrinkt", obwohl es keine Flächeneinsparung gab.
Warum wohl? Weil man Langeweile hatte und zu viel Geld, das ausgegeben werden musste?...

[Unicous]

AMD nutzt weiterhin 14nm und 12nm für die IODs, ich habe leider vergessen wie rum es war. Epyc und Ryzen IODs nutzen iirc jeweils ein anderes Verfahren, man möge mich aber korrigieren. edit: Halt, das war bei Matisse und Rome der Fall, sorry.

Es ist im Übrigen auch ein Mythos, dass der IOD nicht taktbar sein muss, denn er ist ja Teil des Fabric und das Speicherinterface wird auch immer stärker ausgebaut. Der Chip hat dadurch eine entsprechend hohe Grundlast.

Chips die momentan in FD-SOI gefertig werden sind darauf ausgelegt einen Großteil der Zeit idle zu verbringen. Ein 5G-Chip in einem Smartphone wird nicht durchgängig genutzt sondern nur wenn er gebraucht wird, dementsprechend ist es von größter Bedeutung die Leistungsaufnahme auf ein Minimum zu drücken, sonst ist der Akku in kürzester Zeit leer.

Die IOD Chips haben dieses Problem nicht. Wenn das Ding idle 10-15 Watt schlürft interessiert das nicht weiter. Auch das dürfte ja ein Grund sein warum AMD seine Mobile Chips weiterhin monolithisch designed.

AMD wird darauf hinarbeiten noch mehr Teile des Chips in den Tiefschlaf zu legen und nur bei Bedarf aufzuwecken, bislang scheinen sie damit ja noch Probleme zu haben, hatte ich irgendwo gelesen.

[Gratzner]

Für etwaige "Fakten" zu FD-SOI und "Analogkram" solltest du robbitop befragen.:rolleyes:

Jetzt wirst du aber hart polemisch. Kann das sein, das bei dir das Verhältnis aus Meinung und Ahnung in schieflage geraten ist?


Darüber hinaus hast du uns jetzt auch nicht näher an die Realität gebracht außer willkürlich ein paar buzz words wie SNR in den Raum zu werfen statt mir ein paar harte Fakten ins Gesicht zu knallen.:freak:

Du hast einfach keine Ahnung (aber viel zu viel Meinung), was sich dahinter verbirgt bzw. was es technisch für Auswirkungen hat. SNR ist nichtmal ein Buzzword. Du solltest wirklich mal dich mit absoluten basics beschäftigen.

22FDX hängt nicht nur einen half node zurück keine Ahnung was das für ein Halbwahrheit verbreitest. Ich habe im Übrigen nichts darüber gesagt, dass es "schlimm" wäre. Das wird ja immer wilder hier?

22nm ist vom Namen ein half node entfernt von 14nm/12nm, weil 14nm mal 1,5 sind rund 22nm.


FD-SOI ist ein spezielle Technologie der zwischen bleeding edge und den tried and true Prozessen wie 28nm und 40nm steht. Das hier eine Nische bedient wird sollte auch allein dem Fakt geschuldet sein, dass TSMC, Samsung und andere Produzenten keinen SOI-Prozess anbieten und GF als einziger Anbieter mit einem vergleichsweise geringen output eine kleine und überschaubare Kundschaft bedient.

Deine Welt passt nicht ganz so mit der Realität zusammen. Samsung bietet beispielsweise auch FD-SOI an. Ist sogar extra ne Partnerschaft mit ARM für die Nutzung der Technolgie eingegangen:https://community.arm.com/developer/ip-products/physical/b/physical-ip-blog/posts/samsung-foundry-and-arm-collaborate-on-18nm-fdsoi
Daneben gibt es weitere Hersteller, z.B.: STMicroelectronics


Und ja AMD hat in der Vergangenheit, die nun mittlerweile fast 8 Jahre zurückliegt auf SOI-Prozesse gesetzt und ist dabei mehr oder minder auf die Nase gefallen.
Kompletter Schwachsinn. AMD war mit K8-Prozessoren extrem erfolgreich. Mit der Servervariante haben die sogar große Marktanteile gewonnen.


edit: "(die Leute, die nicht so sehr unter Dunning-Kruger leiden, haben halt nicht den Anspruch so supertolle Vorhersagen zu machen)" raushauen und dann mit buzzwords und willkürlichen Prozesscharakteristiken um dich schlagen.:freak:
Sry, das sehe ich nur bei dir. Außerdem habe ich keine willkürlichen Prozesscharakteristiken an die Wand gehauen, sondern in der Halbleiterei allgemein bekannte Vorteile von SOI genannt, die du wahrscheinlich nur glaubst zu kennen, es aber nicht tust. Die Vorteile kannst Du auch nochmal bei STMicroelektronics oder Glofo nachlesen. HIer habe ich extra ein Link für dich (hab auch was möglichst leicht verständliches rausgesucht): https://www.st.com/content/st_com/en/about/innovation---technology/FD-SOI/learn-more-about-fd-soi.html

[Unicous]

22nm ist vom Namen ein half node entfernt von 14nm/12nm, weil 14nm mal 1,5 sind rund 22nm.
:facepalm:

Sorry, da habe ich aufgehört zu lesen. Dunning-Kruger, volle Fahrt voraus. Mich der Polemik beschuldigen und dann sowas heraushauen.;D

Aber eins noch. Willkürlich Prozesscharakteristiken korrekt zu zitieren macht dich nicht automatisch zum Experten oder hat irgendeine Relevanz ob ein Prozess für einen konkreten Anwendungsfall geeignet ist.

Du wirst mir aber sicherlich im nächsten Post detailreich erläutern wie das Substrat beschaffen sein muss, wenn man einen SOI-Chip mit einem Bulk-Chip auf einem Package vereint. Wie das Routing gelingt. Was für bumps genutzt werden und vor allem bitte noch ein paar mehr Charakteristiken hineinstreuen. Wie sieht es mit der Threshold- Voltage aus...

Edit: kannst Du eigentlich was anderes außer deine unfundierte Meinung heraushauen?

Jetzt wirst du aber hart polemisch

[Gratzner]

sorry, wusste nicht, das Du die Deutungshoheit über half-node und full-node hast. Tut mir echt leid. Sowas wie die Transistorendichte (mit Quelle), um mein -mich am Namen orientiertes Argument- zu widerlegen, warst du auch nicht in der Lage zu nennen.

Dann erzählst Du hier ganze Zeit "falsche Fakten" und kannst z.B.: nichtmal Folien richtig lesen.
(Beispielweise, Samsung würde kein FD-SOI anbieten, SOI Prozessoren, wie die AMD-K8-Prozessoren waren Flops, SNR sei ein Buzzword, SOI sei nur was für spezialisierten Analogkram und IoT, ...)

Auf meine Argumente gehst du gar nicht ein, obwohl ich dich vielfach widerlege. Das einzige, was Du kannst, ist hier dich an sinnlosen Namen aufzugeilen.

Deine Fragen zeigen, das du von den basics der basics überhaupt kleine Ahnung hast, beispielsweise:

"wie das Substrat beschaffen sein muss, wenn man einen SOI-Chip mit einem Bulk-Chip auf einem Package vereint"
Das Substrat ist egal, da die auf das Substrat aufgebrachten Metallisation nach unten zeigt und auf das Leadframe bzw. Interposer gelötet wird

[HOT]

Das ist klar definiert. Von 65 auf 55nm ist half node, von 65 auf 45 full node. Half node prozesse:55, 40, 28, 20, 14nm, full node: 65, 45, 32, 22, 16nm. Von 28 auf 12nm ist 1 1/2 nodes. 12lp ist erheblich leistungsfähiger als 22fdx. Man darf sich nicht von den Namen irritieren lassen. 22fdx ist 28nm FDSOI und 12lp ist <20nm finfet.

[Unicous]

Darum geht es gar nicht. Die Namen sind Schall und Rauch. Außerdem ist es vollkommen dämlich SOI-Prozesse mit Bulk-Prozessen zu vergleichen und dann zu konstatieren: You see, it's the same.

Das ST-Micro an Samsung ihren Prozess lizenziert hat ist mir wirklich im Eifer des Gefechts entfallen, aber über den Treppenwitz 18FDS lache ich immer noch, besonders über die gepostete zwei Jahre alte PM und der kompletten Funkstille seitens Samsung seitdem.;D

Gratzner arbeitet sich gerade an mir persönlich ab wirft mir gleichzeitig aber Polemik vor.:freak:

Statt mit klarem Geist ein kohärentes, mit erfrischenden Fakten gespicktes, Szenario zu entwerfen in dem AMD FD-SOI für ihre IODs verwendet verliert er sich in auf gar keinen Fall willkürlich eingestreuten buzzwords wie signal-to-noise-ratio ohne konkret zu nennen warum das im Fall der IODs einen Vorteil gegenüber einem FinFET-Bulk Verfahren hätte. Warum AMD seit nun mehreren Generationen und Ausführungen der IODs nicht auf FD-SOI umgeschwenkt ist, wenn es doch das überlegene Verfahren für diesen konkreten Anwendungsfall darstellen soll bleibt er weiter schuldig.

Es kommt nichts Konkretes, er drückt mir aber so richtig eins rein, ich erschaudere geradezu vor so viel geballter Kompetenz wenn er total Relevantes erwähnt wie zum Beispiel dem Fakt, dass auch Samsung FD-SOI Chips produziert.
Hatte ich schon erwähnt wie extrem relevant das für das Thema ist. :uponder:

Vor lauter "keine Ahnung" und "Dunning Kruger" sehe ich die ganzen Fakten nicht die mir ins Gesicht fliegen. :frown:

Für mich hat sich das erledigt. Das war der von Anfang an falsche Thread dafür, ich wollte lediglich mit ein paar Missverständnissen aufräumen, robbitop hat das auch eingesehen. Gratzner kann sich einen anderen Gratzbaum suchen.

[basix]

Meine Meinung:
22FDX bringt für ein CPU/GPU IOD nicht die selbe Density, Performance und Energieffizienz wie 12LP+ und ist deshalb weniger gut geeignet. Das Zen 2/3 IOD besteht sicher zu >50% noch aus normaler Logik und SRAM. 22FDX wäre Verschwendung und einfach nicht die richtige Technologie. Ein anderes Thema könnte auch IP sein. Ich weiss nicht, ob es GDDR6 für 22FDX geben würde, ein Rückport kostet Geld.

Wenn es um reine analoge Schaltungen geht, wird 22FDX schon besser sein. SNR ist etwas vom wichtigsten was man dort haben muss, das ist definitiv kein Buzzword. Und umso kleiner die Schaltungen, desto schwieriger ist gutes SNR. Ich sitze selber gerade an einem Verstärkerdesign-Konzept für einen ASIC (noch in 0.18um) und um SNR dreht sich ein guter Teil des Designs. Daneben sind noch Leakage und Parasitics (parasitäre Komponenten) wichtig, was bei SOI ebenfalls besser handhabbar sein sollte. Ebanfalls Sachen wie Deep Trench sind nützlich, wenn man empfindliche analoge Schaltungen gegenüber anderen Schaltungsteilen isolieren will (weiss jetzt nicht ob einer der beiden Prozesse das uneterstützt). Der einzige Grund, welcher für 22FDX spricht: Embedded DRAM. Wenn der kommt, kann 22FDX Sinn machen. Andernfalls eher nicht. Edit: Wait, IBM nutzt HP14 FF on SOI (https://fuse.wikichip.org/news/3383/ibm-doubles-its-14nm-edram-density-adds-hundreds-of-megabytes-of-cache/). Habe nichts gesagt. Link2 (https://fuse.wikichip.org/news/956/globalfoundries-14hp-process-a-marriage-of-two-technologies/). Wieso nicht den nutzen? ;)

Lest euch auch den Product Brief von 12LP und 22FDX durch.
https://www.globalfoundries.com/sites/default/files/product-briefs/pb-12lp-11-web.pdf
https://www.globalfoundries.com/sites/default/files/22fdx-product-brief.pdf
12LP+ findet man leider nirgends, am besten ist die News von https://www.anandtech.com/show/14905/globalfoundries-unveils-12lp-technology-massive-performance-power-improvementsdazu.

Noch zu SOI (https://fuse.wikichip.org/news/956/globalfoundries-14hp-process-a-marriage-of-two-technologies/2/):
The biggest one is that bulk substrate is much cheaper than an SOI substrate..... that claimed it would add roughly 10% to the total process cost.....Another less obvious issue is derived from the fact that heat dissipation in SOI-based devices is greatly hindered in the base silicon layer by the low thermal conductivity of the buried oxide layer.

@HOT
Der 22FDX Product Brief redet etwas von "Full Node" Scaling verglichen mit 28nm (70% Fläche) für "Mid/Low Tier Apps Processor". Etwas dichter als 28nm sollte der schon sein.

Und nun bitte mal wieder BTT hier, es geht hier eigentlich nicht um einen Lithographieprozess-Kleinkrieg ;)

[Leonidas]

... und ich dachte, hier geht es um RDNA3.


BTT:

CapFrameX stellt folgende Behauptungen auf:
https://twitter.com/CapFrameX/status/1353378042941485056

I've got some infos about RDNA 3 (top tier). It's gonna be a real beast. Holy shit. Chiplet design, 32GB VRAM but very expensive too.
AMD pursues the strategy to beat Nvidia this time.


Und ich hab derweil mal nachgeschaut, wie das Verhältnis bei RDNA1 zu RDNA2 war:
https://www.3dcenter.org/news/hardware-und-nachrichten-links-des-25-januar-2021

|Radeon RX 5700 XT|Radeon RX 6900 XT|Differenz
Hardware|Navi 10, 40 CU @ 256 Bit GDDR6|Navi 21, 80 CU @ 256 Bit GDDR6 + Infinity Cache|+100% CU
Realtakt|1822 MHz lt. CB|2265 MHz lt. CB|+24%
Rohleistung auf Realtakt|9,3 TFlops|23,2 TFlops|+149%
Spiele-Performance (lt. 4K-Index)|163%|332%|+104%
Real-Verbrauch|221W|305W|+38%

[robbitop]

22FDX haben wir im Zusammenhang zu einem IOD zu RDNA3 diskutiert. :)

@Unicous
Du hast inhaltlich Recht (#222, #230). Danke für die Links/Quellen. Kleiner Hinweis: Der Ton macht die Musik. ;)

[disap.ed]

Was hat die letzte Seite eigentlich mit RDNA3 zu tun?
@Admins: Könnte man das bitte in den Chipfertigungs-Thread verschieben?

[robbitop]

Was hat die letzte Seite eigentlich mit RDNA3 zu tun?
@Admins: Könnte man das bitte in den Chipfertigungs-Thread verschieben?
Es ging um mögliche Fertigungsprozesse inkl. Vor und Nachteile für einen I/O Die für RDNA3 SKUs unter der Annahme, dass es einen Chiplet Ansatz mit Compute- und IODs geben wird. ;)

[davidzo]

... und ich dachte, hier geht es um RDNA3.


BTT:

CapFrameX stellt folgende Behauptungen auf:
https://twitter.com/CapFrameX/status/1353378042941485056




Und ich hab derweil mal nachgeschaut, wie das Verhältnis bei RDNA1 zu RDNA2 war:
https://www.3dcenter.org/news/hardware-und-nachrichten-links-des-25-januar-2021

&nbsp;|Radeon RX 5700 XT|Radeon RX 6900 XT|Differenz
Hardware|Navi 10, 40 CU @ 256 Bit GDDR6|Navi 21, 80 CU @ 256 Bit GDDR6 + Infinity Cache|+100% CU
Realtakt|1822 MHz lt. CB|2265 MHz lt. CB|+24%
Rohleistung auf Realtakt|9,3 TFlops|23,2 TFlops|+149%
Spiele-Performance (lt. 4K-Index)|163%|332%|+104%
Real-Verbrauch|221W|305W|+38%



2,5fache Rohleistung, passt doch!
Das Scaling in Games ist schon sehr gut, aber wäre noch besser wenn der Cache etwas größer wäre. Navi21 geht in 4K schon Sichtbar die Bandbreite aus.


BTW, afaik wurde das leistungsziehl 2,5x nie gesagt. Es gibt lediglich diese Aussage von Kopite7Kimi:
I don't think a design with 10240 cores can reach the perf goal.
Die 2,5x haben wir uns dann so dazu gedichtet. Es könnten genausogut 3x sein, aber das erscheint ein bisschen unrealistisch hoch in dem Zeitraum.


Seinen Erklärversuch danach könnte man aber auch dahin deuten dass er meinte Navi3x CUs sind eben nicht dasselbe wie Navi2x Skus, also starke IPC Verbesserungen, viel mehr Cache, Takt, Raytracingkerne oder Ähnliches:
Ah, I mean a simple mcm design with 10240 cores is not enough.
Because the lift from RDNA2 to RDNA3 is much bigger than from RDNA1 to RDNA2.
We should expect many big improvements in GFX11. ��

[davidzo]

NVM, die 2,5x kommen von Redgamingtech: https://www.youtube.com/watch?v=dq9_wMMS7ac&feature=youtu.be
dq9_wMMS7ac


Außerdem meint RGT in Patenten gelesen zu haben dass es erhebliche Verbesserungen bei der RT Leistung geben wird.

Lisa pumpt außerdem massiv Budget in die Radeon Technologies Group.
Trotzdem soll der launch frühestens Q2/22 sein.

Dazu erzählt die Source von drastisch mehr IPC, Takt und Effizienz.
Die Source soll wieder dieselbe sein die ihm letztes Jahr das mit dem Infinity cache gesteckt hat. Er war damit ja echt früh dran und zu dem Zeitpunkt hat ihm den spaß keiner geglaubt, vllt. auch wegen der Aufmachung des ganzen channels.

[HOT]

2,5x ist halt grob überschlagen: Doppelt soviele CU+Effizienz+mehr Takt=2,5x. Das ist eben ne grobe, schlampige Einschätzung sonst nichts.

[robbitop]

Die Frage ist, ob die 2,5 z.B. für RT gemeint sind. Da kann allein die HW Beschleunigung von BVH Traversals stark helfen. Ich kann mir gut vorstellen, dass das zu RDNA3 kommen wird.

Ansonsten kann es auch sein, dass man die CUs auch umstrickt. Siehe Ampere. Mehr FPUs pro CU und/oder mehr Kontrolllogik.
Entsprechend kann jeder CU für sich auch schneller werden.

[Gratzner]

Das ist klar definiert. Von 65 auf 55nm ist half node, von 65 auf 45 full node. Half node prozesse:55, 40, 28, 20, 14nm, full node: 65, 45, 32, 22, 16nm. Von 28 auf 12nm ist 1 1/2 nodes. 12lp ist erheblich leistungsfähiger als 22fdx. Man darf sich nicht von den Namen irritieren lassen. 22fdx ist 28nm FDSOI und 12lp ist <20nm finfet.

So klar ist das gar nicht definiert und ich glaube kaum, dass das über Namen definiert wird, hab dir mal was im Spoiler ein Bild über das scaling hinzugefügt. Auffälligerweise spricht die international technologie roadmap for semiconductor gar nicht von full nodes, sondern von major technology nodes

https://i.ibb.co/fFdMzn5/scaling.png

[vinacis_vivids]

Bei Navi31 stellt sich die Frage nach der Massentauglichkeit bei 8K Gaming.
4K 3840x2160 = 8.294.400 pixel
8K 7680x4320 = 3.3177.600 pixel

Die Vervierfachung der benötigten Pixeldarstellungsanzahl braucht einfach mehr Rohleistung wenn man es nativ betreiben will. Bei einer Verdopplung der Leistung muss eben upscaling, checkerboard, cas und fidelityfx herangezogen werden.

Bei 8K bekommt man Probleme mit der benötigten Bandbreite, weil es mit dem herkömmlichen SI zuviel Energie und Fläche verbraucht.
Der Kernpunkt wird sicherlich die Ausweitung der Fläche für den L3/L4-Caches sein und deren Anbindung mit der CPU, um die Kontrolllogik auf der GPU einsparen zu können. SAM und Infinity Cache mit der Infinity Fabric lassen grüßen.
Was den CU-Takt angeht, sind 2,5-3,0 Ghz unter Luft anzupeilen.
Der Ausbau des Infinity-Caches bringt auch Herausforderungen mit sich, weil die hitrate mit der Auflösung fällt. Da muss und wird AMD sicherlich massivst dran arbeiten um auch die CPU bei den hits mitarbeiten zu lassen.
Villt. sehen wird endlich mit Navi31 eine extrem hohe >80% CPU-Auslastung bei gleichzeitig 99-100% GPU-Auslastung. Da liegt die secret-sauce begraben, wenn ich mir die heutige Spielesoftware so anschaue, die in höheren Auflösungen ja fast nur die GPU nutzen während die CPU-däumchen dreht.

[dargo]

Das Scaling in Games ist schon sehr gut, aber wäre noch besser wenn der Cache etwas größer wäre. Navi21 geht in 4K schon Sichtbar die Bandbreite aus.

Geht dieser Unsinn wieder los?

[robbitop]

Die Frage ist, was man als normierte Basis ansieht. Aus meiner Sicht sollte das nicht eine andere uArch sein, denn diese kann eine andere Charakteristik haben. In der Regel unterscheiden diese sich in der Auslastung je größer das Geometrie/Pixelverhältnis wird.

Rechnerisch müsste man die Anzahl der Pixel anschauen.

1080p: 2 MPix
1440p: 3,68 MPix
2160p: 8,29 MPix

Wenn also die 2160p Framerate jeweils im absoluten GPU Limit (auch ohne im Geometrielimit zu hängen) um mehr als Faktor 2,25 sinkt ggü 1440p, dann kann man über spezifische Flaschenhälse sprechen. IMO.

Ist allerdings schwer zu gewährleisten, dass die GPU in beiden Settings im vollen GPU Limit (und ohne Geometrielimit) liegt.
Um das sinnvoll zu untersuchen müsste man die jeweilige GPU und den Speicher relativ linear untertakten oder eine kleinere SKU wählen.

[Gratzner]

Das ST-Micro an Samsung ihren Prozess lizenziert hat ist mir wirklich im Eifer des Gefechts entfallen, aber über den Treppenwitz 18FDS lache ich immer noch, besonders über die gepostete zwei Jahre alte PM und der kompletten Funkstille seitens Samsung seitdem.;D

Es kann ja wirklich sein, das Samsung diesen Prozess aufgegeben hat. Darfst ja auch gerne eine Quelle verlinken. Dein Argument basiert aber darauf, das der Prozess nicht mehr gibt, weil man im Internet nix mehr aktuelles liest. Hast Du schon mal was von Objekt Permanenz gehört? Nur weil man von etwas nix mehr hört, hört es noch lange nicht auf zu existieren. Sorry wusste einfach nicht, das so eine simple Fähigkeit nicht selbstverständlich ist (Alter wir reden über Objekt Permanenz). Tut mir echt leid, das dich dadurch der Samsung Prozess verwirrt und dir wie ein Treppenwitz vorkommt (bist ja überhaupt nicht polemisch)


Vor lauter "keine Ahnung" und "Dunning Kruger" sehe ich die ganzen Fakten nicht die mir ins Gesicht fliegen. :frown:

Hab dir schon viele sehr harte Vorteile von SOI erzählt, wie z.B.: wesentlich geringere Spannung und damit Leistungsaufnahme. (Kennst ja hoffentlich den Vorteil von geringerer Leistungsaufnahme, klar für die Aktuellen Ryzen Prozessoren ist Leistungsaufnahme im Desktop weniger wichtig, für eine Potenzielle IOD für eine Graka dürfte Leistungsaufnahme wesentlich mehr wichtig sein)


Statt mit klarem Geist ein kohärentes, mit erfrischenden Fakten gespicktes, Szenario zu entwerfen in dem AMD FD-SOI für ihre IODs verwendet verliert er sich in auf gar keinen Fall willkürlich eingestreuten buzzwords wie signal-to-noise-ratio ohne konkret zu nennen warum das im Fall der IODs einen Vorteil gegenüber einem FinFET-Bulk Verfahren hätte.
Du tust ja so, als hättest du Ahnung, ich dachte die Vorteile würdest Du daher selbstverständlich wissen.

Falls nicht, hier ein paar wenige Bsp.:
- noise -> immer zusätzliche nichtsbringende Rauschleistung die verbraten wird

- noise am io-Ausgang = schlechtes EMV z.B.: auf PCB

- noise durch Flanken auf Signalleitungen -> übersprechen ganz gerne, da Induktivität proportional zur Ableitung des Stromes nach der Zeit ist (delta_t ist wahnsinnig klein) ->
sensible Leitungen, z.B.: Taktleitungen müssen unter Umständen Differentiell Ausgeführt werden; brauchen Buffer; zusätzlicher Routingaufwand, da man störende Leitungen möglichst nahe den dazugehörige Leitung der Spannungsversorgung zusammenrouten muss, damit sich die Felder gegenseitig "auslöschen" können, um nicht andere Leitungen zu stören (Anm. die steile Flanke einer Signalleitungen findet sich in der Spannungsversorgung wieder), etc.

Ich wüsste nicht, warum das keine großen Vorteile für IO (-Die) bringen soll. Wird aber, wie ich schon schrieb, wahrscheinlich nicht eigesetzt, da relativ teuer (ein SOI Wafer wird typischerweise aus zwei normalen Wafer gebaut)

[dargo]

@robbitop

Man muss das Thema jetzt nicht unnötig verkomplizieren. Wenn ich sehe, dass meine Applikation in 4k mit 5% mehr Bandbreite (2,1Ghz vs. 2Ghz Speicher) nur 0,2% schneller wird dann weiß ich nicht wo N21 die Bandbreite in 4k ausgehen soll. Mich würde viel mehr interessieren auf welcher Basis davidzo so eine Behauptung aufstellt.