OpenGL ES und EGL implementieren

OpenGL ist eine plattformübergreifende Grafik-API, die eine Standardsoftwareschnittstelle für 3D-Grafikverarbeitungshardware angibt. OpenGL ES ist eine Teilmenge der OpenGL-Spezifikation für eingebettete Geräte.

Damit Geräte mit Android kompatibel sind, müssen sie Treiber für EGL, OpenGL ES 1.x und OpenGL ES 2.0 bereitstellen. Die Unterstützung von OpenGL ES 3.x ist optional. Wichtige Überlegungen sind:

• Der GL-Treiber muss robust sein und den OpenGL ES-Standards entsprechen.
• Es wird eine unbegrenzte Anzahl von GL-Kontexten unterstützt. Da Android Apps im Hintergrund zulässt und versucht, GL-Kontexte aktiv zu halten, sollten Sie die Anzahl der Kontexte in Ihrem Treiber nicht begrenzen.
• Achten Sie auf die Menge des Arbeitsspeichers, der jedem Kontext zugewiesen wird, da häufig 20 bis 30 aktive GL-Kontexte gleichzeitig vorhanden sind.
• Unterstützung des YV12-Bildformats und anderer YUV-Bildformate, die von anderen Komponenten im System stammen, z. B. von Medien-Codecs oder der Kamera.
• Unterstützung der obligatorischen Erweiterungen EGL_KHR_wait_sync, GL_OES_texture_external, EGL_ANDROID_image_native_buffer und EGL_ANDROID_recordable Außerdem ist für Hardware Composer 1.1 und höher die EGL_ANDROID_framebuffer_target-Erweiterung erforderlich.

Wir empfehlen dringend, auch EGL_ANDROID_blob_cache, EGL_KHR_fence_sync und EGL_ANDROID_native_fence_sync zu unterstützen.

Android 10 implementiert die EGL 1.5-Schnittstelle. Informationen zu den neuen Funktionen in EGL 1.5 finden Sie in der Khronos Releases 1.5 Specification.

Hinweis:Die OpenGL API, die App-Entwicklern zur Verfügung steht, unterscheidet sich von der auf dem Gerät implementierten OpenGL. Apps können nicht direkt auf die GL-Treiberebene zugreifen, sondern müssen die von den APIs bereitgestellte Schnittstelle verwenden.

Treiber wird geladen

Android erwartet, dass die für das System verfügbaren GPUs bekannt sind, wenn das System-Image erstellt wird. Die bevorzugten Pfade für 32-Bit- und 64-Bit-OpenGL ES-Treiber sind /vendor/lib/egl bzw. /vendor/lib64/egl. Der loader verwendet zwei Systemeigenschaften, ro.hardware.egl und ro.board.platform oder den genauen Namen zum Ermitteln und Laden der Systemtreiber. Der OpenGL ES-Treiber muss entweder in einer Binärdatei oder in drei Binärdateien bereitgestellt werden. Wenn der OpenGL ES-Treiber in einer Binärdatei bereitgestellt wird, verwenden Sie einen der folgenden Namen:

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

Wenn der OpenGL ES-Treiber in drei Binärdateien bereitgestellt wird, verwenden Sie einen der folgenden Namenssätze:

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

OpenGL ES-Ebenen

Android 10 führt ein Schichtsystem für GLES 2.0 und höher ein. GLES-Schichten sind freigegebene Objekte, die in Apps verfügbar sind oder von Tools bereitgestellt werden. Mit GLES-Ebenen können debierbare Apps mit denselben Einrichtungsmechanismen wie Vulkan Ebenen erkennen und laden.

Achtung:Wenn die Schichtung aktiviert ist, werden Funktionen, die nur für GLES 1.x gelten, weiterhin an GLES 1.x-Treiber weitergeleitet. Funktionen, die mit GLES 2.0 und höher gemeinsam genutzt werden, werden jedoch an 2.0- und höher-Treiber weitergeleitet.

GLES LayerLoader, eine Komponente des EGL-Ladeprogramms, identifiziert GLES-Ebenen. Für jede Schicht, die der GLES LayerLoader findet, ruft er AndroidGLESLayer_Initialize auf, durchläuft die Funktionslisten der libEGL und ruft AndroidGLESLayer_GetProcAddress für alle bekannten Funktionen auf. Wenn die Schicht eine Funktion abfängt, wird die Adresse der Funktion erfasst. Wenn die Ebene keine Funktion abfängt, gibt AndroidGLESLayer_GetProcAddress dieselbe Funktionsadresse zurück, die sie übergeben wurde. Der LayerLoader aktualisiert dann die Funktion-Hook-Liste, sodass sie auf den Einstiegspunkt der Ebene verweist.

Ebenen aktivieren

Hinweis:Das Sicherheitsmodell und die Richtlinien von Android unterscheiden sich erheblich von anderen Plattformen. Unter Android können nur Nutzer mit Root-Zugriff GLES-Ebenen aus dem lokalen Speicher eines Geräts laden. Ohne Root-Zugriff können GLES-Ebenen nur für debuggbare Apps geladen werden.

Sie können GLES-Ebenen entweder pro App oder global aktivieren. App-spezifische Einstellungen bleiben nach einem Neustart erhalten, während globale Eigenschaften gelöscht werden.

So aktivieren Sie Ebenen pro 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

So deaktivieren Sie Ebenen pro 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

So aktivieren Sie Ebenen global:

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

Testebenen

GLES-Ebenen werden von Android CTS abgesichert und sind erforderlich, um CTS-Tests für kompatible Geräte zu bestehen. Führen Sie $ atest CtsGpuToolsHostTestCases aus, um zu prüfen, ob Ebenen auf einem Gerät funktionieren.