Bár a Khronos Group jelenleg a márciusban bemutatott Vulkan API-ra koncentrál az OpenGL is fejlődni fog tovább, amit a legfrissebb információk is megerősítenek. Az új OpenGL verzió várhatóan még idén bemutatkozik, és egy alapvető frissítésnek fogható fel.
Az aktuális adatok szerint a legnagyobb figyelmet a gyártói kiterjesztések szabványosítása kapja, többek között megtudtuk, hogy az GL_INTEL_fragment_shader_ordering kiterjesztésből lesz egy ARB-s verzió, hiszen már az Intel specifikus kiterjesztését is támogatják a Haswell és Broadwell lapkák IGP-i, illetve a GCN architektúrára épülő Radeonok. Mindemellett a GL_AMD_pinned_memory kiterjesztés is szabványosítás alatt van, és még pár meglévő kiterjesztés esetében is várható, hogy mindenki által támogatható formába önti azokat az ARB csoport.
Ennél érdekesebb, hogy az OpenGL és a Vulkan bizonyos szempontból összeolvad. Többek között tervbe van véve egy olyan OpenGL wrapper réteg, amely a Vulkan implementációkon fut. Ez nem kínálja fel ugyanazokat az előnyöket, amelyeket maga Vulkan API, de lehetővé teszi a gyártóknak, hogy leállítsák az OpenGL meghajtók fejlesztéseit, mivel a wrapperen keresztül a Vulkan implementáció is képes lenne OpenGL-re írt programokat futtatni. Sebességelőny ebből nem származna, de a kompatibilitás biztosítható.
Ez a tervezés alatt álló koncepció az OpenGL-nek azt a problémáját is megoldaná, ami miatt sokan kritizálják, mivel a Vulkan implementációkon keresztül elérhető a SPIR-V is, aminek hála nem kell a gyártók által biztosított shader fordítókra hagyatkozni, vagyis azonos GLSL, vagy akár OpenCL C/C++ kód is tökéletesen futtatható lesz minden hardveren.
A Vulkan API-ra épített OpenGL wrapper másik előnye, hogy a programozó számára nem szükséges az alacsonyabb szintű hardvereléréssel járó dolgok megtanulása, így logikai szinten OpenGL-re írt játékok születnének, csak a tényleges futtatásuk egy wrapperen valósulna meg. Ez a wrapper természetesen tartalmazná a hatékony programfuttatáshoz szükséges mechanizmusokat, persze a Vulkan által biztosított tempóelőny nélkül.
A gyártók közül egyedül az Intel reagált a kérdésünkre, és elmondták, hogy nagyon logikusnak gondolják ezt a koncepciót, és szívesen támogatnak minden olyan kezdeményezést, amely egyszerűsíti a grafikus meghajtók fejlesztését. Szintén megtudtuk, hogy a Microsoft a Windows 10-ben is kínál egy hasonló lehetőséget, így a DirectX 11-re írt programokat az új operációs rendszer alól úgy is lehet futtatni, hogy az adott meghajtóban csak DirectX 12-es implementáció van. Ez a koncepció is egy beépített wrapperen keresztül működik, és a DirectX 12 sebességelőnyeit ugyan nem kínálja fel, de a programfuttatás ismét csak biztosítható.
Az Intel szerint az lenne az ideális, ha az OpenGL és a DirectX 11 direkt támogatását a távolabbi jövőben le lehetne állítani, és ezek helyét átvenné egy Vulkan és DirectX 12 API-n futó wrapper. Ennek következtében a meghajtók fejlesztése leegyszerűsödne, miközben a fejlesztők továbbra is képesek lennének futtatni – egy nem natív eléréssel – az OpenGL és a DirectX 11 API-ra írt programokat.
