Implémenter OpenGL ES et EGL

OpenGL est une API graphique multiplateforme qui spécifie une interface logicielle standard pour le matériel de traitement graphique 3D. OpenGL ES est un sous-ensemble de la spécification OpenGL pour les appareils embarqués.

Pour être compatible avec Android, les appareils doivent fournir des pilotes pour EGL, OpenGL ES 1.x et OpenGL ES 2.0. La prise en charge d'OpenGL ES 3.x est facultative. Les principales considérations comprennent :

• S'assurer que le pilote GL est robuste et conforme aux normes OpenGL ES.
• Autoriser un nombre illimité de contextes GL. Étant donné qu'Android autorise les applications en arrière-plan et essaie de maintenir les contextes GL en vie, vous ne devez pas limiter le nombre de contextes dans votre pilote.
• Soyez conscient de la quantité de mémoire allouée à chaque contexte, car il est courant d'avoir 20 à 30 contextes GL actifs à la fois.
• Prise en charge du format d'image YV12 et d'autres formats d'image YUV provenant d'autres composants du système, tels que les codecs multimédias ou la caméra.
• Prise en charge des extensions obligatoires EGL_KHR_wait_sync , GL_OES_texture_external , EGL_ANDROID_image_native_buffer et EGL_ANDROID_recordable . De plus, Hardware Composer v1.1 et versions ultérieures nécessitent l'extension EGL_ANDROID_framebuffer_target .

Il est fortement recommandé de prendre également en charge EGL_ANDROID_blob_cache , EGL_KHR_fence_sync et EGL_ANDROID_native_fence_sync .

Android 10 implémente l' interface EGL 1.5 . Pour plus d'informations sur les nouvelles fonctionnalités d'EGL 1.5, consultez la spécification Khronos Releases 1.5 .

Remarque : L'API OpenGL exposée aux développeurs d'applications diffère de l'OpenGL implémenté sur l'appareil. Les applications ne peuvent pas accéder directement à la couche pilote GL et doivent passer par l'interface fournie par les API.

Chargement du pilote

Android s'attend à ce que les GPU disponibles pour le système soient connus lors de la création de l'image système. Les chemins préférés pour les pilotes OpenGL ES 32 bits et 64 bits sont respectivement /vendor/lib/egl et /vendor/lib64/egl . Le chargeur utilise deux propriétés système, ro.hardware.egl et ro.board.platform , ou le nom exact pour découvrir et charger les pilotes système. Le pilote OpenGL ES doit être livré dans un seul binaire ou divisé en trois binaires. Si le pilote OpenGL ES est fourni dans un seul binaire, utilisez l'un des noms suivants :

libGLES_${ro.hardware.egl}.so
libGLES_${ro.board.platform}.so
libGLES.so

Si le pilote OpenGL ES est livré dans trois fichiers binaires, utilisez l'un des jeux de noms suivants :

libEGL_${ro.hardware.egl}.so
libGLESv1_CM_${ro.hardware.egl}.so
libGLESv2_${ro.hardware.egl}.so

libEGL_${ro.board.platform}.so
libGLESv1_CM_${ro.board.platform}.so
libGLESv2_${ro.board.platform}.so

libEGL.so
libGLESv1_CM.so
libGLESv2.so

Couches OpenGL ES

Android 10 introduit un système de superposition pour GLES 2.0+. Les couches GLES sont des objets partagés disponibles depuis les applications ou fournis par des outils. Les couches GLES permettent aux applications déboguables de découvrir et de charger des couches en utilisant les mêmes mécanismes de configuration que Vulkan .

Attention : lorsque la superposition est activée, les fonctions exclusives de GLES 1.x continuent d'être acheminées vers les pilotes GLES 1.x, mais les fonctions partagées avec GLES 2.0+ sont acheminées vers les pilotes 2.0+.

GLES LayerLoader, un composant du chargeur EGL, identifie les couches GLES. Pour chaque couche trouvée par GLES LayerLoader, GLES LayerLoader appelle AndroidGLESLayer_Initialize , parcourt les listes de fonctions de libEGL et appelle AndroidGLESLayer_GetProcAddress pour toutes les fonctions connues. Si la couche intercepte une fonction, elle suit l'adresse de la fonction. Si la couche n'intercepte pas une fonction, AndroidGLESLayer_GetProcAddress renvoie la même adresse de fonction qui lui a été transmise. Le LayerLoader met ensuite à jour la liste des hooks de fonction pour pointer vers le point d’entrée de la couche.

Activer les calques

Remarque : Le modèle et les politiques de sécurité d'Android diffèrent considérablement de ceux des autres plates-formes. Android permet uniquement à ceux qui disposent d'un accès root de charger des couches GLES à partir du stockage local d'un appareil. Sans accès root, les couches GLES ne peuvent être chargées que pour les applications déboguables.

Vous pouvez activer les couches GLES soit par application, soit globalement. Les paramètres par application persistent lors des redémarrages, tandis que les propriétés globales sont effacées au redémarrage.

Pour activer les couches par application :

# Enable layers
adb shell settings put global enable_gpu_debug_layers 1

# Specify target app
adb shell settings put global gpu_debug_app package_name

# Specify layer list (from top to bottom)
adb shell settings put global gpu_debug_layers_gles layer1:layer2:...:layerN

# Specify packages to search for layers
adb shell settings put global gpu_debug_layer_app package1:package2:...:packageN

Pour désactiver les calques par application :

adb shell settings delete global enable_gpu_debug_layers
adb shell settings delete global gpu_debug_app
adb shell settings delete global gpu_debug_layer_app

Pour activer les calques globalement :

# Attempts to load layers for all applications, including native executables
adb shell setprop debug.gles.layers layer1:layer2:...:layerN

Couches de test

Les couches GLES sont soutenues par Android CTS et doivent réussir les tests CTS pour les appareils compatibles . Pour identifier si les couches fonctionnent sur un appareil, exécutez $ atest CtsGpuToolsHostTestCases .