A GCN4 nagy fejlesztése
A GCN4 az előző oldal alapján olyannak tűnik, mint a többi korábbi GCN, ez azonban csak a látszat, mivel eddig ez az iteráció számít a legnagyobb előrelépésnek a GCN-ek történelmében. A legnagyobb fejlesztés vitathatatlanul az utasítás-előbetöltés támogatása. Ez egy olyan funkció, amit a központi processzoroknál már megszokhattunk, de a grafikus vezérlőknél nem sok használt lehetett látni, így nem is került bele a rendszerekbe. A világ azonban változik, és ez magával hozza az igények módosulását is, amelyekre reagálni kell.
Ha pusztán az elméletet tekintjük, akkor utasítás-előbetöltésre egy GPU esetében nincs szükség. Hogy miért? Mert ezeket a rendszereket eleve úgy tervezik, hogy toleránsak legyenek a memóriaelérésből eredő késleltetéssel szemben, ami például a GCN architektúra SIMT modelljével is megfigyelhető. Az efféle architektúrák működésének alapja az úgynevezett wavefront, ami gyakorlatilag szálak csoportját tartalmazza, annak érdekében, hogy az egy szálhoz tartozó memóriaelérés késleltetését egy másik szál betöltése kompenzálni tudja. A logika a GCN esetében nagyon egyszerű: egy CU egy SIMD motorjára levetítve biztosan lesz elég szál, hogy elfedjék egy szál memóriaelérésből eredő késleltetését, vagyis a rendszer állandóan képes dolgozni. A megfelelő kihasználáshoz az AMD SIMD motoronként 10 wavefrontot futtat, ami a teljes CU-ra levetítve 2560 szálat garantál.
Az alábbi ábra ezt némiképp szemlélteti. Persze nem rajzoltunk be 2560 szálat és a valódi késleltetés időigényét sem ábrázoltuk, ami ezernél is több ciklus lehet, de a lényeg így is látható. A SIMD motorok a memóriaelérés miatt nem tudják folytatni a munkát az adott feladaton, így bekövetkezik az úgynevezett pipeline stall. Ilyenkor megtörténik a kérés az adatelérésre, de a következő ciklusban már átveszi a munkát a következő SIMD, majd egyszer befut az első SIMD-hez az adat és az eredeti munka folytatódik. A lényeg az, hogy a folyamatos pipeline stall ellenére is mindig van min dolgozni.
A pipeline stall ideálisan kezelve (a kép csak illusztráció)
A wavefront futtatása azonban nem olyan egyszerű, mint ahogyan az a fentiek alapján látszik, ugyanis a különböző shader programok eltérő regiszterterületet igényelnek, vagyis elképzelhető, hogy 10 wavefront egyszerűen nem futhat a SIMD motoron, mert nincs elég regiszter hozzá. Ilyenkor az aktív wavefrontok száma csökken. Az AMD ajánlásai szerint a GCN architektúrában 7 wavefont az a minimum mennyiség, amivel a memóriaelérés még megfelelően átlapolható.
A pipeline stall problémája kevés aktív wavefront, ezen belül is kevés konkurens szál mellett (a kép csak illusztráció)
A lényeg ebből már látható. Elméletben a pipeline stall nem okozhatna problémát, mert a SIMT rendszerű architektúrákba bele van tervezve maga a megoldás. A gyakorlatban azonban ez az egyszerű programokra van méretezve, ugyanakkor ma már egyre bonyolultabb shadereket írnak a fejlesztők, amelyek egyre nagyobb regiszterigénnyel rendelkeznek. Ez addig nem baj, amíg ezek a shaderek vagy inkább futószalagok a program összes futószalagjának kis részét teszik ki, de maga a trend az AMD szerint egyre inkább felerősödik, vagyis kell valami megoldás arra az esetre, amikor a hardverbe tervezett működési modell kudarcot vall. Az utasítás-előbetöltés tulajdonképpen ezért került bele a GCN4-be. Ilyen formában radikális mértékben csökken a memóriaelérés ideje, mivel az adat jó eséllyel már az igénylés pillanatában ott van a gyorsítótárakban, ahonnan jóval kevesebb idő áttölteni a regiszterekbe. Bár ettől a SIMT rendszerű architektúra alapvető működési modellje nem változik, de például a teljesítmény már nem fog összeomlani akkor, ha az adott shader regiszterigénye akkora, hogy a SIMD motoron esetleg csak egyetlen egy wavefront futhat.
Az utasítás-előbetöltés megoldása a kevés aktív wavefrontra, ezen belül is a kevés konkurens szálra (a kép csak illusztráció)
A megfelelő működés érdekében az AMD megnövelte a wavefrontokhoz rendelt utasításpuffert is, ami a fenti változással együtt jelentős mértékben növeli az egy szálon leadott teljesítményt. A pipeline stall mértéke a GCN4 architektúrában minden esetben jelentősen csökken. Itt tényleg nagyságrendi változásra kell gondolni, mert az utasítás-előbetöltéssel gyakorlatilag bőven 100 ciklus alá lehet vinni a memóriaelérésből eredő késleltetést. Bár magát a rendszert az AMD az új és egyre bonyolultabb shaderekhez dolgozta ki, az egész akkor is segít, ha a fejlesztők rosszul optimalizált, indokolatlanul nagy regiszterigénnyel rendelkező shadereket használnak. Ezeknél is tipikus probléma szokott lenni a pipeline stall, és ezt gondot a Polaris tulajdonképpen hardverből kezeli. Persze a rosszul optimalizált shadereket driverből is ki lehet cserélni (és az AMD, illetve az NVIDIA ezt meg is szokta tenni), vagyis ez a gond tulajdonképpen kezelhető, ugyanakkor a hardveres konstrukció így is előnyös, mivel a shaderek szoftveres úton történő cseréjére sokszor hónapokat kell várni, míg a hardveres út azonnal működik.
Az utasítás-előbetöltés a DirectX 12 és a Vulkan API mellett is lényeges előnyöket biztosít. A többszálú modellel egyszerűen annyira hatékonnyá vált a processzor oldalán történő parancsfeldolgozás, hogy bőven lehet olyan játékokat fejleszteni, amelyek tízezer rajzolási parancsnál többel dolgoznak képkockánként. Ez a DirectX 11 miatt eddig nem volt realitás, de nagyon gyorsan az lesz. A váltás miatt ugyanakkor olyan limitációk jelennek meg az aktuális hardverekben, amelyeket a DirectX 11 alatt nem lehetett kihozni. Mindmáig ugyanis nem volt fontos az a tényező, hogy az adott GPU multiprocesszorának úgymond milyen mély a futószalagozása, vagyis mennyi az az idő, ami eltelik a feladatok adatigénylése és a várt adatok beérkezése között. Az aktuális GPU-k futószalagozásának mélysége ezer és tízezer ciklus közötti.
A dolgok pikantériája itt az, hogy megfelelő programfuttatási sebességet feltételezve tízezer rajzolási parancs képkockánként már nagyjából csak 1 mikromásodpercnyi késleltetést enged meg a GPU-n belüli szálak esetében, és ha a rajzolási parancsok száma nő, akkor a bőven bele lehet csúszni a mai hardverek futószalagozási modelljének limitjeibe. Ezen a problémán is jelentősen segít az utasítás-előbetöltés, amellyel bőven 1 mikromásodperc alá vihető a futószalagidő azzal, hogy a szükséges adat igénylése az előbetöltésnek hála még a tényleges igényre vonatkozó parancs kiadása előtt megtörténik. Mindez azt jelenti, hogy a rengeteg rajzolási paranccsal dolgozó alkalmazások lényegesen jobban fognak skálázódni a Polaris családba tartozó grafikus vezérlőkön, míg a többi hardveren beleütköznek a mély futószalagozás limitjeibe.
A cikk még nem ért véget, kérlek, lapozz!
