News AMD Radeon RX 7800 (XT): Es tut sich etwas in der RDNA-3-Gerüchteküche

[Blood011]

AMD hat damit wieder mal nix gegen NV in der Hand schade.

FSR3 lässt ja auch auf sich warten da kommt auch nix mehr......

 

[BAR86]

das wird schon noch kommen, auch bei FSR hat mans angekündigt, dann war lange stille und plötzlich wars da.

 

[ETI1120]

Ich hab bei RDNA3 auch noch eine andere Vermutung, die nicht unbedingt ein Hardwarebug ist und warum die GPU in Compute-Workloads locker die 3 GHz schafft, während es bei Spielen nicht so ganz klappt.

Und sich bei vielen dieser Workloads der theoretischen Rechenleistung ziemlich annähert. D. h. hier bringt Dual Issue tatsächlich einen deutlichen Performancezuwachs.

Meiner Meinung nach hat AMD damit gerechnet, dass Dual Issue bei den Spielen mehr bringt. Auch hier gilt, das kann man bereits im Vorfeld prüfen kann, wie gut die Compiler bei bestehenden Games von Dual Issue Gebrauch machen.

Was mich aber verwirrt ist, dass wenn Dual Issue tatsächlich aktiv ist, eigentlich mehr Transistoren aktiv sein müssen. Damit sollte die Power höher sein und der erreichbare Takt bevor man ins Powerlimit reinläuft eher niedriger sein, als wenn Dual Issue nicht aktiv ist.

Ich denke nicht, dass es 1 Fehler ist, da spielen mehrere Sachen rein.

Davon abgesehen, selbst wenn jeder Shader nur einen Fehler hätte, dann hat die GPU nicht einen Fehler, sondert sie hat viele tauschend Fehler.

a = a + b * c.

D = A + B * C kann man nur machen, wenn man 3 Operanten übergeben kann => V_FMA_F32

Bei VOP2 gibt es Varianten davon, unter anderem
D = A * B + D => V_FAMC_F32

Das Hauptproblem ist hier aktuell eher, dass RDNA 3 aktuell 2 Wortbreiten*) kenn: 32 Bit und 64 Bit. Viele VOP2-Befehle unterstützen auch das VOP3-Format - was wir ja dann als FMA3/FMA4 "kennen" bei Intel und AMD für die x86.

Aus RDNA 3 Instruction Set Architecture Reference Guide

Dual Issue muss 64 Bit haben wenn zwei 32 Bit Befehle darin kodiert werden sollen.

Von den Anzahl der Bits sollten eigentlich auch 2 VOP1 bzw. 2 VOPC Befehle umsetzbar sein. Für 2 VOP3 reichen 64 Bit allerdings nicht aus.

VOP3 hat bei weitem den größten Befehlsumfang.

Die VOPC-Befehle stehen auch noch Mal als VOP3SD zur Verfügung.

Und Dual Issue unterstützt nur den kleineren Teil der Befehle, die für VOP2 zur Verfügung stehen.
Dabei ist die Abdeckung für F32 recht gut. Aber die Befehle für F16 und Integer fehlen weitgehend.

Außerdem stehen bei Dual Issue keine Vergleichsoperationen und mathematische Standardfunktionen zur Verfügung.

Mit Dual Issue kann man nur den Bruchteil dessen Umsetzen das mit einem zweiten Shader möglich wäre.
Das ist nicht verwunderlich, weil AMD für Dual Issue deutlich weniger Transistoren inverstiert hat, als es beim Verdoppeln der Shader erforderlich wäre. Aber wenn man sich die Zahlen für die RX7600 anschaut kommen Zweifel auf, dass sich die Transistoren für Dual Issue über alle Games betrachtet tatsächlich lohnen.

*) die variable Breite ist übrigens der Hauptgrund warum UTF8 von vielen Leuten bevorzugt wird. Texte mit westlichen Sprachen sind sehr viel kompakter als es mit UTF16 möglich wäre. UTF32 das Fixed Lenght ist, wird praktisch nicht verwendet.

 

[Holgmann75]

Hier stand Blödsinn.... 🤐 🤦‍♂️

 

[Vitche]

Ich weiß ja nicht ob das hier schon verlinkt oder angesprochen wurde, aber Igor gibt einen Ausblick auf die 7800XT anhand der Radeon Pro W7800:
https://www.igorslab.de/amd-radeon-rx-7800xt-als-radeon-pro-w7800-im-test/

... dem hab ich einen ganzen Abschnitt der News gewidmet, in deren Kommentarthread du dich gerade befindest.

 

[Holgmann75]

Okay... es ist sehr Früh, ich habe kaum geschlafen und die News nicht nochmal gelesen... 🥴
Ich gehe mich dann mal schämen und danach schlafen... 🤦‍♂️ 🤐

 

[Pro_Bro]

@yamiimax
Die 4070 Ti ist für die gebotene Gamingleistung einfach zu teuer. Ich persönlich habe mir zwar trotzdem kürzlich eine gegönnt, da sie ich von der Computing-Performance und dem niedrigen Stromverbrauch (185 Watt mit 65% Powerlimit und dank 180 MHz OC kaum Performanceverlust) profitiere und sie super leise betreiben kann, aber allgemein halte ich sämtliche RTX 40XX-Karten für zu teuer aktuell.

Die RX 7800-Karten könnten da ganz gut Druck auf die 4070 (Ti) ausüben, von daher bleibt es durchaus sehr interessant, wie diese bepreist werden.

Die 4070 Ti ist 20% schneller als die 7800xt, wenn diese knapp an die 6900xt rankommt. Das übt eher Druck auf die noch verfügbare alte AMD Generation aus die ja Leistungsmäßig der Konkurrent ist.

Hab für die 4080 auch ein Profil mit oc und gesenktem PL laufen, 250 Watt Limit ohne Leistungsverlust, echt krass wie effizient ADA ist, läuft auch sehr leise und kühl. AMD hat es da mit der aktuellen Generation echt vergeigt, mal abgesehen von den versprochenen und nicht gelieferten Features^^

 

[syfsyn]

Die rx 7800xt kämpft gegen die rtx4070 und wird definitiv nicht über 600€ kosten
allerdings ist nicht klar ob der n31 drin ist mit 70cu oder doch der vollausbau des n32 mit 60cu macht mal locker 17% aus.
Erstere wird die rtx4070 zersägen

 

[yamiimax]

Wenn man günstige Karte will, einen RTX nicht juckt und gute Leitung bzw vram will wird die Karte mal so einschlagen hehe


... nur wann kommt die im Herbst?

Ergänzung (27. Juni 2023)

Die 4070 Ti ist 20% schneller als die 7800xt, wenn diese knapp an die 6900xt rankommt. Das übt eher Druck auf die noch verfügbare alte AMD Generation aus die ja Leistungsmäßig der Konkurrent ist.

Hab für die 4080 auch ein Profil mit oc und gesenktem PL laufen, 250 Watt Limit ohne Leistungsverlust, echt krass wie effizient ADA ist, läuft auch sehr leise und kühl. AMD hat es da mit der aktuellen Generation echt vergeigt, mal abgesehen von den versprochenen und nicht gelieferten Features^^

Schön aber die 7800xt wird nur 600 kosten als preislich eher ein Konkurrent zur 4070

- rtx ist nur spielerei

- DLLS3 und FG unterstützen kaum Spiele

- VRAM ist n joke bei der 4070

+ P/L Sieger

+ VRAM genug

+ wohl um einiges besser als die 4070


Aber klar beide haben verstümmelte Karten rausgebracht

 

[DevPandi]

Und sich bei vielen dieser Workloads der theoretischen Rechenleistung ziemlich annähert. D. h. hier bringt Dual Issue tatsächlich einen deutlichen Performancezuwachs.

Vielleicht, Vielleicht auch nicht! Hier muss man jetzt tatsächlich genau aufpassen, denn - schön dass du auch das Whitepaper mit anführst - die neuen ALUs haben ja aktuell theoretisch drei Modi:

Vec32 - Ein Takt für ein Wave32, oder zwei Takte für ein Wave64.
Vec64 - Ein Takt für Wave64
Vec32+32 (Dual Issue) - 1 Takt für 2 Wave32, sofern es entsprechend den Befehlsparen zusammen passt.

Viele der Computeworkloads sind immer noch auf Wave64 ausgelegt, in dem Fall bringt also die eigentliche Dual-Issue-Fähigkeit nicht viel, sondern dass man eine "Vec64" hat.

Das will ich nur mal andeuten, weil das auch für die weitere Betrachtung wichtig ist.

VOP3 hat bei weitem den größten Befehlsumfang.

Ja, VOP3 hat in dem Fall den größten Umfang, dass ist richtig. Aber - jedem der sich das ansieht - fällt dabei aber auch auf, dass der Hauptteil der VOP3-Befehle aus den Reihen der VOP2-Befehlen kommt. Dazu kommt, dass bestimmte VOP3-Befehle eine "Dopplung" der VOP2-Befehle sind - ist ja gut zu sehen.

Und Dual Issue unterstützt nur den kleineren Teil der Befehle, die für VOP2 zur Verfügung stehen.
Dabei ist die Abdeckung für F32 recht gut. Aber die Befehle für F16 und Integer fehlen weitgehend.

Dual-Issues muss an dieser Stelle garnicht alle VOP2, sowie VOP1 oder VOP3-Befehle unterstützen. Das ist garnicht notwendig und würde zu Teilen sogar Probleme schaffen.

Aktuell sind ja auch alle wichtigen Rechenoperationen - also die, die bei Shadern häufig verwendet werden, mit dabei. Dass das nur F32 ist, ist vielleicht nicht "optimal" aber weitgehend verschmerzbar. F16 hatte 2017 ja den Peak mit Wolfenstein und Rapid-Packet-Math. Mit VSR und Co gibt es hier aber auch andere Alternativen.

Bei den VOP1-Befehlen haben wir viele Befehle, die eher das Laden/Speichern/Verschieben von Daten betreffen, dass diese nicht Dual-Issue sind, hat eventuell den Hintergrund, dass hier einfach das Raze-Hazard zu groß ist und am Ende entsprechend es langsamer wird oder Fehleranfälliger.

Bei den VOP3-Befehlen wiederum haben wir ja fest getellt, dass hier das Problem die Wortbreite ist. Es gibt entweder 32 Bit oder eben 64 Bit-Wortbreite. Für die Dual-Issues müsste die Wortbreite verbreitert werden.

Aber auch das ist an der Stelle nur "sekundär" ein Problem. Bei den VOP1-Befehlen - wie gesagt - ist viel zur Verwaltung der Daten dabei, dass viel Potential für Raze-Hazards sorgt. Hier müsste der Compiler also sehr gut "optimieren", damit er sowas abfangen kann. Dazu darf man auch nicht vergessen, dass manche VOP1 und VOP3-Befehle garnicht auf der Vector-ALU ausgeführt werden.

Aber man wird mal abwarten müssen, wie AMD die Vec mit RDNA4 verbessert.

 

[ETI1120]

Viele der Computeworkloads sind immer noch auf Wave64 ausgelegt, in dem Fall bringt also die eigentliche Dual-Issue-Fähigkeit nicht viel, sondern dass man eine "Vec64" hat.

Ja und hier wird es interessant.

Im RDNA 3 Deep Dive beschreibt AMD dass Wave 64 als One Clock Operation arbeitet

Im RDNA 3 ISA sieht das Ganze völlig anders aus:

Ich interpretiere es so dass Wave64 nur beim Verwenden von Dual Issue Befehlen als
One Clock Operation funktioniert. Die Folie im Deep Dive beschreibt einen Sonderfall, nämlich dass Dual Issue verwendet werden kann.

Das will ich nur mal andeuten, weil das auch für die weitere Betrachtung wichtig ist.

Ja, VOP3 hat in dem Fall den größten Umfang, dass ist richtig. Aber - jedem der sich das ansieht - fällt dabei aber auch auf, dass der Hauptteil der VOP3-Befehle aus den Reihen der VOP2-Befehlen kommt. Dazu kommt, dass bestimmte VOP3-Befehle eine "Dopplung" der VOP2-Befehle sind - ist ja gut zu sehen.

Dass VOP3 in Dual Issue nicht geht ist klar, aber es fällt eben auf wie groß der Befehlsumfang ist.
Dass ein paar auch als VOP2 verfügbar sind, ändert daran nichts.

Dual Issue deckt wiederum nur ein Bruchteil der VOP2 Befehle ab. Integer wird praktisch gar nicht unterstützt, nur eine Additionsvariante.

Dual-Issues muss an dieser Stelle garnicht alle VOP2, sowie VOP1 oder VOP3-Befehle unterstützen. Das ist garnicht notwendig und würde zu Teilen sogar Probleme schaffen.

Wenn AMD alle Befehle für Dual Issue bereitstellen wollte, hätten sie auch gleich zwei Shadern implementieren können. So weit ich es verstehe ist es eben der Trick dass man ein paar Transistoren investiert und dafür in der Lage ist einige Befehle parallel ausführen zu können.

Aktuell sind ja auch alle wichtigen Rechenoperationen - also die, die bei Shadern häufig verwendet werden, mit dabei. Dass das nur F32 ist, ist vielleicht nicht "optimal" aber weitgehend verschmerzbar. F16 hatte 2017 ja den Peak mit Wolfenstein und Rapid-Packet-Math. Mit VSR und Co gibt es hier aber auch andere Alternativen.

Die Grund-Rechenoperationen von F32 sind bis auf die Division enthalten. Darunter 3 varianten von Fused Multiply ADD

Bei F16 ist das Skalarprodukt mit F16 und BF16 vorhanden.

Bei den VOP1-Befehlen haben wir viele Befehle, die eher das Laden/Speichern/Verschieben von Daten betreffen, dass diese nicht Dual-Issue sind, hat eventuell den Hintergrund, dass hier einfach das Raze-Hazard zu groß ist und am Ende entsprechend es langsamer wird oder Fehleranfälliger.

VOP1 ist weit mehr als nur Laden/Speichern/Verschieben. Das sind nur 6 Befehle.

V_DUAL_MOV_B32 ist der Movebefehl für Dual Issue.

VOP1 umfasst hauptsächlich das Konvertieren zwischen den Zahlenformaten. Das die fehlen stört nicht wenn man hauptsächlich F32-berechnungen durchführt. Allerdings steuert VOP1 auch Rechenoperationen wie Exponent, Logarithmus, Wurzel, Sinus, Cosinus bei.

Außerdem stehen bei Dual Issue keine Vergleichsoperationen zur Verfügung,

Aber auch das ist an der Stelle nur "sekundär" ein Problem. Bei den VOP1-Befehlen - wie gesagt - ist viel zur Verwaltung der Daten dabei, dass viel Potential für Raze-Hazards sorgt. Hier müsste der Compiler also sehr gut "optimieren", damit er sowas abfangen kann.

Aber es muss trotzdem erledigt werden. Und wie gesagt bei VOP1 gibts auch einige Rechenoperationen. Sie werden zwar seltener benötigt als Addition, Subtraktion und Multiplikation, aber wenn sie benötigt werden muss der Dual Issue Modus verlassen werden. Deshalb ist der Nutzen des Dual Issue sehr beschränkt.

AMD nennt im Deep Dive für RDNA 3 inklusive Dual Issue 17,4 % IPC-Steigerung. Das ist auch der Grund warum AMD darauf verzichtet hat die Shader doppelt zu zählen. Zurecht wie ich finde.

Interessant finde ich dass im Vorfeld Shader-Zahlen genannt wurden, die auf dem Doppel-Zählen basieren. War das die Einsicht sich dem Doppelzählen sich lächerlich zu machen?

Wir haben aber bei RDNA 3 eine lebhafte Debatte über die Frequenzen. Diese wurde unter anderem durcj diese Folie im Deep Dive ausgelöst:

Was AMD hier zeigt sind die Kurven des 5 nm und 7 nm Prozesses. Die 1,3 x Frequenz und 0,5 x Power ist so ziemlich das was AMD im November 2021 für den neuen Prozess angekündigt hat.

Bei 30% höherer Frequenz bei gleicher Power und 17 % IPC kämen 52 % Effizienzsteigerung heraus. Dieser Betriebspunkt ist für die RX 7900XTX im Referenzdesign nicht möglich.

RX 6950XT verbraucht ca. 350 W und ist am Powerlimit dessen was mit 2 x 8 Pol Stecker umsetzbar ist. Da die RX 7900XTX 20 % mehr CUs hat, muss ein anderer Betriebspunkt mit niedrigerer Power gewählt werden. Ein weiter Aspekt der zeigt das die zahlen die AMD zu Navi 31 gezeigt hat, hinten und vorne nicht zusammen passen.

Grafikkarte	GPU	CU	Durchschn. Takt in Games*)	Prozess	Transistordichte**)
Radeon RX 7900 XTX	Navi 31	96	2.556 MHz	5 nm GDC 6 nm MDC	150,2 M/mm² 54,64 M/mm²
Radeon RX 7900 XT	Navi 31	84	2.566 MHz	"	"
Radeon RX 7600	Navi 33	32	2.250 MHz	6 nm	65,2 M/mm²
Phoenix		12	?	4 nm	142,6 M/mm²
Radeon RX 6950 XT	Navi 21	80	2.392 MHz	7 nm	51,5 M/mm²
AMD RX 6900 XT	Navi 21	80	2.246 MHz	7 nm	"
Radeon RX 6700 XT	Navi 22	40		7nm	51,3 M/mm²
Radeon RX 6650 XT	Navi 23	32	2.410 MHz	7 nm	46,7 M/mm²
Radeon RX 6600 XT	Navi 23	32	2.359 MHz	7 nm	"
Radeon RX 6600	Navi 23	28	2.044 MHz	7 nm	"
Radeon RX 6500	Navi 24	16		6 nm	50,5 M/mm²
Rembrandt		12		6 nm	63,0 M/mm²

*) Aus den Tests von Computerbase
**) Techpowerup

Auf der Basis der Radeon RX 6950XT wären 30 % mehr 3,1 GHz und auf der Basis der 6900XT wären es 2,9 GHz. Da wären wir bei den 3 GHz die AMD als Ziel für Navi 31 genannt hat. Aber dann hätte AMD einen höheren Verbrauch einplanen müssen und gleich mit 3 Steckern vorsehen müssen.

Tatsächlich erreicht die RX 7900XTX eine knapp 7 % höhere Frequenz als die RX 6950XT. Aber wenn die Kurve korrekt wäre, müsste der Verbrauch deutlich niedriger sein.

Bei der RX 7600 ist die Frequenz sogar niedriger als bei RX 6650XT und bei RX 6600XT.

Allerdings finde ich die stagnierenden Frequenzen bei RDNA 3 angesichts der gesteigerten Transistordichte wenig überraschend. Oder anders formuliert, wenn man an der Taktschraube drehen will, erhöht man üblicherweise nicht die Transistordichte so massiv wie AMD es bei RDNA 3 getan hat.

Laut Grafikkarten Rangliste ergeben sich folgenden Performancesteigerungen der Radeon RX 7900 XTX in Bezug auf die Radeon RX 7900 XT
1920 x 1080: +12 %
2560 x 1440: +14%
3840 x 2160: +18%

Also kann die RX 7900 XTX ihre 14% zusätzlichen Shader gut auslasten.

Aber man wird mal abwarten müssen, wie AMD die Vec mit RDNA4 verbessert.

Eventuell liefert schon Strix Point weitere Antworten.

PS:

AMD für den Herbst ROCm für die 7900XTX angekündigt.
https://community.amd.com/t5/rocm/n...nhancements-and-optimizations-for/ba-p/614745

Außerdem schlägt ein Blogbeitrag von mosaicML Wellen:
https://www.mosaicml.com/blog/amd-mi250

 

[DevPandi]

Ich interpretiere es so dass Wave64 nur beim Verwenden von Dual Issue Befehlen als
One Clock Operation funktioniert. Die Folie im Deep Dive beschreibt einen Sonderfall, nämlich dass Dual Issue verwendet werden kann.

Wäre glaub ich mal ein Punkt direkt mit dem Treiber zu interagieren und entsprechende Tests laufen zu lassen. Leider fehlt da die Zeit.

Allgemein ist es aber auffällig das zwischen Präsentationen und dem ISA-Paper gewisse Unstimmigkeiten vorhanden sind. Im Endeffekt ist aber auch das egal, wir können da nur Rätselraten, was wie funktionieren sollte.

Dual Issue deckt wiederum nur ein Bruchteil der VOP2 Befehle ab. Integer wird praktisch gar nicht unterstützt, nur eine Additionsvariante.

Naja, dass INT nicht abgedeckt wird, wissen wir ja, genauso das weitere Datenformate nicht abgedeckt werden. Das ist an der Stelle auch nicht so tragisch.

Außerdem stehen bei Dual Issue keine Vergleichsoperationen zur Verfügung,

Das mit den Vergleichsoperationen ist da so ein Ding, da gibt es bei den VOP3 ein paar tolle Sachen. Frage ist nur, wie wichtig die für die Spieleprogrammierung wirklich sind.

Aber die MIN_MAX und Co sind toll.

Interessant finde ich dass im Vorfeld Shader-Zahlen genannt wurden, die auf dem Doppel-Zählen basieren. War das die Einsicht sich dem Doppelzählen sich lächerlich zu machen?

Ich finde das an der Stelle schwer zu beurteilen, ob es lächerlich ist oder nicht. Im Endeffekt muss man abwarten, was kommt. Ich denke, die RDNA3 "Dual-Issues" sind eben einfach die erste Implementation die sie erweitern können.

Ich denke auch, dass der Weg hier mit einer "Vec", die ggf. 2 Befehle ausführen kann, nicht mal verkehrt, wenn man entsprechende Limitationen mit der Zeit eleminiert und damit dann entweder wirklich 2 Wave32 auf der ALU ausführen kann oder einen Wave64. Aber mal abwarten, was mit RDNA4 kommt.

Tatsächlich erreicht die RX 7900XTX eine knapp 7 % höhere Frequenz als die RX 6950XT. Aber wenn die Kurve korrekt wäre, müsste der Verbrauch deutlich niedriger sein.

die Kurve würde an der Stelle aber nur funktionieren, wenn es der gleiche Chip wäre. Aber am Ende kommst du da auf die gleiche Schlussfolgerung wie ich und wie ich sie bereits ausgeführt habe:

Oder anders formuliert, wenn man an der Taktschraube drehen will, erhöht man üblicherweise nicht die Transistordichte so massiv wie AMD es bei RDNA 3 getan hat.

Ich denke, dass eines der Probleme zusuchen ist. Mit 150 mio. Transistoren pro mm² schlägt man selbt NVIDIA mit 125 mio. Transistoren pro mm². Ich glaube, man hat den Chip wirklich auf Kosten optimiert und irgendwo bekommen sie die Signale nicht mehr in den Griff und entsprechend müssen sie für den anvisierte Takt daher viel mehr Leistung einspeißen, als sie dachten.

Es wäre nicht das erst mal, dass genau sowas passiert.

Also kann die RX 7900 XTX ihre 14% zusätzlichen Shader gut auslasten.

Ich habe ja auch nie geschrieben, dass RX 7900 XTX ihre "Shader" nicht gut auslasten kann. Nimmt man den reinen CU-Count und den Takt, dann skalliert RDNA3 sogar sehr gut. 20 % mehr CU, 7 % mehr Takt, bedeutet im Idealfall ca. 30 % mehr Leistung als die 6950 XT und das schafft RDNA3 auch.

Geht man rein von der Skalierung aus, die zwiscen RDNA und RDNA2 quasi "perfekt" war - hier konnte fast alles 1:1 umgesetzt werden bei 4K. Man hätte sich die Dual-Issue durchaus spare können und in weitere CU stecken können.

Man wird abwarten, was AMD hier vorhat.

Außerdem schlägt ein Blogbeitrag von mosaicML Wellen:

Danke für den Artikel an dieser Stelle. Im Endeffekt bestätigt er das, was ich in einem anderen Thema zu KI ja bereits angesprochen habe, dass NVIDIA hier zwar aktuell den Markt von der Hardware dominiert, aber keine so starkes Bollwerk hat, wie es im Bereich ContentCreation und Co dank CUDA hat.

Die ganzen Frameworks und Co sind wirklich weitgehend Hardwareagnostisch ausgelegt und entsprechend kann Intel und AMD hier auch noch mit mischen und müssen nicht erst CUDA knacken.

 

[SonyFriend]

nvidia hat ja bei der 4070/4070ti mehr Cache spendiert (32 anstatt 4 MB), was das wenige VRAM von 12 GB wieder etwas relativiert.

Wäre doch für AMD wieder ein Schritt in die richtige Richtung, wenn sie analog zu den CPUs jetzt auch bei den GPUs gestapelten Cache einführen könnten.

Eine 6700XT hat 96 MB L3-Cache, eine 6800XT 128 MB.

1 GB L2 oder L3-Cache würden sich prima anhören, wobei ich den Unterschied L2 und L3 nicht kenne und warum hat nvidia keinen L3 Cache?

 

[syfsyn]

Das cache argument ist völliger murks
Amd Ansatz einen L3 cache vor dem SI zu setzen damit dieser die Bandbreite erhöht funktioniert
Nvidia hat aber den L2 cache vergrößert dieser kann keine Bandbreite vergrößern lediglich mehr daten im kern abarbeiten womit weniger vom Si gefordert wird.
Das reduziert lediglich die Ladevorgänge bis ein rendervorgang abgeschlossen ist und das ist nur bei dxr vom belang.
Also dem Rt core mehr daten geben.
Da wird nix an der speicherbandbreite entlastet.

Das die rtx4070ti schneller als die rtx3090 ist liegt allein an den spielen die die bandbreite nicht fordert.
Das maxed die spiele fordern ist etwa 500gb/s den spiele werden nicht an die monitor auflösung aufeinmal bandbreiten intensiver das richte sich danach womit man das spiel hin designt hat.
Und das ist aktuell 720p bis 1440p mit Fokus auf eher 720p

 

[ETI1120]

Wäre doch für AMD wieder ein Schritt in die richtige Richtung, wenn sie analog zu den CPUs jetzt auch bei den GPUs gestapelten Cache einführen könnten.

Bei RDNA 3 ist der Cache in die MCDs gewandert. Laut Angstronomics soll es möglich sein, dass hier gestapelt wird. AFAIK gibt es noch keine hochauflösenden Die-Shots der MCD, so dass man nicht prüfen kann, ob dies stimmt.

1 GB L2 oder L3-Cache würden sich prima anhören, ...

SRAM braucht je Bit eine große Fläche und ist deswegen teuer. Hauptspeicher und GrafikRAM verwenden DRAM-zellen, die erheblich weniger Fläche benötigen und damit preiswerter sind.

Bei der Vorstellung von RDNA 2 mit dem Inifitiy Cache hat AMD folgende Folie gezeigt, hier in ener von Locuza erweiterten Fassung:

Man sieht dass der Nutzen von zusätzlichen L3-Cache stetig abnimmt und dass man bei allem was über 128 MByte hinausgeht kosten und Nutzen gut abwägen muss.

Bei RDNA 3 hat AMD angeblich die Nutzung des Infinity Caches optimiert. Dehalb soll der kleinere Infinity Cache von RDNA 3 ausreichen. Bei N31 und N32 wurde die Bandbreite zum GDDR-RAM erhöht. Ich habe keine Information gesehen die darauf hindeutet dass RDNA 3 ein Bandbreitenproblem hätte.

 

[DevPandi]

Amd Ansatz einen L3 cache vor dem SI zu setzen damit dieser die Bandbreite erhöht funktioniert

Du verstehst aber auch, warum AMDs Ansatz funktioniert? So wie du hier wieder dein "geballtes" Wissen raus haust, scheint es aber eher nicht so zu sein, sonst würdest du nämlich in weiten Teilen nicht so einen Murks verfassen.

Caches - egal ob man den nun L0, L1, L2, L3, Infinity Cache, Super-Duper-Ultra-Cache, nennt, Ziel ist es möglichst die Daten bei den Rechenwerken vor zu halten, die dieser demnächst benötigt oder benötigen könnte.

Je mehr Daten man in einem Cache zwischen puffern kann, um so seltener muss man dafür in den RAM.

Nvidia hat aber den L2 cache vergrößert dieser kann keine Bandbreite vergrößern lediglich mehr daten im kern abarbeiten womit weniger vom Si gefordert wird.

Du merkst an der Stelle schon, dass du dir widersprichst? AMD geht bei ihrer GPU den weg: Register -> LDS -> L1 -> L2 -> InfityFrabric -> Infinty Cache (L3) -> RAM. Liegen die Daten im L3, spart man sich den Zugriff auf den RAM und benötigt in folge dessen nicht die Bandbreite des SI und kann diese Bandbreite für etwas anderes nutzen.

NVIDIA geht über den Register -> L1 -> L2 -> RAM. Das SI hängt am L2 Cache und damit hat der L2-Cache die gleiche Wirkung wie der L3 bei AMD. Sobald die Daten im L2 liegen, muss nicht mehr in den RAM gesprungen werden, entsprechend spart man sich hier die Bandbreite ein.

Das reduziert lediglich die Ladevorgänge bis ein rendervorgang abgeschlossen ist und das ist nur bei dxr vom belang.

Das ist für alles von Belang, egal ob RT oder Compute oder Co. Sobald die Daten im L2 sind, müssen diese nicht mehr aus dem RAM geholt werden.

Wenn ein Shader "30" MB an Daten benötigt, davon liegen 15 MB im L2, müssen nur noch 15 MB "direkt" in den L2 geladen werden, entsprechend ist das SI um 15 MB entlastet worden.

Vollkommen unabhängig ob das eine Texture, Polygon oder der BVH war.

 

[FrankN84]

Etwas kurios finde ich nun AMDs Angaben auf der Homepage.
Da wird eine

AMD Radeon™ RX 7600 XT Desktop-Grafikkarte​

erwähnt.

Zudem steht in der Beschreibung zur RX 7600
"Radeon™ RX 7600 Grafikkarten nutzen fortschrittliche AMD RDNA™ 3-Recheneinheiten..."

https://www.amd.com/de/products/graphics/amd-radeon-rx-7600

Die RX7600 ist doch aber bereits der Vollausbau. Wenn eine XT geplant ist, wäre allenfalls eine Vergrößerung des Speichers denkbar. Aber das wird die Karte performancemäßig auch nicht groß helfen. Allenfalls bei Texturauflösungen, aber da sind dann 16GB to much.

 

[ETI1120]

@FrankN84 ich würde das unter Fehler auf der Website verbuchen

Zudem steht in der Beschreibung zur RX 7600
"Radeon™ RX 7600 Grafikkarten nutzen fortschrittliche AMD RDNA™ 3-Recheneinheiten..."

AMD und die Partner verkauft ja nicht nur eine einzige Grafikkarte, sondern wollen schon zig tausend verkaufen. Also wurde ich hier der Mehrzahl keine besondere Bedeutung beimessen.

Der Artikel in dessen Thread wir diskutieren besagt, dass eine RX7800XT basierend auf Navi 31 kommen soll. Ich hätte nicht erwartet, dass AMD Navi 31 so stark beschneidet, weil damit sehr viele funktionierende Shader stillgelegt werden. Aber so wie die Performance von RDNA 3 in Vergleich zu den Nvidia-Karten liegt, bleibt wohl AMD wenig anderes übrig.

Es gibt immer noch nichts konkretes zu Navi 32. Wenn sie entsprechend Navi 31 performed wird der Vollausbau (60 CUs) ca. 15 bis 20 % vor der RX 6800 liegen. Und dann ist die Frage wie viele SKUs AMD aus Navi 32 ableiten wird. Da könnte durchaus eine RX 7600XT dabei sein. Aber diese würde bestenfalls gleichzeitig mit den anderen SKUs veröffentlicht werden, die AMD aus Navi 22 ableitet. IMO eher später.

 

[yamiimax]

Die RX7600 ist doch aber bereits der Vollausbau. Wenn eine XT geplant ist, wäre allenfalls eine Vergrößerung des Speichers denkbar. Aber das wird die Karte performancemäßig auch nicht groß helfen.

Mmh naja es gibt ja auch die 4600 und 4060 ti nun macht amd das gleiche

7600 vollausbau? eher krüppelausbau haha

Vielleicht hat AMD ja vor die 7600 xt zu entkrüppeln für richtige Zocker hehe

Schlau wäre 10 gb vram

 

[FrankN84]

Der Zusatz XT ist nun von der AMD Homepage verschwunden. Damit hat sich das wohl erledigt und es bleibt bei der RX 7600 ohne XT. Eine XT hätte wohl keine Daseinsberechtigung auf dem Markt. Zumal die 7700 XT (Nachfolger der immer noch top Karte 6700XT) ansteht.