Az új NCU-k képességei

A multiprocesszorokhoz szorosan nem kapcsolódó részt átrágva visszatérhetünk az utasítás-architektúra újításaihoz. Az AMD az elmúlt időszakban folyamatosan a rapid packed math képességről beszélt, amit egy ideje a GCN3 és a GCN4 architektúra is támogat, viszont a GCN5-öt használó Vega 10 további fejlesztéseket tartalmaz. Itt konkrétan arról van szó, hogy milyen adatokkal dolgozik a program. Jelenleg jellemzők a 32 bites, nem csomagolt adatok, amelyekkel a vektorregiszterekre vonatkozó terhelés tulajdonképpen teljes lesz, és ez nem igazán jó, mivel sok shader esetében a nagyobb pontosságnak nincs lényegi haszna, viszont a kihasználtságra vonatkozó limittel rendelkező SIMT architektúráknak (ilyen a GCN is) az egész szituáció nem kedvez. Az AMD a megoldást kétféle csomagolási stratégiában látja, amelyek struktúrák tömbje, illetve tömbök struktúrája néven ismertek. A GCN3 és GCN4 hardvereken mindkettő a felére csökkenti a vektorregiszterekre vonatkozó terhelést, így a kihasználtságra vonatkozó limit csökken, vagyis az újabb verziójú GCN dizájnok esetlegesen több wavefrontot futtathatnak a multiprocesszoron.

[+]

A Vega esetében már nem csak a vektorregiszterek terhelése lesz visszafogva, hanem konkrétan nő az operációk végrehajtásának tempója. Elméleti szinten ez a struktúrák tömbje opciónál 50%-kal jobb sebességet eredményez, míg a tömbök struktúrája verzió konkrétan a duplájára gyorsítja a feldolgozást.

Az AMD arra számít, hogy ez egy vezető irányzat lesz a közeljövőben, köszönhetően annak, hogy az aktuális explicit API-kra vonatkozóan már él a támogatás, és elég komoly teljesítményt lehet vele nyerni. Ugyanakkor a fejlesztők inkább a PlayStation 4 Pro miatt szemezhetnek vele, hiszen a Sony aktuális csúcskonzoljának is ez a "szuperképessége", márpedig nagyon sok multiplatform címnél a Sony rendszere számít a vezető platformnak. Inkább ez a tényező indikálhatja ezt az irányt a PC-piacon is, noha ez az AMD nézőpontjából mindegy, számukra úgyis csak a támogatás megléte számít.

Az NCU-k másik újítása, hogy a 64 kB-os LDS mostantól nem statikusan lesz particionálva. A korábbi architektúrákban a helyi adatmegosztásnak a fele bizonyos feladatokra volt fenntartva, példaként említve a manuális interpolációt, és a másik felét, vagyis a maradék 32 kB-ot érhették el a SIMD feldolgozók a compute shaderek futtatására. Az új rendszerből ez eltűnik, így a teljes 64 kB elérhető az utóbbi feladatra is, amellett persze, hogy a manuális interpoláció megmarad. Ezt dinamikus particionálással érik el.

A fenti két újítás részben megpróbál kezelni egy problémát. A mai GPU-k statikus erőforrás-allokációt használnak, ami azt jelenti, hogy egy új wavefront futtatása előtt az ütemező biztosít minden erőforrást, ami a végrehajtáshoz szükséges. Amíg a megkezdett wavefront be nem fejezi a munkát, az erőforrások nem szabadíthatók fel, függetlenül attól, hogy használva vannak-e épp vagy sem.

Ez igazából egy elég rossz működési modell, és el is értünk a SIMT dizájnok egyik problémájához: a kihasználtságlimithez. Mivel az erőforrások, vagyis tulajdonképpen a regiszterek és a helyi adatmegosztásra szánt tárolók limitáltak, így egy multiprocesszoron nem futhat tetszőleges számú wavefront. Pedig jó lenne, ugyanis minél több wavefront fut, annál inkább át lehet lapolni a memóriaelérésből adódó késleltetést. Ez könnyen kitalálható, hogy miért kell, mivel ha egy wavefront számára nincs meg az adat, akkor lementi a munkát az adott multiprocesszor, és elindít egy olyan wavefrontot, ami már tud dolgozni az elérhető adatokkal. Később az eredeti folyamat folytathatja a munkát a már beérkezett adatokkal. Ha viszont elfogy azoknak a wavefrontoknak a száma, amelyek futhatnak, és mindegyik adatra vár, akkor az adott vektormotor konkrétan nem fog csinálni semmit.

Régóta ismert, hogy a GCN architektúrán egy vektormotoron maximum 10 wavefront futhat, az optimális működéshez pedig ajánlott úgy írni a shadereket, hogy hét wavefront legalább legyen. Ez az elmélet ugye, de a gyakorlatban a statikus erőforrás-allokáció igencsak megnehezíti a helyzetet, ugyanis a shaderek rendkívül eltérők. Előfordulhat olyan shader, amelynek rengeteg vektorregisztert kell allokálni, de kevés helyi adatmegosztást, vagy fordítva, esetleg mindkét erőforrás szempontjából nagy igénybevétel keletkezik. Tulajdonképpen mindegyik eset problémás, mert potenciálisan csökkenti a futtatható wavefrontok számát.

Vektorregiszterek tekintetében a GCN kellemesen felhizlalt architektúrának tekinthető, mivel vektormotoronként 64 kB regiszter áll rendelkezésre. Meglepő ugyanakkor, hogy ez időnként mennyire kevés, de ekkor a rapid packed math segíthet, ugyanis az adott shader regiszterigényét konkrétan megfelezi, vagyis ha a helyi adatmegosztás nem limitálja a wavefrontok számát, akkor ezekből dupla annyi, vagy akár a maximum mennyiség lesz futtatható.

Hasonlóan segít a helyi adatmegosztásra szánt tároló statikus particionálásának megszüntetése, ugyanis ez effektíve növeli a rendelkezésre álló memóriát. Ahogy fentebb említettük, ez is limitálhatja a wavefrontok számát, még akkor is, ha mondjuk lenne kellő mennyiségű vektorregiszter.

Ezek mellett a Polaris architektúrából megörökölt utasítás-előbetöltés is lerövidíti a memória-hozzáférés késleltetését. De van még egy probléma, mégpedig a maximum három-három NCU-hoz kapcsolódó 16 kB-os skalár és 32 kB-os utasítás, illetve az NCU-nkénti 16 kB-os L1 gyorsítótárak túlterhelése, illetve jobban mondva az úgynevezett újrahasznosítási ablakról való lecsúszás. Egy GPU-nál ugyanis tipikus, hogy az adatok viszonylag kevés ideig élnek a feldolgozókhoz közeli gyorsítótárakban, tehát nagyon nehéz ezeket újrahasznosítani, mivel kevés idő van rá. Ezt a nehézséget az AMD szoftveresen szeretné kezelni, és ehhez például a Vulkan API kapott is egy VK_AMD_wave_limits kiterjesztést. Utóbbi még nem publikus, de arról van szó, hogy a fejlesztők konfigurálhatják, mik fussanak a multiprocesszorokon, így hatékonyabb lehet a gyorsítótárak kihasználása. Ez óhatatlanul azzal járhat, hogy a wavefrontok számát limitálni kell, de vannak esetek, amikor az újrahasznosítási ablak megcélzása jobb teljesítményt eredményez. Maga a VK_AMD_wave_limits kiterjesztés egyébként nem csak a Vega architektúrához való, hanem a korábbi GCN-es Radeonokhoz is, de a Vega képességeivel némileg hatékonyabban működtethető.

A cikk még nem ért véget, kérlek, lapozz!