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