A Valve programozója nagy port kavart, amikor lefestette az OpenGL API és az egész köré épülő ökoszisztéma helyzetét, ami máig vitatéma az iparágon belül. A jó hír, hogy valami elkezdődött. Lassan mindenki belátja, hogy a helyzet tarthatatlan, így az előrelépés már csak idő kérdése. Az idő azonban pont az a tényező, amiből nincs sok. Még a Microsoft DirectX 12 API-ja is csak a következő év végén érkezik, ami ráadásul nem lesz megoldás a Linux és ezzel a SteamOS gondjaira.
Korábban már többször felmerült (még a nagy API reformok előtt), hogy lehetne-e a játékokat direkten a grafikus vezérlőre írni. Elvileg ehhez csupán a hardver dokumentációjára van szükség, illetve szükséges egy olyan driver, ami lehetővé teszi a program számára az erőforráshoz való direkt hozzáférést. Ez a módszer ugyanazokat az előnyöket kínálná, mintha a program alacsony szintű grafikus API-ra készülne, ami jó, mert jönne a sebesség, de az ötlet mindig a süllyesztőben végezte. Az okok szempontjából felhozható, hogy egyrészt nincs minden hardvernek jó dokumentációja, másrészt a zárt driverek nem engedik a hardverhez való közvetlen hozzáférést, harmadrészt pedig minden architektúrára külön kellene egy leképző, illetve a tesztelés szempontjából szükség lenne egy saját fejlesztésű validátorra, mellyel meggyőződhetne a fejlesztő, hogy nem követett-e el a programozás során valami hibát, ami esetleg teljes rendszerösszeomláshoz vezetne.
A grafikus architektúrák direkt programozása tehát sok munkával járna, ami kizárja, hogy ilyen megoldáshoz nyúljanak a fejlesztők a teljes piacot tekintve, de a mai viszonylatban pár elterjedt hardverre még be is lehetne vállalni. A cél pedig mindig az, hogy a kívánt eredményt a lehető legkevesebb idő alatt lehessen hozni. Egy alacsony szintű grafikus API messze a legolcsóbb megoldás az AAA kategóriás játékok fejlesztőinek szemében, de sok hardverre nem érhető el ilyen koncepció, ám ma már nem feltétlenül rosszabb egy-két architektúrára direkten programozni, mintha OpenGL API-n keresztül születne meg a kód. Emlékezhetünk Rich Geldreich blogjára, melyből kiderült, hogy egy ismert motort fejlesztő vállalat több mint egy évig dolgozott azon, hogy működésre bírják az új OpenGL 4-es funkciókat az Intel grafikus driverein. Azóta kiderült, hogy az Unreal Engine 4-ről volt szó, így a munkát az Epic végezte. Ugyanakkor a sebesség még az eltelt idő és a temérdek optimalizálás után sem jó, így mondhatni az az egy év arra volt elég, hogy valahogy működjön a rendszer.
Ha kiindulunk abból, hogy az Epic tapasztalt programozóinak nagyjából másfél évre van szükségük ahhoz, hogy tényleg gyorsra és stabilra összerakják a modern OpenGL-t a legújabb Intel hardverekhez, akkor felmerül a kérdés, hogy gyorsabb lenne-e hagyni az OpenGL-t, és szimplán direkten leprogramozni az IGP-kre egy-egy leképzőt. Tulajdonképpen csak két fő architektúrát (Gen7 és Gen7.5) kellene támogatni, ráadásul ezek eléggé hasonlítanak egymáshoz, tehát a munka egyes elemei újrahasznosíthatók. Az Intel dokumentációi is elég jók, illetve a nyílt forráskódú Linux driverbe lehetne írni egy olyan kiskaput, mely engedné az adott alkalmazásnak a hardver direkt elérését.
Információink szerint a Firaxis már dolgozik is egy hasonló terv megvalósításán. Számukra ez nagyon fontos lehet, hiszen olyan operációs rendszereket is támadnak, amelyekben csak az OpenGL érhető el, de nyilván nem akarnak egy évet csak arra költeni a drága idejükből, hogy egyáltalán elinduljon a kód az amúgy nagyon fontos modernebb Intel IGP-ken, melyek a Linuxos körökben eléggé népszerűek. A hardver direkt programozása lényegében gyorsabban és könnyebben tenné kihasználhatóvá a Haswell, az Ivy Bridge és a Bay Trail lapkák IGP-it. Ehhez persze szükséges a MESA csapatával való együttműködés is, de ez nem jelenthet gondot.
A Firaxis sajnos a megjelenés előtt nem beszél semmilyen tervéről, így erre vonatkozó kutatásunk zátonyra futott. Más fejlesztőtől azonban megtudtuk, hogy egy efféle koncepció nagyjából hat hónapot venne igénybe jó dokumentációk és külön architektúrákhoz kirendelt csapatok mellett. Ebből három-négy hónap lenne a felkészülés és a fejlesztőeszközök kidolgozása, illetve további két-három hónap a leképzők megírása. Elméletben persze, mivel ilyet korábban még soha senki sem tett, így lehetnek olyan buktatók, amelyek megnehezíthetik a fejlesztést, de a koncepció működhet.
Nagyon érdekes, hogy a grafikus vezérlők direkt programozása már Christopher Roberts blogjában is felmerült. A Star Citizen című játék fejlesztésének vezetője konkrétan felszólította az Intelt és az NVIDIA-t, hogy ha alacsony szintű grafikus API-t nem is biztosítanak számukra, legalább engedjék meg a hardverek direkt elérését a driverekben. Ezzel kapcsolatban azonban az elmúlt év vége óta nincs új fejlemény. Általában a hasonló megoldásoktól a gyártók elzárkóznak, mert bár az ötlet jó, és nyilvánvalóan értik, hogy a fejlesztőket is csak a jó szándék vezérli, de a direkt programozás nem elegáns. Többek között azért, mert általános dolog, hogy generációnként változik az utasításarchitektúra az adott grafikus vezérlőben. Ezzel a megírt kód máris nem lesz kompatibilis, tehát vagy írni kell egy új leképzőt (előtte egy új validátort is), vagy a szabványos kódon keresztül működhetnek az újabb hardverek. Utóbbi viszont azt jelenti, hogy az adott, bizonyos GPU-architektúrákat direkten támogató játék az új termékeken lényegesen lassabban futna, mint a régebbieken, ami borzalmasan kedvezőtlen a cégek üzletstratégiájára nézve.
Valószínűleg a zárt meghajtók továbbra sem változnak meg, de a SteamOS esetében a MESA egy elfogadott támogatási forma lesz az Intel IGP-ire, azaz elvben meg lehet oldani a hardver direkt elérését, így a fejlesztők egy része megpróbálkozhat ezzel a koncepcióval. Ez az Intel számára egy darabig kedvező lesz, hiszen gyorsan fut majd a program a hardveren, de az új generáció eladásánál már borzalmasan káros, amikor az adott játék rajongója gyakorlatilag úgy vesz új és elvileg gyorsabb hardvert, hogy nem is sejti mennyivel rosszabban fog futni a kedvenc játékprogramja. Az efféle támogatási modell tehát csak időszakos megoldást kínál a problémákra.
