Implementare OpenGL ES ed EGL

OpenGL è un'API grafica multipiattaforma che specifica un'interfaccia software standard per l'hardware di elaborazione della grafica 3D. OpenGL ES è un sottoinsieme della specifica OpenGL per i dispositivi embedded.

Per essere compatibili con Android, i dispositivi è necessario fornire driver per EGL, OpenGL ES 1.x e OpenGL ES 2.0. Assistenza per OpenGL ES 3.x è facoltativo. Le considerazioni chiave includono:

• Assicurarsi che il driver GL sia affidabile e conforme agli standard OpenGL ES.
• Consente un numero illimitato di contesti GL. Poiché Android consente app in background e tenta di mantenere attivi i contesti GL, limitare il numero di contesti nel driver.
• Fare attenzione alla quantità di memoria allocata per ogni contesto, è comune avere 20-30 contesti GL attivi contemporaneamente.
• Supporto del formato immagine YV12 e di altri formati di immagini YUV provenienti da altri componenti del sistema, come i codec multimediali o la videocamera.
• Supporto delle estensioni obbligatorie EGL_KHR_wait_sync, GL_OES_texture_external, EGL_ANDROID_image_native_buffer e EGL_ANDROID_recordable. Inoltre, Hardware Composer v1.1 e superiori richiedono EGL_ANDROID_framebuffer_target .

Ti consigliamo vivamente di supportare anche EGL_ANDROID_blob_cache, EGL_KHR_fence_sync e EGL_ANDROID_native_fence_sync.

Android 10 implementa l'interfaccia eSIM 1.5. Per informazioni sulle nuove funzionalità in EGL 1.5, consulta la specifica di Khronos Releases 1.5.

Nota: l'API OpenGL esposta all'app rispetto alla modalità OpenGL implementata sul dispositivo. Le app non possono accedere direttamente al livello del driver GL e devono passare per l'interfaccia fornita dalle API.

Caricamento del driver

Android si aspetta che le GPU disponibili per il sistema siano note al momento della compilazione dell'immagine di sistema. I percorsi preferiti per i driver OpenGL ES a 32 e 64 bit sono rispettivamente /vendor/lib/egl e /vendor/lib64/egl. Il loader utilizza due proprietà di sistema: ro.hardware.egl e ro.board.platform o il valore esatto per scoprire e caricare i driver di sistema. Il driver OpenGL ES deve essere sono forniti in un file binario o suddivisi in tre file binari. Se la modalità OpenGL ES che viene spedito in un unico file binario, usa uno dei seguenti nomi:

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

Se il driver OpenGL ES viene distribuito in tre file binari, utilizza uno dei i seguenti set di nomi:

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

Livelli OpenGL ES

Android 10 introduce un sistema di stratificazione per GLES 2.0 e versioni successive. Gli strati GLES sono oggetti condivisi disponibili all'interno delle app o forniti da strumenti. I livelli GLES consentono alle app di cui è possibile eseguire il debug di scoprire e caricare i livelli utilizzando gli stessi meccanismi di configurazione Vulkan.

Attenzione: quando il layering è attivato, le funzioni esclusive di GLES 1.x continuano a essere inoltrate ai driver GLES 1.x, ma le funzioni condivise con GLES 2.0 e versioni successive vengono inoltrate ai driver 2.0 e versioni successive.

GLES LayerLoader, un componente all'interno del caricatore EGL, identifica i livelli GLES. Per ogni livello trovato da GLES LayerLoader, GLES LayerLoader chiama AndroidGLESLayer_Initialize, esamina gli elenchi di funzioni di libEGL e chiama AndroidGLESLayer_GetProcAddress per tutte le funzioni conosciute. Se il livello intercetta una funzione, ne monitora l'indirizzo. Se il livello non intercetta una funzione, AndroidGLESLayer_GetProcAddress restituisce la stessa funzione a cui è stato trasmesso. LayerLoader aggiorna l'elenco di hook delle funzioni punta al punto di ingresso del livello.

Attivare i livelli

Nota: il modello e i criteri di sicurezza di Android differiscono notevolmente da quelli di altre piattaforme. Android consente solo a chi ha accesso come amministratore di caricare i livelli GLES dallo spazio di archiviazione locale di un dispositivo. Senza l'accesso root, i livelli GLES possono essere caricati solo per le app di cui è possibile eseguire il debug.

Puoi attivare i livelli GLES per app o a livello globale. Le impostazioni per app rimangono invariate dopo i riavvii, mentre le proprietà globali vengono cancellate al riavvio.

Per attivare i livelli per app:

# 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

Per disattivare i livelli per app:

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

Per attivare i livelli a livello globale:

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

Livelli di test

I livelli GLES sono supportati dai CTS di Android e sono necessari per superare i test CTS per dispositivi compatibili. Per identificare se i livelli funzionano su un dispositivo, esegui $ atest CtsGpuToolsHostTestCases.