RenderScript ist ein Framework für rechenintensive Aufgaben auf Android-Geräten mit hoher Leistung ausführen. Es wurde für die Verwendung mit datenparallelen Berechnung, obwohl auch serielle Arbeitslasten von Vorteil sein können. Die Die RenderScript-Laufzeit parallelisiert die Arbeit zwischen den auf einem wie Mehrkern-CPUs und GPUs, sodass sich Entwickler auf Algorithmen auszudrücken, anstatt Arbeit zu planen. RenderScript ist besonders nützlich für Anwendungen zur Bildverarbeitung, Fotografie oder maschinelles Sehen.
Geräte mit Android 8.0 und höher verwenden das folgende RenderScript Framework- und Anbieter-HALs:
Abbildung 1: Anbietercode mit Verknüpfung zu internen Bibliotheken.
Unterschiede zu RenderScript in Android 7.x und niedriger:
- Zwei Instanzen interner RenderScript-Bibliotheken in einem Prozess. Ein Satz ist für
CPU-Fallback-Pfad und stammt direkt von
/system/lib
; der andere "set" bezieht sich auf den GPU-Pfad und stammt aus/system/lib/vndk-sp
. - Interne RS-Bibliotheken in
/system/lib
werden im Rahmen der und werden mit dem Upgrade vonsystem.img
aktualisiert. Bibliotheken in/system/lib/vndk-sp
sind für den Anbieter konzipiert und nicht aktualisiert, wennsystem.img
aktualisiert wird (während sie aktualisiert werden können) für ein Sicherheitsupdate bleibt ihr ABI gleich). - Anbietercode (RS HAL, RS-Treiber und
bcc plugin
) sind die mit den internen RenderScript-Bibliotheken unter/system/lib/vndk-sp
. Sie können keine Links zu Bibliotheken in/system/lib
, da Bibliotheken in diesem Verzeichnis für die Plattform und daher möglicherweise nicht mit dem Anbietercode kompatibel (d.h. Symbole, entfernt werden. Das würde ein reines Framework-OTA-Verfahren unmöglich machen.
Design
In den folgenden Abschnitten wird das RenderScript-Design unter Android 8.0 und höher beschrieben.
Für Anbieter verfügbare RenderScript-Bibliotheken
In diesem Abschnitt sind die RenderScript-Bibliotheken aufgeführt, die als Anbieter NDK für Same-Process bezeichnet werden. HALs oder VNDK-SP), die für den Anbietercode zur Verfügung stehen und verknüpft werden können zu vergleichen. Er enthält auch Informationen zu weiteren Bibliotheken, die nichts mit RenderScript. Sie werden aber auch für den Anbietercode bereitgestellt.
Die folgende Liste der Bibliotheken kann sich je nach Android-Version unterscheiden,
Sie ist für eine bestimmte Android-Version unveränderlich. finden Sie eine aktuelle Liste der
Verfügbare Bibliotheken finden Sie unter /system/etc/ld.config.txt
.
RenderScript-Bibliotheken | Nicht-RenderScript-Bibliotheken |
---|---|
|
|
Konfiguration des Verknüpfungs-Namespace
Die Verknüpfungsbeschränkung, die verhindert, dass Bibliotheken, die nicht in VNDK-SP enthalten sind, von Der Anbietercode wird zur Laufzeit mithilfe des Verknüpfungs-Namespace erzwungen. (Weitere Informationen siehe VNDK Design Präsentation.)
Auf Geräten mit Android 8.0 und höher: alle Same-Process-HALs (SP-HALs)
außer RenderScript werden innerhalb des Verknüpfungs-Namespace geladen.
sphal
RenderScript wird in die RenderScript-spezifische
Namespace rs
, ein Standort, der eine etwas lockerere
-Erzwingung für RenderScript-Bibliotheken. Da die RS-Implementierung
wird der kompilierte Bitcode /data/*/*.so
zum Pfad des
rs
-Namespace (andere SP-HALs dürfen keine Bibliotheken aus dem
Datenpartition).
Außerdem erlaubt der Namespace rs
mehr Bibliotheken als für
von anderen Namespaces. libmediandk.so
und libft2.so
sind im Namespace rs
verfügbar, weil
libRS_internal.so
hat eine interne Abhängigkeit zu diesen Bibliotheken.
Abbildung 2: Namespace-Konfiguration für die Verknüpfung.
Treiber laden
CPU-Fallback-Pfad
Je nachdem, ob das RS_CONTEXT_LOW_LATENCY
-Bit vorhanden ist,
wird beim Erstellen eines RS-Kontexts entweder der CPU- oder GPU-Pfad ausgewählt. Wenn der Parameter
CPU-Pfad ausgewählt, libRS_internal.so
(die Hauptimplementierung
des RS-Frameworks) direkt dlopen
aus der Standardverknüpfung
Namespace, in dem die Plattformversion der RS-Bibliotheken bereitgestellt wird.
Die RS HAL-Implementierung des Anbieters wird überhaupt nicht verwendet,
Fallback-Pfad wird verwendet und ein RsContext
-Objekt wird mit
null mVendorDriverName
. libRSDriver.so
ist (von
dlopen
ed und die Treiber-Bibliothek wird aus dem
default
-Namespace, da der Aufrufer
(libRS_internal.so
) wird auch in default
geladen:
-Namespace auf sie zugegriffen werden.
Abbildung 3: CPU-Fallback-Pfad.
GPU-Pfad
Für den GPU-Pfad wird libRS_internal.so
anders geladen.
Zunächst verwendet libRS.so
android.hardware.renderscript@1.0.so
(und die zugrunde liegenden
libhidltransport.so
) zum Laden
android.hardware.renderscript@1.0-impl.so
(ein Anbieter
Implementierung von RS HAL) in einen anderen Verknüpfungs-Namespace namens
sphal
Der Aufsteiger
HAL, dann dlopen
s libRS_internal.so
in einem anderen
Verknüpfungs-Namespace namens rs
.
Anbieter können ihren eigenen RS-Treiber bereitstellen, indem sie das Flag für die Build-Zeit setzen.
OVERRIDE_RS_DRIVER
, die in den RS HAL eingebettet ist
Implementierung
(hardware/interfaces/renderscript/1.0/default/Context.cpp
) Dieses
Der Treibername wird dann für den RS-Kontext für den GPU-Pfad mit dlopen
festgelegt.
Die Erstellung des RsContext
-Objekts wird an den RS HAL delegiert.
Implementierung. Der HAL ruft das RS-Framework mithilfe von
rsContextCreateVendor()
-Funktion mit dem Namen des Treibers,
als Argument verwenden. Das RS-Framework lädt dann den angegebenen Treiber,
RsContext
wurde initialisiert. In diesem Fall ist die Treiberbibliothek
rs
in den Namespace geladen, weil der RsContext
-Objekt im Namespace rs
erstellt und
/vendor/lib
ist im Suchpfad des Namespace enthalten.
Abbildung 4: GPU-Fallback-Pfad.
Beim Übergang vom default
-Namespace auf den
sphal
-Namespace, libhidltransport.so
verwendet den
android_load_sphal_library()
, um den Parameter
um die -impl.so
-Bibliothek aus dem
sphal
-Namespace.
Beim Übergang vom sphal
-Namespace auf den
rs
-Namespace, wird indirekt über die folgende Zeile in
/system/etc/ld.config.txt
:
namespace.sphal.link.rs.shared_libs = libRS_internal.so
Diese Zeile gibt an, welche dynamische Verknüpfung geladen werden soll.
libRS_internal.so
aus dem Namespace rs
, wenn die Bibliothek
kann nicht aus dem Namespace sphal
gefunden/geladen werden (der immer
da der sphal
-Namespace nicht nach
/system/lib/vndk-sp
, wobei libRS_internal.so
sich befindet). Bei dieser Konfiguration führt ein einfacher dlopen()
-Aufruf für
libRS_internal.so
reicht für die Namespace-Umstellung aus.
Bcc-Plug-in laden
bcc plugin
ist eine vom Anbieter bereitgestellte Bibliothek, die in den
bcc
-Compiler. Da bcc
ein Systemprozess im
/system/bin
enthält, kann die bcc plugin
-Bibliothek
SP-HAL (d.h. ein Anbieter-HAL, der direkt in den
Systemprozess, ohne binderisiert zu werden). Als SP-HAL kann das
bcc-plugin
-Bibliothek:
- Verknüpfungen mit Nur-Framework-Bibliotheken wie
libLLVM.so
- Es kann nur eine Verknüpfung mit den VNDK-SP-Bibliotheken hergestellt werden, die für den Anbieter verfügbar sind.
Diese Einschränkung wird erzwungen, indem bcc plugin
in den
sphal
-Namespace mit dem
android_sphal_load_library()
. In früheren Versionen von
Android ist der Name des Plug-ins mit der Option -load
und
die lib-Bibliothek wurde mit der einfachen dlopen()
von
libLLVM.so
In Android 8.0 und höher wird dies in der
-plugin
und die Bibliothek wird direkt vom
bcc
selbst. Mit dieser Option wird ein nicht Android-spezifischer Pfad zu
das Open-Source-LLVM-Projekt.
Abbildung 5: Bcc-Plug-in wird geladen, Android 7.x und niedriger.
Abbildung 6: Bcc-Plug-in wird geladen, Android 8.0 und höher.
Suchpfade für ld.mc
Beim Ausführen von ld.mc
werden einige RS-Laufzeitbibliotheken als Eingaben angegeben
an die Verknüpfung. Der RS-Bitcode der App ist mit den Laufzeitbibliotheken verknüpft.
Wenn der konvertierte Bitcode in einen Anwendungsprozess geladen wird,
werden wiederum über den konvertierten Bitcode dynamisch verknüpft.
Laufzeitumgebungen enthalten:
libcompiler_rt.so
libm.so
libc.so
- RS-Fahrer (entweder
libRSDriver.so
oderOVERRIDE_RS_DRIVER
)
Wenn Sie den kompilierten Bitcode in den App-Prozess laden,
Bibliothek, die von ld.mc
verwendet wurde. Andernfalls wird der kompilierte Bitcode
ein Symbol, das zum Zeitpunkt der Verknüpfung verfügbar war, möglicherweise nicht.
Dazu verwendet das RS-Framework unterschiedliche Suchpfade für die Laufzeitbibliotheken, wenn
ld.mc
ausführen, je nachdem, ob das RS-Framework selbst
von /system/lib
oder /system/lib/vndk-sp
geladen.
Dies lässt sich ermitteln, indem die Adresse eines beliebigen Symbols eines Aufsteigers gelesen wird.
Framework-Bibliothek und mit dladdr()
, um den Dateipfad abzurufen, der
die Adresse.
SELinux-Richtlinie
Als Folge der SELinux-Richtlinienänderungen unter Android 8.0 und höher müssen Sie
bestimmte Regeln einzuhalten (durch neverallows
erzwungen), wenn
Zusätzliche Dateien in der Partition vendor
mit Labels versehen:
- „
vendor_file
“ muss das Standardlabel für alle Dateien im folgenden Ordner sein: Partitionvendor
. Gemäß den Plattformrichtlinien ist dies für den Zugriff erforderlich Passthrough-HAL-Implementierungen. - Alle neuen
exec_types
in der Partitionvendor
hinzugefügt über die SEPolicy des Anbieters muss das Attributvendor_file_type
haben. Dies wird überneverallows
erzwungen. - Vermeiden Sie Labels, um Konflikte mit zukünftigen Plattform-/Framework-Updates zu vermeiden.
Andere Dateien als
exec_types
in der Partitionvendor
- Alle Bibliotheksabhängigkeiten für durch AOSP identifizierte HALs desselben Prozesses müssen
mit dem Label
same_process_hal_file
.
Einzelheiten zur SELinux-Richtlinie finden Sie unter Sicherheitsfunktionen für Linux unter Android
ABI-Kompatibilität für Bitcode
Werden keine neuen APIs hinzugefügt, d. h., es gibt keinen HAL-Versionssprung, werden die RS-Frameworks verwenden weiterhin den vorhandenen GPU-Treiber (HAL 1.0).
Bei kleineren HAL-Änderungen (HAL 1.1), die sich nicht auf den Bitcode auswirken, sollten die Frameworks für diese neu hinzugefügten APIs auf die CPU zurückgreifen und weiterhin den GPU-Treiber (HAL 1.0) verwenden woanders hin.
Bei größeren HAL-Änderungen (HAL 2.0), die sich auf die Kompilierung/Verknüpfung von Bitcode auswirken, RS Frameworks sollten keine vom Anbieter bereitgestellten GPU-Treiber laden, CPU oder Vulkan-Pfad für die Beschleunigung verwenden.
Die Verarbeitung von RenderScript-Bitcode erfolgt in drei Phasen:
Bühne | Details |
---|---|
Kompilieren |
|
Link |
|
Laden |
|
Neben dem HAL werden auch Laufzeit-APIs und die exportierten Symbole Schnittstellen. Keine der Benutzeroberfläche hat sich seit Android 7.0 (API-Version 24) geändert. gibt es keine unmittelbaren Pläne, dies in Android 8.0 und höher zu ändern. Wenn die ändert sich die HAL-Version ebenfalls.
Implementierungen von Anbietern
Für Android 8.0 und höher sind einige Änderungen an den GPU-Treibern erforderlich, damit der GPU-Treiber ordnungsgemäß funktioniert.
Treibermodule
- Treibermodule dürfen nicht von Systembibliotheken abhängig sein, die sich nicht in zur Liste.
- Der Fahrer muss eine eigene Angabe machen
android.hardware.renderscript@1.0-impl_{NAME}
oder deklarieren Sie die Standardimplementierungandroid.hardware.renderscript@1.0-impl
als deren Abhängigkeit. - Die CPU-Implementierung
libRSDriver.so
ist ein gutes Beispiel dafür, Nicht-VNDK-SP-Abhängigkeiten zu entfernen.
Bitcode-Compiler
Sie können RenderScript-Bitcode für den Anbietertreiber auf zwei Arten kompilieren:
- Anbieterspezifischen RenderScript-Compiler in
/vendor/bin/
aufrufen (bevorzugte Methode der GPU-Kompilierung). Ähnlich wie bei anderen Treibermodulen Die Compiler-Binärdatei des Anbieters darf nicht von einer Systembibliothek abhängig sein, die sich nicht in der Liste der RenderScript-Bibliotheken für Anbieter verfügbar. - System-Bcc:
/system/bin/bcc
mit einem vom Anbieter bereitgestelltenbcc plugin
; Dieses Plug-in darf nicht von einer Systembibliothek abhängig sein, die ist nicht in der Liste der Verfügbare RenderScript-Bibliotheken für die Zulieferunternehmen.
Wenn der Anbieter bcc plugin
die CPU beeinträchtigen muss
Kompilierung und ihre Abhängigkeit von libLLVM.so
können nicht ohne Weiteres
entfernt wurde, sollte der Anbieter bcc
kopieren (und alle Nicht-LL-NDK-
Abhängigkeiten, einschließlich libLLVM.so
und libbcc.so
, in
/vendor
-Partition.
Darüber hinaus müssen Anbieter folgende Änderungen vornehmen:
Abbildung 7: Änderungen am Anbietertreiber.
- Kopieren Sie
libclcore.bc
in die Partition/vendor
. Dieses stelltlibclcore.bc
,libLLVM.so
undlibbcc.so
sind synchronisiert. - Ändern Sie den Pfad in die ausführbare Datei
bcc
, indem Sie Folgendes festlegen:RsdCpuScriptImpl::BCC_EXE_PATH
aus der RS HAL-Implementierung.
SELinux-Richtlinie
Die SELinux-Richtlinie wirkt sich sowohl auf die Treiber als auch die ausführbaren Compiler-Dateien aus. Alle
Treibermodule müssen imsame_process_hal_file
file_contexts
des Geräts. Beispiel:
/vendor/lib(64)?/libRSDriver_EXAMPLE\.so u:object_r:same_process_hal_file:s0
Die ausführbare Compiler-Datei muss wie auch von einem Anwendungsprozess aufgerufen werden können.
Die Anbieterkopie von Bcc (/vendor/bin/bcc
) Hier einige Beispiele:
device/vendor_foo/device_bar/sepolicy/file_contexts: /vendor/bin/bcc u:object_r:same_process_hal_file:s0
Alte Geräte
Als Altgeräte gelten die folgenden Bedingungen:
- PRODUCT_SHIPPING_API_LEVEL ist niedriger als 26.
- PRODUCT_FULL_TREBLE_OVERRIDE ist nicht definiert.
Bei älteren Geräten werden die Einschränkungen beim Upgrade auf
Android 8.0 und höher, d. h., die Treiber können weiterhin auf Bibliotheken verweisen
in „/system/lib[64]
“. Aufgrund der Architekturänderung
in Bezug auf OVERRIDE_RS_DRIVER
,
android.hardware.renderscript@1.0-impl
muss installiert werden für
Partition /vendor
; Andernfalls wird die RenderScript-Laufzeit erzwungen.
Fallback auf den CPU-Pfad.
Informationen über die Gründe für die Einstellung von Renderscript finden Sie auf der Website für Android-Entwickler Blogartikel zu den Themen Android GPU Compute Going Forward Zu den Ressourceninformationen für diese Einstellung gehören:
- Von Renderscript migrieren
- RenderScriptMigration-Beispiel
- Intrinsics Replacement Toolkit README
- Intrinsics ReplacementToolkit.kt