Bemutatkozott az OpenGL ES 3.0

Az OpenGL ES 3.0 érkezéséről már sokszor beszéltek a gyártók, és a Khronos Group sem titkolta, hogy a bejelentést az idei SIGGRAPH rendezvényre tervezik. Ez tulajdonképpen meg is történt, így az új OpenGL ES API megszületett, és rengeteg változást hoz az ultramobil GPU-k piacán.

Hirdetés

Azt talán nem felelőtlenség kijelenteni, hogy a fejlesztők az OpenGL ES 2.0-ért nem rajongtak. Az API alapvetően annak köszönheti sikerét, hogy nem volt más alternatíva. A legnagyobb probléma a pufferformátum specifikációjával volt kapcsolatos. A Khronos Group szakszerűtlenül definiálta az API ezen részét, ami ahhoz a gondhoz vezetett, hogy a gyártók esetenként eltérő pufferformátumot implementáltak, és a fejlesztőknek ezeket a különbségeket direkten le kellett kezelni. A kompatibilitással szintén gond volt, az OpenGL ES 2.0 ugyanis egyáltalán nem volt kompatibilis az első OpenGL ES verziókkal, illetve a multiplatform alkalmazások esetén meg kellett küzdeni a PC-s GPU-knak szánt OpenGL API és az ES verzió jelentősnek mondható különbségeivel, mely egyáltalán nem kedvezett a fejlesztőknek.

Az OpenGL ES 3.0 legnagyobb előnye, hogy felszámolta az előd igen komoly hibáit, így például a pufferformátum specifikációja végre egyértelmű. Az új API-t ugyan nem illik összehasonlítani a DirectX-szel, de a legtöbb olvasó számára ez a felület mond valamit, így a legkönnyebb úgy jellemezni a rendszert, hogy az alapvető funkcionalitás a DirectX 10-re hajaz, de az OpenGL ES 3.0-ból hiányzik a geometry shader. Persze eltérések vannak bőven, ám egy ilyen összehasonlítás ad egy általános képet.

Az OpenGL ES 3.0 a 2.0-s verzióhoz képest bevezeti az occlusion query-t és a geometry instancinget. Előbbi a rajzolás előtt a komplex objektumok helyett először olyan téglaalakú dobozokat helyez el, amelyek az objektum adatait hordozzák. A Z tesztek lefuttatása után azok az objektumok nem lesznek megrajzolva, amelyekről az ellenőrzés során kiderült, hogy nem fognak látszani a végső képkockán. A geometry instancing technika is hasznos, hiszen segítségével a futószalag bármely pontján képes a rendszer bármilyen eddig betöltött objektumot lemásolni és ismét kirajzolni egyetlen utasítással. Ezek persze a PC-s API-kat figyelembe véve messze nem számítanak újdonságnak, de az ultramobil termékek esetében komoly előrelépést jelenthetnek. További újítás, hogy bekerült a több render target támogatása is, mely a deferred render motorok esetében hasznos lehet. Ilyet persze az erősen korlátozott memória-sávszélesség miatt egy ideig nem fogunk látni, de a lehetőség mindenképpen adott. Számottevő változás még, hogy az új API rengeteg új textrúraformátumot támogat.

A legjelentősebb változás, hogy a Khronos Group megpróbálja szabványosítani a textúratömörítést az OpenGL ES 3.0-ban, ez ugyanis tradicionálisan problémás terület. Az API 2.0-s verziója az ETC, az S3TC, a PVRTC és az ATITC formátumokat támogatta. Ezek közül csak az ETC-t kezeli az összes OpenGL ES 2.0-t támogató hardver, de ennek elég gyenge a minősége, így a fejlesztők jellemezően nem is alkalmazzák. A gond tehát mondhatni hatalmas, hiszen előfordulhatott olyan termék a piacon, amely nem fogadta el a program által használt tömörített textúrákat, így egy másik formátumnak megfelelő tartalmat is el kellett készíteni a fejlesztőknek. Jellemző volt persze, hogy az S3TC-t sok gyártó támogatta, és ezért a fejlesztők számára is logikus alternatíva volt, de ez nem válhatott a szabvány részévé, ugyanis a Khronos Group sosem vesz fel olyan technikát az API-ba, amely licenchez kötött. Az S3TC márpedig a HTC tulajdona, és a támogatásához pénzt kér a cég.


[+]

A helyzetet az Ericsson Research oldotta meg, mely cég felajánlotta az ETC textúratömörítési formátumot az OpenGL ES 3.0-s API-ba. Ennek kiegészítése az ETC2 és az EAC, melyek megfelelnek a célnak, legalábbis addig, amíg nem lesz jobb alternatíva. Mivel az ETC szabvány lett, így bárki támogathatja anélkül, hogy licencdíjat kellene fizetni érte. Természetesen a többi textúratömörítési formátum továbbra is elérhető marad, de szabványos és mindenki által támogatott technika mellett elég valószínű, hogy a fejlesztők milyen irányba menetelnek majd.

Az OpenGL ES 3.0 specifikációja már elérhető az alábbi oldalon keresztül. Az ultramobil grafikus vezérlők új generációja természetesen támogatni fogja az új API-t.

Hirdetés

Azóta történt

Előzmények

Hirdetés