A Valve programozója az OpenGL kritizálásával elérte, hogy egyre több fejlesztő elmondja véleményét a grafikus API-k helyzetéről. Bár ezt sokan még mindig óvatosan teszik, így jelzik is, hogy a véleményüket nem biztos, hogy osztják a munkaadóik, de soha nem látott bloghullám indult meg ezzel kapcsolatban, és bizony egyértelmű, hogy az amúgy korrigálható problémák (driverek, operációs rendszerek, fejlesztőeszközök) mellett technikai hibák is vannak a nyílt forráskódú API-ban.
Joshua Barczak, a Firaxis vezető grafikai programozója sem maradt adós a véleményével, ami még a Valve programozójánál is velősebb, noha többnyire ugyanazokat a problémákat jellemzi, csak keményebb megfogalmazásokkal él, illetve a technikai részletekbe is belemegy. Nagyon érdekes részlet azonban a GLSL működése, amely alapvető vitát generál. Mint ismeretes, az OpenGL shader fordítása nem egyezik meg azzal a modellel, amit a DirectX alkalmaz a HLSL esetében. A nyílt forráskódú API-ban a fordítót az adott grafikus meghajtó tartalmazza, és tulajdonképpen teljes egészében ez felel a shader adott hardverre való lefordításáért. Ezzel szemben a Microsoft API-jában van egy szabványos referenciafordító, amely a shadert előbb egy szabványos reprezentációra fordítja, ami tulajdonképpen a Direct3D bájtkód, majd az adott grafikus meghajtó ezt a kódot fordítja le az adott hardverre.
Ha a működés lépcsőit tekintjük, akkor az OpenGL és a DirectX is ugyanazt teszi. A magas szintű forráskódból egy reprezentáció készül, azaz a fordítás előbb egy virtuális utasításarchitektúrára valósul meg, és abból lesz még egy konverziós lépcső a hardver fizikai utasításarchitektúrájának megfelelően. A különbség csupán annyi, hogy a DirectX egységes virtuális utasításarchitektúrát használ, amit a gyártóknak kötelező támogatni, míg az OpenGL esetében minden gyártó más virtuális utasításarchitektúrát alkalmaz. Elméleti szinten, jól megfogalmazott specifikációk mellett egyikkel sem lehet probléma, de a gyakorlat már nem ezt mutatja.
A DirectX modellje egyrészt nagyon jól használható. Az egységes virtuális utasításarchitektúra garantálja, hogy a magas szintű forráskód minden támogatott rendszeren tökéletesen fut. Ezt a Microsoft még külön ellenőrzi a driverek aláírásánál, tehát maga a koncepció a gyakorlatban is működőképes, és ezt több éve bizonyítja is. Néhány fejlesztő azonban felhozza hátrányként, hogy az egységes virtuális utasításarchitektúra következtében minden hardver ugyanazt tudja, tehát az egyes specifikus képességek nem használhatók ki, illetve a végső fordítás a reprezentációból történik, amely már nem tartalmaz olyan információkat, amelyekre a driver esetleg építhetne az extra optimalizálás szempontjából.
Az OpenGL modellje esetében a Khronos Group szándékosan előtérbe helyezte specifikus képességeket, így nem alkalmaznak egységes virtuális utasításarchitektúrát. Ennek megfelelően mindegyik gyártó szabad kezet kap, hogy beépítsék az egyes hardverek extra képességeinek kihasználhatóságát, emellett a driver több információt kap a fordításhoz, így olyan optimalizációkat is bevethet, ami DirectX alatt lehetetlen. Ez bizonyos nézőpontból kétségtelenül előnyös, de az OpenGL modelljének a hátránya, hogy maga a driver állandóan ellenőrzi, hogy a magas szintű forráskód sematikusan megfelelő-e, ami nem éppen gyors folyamat, így a betöltési idők megnőnek. Ennél is problémásabb az időnként elkerülhetetlen valós idejű shader újrafordítás, ami biztosan akadást fog okozni a program futtatásában. Ezt a fejlesztők képtelenek kivédeni, így együtt kell élni vele.
Sajnos magának az OpenGL API-nak sem tökéletes a specifikálása, ami ahhoz vezet, hogy bizonyos szabványos shaderek nem minden hardveren futnak le. A probléma az, hogy nem nyilvánvaló milyen a szabványos kód, így az egyes hardverekre több shadert is kell írni ugyanarra a feladatra. Ha azt tekintjük, hogy az OpenGL modellje milyen extrát ad, akkor azokat a legtöbb fejlesztő bőven a háttérbe szorítaná, annak érdekében, hogy egységes legyen a virtuális utasításarchitektúra, ami garantálhatja, hogy egy szabványos shader biztosan fut minden kompatibilis hardveren. Tulajdonképpen a GLSL és a HLSL között a fő különbség, hogy utóbbi esetében a Microsoft a gyakorlatban is tökéletes működést tartotta szem előtt, míg a Khronos Group az OpenGL esetében inkább a hardverek egyedi képességeinek kihasználhatóságára koncentrált. Bár ez már feltételezi, hogy optimális shader fordításról sosem beszélhetünk, de ha a gyakorlatban való alkalmazhatóságot nézzük, akkor a Microsoft modellje sokkal kedvezőbb.
