Tavasszal írtunk a Collabora érdekes fejlesztéséről, amely futtathatóvá tenné az egyes, OpenGL és OpenCL programokat a megfelelő natív implementációval nem rendelkező rendszereken. Ezt a Microsoft is támogatja, főleg az OpenGL miatt, hiszen ez az API már nem igazán kap frissítést, és a Vulkan terjedésével a jövőben egyre kisebb lesz az esélye annak, hogy az egyes új hardverekhez készül egyáltalán natív OpenGL implementáció. Ennek a költségcsökkentés tekintetében komoly előnye van, de problémás lépés is, hiszen ellehetetlenítené az OpenGL-re írt alkalmazások futtatását. A Collabora projektje ugyanakkor a maximum OpenCL 1.2-re és OpenGL 3.3-ra épülő alkalmazásokat képes lenne elindítani a DirectX 12 implementációkon keresztül is, vagyis anélkül lehetne a gyártóknak költségeket csökkentő intézkedéseket tenni, hogy fel kellene áldozni az egyes alkalmazások működését.
A korábbi hírben leírtuk, hogy a rendszer a Mesa 3D-re épít, amely számos API-t implementál nyílt forráskódú módon. A Collabora friss beszámolója szerint az OpenGL API-ra vonatkozóan jól halad a munka, és pár új komponens beépítésre került.
[+]
Az olvasóink egy része valószínűleg tudja, hogy egy OpenGL-re írt alkalmazás a Windows operációs rendszeren a WGL függvényeket, illetve az adott natív OpenGL implementációt hívja meg, utóbbihoz értelemszerűen kapcsolódik egy megfelelő GLSL fordító is. Ezeket a Collabora konstrukciójában a MESA kezeli. A WGL state tracker értelemszerűen a WGL-ért felel, ami egy kevésbé ismert API, de az OpenGL-t, illetve a Windows ablakkezelő rendszerinterfészét köti össze. Itt olyan nagyon sok gond nem lehet, hiszen a grafikus kernel alrendszer felé a GDI (Graphics Device Interface) számára egyenes az út, viszont a DirectX 12-es erőforrás eléréshez szükség volt egy DXGI swapchain implementációra. Ez az egyik újdonság, és a segítéségével végre lehetővé vált a háttérpuffer használata (egyelőre dupla pufferelés mellett). Ennek a viszonylag kis fejlesztésnek hatalmas jelentősége van a hardver optimális kihasználása szempontjából, hiszen háttérpuffer nélkül a következő jelenetszámítás megkezdéséhez meg kell várni az éppen aktuális képkocka elkészültét, ami finoman szólva is lassú, illetve pazarló feldolgozási modell.
Az OpenGL, illetve a GLSL kérések a MESA state trackerbe futnak be. Ez fordítja le az OpenGL állapotokat, illetve rajzolási parancsokat a Gallium API-ba, ami gondoskodik róla, hogy az így kapott objektumok és operációk jól illeszkedjenek a modern hardverekhez. Természetesen ezzel még nem adható tovább a munka a DirectX 12-es erőforrásnak, pontosabban nem célszerű így tenni, mivel rajzolási parancsonként egyedileg lenne beállítva minden szükséges munka, ami minden csak nem gyors. Persze működni működik. A Collabora azonban írt egy D3D12 meghajtót, ami megfelelően tud viselkedni a rajzolási parancsok kötegelése, az állapotok kezelése, illetve az erőforrásokra vonatkozó munka menedzselése szempontjából. Ez az újítás is a nagymértékű teljesítménynövekedést célozza.
Már csak a GLSL shaderek maradtak hátra, amelyeket a MESA state tracker eljuttat a GLSL to NIR modulba. Ennek a feladata nagyon egyszerű, a kapott kódokból készít egy köztes reprezentációs szintet, jelen esetben ez a NIR. Eddig rendben is van, de egy DirectX 12-es erőforrás semmit sem tud ezzel kezdeni, ami miatt a NIR-t át kell fordítani DXIL-be, és ez már egy olyan köztes kód, amelyet a hardverek DirectX 12-es implementációi megértenek. Ez az utolsó fordítási lépcső kritikus fontosságú, hogy egyáltalán a shaderek lefuttathatók legyenek, tehát a működés szempontjából elengedhetetlen újításról beszélünk.
A fenti fejlesztésekkel lényeges előrelépést sikerült elérni, ugyanis a Doom 3 egy specifikus jelenete, a korábbi implementációhoz képest nagyjából 40-szer gyorsabban futott. A hardver itt egy IGP-vel rendelkező Intel processzor volt, de nem ez az igazán lényeges, hanem a szoftverből eredő előrelépés. És itt konkrétan a játszhatatlan, illetve a játszható élmény közötti különbségről van szó.
Azt fontos kiemelni, hogy a projekt még mindig aktív fejlesztés alatt áll. Ez még messze nem az út vége, további koncepciók vannak az optimalizálásra. Viszont a mostani állapot egy rendkívül jó alapnak fogható fel.
