Az elmúlt verziókban elképesztő mértékű fejlődésen ment keresztül a Shader Modell szabvány és a HLSL (High Level Shader Language) programnyelv. Az 5.0-ás verzió nem igazán bővíti tovább a lehetőségeket, hiszen a mérce már amúgy is igen magasra lett tolva. Ellenben egyszerűsíti a programozók feladatát, hiszen objektumorientált lett a nyelv. Ez a változás a felhasználóknak jelentéktelennek tűnhet, de érdemes belegondolni, micsoda előrelépés a fejlesztőknek. A mai programok rengeteg eltérő kódot alkalmaznak az adott fényhatást figyelembe véve a különböző paramétereknek megfeleltethető felületekre (legyen az virtuális fém, műanyag, fa, üveg vagy szövet). A szekvenciális alapokon nyugvó, korábbi verziójú HLSL nyelvekben ezeket a fény-anyag kölcsönhatásokat kétféleképpen kódolhatták le a programozók. Az egyik megoldás, hogy a grafikus motor összes lehetséges árnyalási metódusára egy külön shader programot kell futtatni. A mai, korszerű grafikát kezelő rendszerek mellett azonban ez nagyon sok kis programot eredményez, hiszen tucatnyi megkülönböztethető felület létezik, emellett az eltérő fényhatásokból is bőven akad.
Shader Modell 5.0
A fentebb említett öt, anyagokra vonatkozó példa három fénytípussal kiegészítve (például: körsugárzó, pont és direkt) rögtön 15 darab programot generál, ami már elég ahhoz, hogy az esetleges hibák kereséséhez és javításához aránytalanul magas időigény járuljon. Arról sem szabad megfeledkezni, hogy shader programok folyamatos generálása a hardver szempontjából is időbe telik. Ennek elkerülésére alkalmazták eddig a fejlesztők az übershadernek gúnyolt programokat, mint alternatív megoldást. A helyzet azonban alig átláthatóbb, mivel egy shader programba kell az összes kódot írni, nem kevés feltételes elágazás használatával. Az objektumorientáltság azonban jelentősen egyszerűsíti a fejlesztők dolgát, hiszen a programegységeket egy előre megtervezett hierarchiának feleltethetik meg. Interfészként megadható a felület és a fényhatás, melyben a tagfüggvények, azok tulajdonságai és bemenő paraméterei találhatók. Az osztályok pedig a függvényeket és a változókat tartalmazzák. Ennek megfelelően a hibakeresésre fordított idő jelentősen redukálódhat.
Textúratömörítés
Két új textúratömörítési eljárás került az új API-ba. Ennek nagy jelentősége van a mai programok mellett, hiszen a nagyfelbontású textúrák komoly helyigénnyel rendelkeznek a memóriára nézve. Ezen kívül a DirectX 11 már megköveteli a hardveres kitömörítést is az összes támogatott formátumra. A BC6 (Block Compression) a HDR (High Dynamic Range) alkalmazása mellett használható. Ilyen esetekben ugyanis a fejlesztők sokszor alkalmaznak Tone mapet a kép színátviteli görbéjének állítása miatt. A BC6 6:1 arányban tömöríti a képkocka HDR adatait, ami némi veszteséggel jár ugyan, de a végső eredmény rendkívül meggyőző.
BC6 textúratömörítés a gyakorlatban
A BC7 az úgynevezett LDR (Low Dynamic Range) formátumú textúrák alkalmazása mellett lehet alternatíva. Nagyon jó képminőséget eredményez az eljárás 3:1-es RGB (vörös, zöld, kék), illetve 4:1-es RGBA (vörös, zöld, kék, átlátszóság) tömörítési arány mellett. A fenti két textúratömörítési eljárást lehetőség van a driver szintjén emulálni, így a támogatás kiterjeszthető a DirectX 10-es hardverekre is. Természetesen a hardveres kitömörítés itt nem lesz alkalmazható, így a sebességre nézve negatívan ható felárat kell majd érte fizetni.
Többszálúság támogatása
Nem nevezhető meglepetésnek, hogy a DirectX API is rálépett a Multi-Threading, azaz a többszálú feldolgozás kissé döcögősen járható útjára. Szerény véleményem szerint ennek már hamarabb meg kellett volna történnie, hiszen meglehetősen problémás, hogy a piac legelterjedtebb grafikus API-ja a többmagos processzorok korában még mindig csak egy programszálon renderel. Az új API-ban az objektum megrajzolásához szükséges rajzolási parancs és az effektek létrehozásánál bekövetkező állapotváltások már több szálon lesznek kezelve. Ahhoz, hogy ez működésben megfelelően ki legyen használva, a Direct3D 11-es erőforrást az azonnali és a halasztott tartalom szintjére kell felosztani. Az azonnali tartalom egy programszálat takar, és olyan kész objektumokat tartalmaz, melyek sorrendben átadhatók a grafikus processzornak. A halasztott tartalom központi processzor által történő feldolgozása már több szálon történik. Minden egyes ilyen szál tartalmaz egy listát a saját objektumairól, így lesz ellenőrizve, hogy a számítás elvégzése megtörtént-e. Amint kész a feladat, a halasztott tartalom behívásra kerül az azonnali tartalomba. Jó hír, hogy a rendszer működése az API szintjén változott meg, így nem szükséges hardveres módosítás a problémamentes feldolgozáshoz. Ez azt jelenti, hogy a Windows Vista operációs rendszerben bemutatkozó WDDM (Windows Display Driver Model) és a megfelelően felépített eszközmeghajtók mellett bármelyik, minimum DirectX 10-kompatibilis grafikus kártyával használható az új feldolgozási elv. Azt persze érdemes megemlíteni, hogy a fő feldolgozási szál továbbra is túlterhelhető, tehát a tökéletes eredmény eléréséhez a fejlesztőnek is optimalizált eljárásokat kell alkalmaznia.
További változás még a DirectX 11-ben, hogy a maximum alkalmazható textúraméret akár 16384x16384 pixeles is lehet. Ezenkívül a Conservative oDepth eljárás segítségével akkor is lehet a Depth Bufferbe írni, ha az Early Z check és más, úgynevezett Z gyorsítási funkciók nincsenek kikapcsolva.
General-Purpose GPU és a fizika
Az NVIDIA és az AMD jó ideje tolja a grafikus processzoron történő általános számítási feladatok szekerét. Az egész elképzelés azon a tényen alapszik, hogy bizonyos, nagymértékben párhuzamosítható számítási feladatokban a központi processzorok teljesítménye messze le van maradva a grafikus processzorokéhoz képest. Mindkét nagy GPU-gyártó cég rendelkezik a termékeik képességeihez igazított programozási interfésszel. A zöldek ezt CUDA-nak, míg a vörösek Stream SDK-nak nevezték el. A fejlesztőknek viszont sokkal fontosabb lenne egy olyan szabványos GPGPU API, amelyet mindkét cég maximálisan támogat. Ezzel a lépéssel jelentősen megkönnyíthető lenne a grafikus processzoron futtatható programok fejlesztése, hiszen nem kell két eltérő interfészre megírni a projektet. Jelen állás szerint a feladat betöltésére két versenyző esélyes. Az egyik jelentkező a Khronos Group által fejlesztett OpenCL (Open Compute Language), míg a másik a DirectX 11-ben bemutatkozó Compute Shader technológia.
Az OpenCL elsősorban az APPLE támogatását élvezi, és várhatóan a legtöbb operációs rendszeren elérhető lesz. Az NVIDIA-val ellentétben az AMD nagyon szoros kapcsolatban van a fejlesztőkkel, ami vélhetőleg annak köszönhető, hogy a riválisaihoz képest előnyösebb pozíciót akar kiharcolni a platform irányelveinek meghatározása szempontjából.
NVIDIA Cuda
A Microsoft Compute Shader a DirectX 11 része lesz, így nem nehéz kitalálni, hogy csak a Windows rendszereket fogják támogatni. A fejlesztés a főbb gyártók bevonásával zajlik. A Redmondi óriáscég nagy reményeket fűz a technológiához; a fő cél elsősorban olyan programok létrehozása, ami a játék fizikájára, mesterséges intelligenciájára és a grafikai minőséget nagymértékben javító effektekre van kihegyezve.
A jelenleg is elérhető GPGPU interfészek közül a CUDA a legkidolgozottabb. Az AMD azonban az esetleges támogatásra nemet mondott a zöldeknek, így borítékolható, hogy a rendszer a jövőben a szükséges támogatás hiányában nem fogja felvenni a versenyt az általános API-kkal szemben. Megjegyzendő azonban, hogy ha a Santa Clara-i cégnek sikerülne valamelyik következő generációs konzolba egy GeForce GPU-t passzírozni, akkor az a CUDA helyzetét meglehetősen pozitív irányba befolyásolná.
Fizika a játékokban
Ezen a területen nagyon kényes a helyzet. Ha a fejlesztők előre megírt rendszert akarnak használni, akkor két lehetőségük van. Választhatják az NVIDIA Ageiatól megvásárolt PhysX technológiáját, vagy az Intel Havokot, amelyet az AMD is támogat. Mindkét rendszer kellően nagy támogatottsággal rendelkezik, és ami a legfontosabb, elérhetőek Xbox 360 és PlayStation 3 konzolra is. A PC-n meglátásom szerint a PhysX némi előnyre tett szert, bár ez viszonyítás kérdése, de a GPU-alapú gyorsítás lehetősége semmiképp sem elhanyagolható tényező. Az Ageia felvásárlása után egy általános zűrzavar alakult ki, az NVIDIA ugyanis nem igazán magyarázta el, mi kell ahhoz, hogy a program a grafikus processzort használja a fizikai számításhoz.
A PhysX technológiát kétféle licensznek feleltették meg a karrierje kezdetén. A különbség abban merült ki, hogy a teljes licenszhez olyan speciális, Novodex API kiterjesztések tartoztak, amelyek lehetővé tették a fizika számítását az Ageia PhysX P100 elnevezésű gyorsírókártyán. Az elkészült programokat ebből a szempontból tehát két részre lehet osztani. Az egyik hányad csak a központi processzort használta a feladatok kalkulálására, míg a többi termék a fizikai gyorsító processzor segítségét is igénybe vette, amennyiben a felhasználó rendelkezett a szükséges hardverrel. A CUDA-kompatibilis NVIDIA termékek jelenleg csak azokat a programokat képesek gyorsítani, amelyek a teljes licenszes NOVODEX API-t használták a számításokhoz. Az éppen készülő projektekkel már más a helyzet, a PhysX technológia régóta ingyenes, így az adott cég megújíthatja meglévő korlátozott licenszét teljes támogatásúra. Minden fejlesztőnek mérlegelnie kell, hogy érdemes-e az előbbi lépést megtenni. Jelent-e komoly változást az ütemtervben az extra támogatás beépítése? Természetesen a felhasználókat az a kérdés érdekli a legjobban, hogy milyen esetekben tudják hasznosítani a GeForce grafikus rendszer fizikai számításra alapozó extra képességeit. Ha az adott program teljes licensszel rendelkezik, akkor lényegében mindig.
Az igazsághoz azonban hozzátartozik, hogy sok esetben nincs értelme a fizikát a grafikus processzoron számítani, egyszerűen nincs komoly haszna az eredményeket tekintve. Példának érdemes az Unreal Tournament 3-at felhozni. Ez a játék minden esetben kihasználja az NVIDIA PhysX lehetőségeit, ellenben nem árt megfigyelni, hogy csak akkor van komoly sebességnövelő hatása a technikának, ha a pálya fizikai komplexitása meglehetősen magas. Az eredeti, PhysX rendszert nem igazán használó pályákon a teljesítmény a grafikus rendszeren történő fizikai számítás hatására elenyésző mértékben növekszik. Ezen a ponton lépnek be a képbe a konzolok. Az Xbox 360 és a PlayStation 3 a PhysX technológiát csak a központi processzoron képesek futtatni, ami limitálóan hat majd a jövőben megjelenő játékok fizikai összetettségére. Emellett tovább rontja a helyzetet, hogy a fizika szerves része a játékmenetnek, így annak butítása, illetve feljavítása komoly aggályokat vet fel. Abban az esetben sem javulna a helyzet, ha az AMD belépne a PhysX-et erősítő cégek táborába, hiszen ha valami nem működik megfelelően konzolon, akkor jelenleg nagyon kicsi a PC-s támogatás esélye.
Voxel space és ray-tracing
Az utóbbi időben igen parázs vitákat vív egymással az Intel és az NVIDIA. Ennek elsősorban az Intel Larrabee nevű fejlesztése az oka. Ez a chip több általánosan programozható és viszonylag egyszerű felépítésű processzormagot tartalmaz, ami teljesen új koncepció a grafikus kártyák piacán. A kékek nyilvánvalóan termékük tökéletességét hirdetik, míg a zöldek elég negatív nyilatkozatokkal hívják fel a figyelmet az eszköz hibáira. Az AMD hivatalos véleményét nem lehet tudni, ők ebben a nyilatkozatháborúban inkább csak külső szemlélőként vesznek részt. A Larrabee megjelenéséig még legalább két év van hátra, de már most világossá vált a csatában résztvevő cégek vezetői számára, hogy a vesztes nagy árat fog fizetni. Az NVIDIA teljes mértékben kiáll a DirectX logikai futószalagja mellett, ami nem csoda, hiszen a felépített GeForce birodalomban majd egy évtized munkája van benne. Az Intel kvázi új szereplő lesz az önálló grafikus kártyák piacán, így alapvetően a befektetett pénzen kívül minimális a vesztenivalója. Az AMD egyfajta kakukktojásnak tűnik a harcban, ugyanis nekik alapvetően mindegy, merre halad tovább a kor, hiszen technológiáikkal mindkét irányvonal kényelmesen követhető. Az NVIDIA ellen tökéletes fegyvert jelentenek jelenleg az R600 mikroarchitektúrára épülő termékek, míg az Intel ellen egy megfelelően felépített Fusion rendszer vehetné fel a harcot. Nehéz megjósolni, hogy mit hoz a távolabbi jövő, de mindenképp kiindulhatunk egy-két vezető fejlesztő elképzeléséből, és a jelenlegi renderelő futószalag esetleges gyenge pontjaiból.
A render futószalag változásai
Érdemes a mellékelt képre vetni egy rövidke pillantást. Az ábra azt vázolja fel, hogy kezdetben minden grafikai program egy szoftveresen definiált renderelő futószalagot használt. A számítások teljes egészében a processzort terhelték. A DirectX futószalagja tulajdonképpen egy előre definiált render. Az alapjai az 1992-ben megjelenő IrisGL-re épülő OpenGL API-ban bemutatott szerkezetnek feleltethetők meg. A logikai felépítése modellezés esetén geometrikus traszformációkra épül, míg a leképzésre a raszterizálást használja. Ez a struktúra a mai napig nem változott, csak egyes elemei bővültek a kornak megfelelően. A DirectX 11 felépítése pedig már feszegeti a fenti két eljárás elméleti határait. A geometrikus transzformációkra épülő modellezés a tesszellátor bevezetésével gyakorlatilag elérte fejleszthetősége csúcsát. Talán egy apró lépcsőfokot jelenhet még az egyénileg definiálható tesszellációs algoritmusok bevezetése, de ez igazából nem számítana kiemelkedő ugrásnak a jelenlegi fix funkciós egységhez képest.
Persze nem feltétlenül kell a modellezésnek a geometrikus transzformációkra építeni, mert van más megoldás is, melynek neve Voxel Space. A közhiedelemmel ellentétben a messze nem újkeltű eljárást jelenleg elsősorban az orvosi képfeldolgozásnál használják. A játékok szempontjából régebben lehetet voxeles rendszerrel találkozni. Hogy példa is legyen szem előtt, az Outcast nevű játék ezt az eljárást használja, emellett érdemes megemlíteni Ken Silverman
Voxlap nevű motorját is. De mi is a voxel definíciója? Tulajdonképpen a virtuális térfogat egyfajta elemi egysége, ahogy a pixel a kép területének a legegyszerűbb megközelítése. A név is innen ered: Volumized Pixel. Voxelnek a 3D-s motorban előre definiálhatót szélessége, magassága és mélysége van; minél kisebb ennek az egységnyi értéke, annál jobb lesz a grafika, viszont a teljesítményigény is ennek megfelelően növekszik. A technika nagy előnye, hogy a poligonhoz képest sokkal kevesebb adatmennyiséget kell tárolni. Nagyon jó alkalmazási területe a Voxelnek a terep kirajzolása, ugyanis tökéletesen leképezhetők vele a barlangok és más kiálló ívek, emellett a technológia alapjai miatt viszonylag kevés erőforrásigénnyel még rombolhatóvá is lehet tenni a virtuális térséget. Általános probléma azonban, hogy a közelben lévő voxelek esetenként nagy kockákat eredményezhetnek. Hasonló a jelenség az aliasing problémához, mely a pixelekből felépülő képeknél fedezhető fel. Ennek csillapítására számtalan kis trükk létezik. Legegyszerűbb megoldás, ha a pixel színének meghatározásához nem csak a hozzá tartozó, hanem a környező voxelek értékeit is figyelembe vesszük.
Sugárkövetés
Az Intel Larrabee bemutatók visszatérő anyaga. A sugárkövetés, idegen szóval ray-tracing a raszterizálás riválisának tekinthető. Technikailag a ray-tracing előnye, hogy nem csak poligon alapú felületekkel képes dolgozni. A számítás szempontjából csak az az információ számít, hogy a fényforrásból kiinduló sugár hol metszi az adott objektumokat. A ray-tracing lényege, hogy a virtuális térben leírt környezetből a fénytan törvényeihez hasonlóan történik a képkockák leképzése. A fénysugarak útját a fényforrásból kell addig nyomon követni, amíg az a nézőpont irányában át nem halad a kép egyik pixelén. Közben persze rengeteg interakció történhet a virtuális térben, így a számításnál figyelembe kell venni, hogy a sugár milyen objektumoknak ütközik neki, és azok a fény mely részét tükrözik vissza, nyelik el vagy eresztik át. Ezen a ponton rögtön található egy nagy probléma: közel sem biztos, hogy a fényforrástól követett fény valaha is eléri a képernyőt. Éppen ezért teljesítmény szempontjából sokkal kifizetődőbb, ha az egész eseménysorozatot visszafelé követjük, azaz a képernyő minden pixeléből a nézőpontnak megfelelően indítunk sugarakat. Ezt backward ray-tracingnek nevezzük.
A feldolgozás menete röviden úgy zajlik, hogy a nézőpontból az adott pixelen át kilőtt sugarat vagy sugarakat (bilineáris vagy jobb minőségű szűrés esetén) követjük az eltalált felületig, majd a beesési pontból újabb sugarak indulnak ki a tükröződések, a fénytörések, illetve a fényforrások irányába. Ha az új sugarak által eltalált felület tükröző vagy áttetsző, akkor megint újabb sugarak indulnak ki az előzőeknek megfelelően. Rögtön észrevehető, hogy rengeteg kis sugár lesz a jelenetben. A számítás legkínosabb pontja a pixel végső színének meghatározása, ami a fényhez irányuló sugarak felülettel bezárt szöge alapján történik. Itt bizony a mai rendszerek számítási teljesítmény szempontjából elhasalnak. Arról nem is beszélve, hogy a különböző virtuális anyagok másképp reagálhatnak a fényre, így az árnyalási modelleket sem szabad figyelmen kívül hagyni. Alapvetően elmondhatjuk, hogy a ray-tracing a raszterizálásnál jobb képminőséget állíthat elő, de nagyságrendekkel magasabb teljesítményigénnyel rendelkezik. A manapság használt raszteres grafika a shaderekkel kiegészítve ugyan az esetek többségében egyfajta utánzott (csúnyán fogalmazva fake) eredményt kelt, de összhatásban rendkívül ütőképes.
Példák, konklúzió
Példákkal előállva az alábbi képet 14 darab Sony Cell processzor számolja (egy ilyen processzor található a PlayStation 3-ban) épphogy folyamatos sebességben, Full HD felbontásban.
Érdemes még az NVIDIA demonstrációját is megnézni, egy Quadro Plex 2100 D4 rendszer eredményét, amelyben négy darab G92-es (a GeForce 8800 GT alapja) chip teljesít szolgálatot fejenként 1 GB memória társaságában. A sebesség szintén folyamatos Full HD felbontásban.
A fenti két példához még mindenképp hozzátartozik, hogy a jelenet minden esetben statikus volt, ami messze nem felel meg a játékok által támasztott igényeknek. Egy interaktív, háromdimenziós program dinamikus jelenetet eredményez, amiben az objektumok helyzete folyamatosan változik. Ez megköveteli a használt térrendező fa újragenerálását, ami további időveszteség.
A valós idejű sugárkövetés a fellelhető információk alapján bizony nagy falat lesz még a belátható időn belül megjelenő hardvereknek is. Természetesen a raszterizálásnak is vannak határai, hiszen az eljárás hatékonysága egyenes arányban csökken a jelenetben használt poligonszám növekedésével. Ez a távoli jövőben még a ray-tracing előnyét is eredményezheti. Ha azonban időponthoz akarjuk kötni ezt a dolgot, akkor még mindig minimum egy évtizedes időtávot érdemes feltételezni. A Larrabee dokumentációkon nagy valószínűséggel azért kapott a technika kiemelt figyelmet, mert a nagyméretű chip feltételezhetően raszterizálásban nehezen veszi fel a versenyt a konkurens GeForce és Radeon modellekkel. Ez persze messze nem azt jelenti, hogy az Intel projektje kudarc lesz. Számtalan területen megvillanthatja még tudását a rendszer. Talán érdemes megjegyezni, hogy az előzetes beszámolók birtokában John Carmack (ID tech 6) és Tim Sweeney (Unreal Engine 4) éppen fejlesztett motorjai bizony visszatérnek a szoftveres renderelés vonalára. Célplatformnak a 2012-2014 körül megjelenő, következő generációs konzolok vannak megadva, de biztosra vehető, hogy a PC-n is lehet majd találkozni a két rendszerrel. Márpedig a szoftveres render a Larrabee malmára hajtja a vizet.
Larrabee technikai demó
Az elmúlt években sok változáson ment keresztül a számítógépes grafika fejlődése, és az elkövetkező időszakokban várhatóan hasonló ütemű fejlődésre lehet számítani. Egyértelműen látszanak egyes cégek úgymond reformtervei. Ettől függetlenül fontos szem előtt tartani azt, hogy a felhasználók többsége elsősorban nem a vásárlandó kártya mögött rejlő technológiát nézi, hanem a jelenben felmutatott értékeket. Ennek ékes példája volt az AMD Radeon HD 2900 nevű próbálkozása, mely közel másfél évvel megelőzve korát technológiailag fasírtot készített a GeForce 8800 sorozatból. A termék azonban mégsem lett sikeres, ami annak köszönhető, hogy nem tudott megfelelni az akkoriban támasztott követelményeknek. Persze az architektúra fejlettségére alapozó AMD az új termékcsaládokkal most kamatostul kapja vissza azt, amit akkor elveszített. Ha egy elvont párhuzamot vonunk a Larrabee rendszerére nézve, akkor láthatjuk, hogy az Intel grafikus elképzelése bizony négy évvel is megelőzheti korát, már ha a 2010-re ígért megjelenés valós adat. Ez nagyon meg fogja nehezíteni a kékek szereplését a GPU-piacon. Szerencsére a Larrabee kellően univerzális termék ahhoz, hogy több piacon is szerepeltessék. Érdemes megfigyelni, hogy az Intel elképzelései mennyire újszerűek, és az eddigi megoldásokkal összehasonlítva komolyan megváltoztathatja a jelenleg elterjedt logikai futószalagot. Ha a piac a kékek terveinek megfelelően formálódik, és kedvező körülmények alakulnak ki az eszközük képességeihez, akkor komoly sikerekre számíthatnak. Fennáll azonban annak az esélye, hogy megosztott lesz az új technológiákról a fejlesztők véleménye.
Bejegyzések
