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.
A cikk még nem ért véget, kérlek, lapozz!
