RDNA5 bzw. UDNA1 (Navi 5X, Radeon RX 10000 Serie, MCM, 2026)

[davidzo]

Dann wurden unsere Gebete ja endlich erhört.

Hier im Forum sprechen wir uns spätestens seit Navi24 für die Rückkehr von DDR bzw. LPDDR in den entrylevel GPU Markt aus. Früher konnten die entrylevel GPUs meist Schritthalten mit den Midrange Modellen wenn es um die VRAM Ausstattung ging, was für die Entwickler einfach war weil die Texturen nicht in X verschiedenen Auflösungen vorliegen müssen und man eher mit LOD etc. arbeiten konnte um die Komplexität der Szene zu reduzieren. Seit 3-4 Generationen ist das nicht mehr der Fall und statt einfach alle Texturen in den VRAM zu laden gibt es aufwändige Textur streaming Verfahren.

AMD war eigentlich prädestiniert dafür das schon viel früher zu machen, da sie die LPDDR eh breitflächig in APUs verwenden. Auch unterhalb von N33 hatte ich sowas eigentlich erwartet.

Dass AMD in 2026 auch den midrange (4060 level) mit LPDDR abdeckt ist nur konsequent, litten die vergangenen Midrangekarten doch seit der 3060 immer wieder massivst unter VRAM Mangel.
Anfangs lag das tatsächlich am Preis für schnellen GDDR6 (rund 30$ für 8GB). GDDR7 dürfte aktuell in ähnlichen gefilden liegen. Mittlerweile hat nvidia das als effektive Upselling Methode entdeckt obwohl die preise unter 20$/8Gb gesunken sind, zumindest für GDDR6.

[basix]

Fixfertige DDR5-DIMMs gibt es ja zum Teil mit ~2$/GByte im Handel. Da ist Vendor- und Händler-Marge auch schon drauf.

LPDDRx soll etwas teurer als deren Geschwister sein, aber das dürfte nicht viel sein. Es kann insgesamt also gut sein, dass LPDDR5X/LPDDR6 ca. 2/3 so teuer sind wie GDDR6/GDDR7. Dann bekäme man 12 GByte für 8 GByte und 16 GByte für 12 GByte und wäre somit ideal für Mainstream-GPUs (AT4 mit 12 GByte und AT3 mit 16 GByte). Bei 10'667...17'066 MT/s und 2-ch Interface erreicht man doch 256...409.6 GB/s Bruttotransferrate. Bei einem 4-ch Interface (AT3) wären es 512...819.2 GB/s. Eine 9070XT hat auch nur 640 GB/s.

[robbitop]

Wobei der LLC und dessen hitrate mit betrachtet werden muss und nicht nur die externe Bandbreite. Wenn es deutlich weniger LLC gibt braucht es mehr externe Bandbreite für die gleiche Performance.

[davidzo]

LPDDRx soll etwas teurer als deren Geschwister sein, aber das dürfte nicht viel sein. Es kann insgesamt also gut sein, dass LPDDR5X/LPDDR6 ca. 2/3 so teuer sind wie GDDR6/GDDR7.

Preis ist eben auch eine Stückzahlenfrage. LPDDR hat mittlerweile vergleichbare bis größere Stückzahlen gegenüber non mobile DRAM. Der Consumer DDR Markt (PCs, labtops) ist schon seit Jahrzehnten weitaus kleiner als der Consumer markt für mobile DRAM (Telefone, mittlerweile auch Notebooks). Bislang hat das Wachstum in den Rechenzentren es aber immer noch rausgerissen für DDR5 und Co. Da Rechenzentren aber aktuell vermehrt in GPUs und HBM investieren und bei klassischen Servern nur noch konsolidieren, könnten DDR5 und DDR6 die Verlierer sein.

Möglicherweise ist in der nächsten Generation also LPDDR6 die am meisten gehandelte Commodity und nicht mehr DDR6.

[HOT]

Zeit für ne Liste:

AT0 -> 192CUs 4x2x12 WGP, 512Bit GDDR7, N2P (N3P wäre völlig sinnlos für den Chip, zumal AMD ja eh schon erfolgreich mit N2P arbeitet und jeder mm² zählt bei der Größe)
AT2 -> 72CUs 3x12 WGP, 192Bit GDDR7, N3P
AT3 -> 48CUs 2x12 WGP, 256Bit LPDDR5x oder 384Bit LPDDR6, N3P
AT4 -> 24CUs 1x12 WGP, 128Bit LPDDR5x, N3P

[horn 12]

Dies wäre dass ja nur 15 bis 20% über einer 9070 XT wenn man AT2 hernimmt
Wenn es hochkommt,- da wäre man knapp an einer 4090

[HOT]

Würd auch sagen, der kommt knapp >4090 raus.

[basix]

AT0 -> 192CUs 4x2x12 WGP, 512Bit GDDR7, N3P
AT2 -> 72CUs 3x12 WGP, 192Bit GDDR7, N3P
AT3 -> 48CUs 2x12 WGP, 256Bit LPDDR5x oder 384Bit LPDDR6, N3P
AT4 -> 24CUs 1x12 WGP, 128Bit LPDDR5x oder 192Bit LPDDR6, N3P
Leichte Anpassungen in fett, wie ich das erwarten würde ;)

[horn 12]

Und AT0 kommt für Endkunden, oder nur für AI udg.
oder wird dies eine Titan wie bei NV werden.

[dargo]

Boah... bitte nicht den gleichen bullshit bei AMD jetzt auch wie schon bei Nvidia. :facepalm: Damit meine ich den riesen Abstand zwischen AT0 und AT2.

[HOT]

Leichte Anpassungen in fett, wie ich das erwarten würde ;)
Vielleicht theoretisch, aber es gibt keinen Grund das praktisch umzusetzen. Das war schon absicht, dass ich das weggelassen habe. Und wie ich schon schrieb, N3P für den AT0 ergibt überhaupt keinerlei Sinn.

[basix]

Ach ja?
- Der mit Abstand grösste Chip im noch unerprobtesten Prozess? Selbst Zen 6 und MI400 nutzen N2P nur für relativ kleine Chiplets
- Die ganze RDNA5 IP von N3P auf N2P portieren? Alle anderen Produkte (dGPUs wie auch APUs, vermutlich auch NextGen Konsolen) nutzen N3P bei den Chips, wo RDNA5 drauf ist

N2P wäre für AT0 aus leistungstechnischer Sicht sicher schön. Aber es gibt schwerwiegende Gründe (Kosten, R&D Aufwand, Risiko) welche dagegen sprechen.


Boah... bitte nicht den gleichen bullshit bei AMD jetzt auch wie schon bei Nvidia. :facepalm: Damit meine ich den riesen Abstand zwischen AT0 und AT2.
AT1 gäbe es noch dazwischen (256bit, 96 CU). Der wurde aber anscheinend gecancelt.

AT0 wie auch GB202 würde es in dieser Form gar nicht geben, wenn es nicht ML/AI gäbe. Die wären sonst auf 384bit und 75...80% der SMs reduziert. Als Top Dog Käufer kann man das aus gewisser Sichtweise sogar begrüssen, da man fettere GPUs bekommt (zu einem natürlich höheren Preis).
99% der Gamer wird das aber wenig interessieren ob der grösste Chip noch fetter und teurer wird, wenn eine 5080 bereits 1000$ kostet und AT2 wohl auch ~600$ kosten wird. Da ist der relative Abstand zum grössten Chip nicht so relevant.

Ihr (und 99% von Gamern) solltet euch lieber auf folgendes freuen:
- AT2 mit 18/24 GByte, ~5080...4090 Performance für ~600/700$
- AT3 mit 16 GByte, ~5070 Ti / 9070 XT Performance für ~400$
- AT4 mit 12 GByte, ~5060 Ti / 9060 XT Performance für ~250$

Und obendrauf aufgebohrtes Featureset für verbessertes Pathtracing, Neural Rendering usw.

[dargo]

AT1 gäbe es noch dazwischen (256bit, 96 CU). Der wurde aber anscheinend gecancelt.

Was es gäbe juckt hier nicht, es hilft dem PC-Gaming Markt in keinster Weise.



Ihr solltet euch lieber auf folgendes freuen:
- AT2 mit 18/24 GByte, ~5080...4090 Performance für ~600/700$
- AT3 mit 16 GByte, ~5070 Ti / 9070 XT Performance für ~400$
- AT4 mit 12 GByte, ~5060 Ti / 9060 XT Performance für ~250$
Was gibt es hier zu freuen? Wo ist der Anreiz bei RDNA5 für einen N48 Besitzer? AT0 für teures Geld und mit hoher Wahrscheinlichkeit auch viel Durst ansonsten auf RDNA6 warten? Lol...

[basix]

+50% Performance, mehr Speicher und deutlich schnelleres Pathtracing (was mMn bei PS6 / Xbox Next zum Standard werden wird) sind für dich also keine Argumente?

Wenn du deine 9070XT verkaufst, bezahlst du nichtmal so viel obendrauf ;)

Und wenn es dich nicht interessiert: Es gibt andere Leute, die es interessieren wird ;)
Es gibt viele Leute, die noch keine Karte mit N48 Performance haben. Für 400$ wäre das mMn ein ansprechender Deal.

[HOT]

Wenn die wirklich AT3 und 4 mit LPDDR5x bringen haben die auch nicht nur so wenig RAM...
Da dürfte AT4 dann 16GB und AT3 24GB haben und auch bei AT2 würde ich nicht von 18GB ausgehen, bis dahin wird es 32Gbit-Module geben, was auch 24GB wären.

@basix N2 hatte die ganze Zeit sehr gute Yields, es gab keinen Grund nicht auf den Prozess zu setzen für AMD, erst recht nicht wenn man wichtigster Kooperationspartner mit Exklusivdeal war. Natürlich ist AT0 aus meiner Sicht N2P, N3P ergibt keinen Sinn bei dem Hintergrund. Außerdem wirst du eine Menge salvage haben (immerhin sämtliche Consumerchips).

[basix]

Wieso sollten sie mehr VRAM draufpacken als nötig? Oder hast du die 8GB 5060 / 5060 Ti / RX 9060 und 9060XT vergessen?

[dargo]

Ich erwarte keine +50% bei AT2. Wie kommt man überhaupt auf solche Zahlen? Vielleicht einzelne, rausgepickte Rosinen aber bestimmt nicht im Schnitt der Spiele.


Es gibt viele Leute, die noch keine Karte mit N48 Performance haben. Für 400$ wäre das mMn ein ansprechender Deal.
Du hast da imo viel zu optimistische Erwartungen an die Performance und Preise. Letzteres insbesondere unter dem Aspekt eines noch teureren Fertigungsprozesses mit RDNA5.

[basix]

Ich erwarte keine +50% bei AT2. Wie kommt man überhaupt auf solche Zahlen?

Educated guess ;)

[dargo]

Entschuldige bitte, aber mir ist da noch zu viel wildes Spekulatius in deiner Prognose. ;)

[dildo4u]

Kommt drauf ob sie es ernst meinen Path Tracing Konsolen zu bauen du willst was in Bereich der 5080, was eine realistische Performance für die 6070 Klasse in 2027 wäre.


3080 waren z.b 300 Watt und 4070 200 Watt was ins Konsolen TDP passt.

[HOT]

Wieso sollten sie mehr VRAM draufpacken als nötig? Oder hast du die 8GB 5060 / 5060 Ti / RX 9060 und 9060XT vergessen?

Das wird einfach Standard sein. Siehe NV: 5070S -> 18GB 5070TiS -> 24GB
Da kannst nicht mehr mit solchen pipimengen auflaufen... das wird so nicht kommen, du wirst mindestens 16GB sehen, erst recht mit LPDDR-RAM.



AT2 soll ja 10% mehr IPC als RDNA4 haben, zudem dürfte der Takt auf 3,5GHz steigen, da kommst bei 72CUs sicherlich irgendwo knapp über der 4090 raus. Mit 24GB 36GT/s GDDR7-RAM haste auch ausreichend Bandbreite, aber ein nativ-UHD-Chip ist das dann natürlich wieder nicht.

[horn 12]

Hier:

https://videocardz.com/newz/amd-rdna5-rumors-point-to-at0-flagship-gpu-with-512-bit-memory-bus-96-compute-units

Kepler gepostet
Dies würde Sinn machen und ein Update für 9070XT rechtfertigen
Plus 50 bis 60% sollten machbar sein

[basix]

Das wird einfach Standard sein. Siehe NV: 5070S -> 18GB 5070TiS -> 24GB
Da kannst nicht mehr mit solchen pipimengen auflaufen... das wird so nicht kommen, du wirst mindestens 16GB sehen, erst recht mit LPDDR-RAM

Jetzt vermischt du aber etwas an meiner Aussage. AT2 wird in 18 & 24 GByte Konfigurationen daherkommen. Das bestreite ich nicht und macht für den Performance-Bereich auch Sinn. Es ging mehr um AT3 und AT4, welche nicht mit "masslosen" VRAM-Mengen daherkommen werden. LPDDRx ist günstiger aber was bringen dir 24 GByte auf einer AT3 Karte? Du zahlst als Kunde mehr aber wirst faktisch nie was davon haben (bei reinem Gaming Use Case). Über 16 GByte bei AT4 kann man noch reden, aber das wird ein 1x SE / 24 CU Mini-Chip werden (~100mm2 ohne MID).

Vielleicht also sowas, um meine "Vision" klarzustellen ;)
- AT2 = 18GB & 24 GByte Varianten
- AT3 = 16 GByte
- AT4 = 12GB & 16 GByte Varianten

Nur weil es günstiger LPDDRx Speicher ist, wird man nicht plötzlich per Giesskanne riesige Speichermengen verbauen. So funktioniert betriebswirtschaftliche Arbeit nicht, auch wenn wir Kunden das gerne anders hätten.
Bei den Profi-Karten sowie allfälligen ML/AI Use Cases sieht das natürlich anders aus. Da können AT3 und AT4 aus dem Vollen schöpfen und 128 GByte oder mehr verbauen.

[dargo]

AT2 soll ja 10% mehr IPC als RDNA4 haben, zudem dürfte der Takt auf 3,5GHz steigen...
Bei welcher Gaming-Last? :tongue: Ich kann auch einen N48 schon spielend auf 3,xGhz hochjagen, nur wird dann das Teil zur Saufziege bei höheren Heizlast.

[HOT]

basix
Das interessiert doch keinen. Das Ding hat billige 24GB, das wird gekauft. Ist doch total egal ob die das brauchen oder nicht (zumal das wieder mal sehr optimistisch ist von dir ;). Wir reden hier von ab Mitte 27).

Bei welcher Gaming-Last? :tongue: Ich kann auch einen N48 schon spielend auf 3,xGhz hochjagen, nur wird dann das Teil zur Saufziege.

RT ist komplette Wildcard, keine Ahnung wie das abschneiden wird, das weiß niemand. Ich rede bei sowas immer nur von Raster. Und ob UDNA bei 3,x GHz saufen wird wird sich zeigen.

[basix]

Mit 16 GByte ist es noch billiger ;)

[HOT]

Vergiss nicht immer das Marketing... Außerdem reden wie von Mitte 27 folgend, da ist 16GB wie 12GB jetzt oder viel schlimmer...

[dargo]

Hier:

https://videocardz.com/newz/amd-rdna5-rumors-point-to-at0-flagship-gpu-with-512-bit-memory-bus-96-compute-units

Kepler gepostet
Dies würde Sinn machen und ein Update für 9070XT rechtfertigen
Plus 50 bis 60% sollten machbar sein
Hä? Da steht was von 96CUs für AT0. Wie zum Teufel kommt basix auf 192CUs? :freak: Außerdem AT2 nur 40CUs. ;D

[basix]

Vergiss nicht immer das Marketing... Außerdem reden wie von Mitte 27 folgend, da ist 16GB wie 12GB jetzt oder viel schlimmer...

Wie viel hat Marketing gebracht, als Nvidia die 5060 Ti 8GB rausgebracht hat? Ja, Tests sind negativ aber die meisten PC Pre-Builts nutzen die 8GB Variante.

Und 12 GByte sind Ende 2026 / Anfang 2027 mit hoher Wahrscheinlichkeit langlebiger als 8 GByte heute. Solange man bei 1080p bleibt.
Und eben, wenn es noch eine 16 GByte Variante gibt hat der Kunde die Wahl. Die gibt AMD den Kunden mit der 9060XT 8GB auch :D

Hä? Da steht was von 96CUs für AT0. Wie zum Teufel kommt basix auf 192CUs? :freak: Außerdem AT2 nur 40CUs. ;D
Beim schnellen zeichnen WGP mit CU verwechselt. Das kann auch Kepler_L2 passieren ;)
Oder was willst du mit 96CU an einem 512bit GDDR7 Interface machen? ;)

40 WGP / 80 CU wäre ein denkbare Variante von AT2, wenn 36 WGP / 72 CU vom Chip-Layout nicht optimal wären. Würde dann aber auch 4x SE anstatt 3x SE bedeuten (wie es Kepler auch eingezeichet hat).
Da der Xbox Next Chip mit AT2 spekuliert wird und ~66...70 CU tragen soll (66 CU wären bei 72 CU und 3x SE meine Wahl, -1x WGP pro SE), ist 72 CU wahrscheinlicher. Sonst wäre der Verschnitt bei der Xbox Next zu gross.

[davidzo]

Hä? Da steht was von 96CUs für AT0. Wie zum Teufel kommt basix auf 192CUs? :freak: Außerdem AT2 nur 40CUs. ;D

Es ist ein komplett neues Gerücht, dass den bisherigen MLID Angaben widerspricht.
Dementsprechend sind die IPC Angaben von MLID auch nicht übertragbar. 96 und 40CU klingt aber eher nach AMD und dass Infinity-cache wieder im Spiel (L2 wird umbenannt?) ist klingt imo auch realistischer.

Gleichzeitig sind es dieselben Namen wie MLID geleakt hatte. Bei den Chip-Bezeichungen lag er also richtig. In dem neuen Kepler Leak gibt es widerrum nichts was nach offiziellen Infos klingt, sondern eher mehr nach educated Guess seitens Kepler womit er in der Vergangenheit auch häufiger mal falsch lag.

[mboeller]

Hä? Da steht was von 96CUs für AT0. Wie zum Teufel kommt basix auf 192CUs? :freak: Außerdem AT2 nur 40CUs. ;D

nt ... hat basix schon beantwortet

[basix]

Bei den Chip-Bezeichungen lag er also richtig. In dem neuen Kepler Leak gibt es widerrum nichts was nach offiziellen Infos klingt, sondern eher mehr nach educated Guess seitens Kepler womit er in der Vergangenheit auch häufiger mal falsch lag.

Ist nicht viel mehr als ein "Schizopost", siehe hier die Originialquelle ;)
https://forums.anandtech.com/threads/rdna-5-udna-cdna-next-speculation.2624468/page-40#post-41496872

Und hier eine tabellarisch aufgestellte Form von dem:
https://forums.anandtech.com/threads/rdna-5-udna-cdna-next-speculation.2624468/page-40#post-41497579

2x old CU / WGP / New CU:
Wird alles durcheinandergewürfelt, bedeutet aber das selbe. Einzel CUs gibt es bei RDNA4 per Definition nicht. Die kleinste Einheit pro SE ist ein WGP mit 2x CU (in RDNA1...4 Sprech). Bei RDNA5 soll die CU jetzt anscheinend doppelt so gross werden (1x RDNA5 CU = 2x RDNA4 CU = 1x RDNA4 WGP)

Edit:
Weiter im Thread noch eine interessante Speku: RDNA5 und CDNA5 gehen in Richtung Apple M3+ Cache Design?
https://forums.anandtech.com/threads/rdna-5-udna-cdna-next-speculation.2624468/page-40#post-41497615
https://forums.anandtech.com/threads/rdna-5-udna-cdna-next-speculation.2624468/page-40#post-41497616
https://forums.anandtech.com/threads/rdna-5-udna-cdna-next-speculation.2624468/page-40#post-41497631

CDNA4 is 32KB L0 + 160KB LDS, CDNA5 is 448KB Shared L0/LDS
-> Zusammenfassung von L0$, LDS und vielleicht auch Registerfile zu einem grossen unified/shared Cache?!

Hier ab Minute 11:37
https://developer.apple.com/videos/play/tech-talks/111375/

Dynamische Register-Allokation hat AMD bei RDNA4 bereits eingeführt. Sieht so aus, also könnten sie hier noch näher an Apples Design-Ansatz ranrücken (unified CU cache, dynamic/OoO scheduling).
Eine effektivere Nutzung der Caches innerhalb der CUs und SE kann natürlich eine Erklärung sein, wieso ein etwas grösserer L2$ ausreicht gegenüber L2$ + MALL.

[AffenJack]

Es ist ein komplett neues Gerücht, dass den bisherigen MLID Angaben widerspricht.
Dementsprechend sind die IPC Angaben von MLID auch nicht übertragbar. 96 und 40CU klingt aber eher nach AMD und dass Infinity-cache wieder im Spiel (L2 wird umbenannt?) ist klingt imo auch realistischer.

Gleichzeitig sind es dieselben Namen wie MLID geleakt hatte. Bei den Chip-Bezeichungen lag er also richtig. In dem neuen Kepler Leak gibt es widerrum nichts was nach offiziellen Infos klingt, sondern eher mehr nach educated Guess seitens Kepler womit er in der Vergangenheit auch häufiger mal falsch lag.

Kepler hat schon häufiger bzgl RDNA5 Sachen geposted, die nicht zu MLID Aussagen passten. Ich hab das nur am Rand mitbekommen, aber fand das ja immer spannend, dass hier MLID als zuverlässiger als Kepler gesehen wird.

MLID lag in der Vergangenheit auch verdammt oft falsch.

[HOT]

Hä? Da steht was von 96CUs für AT0. Wie zum Teufel kommt basix auf 192CUs? :freak: Außerdem AT2 nur 40CUs. ;D

Das ist so ne Sache mit den CUs. Ich vermute, dass sowohl Kepler als auch MLID recht haben und das wie basix schon ausführte tatsächlich nur Definitionssache sein könnte, denn es kann sein, dass AMD die WGPs jetzt einfach als CUs bezeichnet, denn die werden bei UDNA ja noch mehr Synergien ausnutzen.

AT0 -> 192CUs 8x2x6 WGPs/CUs, 512Bit GDDR7, N2P, (384Bit und ca.84WGP/CU) 48GB 36Gbit/s 16Gbit GDDR7 (Doppelseitig) (Radeon AI290)
AT2 -> 80CUs 4x2x5 WGPs/CUs, 192Bit GDDR7, N3P, 36GB 36Gbit/s 24Gbit GDDR7 (Doppelseitig) (Radeon AI280)
AT3 -> 48CUs 2x2x6 WGPs/CUs, 256Bit LPDDR5x oder 384Bit LPDDR6, N3P, 24GB LPDDR5x 10667 (Radeon AI270)
AT4 -> 24CUs 1x2x6 WGPs/CUs, 128Bit LPDDR5x oder 192Bit LPDDR6, N3P, 16GB LPDDR5x 10667 (Radeon AI260)

Über salvage braucht man sich bei den diskreten GPUs keine Gedanken mehr machen, dafür gibts ja die APUs/Magnus und der N3P-Yield soll wahnsinnig gut sein. Vielleicht gibts noch ne GRE oder sowas.
Nochmal an basix Speicherkonfiguration: Die Speicherausstattung wäre knapp, die neuen Konsolen sollten alle mindestens 24GB RAM bekommen wegen AI, selbst das PS Handheld, denn die Developer brauchen mindestens 10GB ausschließlich für AI. Jetzt hat man auch den wahren Grund, warum die alle LPDDR benutzen, denn das trifft die PS6+Handheld offenbar beide, nur Magnus nicht.

[robbitop]

AMD spricht IIRC auch schon relativ lange primär von WGPs und kaum noch von CUs (seit RDNA1 schon). Das kann dann auch schnell mal verwechselt werden. Ich denke auch dass Kepler WGPs meint.

[dargo]

Bei den neuen Konsolen kommen hoffentlich 32GB. Auch dort kann AMD wunderbar den LPDDR5x verwenden.

[robbitop]

Also ich empfand schon PS5 und PS5PRO als enttäuschend was RAM angeht. Die RAM Preise sind ja glücklicherweise gesunken und nun kann es auch endlich mal einen Sprung beim RAM geben.
Und wenn Laptop RAM dabei hilft -> warum nicht?
Die Frage ist nur ob bei Konsolen der Tradeoff genauso greift (dank kleinerer Taktfrequenz des Laptop RAMs muss man mehr Breite und/oder mehr Cache akzeptieren was Kosten des PCBs und kosten des dies (wird größer) beeinflusst). Aber wenn das bei AT3/4 so funktioniert - warum nicht auch in der Konsole.
Die Rumors sind ja dass einer der ATs (AT3?) sogar in der nächsten Xbox verbaut wird.

[Exxtreme]

Konsolen werden eher GDDR7 als RAM verwenden weil sich die CPU und der Grafikchip den RAM teilen. Und da ist die viel höhere Bandbreite wichtiger auch wenn man hohe Latenzen inkauf nehmen muss. Vielleicht werden die Konsolen aber auch einen X3D-Cache bekommen um die hohen Latenzen ein wenig zu egalisieren.

[robbitop]

IMO muss man sehen was für eine Bandbreite von X am günstigsten ist. Und das kann man mit GDDR erreichen aber auch mit LPDDR. Je nach Breite und Cache. Egal ob für eine GPU oder eine APU.
Wenn das für eine Konsole keinen Sinn machen würde, warum tut man es dann für die großen APUs die ja auch ähnlich sein werden? (Medusa Halo / mini)

[Exxtreme]

GDDR7 hat ca. 3,8x so viel Bandbreite wie DDR5-SDRAM. Das auszugleichen wird sehr schwer. Da müsste man die Busbreite vervierfachen. Und das erhöht die Produktionskosten beträchtlich. Und die Margen sind bei Konsolen extrem dünn, oft sogar negativ.

[HOT]

Man wird einfach entsprechend mehr Bandbreite verwenden. Bei AT4 und AT3 ist das ja schon so - AMD baut GPUs mit LPDDR, falls du das nicht mitbekommen hast.
Die PS6 hat ja auch offenbar nur 48CUs, da wird 384Bit LPDDR6 reichen. Das PS Handheld hat offenbar LPDDR5x, wie es aussieht, das scheint aber auch ein Jährchen früher zu erscheinen. Und Magnus setzt ja nach wie vor auf GDDR7, aber eben mit recht wenig Bandbreite von nur 192Bit.

[ChaosTM]

Der Junge von Moore's Law Is Dead (https://www.youtube.com/watch?v=x-A3Bl2hXoQ&t=1358s) spricht von 24-32GB beim Canis Handheld und 32-40 bei der Orion Variante für die PS6.
Vorher zufällig gesehen. K.a. ob das hinkommen kann/wird.

[HOT]

Von der PS4 8GB zur PS5 16GB zur PS6 32GB, kann schon gut sein. Er meint auch, das Handheld soll mindestens 24GB bekommen.

[robbitop]

GDDR7 hat ca. 3,8x so viel Bandbreite wie DDR5-SDRAM. Das auszugleichen wird sehr schwer. Da müsste man die Busbreite vervierfachen. Und das erhöht die Produktionskosten beträchtlich. Und die Margen sind bei Konsolen extrem dünn, oft sogar negativ.
LP-DDR6 ist aber nicht DDR5. Letzterer ist bis 17 GT/s spezifiziert. GDDR6 zumindest gibt es bis 20 GT/s. GDDR7 ist natürlich nochmal schneller - aber wer sagt denn dass man das braucht? N48 kommt mit 20GT/s und ist gleich schnell wie die 5070ti die 28GT/s braucht (und die 4080 ist genauso schnell und die hat auch nur GDDR6 mit 20 GT/s).

Und das macht natürlich nur Sinn, wenn es im Endeffekt günstiger ist. Was MLID meinte ist dass GDDR deutlich teurer ist als LPDDR. Im Gegenzug wird das PCB etwas komplexer und der die ein bisschen größer. Aber es scheint sich bandbreitennormiert sich kommerziell zu lohnen ansonsten erklärt es nicht warum AT3 und 4 mit LPDDR kommen sollen und warum Strix Halo heute schon LPDDR nutzt anstatt GDDR.

[iamthebear]

Kepler hat schon häufiger bzgl RDNA5 Sachen geposted, die nicht zu MLID Aussagen passten. Ich hab das nur am Rand mitbekommen, aber fand das ja immer spannend, dass hier MLID als zuverlässiger als Kepler gesehen wird.

MLID lag in der Vergangenheit auch verdammt oft falsch.

Afaik zieht Kepler seine Leaks ausschließlich aus den öffentlich zugänglichen Sources für AMDs Linux Treibern. Insiderquellen hat er soviel ich weiß keine und lag schon mindestens genauso oft falsch wie MLID. Er war sich zu 100% sicher, dass Navi 31 AD102 (den Full Die) in Grund und Boden stampft bzw. behauptet Zen 5 ist 52% schneller in spec int (waren in der Realität glaube ich 15%)

[basix]

Aus dem Anandtech-Forum ein paar Angaben zu den Low-Level Caches von RDNA5 und CDNA5:
https://forums.anandtech.com/threads/rdna-5-udna-cdna-next-speculation.2624468/page-42#post-41498114
https://forums.anandtech.com/threads/rdna-5-udna-cdna-next-speculation.2624468/page-42#post-41498140

L0$ und LDS sollen bei CDNA5 zusammengelegt werden und in der Grösse anwachsen (448kByte anstatt 128kByte LDS und 32kByte L0$). Das dürfte die Datenlokalität stark erhöhen. Wenn man das auf RDNA5 überträgt, sollte das insbesondere auch für Raytracing von Vorteil sein (z.B. BVH Stack-Management geht über den LDS). Zudem wird auch parallele Ausführung von Vektor, RT und Matrix Operationen von dem profitieren. Aber auch generell dürfte man mehr Threads / Waves in-flight halten können. Zusammen mit out-of-order memory accesses und dem vermutlich kommenden out-of-order Thread / Wave processing sollte die Auslastung der Recheneinheiten und somit die "IPC" ein gutes Stück zulegen können.

Vielleicht stutzt man die 448kByte von CDNA5 auf 224kByte bei RDNA5 zusammen. Aber selbst in diesem Fall hat man mehr L0$+LDS als RDNA4 und man kann es flexibler nutzen / sharen.

Hinsichtlich Zusammenlegung der Caches gibt es bei RDNA5 auch Indizien anhand Treibereinträge:
https://forums.anandtech.com/threads/rdna-5-udna-cdna-next-speculation.2624468/page-42#post-41498299

Und von Seiten AMD gibts auch enstprechende Patente dazu:
https://forums.anandtech.com/threads/rdna-5-udna-cdna-next-speculation.2624468/page-42#post-41498359
"As described herein, a unified flexible cache can be a large cache structure that can replace various smaller cache structures, which can simplify design and fabrication and improve yield during manufacturing. In addition, the unified flex cache can be used for various types of caches, such as various levels of processor and/or accelerator caches, and other cache structures for managing a cache hierarchy, such as a probe filter. Because the flex cache can be partitioned into various sized partitions, the cache types are not restricted to a particular size (e.g., limited by the physical structure). Thus, the flex cache can be reconfigured to provide more efficient cache utilization based on system needs."

[basix]

Samsung legt nochmals schnelleren LPDDR5X auf: 12'700 MT/s
https://www.tomshardware.com/pc-components/dram/samsung-extends-lpddr5-to-12-7-gt-s-next-gen-devices-enjoy-a-nice-speed-boost

Damit wäre man nicht mehr weit weg vom langsamsten LPDDR6, was Bandbreite pro Channel anbelangt.
Interessant für AT3 und AT4.

[Exxtreme]

LP-DDR6 ist aber nicht DDR5. Letzterer ist bis 17 GT/s spezifiziert. GDDR6 zumindest gibt es bis 20 GT/s. GDDR7 ist natürlich nochmal schneller - aber wer sagt denn dass man das braucht? N48 kommt mit 20GT/s und ist gleich schnell wie die 5070ti die 28GT/s braucht (und die 4080 ist genauso schnell und die hat auch nur GDDR6 mit 20 GT/s).


Man wird die Bandbreite wohl doch brauchen. Will man die Performance einer RX9070XT dann braucht man knapp 650 GB/s, wahrscheinlich aber eher 800 - 900 GB/s da die CPU auch noch was haben will. Dafür reicht ein 256 Bit Speicherinterface wenn man GDDR7 nimmt. Mit LPDDR6 wird man eher 1024 Bit brauchen für die gleiche Bandbreite. Ist wohl auch deshalb der Grund warum die PS5(Pro) mit GDDR6 läuft.

[basix]

Es wird interessant werden, ob wir in Zukunft mehr LPDDR Designs sehen werden.

GB10 hat ~300 GByte/s bei 31 TFLOPS und 24 MByte L2$.
Eine 5070 hat 672 GByte/s und 48 MByte L2$ bei etwa selber Rechenleistung.

Da bin ich also gespannt auf Benchmarks und Vergleiche.

[robbitop]

Man wird die Bandbreite wohl doch brauchen. Will man die Performance einer RX9070XT dann braucht man knapp 650 GB/s, wahrscheinlich aber eher 800 - 900 GB/s da die CPU auch noch was haben will. Dafür reicht ein 256 Bit Speicherinterface wenn man GDDR7 nimmt. Mit LPDDR6 wird man eher 1024 Bit brauchen für die gleiche Bandbreite. Ist wohl auch deshalb der Grund warum die PS5(Pro) mit GDDR6 läuft.
Also eine 9070XT hat 640 GB/s. Ein moderner Zen mit 6000er DDR5 hat gerade mal 96 GB/s. Da käme man also nur auf 738 GB/s raus. UDNA soll ja auch eher bandbreiteneffizienter werden und in Konsolen gibt es auch eigentlich immer weniger Bandbreite als im PC (und ich denke auch nicht dass ein moderner Zen Prozessor die Bandbreite in Games wirklich ausreizt die er mit DDR5-6000 hat - da ist es eher ein Latenzlimit - würde mich überhaupt nicht wundern, wenn die Hälfte locker ausreicht - sieht man ja bei Intels CPUs wo DDR4 und DDR5 vorhanden ist und letzterer kaum etwas bringt).
Ich denke dass < 738 GB/s reichen wird. Wahrscheinlich sogar ~600 GB/s.

Für die 738 GB/s wären es bei 256 bit also 23 GT/s (das ist fast GDDR6 Terretorium) die notwendig wären. Bei 600 GB/s wären es sogar nur 18 GT/s. Das ist Massen GDDR6 RAM.

Bei 384 bit wären es bei 738 GB/s gerade mal <16 GT/s was im Spektrum von LPDDR6 (und GDDR6) liegt.
Bei 600 GB/s wären es dann gerade mal 12,5 GT/s was dann sogar mit der Einstiegs LPDDR6 Spec möglich ist.

Wie du da auf 1024 bit kommst, ist mir nicht ganz klar. Man braucht eher sowas wie 50% mehr Breite - nicht 4x.

[Exxtreme]

Ich komme deshalb drauf weil ich mal unterstelle, dass man mit neuen Konsolen viel mehr Wumms haben will als beim Vorgänger. ;) Es würde mich schwer wundern wenn es ausgerechnet diesmal anders laufen würde. Und die PS5 kommt schon auf 448 GB/s. Und ich habe als Referenz diese Auflistung genommen:
https://www.heise.de/news/Superschnelles-RAM-PCI-Express-DDR6-LPDDR6-GDDR7-HBM4-und-PCIe-7-0-9760640.html

Aber jetzt fällt mir auf, dass die die Bus-Anbindung wild vermischt haben bei den Zahlen. Denkfehler inc. :crazy:

Ich rechne das nochmal durch.

[robbitop]

Naja die PS5 PRO hat die GPU deutlich größer gemacht und gerade einmal 576 GB/s an RAM Bandbreite hinzugefügt.
Und wenn das mit den 40 RDNA5 CUs stimmen sollte (die pro CU gerade mal 5-10% schneller in Raster sein sollen als RDNA4 CUs) bei gleichzeitiger Steigerung der Bandbreite, sehe ich nicht, wo mehr Bandbreitenbedarf für die GPU herkommen soll.

[basix]

Die RDNA5 CUs sind aber wohl das, was bei RDNA4 eine WGP war. Wir sprechen hier von 10 TFLOPS bei der PS5 gegenüber ~50 TFLOPS FP32 bei der PS6.

192bit GDDR7 mit 32 Gbps ist gut für 768 GByte/s. Dazu noch ein grosser LLC (vermutlich 24 MByte L2$). Die CPU spielt da sicher nicht eine grosse Rolle, macht sie bandbreitentechnisch am PC auch nicht. Ausserdem dürfte der CPU LLC deutlich anwachsen, von 2x 4 MByte auf vermutlich 16 MByte. Die GPU dürfte zudem generell effizienter mit Bandbreite umgehen.

Wenn man in nur ~1080p rendert und auf 4K upscaled, reichen die 24MByte LLC der GPU für 2x oder evtl. sogar etwas mehr an Bandwidth-Amplification. Effektiv 1536 GByte/s vs. 448 GByte/s bei effizienterer Bandbreitennutzung der CUs sieht schon mal etwas anders und ziemlich vernünftig aus ;)

Nimmt man LPDDR6, wären 384bit (Quad-Channel) mit ~12.8...14.4 Gbps wohl auch ausreichend (614....691 GByte/s abzüglich ~10% Encoding-Overhead aufgrund 256/288 Byte Payload).
Ich denke das wäre aber etwas knapp (AT3 mit 24 "New-CU" hat bereits Quad-Channel LPDDR6). Da müsste wohl schon Hexa-Channel her.

[Exxtreme]

Naja die PS5 PRO hat die GPU deutlich größer gemacht und gerade einmal 576 GB/s an RAM Bandbreite hinzugefügt.
Und wenn das mit den 40 RDNA5 CUs stimmen sollte (die pro CU gerade mal 5-10% schneller in Raster sein sollen als RDNA4 CUs) bei gleichzeitiger Steigerung der Bandbreite, sehe ich nicht, wo mehr Bandbreitenbedarf für die GPU herkommen soll.

Das ist korrekt. Leider ist es schwer rauszufinden wieviel mehr Leistung der größere Chip und die etwas höhere Bandbreite bringt. Viele Spiele sind auf 60 fps festgetackert und man hat die höhere Leistung in Bildqualität gesteckt. Nur weiss man auch nicht wieviel mehr Leistung die bessere Bildqualität braucht da die PS5Pro auch noch PSSR kann, was besser als FSR3 ist. Und RT ist auf RDNA3 auch effizienter.

Und ich erwarte da schon mindestens doppelt so viel Bandbreite als bei der PS5. Und da wäre man bei nahe 800 GB/s.

[HOT]

Die RDNA5 CUs sind aber wohl das, was bei RDNA4 eine WGP war. Wir sprechen hier von 10 TFLOPS bei der PS5 gegenüber ~50 TFLOPS FP32 bei der PS6.

192bit GDDR7 mit 32 Gbps ist gut für 768 GByte/s. Dazu noch ein grosser LLC (vermutlich 24 MByte L2$). Die CPU spielt da sicher nicht eine grosse Rolle, macht sie bandbreitentechnisch am PC auch nicht. Ausserdem dürfte der CPU LLC deutlich anwachsen, von 2x 4 MByte auf vermutlich 16 MByte. Die GPU dürfte zudem generell effizienter mit Bandbreite umgehen.

Wenn man in nur ~1080p rendert und auf 4K upscaled, reichen die 24MByte LLC der GPU für 2x oder evtl. sogar etwas mehr an Bandwidth-Amplification. Effektiv 1536 GByte/s vs. 448 GByte/s bei effizienterer Bandbreitennutzung der CUs sieht schon mal etwas anders und ziemlich vernünftig aus ;)

Nimmt man LPDDR6, wären 384bit (Quad-Channel) mit ~12.8...14.4 Gbps wohl auch ausreichend (614....691 GByte/s abzüglich ~10% Encoding-Overhead aufgrund 256/288 Byte Payload).
Ich denke das wäre aber etwas knapp (AT3 mit 24 "New-CU" hat bereits Quad-Channel LPDDR6). Da müsste wohl schon Hexa-Channel her.

https://wccftech.com/amd-next-gen-rdna-5-radeon-gaming-gpus-pack-over-12k-cores-128-cores-per-compute-unit/

[Leonidas]

gfx13 codenames are from Transformers
Alpha Trion, (Ultra) Magnus, Orion (Pax)
https://forums.anandtech.com/threads/rdna4-cdna3-architectures-thread.2602668/page-469#post-41500592

Alpha Trion is for the whole GMD lineup, Magnus is for Xbox and Orion for PS6
https://x.com/Kepler_L2/status/1963275078302302272

[HOT]

Also genau das was MLID vorher geleakt hat.

[OgrEGT]

Aus dem Playstation Thread:
Update von Sony und AMD, ihrer Zusammenarbeit und Architektur-Vision
https://youtu.be/1LCMzw-_dMw?si=FJcyqXCj3oTNbphz

Und die News dazu auf Videocardz:
AMD discusses Next-Gen RDNA tech with Radiance Cores, Neural Arrays and Universal Compression
https://videocardz.com/newz/amd-discusses-next-gen-rdna-tech-with-radiance-cores-neural-arrays-and-universal-compression

[basix]

Das Neural Arrays Thema inkl. Data Sharing innerhalb der Shader Engine erinnert mich sehr stark an das Shared L1 Cache Paper von 2020:
https://okayiran.github.io/docs/pdf/SharedL1-PACT2020.pdf

Da AMD den L0$ & LDS bei RDNA5 zusammenführen und vergrössern soll (448kByte pro WGP / "new CU"), hätte man bei 12x CU stolze 5376 KByte pro Shader Engine, welche man sharen kann.
Wird auch interessant in Richtung generelle ML/AI Performance und auch CDNA5, da dort ein grosser shared Cache sehr gut durchschlägt (siehe das verlinkte Paper).
Specifically, on average, DynEB reduces the L1 miss rate by 79% for these applications, thus improving their performance by up to 3.9× and by 2.3× on average.

Der grosse virtuell shared L1$ könnte auch mit ein Grund sein, wieso man sich den fetten IF$ sparen kann.

[dargo]

Aus dem Playstation Thread:

Habe ich es richtig verstanden, dass die neuen Radiance Cores die CPU bei RT/PT entlasten sollen? Das wäre natürlich sehr begrüßenswert.

[basix]

Ist grundsätzlich das selbe wie HW BVH Traversal bei Nvidia. Was genau dort die CPU entlasten soll, weiss ich noch nicht. Evtl. hängt das mit DGF / DMM und Mega Geometry zusammen?

Interessant ist auch die "Universal Compression". Mir ist völlig unklar, wie man das effizient machen will aber es ist definitiv spannend ;)

[dargo]

Jo... eine Weiterentwicklung von DCC war schon längst überfällig.

[HOT]

Das Neural Arrays Thema inkl. Data Sharing innerhalb der Shader Engine erinnert mich sehr stark an das Shared L1 Cache Paper von 2020:
https://okayiran.github.io/docs/pdf/SharedL1-PACT2020.pdf

Da AMD den L0$ & LDS bei RDNA5 zusammenführen und vergrössern soll (448kByte pro WGP / "new CU"), hätte man bei 12x CU stolze 5376 KByte pro Shader Engine, welche man sharen kann.
Wird auch interessant in Richtung generelle ML/AI Performance und auch CDNA5, da dort ein grosser shared Cache sehr gut durchschlägt (siehe das verlinkte Paper).


Der grosse virtuell shared L1$ könnte auch mit ein Grund sein, wieso man sich den fetten IF$ sparen kann.

Ich glaube eher, dass Universal Compression die kleineren (und schnelleren) Caches ermöglicht. Es gab ja 3 wichtige Features bei dieser Präsentation:
https://www.youtube.com/watch?v=ItXPvGrI6gY
zwischen Cherny und Huynh
1.) Neural Rendering (Redstone und Weiteres) incl. Ray Reconstruction (AMD nennt das Regeneration)
2.) RT mit echter Ray Traversal Hardware
3.) Universal Compression aller Daten überall in der Pipeline von CPU bis Displayengine.

[robbitop]

Das Neural Arrays Thema inkl. Data Sharing innerhalb der Shader Engine erinnert mich sehr stark an das Shared L1 Cache Paper von 2020:
https://okayiran.github.io/docs/pdf/SharedL1-PACT2020.pdf

Also geht AMD doch den Weg für FF Hardware für RT. BVH Traversal Hardware wurde ja bereits seit 2018 bei Turing verbaut - aber RDNA4 hat erstaunlicherweise gezeigt, dass man auch ohne FF HW ziemlich fix sein kann. Aber anscheinend ist es mit FF dann auf einer anderen Stufe.

[reaperrr]

Der grosse virtuell shared L1$ könnte auch mit ein Grund sein, wieso man sich den fetten IF$ sparen kann.
Neben dem größeren L2 und der durch GDDR7 viel höheren VRAM-Bandbreite je Bit, ja.

Habe ich es richtig verstanden, dass die neuen Radiance Cores die CPU bei RT/PT entlasten sollen? Das wäre natürlich sehr begrüßenswert.

Was genau dort die CPU entlasten soll, weiss ich noch nicht.

So wie ich es verstehe, werden durch Hardware-BVT etc. die regulären Shader entlastet, in der Umsetzung könnte das auch weniger Treiberlast und damit weniger CPU-Overhead bedeuten.

Interessant ist auch die "Universal Compression". Mir ist völlig unklar, wie man das effizient machen will aber es ist definitiv spannend ;)
Jo... eine Weiterentwicklung von DCC war schon längst überfällig.

Ähnliches (also Kompression durch die ganze Pipeline hindurch) wurde aber auch schon für RDNA4 genannt, und ist wohl auch einer der Gründe warum RDNA4 überhaupt trotz relativ schmaler GDDR6-SIs konkurrenzfähig ist.

Natürlich wird das in RDNA5 noch weiter verbessert worden sein, aber in dieser Präsentation ging es ja um die PS6 im Vergleich zum Vorgänger, und selbst die PS5Pro war ja nur RDNA3.5 + RDNA4-RT, also zumindest ein Teil dieses spezifischen Punktes (Kompression) ist im Desktop mit RDNA4 de facto schon da.

[basix]

Bei RDNA4 ist L1/L2/L3 Cache inkl. Kompression. Bei L0/LDS sowie VRAM ist dem nicht so. Edit: RDNA4 hält Daten auch komprimiert im VRAM, evtl. aber nicht so stark komprimiert wie RDNA5

So wie ich Universal Compression verstanden habe, soll auch mindestens der VRAM (stärker) komprimierte Daten halten. Beim L0/LDS vermutlich aus Performance-Gründen nur teilweise (DGF und Texturen dürften komprimiert im L0/LDS landen).

Weitere Kompressions-Komponenten:

DGF (+DMM Augmentation). Ohne DMM ist die Kompression ähnlich wie bei Nanite. Ich weiss nicht genau, wo Nanite dekomprimiert (vermutlich in einem Compute Shader). DGF kann allerdings garantiert komprimiert im VRAM landen und bekommt einen HW Accelerator in der CU. Wenn man DGF mit DMM ergänzt (gibt einige Papers und Patente von AMD zu dem Thema), könnte der Kompressionsfaktor nochmals 2...3x zunehmen. Das hätte massive Auswirkungen auf Speichermengen (Festplatte wie auch VRAM). Neben geringerer Speichergrösse wird auch Ray Tracing massiv beschleunigt und man spart sich enorm viel Speicherbandbreite.
NTBC (Neural Texture Block Compression). Gibt ein AMD Paper (https://gpuopen.com/download/2024_NeuralTextureBCCompression.pdf) zu dem Thema. Oder auch ein Paper von Ubisoft: https://hal.science/hal-04255874v2/file/neural-textures.pdf. Beides benutzt bestehende BC-Acceleration, keine neue HW benötigt. Oder man geht noch weiter, den Nvidia NTC oder Intel Cooperative Vectors Weg (z.B. https://arxiv.org/pdf/2506.06040). Auch hier spart man enorm Speichermenge und -bandbreite

Das Ding "Universal Compression" zu nennen ist mMn ein wenig unsinnig. Ich vermute, dass man für die verschiedenen Datentypen separate Accelerators benötigt. Vielleicht kann man aber noch einen generellen LZ4 Compressor/Decompressor (https://arxiv.org/pdf/2409.12433) einbauen, für alles was nicht bereits separat abgedeckt ist (DGF, Texturen, ...). Unter dem Strich könnte verglichen mit heute allerdings eine durchschnittliche Kompression von 2...3x resultieren (DGF, Texturen, sonstiges). Das wäre extrem gut und würde sehr viele Ressourcen sparen (VRAM sowie Cache Menge/Bandbreite). Das coole daran: Alles mit Texturen und Geometrie würde auch auf älterer HW laufen. Einfach etwas langsamer aufgrund fehlender HW Acceleration (im Falle von Neural Textures wäre zumindest Lovelace+ und RDNA4 bereits gut dabei). Neural Textures skalieren aber sehr gut nach unten, das heisst ältere HW müsste einfach die Texturqualität/-auflösung etwas runterschrauben (immer noch bessere Qualität als heute mit Block Compression!), damit die Performance nicht zu stark leidet. Dafür spart man massig VRAM-Menge, was insbesondere bei älteren Karten wichtig wäre. Da trifft sich reduzierte Texturauflösung ja eh richtig.

Hier noch ein sehr detaillierter Post zum Thema RT bei RDNA5:
https://forums.anandtech.com/threads/rdna-5-udna-cdna-next-speculation.2624468/page-65#post-41521314

[BavarianRealist]

Ist eine Kompression der Daten im VRam aktuell nicht sehr interessant bei den kommenden sehr hohen Dram/VRam-Preisen? Da könnte es sich schnell lohnen, etwas mehr Silizium in die GPU für die Kompression auf zu nehmen, um dann mit der Hälft an Ram auszukommen?

[robbitop]

Und darüber hinaus erlaubt es ggf noch bessere Assets (VRAM normiert) was potentiell langfristig Spiele schicker machen könnte. Insbesondere wenn es in die Konsolen kommt - dann wird das sicherlich auch genutzt.

[HOT]

Soweit ich das verstanden habe geht es nicht darum VRAM zu sparen, sondern den Datentransfer innerhalb der GPU weitestgehend zu verringern. VRAM kann man nur mit einer vernünftigen Texturkompression sparen.

[basix]

Ist eine Kompression der Daten im VRam aktuell nicht sehr interessant bei den kommenden sehr hohen Dram/VRam-Preisen? Da könnte es sich schnell lohnen, etwas mehr Silizium in die GPU für die Kompression auf zu nehmen, um dann mit der Hälft an Ram auszukommen?

Ein Grossteil der Daten ist bereits heute komprimiert im VRAM (Texturen, Geometrie). Diese zwei werden mit neuen Techniken aber anscheinend nochmals stark geboosted (=stärkere Kompression).

Was jetzt noch fehlt sind die anderen Daten. Da die ziemlich unterschiedlich sein werden, müsste man dort eine 0815 / allgemeine Kompression verwenden. LZ4 würde sich hier anbieten.

Ich habe nochmals die RDNA4 Hotchips Präsentation angeschaut. RDNA4 macht einige Dinge bereits. Je nach Daten dekomprimiert man einfach den Header wenn man aus dem VRAM lädt und nicht alle Daten (Daten sind komprimiert im VRAM, IF$, L2$, L1$). Was genau dort gemacht wird und wie stark komprimiert wird, weiss ich nicht. Aber vielleicht macht RDNA5 das nicht viel anders als RDNA4, die Präsentation mit Cerny zeigt evtl. mehr die Unterschiede zur PS5 auf. Ich nehme aber an, dass RDNA5 das noch etwas ausbaut.

Und darüber hinaus erlaubt es ggf noch bessere Assets (VRAM normiert) was potentiell langfristig Spiele schicker machen könnte. Insbesondere wenn es in die Konsolen kommt - dann wird das sicherlich auch genutzt.
NTC von Nvidia hat mich beeindruckt. Das skaliert extrem weit runter und die Texturqualität ist immer noch ansprechend. Bei Block Compression ist es dann bereits Matsch. Das dürfte die "Low Quality" Settings von Texturen massiv verbessern, deutlich stärker als am oberen Ende des Qualitätsspektrums.

Am oberen Ende dürfte DGF, DMM und MegaGeometry mehr bewirken. Die verbessern die Detailausleuchtung von detaillierter Geometrie. Bei genug VRAM und High-Res Texturen war die Qualität bereits heute ziemlich gut. Aber bekommt man in den selben oder noch weniger Platz noch bessere Texturen, nehmen wir das auch gerne ;)

[Dampf]

Also geht AMD doch den Weg für FF Hardware für RT. BVH Traversal Hardware wurde ja bereits seit 2018 bei Turing verbaut - aber RDNA4 hat erstaunlicherweise gezeigt, dass man auch ohne FF HW ziemlich fix sein kann. Aber anscheinend ist es mit FF dann auf einer anderen Stufe.

Das stimmt wohl, RDNA4 ist ziemlich gut in RT. Wenn sie es schon ohne Hardware BVH Traversal so gut hinbekommen haben, frage ich mich wie dann RDNA5 mit BVH Traversal aussieht. Wird bestimmt Blackwell schlagen. Und wenn sich Nvidia nicht anstrengt könnte es sogar besser als Rubin werden.

[basix]

Ich glaube nicht, dass sich Nvidia nicht anstrengen wird. Bis jetzt haben sie bei jeder Generation grössere Verbesserung und auch neue Features gebracht ;)

[HOT]

Na ja in den letzten beiden Iterationen gab es evolutionäre Fortschritte, aber so gigantisch waren die jetzt nicht. Mal sehen, wie es in der nächsten Generation aussieht. Vielleicht braucht man mal ne neue Basis.

[basix]

Hä?
- Lovelace brachte DMM, OMM und SER und verdoppeltes Ray-Triangle Intersection Testing pro RT-Core
- Blackwell brachte Linear Swept Spheres sowie die Triangle Cluster Compression Engine / Triangle Cluster Intersection Engine für MegaGeometry und obendrauf verdoppelten Durchsatz für Ray-Triangle Intersection Testing pro RT-Core

OMM und SER kommen nun in DXR 1.2 rein. MegaGeometry (als Vorlage) wird vermutlich ebenfalls Teil eines zukünftigen RT-API Standards. Ich weiss nicht, was du von HW-Iterationen erwartest, aber aus meiner Sicht sind das ziemlich nützliche und durchschlagende Features. Und daneben noch den Intersection Testing Durchsatz pro RT-Core mit jeder neuen Generation verdoppelt.

[HOT]

Jo mal sehen.

[robbitop]

Hä?
- Lovelace brachte DMM, OMM und SER und verdoppeltes Ray-Triangle Intersection Testing pro RT-Core
- Blackwell brachte Linear Swept Spheres sowie die Triangle Cluster Compression Engine / Triangle Cluster Intersection Engine für MegaGeometry und obendrauf verdoppelten Durchsatz für Ray-Triangle Intersection Testing pro RT-Core

OMM und SER kommen nun in DXR 1.2 rein. MegaGeometry (als Vorlage) wird vermutlich ebenfalls Teil eines zukünftigen RT-API Standards. Ich weiss nicht, was du von HW-Iterationen erwartest, aber aus meiner Sicht sind das ziemlich nützliche und durchschlagende Features. Und daneben noch den Intersection Testing Durchsatz pro RT-Core mit jeder neuen Generation verdoppelt.
Bezogen auf im rasterizen gleich starke GPUs bzw auf den fps drop RT/PT vs Rasterizing:
Naja zumindest Blackwell scheint nicht schneller in RT zu sein als Ada. Zumindest zeigten die Benchmarks von RT/PT zum Launch da keine Verbesserungen.
Ada hingegen ist schon etwas schneller bei diesen Workloads als Ampere. Aber auch nicht so dramatisch wie man annehmen könnte. Und auch nur dort wo explizit SER und co eingebaut sind. Abseits dessen war der boost kleiner.

[basix]

Es geht ja nicht nur um rohe Leistung. Sondern auch um neue Features und Konzepte. Und da scheint Nvidia definitiv nicht zu schlafen. Das selbe sieht man auf der SW Seite. MegaGeometry ist nur ein Teil davon. Da gibt es RTXDI (ReSTIR), welches sich laufend weiterentwickelt (z.B. Area ReSTIR) oder Neural Radiance Caching, verbessertes Ray Reconstruction mit DLSS4 usw.

Die insgesamten Gewinne aller dieser Features ist vermutlich deutlich höher als das was eine HW Generation mit reiner Rohleistungs-Skalierung bringen könnte.
Momentan schlagen die einfach noch nicht durch, da die meisten neuen Features noch nicht in Spielen verwendet werden.

[robbitop]

Was mich bei sowas dann besorgt ist, wenn es proprietär umgesetzt wird. IMO sollte sowas wie in guten alten Zeit im Vulkan/DirectX Gremium beschlossen werden und standardisiert werden. Dann kann das über die Schnittstelle jeder einsetzen.
Klar trickelt jetzt einiges was mal proprietär war auch down in die DX/VLK API aber man hatte dann einige Jahre lang quasi Exklusivität. Nicht gut für den Endkunden.

Ansonsten finde ich HW auch sehr nett, die transparent zur Anwendung mehr Leistung schafft ohne vendorspezifische Optimierungen. AMDs neue Renderpipeline scheint ja zumindest in Teilen in diese Richtung zu gehen.

Auch wäre es sehr geil wenn AMD (und Nvidia) sich bei Intel eine Scheibe abschneiden würden in Bezug auf shader compilation delivery. Geil dass das endlich jemand (anscheinend über den Treiber/GPU Software) transparent zur Anwendung macht. Man kennt es ja schon vom Steam Deck. Das wäre seitens AMD jedenfalls ein nettes Feature was man zu RDNA5 launchen könnte.

[basix]

Standardisierungen sind gut. Aber selten bis fast nie kommt der erste Schritt von dieser Seite. Der kommt typischerweise zuerst von den HW-Vendors, die viel Geld in die Entwicklung neuer Features stecken.