Virtuális valóságra tervezve
Az általános számítások szempontjából a Fiji egy igazi monstrum. A lapkán belül megmarad a nyolc darab ACE egység a grafikus parancsprocesszor mellett, ahol előbbi csak compute, míg utóbbi compute és grafikus feladatokat képes feldolgozni. Eközben továbbra is a rendszer része 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 rendszer összességében 64 compute parancslistát kezel 1 grafikai parancslista mellett, ami egyébként általánosan jellemző az újabb Radeonokra.
Az általános számításokhoz kapcsolódóan viszont az egyik legfontosabb információ, hogy ez az első igazán nagy teljesítményű grafikus vezérlő a piacon, amelyet a technikai tudás tekintetében is a virtuális valósághoz terveztek. Utóbbi szegmens az AMD reményei szerint a következő év elején hatalmas népszerűségre tesz majd szert, és nem véletlen, hogy ennyire kampányolják az újszerű élményt, hiszen a GCN architektúra, különösen a Fiji harmadik generációs iterációja abszolút kiszolgálja a virtuális valóság legfőbb igényeit, olyan fontos funkciókra alapozva, amelyeket más még nem épített be. Nyilván az sem véletlen, hogy az E3-on a virtuális valóságot bemutató demonstrációkat az AMD rendszerén futtatták.
Ha már ennyire ki van emelve a virtuális valóság a Fiji cGPU szempontjából – nyilván nem ok nélkül –, akkor érdemes megvizsgálni, hogy mitől is olyan különleges ez a lapka, vagy másképp fogalmazva mi kell a jó élményt kínáló virtuális valósághoz.
[+]
A Fiji legfontosabb képessége ebből a szempontból az úgynevezett finomszemcsés preempció támogatása, amely lehetővé teszi, hogy az architektúra tetszőlegesen leállítson és későbbi folytatásra elmentsen egy feladatot, ha időközben befut egy magasabb prioritású feladat. Erre természetesen a AMD Radeon R9 285 is képes, de a Tonga cGPU számítási teljesítménye nem kiemelkedő, persze nem is tekinthető rossznak. Az azonban kétségtelen, hogy a Fiji jóval erősebb, és a Tonga tudásával kiegészítve rendkívül hatékony az asynchronous timewarpok kezelése szempontjából.
Hogy ez az egész érthetőbb legyen, érdemes leírni, hogy a virtuális valóság teljesen más követelményekkel rendelkezik, mint egy normál, fogalmazzunk úgy, hogy monitoron történő szórakozás. Egyrészt a képkocka/másodpercre vonatkozó értékek részben irrelevánsak lesznek. A virtuális valóságban állandó a vertikális szinkron, vagyis arra van szükség, hogy legyen minden másodpercben megfelelő mennyiségű elkészült képkocka. Az Oculus Rift esetében ez például 90-et jelent, hiszen a szemüveg 90 Hz-en frissít. A vertikális szinkron miatt azonban kialakul egy szinkronablak, vagyis – maradva az Oculus Rift hardverének vizsgálatánál – muszáj 11,1 ezredmásodpercen belül új sztereó 3D-s képkockát számolni. Ebben az lesz a nehézség, hogy ha jó minőséget akar a fejlesztő, akkor az említett időkereten belül a sztereó 3D következtében két darab 1920x1080 pixeles képkocka kell, ráadásul négymintás MSAA és mellette még szintén négymintás SSAA élsimítással, plusz szükség van még némi utófeldolgozásra is.
Rögtön észrevehető, hogy az igények miatt a nyers erőre alapozni tévút lesz, és itt jön képbe az Oculus korábbi felfedezése, hogy valójában a virtuális valóságnál csak folyamatosság kell, és nem feltétlenül szükséges minden képkockát különálló jelenetből számítani. Sőt elég minden második képkockát a nulláról kalkulálni, vagyis effektíve 45 jelenetet kap a felhasználó másodpercenként, és a hézagokat az előbbi említett timewarpok töltik ki. Ez ugyan nagymértékű trükközés, de a gyakorlatban fantasztikusan működik, tehát a végeredmény tekintetében helytáll a koncepció.
A timewarpok számítása viszont teljes egészében a grafikus vezérlő feladata, méghozzá az előző képkocka adataira építve. A jelenet természetesen nem változik, de a számításhoz a grafikus vezérlő kap egy új fejpozíciót, hogy az eredeti képkocka adataiból számoljon egy olyan sztereó 3D-s képet, amely elmozdul az új fejpozíciónak megfelelően. Ez teljes egészében compute feladat, de minden előnye ellenére vannak problémák. Ahhoz, hogy ez működjön, aszinkron módon kell futtatni a timewarp kalkulációját az éppen számolt, tényleges új jelenetre épülő képkockával. Innen is kapta az asynchronous timewarp nevet. Ehhez viszont igen modern architektúra kell, mert a korábbi grafikus API-k sosem követelték meg a grafikus vezérlőtől, hogy az egyes futószalagokat párhuzamosan futtassák. Ezek most szép sorban megérkeznek a hardverre és egymás után lefutnak. Ennek megfelelően alig van olyan grafikus architektúra a piacon, amely tényleg úgy lett megtervezve, hogy képes legyen egymás mellett futtatni egy grafikai és egy compute futószalagot, ráadásul tegye ezt tényleg hatékonyan.
A cikk még nem ért véget, kérlek, lapozz!
