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.