News Navi 31, 32 und 33: Handfeste Gerüchte zu AMDs Radeon RX 7000 mit RDNA 3

Man sieht ja bei den derzeitigen Karten, dass der Cache in hohen Auflösungen eine breitere Speicheranbindung nicht ersetzen kann.
Da der Einsatzzweck der großen Karten aber in Richtung hohe Auflösungen geht, ist eher eine breite Speicheranbindung notwenig.
Ich denke die 384Bit Anbindung würde auch für 2x Navi 31/32 reichen, weil es auch genug Dinge gibt, die Rechenleistung benötigen und nicht unbedingt von viel mehr Speicherbandbreite profitieren (Raytracing evtl).
 
stefan92x schrieb:
Packaging ist aber bei AMD aufwändiger, was einen Teil dieses Unterschieds wieder aufwiegen dürfte.
Meine Rechnung ist eine sehr grobe Schätzung. Ich habe pauschal 10 % tote Fläche angenommen. Bei kleineren Chips kommt das gut hin, weil man auch den Verschnitt einplanen muss, bei größeren Chips nimmt die tote Fläche tendenziell zu und liegt auch mal bei 15 - 20 %. Es wäre genauer gewesen, wenn ich für die kleinen 10 % zusätzliche Fläche für den Schnitt sowie 5 % tote Flüche angenommen hätte, während ich bei den 300 mm² und 600mm² 5 % Fläche für den Schnitt und 10 % sowie 15 % tote Fläche angenommen hätte.

Deswegen sind die Preise bei beiden Herstellern als untere Grenze zu verstehen. Zudem habe ich bei beiden Herstellern die Preise nach oben gerundet, so dass das Packaging bei beiden inklusive ist, bei AMD sind es die die 7 Chips auch 7 $ die ich höher bin, bei NVIDIA 1 $, das sollte den Unterschied zumindest symbolisieren.
ETI1120 schrieb:
Was man aber auch noch berücksichtigen muss sind die Kosten für F&E und das Chipdesign.
Ich hätte an der Stelle wohl erwähnen sollen, dass die 45 % die Bruttomarge sind und nicht die Nettomarge die ganz am Ende bei rum kommen soll.

Weder Intel, NVIDIA noch AMD und auch die meisten anderen Hersteller wälzen die Kosten für Forschung, Entwicklung und Design nicht als einen festen Prozentsatz auf das Produkt um, sondern die F&E sind in der Bruttomarge bereits mit drin. Vorallem, weil ja dieser Kostenanteil pro Chip mit der Zeit immer weiter sinkt und "theoretisch" irgendwann gegen Null tendiert.

An der Stelle ist also: Nein, F&E und auch das Chipdesign muss man an der Stelle nicht berücksichtigen. Die Kosten gehen anschließend von der Bruttomarge ab als weitere Kosten und am Ende steht dann die Netto-Marge.
ETI1120 schrieb:
Und ist Nvidia tendentiell im Vorteil. Nvidia setzt höhere Stückzahlen ab, und kann diese Kosten auf viel mehr GPUs als AMD verteilen.
Richtig, wobei man hier dann eher sagen muss, dass NVIDIA schneller den Punkt erreicht, an dem F&E irgendwann keinen nenneswerten Anteil an Kosten des Chips mehr hat.

Und für die unter euch, die mir das nicht glauben: Wenn AMD für Navi3x als ganzes ca. 250.000.000 Dollar hatte - nur geschätzt - dann müsste 1.250.000 Chips absetzen, dass die Entwicklungskosten wieder drinnen sind. Ab dem Punkt finanziert das Produkt dann die "zukünftige" Entwicklung und liefert Gewinn. Und das ist jetzt wirklich GANZ grob gerechnet.

ETI1120 schrieb:
Ich gehe auch davon aus, dass AMD die Gaming GPUs auch für ML Training oder ML Inference nutzen will. Es wäre schade dieses Potential nicht zu berücksichtigen.
@Colindo hatte doch ein Patent von AMD erwähnt oder war es ein Vorhaben, dass AMD die Shader mit einigen zusätzlich Fähigkeiten ausstatten will oder besser dafür nutzbar machen will. Ich erwähnte darauf hin, dass es durchaus möglich ist, die Vec32-ALUs um entsprechende Schaltungen für eine Matrix-Berechnung zu erweitern, in dem ein weitere Schaltungspfad eingeführt wird, der dann ein Matrix-MAD ausführen kann.

Das ist auch die Grundlage, die ich hier erwähne. Es geht jetzt nicht darum, dass ich die "Effektivität" der Tensore-Kerne in Frage stellen, sondern ob AMD in RDNA wirklich "dedizierte" Hardware braucht, oder ob eine Verbesserung an den Shadern ausreichend sein kann, wenn genug TOPS dabei herum kommen.
Ergänzung ()

stefan92x schrieb:
Denn wenn man den Cache sogar noch verbessert hat, so dass er kleiner ausfallen kann, kann die Bandbreite nicht wirklich ein Problem sein.
Ich muss mich an der Stelle wohl etwas präziser Ausdrücken, damit wir da nicht uns in falsche Richtungen entwicklen.

Bei RDNA2 sollte der Infinity-Cache primär das SI von der Bandbreite her entlasten. Navi21, Navi22 und Navi23 "verhungern" praktisch, da das SI nicht genug Bandbreite liefert. Der Cache muss, um die Bandbreite kompensiere zu können, selbst eine gewisse Bandbreite zum L2-Cache haben und ebenso muss er eine gewisse Größe haben, so dass er genug Daten vorhalten kann.

Bisher ging man bei Navi31 erneut von einem 256 Bit SI aus und ebenso - noch wichtiger - war bis vor kurzem sogar das Gerücht, dass es zwei GCDs gibt. Man hätte hier durch weitere Optimierungen - AMD sprach ja bereits an, dass man Spiele, aber auch am Treiber noch einiges machen kann mit dem Infinity Cache - durchaus etwas an Menge "sparen" können, gleichzeitig hätte es aber auch mehr Bedarf an Infinity Cache gegeben, da mehr Daten hätten vorgehalten werden müssen, da gewisse Daten wegen temporalen Effekten und Co, teilweise aus dem gesamte Bild benötigt werden.

Navi31 hat jetzt aber nur ein GCD und dazu wächst das SI um 50 % an. Dazu kommt dass man statt 16 GBit/s(?) pro Baustein, sondern nun wohl 20 GBit/s hat. Es kommen also ca. 25 % durch den RAM dazu und 50 % durch das breitere SI. Das Thema "Bandbreite" rückt beim Infinity Cache etwas in den Hintergrund, es gewinnt an dieser Stelle aber das Thema Latenz etwas an Bedeutung - auch wenn ich vorher erklärt habe, dass Latenz für die GPU nicht der entscheidente Faktor ist, weil man gut vorplanen kann.

Natürlich spielt die Latenz dennoch eine gewisse Rolle, weil man ja anhand der Latenzen auch in die Vorplanung mit einbeziehen muss. In diesem Fall wird der Infinity Cache vermutlich nur sekundär die Bandreite kompensieren, sondern wird primär dazu dienent, dass man Anfragen entsprechend puffert und damit die Latenzen eben gleich hält. Da man weniger Bandbreite kompensiert, kann der Cache daher entsprechend kleiner ausfallen.

Ich hab es bereits mehrfach erwähnt - primär im Zusammenhang mit CPUs: Cache ist keine Wunderwaff und es bringt auch nicht wirklich etwas pauschal einfach mehr Cache hinzuzufügen. Caches müssen in der Regel für ihr Augabengebiet entsprechend dimensioniert werden und dürfen nicht zu klein sein. Ab gewissen Größen verpufft der Effekt wiederum und verursacht nur kosten.

Und für die, die meinen dass die 128 MiB Infinity Cache nicht genug wären für 4K und Navi21 deswegen von der Ampere eingeholt und geschlage wird: Nein, das ist nicht der Grund. Ampere kann - wie damals Vega - mit höheren Auflösungen nur besser seine Schlagkraft auf die Straße bringen.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Colindo
DevPandi schrieb:
Ich hätte an der Stelle wohl erwähnen sollen, dass die 45 % die Bruttomarge sind und nicht die Nettomarge die ganz am Ende bei rum kommen soll.
Es ging mir nur darum, dass die Produktionskosten nicht der einzige Kostenfaktor sind.
DevPandi schrieb:
An der Stelle ist also: Nein, F&E und auch das Chipdesign muss man an der Stelle nicht berücksichtigen. Die Kosten gehen anschließend von der Bruttomarge ab als weitere Kosten und am Ende steht dann die Netto-Marge.
Die Operation Expenses lagen im Q2 2022 bei ca 24,5%.

Aber der Prozentsatz hängt entscheidend vom Umsatz ab. Wenn der Umsatz einbricht steigt der Anteil der Operation Expenses rasant an.

DevPandi schrieb:
Und für die unter euch, die mir das nicht glauben: Wenn AMD für Navi3x als ganzes ca. 250.000.000 Dollar hatte - nur geschätzt - dann müsste 1.250.000 Chips absetzen, dass die Entwicklungskosten wieder drinnen sind.
Bei der Elektronik macht es alleine die Masse. Je höher die Stückzahlen, desto weniger fallen die Entwicklungs- und Designkosten ins Gewicht.

Allerdings die 250.000.000 USD genügen IMO nicht annähernd. Alleine die Kosten des Chipdesign dürften erheblich höher liegen.

Eine sehr gern kopierte Graphic von International Business Strategies, sie zeigt die Designkosten eines Chips bei verschiedenen Nodes.
1660943383924.png

DevPandi schrieb:
@Colindo hatte doch ein Patent von AMD erwähnt oder war es ein Vorhaben, dass AMD die Shader mit einigen zusätzlich Fähigkeiten ausstatten will oder besser dafür nutzbar machen will.
AMD will die Shader effektiver für Matrixmultiplikationen einsetzen. So wie ich es verstehe, geht es um den Scheduler.
Aus dem Patentantrag US 2022/0138002 A1
1660943785154.png

To support recurrent matrix multiply operations , the scheduler 104 logically divides the CUs of the GPU into subsets, designated CU subsets 110-113 . It will be appreciated that in other embodiments the scheduler 104 logically divides the CUs into more or fewer subsets . As used herein , a subset refers to a set including some , but not all , of the CUs of a a GPU . Thus, for example , in an embodiment wherein the GPU 100
includes a total of 128 CUs , each of the CU subsets 110-113 includes a different set of 32 CUS , and each of the 128 CUs is in a a different one of the CU subsets 110-113 .
[ 0013 ] In some embodiments, a kernel logically divides each CU subset 110-113 into smaller subsets , referred to herein as CU clusters for clarity . It will be appreciated that in some embodiments, different operations of the scheduler 104 can be performed by a hardware scheduler , by software scheduling operations , or a combination thereof . As used herein , a CU cluster is a set of CUs that includes some , but
not all of the CUs of a CU subset. For example , the CU subset 110 includes CUS 105-108 , wherein CUs 105 and 106 are included in one CU cluster ( designated CU cluster 109 ) while CUs 107 and 108 are included in a different CU cluster of the CU subset 110. In the above example where each of the CU subsets 110-113 includes 32 CUS , each CU cluster includes 8 CUs of the corresponding CU subset , with each
CU included in a different CU cluster .

DevPandi schrieb:
Das ist auch die Grundlage, die ich hier erwähne. Es geht jetzt nicht darum, dass ich die "Effektivität" der Tensore-Kerne in Frage stellen, sondern ob AMD in RDNA wirklich "dedizierte" Hardware braucht, oder ob eine Verbesserung an den Shadern ausreichend sein kann, wenn genug TOPS dabei herum kommen.
AMD will bei den Gaming GPUs keine Chipfläche für Matrixeinheiten opfern. Da war Sam Naffziger ganz eindeutig. AMD geht davon aus, dass bei typischen Lasten die Matrixeinheiten nicht ausreichend genutzt werden.
 
  • Gefällt mir
Reaktionen: Colindo und mr_clark
ETI1120 schrieb:
dass bei typischen Lasten die Matrixeinheiten nicht ausreichend genutzt werden.
Was ja auch stimmt, wenn man sich mal die Render-Timelines bei Spielen ansieht, auch mit DLSS und was wann wie gefordert wird. Die FP/INT-Belastung nimmt in der Zeit, in der die Tensore-Kerne rechnen drastisch ab und macht vielleicht 5 - 10 % der Rechenlast aus.

Auch AMDs Idee, die TMU "teils" für RT "zweckzuentfremden" ist nicht doof, weil, man entweder das die RT-Berechnungen macht oder die Textur benötigt.

AMD ist echt versucht so viele Gemeinsamkeiten wie möglich zu finden.
 
zeedy schrieb:
Zum einen die winzigen Infinity Caches. Wie soll das denn gut gehen?

Und dann noch die Chipgrößen. Navi 33 in N6 soll also deutlich kleiner sein als Navi 23 bei doppelter ALU Anzahl bei ansonsten gleich bleibender Busbreite und Infinity Cache?
Die winzigen Infinity Caches wurden ja schon erklärt. Verbesserter Caching-Algorithmus --> weniger L3-Cache für gleiche Auflösung benötigt. Den gestiegenen Bedarf an Bandbreite erledigt das größere SI.

Bei den Chipgrößen scheinst du die Essenz des Artikels nicht mitbekommen zu haben, nämlich dass AMD explizit die Shader so verbessert hat, dass sie deutlich weniger Chipgröße benötigen. Es wird also alles etwas günstiger in der Fertigung
Rock Lee schrieb:
sag ich ja. Ergibt überhaupt kein Sinn. Logische Konsequenz wären 512-Bit. Sonst hätte man ein Single Navi32 auch mit 192-bit bringen können.
Spricht ja nix dagegen, bei einem 2x Navi 32 den V-Cache zu benutzen. Dann hätte das Modell weiterhin 384 bit (die Anzahl an MCDs ist ja variabel), aber eine höhere Trefferquote im L3-Cache und damit effektiv eine höhere Bandbreite. Das Ganze dann als 8K-Karte vermarktet mit extra viel Speicher, fertig ist die Laube.
DevPandi schrieb:
Grafikkarten arbeiten auch heute nach einem In-Order-Prinzip und auch heute schickt der Grafikkartentreiber rechzeitig passende Ladeanweisungen an die GPU, so dass sie die Daten aus dem VRAM holen kann.
Völlig richtig. Außer für einige wenige RT-Algorithmen ist die Latenz des VRAMs unwichtig. Deswegen wird der ausgelagerte MCD da keine Probleme bringen.
phanter schrieb:
Chiplets können einen Vorteil haben wenn die Gesamtfläche steigt. TUT SIE ABER NICHT
Du hast die Essenz des Artikels wohl auch nicht mitbekommen. AMDs 300mm² in N5 könnten deutlich mehr Leistung liefern als Nvidias 300mm² in N4, wenn AMD als einzige diese massive Verkleinerung der Shader hingekriegt hat. Und deswegen ist dein Vergleich bezogen auf Leistung nicht haltbar.
ETI1120 schrieb:
Im Grunde überrascht es mich sehr, dass AMD auf 92 MByte Infinity Cache zurückgeht, und gleichzeitig eine Speicheranbindung mit 384 Bit macht. Und zusätzlich soll 192 MByte Infinity Cache nicht viel bringen.
Das ist der einzige Punkt bei den Ausführungen bei denen ich ins Grübeln komme.
Es ist schon echt komisch, das so zu lesen. Vielleicht ist diesmal die Steigerung des SIs günstiger als eine Steigerung des L3-Caches? Und die 192 MB bringen nichts, außer man geht auf 2x Navi 32?
 
  • Gefällt mir
Reaktionen: ETI1120
Colindo schrieb:
Völlig richtig. Außer für einige wenige RT-Algorithmen ist die Latenz des VRAMs unwichtig. Deswegen wird der ausgelagerte MCD da keine Probleme bringen.
Ich erwarte hier keine viel größere Latenz. Die reine Distanz hat sich praktisch nicht verändert lediglich ein paar Übergänge könnten sich auswirken.

Außerdem behauptet der Artikel dass die Bandbreite zwischen Grafik und Infinity Cache (MALL) gesteigert wurde. Das legt nahe, dass die Anbindung über das FanOut hervorragend ist.

Colindo schrieb:
Es ist schon echt komisch, das so zu lesen.
Das ist das Ergebnis von nachgrübeln. Wenn Navi 31 wirklich ein SI von 384 Bit benötigt, dann wird das weitere Skalieren problematisch.

Außerdem hatte ich das folgende Diagramm Kopf:
1661029320558.png


Der Anstieg der Hitrate bei HD flacht bei über 64 MByte ab.
Der Anstieg der Hitrate bei 1440p verläuft deutlich flacher und scheint bei 96 MByte abzuflachen, hier unbedingt die Interpolation ignorieren, da sie eine falsche Tangente bei 128 MByte vorgaukelt.
Der Anstieg der Hitrate bei 4 K verläuft sehr flach, hat im beim Sprung von 96MByte und 128 MByte von allen 3 Auflösungen den größten Anstieg der Hit Rate.

Auf der anderen Seite hatte AMD mit der neuen Packaging das ideale Testvehikel SpeicherInterface und Infinity Cache auszutesten. Also dürfte AMD nun Datenpunkte bis 288 MByte haben.

Zusätzlich zur effektiveren Nutzung des Platzes kommt noch, dass laut Artikel der Mehraufwand bei einem Cache Miss verringert wurde.
Colindo schrieb:
Vielleicht ist diesmal die Steigerung des SIs günstiger als eine Steigerung des L3-Caches?
Kann ich mir eigentlich nicht vorstellen, da dies die Boards erheblich komplexer macht.
Colindo schrieb:
Und die 192 MB bringen nichts, außer man geht auf 2x Navi 32?
Im Artikel steht, dass 192 MByte wenig bringt, allerdings steht auch dass es bei Navi 31 2 Varianten für den Inifinity Cache gibt mit 96 MByte (0-hi) und 192 MByte (1-hi). Bei Navi 32 steht ausdrücklich dass es keine Variante mit 1-hi gibt.

Eines hatte ich vollkommen ignoriert. Vielleicht hält AMD 24 MByte Grafikspeicher für erforderlich, dann bleibt nichts anderes übrig als das Speicher Interface zu verbreitern. Ich müsste nicht dass 3 GByte-Chips verfügbar sind.
 
ETI1120 schrieb:
Außerdem behauptet der Artikel dass die Bandbreite zwischen Grafik und Infinity Cache (MALL) gesteigert wurde.
Das würde ich aber durch eine erhöhte Taktrate des L3-Caches und damit einer gesteigerten Cache-Bandbreite bereits als erfüllt ansehen. Dann muss die Anbindung per FanOut solch hohe Bandbreiten nur unterstützen, sie kommen aber von den Fähigkeiten des Caches.
 
Colindo schrieb:
Das würde ich aber durch eine erhöhte Taktrate des L3-Caches und damit einer gesteigerten Cache-Bandbreite bereits als erfüllt ansehen. Dann muss die Anbindung per FanOut solch hohe Bandbreiten nur unterstützen, sie kommen aber von den Fähigkeiten des Caches.
Das "nur unterstützen" ist in dem Zusammenhang das Entscheidende. Das bedeutet das FanOut begrenzt die Anbindung des Caches nicht.
 
  • Gefällt mir
Reaktionen: Colindo
ETI1120 schrieb:
Außerdem hatte ich das folgende Diagramm Kopf:
AMD hat Erfahrung mit RDNA2 gesammelt und für RDNA3 soll es Änderungen beim caching geben und AMD soll besser kontrollieren können, was im Cache landet und was nur im RAM vorhanden sein wird.

Daten die zu Beginn eines Frames erstellt werden und am Ende einmal gelesen werden müssen, profitieren nicht vom Cache und blockieren ihn nur.
Daten die ständig gelesen werden profitieren entsprechend stark vom Cache.
Wenn man also besser kontrolliert, was im Cache landet, ist auch für höhere Auflösungen ein kleinerer Cache ausreichend.
 
whyme schrieb:
AMD hat Erfahrung mit RDNA2 gesammelt und für RDNA3 soll es Änderungen beim caching geben und AMD soll besser kontrollieren können, was im Cache landet und was nur im RAM vorhanden sein wird.

Wenn man also besser kontrolliert, was im Cache landet, ist auch für höhere Auflösungen ein kleinerer Cache ausreichend.
Das ist klar. Und das hat Sam Naffziger auch so gesagt.
Naffziger deutete Design-Entscheidungen an, bei denen AMD bessere Wege zur Optimierung der Cache-Nutzung gefunden hat, einschließlich des Ausschlusses bestimmter Dinge, die in der Regel nicht vom Caching profitieren (Naffziger erwähnte Display-Interface, Multimedia-Verarbeitung und Audio-Verarbeitung als Arbeitslasten, die vielleicht nicht im Infinity-Cache gespeichert werden müssen - einige von ihnen könnten den gesamten Cache, den sie benötigen, vom L2-Cache erhalten).

Übersetzt mit www.DeepL.com/Translator (kostenlose Version)

Die Frage war aber, warum verkleinert AMD den Infinity Cache und verbreitert das Speicherinterface. Wenn man nur die Bandbreite berücksichtigt erscheint das unlogisch, aber wie gesagt gibt es auch andere Faktoren.
 
Otsy schrieb:
Ist das so?

Anhang anzeigen 1251142

Vielleicht solltest du das nochmal durchdenken. So von vorne bis hinten.
3060Ti vor 6800XT, steht auch auf einem Bild... Ist mir aber auch ehrlich gesagt egal, was du denkst. Mein System besteht komplett aus AMD und die 6800XT ist meine erste AMD seit vielen Jahren, weil ich nie wirklich zufrieden mit AMD früher war. Nach einem Ausflug jetzt bin ich das auch weiterhin nicht und AMD fliegt bei den Grafikkarten für die nächsten Jahre wieder raus, ganz einfach.
 
Iconoclast schrieb:
3060Ti vor 6800XT, steht auch auf einem Bild... Ist mir aber auch ehrlich gesagt egal, was du denkst.

3060 Ti ≠ 3060
 
Iconoclast schrieb:
3060Ti vor 6800XT, steht auch auf einem Bild... Ist mir aber auch ehrlich gesagt egal, was du denkst. Mein System besteht komplett aus AMD und die 6800XT ist meine erste AMD seit vielen Jahren, weil ich nie wirklich zufrieden mit AMD früher war. Nach einem Ausflug jetzt bin ich das auch weiterhin nicht und AMD fliegt bei den Grafikkarten für die nächsten Jahre wieder raus, ganz einfach.
Wieso fliegt die wieder raus? Wenn man die RT Leistung der AMD Karten außer acht nimmt, sind die AMD Karten doch um einiges Interessanter als die von Nvidia.
 
iSteven schrieb:
Wieso fliegt die wieder raus? Wenn man die RT Leistung der AMD Karten außer acht nimmt, sind die AMD Karten doch um einiges Interessanter als die von Nvidia.
Ich möchte aber gerne RT nutzen wo es geht. Habe das auch damals direkt bei BF5 genutzt. Enthusiasten Kram halt. Es würde ja auf AMD Karten gehen, wenn nur FSR nicht so abgrundtief schlecht aussehen würde gegenüber DLSS.
 
HOFFENTLICH bleiben die Preise schön oben!! Dann ist wenigstens die Verfügbarkeit besser!
Habe mit meiner RX 6900 XT LC auf eine RX 7900 XT gespart und auf Urlaub verzichtet! (mir sin doch net bei arme Leute hier!) Quatsch, ich verdiene keine 1800€ netto, lebe alleine in meiner kleinen Wohnung, brauche nur kein Auto und arbeite vollzeit.

Kanns kaum erwarten das baby direkt zu besorgen und meine erste GPU mit Wasserblock selbst zu bauen und mit dem NexXxoS XT45 Quad 480/560mm Kupfer Radiator ganz alleine zu kühlen...lecker!

Auch wenn die über 1200€ kosten wird, besorge ich mir die RX 7900 XT mit Vergnügen, auch wenn die RT Leistung schlechter wird wie bei der RTX 4090 und verkaufe meine Asus Rog Strix RX 6900 XT LC Top.

Übrigens, SELBSTVERSTÄNDLICH wird die RX 8900 XT bei Release auch besorgt und die RX 7900 XT wieder verkauft :D
 
Zuletzt bearbeitet:
Zurück
Oben