AMD RDNA 4 - 144CU, 48GB VRAM, 3nm + 4nm

[E555user]

MLID hat eigene Infos zu den RDNA4 Entwicklungen recherchiert...

RNDA4 ist wie RDNA1 oder Polaris - Tweet von Leaker Kepler bestätigt
RDNA1 mit Wechsel auf RDNA2 hätte gut funktioniert, evtl. mit RDNA4 auf RDNA5 wiederholen
RDNA4 ist kein grosser Leistungssprung wie ursprünglich geplant, Fokus aber auf Raytracing, Geometrie und Effizienz (also nicht Pixelrate >4k, peak FPS)
N41 hat Probleme die bei RDNA5 nicht auftreten, Ressourcen zugunsten RDNA5 verschoben.
N41 wird weiterentwickelt und könnte dennoch kommen sofern RDNA5 problematisch wird aber N41 gefixt werden kann
RDNA4 Lauch Window Q3-2024

Er spekuliert, dass mit einem schneller entwickeltem RDNA5 High End AMD in der übernächsten Gen vor den Start der Nvidia Generationen kommen könnte, RDNA3.5 Strix Point für Q2-2024, aber Strix Halo auch nur Q3-2024, ebenso wie PS5pro.
FSR3 Launch Date wird spätestens in Q4-2023 sein, eventuell "schon" mit dem Start der N32 GPUs.

 

[E555user]

MLID legt im aktuellen "Loose Ends" nach mit der Information dass N41 im Design gut ist, aber die Chiplet-Implementierung in der Fertigung Schwierigkeiten macht. Sobald das gelöst ist, ist es auch für Nachfolgegerenrationen gelöst....

Also war mehr als nur ein Upgrade der single GCD geplant, ich vermute mGCDs.

 

[pipin]

FSR3 Launch Date wird spätestens in Q4-2023 sein, eventuell "schon" mit dem Start der N32 GPUs.

Das ist etwas ernüchternd. Weil faktisch kommt FSR3 dann ein Jahr nach Einführung der Hardware.
AMD hat zwar nie von was anderem gesprochen als 2023, aber wenn das noch nach N32 kommen sollte.

Irgendwie ist zu vermuten, dass AMD alle Resourcen in Richtung ROCm bzw AI geschoben hat.
AMD HYPR-RX ist ja mittlerweile auch 2 Monate verspätet und mein genereller Eindruck vom aktuellen Zustand der Entwicklung beim Radeon Treiber ist kein guter.

 

[E555user]

Irgendwie ist zu vermuten, dass AMD alle Resourcen in Richtung ROCm bzw AI geschoben hat.
AMD HYPR-RX ist ja mittlerweile auch 2 Monate verspätet und mein genereller Eindruck vom aktuellen Zustand der Entwicklung beim Radeon Treiber ist kein guter.

Ich nehme an es ist ein Mix aus vielen Faktoren.

Zum einen hat RDNA3 Probleme in SW kompensieren müssen und war dennoch nicht performant wie geplant. Dann müssen die Überzeiten von dem Post-Launch abgebaut werden.
Der massive Personalzuwachs muss angelernt bzw. integriert werden, Tems werden neu zusammengesetzt, nicht jeder langjährige Mitarbeiter taugt zum Teamleader, etc. und Ergebnisse brauchen erst einmal eine Rückkopplung zur Koordination und Ausrichtung.

Und dann ist der strategische Fokus - wie Du schreibst - ganz bestimmt in AI mit dem Start der MI300 Serie. Dieser Hype-Zyklus muss auf der Welle mitgeschwommen werden soll er nicht an AMD vorbei gehen. Dann ist es ganz verständlich wenn im Zweifel einzelne Experten umdispositioniert werden um ein komplettes Softwareökosystem mit der Hardware anbieten zu können. Wäre mir persönlich auch lieber AMD schafft es hier eine echte Alternative zu Nvidia aufzubauen. Intel ist da für den Moment wieder aussen vor. Die Schwierigkeit bei AMD war aber schon immer Software als Afterthought mitzuliefern und nicht mit dem Produktlaunch marktreif aktualisiert zu haben.

Im Gaming erwarte ich dabei keine grossen Technologiesprünge für die nächsten 24 Monate, hier ist doch eher eine Konsolidierungsphase in der die Must-Haves gesichert werden. Dennoch muss auch dort der PS5-Pro Start begleitet werden. Im Raytracing werden noch Alternativen ausprobiert und Microsoft könnte eine neue DXR Version nachlegen.
Bei AMD wird FSR3 voraussichtlich weiterhin kein DeepLearning einsetzen. Aber eigentlich ist das Upscaling-Thema durch. Die Leistung der künftig zu vermarktenden GPUs übertrifft die Anforderungen in der Regel. Da wird es dann eine "besser als nativ" BS-Diskussion geben.
Enttäuscht bin ich, dass trotz der Anstrengungen von Microsoft und Sony auf den Konsolen das Thema Audio nicht mehr Bedeutung bekommen hat. Der Mainstream ist ignorant was das anbelangt. Ich hätte mich hingegen über ein Revival von TrueAudio auf den kleinen iGPUs für korrekte räumliche Vertonung gefreut.

 

[E555user]

MLID hat im Video nachgelegt mit einer Grafik des abgekündigten Navi4C, das extrem komplex aufgebaut ist/war. (gefunden via Videocardz)

AMD's canceled Radeon RX 8000 "Navi 4C" GPU diagram has been partially leaked - VideoCardz.com

AMD Navi 4C: The GPU that will never be? This would have been the AMD flagship RX 8000 GPU if not for the fact that it was canceled, allegedly. Alleged AMD Navi 4C, Source: Moore’s Law is Dead Moore’s Law is Dead recently shared a diagram of AMD’s unreleased RX 8000 GPU, codenamed Navi 4C. In […]

videocardz.com

 

[Complicated]

Ich bin etwas überrascht über 3 AIDs, eigentlich dachte ich ein AID kann die Compute-Dies vollständig anbinden. So sind schon die Chiplets mit einem AID ausgestattet, die dann auf dem Substrat auch noch angebunden sind. Möglicherweise hat das nicht so geklappt wie man es sich vorgestellt hat.
Macht aber Sinn das AID-Packaging auf Chiplet-Ebene durchzuführen, wegen den Kosten/Yield.

 

[E555user]

Ich bin da wegen dem Layout mit den kleinen Shader Engines auch überrascht gewesen. Nach der Grafik wäre das je SE mit 8 DCUs bzw. 16 CUs ein Chiplet. Das ist sehr klein, je nach Umfang des L1 und Ausbau von RT und AI.
Ich nehme an die Leaker der maximalen 144 CU Variante hatten das Bild gekannt und die aktuellen RDNA3 SE als 16er CUs x3 Chiplets x3 AIDs multipliziert.
Diese ChipsOnWafer-Lateral Brücken empfinde ich als schwierig, wohl wären diese für niedriege Latenzen im L1 Abgleich notwendig. Das Bild zeigt nicht wo L2 und Scheduler bzw. ACE Einheiten wären.

Meine Erwartung war ursprünglich AMD lagert nur die Einheiten aus, die nach und am L2 gebunden sind (L2, Geometrie, G-Command, HWS, DMA) um alles was am L1 ist in GCD Monolithen zu belassen (CUs, RB, L1 mit Kohärenz, Global Data Share Konstanten). Das Ganze in z.B. 40, 80, 120 CU Varianten aufgelegt wäre ein Design gewesen, das nur in der Menge der SE sich unterschieden hätte. Auch hätte ich erwartet, dass man je SE eben wieder auf 10 DCUs bzw. 20 CUs hoch geht, wie diese in RDNA2 zu sehen waren. Einfach weil wie Eingangs erwähnt ein Chiplet mit nur 32 oder gar 16 CUs aus der Grafik in 3nm doch viel zu klein wäre, kaum mehr Vorteile im Yield brächte. Ein 16 CU Chiplet allein würde man doch nicht haben wollen, zu teuer mit dem Drumherum für die gebotene Leistung.

 

[vinacis_vivids]

Auf dem N4C sieht man eine 3 X SE Konfiguration von einer Seite.
Auf jedem SE sitzen 16CU, also in einer Reihe maximal 48 CUs
Drei dieser 3 X SE Reihe ergeben 3 X 3 X SE = 9 SE X 16CU = 144 CU.

Ich könnte mir vorstellen, dass die Umstellung des Command Prozessors, Geometry Prozessor, HWS, DMA usw. doch größere Probleme verursacht die 144 CU auch mit genügend Tasks auszulasten. Bei fp32-compute WMMA fallen dann doch größere Datenmengen an, die dann auch einen größeren (teureren) Cache brauchen. Zumal AMD bei der BVH-Beschleunigung (Baumstruktur) nun andere Wege gehen will als wie bei RDNA2.

Möglicherweise kommt auch die Order von oben (Lisa), erstmal die Entwicklung /Ressourcen beim teuren fp32 zurückzustellen und mehr auf bf16/ fp16, int8 und int4 AI-Cores (WMMA) umzustellen. auch für die Gaming-Sparte (und nicht nur HPC).

 

[WindHund]

@

vinacis_vivids​

Ficken, hat nicht Zwangsläufig was mit, Sex zu tun...

Trillionen sind über Milliarden...

 

[Hammerhead Shark]

MLID mit weiteren Leaks/Infos zu RDNA4 inkl. Performanceeinschätzung zu Navi 43:

 

[E555user]

MLID mit weiteren Leaks/Infos zu RDNA4 inkl. Performanceeinschätzung zu Navi 43:

Er schätzt die Möglichkeiten ein, alles sehr vage…
Die theoretische FLOP Leistung einer CU pro Takt ist letztlich sehr konstant seit GCN. Die Auslastung durch den Gamecode und Treiber durch verbessertes Design zu unterstützen geht vor allem über Cache und reduzierte Latenzen bei Shadercode. Nur bei RT erwarte ich noch Sprünge durch neue ISA Features. Bei UE5 fehlen noch genügend Messdaten um die nächsten Gens einschätzen zu können. Ich vermute der Gap zwischen Konsole und dGPU ging relativ zur theor. GPU Leistung erst mal wieder zurück.

Dass AMD mit RDNA4 hauptsächlich auf Laptop schielt und dGPU erst mit RDNA5 wieder in den Fokus nimmt wäre durchaus ein Erklärungsansatz. Etwas für mehr Marktanteile dort und im Mainstream PC Gaming die Anteile halten.

 

[vinacis_vivids]

N41 = 64WGP / 128CU - 8192SP (N41?)
Vermutlich die 4 X GCD Version mit jeweils 2048SP pro GCD.
-> gecancelt wegen fehlender 3nm Kapazität?

N42 = 48WGP / 96CU - 6144SP (N31XTX, N42?)
Vermutlich die 3 X GCD Version mit jeweils 2048SP pro GCD.
-> gecancelt wegen fehlender 3nm Kapazität ?

N43 = 32WGP / 64CU - 4096SP (Vega10, Fiji10 Struktur)
Fertigung: TSMC 4nm ?

N44 = 16WGP / 32CU - 2048SP (Antigua full, Polaris10 Salvage, Navi23 full, Navi33 full)
Fertigung: TSMC 4nm ?

Für die Masse reicht wohl ein Chip 100-200mm²

Die neuesten Gerüchte gehen von 180 WGP aus! Also 45WGP / 90CU pro GCD und Taktraten von 4,0Ghz für den Maximalausbau 8900XTX.

180 WGP = 360CU = 8900XTX ?
48 WGP = 96CU = 7900XTX

Erhöhung von +275% bei den CUs und bei einem Takt von 4,0Ghz käme man auf surrealistische Rechenleistung von:

256 Flop 32 pro Clk / 4,0Ghz Clk / 360CU ~ 368,640 Tflops fp32 dual-issue

Vergleich 7900XTX
256 Flop 32 pro Clk / 2,7Ghz Clk / 96CU ~ 66,355 Tflops fp32 dual-issue

An roher Erhöhung der Rechenleistung wären es +443,5% für den RDNA5 ? Top-Dog 180WGP ggü. N31XTX.

 

[WindHund]

@vinacis_vivids

fp8 sind dann wie viel Terra Flops ?

 

[derDruide]

Erste Code-Patches für Navi 4 tauchen im LLVM-Compiler auf, mutmaßlich für Navi 44 und 48.

AMD discrete RDNA4 "GFX1200/GFX1201" GPUs spotted in LLVM patches - VideoCardz.com

AMD RDNA4 in LLVM project The next-generation gaming graphics architecture known as GFX12 or RDNA4 is being prepared by AMD. It appears that AMD has now decided which GPUs from the RDNA4 series will be the first to deploy. The GFX1200 and GFX1201 are two unnamed graphics processors which have...

videocardz.com

Man könnte daraus einen groben Zeitplan ableiten, denn der Ablauf wird ja immer ähnlich sein.

 

[E555user]

ich dachte das Zeitfenster steht schon fest mit Q3/2024.

Ich hoffe die Leaks sind falsch, der IF Cache sollte mit 192MB deutlich grösser werden um die Rendertargets in 4k aufzunehmen. Das würde viel weniger Optimierung im Shadercode bzw Treiberpatches für Spiele nötig machen.

 

[WindHund]

Server, Destruktion Derby, we DDos the Single...

 

[vinacis_vivids]

Zusammengefasst:
RDNA4 N48
32WGP = 64CU
48MB IF$
192bit SI
PCIe 5.0 X16

4096SP ~ also Vega64 und Fiji10 Struktur.
192bit SI ~ Das SI einer 7700XT
48MB IF$ ~ Das IF$ einer 7700XT

Taktraten geschätzt: ~3,0Ghz
Rechenleistung geschätzt N48: 3,0 X 4096 X 4 ~ 49,1 Tflops fp32 dual-issue

N48 könnte die 7900XT ersetzen, welche mit ~51,48 Tflops fp32 dual-issue in etwa die gleiche Rechenleistung hat. Durch PCIe 5.0, uArch Optimierung wegen RT und die Beschleunigung des IF$ könnte N48 leicht schneller sein als die 7900XT. Wird vermutlich als "Mid-Range" GPU im günstigen 4nm (5nm Derivat) gefertigt um die teure N31XT zu ersetzen.

Preislich macht die 7900XT sich gerade bei ~800€ , mit günstiger könnte AMD dann die 499-599 USD anpeilen für die neue 12GB Grafikkarte.

 

[E555user]

Ich denke man hat schon an der 7800XT vs. 6950XT gesehen wie AMD das angeht. In hohen Auflösungen kommt der kleinere IF Cache dann zu kurz bis nachoptimiert wurde wo möglich.

 

[BavarianRealist]

Mal ein paar Gedanken zu RDNA4, da selbst die Gerüchte bisher recht rar sind:
Meines Erachtens konzentriert sich AMD bei RDNA4 (wie auch bei RDNA3.5) auf Effizienz (Lowpower für Notebook) und günstige Herstellung, d.h möglichst kleine Dice. Beides ist für die kommenden APUs als auch neue Konsolen SoCs wichtig, insbesondere für die kleinen Handheld-Konsolen, die nun fast alle auf AMDs Phoenix basieren.

Dennoch dürfte Navi4x unterschätzt werden, insbesondere beim zu erwartenden Takt: bisher takteten die GPUs in den APUs niedriger als in den diskreten GPUs: so taktet RDNA2 z.B. in RX6650XT (Navi23) mit 2635Mhz deutlich höher als der maximale Takt in Rembrandt mit 2400Mhz. Vergleicht man nun RDNA3 so taktet Navi33 in RX7600 mit 2655Mhz auch nur unwesentlich höher als Navi23. Die APU-GPUs takten aber mit bis zu 2800Mhz (es waren angeblich sogar 3Ghz angeplant), also höher als die diskreten GPUs. Vermutlich ist der Taktsprung vor allem dem effizienteren 4nm-Prozess zu verdanken.

Die in 5nm hergestellten Navi31 und 32 schaffen gar nur max. 2500 bzw 2430Mhz, also gut 15% weniger als die Ausführung in den APUs. Wenn die bisherigen Navi3x-CUs in den APUs bereits bis zu 2800Mhz in 4nm schaffen, sollten nach etwas Optimierung (RDNA3.5 oder RDNA4) deutlich höhere Takte in den diskreten Navi4x möglich werden, die ja dann auch 4nm nutzen und nochmals etwas Optimierung erleben sollten.

 

[E555user]

Das ist richtig. Eigentlich war mit dem TSMC Sprung von n7 auf n5 mit 15% mehr Takt gerechnet worden. Das wäre von Boost der 6950XT für N31 2.65 GHz gewesen, dazu noch Designverbesserungen und kleinerer Die. Es hat bei der XTX nur für 2.5 GHz Boost gereicht. Auch in der Game Frequency ist man 100Hz zu kurz gekommen, nur die ausgesuchten Dies in wenigen OC Karten kommen da ran. OC soll auf dem Monolithen N32 teilweise sehr gut funktionieren. Vermutlich musste AMD den Takt für die Positionierung eher klein halten.

Für n3 sollen es nochmals 15% mehr Takt werden können, je nach Design. Für Monolithen bin ich da eher zuversichtlich, dass man wieder die Ziele schafft. Für MCM wären Schwierigkeiten eher erwartbar, der IF braucht auch Energie und macht Abwärme.

 

[vinacis_vivids]

N31XTX schafft auch 2,8-2,9Ghz Shader und 3,1-3,2Ghz Front-End Takt. Allerdings mit hohen Energiekosten von ~420-464W.
AMD könnte einen kostengünstigen Refresh vor RDNA4 einschieben gegen due Super Serie von Huang. Diese müsste auf Energieverbrauch optimiert werden:

2,8-2,9Ghz Shader-Takt
3,1-3,2Ghz Command Prozessor
192MB IF$ 3D-Stacked

Energieoptimiert auf N4P, also -22% Verbrauch bei gleicher Leistung.
420-464W * 0,8 ~ 335-375W
Dichte steigt auf 1.06X für das GCD. 304,35mm² / 1.06X ~ 287,2mm² N31XTX GCD N4P

Mit der Vergrößerung des IF$ und einer guten Takterhöhung könnte AMD im Raster nach der Krone greifen, für vergleichsweise günstig.
Mit einem Power Budged von max. 525W hätte der N31XTX N4P shrink noch Energiereserven für Mehrtakt. Dafür müsste AMD die hungrigen shader noch optimieren. ~3,0Ghz Shader und 3,3Ghz Front-End Takt bei gleichem Energieverbrauch von ~355W MBA wäre extrem geil. Das schafft raum für größere Custom-Modelle.

Beim Speicher könnte AMD auf 48GB gehen für Enthusiasten und KI-Experimente.
[automerge]1703183401[/automerge]

Ich denke man hat schon an der 7800XT vs. 6950XT gesehen wie AMD das angeht. In hohen Auflösungen kommt der kleinere IF Cache dann zu kurz bis nachoptimiert wurde wo möglich.

Die Custom 7800XT ersetzt leistungsmäßig die 6900XT / 6950XT. Also N32XT für N21XTX. 200mm² 5nm für 521mm² 7nm. Der Flächencut ist extrem hoch, dazu die Einsparungen im PCB und höhere Ausbeute. AMD kann nicht klagen denke ich derzeit.

 

[sompe]

Ich habe starke Zweifel das es einen solchen Refresh geben wird denn bislang gab es sowas nur mit leicht optimierten Fertigungsprozessen, der Leistungszuwachs war eher gering und ging eher mit einer schlechteren Effizienz einher.
Das dürfte vor allem daran liegen das so große Shrink sehr arbeits- und kostenintensiv sein dürften weil das Chipdesign erstmal an die Gegebenheiten des neuen Fertigungsprozesses angepasst werden und die Produktion des neuen Chips erstmal eingefahren werden müßte. Sowas ist nichts für mal eben zwischendurch sondern müßte eher von langer Hand geplant sein. Sowas wäre nur sinnvoll wenn frühzeitig größere Verzögerungen bei der Nachfolgegeneration absehbar gewesen wären.

 

[E555user]

Die Custom 7800XT ersetzt leistungsmäßig die 6900XT / 6950XT. Also N32XT für N21XTX. 200mm² 5nm für 521mm² 7nm. Der Flächencut ist extrem hoch, dazu die Einsparungen im PCB und höhere Ausbeute. AMD kann nicht klagen denke ich derzeit.

Leistungsmässig bleibt die 7800XT in 4k+ bei Min-FPS manchesmal gegenüber den 69x0XT zurück, besonders wenn der Treiber noch nicht optimiert war. Da könnte AMD mit mehr IF-Cache einfach allen das Leben leichter machen und von Anfang an besser abschneiden, mehr Luft bei hoher Auflösung und VR haben. Sie entscheiden sich zu oft für das in Hardware technisch sinnvolle, so gut wie nie für brute force. Bei RT ist das momentan leider ähnlich. Bei Tesselation war es auch ein ewiges Hinterherhängen. Mehr IF-Cache wäre weniger Marge, gerade bei Launch, aber es würde die RDNAs viel besser dastehen lassen.

 

[sompe]

Wobei ich mit dem Thema Tesselation eher vorsichtig wäre.
Damals wurde fleißig Rechenleistung mit überzogenen Tesselationsstufen verbrannt um den Abstand künstlich zu erhöhen. Werden dadurch die Dreiecke kleiner als die Pixel ist es für die Optik schlicht wertlos und kostet nur noch Rechenleistung.

 

[BavarianRealist]

AMDs Ansatz für RDNA4 dürfte aus folgenden Gründen klar in Richtung LowPower und HighDensitiy gehen:
- dies sind die Anforderungen für APUs, die immer wichtiger werden dürften, nicht nur im Notebook, sondern auch im "Desktop" (in Anführungszeichen, weil der echte Desktop mehr und mehr nur noch von Gamern und Enthusiaten genutzt wird, alles andere wird immer kompakter), wo mehr und mehr APUs mit iGPU ausreichen
- AMD dies für künftige Konsolen (Sony, MS) braucht und vor allem auch für die immer häufiger werdenden Handheld-Konsulen, einen Markt den AMD gerade heimlich zu erobern scheint
- LowPower der Schlüssel ist, mit den GPUs auch den gewaltigen MobilePhone-Markt eines Tages erobern zu können: hier könnte die Kooperation mit Samsung der Einstieg werden

UND für die Zukunft, die AMD mit seinen MI300 aufgezeigt hat:
Zukünftige Produkte von AMD, deren Grundaufbau dem in MI300 folgen dürften: keine Anordnung von Chiplets nebeneinander, sondern übereinander: kürzere Wege: höhere Performance, höhere Effizienz; Einsparung von Diesize, da Kommunikations-Kontroller entfallen. Zudem wird nur noch das im teuersten Prozess gefertigt, was ihn braucht: CPU- und GPU-Chiplets. In den I/O-Chiplets, auf denen die CPU/GPU-Chipletzs sitzen, findet sich alles in Bezug auf I/O (diese dürften dann weitgehend auch Video-I/O erhalten, selbst wenn sie nicht genutzt wird) und vor allem auch die L3-Chaches, die kaum shrinken und daher von modernen Prozessen nicht profitieren. Zuletzt würde dieser Ansatz eine höhere Produktvielfalt mit noch weniger verschiedenen Dice ermöglichen: es gäbe z.B. keine extra Desktop-CPUs und APUs mehr, sondern: die "Desktop"-CPU erhält eben nur CPU-Chiplets onTop. Kombiniert man dagegen ein CPU- und GPU-Chiplet, hat man eine APU. Nimmt man nur GPUs, ergäbe das folglich eine Art reine GPU für eine diskrete Graka....allerdings wird man dafür dann wohl ein eigenes I/O-Chiplet brauchen....aber der Ansatz gefällt mir sehr: spart Kosten und bringt den nächsten Performance-Sprung, weil alle näher zusammen rückt. Mit diesem Ansatz dürfte das der Chiplet-Ansatz auch für GPUs funktionieren, weil die Inter-Chiplet-Kommunikation schneller und vor allem effizienter wird.