RDNA4 (Navi 4X, Radeon RX 9000 Serie, 4nm, 2025)

[Savay]

Für mich machte es ein wenig den Eindruck, dass die WGP eigentlich eher zu einem Äquivalent zu Nvidias SM wurde und CU eigentlich eher ein legacy term wurde.

Also "CU" ist bei RDNA doch eh bereits von Anfang an ein "legacy term" gewesen...zumindest in der technischen Dokumentation.
Schau dir einfach den Aufbau bspw. mal bei RDNA4 an...ein CU wäre da ein (virtuell) halbierter WGP...den kannst du aber logisch und physikalisch gar nicht sinnvoll halbieren.

Mein Tipp ist, wie von vielen Seiten auch schon mehrfach angemerkt, einfach das sie künftig das was für RDNA noch WGP waren bei UDNA schlicht CU nennen, weil's einfach zu missverständlich wurde und es begrifflich auch mit CDNA besser zusammenpasst wo es die CU ja weiterhin gibt. (bzgl. Zusammenführung der Architekturen)

[dildo4u]

Retail 9700 Pro 32gb kommt für 1300$ ab 27.10


https://videocardz.com/newz/amd-radeon-ai-pro-r9700-officially-launches-october-27-for-1299-retail

[mksn7]

Mein Tipp ist, wie von vielen Seiten auch schon mehrfach angemerkt, einfach das sie künftig das was für RDNA noch WGP waren bei UDNA schlicht CU nennen, weil's einfach zu missverständlich wurde und es begrifflich auch mit CDNA besser zusammenpasst wo es die CU ja weiterhin gibt. (bzgl. Zusammenführung der Architekturen)

Das denke ich auch. Wenn man bei den aktuellen WGP's die zwei separaten L1 caches zusammenlegt, dann ist von der Unterteilung einer WGP in zwei CUs doch gar nichts mehr übrig.

Das komplette Konstrukt wird dann halt CU genannt weil das der ältere Begriff ist.

[mczak]

Das denke ich auch. Wenn man bei den aktuellen WGP's die zwei separaten L1 caches zusammenlegt, dann ist von der Unterteilung einer WGP in zwei CUs doch gar nichts mehr übrig.

Naja also so eine CU bei RDNA4 enthält schon eine ganze Menge. Klar Befehlscache, Skalarcache und LDS sind innerhalb der WGP geshart, aber es ist ja nicht nur der L0 der separat ist - die CUs enthalten ja nicht nur das ganze Arithmetik-Zeugs, inklusive eigenem Scheduler, sondern sowohl die RT-Einheiten wie auch die TMUs (macht wohl sonst auch keinen Sinn wenn der L0 separat ist). Die WGP mag zwar der fundamentale Block sein, aber man könnte auch sagen die besteht fast ausschliesslich aus 2 CUs und macht selber quasi nichts, ausser eben dem Teilen von ein paar Caches.
Aber natürlich möglich dass das anders ist bei RDNA5.

[mksn7]

TMUs und raytracing accelerators sind tatsächlich noch in der jetzigen CU beheimatet. Alle anderen Komponenten die du aufzählst, wie scheduler und execution units, sind ja nicht auf der CU Ebene geteilt sondern gehören zur Unterteilung darunter, den SIMDs (wie AMD sie nennt). Der Wegfall der Unterteilung einer WGP in zwei CUs betrifft deswegen nur L0, TMUs, RA. Zumindest soweit man den Schaubildern glauben darf, die stellen eine vereinfachte Erzählung dar.

In Zukunft gäbe es als eine CU mit gemeinsamen L1I, L0, TMU, RA, scalar cache, und 4 SIMDs mit jeweils eigenen schedulers, registers, execution units etc.

[Locuza]

Also "CU" ist bei RDNA doch eh bereits von Anfang an ein "legacy term" gewesen...zumindest in der technischen Dokumentation.
Schau dir einfach den Aufbau bspw. mal bei RDNA4 an...ein CU wäre da ein (virtuell) halbierter WGP...den kannst du aber logisch und physikalisch gar nicht sinnvoll halbieren.

Mein Tipp ist, wie von vielen Seiten auch schon mehrfach angemerkt, einfach das sie künftig das was für RDNA noch WGP waren bei UDNA schlicht CU nennen, weil's einfach zu missverständlich wurde und es begrifflich auch mit CDNA besser zusammenpasst wo es die CU ja weiterhin gibt. (bzgl. Zusammenführung der Architekturen)
Für RDNA1-4 ist es zweckvoll zwei unterschiedliche Begrifflichkeiten zu haben, zwar gibt es physisch tatsächlich immer nur eine "WGP" Unit, aber logisch betrachtet unterstützt das Konstrukt zwei unterschiedliche Arbeitsmodi:

Each work-group or wave can operate in one of two modes, selectable per draw/dispatch at wave-create time:

CU mode
In this mode, the LDS is effectively split into a separate upper and lower LDS, each serving two SIMD32s.
Waves are allocated LDS space within the half of LDS which is associated with the SIMD the wave is running on.
For work-groups, all waves are assigned to the pair of SIMD32s. This mode may provide faster operation since both halves run in parallel, but limits data sharing (upper waves cannot read data in the lower half of LDS and vice versa).
When in CU mode, all waves in the work-group are resident within the same CU.

WGP mode
In this mode, the LDS is one large contiguous memory that waves on the WGP allocate from, up to the same maximum allocation size.
In WGP mode, waves of a work-group may be distributed across both CU’s (all 4 SIMD32s) in the WGP. DS_PARAM_LOAD and DS_DIRECT_LOAD are not supported in WGP mode.
The WGP (and LDS) can simultaneously have some waves running in WGP mode and other waves in CU mode running. LDS performance may degrade when wave reference data on the "opposite side" from the SIMD they’re on.
https://www.amd.com/content/dam/amd/en/documents/radeon-tech-docs/instruction-set-architectures/rdna4-instruction-set-architecture.pdf

Der CU-Mode scheint auch häufig verwendet zu werden, weil unter dem WGP-Mode die LDS-Bandbreite/Performance schlechter ausfallen kann, denn physisch verschaltet eine Crossbar zwei 64 KB LDS Hälften, es ist keine "uniforme" 128 KB Struktur.
Ebenso entfällt das explizite Management der Speicherzugriffe, da alles nur durch einen lokalen L0 Cache geht, nicht durch zwei die keine HW Kohärenz untereinander haben.

[gedi]

Retail 9700 Pro 32gb kommt für 1300$ ab 27.10


https://videocardz.com/newz/amd-radeon-ai-pro-r9700-officially-launches-october-27-for-1299-retail

Die günstigste 32GB Karte. Wenn se ein Dual-Bios hätte, dann wäre sie eine Überlegung wert!

[reaperrr]

Naja, GDDR5X hätte Fiji schon irgendwie gerettet. Damit wäre die Karte wie Hawai mit 8GB ausgestattet gewesen. Passt aber vom Zeitplan nicht ganz, GDDR5X fällt genau zwischen FuryX und Vega.
Ne, im Gegenteil, damit hätte Fiji noch weniger Sinn gemacht.

Dass selbst ne 390 mit nur 40 CUs und leicht niedrigerem Chip-Takt trotzdem etwas mehr Saft zieht als ne Fury X liegt alles am SI/GDDR5.
Speichercontroller + -interfaces + GDDR5 ziehen @ 6 GHz bei Hawaii scheinbar mal eben ca. ~120-150W mehr als das gesamte HBM-System von Fiji.

Mit GDDR5(X) hätte Fiji mehr L2 und (mglw. deutlich) niedrigere Taktraten gebraucht, um irgendwie in 300W zu bleiben.

CDNA5 / RDNA5 VGPRs sollen auf 256kByte anwachsen:
https://forums.anandtech.com/threads/rdna-5-udna-cdna-next-speculation.2624468/page-51#post-41501334

Macht mMn Sinn, wenn man von 64SP auf 128SP pro CU vergrössert. 256kByte sind 2x von CDNA3/4 und 1.33x ausgehend von RDNA3/4.
Schau dir mal die Schaubilder von RDNA4-CUs genauer an.
https://www.notebookcheck.net/AMD-RDNA-4-architecture-deep-dive-A-64-CU-monolithic-design-with-all-round-improvements-to-compute-media-encode-decode-ray-tracing-and-AI.969593.0.html
RDNA4 hat bereits 128 ALUs je CU, genau wie RDNA3.
64 reine FMA, 64 FMA/INT je CU.
Wurde nur nach dem RDNA3-Fiasko wegen schlapper DualIssue-Auslastung nicht mehr so beworben, weil die Auslastung halt erst mit RDNA5 wirklich verbessert wird.

Die 256kB VGPR sind eine der Maßnahmen um das zu beheben, irgendwo wurde mal erklärt, dass die DualIssue-Auslastung von RDNA3/4 u.a. durch die 128 (N33) bzw. 192KB VGPR limitiert wurden (könnte auf Chips&Cheese gewesen sein).

Gibts schon Spekulationen, was dann mit TMUs etc passiert? Wenn die SP ohne Anstieg der anderen Units verdoppelt wird, dann wird die IPC fallen und nicht steigen. Außer man verzichtet auf Dual-Issue, weil man auf vollständige SP stattdessen geht.
Da passiert nix, weil sich das Verhältnis von ALUs zu TMUs eben gar nicht wirklich ändert.
Die RDNA5-"CUs" sind einfach WGPs, die jetzt besser verzahnt sind, und der bereits seit RDNA3 vorhandene, aber bisher selten genutzte zweite Satz ALUs pro alt-CU/WGP-Hälfte/neu-CU-Hälfte wird mit RDNA5 einfach nur deutlich zuverlässiger ausgelastet.

Das ist also ne IPC-Steigerung, weil eine RDNA5-CU die Specs einer RDNA4-WGP hat, aber ca. 10-20% IPC draufpacken soll durch u.a. besseres Cache-System und mehr VGPR.

[mksn7]

Die 256kB VGPR sind eine der Maßnahmen um das zu beheben, irgendwo wurde mal erklärt, dass die DualIssue-Auslastung von RDNA3/4 u.a. durch die 128 (N33) bzw. 192KB VGPR limitiert wurden (könnte auf Chips&Cheese gewesen sein).


Die zusätzlichen execution units (es ist kein richtiges dual-issue, aber ja, der Begriff wird von AMDs marketing verwendet) werden genau dann effektiv, wenn entweder eine "dual" instruction genutzt wird oder der wave64 mode aktiv ist. Beides wird von der Kapazität des register file nicht beeinflusst.

Es hängt von der genauen Art der Berechnung und dem compiler ab, ob zwei seperate instructions in eine dual instruction kombiniert werden. Für eine effektivere Nutzung der zusätzlichen execution units müssten die Anforderungen (Anzahl an Operanden, welche Operanden geshared werden müssen, welche isntructions kombiniert werden können) an die dual instructions reduziert werden.

[horn 12]

Navi 48 Refresh in Anmarsch

PGGH hat da bei Linux Kernel was entdeckt

Würde man die Gunst der Stunde nutzen, auch wenn Speicher teuer sein wird.
NV kann womöglich nicht vor Juli - August Releasen und würde somit dem AMD Refresh guttun!


https://www.pcgameshardware.de/Grafikkarten-Grafikkarte-97980/News/AMD-Radeon-Next-Gen-GPUs-in-Linux-Patches-1487242/

[mczak]

Navi 48 Refresh in Anmarsch

PGGH hat da bei Linux Kernel was entdeckt

Würde man die Gunst der Stunde nutzen, auch wenn Speicher teuer sein wird.
NV kann womöglich nicht vor Juli - August Releasen und würde somit dem AMD Refresh guttun!


https://www.pcgameshardware.de/Grafikkarten-Grafikkarte-97980/News/AMD-Radeon-Next-Gen-GPUs-in-Linux-Patches-1487242/
Das sollte eigentlich kein N48 Refresh sein. N44 ist gfx1200, N48 gfx1201, wobei das sind die Bezeichnungen die im Userspace verwendet werden. Aber 12.1 müsste eigentlich ein neuer Chip sein, impliziert doch gewisse Aenderungen an der Architektur. Gibt ja auch schon Userspace-Einträge mit gfx1250, das scheinen APUs zu sein. Tomshardware vermutet gfx 12.1 sei AMD Instinct (https://www.tomshardware.com/pc-components/gpus/amds-linux-kernel-patches-suggest-enablement-of-next-gen-instinct-mi400-series-ai-gpu-accelerators).

[reaperrr]

Das sollte eigentlich kein N48 Refresh sein. N44 ist gfx1200, N48 gfx1201, wobei das sind die Bezeichnungen die im Userspace verwendet werden. Aber 12.1 müsste eigentlich ein neuer Chip sein, impliziert doch gewisse Aenderungen an der Architektur. Gibt ja auch schon Userspace-Einträge mit gfx1250, das scheinen APUs zu sein. Tomshardware vermutet gfx 12.1 sei AMD Instinct (https://www.tomshardware.com/pc-components/gpus/amds-linux-kernel-patches-suggest-enablement-of-next-gen-instinct-mi400-series-ai-gpu-accelerators).
GFX12.5 ist laut mehreren Leakern CDNA5.
Schreiben Tom's Hardware auch so.

Die kleineren integrierten Grafiken bleiben bei den Zen6-APUs nach derzeitiger Info-Lage noch bei RDNA3.5, bzw. kriegen gleich RDNA5 als Chiplet (AT3/4) bei den Premium/Halo APUs.
PS6 und XboxNext sollen beide ebenfalls schon RDNA5 haben.

Hinweise auf RDNA4-APUs gab's bisher eigentlich Null, bis auf einen Samsung Exynos Prototyp, der scheinbar RDNA4 hat.

Wäre insofern schon interessant zu wissen, für was jetzt GFX12.1 steht.
Vielleicht ist die Auflösung aber auch was ganz banales (z.B. 430X mit FP64-Fokus = GX12.1, 455X mit KI-Fokus = GFX12.5).

[robbitop]

CDNA ist ja schon ultra lange GFX9 (was die Herkunft zu GCN unterstreicht). Ob hinter dem Versionssprung auf GFX12 (wie RDNA4) wirklich ein Indiz ist, dass jetzt schon beide uArchs näher zusammenrutschen (also UDNA)?

[basix]

GFX12.5 ist laut mehreren Leakern CDNA5.
Schreiben Tom's Hardware auch so.

[...]

Hinweise auf RDNA4-APUs gab's bisher eigentlich Null, bis auf einen Samsung Exynos Prototyp, der scheinbar RDNA4 hat.

Wäre insofern schon interessant zu wissen, für was jetzt GFX12.1 steht.
Vielleicht ist die Auflösung aber auch was ganz banales (z.B. 430X mit FP64-Fokus = GX12.1, 455X mit KI-Fokus = GFX12.5).

Als zusätzliche Info:
RDNA5 ist GFX13