AMD RDNA 5 (Mitte 2027)

[Night<eye>]

Von der Taktrate her sind die Partnerboards von AMD auch limitiert worden. Sapphire wollte beispielsweise noch höhere Taktraten und höheres TBP für RDNA4, spricht weit über die 3,2Ghz Taktwall hinaus.

Ändert nichts an den Fakten die ich nannte das der RDNA 4 Sweetspot bei höchstens 2,5ghz liegt.
RDNA 5 mit 3,5ghz wäre eine Brechstange und kein rundes Produkt, sondern versteckte Kostensenkung bzw Uplabeling wenn die AT 2 mit 64 CU,s als RTX 6070 Konkurrenz gelabelt wird.

 

[vinacis_vivids]

Deine Fakten spielen aber einfach keine Rolle. Gaming am Desktop-PC ist niemals "effizient" gewesen. Dann lieber kostenlos im Wald spazieren gehen, das spart mehr Strom.

Ich persönlich gehe bei ATI (AMD) Grafikkarten nur noch auf Hochleistung bzw. maximale Leistung, weil ich von AMD jetzt erwarte, dass sie mit besserer Technik (und mehr Geld) wieder die Nr.1 im Grafikkartenmarkt werden.

RDNA4 ist meiner Ansicht nach bereits jetzt schon die technisch überlegene uArch ggü. überteuertes Schrottwell.

Effizienz am Desktop-PC interessiert letztendlich keine Sau wirklich. In erster Linie geht es um Leistung (und Preis.). Effizienz landet irgendwo an der fünften Stelle weit weit hinten bei der Kaufentscheidung, hinter Kühlung, Aussehen, RGB, Geräuschkulisse usw.

Richtig "effizient" (für den Geldbeutel) war es früher vor 20 Jahren bspw. die Pipelines freizuschalten bei der X800 Pro @ X800 XT oder 9500 @ 9700 Pro.

Bei RDNA5 3nm Desktop-PC erwarte ich in der Spitze schon an die ~3,8Ghz - 3,9Ghz oder im Einzelfall auch ~4Ghz unter H20-Kühlung, also für AT2. Bei einem kleinen Chip (AT2 64CU) ist es am "effizientesten" durch höheren Takt an Mehrleistung zu kommen.


Der größte Chip, also AT0, mit geschätzt >700mm^2 Die Size wird ein Effizienzmonster sein wie du ihn dir vielleicht vorstellen kannst. Vielleicht da mal mehr Blicke auf AT0 werfen und nicht von AMD's AT2 verlangen, dass es "High-End" sei. Isses einfach nicht nach der derzeitigen Gerüchteküche.

 

[sompe]

Deine Fakten spielen aber einfach keine Rolle.

Das ist so aber auch nicht richtig.
Frißt die Karte zu viel wird das für für die Hersteller zum Wettbewerbsnachteil und Kosenfaktor weil Kühlung und Stromversorgung schließlich auch bezahlt werden wollen. Es spielt bei Desktop Karten wegend er externen Stromversorgung vielleicht nur eine untergeordnete Rolle aber es spielt eine Rolle.

 

[sompe]

Das Thema erledigt sich ja wenn man den Takt der XT bei 2500mhz gelassen hätte

Eben nicht denn dann wäre sie vermutlich gute 15% langsamer gewesen und hätte womöglich noch nicht einmal die normale 7900XT geschlagen denn eines hast du wie so vielen komplett misachtet, den Einfluss der Änderungen des Powertargets und der Spannungsänderungen auf die Taktfrequenz.

Das bedeutet nämlich nicht zwangsläufig eine großere Absenkung der Taktfrequenz sondern kann auch das Gegenteil bewirken weil der Turbo z.B. durch die sinkenden Temperaturen mehr Spielraum bekommt, siehe die steigenden Frameraten beim Powertarget von 80% und 90%.
Zudem sind diese Spielchen mit den Targets nichts anderes als Feintuning welches die Reserven/Spielräume der Spezifikationen ausnutzt aber nicht auf alle Karten übertragbar ist.

Was du ebenfalls übersehen hattest ist dass der Boost Takt nicht die max. Taktfrequenz ist. Mal eine kleine Übersicht aus einem damaligen Test der Karten. Wie man sieht taktet die normale 9070 je nach Spiel teils deutlich über dem angegebenen Boost Takt.

AMD Radeon RX 9070 (XT) im Test: Benchmarks in WQHD, UWQHD sowie Ultra HD und die Taktraten

AMD Radeon RX 9070 (XT) im Test: Benchmarks in WQHD, UWQHD sowie Ultra HD und die Taktraten

www.computerbase.de

 

[vinacis_vivids]

@Topic

Sapphire fordert mehr Freiheiten bei AMD-Grafikkarten

Sapphire, einer der wichtigsten exklusiven AIB-Partner von AMD, hat sich öffentlich für mehr Gestaltungsfreiheit bei der Entwicklung eigener Grafikkarten ausgesprochen. In einem Interview mit Hardware Unboxed erklärte Ed Crisler, PR-Manager von Sapphire Technology für Nordamerika, dass die...

www.tweakpc.de

Sapphire, ATIs Premiumpartner, hat mehr "Freiheiten" für AMDs Grafikkarten gefordert. Also mehr TBP für die höchste Taktrate und auch lang anhaltenden konstant hohe Taktraten.

Höhere (und stabile) Taktraten schützt vor sogenannten "Dips" und "Hicks" beim Gaming, was typisch für das grüne Lager ist.

 

[sompe]

Während AMD auf einheitliche Standards setzt, um Kompatibilität und Stabilität sicherzustellen, wünschen sich AIBs wie Sapphire mehr Spielraum, um Innovationen und Alleinstellungsmerkmale für Enthusiasten zu schaffen.

Das klingt nach "Back to the roots" wo jeder Kartenhersteller sein eigenes Ding machte und deshalb auch selbst die erfürderlichen Treiber Anpassen und zur Verfügung stellen mußte aber wegen der anfallenden Kosten eher selten pflegte.....

 

[Night<eye>]

weil ich von AMD jetzt erwarte, dass sie mit besserer Technik (und mehr Geld) wieder die Nr.1 im Grafikkartenmarkt werden.

RDNA4 ist meiner Ansicht nach bereits jetzt schon die technisch überlegene uArch ggü. überteuertes Schrottwell.

Effizienz am Desktop-PC interessiert letztendlich keine Sau wirklich

Erstmal hast du Recht damit das Blackwell Unterlegen ist.
Ich begründe dies mit 2 Aspekten:
1.) Blackwell hat einen Massiven CPU Driveroverhead, wodurch zb in CPU Lastigen Spielen wie Star Citizen, die N48 mehr FPS erreicht als die RTX 5080.
2.) Blackwell ist auch weniger Effizient in FPS pro Watt, sogar bei Modellen die Mhz Technisch im Sweetspot laufen.
(Referenz RTX 5090 mit Maximal 2400mhz Boost sowie RTX 5070ti mit 2450mhz maximalem Boost ab Werk)

Einfach Stumpf mehr Watt auf den Chip hauen wie Nvidia es macht kann jeder.
Sogar Intel könnte eine GPU Bauen, die 1000W frisst, und 10% schneller ist als die N48.
Aber das wäre keine Fortschrittliche GPU sondern eine Rückschrittliche.
Daher sage ich immer: FPS pro Watt ist immer der beste Indikator für Fortschritt.

Daher ist RDNA 4 ja auch wirklich Technisch den Blackwells überlegen wie du schon richtig sagst.
Allerdings ist es Interessant, wie AMD diesen Technischen Vorteil weg wirft mit dem Brechstangen Prinzip.
Die RX9070 nonXT ist auf Platz 1 und schlägt alle Blackwells in der Fortschrittsdisziplin FPS pro Watt. (Die Disziplin der Kenner)
Und die RX9070nonXT hat über 400mhz weniger als die RX9060XT und RX9070XT.
Es ist interessant was diese paar hundert Mhz unterschied ausmachen in dieser Relevantesten aller Disziplinen um den Fortschritt zu messen.

Spoiler: Watt-Brechstange kann jeder, FPS pro Watt ist der beste Indikator für Fortschritt.

 

[Complicated]

Am Ende zählt halt nicht der technische Vorteil in einer Kenner-Disziplin, sondern lediglich was der Markt möchte. Und hier haben die ganzen Benchmark-Redaktionen nun mal max. FPS gefeiert und da wird jetzt das Geld ausgegeben. Ich kann mich noch gut daran erinnern, als die effizientesten Modelle noch einen Preisaufschlag hatten, weil mehr Kunden an der Effizienz interessiert waren und das Binning den geringeren Verbrauch im Fokus hatte anstatt mehr Takt.

 

[sompe]

Das ist noch viel simpler.
Gefragt ist das wo nvidias Geforce Karten im Vorteil sind damit deren Kauf trotz Preistreiberei gerechtfertigt werden kann.

Das war bei der Bildqualität, der max. Framerate, der Effizient, sowie dem Idle, dem multi Monitor und dem Spiele Strombedarf so und wenn alle Stricke reißen beruft man sich auf Features welche die Konkurrenz nicht unterstützen kann. (CUDA, GPU Physx usw.)
Sobald sie das nicht mehr als Alleinstellungsmerkmal haben spielt es bei der Begründung keine Rolle mehr.

Solange die Kundschaft keine harte Bauchlandung hinlegt die richtig weh tut wird sich das auch nicht ändern.

 

[vinacis_vivids]

Nvidia's Kundschaft sind doch schon längst verarmt. Nur noch Lemminge kaufen den Schrott bei dem Dude.

 

[vinacis_vivids]

Golem

Neuigkeiten zu RDNA5 in der Xbox-Next:
- Next Gen DirextX
- Next Gen Ray Tracing
- GPU Work Graph Execution

- AMD FSR Next + Project Helix
- Next Gen ML Upscaling
- ML Multi Frame Generation
- Next Gen Ray Generation RT/PT

- Deep Texture Compression
- Neural Texture Compression
- Direct Storage

Microsoft scheint mit der Xbox-Next wieder die technischer Oberhand über die PS6 haben zu wollen. Für die vielen Features braucht man viele RDNA5 CUs sowie schnelle CPU Cores.

 

[vinacis_vivids]

Xbox Project Helix: AMD kündigt FSR Diamond als Antwort auf Sonys PSSR an

Mit Project Helix steht die nächste Xbox in den Startlöchern - und AMD liefert mit FSR Diamond das passende KI-Kraftpaket. Die neue Upscaling-Technik ist AMDs direkte Antwort auf Sonys PSSR sowie Nvidias DLSS und wurde jetzt offiziell angekündigt.

www.play3.de

AMD FSR-Diamond soll RDNA5 / Xbox-next unter Windows / Xbox-next unterstützen.
Das ist der Konter zu Sonys PSSR 2.0 (FSR4-int8).

 

[E555user]

Äh nein. So ist das alles nicht zu verstehen. Vielleicht mache ich noch einen ausführlicheren News-Artikel.
Im Wesentlichen gibt es hier aber nur ganz viel Marketingsprüche zu bekannten Technologien für künftige Produkte. Dass RDNA5 und PS6 deutlich aufgebohrte KI-Tops bringen und moderaten Zuwachs bei RT vs. RDNA4 bzw. gigantischem Zuwags vs. XSX/PS4 war auch schon länger klar. Auf dem Papier scheint eine Xbox Helix GPU 20% +/- ? schneller als eine PS6 werden zu können, das haben wir jetzt auch schon.

Bitter aber wahr ist in der Microsoft-Folie dass künftig/endgültig die Game-Engine der grösste Faktor sein wird. (Du hast die Reihenfolge dort verdreht).

 

[vinacis_vivids]

AMD FSR-Diamond ist in das Xbox-next SDK integriert, während PS5 zurzeit PSSR 2.0 nutzt.
Welchen Upscaler die PS6 verwendet, ist derzeit unbekannt. Kann auch sein, dass Sony PS6 einen eigenen Upscaler verwendet und nicht unbedingt auf FSR-Diamond setzt.
Ich gehe davon aus, dass es da schon unterschiedliche Ansätze gibt. Bei PS6 denke ich, dass da eine iNPU für Upscaling verwendet wird während Xbox-next sich auf FSR-Diamond stützen wird ohne iNPU und nur über die CUs rennt.

 

[E555user]

Die Softwareunterschiede im ML-Upscaler auf künftigen RDNA5 Architekturen sehe ich nicht als besonders relevant an. Ich bin aber ziemlich sicher, dass das über ML-optimierte CUs läuft, gerade so wie es im Amethyst-Video von Cerny und Huyng erklärt wurde.
MLID fasst aktuell nochmals seine Erwartungen für RDNA5 in Bezug auf die Konsolen zusammen.

Ich ziehe aus den aktuellen Aussagen zur GDC noch etwas anderes heraus, RDNA5 ist so unterschiedlich zu RDNA4, dass DevKits erst mit fertigem Silikon anfangs nächsten Jahres rauskommen. Gründe könnten sein
- Work Graphs sind womöglich nicht auf aktuellen Konsolen mit RDNA2 lauffähig (wurde auf RDNA3 getestet/entwickelt)
- HW-Scheduler für Work Graphs werden mit RDNA5 nochmals verbessert sein, auch für zStd wäre Optimierungen denkbar
- es wird neue ML optimierte Datentypen geben mit weniger Speicherbedarf und im Umkehrschluss mehr TOPS
- neben ML-Komprimierung wird die CU auch für zStd-Komprimierung optimiert werden (aka Sonys Universal Compression?)
- grössere L0 Caches für Textureload
- in-Memory Komprimierung durch Pointer/Adressarithmetik auf Datablocks bzw. Dictionary-Einträge
- grössere L0 Instruction Caches, Scalar Caches
- ML beschleunigte "RadianceCores" (Sony) deuten auf RT Umsetzung je CU wie bisher hin, nur mehr BVH und ML Leistung auf gleichem Cache innerhalb einer SE, also vermutlich wieder L1 wie bei RDNA3 oder spezifische Register, ein separater L0 für RT? Huynh meinte ja dazu, dass CPU komplett entlastet wird, d.h. der BVH-Tree wird wohl komplett auf der GPU berechnet. Wie dann per ML die Ray-Hit-Daten vervollständigt werden ist mir allerdings noch nicht klar, ob dort besonders schneller Austausch notwendig wäre.

Ich denke AMD hat bei RDNA4 mit den Schaubildern zum CU-Aufbau bei den Details mehr hinter dem Berg gehalten als die Generationen zuvor. Hier könnte es einiges geben das verbessert wird aber im Dunkeln bleibt.

 

[vinacis_vivids]

RDNA 5 ではより多くのケースで Dual Issue が機能し、ピーク FP32 性能を出しやすくなる可能性 | Coelacanth's Dream

LLVM で現在対応が進められている AMD RDNA 5 アーキテクチャ (gfx1310) だが、最近になり Dual Issue VALU/Wave32 に関するプルリクエストが公開された。 [AMDGPU] Add VOPD to gfx13 (#182815) · llvm/llvm-project@1911488 Dual Issue VALU は RDNA 3 アーキテクチャ (GFX11) から実装された機能であり、VOPD 系命令 (V_DUAL_*) を最大 2種類を組み合わせて、X側と Y側に同時に発行することができる。...

www.coelacanth-dream.com

Gfx1310 (RDNA5) kann wie Gfx1250 (RDNA4.5) bessere "Dual Issue" Fähigkeiten für fp32-Operationen.

 

[tex_]

Das ist nicht verwunderlich, da RDNA3 aus der theoretisch doppelten Rechenleistung wenig Nutzen ziehen konnte. Die getrennten Registersets für Dual Issue scheinen wirklich ein großes Problem zu sein, da stellt sich die Frage ob das wirklich so eine gute Idee war. Ob ein paar neue Instruktionen die nun beide Registersets nutzen können das Problem beseitigen wird interessant werden.

 

[Night<eye>]

Ich ahne böses. RDNA war gegenüber GCN so Smooth. (Besonders RDNA 2 & 4)
Jetzt kommen wieder Experimente die mir Flashbacks an heiße Architekturen wie bei Vega & Tahiti geben
Polaris war ja auch nicht gerade sehr Effizient für seinen besseren Shrink gegenüber der sehr viel älteren GTX 970 in altem Shrink damals.

 

[vinacis_vivids]

Im Durschnitt konnte bei Dual-Issue, zwei gleiche fp32-Operationen in der ersten Generation, spricht RDNA3/RDNA4 ca. +17% Geschwindigkeit ggü. Single-Issue geholt werden.

Hier liegt sicherlich noch viel Potenzial für eine Veränderung bzw. Verbesserung.

Hier wird auf eine Verdopplung der Leistung spekuliert:

AMD RDNA 5: Geheimrezept enthüllt? Verbesserter Dual-Issue-Chip könnte Leistung verdoppeln

https://overclock3d.net/news/gpu-di...improved-dual-issue-could-double-performance/

MT - Machine Translation:

"Dank einer Funktion namens „Dual Issue“ können zwei Operationen in einem einzigen Taktzyklus ausgeführt werden, wodurch die Leistung betroffener Anwendungen verdoppelt wird."

"Darüber hinaus wurden mit RDNA 5 (gfx1310) die Beschränkungen bei Dual Issue teilweise gelockert, sodass nun dasselbe Eingangsregister sowohl für die X- als auch für die Y-Seite angegeben werden kann. Dies trägt dazu bei, die Anzahl der Anwendungsfälle für Dual Issue zu erhöhen.

– Der Traum des Quastenflossers"

Die RDNA5 CUs können IPC mäßig schon gut steigern ggü. RDNA3/RDNA4.

 

[E555user]

Der Artikel ist ganz OK - aber eigentlich auch nur eine englische Aufbereitung des japanischen Forenbeitrags (!?). Das Problem beim bisherigen Dual-Issue Support ist letztlich nicht unbedingt dass Gamedevs das nicht supporten wollten, das Problem ist dass der üblicher HLSL Code bisher kaum im GPU-Compiler damit beschleunigt werden konnte. Die wenigsten Devs werden so spezifisch optimieren wenn es nur Radeon-Gen-xy ist, für Konsole schon eher.
Mehr als 20% ist wirklich erstmal nicht drin, 50% wäre toll, Verdoppelung ist bei Gaming natürlich nonsense. Fürs Rendern ist SIMD doch eher der übliche Fall.

 

[Night<eye>]

das Problem ist dass der üblicher HLSL Code bisher kaum im GPU-Compiler damit beschleunigt werden konnte. Die wenigsten Devs werden so spezifisch optimieren wenn es nur Radeon-Gen-xy ist, für Konsole schon eher.
Mehr als 20% ist wirklich erstmal nicht drin, 50% wäre toll

Du kennst dich mit Engines anscheinend gut aus.
Weißt du evtl wie effektiv Dual Issue bei Star Citizen fungieren könnte ?

 

[E555user]

Nein, das weiss ich nicht. Das wissen am Ende nur die Engine-Entwickler selbst, evtl. auch jemand der sich mit der Cry-Engine auskennt könnte spekulieren, falls es da noch Ähnlichkeiten gibt. Am Ende wird kaum jemand seinen HLSL Code für die ISA einzelner GPUs optimieren wenn er nicht selbst an der Engine bastelt, das war mein Punkt.
Wenn man nun in einer CU weniger gleichförmig Code ausführen möchte, weil z.B. bei Strahlenberechungen sehr unterschiedliche Zwischenergebnisse weiterverfolgt werden müssen, dann könnte das künftig sicherlich mehr helfen. Es müssten relevante Ops für die jeweiligen Berechnungen in der ISA möglich sein. Daher meine Speku der 20%-50%.
Wenn aber bspw. in UE5 Nanite128 Dreiecke in Software geshaded werden, dann sind das in den meisten Fällen immer die gleichen Ops. Mir fällt bei deren Grundprinzip nichts ein wo da ein besonderer Vorteil entstehen würde, mag sein dass da in Lumen und Co das helfen könnte, müsste man analysieren.

PS: nur so eine Gedankennotiz
... bei den DualCU und WGP aka DualDualCU mit 128T war mit dem Zusammenschalten in den gemeinsamen Modus und bei Trennung für den Cache AFAICR immer ein Flush angesagt. Wenn jetzt durch Dual-Issue beim kurzen Wechsel der Cache nicht invalidiert werden müsste wäre das natürlich cool für das Scheduling, v.a. wenn das intern auf deren HW-Scheduler zurückfällt.

 

[vinacis_vivids]

Diese Befehle können Dual-Issue bei RDNA5:

"V_FMAC_F32_e32", "V_FMAAK_F32", "V_FMAMK_F32", "V_MUL_F32_e32", "V_ADD_F32_e32", "V_SUB_F32_e32", "V_SUBREV_F32_e32", "V_MUL_LEGACY_F32_e32", "V_MOV_B32_e32", "V_CNDMASK_B32_e32", "V_MAX_F32_e32", "V_MIN_F32_e32", "V_DOT2C_F32_F16_e32", "V_DOT2C_F32_BF16_e32"

Das sieht sehr gut aus was den Umfang angeht. Das sind 14 unterschiedliche Operationen, die nun in RDNA5 "Dual-Issue" CU ausgeführt werden können. Davon zwei fp16/bf16 Befehle.

Addition, Multiplikation, Subtraktion, Akkumulation usw. sind Vorhanden und int32 ist mit Dual-Issue möglich.

Sieht gut aus mit bis zu +50% IPC-Gewinn in manchen, nicht in allen Fällen. Durchschnitt (50+20)/2 = +35% IPC Gewinn für RDNA5 durch Verbesserungen im Dual-Issue Mode. RDNA5 macht Dual-Issue mit wave32.

 

[Night<eye>]

Nein, das weiss ich nicht. Das wissen am Ende nur die Engine-Entwickler selbst, evtl. auch jemand der sich mit der Cry-Engine auskennt könnte spekulieren, falls es da noch Ähnlichkeiten gibt.

Es gab ja jetzt die Meldungen zum neuen FSR Diamond, und Spekulationen deuten daraufhin das es ausschließlich für RDNA 5 sein wird.
Mich besorgt eine Sache.
Selbst für das alte FSR 4 gibt es noch keinen Offiziellen Vulkan Support. (Star Citizen basiert auf Vulkan)
Daher frage ich mich, ob für das neue FSR (Ich nenne es mal FSR 5) überhaupt Vulkan support erscheinen wird.
Was denkst du ?

 

[E555user]

Wie bei NN basiertem Upscaling bereits anderswo beschrieben ist das portieren auf andere Architekturen grundsätzlich möglich, es ist lediglich Mathematik mit Lookup durch ein Netz von Gewichtungen. Die Frage ist letztlich ob das Modell und der Rechenaufwand auf bestimmten GPUs und typische Auflösung noch für Echtzeitgrafik schnell genug läuft. Bei FSR4 darf man davon ausgehen, dass AMD bislang davon ausgeht, dass der Aufwand das auf RDNA3 zu bringen zu gross ist und die dann auch negativen Reaktionen nicht wirklich überwiegt. Es könnte durchaus nicht auf allen RDNA3 oder älteren GPUs durchweg gut nutzbar sein, zumindest sind bei RDNA4 die TOPS sehr viel grösser. Oder aber AMD scheut den Entwicklungsaufwand weil man das Personal dringender an anderer Stelle benötigt, typischer Weise professinelle AI Anwendungen mit ROCm, das ist momentan strategisch der wichtigste Markt.

Für Vulkan mache ich mir keine Sorgen solange Valve die Steam-Machine noch bringen will sollte das kommen. FSR5 wird nochmals grössere NNs und mehr Rechenoperationen pro Frame benötigen. Ab FSR3.1 kann man auch im Treiber ein Upscaling "einfach" per DLL-Wechsel auf andere Versionen tauschen, eine abgestimmte Entwicklung mit Microsoft. Die in der DLL benötigten Ops sollte dann aber schon auch in HW unterstützt werden. Womöglich war die Strategie von AMD die FSR-Version 3-4-5 an die RDNA-Version zu koppeln. Es ist sehr viel einfacher in der Entwicklung nur ein NN für ganz bestimmte HW anpassen bzw. optimieren zu müssen. Zudem kann man dann von der vielfach höheren TOPs Leistung mit neuen Datenformaten ausgehen, wo man bei älteren Architekturen Kompromisse oder Neuanfänge machen müsste. Aber auch an fehlendem offiziellen Vulkan-Support sieht man, AMD ist hauptsächlich daran Prioritäten zu setzen weil man zu wenig Personal für diese Dinge hat.

Bis FSR3.1 waren es letztlich Shader-Algorithmen, die HW-agnostisch waren solange es moderne GPUs mit modernem Direct-X Shader Model Support waren. Da wurde AMD noch gefeiert für die Rückwärtskompatibilität inklusive GeForce. Aber das ist so schnell vergessen und der Trend ist aktuell AMD für mangelnde Rückwärtskompatibilität abzustrafen. Da war alle Bemühung der Vergangenheit fast umsonst.