Az AMD az explicit API-k bevezetése, illetve ma már térhódítása mellett nagyon fontosnak tartja, hogy a fejlesztők pontosan ismerhessék az egyes grafikus vezérlőiket, így az architektúráik fejlesztését folyamatosan dokumentálják. A Radeonok többségének alapját adó GCN (Southern Islands), GCN2 (Sea Islands), GCN3/4 (Volcanic Islands/Polaris) és GCN5 (Vega) verzióhoz már elérhető a dokumentáció, míg mától a Navi 10 alapját képző legújabb RDNA opcióhoz is publikusan hozzáférhetővé vált a teljes leírás egy 232 oldalas dokumentum formájában.

A korábbi GCN dizájnokhoz képest alapvető változások állnak be, hiszen teljesen új architektúráról van szó, ami egyrészt módosított kódolási sémát használ, másrészt radikálisan eltérő a rendszer ütemezése. Minderről részletesen írtunk az RDNA-t elemző cikkünkben, vagyis ismerős lehet a négy helyett egy cikluson belül utasításkiosztás, illetve a variálható wavefrontméret, amivel 32 és 64 munkaelemből is állhat egy wavefront. Mindezeket részben az átdolgozott multiprocesszorok biztosítják, amelyek párosával használják a compute egységeket.

A utasításarchitektúrára vonatkozó legfontosabb változás, hogy mostantól mindegyik wavefront kap egy fix számú skalár regisztert, ami lényegében abból ered, hogy az RDNA-s hardverekben már minden vektormotor mellett van egy skalárfeldolgozó is. Ahhoz, hogy legyen elég kapacitás, egy skalárfeldolgozó mellé 16 kB-nyi regiszterterület tartozik, ami a korábbi generációk 2,8-4 kB-os értékéhez képest jelentős előrelépés.

A fentieken túl számos utasítás működése jelentősen módosult, illetve bizonyos korábbi utasítások el is tűntek, köztük a VSKIP, amely a GCN-nél nagyon kedvezően használható volt bizonyos optimalizálásokhoz, de az RDNA annyira másképp működik, hogy nincs rá szüksége.

A dokumentációból kiderül még, hogy a helyi adatmegosztás, vagyis az LDS (Local Data Share) tekintetében az RDNA kétféle módban is képes üzemelni: CU és WGP. A CU módban az LDS két 64 kB-os részre lesz vágva, és maguk a tárterületek aszerint lesznek kiosztva, hogy az adott CU-n belüli SIMD motorokhoz mennyire vannak közel fizikailag. Ez növeli az LDS teljesítményét, de csökkenti az adatmegosztásra vonatkozó lehetőségeket, mivel az adott CU a távolabbi LDS szeletet nem tudja elérni. Erre jelent választ a WGP mód, ahol a multiprocesszoron belüli összes SIMD motor eléri a teljes, 128 kB-os LDS-t, de bizonyos esetekben az operációk végrehajtása lassabb lesz a CU módhoz képest. Az nagyon az adott shadertől függ, hogy melyik mód működik jobban, ugyanakkor az RDNA architektúra támogatja azt, hogy az egyik shader a CU, míg a másik a WGP módot használja, mindez a hardver szintjén problémamentesen van kezelve.