aldaric schrieb:
Woher weißt du wie die verschiedenen Architekturen performen? RDNA2 war ja schon leicht vor Ampere. Wer sagt das dieser Vorsprung nicht größer wird?
Er kann es nicht wissen und ich geb es an der Stelle auf ihm seine Denkfehler aufzuzeigen, weil es mehr Kraft kostet, als es nutzen hat.
AMD hat nun das Speicherinterface zusammen mit dem Infinity Cache ausgelagert, beides sind - wie hier oft erwähnt wurde, Komponenten, die nicht wirklich von kleineren Nodes gleichermaßen profitieren. Hier mal ein interessanter Text dazu und
welche Herausforderungen da so kommen. Grob und stark vereinfacht ausgedrückt - wenn jemand das da nicht lesen will: Um wirklich Vorteile beim SRAM zu bekommen, muss bei der Skalierung eher 0,5 erreicht werden als 0,3 wie aktuell üblich. Oder noch mal anders ausgedrückt: SRAM-Zellen in N7/N6 sind nicht wirklich schlechter als N5/N4, erst N3 würde wieder einen Unterschied machen.
Beim SI/MC kommt wiederum zum Tragen, dass dort entsprechend die Ausgänge in der Schaltung hat und man an der Stelle die Wege auffächern muss. Man hat auf einem Chip an der Stelle also tote Fläche, die man nicht nutzen kann und das teilweise auch ordentlich. Das sieht man sehr gut, wenn man sich mal die Dies von verschiedenen GPUs ansieht und feststellt, dass die Memory-Controller selbst in der Fläche kaum schrumpfen und über verschiedene Nodes immer recht ähnlich viel Platz einnehmen.
AMD lagert bei RDNA3 also all das aus, was ohnehin entweder nicht wirklich kleiner wird oder was vom N5 nicht wirklich profitiert. Es ist an der Stelle für die Leistung egal, ob man entweder die ca. 150 mm² (4 × 37,5 mm² bei Navi32) oder 225 mm² (6 × 37,5 mm²) auslagert oder direkt in die CPU mit aufnimmt. Kostentechnisch wiederum macht das einen gewaltigen Unterschied, weil man sich ca. ca. 1/3 bis 2/5 an Fläche sparen kann im teuren Prozess.
Und AMD muss auch NVIDIA bei der Größe des Dies nicht schlagen, um NVIDIA ggf. schlage zu können. Wenn es stimmt, was die Gerüchteküchen so aktuell verbreiten, dann werden die SM bei NVIDIA auf 2 × 64 + 1 × 32 ALUs aufgebohrt. 128 FP-ALU + 32 dedizierte INT-ALUs, NVIDIA kann damit zwar einen zweiten Datenpfad für FP nutzen, das ändert aber nichts an dem Problem, dass weiterhin die beiden FP-Datenpfade für die effektive Auslastung 64 Werte brauchen, ansonsten aber brach liegen. Den INT-Workload muss NVIDIA wiederum im Treiber anpassen und auf Wave32 "optimieren". Kein großes Problem, gleichzeitig muss NVIDIA hier aber wieder Komplexität schaffen.
AMD wird bei RDNA 3 bei den Vec32-ALUs bleiben und hat den Treiber auf Wave32 angepasst. Mit den nun pro CU vermutlich 2 weiteren Vec32-ALU und zwei weiteren Skalaren-Einheiten, muss AMD nicht viel am Treiber machen und kann nun pro CU wieder bis zu 4 Threads laufen lassen und bekommt im Zweifel auch eine 3:1 Aufteilung für die Workloads bei Spielen hin: 1 Thread mit bis zu 32 INT-Werte, 3 Threads mit bis zu 32 FP-Werte. Dazu kann AMD auf die Workloads wesentlich flexibler reagieren, auch eine 2:2, 1:3 oder 4:0 und 0:4 ist möglich.
Auch wenn 4K und auch 8K später mehr Werte liefern, auch pro Thread, ist es in der Entwicklung der Grafikengines dennoch so, dass nicht unbedingt "viel" mehr Werte pro Thread zusammen kommen, aber durch immer mehr Details immer mehr Threads.
NVIDIA wird bei 128 SM - AD102 - mit der aktuellen Konfiguration 256 Threads zu 64 Werten und 128 Threads zu 32 Werten benötigen, als im ganzen 384. AMD 384 Threads zu 32 Werten. AMD kann seine Grafikkarte daher "einfacher" auslasten und Ressourcen auch bei Bedarf besser und feiner granuliert verteilen.
Der "primäre" Vorteil - und die Anführungszeichen sind Absicht - sind die Tensore-Kerne bei NVIDIA, gleichzeitig wird dieser Vorteil hier von sehr vielen massiv überschätzt, ebenso dass sie theoretisch auch bereits parallel arbeiten könnten. NVIDIA hat 2018 zu Turing ein paar Timelines für Frames veröffentlicht, auch bereits mit DLSS, die sehr gut zeigen, in den Abschnitten, in denen die RT-Kerne als auch die Tensore-Kerne arbeiten, quasi die restliche GPU sich weit gehend langweilt. AMDs Überlegung, die Vec32 für "Matrix"-Operationen vorzubereiten, könnte genau die richtige Entscheidung sein, weil man damit zwar etwas die Vec32 "aufbläht" sich den Platz aber für dedizierte Matrix-Cores sparen kann.
Und für weitere Sachen, die KI benötigen, könnte man über kurz oder lang in einem AMD-System dann zukünftig die integrierte GPU nutzen.
Novasun schrieb:
AMD`s Ausbeute dürfte doppelt so schlecht ausfallen - bezogen auf fehlerhafte Chips wie bei NVIDIA und man hätte Kostengleichstand!
In dem Fall: Die Ausbeute müsste MINDESTENS doppelt so schlecht ausfallen, in der Regel dürfte sie sogar ein Stück schlechter ausfallen, bevor man Kostengleichstand hätte. Ich drücke es mal mathematisch aus: x mm² = n Chips ⇾ x/2 mm² = 2 × n + m Chips, wobei m >= 0.
Für AMD könnte das wirklich der entscheidende Punkt sein, dass man ggf. die Preise auch nach "unten" korrigieren kann und man dennoch die Chips mit Gewinn verkauft. 63585
300 mm Wafer bieten ca. 70650 mm². 10 % der Fläche ist "pauschal" tot - ich habe jetzt keine Lust 600 mm² und 300 mm² darauf zu verteilen, daher sind die Zahlen UNGENAU: NVIDIA bekommt mit 600 mm² 105 Chips heraus, AMD mit 300 mm 211 (das beschriebe m > 0). Wir lassen die Yieldrate auch weg: NVIDIA zahlt pro Chip bei 17000 $ pro Wafer 162 $, AMD zahlt 81 $.
Jetzt müssen wir bei AMD noch den MC-Chip dazu zählen: Pro Wafer können 1695 MC gewonnen werde, der Wafer kostet 9000 $, macht dann 6 $ pro MC. Es kommen bei AMD also noch mal 36 $ dazu. Navi31 kostet also 117 $ gegen 162 $. NVIDIA ist also in der Produktion schon mal 38 % teurer und wir haben Yields herausgelassen und pauschal 10 % tote Fläche angenommen, die aber bei kleineren Dies eher sinkt.
AMD wird bei einer Marge von 45 % also Navi31 ab ca. 200 $ ihren Partnern anbieten können, NVIDIA muss bei 45 % Marge ab 300 $ starten müssen.
Natürlich sind die Preise als Tendenz zu verstehen!