Felzárkózás a konzolokhoz a Hawaii cGPU-val
Az új ACE egység elsődleges újítása, hogy egy parancslista helyett már nyolcat kezel, emellett a rendszer képes saját magának új munkát adni anélkül, hogy a processzor beavatkozására lenne szükség. Ezzel lényegében támogatható az OpenCL 2.0-ban érkező dinamikus parallelizmus funkció.
[+]
A felújított ACE egységek száma továbbra is meghatározható. Például a Kabini és a Temash kódnevű SoC APU-k IGP-je négyet, az Xbox One APU-jának IGP-je kettőt, míg a PlayStation 4 APU-jának IGP-je nyolc darabot kapott. Utóbbitól az új Hawaii kódnevű cGPU sem akart elmaradni, így ebbe a lapkába is nyolc új ACE egység került. Ezek továbbra is képesek egymással szinkronizálni, és kommunikálni a GDS (globális adatmegosztás) és az L2 gyorsítótáron keresztül. Az AMD a változásokkal még erősebben rálépett a compute irányra, aminek hála olyan grafikus processzorok készülnek, amelyek hatékony multitaszk feldolgozást tesznek lehetővé. Ennek manapság nincs látható jelentősége, hiszen a piacon kapható hardverek többsége nem elég jó ahhoz, hogy a fejlesztők építsenek az előbbi a képességekre, de az új generációs konzolok megjelenésével ez a felfogás megváltozik, így a PC-be is át kell menteni ezeket a funkciókat.
Újítások a Hawaii cGPU-ban
Most, hogy látható a GCN rendszerek közötti alapvető eltérés, rá lehet térni a Hawaii kódnevű cGPU vizsgálatára, mely gyakorlatilag a legmodernebb részegységekre épít, azaz konkrétan azokra, amelyeket az Xbox One és a PlayStation 4 konzolok APU-jainak IGP-je kapott. Az új lapka a TSMC 28 nm-es gyártástechnológiájával készül, kiterjedése pedig 438 mm², és ebbe a méretbe 6,2 milliárd tranzisztort sikerült bepasszírozni. A rendszer alapját továbbra is a CU, azaz a Compute Unit képzi, ami azonban a Tahiti cGPU-hoz képest változott egy picit. Radikális különbségekre persze nem kell gondolni, hiszen megmaradt az egy skalár feldolgozó, illetve négy darab, egymástól teljesen független, 16 utas, azaz 512 bites, multiprecíziós SIMD motor. Egy CU-n belül továbbra is 64 kB-os helyi adatmegosztás, vagy más néven Local Data Share (LDS) található, melyen a négy darab, egyenként 64 kB-os regiszterterülettel rendelkező SIMD motor osztozik. Az LDS mellett egy 16 kB-os adat gyorsítótár is elérhető, melyet a CU írhat és olvashat is.
[+]
Az előző bekezdésben már említett skalárfeldolgozó némileg különc a CU-n belül. Ez lényegében egy integer ALU, mely 4 kB-os dedikált regiszterterületet kapott. Észrevehető, hogy a korábbi CU dizájnban 8 kB dedikált regiszterterület állt rendelkezésre, vagyis az AMD itt jelentősen visszavett az elődökhöz képest. Ezt a cég azzal magyarázza, hogy még a 4 kB is bőven sok erre a célra, így nincs értelme a tranzisztorokat olyan helyen használni, ahol nem hoz gyorsulást. A textúrázást CU-nként továbbra is egy blokk oldja meg, mely négy darab, csak szűrt mintákkal visszatérő, Gather4-kompatibilis textúrázó csatornát rejt. Funkcionális újítás még a továbbfejlesztett MQSAD utasítás, mely jobb minőségben dolgozik, mint a korábbi lapkákban, illetve a rendszer pontosabban számolja a natív LOG és EXP operációkat.
Rendkívül érdekes extra még a CU-kon belül, hogy a rendszer mostantól használhatja az LDS-t a geometry shaderek adatainak lementésére. Erre az AMD korábban a GDS-t használta, illetve ez még most sem tilos, de a 64 kB-os helyi adatmegosztás továbbra is túlteljesíti a DirectCompute 5.0 igényét, hiszen ez a felület 32 kB-os tárat ír elő. Viszont a vállalat a GCN architektúra esetében az LDS-t virtualizálja, tehát a különböző feladatok egymás adatait nem bánthatják. Az új ötlettel drámaian lehet növelni az architektúra geometry shader kódokban leadott teljesítményét anélkül, hogy az kárt okozna más munkafolyamatoknak.
A lapka egészét tekintve már érdekesebb újítások vannak. Ahogy korábban említettük, nyolc darab ACE egység került a grafikus parancsprocesszor mellé. Előbbi csak compute, míg utóbbi compute és grafikus feladatokat képes feldolgozni. A rendszer része maradt a 64 kB-os globális adatmegosztás, vagy más néven Global Data Share (GDS), emellett megmaradt a két DMA motor, a VCE 1.0-s és az UVD 3.2-es egység, illetve bekerült a TrueAudio blokk, melyről cikkünkben részletesen írtunk.
A rendszer belső szervezése azonban egy picit megváltozott. Mostantól a hardver úgynevezett shader motorokra van felosztva. Ezeken belül számos CU tömb lehet, számos ROP-blokkal, viszont mindegyik motor alapvető eleme egy tesszellátor és egy raszter motor. Az új, tizedik generációs tesszellátor a Tahiti cGPU-ban bemutatott kilencedik generációs egységhez képest csak picit fejlődött, főleg a pufferelés területén. Lényegesebb újítás azonban, hogy a raszter motorok jelentős fejlődésen mentek keresztül. Egy ilyen egység órajelenként 16 pixelt képes feldolgozni, de ennél is fontosabb, hogy a teljes raszterizálási folyamat nagyobb gyorsítótárakkal dolgozhat, így jelentősen gyorsul majd a hardver azokban a szituációkban, ahol a háromszögek nem tesznek ki 16 pixelt. Információink szerint a felújítás hatására a csupán négy pixelt kitöltő háromszögek feldolgozása is rendkívül gyors lett, annak ellenére, hogy itt már a raszterizálás hatékonysága általánosan hátrányosnak tekinthető.
Korábban már többször is leírtuk, hogy a 2 x 2 pixeles tömbökön zajló leképzés miatt nem ideális, ha egy háromszög kisebb mint 16 pixel, mivel ez drámaian csökkenti a feldolgozás hatékonyságát minden hardveren. Ez alól az új Hawaii cGPU sem kivétel, csupán az történik, hogy a feldolgozás sebessége nem esik annyira vissza, mint a többi hardveren, de a hatékonyság akkor is radikális mértékben esik. Ennek megfelelően továbbra sem támogatjuk, hogy egy játékban 16 pixelnél kisebbek legyenek a háromszögek. Az viszont elmondható, hogy ha kisebbek, akkor az messze a Hawaii setup részének a legkedvezőbb. Úgy gondoljuk azonban, hogy a fejlesztők értik a tesszellálás lényegét, így pontosan tudják, hogy semmire sem mennek azzal, ha drámaian lecsökkentik a raszterizálás hatékonyságát, tehát az AMD fejlesztése nem nekik szól, hanem inkább az NVIDIA-nak. Ha a zöldek továbbra is igénylik a reálisan értékelhetőnél jobban tesszellált felületeket (legyen az akár sík vagy sem) a fejlesztőktől, akkor azzal mostantól a Hawaii cGPU-nak tesznek nagyon jót. Viszont kérdés, hogy átesünk-e a ló túloldalára, mivel az AMD is hozzáállhat úgy a kérdéshez, hogy a jövőben túltesszellálják a játékokat, hiszen ez mostantól nekik kedvez.
A shader motorokon belül három vagy négy CU rendeződhet egy tömbbe, és ezekhez tartozik egy 16 kB-os skalár és egy 32 kB-os utasítás gyorsítótár. Előbbit csak a skalárfeldolgozó éri el, és csak olvasható tárról van szó, ám utóbbi írható is, és a CU összes feldolgozója hasznosíthatja.
A cikk még nem ért véget, kérlek, lapozz!
