Az OpenGL körül manapság PC-n is elkezdett pezsegni az élet. A SteamOS mindenképp jó hatással van rá, hiszen a fejlesztők újra észrevették, hogy a DirectX mellett létezik egy esetenként kedvezőbb alternatíva is. Ez persze nem jelenti automatikusan az OpenGL terjedésének kezdetét, de az NVIDIA a Steam Dev Days konferencián azért bemutatta, hogy miképp kell használni a modern kiterjesztéseket. Erről egy korábbi hírben már írtunk, de mára kiderült, hogy a vállalat három fő szempont szerint javítaná a hardverek kihasználhatóságát. Elsősorban dinamikus puffergenerálás kell hatékonyabb textúra menedzsmenttel, és több rajzolási parancs kiadásának is lehetőséget biztosítani. Az egész koncepció a grafikus meghajtó és az API munkájából fakadó többletterhelés csökkentését célozza meg, amiről a Mantle API bejelentése óta rengeteget beszél a piac. Ez persze nem újdonság, a fejlesztők évek óta kérik a Microsoftot a DirectX hatékonyabbá tételére, de ennek sajnos máig nincs eredménye.
Az NVIDIA előadásában csupa szabványos kiterjesztés szerepel. A dinamikus puffergeneráláshoz a GL_ARB_buffer_storage lehet hatékonyan használható. Ez a kiterjesztés felfogható a GL_ARB_texture_storage koncepcionálisan hasonló változatának csak éppen a pufferekre vonatkozóan. Leginkább akkor hasznos, ha a programba dinamikus geometriát kell generálni, példának okáért ez jó lehet a részecskerendszerekhez, illetve vegetáció leképzéséhez is használható. A régi és egyben tipikus megoldással az a gond, hogy ugyan a rendszer mentesül a teljesítményt sokszor kivégző CPU és GPU szinkronizálási pontoktól, de a driver által futtatott rejtett szálakat soros végrehajtásra kényszeríti, ami a mai sok szállal dolgozó processzorok esetében messze nem ideális. A GL_ARB_buffer_storage kiterjesztésre építve a modern megoldás egy specifikus point sprites tesztben hatvanszor is gyorsabb lehet.
A hatékonyabb textúra menedzsmenthez jó lehet a GL_ARB_bindless_texture és GL_ARB_sparse_texture kiterjesztések használata. Ezek alkalmazása egy kicsit problémásabb, mivel az előbbi kiterjesztés például mindenképp NVIDIA Kepler és AMD GCN architektúrára épülő grafikus processzorokat igényel. Viszont ez a fajta binding modell sokkal jobban illik a mai modern hardverek működéséhez, és egyben minden bekötéssel kapcsolatos terhet levesz a központi processzormagokról. Az így szerzett előny egyértelmű, önmagában is gyorsabb feldolgozás, miközben még a processzor erőforrásai is felszabadulnak.
A több rajzolási parancs kiadása lassan kritikus igény lesz a fejlesztők részéről, hiszen ebből a szempontból már az előző generációs konzolok is megelőzték a PC-t, az új generációs gépek pedig egyenesen megalázzák a hardver tekintetében amúgy izmos masinákat. Mentőövet a GL_ARB_ multi_draw_indirect adhat. A fenti kiterjesztésekkel a pufferek frissítéséből és a textúrák bekötéséből eredő többletterhelések kvázi megszűnnek. Az objektumok rajzolására azonban szükségesek a parancsok, viszont az előbb említett kiterjesztés lehetővé teszi, hogy a fejlesztő eltároljon egy pufferobjektumban számos rajzolással kapcsolatos paramétert, majd ezt a puffert egy rajzolási paranccsal meg lehet hívni, és a benne tárolt rajzolási parancsok kiadása kvázi ingyenes lesz. Tulajdonképpen maga a ténylegesen kiadott rajzolási parancs többletterhelése nem lesz olcsóbb, de az erőforrásokat mégis okosabban lehet használni, ami végtére is sebességnövekedéshez vezet.
Többletterhelés tipikusan használt és modern OpenGL kiterjesztésekkel [+]
A fenti modern OpenGL kiterjesztésekkel a driverrel kapcsolatos interakciók nagyjából 75%-kal csökkenthetők, illetve lényegesen több objektum rajzolható ki kvázi egységnyi rajzolási parancs kiadásával. Az OpenGL persze az említett kiterjesztésekkel nem úgy működik, ahogy például a Mantle, hiszen inkább az erőforrások hatékonyabb kihasználására tör, és nem az alacsony szintű elérésre, de a cél ugyanaz. Ha a fejlesztők elérik a kívánt eredményt, akkor az irány és a mögöttes koncepció lényegében nem számít. Ráadásul leginkább a kirajzolható egyedi objektumok számára vonatkozóan vannak igen komoly igények. A GPU memóriájának közvetlen elérése, illetve a compute és grafikai feladatok kontrollált és egyben tervezhető átlapolása ugyan hasznos a Mantle-ben, de túl lehet élni a hiányukat. A többletterhelés problémája azonban kritikus mértéket ölt, így ezzel mindenképp kezdeni kell valamit. Az OpenGL szabványos és már elérhető modern kiterjesztései első lépésként jó irányt képviselnek. Az egyetlen hátránya, hogy legalább OpenGL 4-et támogató hardverek kellenek, de 2014-ben ez nem jelenthet gondot.
A legnagyobb kérdés azonban, hogy a fenti extrák mellett miért nem terjed jobban az OpenGL PC-n? Erről több fejlesztőt is megkérdeztünk és meglepetésünkre mindenki ugyanazt mondta. A Microsoft a DirectX esetében az előző évtized közepén nagyon ráfeküdt a megfelelő debug programok és profilozók biztosítására, míg a Khronos Group erre nem figyelt. Az évek során a DirectX-re sokkal jobb fejlesztőeszközök készültek, és ezt a hátrányt máig nem sikerült behozni. A legtöbb fejlesztő egyszerűen nem szeretne modern grafikai eljárásokat és leképzőket profilozni, illetve debugolni félkész vagy nem túl jól működő eszközökkel. Jó hír azonban a VOGL érkezése, ami a Valve saját debug és profilozó programja az OpenGL API-hoz, illetve Linuxhoz is. Ennek a célja lényegében ledolgozni az OpenGL előbb említett hátrányát. Ha ez sikerül, akkor több OpenGL játék érkezhet Windowsra is, hiszen maga az API a kritikus szempontok szerint jobbnak tekinthető a DirectX-nél.
