Kötelező lesz a Vulkan 1.1 a 64 bites Android Q-s eszközökön

A 32 bites megoldásoknál ez az igény elhagyható, de a Google ezekhez is nagyon ajánl egy megfelelő implementácót.

Nagyjából egy éve számoltunk be arról, hogy jön a Vulkan 1.1 az Android P-be, de most a Google sebességfokozatot vált, így a mérsékelt újításokkal érkező Android Q esetében az említett API-t már kötelezően előírják a 64 bites eszközöknél. A 32 bites hardverek esetében a támogatás elhagyható, de nagyon nem ajánlja a keresőóriás.

Valószínűleg a Google döntése különösebb gondot nem fog okozni a gyártóknak, mivel már most is számos eszközön van Vulkan implementáció, annak ellenére, hogy ez korábban nem volt követelmény. A licencelhető grafikus vezérlők fejlesztői is folyamatosan javítják a Vulkan meghajtókat, az már más kérdés, hogy az eszközök gyártói ezeket ritkán frissítik.

A Vulkan API egyébként abból a szempontból fontos a Google-nek, hogy az ANGLE projekt végre bevethető legyen Androidon. Ez az új operációs rendszeren belül kíséreti fázisban lesz, de kihasználható, ami a tesztek elkezdéséhez szükséges. A keresőóriás problémája az, hogy az OpenGL ES rendkívül erős fragmentációt okoz Androidon belül, amit eddig nem tudtak kezelni. A gondok gyökere ott keletkezik, hogy a gyártók specifikus meghajtókat szállítanak, és ezek egyszerűen nem ugyanúgy kezelik a kódokat, annak ellenére sem, hogy az OpenGL ES API különböző verziói szabványnak tekinthetők.

A gyártók oldaláról erre biztos nem lesz megoldás, mivel eddig sem mutatkozott hajlandóság a probléma felszámolására, így a Google úgy döntött, hogy saját kézbe veszik a dolgokat. Az Android Q-ba implementáltak egy olyan OpenGL ES implementációt, amely a Vulkan API-n fut, így a fejlesztők eldönthetik, hogy az alkalmazás az eszközhöz szállított, gyártóspecifikus OpenGL ES meghajtót használja, vagy a Google Vulkan API-n futó ANGLE rétegét, amely képes futtatni az OpenGL ES API-ra írt szabványos kódokat. Utóbbinak az előnye, hogy minden Android Q rendszer egységes lesz, vagyis ha az egyiken fut az OpenGL ES API-ra írt program, akkor garantált, hogy mindegyiken fog. Hátránya, hogy egyelőre még kísérleti fejlesztésről van szó, de a cég azt ígéri, hogy sűrűn fogják frissíteni, mivel tényleg egy komoly problémát tudnak vele kezelni.

Fontos kiemelni, hogy a felhasználó sosem dönthet majd arról, hogy melyik OpenGL ES implementáción futhat az adott alkalmazás, erről vagy a program tartalmaz egy bejegyzést, ami alapján külön kéri az egyik opciót, vagy az adott eszköz gyártója dönthet erről egy szoftverfrissítésben. Utóbbi nem lesz jellemző, a Google csupán azért építette be ezt a lehetőséget a rendszerbe, hogy ha egy alkalmazással valami gond van, de a fejlesztők nem hajlandók, vagy nem tudják javítani, akkor a gyártók képesek legyen valamit tenni a működés érdekében.

Azóta történt

Előzmények

Hirdetés