Az OpenGL az elmúlt hónapokban fő téma lett, ezen belül is a modern kiterjesztések szempontjából kapott az API hírverést. Az idei GDC-n az AMD, az Intel és az NVIDIA egy közös előadást tartottak arról, hogy a Mantle és a DirectX 12 mellett még az OpenGL is életben van, ráadásul tartalékokat is kínál.
A gyártók együttesen kiemelték, hogy az OpenGL már ma képes mérhetetlenül alacsony többletterhelés mellett működni, és ezt teszi teljesen szabványos, vagy legrosszabb esetben is opcionális, de amúgy minden érintett gyártó által támogatott kiterjesztéssel. A végeredmény tehát mindenki számára jó lenne, de a fejlesztői támogatás hiányzik. Ennek egyrészt az lehet az oka, hogy az OpenGL-hez használt fejlesztőkörnyezetek nem olyan kiforrottak, de ezen már javában dolgozik a Valve, viszont még mindig gond, hogy az oktatás zömében nem tért át a modern OpenGL funkciókra. A fejlesztők többsége egyszerűen nincs tisztában azzal, hogy ez az API valójában mire képes.
Az érintett gyártók elmondták, hogy a modern OpenGL-tól nem kell félni, abszolút nem bonyolult, csupán más, de ez teszi hatékonnyá. Az API-nak manapság leginkább a „kőkorszakiként” jellemzett funkcióit használják a programok, aminek egyébként az lehet az alapja, hogy ezeket is oktatják, tehát önmagában érthető, hogy miért történik mindez. Ugyanakkor van az API-nak „űrkorszakiként” jellemzett funkcionalitása is, ami már nagyon is hatékony, de az oktatásból jellemzően kimarad. Lehetne elemezni, hogy ez miért alakult így, de a gyártók szerint fontosabb, hogy felhívják a figyelmet a lehetőségekre, amire a programozók felfigyelnek, és ez majd az oktatást is megváltoztatja.
Klasszikus „kőkorszaki” OpenGL [+]
A modern OpenGL persze rengeteg hibaforrás alapja is. Az elsődleges probléma, hogy az API funkciói közül viszonylag sok nem kompatibilis egymással. Még aki ki is próbálja a modern OpenGL-t, jellemzően letesz róla, mert nem érti, hogy miért nem működik. Sokszor ezt driveres hibaként jellemzik, de az esetek többségében kiderül, hogy programhibáról van szó. Ezért lenne fontos az oktatás, mivel egy átlag programozó nem mindig gondol arra, hogy egy API saját magával ne legyen kompatibilis, de ugyanakkor ez mind dokumentálva van, tehát kellő utánajárással a jellemző hibák zöme elkerülhető. Valamilyen szinten itt a fejlesztőeszközök is sárosak, mivel nem adnak jó visszajelzést a problémákról, ami nagyon megnehezíti a fejlesztést.
Modern „űrkorszaki” OpenGL [+]
A kőkorszakinak gúnyolt, de hivatalosan klasszikus OpenGL modell egyébként nem teljesen előnytelen, hiszen nagyon stabil, a 20 éve írt kódok egyszerűen futnak, ráadásul egyszerű is, hiszen a driver sok feladatot elintéz. Ennek következtében rengeteg programhoz ma is ideális, és nincs ezzel semmi gond. A modern, hardverigényes játékokhoz azonban pont nem jó, és ezt kell felismerni, mivel maga az API nem úgy működteti a hardvert, ahogy kellene. A modern OpenGL azonban a problémákra megoldást kínál, csupán arra kell figyelni, hogy az alkalmazást már a kezdetektől a modern funkciókra kell felépíteni, illetve számon kell tartani a lehetséges kompatibilitási gondokat, amelyeket így el lehet kerülni a fejlesztés során. A modern funkciók bevetésével az egyes, driver által limitált szituációkban az OpenGL akár 15-ször is gyorsabb lehet, ami lényeges előrelépés minden fejlesztő számára.
A legtöbb modern kiterjesztést az OpenGL 4.2-es verziója tartalmazza, de van a 4.3-as és a 4.4-es verzióban is újítás. Viszont a gyártók kiemelték, hogy ha az adott API verziót az aktuálisan legfrissebb driver nem is támogatja teljesen, az elemzett modern kiterjesztéseket kezeli, tehát ebből nem lehet gond. Innentől pedig már tényleg a fejlesztők oldalán pattog a labda. Mindenesetre a Khronos Group megpróbálja felrázni az oktatást is, hogy vegyék számba az AMD, az Intel és az NVIDIA által ajánlott feldolgozási modellt. Az érintett gyártók mindemellett összefogtak, hogy a legtöbb rendezvényen közös előadásokat szerveznek a modern OpenGL működésének megértése, illetve az új kiterjesztések kihasználása érdekében.
