Számtech-tévhitek: Mi a baj a DirectX-szel?

Manapság nagy nyüzsgés van a 3D grafikus API-k témájában, mivel egy régóta jelenlévő probléma mostanában elérte azt a pontot, ahonnan nincs tovább nagyobb reformok nélkül. A reformot az AMD indította el a Mantle nevű API-val, aminél a cél az volt, hogy belerúgjanak a régóta Pató Pál úr módban („Ej, ráérünk arra még!”) üldögélő Microsoftba, és ez nagyon jól is sikerült. Ez a lépés persze nem volt előzmény nélküli, a játékfejlesztők hosszú ideje „sírnak” a jelenlegi grafikus API-k pazarló és korlátozott működése miatt.

A 3D grafikus API egy köztes réteg a szoftver és a hardver között, ami arra szolgál, hogy a grafikus processzorokat egységes módon lehessen programozni (elméletben, mert gyakorlatban sajnos nem mindig jön össze), lehetőleg egyszerűen, és nagyjából platformfüggetlenül. Hiszen a grafikus processzorok gépi kódja, szinte generációnként, teljesen megváltozhat, és a különböző GPU-gyártók is egész más utasításkészletet használnak, ellentétben a CPU-k viszonylag stabil utasításkészleteivel. A 3D API utasításait a grafikus driver fordítja le az adott GPU számára legmegfelelőbb gépi kódra, ezért nagyon fontos a driver minősége a hatékonyság szempontjából, és ezért jellemző az, hogy a népszerűbb játékokra külön optimalizálják az illesztőprogramokat.

API történelem

Az első jelentősebb 3D grafikus API az OpenGL volt, amelynek első változata 1992-ben jelent meg, viszont csak 1997-ben jött ki az első „stabil”, 1.1-es verzió. Ez azonban nem azt jelenti, hogy az előző változatok állandóan lefagytak volna, vagy hasonló. A szoftvereknél a „stabil” jelző azt jelenti, hogy az a kiadásra szánt verzió, ami már túl van a tesztelésen.

Az OpenGL 1992 óta van velünk, és sokáig remek
alternatívát nyújtott a DirectX-szel szemben

Közben a Microsoft sem tétlenkedett, hiszen megalkotta a DirectX-et, amely egyébként egy játékfejlesztés segítő csomag volt, hiszen a 3D API-n kívül (Direct3D, vagy D3D), tartalmazott egyéb részprogramokat is a játékoknál jellemző többi programozási feladat egyszerűsítése érdekében, úgy mint DirectSound (hangok), DirectPlay (hálózat, multiplayer), DirectInput (játékvezérlők), és így tovább. Mégis a 3D grafikára ragadt a DirectX név, bár igaz, hogy a Direct3D-n kívül mára az összes többi DirectX részegység eltűnt, (vagy csak simán elavulttá vált), így most már tényleg egyenlő a DirectX a D3D-vel.

Vannak olyan feltételezések, miszerint a Microsoft a DirectX-et eleinte arra szánta, hogy elhúzza a mézesmadzagot a játékfejlesztők előtt, és a játékosokkal együtt Windows platformhoz láncolja őket. Ennek lehet alapja, tekintve, hogy a 3D grafikában az OpenGL sokkal jobban muzsikált a korai időkben, hiszen gyorsabb volt, és bizonyos játékok szebbek is voltak vele, amit könnyű volt összehasonlítani, hiszen a 2000-es évek középéig gyakori volt, hogy a játékok több API-t támogattak. Ez természetesen megváltozott, ahogy a D3D terjedt, elsősorban a Microsoft meggyőző erejének köszönhetően, és a GPU gyártók egyre kevesebbet törődtek az OpenGL driverekkel, legalábbis a „Wintel” platformon. Más platformokon viszont mindenhol az OpenGL maradt az etalon, mostanáig.

Az idősebb játékosok számára ismerős lehet még egy grafikus API: a Glide, ami a 3Dfx saját, alacsonyabb szintű, hardverközeli megoldása volt (olyasmi, mint ma az AMD-nek a Mantle). A 3Dfx és a Glide nevek nagyon jól csengtek akkoriban, hiszen a Glide-os játékok sokáig szebbek voltak mint a D3D-s vagy OpenGL-es változatok, így nagy dolognak számított, ha valakinek volt egy 3Dfx Voodoo kártyája. (A 3Dfx-szel egyébként mi is foglalkoztunk egy külön cikkben, az érdeklődőknek erre tessék!)

DirectX tévhitek, és legendák

Az évek során elterjedt pár tévhit a DirectX (D3D)-vel kapcsolatban, egyesek már egy mágikus, természetfeletti dolognak hiszik, amit úgy alkotnak a semmiből, a GPU-gyártók meg követik. Pedig ez épp fordítva van: a GPU-gyártók találnak ki újabb és újabb hardveres és szoftveres okosságokat, majd jó esetben megegyeznek egymással és a Microsofttal, amely inkább moderátori szerepet vállal, pár javaslattal.

A DirectX 12 a Windows 10 egyik nagy találmánya lesz,
ami remélhetőleg a játékok fejlődésének is jót tesz majd

Tehát egy új D3D verzió megalkotása nem úgy zajlik, hogy az MS-nél mondanak valamit, és akkor az biz úgy lesz. Attól függetlenül, hogy mi, végfelhasználók azt látjuk, hogy megjelenik egy új D3D verzió, és a hardvert még nem lehet kapni hozzá, az a hardver már rég kész van, maximum még nincs sorozatban gyártva, vagy éppen készletet halmoznak fel a hivatalos kiadási időre.

Másik jellemző tévhit, hogy az új D3D verzió új hardvert igényel, pedig ez nem feltétlenül igaz, sőt eleinte egyáltalán nem volt igaz. Akkor kell új hardver hozzá, ha olyan alapkövetelményei vannak, ami nélkül régebbi hardveren egyáltalán nem tud működni az új API-ra írt program. Például a D3D 12-nek sem kell új hardver, hiszen főleg szoftveres változásokat hoz, bár hozzácsapták a legújabb hardveres képességek támogatását is, ezek azonban opcionálisak, és teszem azt a több éves AMD GCN architektúrára épülő GPU-k maradéktalanul támogatják.

Ott van még az is, hogy egyesek szerint, még ha a képességek támogatottak is, új D3D-re nagyobb teljesítmény kell. Holott egyáltalán nem. Az utóbbi években az újdonságok mindig a hatékonyság növelését célozták, a 12-es verzió pedig szinte kizárólag erről szól.

Az, hogy idő közben a fejlesztők egyre több olyan módszerre jöttek rá, amivel a felszabaduló számítási teljesítményt el tudják használni látványos és kevésbé látványos effektekre (járda alatt hullámzó tenger, több ezer háromszögre bontott síkfelületek, amelyek pontosan úgy néznek ki, mintha két háromszögből állnának), vagy épp arra, hogy nehogy megszakadjanak már a lázas optimalizálgatásban, már más kérdés. Ugyanaz a grafika, ugyanolyan részletességgel, új D3D verzióra átültetve szinte biztos, hogy jobb teljeítményt eredményez.

Problem?

Na de mi történik ma, mi ez a mozgolódás, mi ez a DirectX 12, Mantle, Vulcan, Metal? Mint már fentebb írtam, egy régóta jelen lévő probléma váltotta ki a változásokat, végre-valahára, laza 15 évvel a felmerülése után.

Az ominózus probléma egyik része, hogy a grafikus API-k és a hozzájuk tartozó driverek túl sok feladatot végeznek automatikusan, ami elsőre jól hangzik, de másodjára már nem annyira, mivel erősen korlátozza a fejlesztők lehetőségeit, és a hardver hatékony kihasználását. A másik gond pedig az, hogy ezek ez automatizált feladatok erősen igénybe veszik a CPU-t, sajnos azonban többnyire egy szálon, így eredményezve az unalmas „kihajtja-e?” kérdést.

Egy példa: a mai grafikus API-kkal egy modern, átlagos PC-s processzor egyetlen processzormagja teljes leterheléssel nagyjából 3000 rajzolási hívásnál tud 60 fps-t biztosítani (tehát kb. 180 ezer rajzolási hívás másodpercenként, hiszen minden egyes képkockánál el kell végezni a teljes feladatot). 3000 fölött elkezd esni a képsebesség, létrejön a CPU-limit. 3000 fa a tájon pedig nagyobb látótávolságnál eléggé szegényesnek tűnne, és még sehol sincsenek az egyéb tereptárgyak. Mivel a zárt világú játékokban (pl „cső” FPS) nem látunk el túl messzire, ezért ezeknél nem jellemző a CPU-limit, ergo szinte mindig a GPU teljesítménye a korlátozó faktor. Viszont a nyílt játékokban, nagy látótávval a GPU limit olyan, mint a fehér holló. A szimulátorosok ismerhetik az ilyenkor jellemző „tök mindegy, mit állítok a grafikán, csak a tárgysűrűségtől és a látótávtól függ az fps” problémát.

Erre kitaláltak olyan trükköket, mint az „instancing”, ami a GPU-nak egy tárgyat csak egyszer küld el az összes példány játékvilágbeli koordinátáival együtt, így a fent említett 3000 fát 3000 helyett egy rajzolással el lehet intézni. Viszont itt az újabb probléma: 3000 teljesen ugyanolyan tereptárgy kissé unalmas lenne, különböző tárgyaknál pedig újra elkezd szaporodni a rajzolási hívások száma. Erre is találtak egy kényszermegoldást, mégpedig a „draw call batching” nevezetű eljárást, ami sok különböző objektumot egybegyúr, így egy rajzolási hívással lehet kirajzolni az összeset. Azonban ennek is megvannak a korlátai, ugyanis bonyolult leprogramozni, és csakis azon tárgyak között működik, amelyek ugyanazt a shadert és textúrát, összefoglaló nevén materialt használják, és animálva sem lehetnek.

Ezen eljárás hatékonyságán a megatextúrázás hivatott segíteni, bár ezt hardveres támogatás híján az id Software-nek PC-n nem igazán sikerült bemutatnia. Igaz, hogy idő közben a hardveres támogatás is összejött, viszont az új grafikus API-kkal az egész batching-téma feleslegessé vált, így a megatextúrázás is. Azért nem volt hiábavaló fáradozás, mert bár az új API-k segítségével a már említett 3000 rajzolási kérés helyett százezres nagyságrendnél lesz a határ, de előbb-utóbb ezt is elérik a fejlesztők, és akkor újra szükség lehet a már említett trükkökre. Ugyanakkor tény, hogy az új API-k rugalmasabbak, így ahogy közeledik a processzormagok száma a dinnyében található magok számához, úgy emelkedik az említett határ is.

Ne hívogassál, rajzoljál!

A játékfejlesztők mindent megpróbáltak (már a lelkiismeretesebbek), de nincs tovább. Az MI, fizika, hangok és a többi már évek óta külön szálat kapnak a játékokban, ám a jelenlegi 3D API-k rajzolási processzorterhelése az előbbieket együttvéve is jelentősen túlszárnyalja (például a CPU-használat 70 százaléka a rajzolásra megy el, a maradék 30 százalék az összes többi feladatra). Több szálra nem lehet osztani a feladatot, a processzorokban pedig évek óta inkább a magok szaporodnak, és nem a magonkénti teljesítmény, így tehát nincs mese, új alapokra épülő, alacsonyabb szintű, közvetlenebb hardverelérést biztosító grafikus API-ra van szükség, ami kiválóan skálázódik több processzormagra, és összességben is kisebb a processzorhasználata.

Az AMD Mantle (ma már Vulcan) a processzorok tehermentesítését
tűzte ki céljául, de még nem sokan támogatják

Ilyen lett a Mantle, ami idő közben Vulcan néven kisebb módosításokkal folytatja pályafutását, immár multiplatformként és nyílt forráskóddal, és jön a DirectX 12 is a Windows 10 mellé, ami szintén hasonló alapokon nyugszik, na meg az Apple is összerakta a saját Metal API-ját, ami egyelőre csak az iOS-en érhető el.

Ám ennek a közvetlenebb hardverelérésnek megvan az árnyoldala is: a nagyobb szabadság nagyobb felelősséggel jár, hiszen a játékfejlesztőnek kell olyan feladatokat megoldani, amilyeneket eddig a 3D API és a driver végzett, úgymint a memóriakezelés vagy a több GPU támogatás. Így a játékok 3D-s kódjában lévő bugok már nem csak szaggatást, belassulást, asztalra kidobást okozhatnak, hanem akár kékhalált is. Emellett még több lehetőség lesz arra, hogy az egyik GPU-gyártó ösztönzésére olyan hibákat „felejtsen” a programban a fejlesztő, ami egész véletlenül a másik gyártó termékein okoz galibát – habár mivel a driver kisebb szerepet játszik és egyszerűsödik, kevésbé tudják a trehány fejlesztők a GPU-gyártókra és a driverre kenni a felelősséget. Ettől függetlenül a hagyományos API-k nem fognak eltűnni, mert a kisebb fejlesztőknek az alacsony szintű, új API használata túl bonyolult lehet, esetleg nem is jelent előnyt.