Az OpenGL a Valve programozója szemével

A Valve SteamOS-sel kapcsolatos terveit figyelembe véve kritikus fontosságú, hogy a Linuxra elérhető OpenGL API használható legyen játékfejlesztésre. Rich Geldreich, a vállalat programozója azonban kieresztette a gőzt blogjában, ahol meglehetősen durva, OpenGL-t érintő hibákat osztott meg a világgal. Szerencsére nem kívánt bűnbakot keresni, bár írása így is nagy port kavart, mindazonáltal felhívta rá az érintettek figyelmét, hogy ez így nem mehet tovább, az OpenGL fejlesztését újra kell kezdeni, különben a Mantle és a DirectX 12 végleg elintézi az API-t. Bár az időpont így sem tökéletes, hiszen a Mantle alig pár hónapra, míg a DirectX 12 másfél évre van a teljesen publikus megjelenéstől, de ha a felmerült problémákra még most felfigyel az iparág, akkor még reálisan elkészíthető egy új, nyílt forráskódú grafikus API.

Az írás alapján az OpenGL legnagyobb problémája, hogy húsz év örökségét hordozza a hátán. A számos alkalommal megújult API mára nehezen átlátható működést kínál, és a szabványosításért felelős Khronos Group sincs a helyzet magaslatán. Többek között sokkal jobb dokumentációk kellenének, a shader programok fordítása és linkelése majdnem használhatatlan (ebből a szempontból a DirectX működésének lemásolását tekinti megoldásnak Rich Geldreich), szörnyen sok szükségtelen függvény van az API-ban, illetve a fejlesztőeszközök sem olyan jók, mint DirectX-re, bár érkeznek lehetséges megoldások erre a gondra. Ezek mellett Rich Geldreich úgy gondolja, hogy az OpenGL nagy előnyeként elkönyvelt kiterjesztések lehetősége inkább csak ront az API használhatóságán, hiszen ezek a specifikus vagy minden gyártó által támogatott kiterjesztések ritkán működnek jól, így nem is éri meg ezekre építeni egy játékban. Ennél nagyobb gond, hogy ha a fejlesztő rákényszerül a kiterjesztésre, akkor megfelelő eszközök hiányában ezek működése nem elemezhető. Ennek értelmében mindenképp szükséges a programban egy alternatív megoldást kínálni az adott problémára, esetlegesen ki kell vágni a kiterjesztés használatát követelő effektet az OpenGL portból. Itt fontos kiemelni, hogy bár a felhasználó elvárja, hogy az adott játék SteamOS-en ugyanúgy nézzen ki, mint Windowson, de valójában a fejlesztők szemében a stabil és problémamentes működés a legfontosabb, így ha egy effektet nem tudnak megfelelően megvalósítani OpenGL-en, akkor nem fogják használni a játék Linux verziójában.

A programozó továbbá úgy gondolja, hogy a DSA (Direct State Access) kiterjesztéseket szabványosítani kellene, mivel segítségével lényegesen csökkenthető az API többletterhelése, ami végső soron gyorsuláshoz vezet. Ezt lényegében minden modernebb hardver támogatja, de a Khronos Group fél évtizede semmit sem tesz az ARB kiterjesztés megszületéséért. Ezzel az OpenGL fejlesztéséért felelős alapítvány a játékfejlesztőkkel tol ki, talán nem szándékosan, bár abból kiindulva, hogy az OpenGL hivatalos specifikációi még 2014-ben sem teljesen készek, akár ebben is megrendülhet a hit.

A fentiek azonban csak felületes gondok, mivel súlyosabb kellemetlenségekbe is sűrűn bele lehet futni, amelyekkel meg kell küzdeni. Ezek közül a legjobban ismert jelenség az, amikor a grafikus meghajtó valamiért ideiglenesen leállítja a futószalagot a leképzésért felelős szálon. Ez az elsődleges és teljesen általános probléma, amivel az OpenGL-re fejlesztő stúdiók szembesülnek, és máig nincs olyan fejlesztőkörnyezet, amivel meghatározható lenne ennek forrása. Maga a jelenség ismert a DirectX API-ból is, de a Microsoft kínál olyan eszközöket, amelyekkel a fejlesztők nyomon követhetik az eseményeket. Bár a probléma forrása nem mindig határolható be pontosan, mindenképp szűkíteni lehet a potenciális listát, ellenben az OpenGL-en a fejlesztő lényegében vak, csak a teljesítmény visszaesése látszik, de megfelelő eszközök nélkül nem lehet megtalálni a hibaforrást. Mindemellett az OpenGL hibaüzenetei sem teljesen világosak. Az API a GL_INVALID_OPERATION hibát rengeteg különböző problémára használja, így borzalmasan nehéz belőni, hogy a kódban hol van probléma.

Végül az OpenGL, bár egyetlen API, a valóságban a fejlesztőknek mindenképpen több leképzőt kell írni, hogy problémamentes és gyors legyen a működés a legtöbb hardveren. Ez viszonylag sok okra vezethető vissza, ám a lényeg, hogy az OpenGL ezzel a modellel egy masszív pénznyelő. Nem véletlen, hogy több fejlesztő is kifejtette korábban, hogy a DirectX-szel megegyező funkcionalitású és sebességű OpenGL port lényegében annyi pénzt igényel, mintha minden egyes grafikus vezérlőt fejlesztő cégnek lenne egy-egy alacsony szintű grafikus API-ja, amelyeket külön-külön támogatni kellene. Tekintve, hogy a Linux még mindig nem rendelkezik túl komoly részesedéssel, a legtöbb kiadó számára az OpenGL nem járható út. Bár a Linuxot több kiadó is támogatni szeretné, idevéve például az EA-t, de utóbbi vállalat az OpenGL-től, pontosabban az API támogatásával járó pénznyelő hizlalásától már elzárkózik, ami a fentiek tudatában érthető.

[+]

A grafikus meghajtók és a gyártók fejlesztőeszközei sem teszik egyszerűvé a helyzetet. Az NVIDIA Rich Geldreich szerint jó drivereket készít, de gyenge fejlesztőeszközöket kínál. Viszont a vállalat csapata szorosan együttműködik a stúdiókkal, hogy megfelelően gyors OpenGL kód szülessen a GeForce driverekre, ezek a kódok azonban nem teljesen követik az OpenGL szabványt, így rosszul futnak a többi gyártó meghajtóin, amiért sokan az adott gyártót hibáztatják. Az AMD már nem készít olyan jó drivereket, mint az NVIDIA, de jóval előnyösebb fejlesztőeszközöket (GPU PerfStudio és CodeXL) kínálnak. Ezek nélkül többek között a Valve projektjei is sokkal később készültek volna el. A gond itt az, hogy az AMD fejlesztőeszközei leginkább AMD hardverekkel működnek, tehát tartani kell a kapcsolatot az NVIDIA és az AMD csapataival is, emellett ez legalább két specifikus leképzőt is jelent az OpenGL portba (egyiket az NVIDIA, másikat az AMD hardvereire optimalizálva).

Az Intelre túl sok figyelmet Rich Geldreich nem fordított. Elmondása szerint ennek a cégnek a driverei egyszerűen nem jók, ráadásul egy ismert motort fejlesztő cég több mint egy évig dolgozott azon, hogy működésre bírják az új OpenGL 4-es funkciókat az Intel driverein. Ez ismét jól jelzi, hogy az OpenGL mennyire gazdaságtalan, hiszen ennyi idő alatt minden architektúra esetleges külön zárt API-jára lehetne írni teljesen jól működő, végletekig optimalizált leképzőket. Ehelyett egyetlen egy platformra kell fordítani rengeteg erőforrást, hogy az OpenGL kód egyáltalán működjön, és ekkor még a sebességről nem is beszéltünk. Márpedig az Intel hardvereit nem lehet kihagyni, mivel sokan nem használnak AMD és NVIDIA grafikus vezérlőt.

Mi lehet a megoldás?

Rich Geldreich blogbejegyzései alapvetően elindítottak egy vitát az iparágon belül. Bár a Valve számára talán nem ideális az OpenGL-t ennyire használhatatlannak hirdetni, amikor gyakorlatilag a SteamOS-en erre az API-ra építenek, de a problémákat sem érdemes szőnyeg alá söpörni. A legtöbb fejlesztő a leírtakkal nagyjából úgyis tisztában van, tehát mondhatni senkit sem ér majd meglepetés, ha a DirectX-ről az OpenGL területére eveznek. Az írások azonban elérték a kívánt hatást, hiszen az iparág nem legyintett az ismert problémákra, hanem elkezdődött a diskurzus a lehetséges megoldásokról. Ezzel kapcsolatban több fejlesztőt is felkerestünk, és meglepően sok programozó véleménye megegyezik.

Sokan úgy gondolják, hogy minden cégnek ki kellene dolgozni egy saját, alacsony szintű grafikus API-t, amit saját hardvereikre szabnak. Ez tulajdonképpen tekinthető felhívásnak is, hogy minden érintett álljon elő a "saját Mantle API-jával". Ezt a fejlesztők egy része viszont nem akarja, mert akkor igen sok API-ra kell egyszerre dolgozni, bár valójában az aktuális modellek mellett sincs ez másképp, ha az OpenGL API használatával is minden egyes architektúrára érdemes külön leképzőt írni. Ez az egyetlen út, hogy a program stabilitása és sebessége elfogadható legyen, amit nyilván az adott szoftver potenciális vásárlói elvárnak a birtokolt hardvertől függetlenül. Sőt az OpenGL még rosszabb is, mert megfelelő fejlesztőeszközök hiányában bizonyos hibákat lehetetlen detektálni, ahogy azt említettük – szürreálisan hangzik, de nagyon gyakori, hogy az OpenGL hibaüzenetei abszolút nem segítenek. Ne feledjük, hogy több ezer soros kódról is lehet szó, és ha azon belül nincs specifikálva a probléma forrása, akkor a kapott hibaüzenet nem több annál, mintha az API azt mondaná: valahol hiba van a kódban, sok szerencsét a megtalálásához.

A fentiek mellett a grafikus driver többek véleménye szerint is egy feketedobozként viselkedik. Egyszerűen a fejlesztő nem látja, miképp működik a meghajtó, így nagyon ajánlott az adott gyártó driverért felelős csapatával úgymond baráti viszonyt kialakítani, különben igen sokáig elhúzódhat egy-egy teljesítményprobléma javítása. Ráadásul a driverek igen masszívak és komplexek, aminek következtében teljesen elhatárolódnak a jellemzően kedvelt KISS (Keep It Simple, Stupid) modelltől. Ezek a rendszerek már-már az átláthatatlanság határáig bonyolódtak, ami nemes egyszerűséggel alacsony hatásfokú fejlesztésekhez vezet. Időnként fájó szívvel ugyan, de olyan döntéseket is meg kell hozni, mint a kód jelentős részének újraírása, mert megfelelő fejlesztőeszközök nélkül nem lehet megtalálni a hiba vagy a teljesítményprobléma forrását. Ez sajnos az OpenGL-re nagyon jellemző, de a DirectX esetében is előfordul, noha a jobb fejlesztőeszközöknek hála ritkábban. Így már érthető az is, hogy a Microsoft DirectX 12 és az AMD Mantle API alapkoncepciója miért a KISS modell erősítésére épül. Ilyenkor a grafikus driver nem több, mint shader programokat futtató interfész az API és a hardver között. A fejlesztők szerint ennél nem is kell többnek lenniük, hiszen ez drámaian leegyszerűsíti a hibakeresést, és eltünteti a driver feketedoboz jellegét.

A gyártói alacsony szintű grafikus API-k tehát már akkor is jobb lehetőségeket és összességében olcsóbb fejlesztést kínálnának a legtöbb stúdiónak, ha az AMD mellé az NVIDIA és az Intel is elkészítené saját megoldását. Azonban ennyire radikálisan talán nem kellene gondolkodni, bár valószínűleg senkinek sem lenne túl nagy probléma, ha az Intel és az NVIDIA is bedobna egy-egy saját grafikus API-t, de a DirectX 12 példájából kiindulva meg lehet ezt oldani egységes szinten is. Általános vélemény, hogy az OpenGL helyére kellene egy új, nulláról újraírt, de ugyanakkor szintén nyílt forráskódú API. Ezzel a rendszer átesne ugyanazon a masszív egyszerűsítésen, amin a DirectX (előreláthatólag) átesik a 12-es verzióval, mindeközben nyílt jellegét sem veszítené el.

Timothy Lottes, az Epic Games programozója szerint nagyon stílusos megoldás lenne, ha az új OpenGL egy alacsony szintű grafikus API lenne, ami biztosítaná a megfelelő alapot a fejlesztéseknek, és erre még lehetne húzni egy magas szintű hozzáférést, ami a független stúdiók számára kedvezőbb lehet. Ez lényegében egy strukturált API, amiből igény esetén lehet használni az alacsony szintű hozzáférést a maximális sebesség érdekében, de akár a szintén megújított magas szintű hozzáférés is elérhető lenne, ami logikailag az alacsony szintű felületen helyezkedne el. Természetesen az összes gyártót be kellene vonni a fejlesztésbe, akár egy új konzorciumot alapítva, így biztosítható lenne az új, nyílt forráskódú grafikus API megfelelő támogatottsága. Reálisan átgondolva a lehetőségeket a piac számára messze ez lenne a legjobb alternatíva.

Itt az ideje újítani

Nagyon fontos tényező, hogy bármit is akarnak az érintettek, a munkát most kell(ene) elkezdeni. Ne feledjük, hogy egy szabványos API kidolgozása 3-4 év is lehet. Ezzel már rögtön két év előnyt ad minden platformszállító a Microsoftnak (köszönhetően a DirectX 12 érkezésének), és minden további késlekedés csak ront a helyzeten. Eközben az egyetlen új generációs grafikus API, ami nincs a Windowshoz kötve, az a Mantle, ez viszont az AMD-hez kötődik. Természetesen nem kizárt, hogy ez megjelenik a Google és az Apple platformjaiban vagy éppen a Linux disztribúciókban, de a Mantle eleve nem ideális leváltója az OpenGL-nek, mert masszívan korlátozza a hardverválasztást. Ugyan több fejlesztő felhívta arra a figyelmet, hogy ezt az API-t is lehet a konkurenseknek támogatni, de egyrészt ezt valószínűleg nem teszik meg addig, amíg az AMD felügyelete alatt van a fejlesztés, másrészt a Mantle binding modellje úgynevezett exkluzív bindless, vagyis nem csak a textúra, hanem a mintavételező state-ek esetében sem fogadja el a fix regiszterekhez való kötődést. Ez a gyakorlatban azt jelenti, hogy a konkurens megoldások közül csak az NVIDIA Kepler és Maxwell architektúrája képes támogatni. Szabványos szinten a mintavételező state-eket mindenképp fix regiszterekhez kell kötni, mert a legtöbb grafikus hardver más binding modellel nem tud működni.

Az lenne ideális, ha a platformban érdekelt cégek, mint a Google, az Apple, a Valve és más Linux disztribúciók fejlesztői összefognának egy új, nyílt forráskódú grafikus API fejlesztése céljából. Az Intel és az NVIDIA régóta azon a véleményen van, hogy ez a probléma az operációs rendszerek fejlesztőire tartozik és nem a grafikus hardverek gyártóit kell elővenni, ha az elérhető API-k nem elég jók. Nem kevés igazság van ebben, hiszen egy hardvergyártó számára az API-k támogatása a feladat, nem pedig azok kifejlesztése. Ez a vélemény viszont részben ütközik a játékfejlesztőkével, hiszen igen valószínű, hogy az Intel és az NVIDIA mondandójának alapjaival egyetért mindenki, de mi van akkor, ha az operációs rendszerek fejlesztői nem tesznek a probléma ellen? A játékfejlesztők egyszerűen nézik, ahogyan egyre bonyolultabb lesz minden, így egyre több pénzt költenek a szoftver kifejlesztésére is, amit természetes, hogy nem tűrnek el a végtelenségig. Idővel alternatívát keresnek, vagy akár egy új API-t kérnek az egyik gyártótól, akkor is, ha az a piac számára nem ideális.

Érdekes opció lehet még a Valve álláspontja is, akik nyílt forráskódú OpenGL drivereket szeretnének. Ennek főleg az Intel nagy támogatója, míg az AMD úgymond elfogadja ezt a lehetőséget, de a kialakult helyzetet látva csak félgőzzel támogatják az önjelölt csapatokat. Nyilván ez részben stratégia, hiszen az OpenGL összes problémája fokozatosan feléjük és a Mantle felé tereli a fejlesztőket, hiszen ez az egyetlen API, ami a DirectX 12-vel versenyképes és implementálható Linuxra. Az NVIDIA a nyílt forráskódú drivereket nem segíti, ami szintén stratégia, hiszen a vállalat szeretné, ha a játékfejlesztők az NVIDIA mérnökeivel együtt dolgoznának minden készülő programon. Éppen ezért nem kínálnak jó fejlesztőeszközöket OpenGL-hez, mert nincs igazából érdekükben, hogy egy stúdió önerőből ki tudjon fejleszteni egy AAA kategóriás játékot OpenGL leképzővel. Ilyen ellentétek mellett a Valve nyílt forráskódú OpenGL drivereket szorgalmazó ötlete nem sokat ér.

A sok lehetőség közül valamit mindenképp választani kell, és ezt gyorsan kell megtenni. Ha pedig az újítások mellett teszi le a voksát az iparág, akkor azokat át is lehetne menteni mobil szintre. Ezt már csak azért is érdemes megfontolni, mert John Carmack szerint a Rich Geldreich által felvázolt PC-s helyzet teljesen elfogadható ahhoz a fejetlenséghez képest, ami az ultramobil IGP-k piacán jelenleg uralkodik.

Abu85