AMD RDNA3 - Chiplet NAVI - NAVI 3X

E555user

Vice Admiral Special
★ Themenstarter ★
Mitglied seit
05.10.2015
Beiträge
878
Renomée
295
Anfang Mai 2021 sind vermehrt Spekulationen um RNDA3 aufgetaucht.
Ich eröffne das Thema zu RDNA3 mit einem Video von Tom von MLID, der seine Informationen und Hinweise der letzten Monate zusammenfasst.

Man wird sehen welche Informationen tatsächlich relevant sind. Im Video werden bis zu 40% mehr Leistung im Vergleich zum aktuellen RDNA Topmodell in Aussicht gestellt, bei den Roadmap-Folien war die Zielsetzung offensichtlich die Leistung der ersten Generation RDNA respektive der NAVI um Faktor 3x zu erhöhen, oder wie Eiernacken aufklärt, dass es sich um die Ziffern der künftigen Chipvarianten handelt, wie bereits bei Navi 21, 22, 24...
AMD_Gaming_GPU_Architecture_Roadmap_Februar2021.png
AMD_Gaming_GPU_Roadmap_Februar2021.png



Die Roadmap-News Diskussion
Div. Forenbeiträge der Vergangenheit
 
Zuletzt bearbeitet:

eiernacken1983

Vice Admiral Special
Mitglied seit
18.06.2020
Beiträge
819
Renomée
506
  • THOR Challenge 2020
  • BOINC Pentathlon 2021
Im Video werden bis zu 40% mehr Leistung im Vergleich zum aktuellen RDNA Topmodell in Aussicht gestellt, bei den Roadmap-Folien war die Zielsetzung offensichtlich die Leistung der ersten Generation RDNA respektive der NAVI um Faktor 3x zu erhöhen.
Nee. Das X in "3X" ist Platzhalter für die Sub-Bezeichnung der großen Chips (Navi 30) und der kleineren Chips Navi 31, 32 und was auch immer noch kommen mag.
 

E555user

Vice Admiral Special
★ Themenstarter ★
Mitglied seit
05.10.2015
Beiträge
878
Renomée
295
Hier die MLID Punkte (11:50), die er in rot geschrieben als gesicherte Info ansieht:
  1. RNDA3 hat einen I/O Die als Chiplet mindestens ein Compute Chiplet - in einigen Modellen der Designphase
  2. Man ist zuversichtlich, dass RDNA3 60-80% mehr Performance als RDNA2 bieten kann
  3. AMD hat öffentlich das Ziel +50% Performance pro Watt vs. RDNA2 ausgegeben
  4. Eine theoretische RX7900XT sollte mindestens 40% besser als die RX6900XT sein
  5. Die optimistischste Annahme war bislang potentiell doppelte Performance zu RNDA2
  6. RayTracing & Gemoetry Leistung soll eine deutliche Steigerung per Dual CU aufweisen
  7. Im Vergleich zum Zen/Ryzen werden grössere Leistungseinbussen durch das Chiplet-Design erwartet
  8. AMD hat wiederholt bestätigt man glaubt man könne mit RNDA3 (vs. Nvidia bezügl. TopPerformance) gewinnen
 
Zuletzt bearbeitet:

BavarianRealist

Grand Admiral Special
Mitglied seit
06.02.2010
Beiträge
3.246
Renomée
49
Da RDNA3 in 5nm kommen und die 5nm-Wafer exorbitant teuer sein sollen, lohnt es sich hier noch mehr als bei den CPUs, möglichst Vieles in ein getrenntes I/O-Die in einem älteren Prozess (7nm oder sogar 10nm oder 12nm+ bei GF?) auszulagern, um Kosten zu sparen. Zumal sich das bei den GPUs noch stärker auswirken wird, weil sich hier noch mehr Ram-Controller auf dem Die finden, die schon lange nicht mehr viel von den kleinen Strukturen haben und somit immer mehr teure Fläche unsinnig verbrauchen. Auch die Video-Einheiten werden wohl raus wandern.
 

E555user

Vice Admiral Special
★ Themenstarter ★
Mitglied seit
05.10.2015
Beiträge
878
Renomée
295
Ich denke die Kosten bei 5nm haben ähnliche Entwicklung wie die vorherigen Generationen. Am Ende ist das wahrscheinlich auf Menge der Chips in ähnlichen Regionen und nur die einmaligen Kosten zum Design können das bei zu kleinen Stückzahlen zu teuer machen. Es wird in der Produktion wohl schneller gute Yields geben als 7nm.
PS5 soll auch einen Shrink in Design haben... Evtl. kann AMD Optimierungen im Design zwischen den ähnlichen RDNA Produkten austauschen bzw. wiederverwenden.

Die grosse Frage, die sich mir stellt ist, wie viel Bandbreite zwischen den Chiplets zur Verfügung gestellt wird und wie AMD den Bedarf mit Caches in Grenzen hält bzw organisiert.
 
Zuletzt bearbeitet:

sompe

Grand Admiral Special
Mitglied seit
09.02.2009
Beiträge
9.868
Renomée
467
Ich denke das ein entscheidener Punkt auch die Chip Ausbeute sein wird.
Kleine Chips sind von Angang an billiger zu produzieren weil sie einfach von Anfang an eine höhere Ausbeute besitzen da die Chance ganz einfach geringer ist das ein Defekt an der falschen Stelle ihn unbrauchbar macht oder einschränkt. Ein doppelt so großer Chip wäre dann z.B. unbrauchbar, bei einem halb so großen Chip vielleicht nur einer von beiden. Bricht man das jetzt noch auf 1/4 der Größe runter geht die Ausbeute natürlich entsprechend rauf.
Das ließe sich dann auch noch auf die Teildefekte übertragen. Damit ist für mich auch klar warum gerade nvidias Monster Chips so gern in gestutzer Form auf den Desktop Markt kamen. Zu viel Fläche bei der Fehler zu Teildefekten führen können und so am Ende kaum voll funktionstüchtige GPUs rauskommen, welche man wiederum für den professionellen Markt benötigt. Wenn sich die Fertigungsprozesse dann mit der Zeit eingearbeitet haben und die Anzahl an defekten sinkt nimmt natürlich auch die Anzahl der voll funktionstüchtiger Chips zu und noch komplexere Designs lassen sich dann überhaupt erst produzieren.
 

E555user

Vice Admiral Special
★ Themenstarter ★
Mitglied seit
05.10.2015
Beiträge
878
Renomée
295
Das mit der Chipausbeute bzw. Yields ist mehr oder weniger immer die gleiche Story.
Wichtig ist nur bei allen Unkenrufen zu 5nm und weniger, dass wir bereits bei 10nm und 7nm Warnungen zu Kosten pro Chip hatten, die sich kaum in der Realität manifestiert hatten, am Ende waren es hauptsächlich Probleme bei Intel die verallgemeinert wurden.

Bei dem Bild von D.Nenny aus dem SemiWiki Forum ergibt sich eine High Volume Manufacturing Übergangsphase gemäss ASML bei 0.1 Def. per qcm und das soll per August 2020 bereits erreicht worden sein (vermutl. für Apple). Eine andere Folie zeigt im zittierten Forum den HVM start schon 1Q früher bei etwas höheren Defects.
index.php


Wichtig ist nur, dass die Wafer noch weniger Defects aufweisen werden als mit 7nm (mehr EUV hat weniger Prozesschritte insgesamt) und das bei einem Ramp-Up mit grösseren GPU-Chiplets zu Einsparungen in Time2Market gegenüber 7nm führen sollte, bzw. sehr frühem HVM und damit geringeren Gesamtkosten.
Ich kenne jetzt die Apple 5nm Chipgrössen nicht. Sollten wirklich die RDNA3 CUs und der Rest einer GPU auf zwei Chiplets aufgeteilt werden würde der Compute Chiplet rund 2/3 des Platzbedarfs mitnehmen und in der 5nm Fertigung grob noch die Hälfte der Fläche eines akutellen Navi21 aufweisen. Auch das würde für gute Ausbeute in der Produktion sprechen. Beim Binning und SKU Zusammenstellung ergeben sich dann tatsächlich Möglichkeiten wie bei Ryzen: Einbussen bei Latenz und Fertigungsauwand mit Interposer, Gewinne bei Ausbeute pro Wafer und Takt bei kleineren Chiplets mit Binning-Optimierung für wenige Spitzenmodelle.
Allerdings wären bereits bei einem simplen Shrink von RDNA2 auch schon wesentliche Zugewinne beim Yield erzielbar, zusätzlich noch Takt. Es wird spannend werden wie AMD das Design letztlich festlegt, sicherlich wird man unterschiedliche Varianten testen. Bei Zen waren es zunächst vollständige SoC als Kombination, erst im zweiten Chiplet-Design mit separatem I/O Chiplet. Ich denke die Eigenschaften bzw. Anforderungen eines IF-Cache könnten hier massgebend sein. Man hätte den IF-Cache nicht für RDNA2 einführen müssen, es hätte konservativer bleiben können mit kleineren Die-Grössen ohne diesen Cache. Mit Blick auf Chiplet-CU war der IF-Cache nach meiner Einschätzung ein Schlüsselelement, das man schrittweise etablieren wollte.
 

Peet007

Admiral Special
Mitglied seit
30.09.2006
Beiträge
1.751
Renomée
16
Was ich so mitbekommen habe ist die Rede von 2x80 CU und 1xI/O Chiplets. Eine Fertigung für die ganze Bandbreite von Low bis HighEnd Grafikkarten.

Ich sehe da eher das Problem mit Microrucklern bei Zwei getrennten Chips. Ob man das endgültig gelöst hat?
 

E555user

Vice Admiral Special
★ Themenstarter ★
Mitglied seit
05.10.2015
Beiträge
878
Renomée
295
Ich denke die Microruckler waren eine Folge von Alternate Frame Rendering. Von der CPU bzw. Treiber wurden vollständige Bilder alternativ auf die eine oder andere GPU als Job vergeben inkl. doppeltem VRAM-Management. Wenn eine GPU schneller mit dem Bild fertig war als die andere (Temp./Volt/VRAM-Updates) haben diese Bilder auf der Zeitachse keine regelmässigen Abstände.
Bei einer Chiplet-GPU, die nach aussen nur als einheitliches Device sichtbar wird, ist die Jobverteilung bei der GPU, alle Verzögerungen sollten dann innerhalb eines Frames über eine Rerndersequenz hinweg gleichmässig auftreten. Entweder weil die Jobverteilung und Last gleichmässig ist oder sogar der Takt auf allen Chiplets gesynct wird. Ein gemeinsamer LL-Cache sollte dem auch entgegen wirken, d.h. die GPUs werden nicht zu unterschiedlicher Zeit im VRAM mit Updates druch die CPU versorgt, sondern teilen den Speicher und die Verzögerungen, die dort verursacht werden. Evtl. müsste der Speicherzugriff auf unterschiedliche Segmente gleich langsam stattfinden, damit es nicht zu Varianzen kommt wenn von Frame zu Frame die gleichen Jobs plötzlich von unterschiedlichen Chiplets berechnet werden.

Da die GPUs nicht durch eine CPU im Treiber synchronisiert werden sondern auf einem Interposer direkt das besorgen können müsste das m.M. nach zu verhindern sein.

(Vermutlich waren bei Mixed Rendering Setups auf Basis von DX12 oder Vulkan die Microruckler schon kein Problem mehr. Dort lassen sich gezielt Render-Targets auf einer GPU berechnen und auf der nächsten dann nach Übergabe der Zwischenergebnisse der Rest. Bevor der Frame ausgegeben wird kann erstere GPU schon wieder Vorberechnungen zum folgenden Frame machen. Die Jobverteilung erfolgt in der Engine, nicht im Treiber.)

Man hat schon bei GCN unterschiedlichen L1-Cache und Performance je Shader Engine via shared L2 synchronisiert. Die Aufgabe wäre also unterschiedlichen L2 eines CU-Chiplet durch einen LL IF-Cache synchron zu halten. Es müssten ähnliche Methoden im Scheduling angewendet werden.

Am Ende könnte die Verzögerung je Berechnung je Shader Engine grösser ausfallen während die Anzahl der Shader sich verdoppelt. Dann sehen wir evtl. Rückschritte in kleinen Auflösungen als Mindest-Frametime bzw. eine Art FPS-Mauer während sehr grosse Auflösungen profitieren.

PS: Microruckler durch SAM zu verhindern wäre noch eine interessante sehr theroretische Diskussion, die man mit einem AMD-Spezialisten führen könnte. Nach meiner Info schliesst sich X-Fire und RX-6000 aus.
 
Zuletzt bearbeitet:
Oben Unten