Test Radeon RX 7900 XT(X): Neue Treiber senken den Verbrauch auch bei Teillast in Spielen

[Perdakles]

Die HW ist nicht das Problem, aber das hast Du nicht verstanden.

Dein Insiderwissen und dein unfassbar durchdringendes Verständnis in Ehren. Ich Frage mich nur warum AMD laut aktuellen Gerüchten (u.a. RedGamintech, MLID und andere) einen RDNA3+ Refresh plant, der die Bugs in der HW angehen soll wenn du uns doch allen versichern kannst, dass die mangelnde Leistung lediglich ein Treiberproblem ist. Dazu passt übrigens auch, dass Navi32 bereits auf diesem Refresh basieren soll und daher so spät kommt. Selbst du mit deinem umfassenden Wissen und deinen Branchen-Kontakten aus erster Hand wirst doch zugeben müssen, dass das recht ungewöhnlich ist wenn man sich die Historie der letzten GPU Generationen ansieht. Normalerweise arbeitet man sich vom größten zum kleinsten Chip vor. Aber schlau mich gerne auf...

 

[Taxxor]

Ich Frage mich nur warum AMD laut aktuellen Gerüchten (u.a. RedGamintech, MLID und andere) einen RDNA3+ Refresh plant welcher die Bugs in der HW angehen soll

Also ich für meinen Teil gebe auf die "Gerüchte" von RGT und MLID zum Thema RDNA3 überhaupt nichts mehr, von denen hat man vor dem Launch im Wochentakt komplett unterschiedliche Infos zu hören bekommen und am Ende ist nichts davon eingetroffen, nicht mal das was man wenige Tage vorher gehört hat.

 

[Perdakles]

@Taxxor Da gebe ich dir Recht. Allerdings sind es wie schon gesagt nicht nur die beiden. Außerdem wissen wir von AMD selbst, dass RDNA3+ definitiv existiert. Auch wenn dies nur für Strix Point bestätigt ist.

 

[ETI1120]

Ich denke, die können 20% auskitzeln, wenn die Shader richtig sortiert werden und jede Einheit doppelt belegt werden kann.

Es kann nicht jeder Befehl als Dual Issue ausgeführt werden.
Aus diesem Grund hat AMD die Zählweise der Shader letztendlich doch nicht geändert.

Im RDNA3 Instruction Set Architecture Reference Guide findet man einiges zu Dual Issue.

In Abschnitt 7.6 "Dual Issue VALU" auf Seite 68 gibt es eine Kurze Einführung.
Obwohl ich mich mit der Programmierung von GPUs nicht aus kenne, fällt mir auf dass die Hälfte dieser Einführung (1 1/2 Seiten) die Grenzen und Restriktionen von Dual Issue beschreibt.

Dual Issue wird mit dem Vektor ALU Format VOPD angesprochen. Es ist eines von 9 verfügbaren Vektor ALU Formate. Es wird In Abschnitt 15.3.7 "VOPD" auf Seite 168 beschrieben
Im Prinzip besteht Dual Issue aus zwei Befehlen X und Y genannt. Beide haben jeweils zwei Quellen und ein Ziel.

Für X stehen 14 einzelnen Befehle zur Verfügung für Y 17.

Für die anderen Formate stehen teilweise erheblich mehr Befehle zur Verfügung.
Es fällt auf dass es hauptsächlich F32 (Floating Point) sind. 2 Befehle mit F16. Für Y gibt es einen Befehl (ADD) mit unsigned Integer (U32). Und dann gibt es noch ein paar Befehle im Bitformat, darunter das unvermeidliche Move. Es gibt keine Dual Issue Befehle für signed Integer.

Die einzelnen Befehle werden im Abschnitt 16.11 "VOPD Instructions" auf Seite 356 beschrieben.
Aber die Suffix Namen benennen konsistent die Zahlenformate mit denen dieser Befehl.

Die HW ist nicht das Problem, aber das hast Du nicht verstanden.

Er hat sehr wohl verstanden, dass AMD die Compiler schon an Dual Issue angepasst hat.

So hat Chips and Cheese festgestellt, dass bei der Nemes Benchmarksuite für Vulkan mit der 7900XTX in einigen F32 Grundoperationen ADD und sehr wohl ein hoher %-Satz an Dual Issue Befehlen verwendet wird. Hier steigt die Leistung im Vergleich zur 6900XT massiv.

Aber das sind offensichtlich synthetische Test. Da sind Optimierungen einfacher als in realen Programmen. Der Testcode für den Test einer einzelner CU den clamchowder in OpenCL geschrieben hat wurde vom AMD Compiler hingegen kaum auf Dual issue optimiert.

Auch die massive Streuung der einzelnen Spiele ist ein klarer Hinweis darauf, dass Dual Issue unterschiedlich häufig verwendet wird.

Natürlich kann man immer weiter optimieren, aber der Ertrag wird immer kleiner. Die Low Hanging Fruits hat AMD schon abgerntet. Da wird sicher noch was dazukommen, aber das sind über die Testsuiten gemessen ein paar Prozentle

Ich Frage mich nur warum AMD laut aktuellen Gerüchten (u.a. RedGamintech, MLID und andere) einen RDNA3+ Refresh plant welcher die Bugs in der HW angehen soll wenn du uns doch allen versichern kannst, dass die mangelnde Leistung lediglich ein Treiberproblem ist.

Was die Trefferquote angeht, sind die Helden ja nicht der Hit.

Dazu passt übrigens auch, dass Navi32 bereits auf diesem Refresh basieren soll und daher so spät kommt.

Ja hört sich toll an.

Die Geschichte mit dem Bug zirkuliert seit einiger Zeit auf Twitter, Twitter ist nämlich die Haupt-Quelle von MLID.

Ich bin skeptisch was diese Geschichte anbelangt. Refresh mit neuen Features passt, Refresh mit neuem Prozess passt. Bugfixes im Refresh können die Ausbeute erhöhen, den Verbrauch ein kleines bisschen senken oder ein kleines bisschen mehr Performance bringen. Ein Bugfix in der Hardware, der deutlich mehr an Perfomance bringt? Das geht nicht gut, das impliziert nämlich, dass man defekte Hardware verkauft hat.

Es möglich, dass ein neues Feature, das mehr Performance liefert im Grunde ein Bugfix ist. Aber das Wort Bug würde gegenüber dritten nie erwähnt werden.

Und das fatale an dieser Geschichte wäre, dass dieser Fehler AMD seit über einem Jahr bekannt sein müsste. Die Anwälte würden Schlange stehen.

Normalerweise arbeitet man sich vom größten zum kleinsten Chip vor. Aber schlau mich gerne auf...

Ich denke normal ist bei RDNA 3 gar nichts. AMD war bisher sehr geizig was Designs angeht. RDNA 2 gab es nur im 7 nm Node. Navi 21, 21 und 23 in N7 und Navi 24 in N6.

Der aktuelle Stand ist:

• Navi 31 GDC 5 nm (AMD), auf dem Markt
• Navi 32 GDC 5 nm (Gerücht, Angstronomics), Erscheinungstermin unbekannt
• Phonix Point 4 nm (AMD), soll ab März in Notebooks sein
• Navi 33 6 nm (AMD), soll bald in Notebooks sein

(Ich verwende hier die nm Zahlen, weil AMD so oder so keinen Standardprozess verwendet und es zudem unklar ist auf welchen Standardprozess sie ihre Anpassungen aufsetzen)

RDNA 3 wird parallel auf 2 Nodes und in 3 Prozessen ausgerollt. Ich hätte es nicht für möglich gehalten.

@Taxxor Da gebe ich dir Recht. Allerdings sind es wie schon gesagt nicht nur die beiden.

Die Gerüchte zirkulieren nun Mal.

Außerdem wissen wir von AMD selbst, dass RDNA3+ definitiv existiert. Auch wenn dies nur für Strix Point bestätigt ist.

Und weil AMD RDNA 3+ im Juni für StrixPoint genannt hat, hat es IMO nichts mit Navi 32 zu tun. Bevor die ganzen Youtuber Mal wieder bloßgestellt wurden, wurde RDNA 3+ im Zusammenhang mit Navi 32 nicht erwähnt.

 

[Perdakles]

@ETI1120 Ich könnte jetzt noch auf einige deiner Punkte eingehen aber das führt eh zu nichts. Daher nur eines: ich wollte eigtl. gar keine (zweifelhafte) RDNA3+ Diskussion lostreten sonden @Eli0t nur klar machen, dass er die Weisheit nicht mit Löffeln gefressen hat. Anderen durch die Blume und unbegründet Dummheit vorzuwerfen während man auf einen vermeintlichen Wundertreiber wartet zeugt auch nicht gerade von Intelligenz. Aber vermutlich hat er das schon bei Vega so gehandhabt...

 

[ETI1120]

Ich fand seinen Ton auch unmöglich, deshalb habe ich ihm geantwortet.

Aber vermutlich hat er das schon bei Vega so gehandhabt...

Ich habe den Hype um Vega und das Warten auf den Wundertreiber mitbekommen. Mir war dann im Dezember 2017 auch klar dass da nichts mehr kommt.

Und Hardware kauft man eben so, wie sie aktuell ist. Wenns passt ist gut und wenns nicht passt kauft man eben nicht. Darauf zu hoffen, dass ein Update Fehler behebt ist immer ein Glücksspiel.

Ich habe 2020 zwei oder drei Videos von RedGamingTech zun RDNA 2 gesehen. Da hat er auch so viel erzählt, das irgend etwas zutreffen musste. 2019 habe ich auch ein Youtube-Video zu BigNavi gesehen, von dem ich denke er war es. Ich habe selten so einen gut erzählten Müll gehört.

MLID habe ich eigentlich immer nur kurz reingeschaut und dann schnell entschieden dass mir die Zeit zu schade ist. Nur einen seiner Beiträge zu Van Gogh habe ich mal komplett angeschaut. Da hatte er zwar einige Details richtig aber er lag beim Verwendungszweck komplett daneben. Van Gogh war SemiCustom und immer für Valve konzipiert.

Zu eigentlichen Thema. Es geht mir nicht darum, dass in Navi 31 keine Bugs oder keine Hardwarebugs wären. Bei Navi 31 läuft einiges schief. Aber die Geschichte mit dem Fehler den AMD in einem Refresh beseitigt und alles ist gut, ist auch nur eine Variante des Wundertreibers.

 

[DevPandi]

Obwohl ich mich mit der Programmierung von GPUs nicht aus kenne, fällt mir auf dass die Hälfte dieser Einführung (1 1/2 Seiten) die Grenzen und Restriktionen von Dual Issue beschreibt.

Wobei die Restriktionen weit harmloser sind, als anfangs behauptet von der Presse. Anfangs hieß es, dass es der gleiche Operator sein muss, was nicht richtig ist. Es muss das gleiche Format sein.

Wie ich in meinem Test angedeutet habe, hat AMD die Vec32 zu einer Vec32+32 umgebaut, die entweder einen Wave64-Befehl ausführen kann oder eben zwei Wave32-Befehle des richtigen Formates. Beides bezieht sich auf denselben Task/Thread/Shader.

Es gibt aber noch einen weiteren Fall - dann muss es der gleiche Operator sein, aber es können unterschiedliche Task/Threads/Shader sein: Data Parallel Processing (DPP). Ist der Abschnitt 7.7 im Paper. Hier können die gleichen Operatoren aus 8 bzw. 16 Threads zusammen gefasst werden. Natürlich gibt es auch da Einschränkungen, aber die "wichtigen" Operationen, die quasi den Alltag ausmachen, sind alle sowohl Dual-Issues als auch DPP fähig.

Wir haben hier also - wenn es auf ein Task/Shader/Thread hinausläuft - entweder die Möglichkeit Wave64 zu nutzen, wenn genug Werte zusammen kommen oder eine VLIW2-Möglichkeit (also auf dem Shader-Compiler basierendes OoO). Ebenso kann, wenn das nicht zutrifft, DPP8 oder DPP16 genutzt werden.

Zum Thema mit den Hardware-Bugs: Ich glaube nicht daran, dass RDNA3+ "in" der Form existiert, wie einige Seiten - hardwaretimes, appuals und auch unsere bekannten Twitter-Glaskugelleser - glauben machen.

RDNA3 zeigt bei bestimmten Titeln, dass das Konzept mit den neuen Vec32 aufgeht, in anderen nicht. Auch zeigen die Treiber aktuell, dass man ja im Teillast-Bereich nachlegen kann. Klar, das bis jetzt waren die richtig leichten Punkte.

RDNA3+ wird vermutlich für die APU angepasst sein, so wie es Zen3+ es war. Darüber hinaus würde ich keine signifikanten Veränderungen erwarten.

 

[Perdakles]

RDNA3+ wird vermutlich für die APU angepasst sein, so wie es Zen3+ es war. Darüber hinaus würde ich keine signifikanten Veränderungen erwarten.

Das ist zugegebenermaßen die wahrscheinlichste Auflösung des ganzen Themas. Zumal Strix Point ja auch noch in einem "Advanced Node" im Vergleich zu Phoenix Point (RDNA3) kommt und RDNA3+ sich daher lediglich auf diesen Shrink beziehen könnte. Trotzdem finde ich es sehr interessant, dass Navi32 so viel später kommt als Navi31 und Navi33. Das kann natürlich einfach produktpolitische Gründe haben aber ein Restzweifel bleibt 😁. Man darf gespannt sein.

 

[b|ank0r]

Das kann natürlich einfach produktpolitische Gründe haben aber ein Restzweifel bleibt 😁

Ich denke es hat produktpolitische Gründe.

Navi 32 hätte im Gefilde einer 6800/6900 XT gewildert und das hätte einfach nicht funktioniert. Zu viele Restbestände der alten Generation bei gleichzeitig günstigerem Preis. Also warten bis die Restbestände verkauft sind und der Kunde keine Wahl mehr hat als zur neuen (teureren) Generation zu greifen 🤓

Mag sein das es einen Refresh geben wird der ein paar Fehler behebt, aber ich denke das AMD die Energie eher in die Entwicklung des Nachfolgers steckt.

 

[Perdakles]

Navi 32 hätte im Gefilde einer 6800/6900 XT gewildert und das hätte einfach nicht funktioniert. Zu viele Restbestände der alten Generation bei gleichzeitig günstigerem Preis. Also warten bis die Restbestände verkauft sind und der Kunde keine Wahl mehr hat als zur neuen (teureren) Generation zu greifen 🤓

Mag gut sein. Dann stellt sich aber die Frage warum man Navi33 nicht auch so stark verzögert wie Navi32. Da wir keine Übersicht über die Restbestände der einzelnen Navi2x Chips und der damit bestückten Karten haben, werden wir das leider nicht abschließend klären können 😭.

 

[b|ank0r]

Dann stellt sich aber die Frage warum man Navi33 nicht auch so stark verzögert wie Navi32.

Navi 33 wird doch auch von AMD verzögert oder habe ich etwas verpasst!? 🤔 Dort startet man lediglich mit Navi 33 im mobilen Notebook Segment.

Navi 33 ist im Vollausbau meine ich mit der 6600 XT identisch, was zu den gleichen Problemen wie oben führt. Gerade 6600 und 6700 (XT) sind aktuell recht günstig und mit guter Lieferbarkeit zu bekommen.

 

[Perdakles]

Navi 33 wird doch auch von AMD verzögert oder habe ich etwas verpasst!?

Nein nichts verpasst. Das basiert nur wieder auf Gerüchten: Navi33 für Desktop im Q2/23 und Navi32 für Desktop irgendwann in H2/23. Ich weiß ehrlich gesagt gerade gar nicht wo ich das aufgeschnappt habe.

 

[Eli0t]

Dein Insiderwissen und dein unfassbar durchdringendes Verständnis in Ehren. Ich Frage mich nur warum AMD laut aktuellen Gerüchten (u.a. RedGamintech, MLID und andere) einen RDNA3+ Refresh plant, der die Bugs in der HW angehen soll wenn du uns doch allen versichern kannst, dass die mangelnde Leistung lediglich ein Treiberproblem ist. Dazu passt übrigens auch, dass Navi32 bereits auf diesem Refresh basieren soll und daher so spät kommt. Selbst du mit deinem umfassenden Wissen und deinen Branchen-Kontakten aus erster Hand wirst doch zugeben müssen, dass das recht ungewöhnlich ist wenn man sich die Historie der letzten GPU Generationen ansieht. Normalerweise arbeitet man sich vom größten zum kleinsten Chip vor. Aber schlau mich gerne auf...

Das ändert nix an der neuen Architektur. Gerüchte sind auch keine Fakten und da AMD dazu nix sagt, läßt sich nur spekulieren. Fakt ist, daß der Treiber nicht fertig war wie man beim Stromverbrauch gesehen hat.
Natürlich kann man auch spekulieren, daß bei RDNA3+ eine HW-Einheit dazukommt, die das Umsortieren der Shader Befehle automatisch durchführt, um so die Einheiten optimal auszunutzen.

Ergänzung (16. Januar 2023)

Es kann nicht jeder Befehl als Dual Issue ausgeführt werden.
Aus diesem Grund hat AMD die Zählweise der Shader letztendlich doch nicht geändert.

Im RDNA3 Instruction Set Architecture Reference Guide findet man einiges zu Dual Issue.

In Abschnitt 7.6 "Dual Issue VALU" auf Seite 68 gibt es eine Kurze Einführung.
Obwohl ich mich mit der Programmierung von GPUs nicht aus kenne, fällt mir auf dass die Hälfte dieser Einführung (1 1/2 Seiten) die Grenzen und Restriktionen von Dual Issue beschreibt.

Dual Issue wird mit dem Vektor ALU Format VOPD angesprochen. Es ist eines von 9 verfügbaren Vektor ALU Formate. Es wird In Abschnitt 15.3.7 "VOPD" auf Seite 168 beschrieben
Im Prinzip besteht Dual Issue aus zwei Befehlen X und Y genannt. Beide haben jeweils zwei Quellen und ein Ziel.
Anhang anzeigen 1312484

Für X stehen 14 einzelnen Befehle zur Verfügung für Y 17.
Anhang anzeigen 1312419
Anhang anzeigen 1312421
Für die anderen Formate stehen teilweise erheblich mehr Befehle zur Verfügung.
Es fällt auf dass es hauptsächlich F32 (Floating Point) sind. 2 Befehle mit F16. Für Y gibt es einen Befehl (ADD) mit unsigned Integer (U32). Und dann gibt es noch ein paar Befehle im Bitformat, darunter das unvermeidliche Move. Es gibt keine Dual Issue Befehle für signed Integer.

Die einzelnen Befehle werden im Abschnitt 16.11 "VOPD Instructions" auf Seite 356 beschrieben.
Aber die Suffix Namen benennen konsistent die Zahlenformate mit denen dieser Befehl.


Er hat sehr wohl verstanden, dass AMD die Compiler schon an Dual Issue angepasst hat.

Ich kann mir nicht vorstellen, daß AMD den Compiler so optimiert hat, daß immer die beste Möglichkeit tatsächlich eintrifft. Desweiteren müßten auch die Engines entsprechend angepasst werden um das "Letzte" aus der Architektur rauszukitzeln. Es wäre besser gewesen, wenn alles doppelt ausgeführt werden würde, dann hätte man sich dieses Chaos erspart.

 

[Zer0Strat]

Wobei die Restriktionen weit harmloser sind, als anfangs behauptet von der Presse. Anfangs hieß es, dass es der gleiche Operator sein muss, was nicht richtig ist. Es muss das gleiche Format sein.

"Weit harmloser"... ^^ Operationen mit drei Operanden funktionieren nicht als Dual-Issue und neben WMMA gibt es nur eine Dual-Issue FP16 Instruktion.

Das ändert nix an der neuen Architektur. Gerüchte sind auch keine Fakten und da AMD dazu nix sagt, läßt sich nur spekulieren. Fakt ist, daß der Treiber nicht fertig war wie man beim Stromverbrauch gesehen hat.
Natürlich kann man auch spekulieren, daß bei RDNA3+ eine HW-Einheit dazukommt, die das Umsortieren der Shader Befehle automatisch durchführt, um so die Einheiten optimal auszunutzen.

Man sollte nicht erwarten, dass AMD den Compiler zügig auf Vordermann bringt, damit dieser mehr Fälle abdeckt.

Zum Thema mit den Hardware-Bugs: Ich glaube nicht daran, dass RDNA3+ "in" der Form existiert, wie einige Seiten - hardwaretimes, appuals und auch unsere bekannten Twitter-Glaskugelleser - glauben machen.

Schaut man sich die V/F-Curve an, dann stellt man fest, da stimmt was nicht. AMD hat seine Designziele verfehlt. Wenn sie das nachbessern, muss das ja nicht RDNA3+ sein, es reicht ja auch ein neues Stepping. Dass ein Respin kommen wird, ist nicht abwegig. Ich denke sogar, dass es so kommen wird.

Übrigens, da einige hier so gerne Autoritäten anführen, hier ein paar Aussagen von Andrei (ehemaliger Redakteur bei Anandtech) bzgl. Navi32.

 

[Pleasedontkill]

Die Preise werden auch der Grund für die Benennung sein.

Man hätte es tatsächlich wie mit der 5700XT machen sollen und sagen wir spielen diese Gen nicht im High End mit.
Nur dann hätten die Preise auch entsprechend niedriger sein müssen, eine 7800XT für 1200€ kann man schlechter als 6800XT Nachfolger verkaufen, als wenn man sie 7900XTX nennt und mit der 6950XT vergleicht.

Das Tor stand weit offen für AMD schön unten rein zu bollern. Hätte alles abgesahnt ohne viel drauf zahlen zu müssen dank Chiplet.

Nein, die zwei verhalten sich schon lange nicht wie Konkurenzen. So sehen Absprachen aus.

 

[heroesgaming]

Ich verstehe nur nicht, warum AMD so einen kleinen Chip mit so einem grossen Namen verkauft.
Wenn man sich mal ansieht, was der 102er für ein Monster ist, mit seinen +16.000 Shadern, deren theoretische Leistung er nicht einmal annähernd im Vergleich zu 4080 und 7900xtx auf die Strasse bringt, tritt AMD ja zu Schießerei mit einem Schraubenzieher an. Die 4090 wird der 7900xtx bei besserer Nutzung der neuen RT-Futures und besserer Auslastung der Kerne nur noch weiter enteilen. Fine Wine ist hier andersrum.

AMD hat letztendlich einfach Nvidias Spiel mitgespielt - freilich zu Ungunsten der Kundschaft.

Dort hat man mit der RTX 4090 ein weiteres Mal getan, was die erste Titan zu Kepler-Zeiten (und damals ebenfalls mit freundlicher Unterstützung von AMD, die das Big-Chip-Spiel zu spät mitspielten) schon mal getan hat: Eine völlig neue GPU-Klasse wurde etabliert. Ja, die RTX 3090 Ti kam damals (meine ich) mit höherer UVP, aber das war eine Refresh-Karte, die sich zu diesem Zeitpunkt kaum noch verkauft haben dürfte.

Die RTX 4090 dagegen ist ein Leistungs- und Effizienzmonster jenseits der bisher üblichen Preispunkte und überzeugt dabei zumindest Enthusiasten doch so stark, dass sie sich gut verkauft. Wie schon 2011 kann AMDs größter Chip da nicht wirklich mithalten, als High-End konnte er aber dennoch positioniert werden, da Nvidia weiter ins "Super-High-End" vorgeprescht ist und somit eine entsprechende Lücke offen gelassen hat.

Nebenbei hat man außerdem eine völlig neue Ära des GPU-Pricings eingeleitet, denn die Vorgängergeneration existiert (zumindest momentan) im "unteren" Preisbereich fort und bleibt dort das einzige Angebot, während die neue Generation sich fast geschlossen obendrauf setzt. RTX 4070 Ti, 4080 und 4090 sind nun als Oberklasse, High-End und Super-High-End positioniert. Wenn Ampere allmählich vom Markt verschwindet, könnte die ganze Struktur zwar noch etwas nach unten gleiten, außerdem kommen ja voraussichtlich noch 4070, 4060 und co. hinzu. Nichtsdestoweniger ist zu erwarten, dass das Niveau - gegebenenfalls stark - angehoben bleiben wird. Gleichzeitig ist GeforceNow attraktiv wie nie, gerade das neue RTX 4080-Abo lässt sicherlich den einen oder anderen grübeln.

Auf AMDs Seite fehlt derweil die Marktmacht und offenbar auch die technische Durchschlagskraft, auf ganzer Breite konkurrieren zu können, also verschanzt man sich im Windschatten des grünen Herstellers und passt sich dessen Pricing an, wovon man ja auch profitiert. Klar, man könnte auch versuchen, mit deutlich besseren Preisen Marktanteile zu gewinnen, aber am Ende hängt man nach wie vor an begrenzten High-End-Kapazitäten bei TSMC, wer kann schon genau sagen, ob man überhaupt das Volumen liefern könnte, das für eine solche Strategie dringend notwendig wäre. Vielleicht müsste man dann gerade bei Epyc und co. zu viel opfern.

Also bietet es sich vielleicht einfach mehr an, in dieser Generation einfach heimlich, still und leise die eigenen Innovationen im Chiplet-Bereich voranzutreiben und dann mit RDNA4 wieder voll anzugreifen. Es wäre nicht das erste Mal, das mindestens eine Generation "Pause" ist im Performance-Wettstreit, das gab es so schon zu Geforce 8-Zeiten, dann bis zu einem gewissen Grad wieder mit Kepler, Maxwell und Pascal, bei denen AMDs Konkurrenzkarten immer sehr spät kamen und Probleme hatten und dann erneut mit RDNA1. Wenn ich das gerade selbst so lese, ist es tatsächlich wohl eigentlich so üblich, dass man sich nicht wundern sollte

Trotzdem ... in meinen Augen bleiben auch RTX 4080 und RX 7900 XTX echte UHD-Karten. Immerhin gibt es also in absoluter Leistung nach wie vor große Fortschritte.

 

[Grillwurst]

Ich betreib Strom-Askese . Zock auf 1920x1080 und ner 3090. 60 Fps-Limit, 793 mV, 1740 Mhz und die Dicke rennt bei 120 bis max 150 Watt (sehr selten). 40 Grad bei 50% Fan-Speed.

 

[mospider]

Kann man machen aber hätte da nicht auch eine 3060 oder 3070 gereicht?

 

[Grillwurst]

Nee - 8 GB viel zuwenig.

 

[Fenkel]

Wie kann es bitte sein, dass die 4090 bei 144 fps weniger verbraucht als die 4070 ti? Verständlicherweise läuft die 4070 ti dann mehr am Anschlag, aber die 4090 hat doch viel mehr Recheneinheiten, die Strom verbauchen?! Das war eine Generation vorher noch anders.