RenderScript

<ph type="x-smartling-placeholder">

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 von system.img aktualisiert. Bibliotheken in /system/lib/vndk-sp sind für den Anbieter konzipiert und nicht aktualisiert, wenn system.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.

<ph type="x-smartling-placeholder">
RenderScript-Bibliotheken Nicht-RenderScript-Bibliotheken
  • android.hardware.graphics.renderscript@1.0.so
  • libRS_internal.so
  • libRSCpuRef.so
  • libblas.so
  • libbcinfo.so
  • libcompiler_rt.so
  • libRSDriver.so
  • libc.so
  • libm.so
  • libdl.so
  • libstdc++.so
  • liblog.so
  • libnativewindow.so
  • libsync.so
  • libvndksupport.so
  • libbase.so
  • libc++.so
  • libcutils.so
  • libutils.so
  • libhardware.so
  • libhidlbase.so
  • libhidltransport.so
  • libhwbinder.so
  • liblzma.so
  • libz.so
  • libEGL.so
  • libGLESv1_CM.so
  • libGLESv2.so

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 dlopenaus 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 dlopened 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 oder OVERRIDE_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: Partition vendor. Gemäß den Plattformrichtlinien ist dies für den Zugriff erforderlich Passthrough-HAL-Implementierungen.
  • Alle neuen exec_types in der Partition vendor hinzugefügt über die SEPolicy des Anbieters muss das Attribut vendor_file_type haben. Dies wird über neverallows erzwungen.
  • Vermeiden Sie Labels, um Konflikte mit zukünftigen Plattform-/Framework-Updates zu vermeiden. Andere Dateien als exec_types in der Partition vendor
  • 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
  • Der Eingabebitcode (.bc) für bcc muss im LLVM 3.2-Bitcodeformat und bcc muss rückwärts sein ist mit vorhandenen (älteren) Apps kompatibel.
  • Die Metadaten in .bc können sich jedoch ändern (es könnte neue Laufzeiten Funktionen wie Zuweisungs-Setter &mp; Getter, mathematischen Funktionen usw. Teil der Laufzeitfunktionen befindet sich in libclcore.bc, ein Teil davon in LibRSDriver oder einem entsprechenden Anbieterkonto gespeichert.
  • Neue Laufzeitfunktionen oder funktionsgefährdende Änderungen an Metadaten erfordern eine Inkrementierung Bitcode-API-Ebene. Da Lieferantentreiber diese nicht nutzen können, die HAL-Version muss ebenfalls erhöht werden.
  • Die Anbieter haben möglicherweise eigene Compiler, aber die Schlussfolgerungen/Anforderungen für bcc gelten auch für diese Compiler.
Link
  • Das kompilierte „.o“ wird mit dem Anbietertreiber verknüpft, z.B. libRSDriver_foo.so und libcompiler_rt.so. Die CPU Pfad wird mit libRSDriver.so verknüpft.
  • Wenn .o eine neue Laufzeit-API von libRSDriver_foo erfordert, muss der Anbietertreiber aktualisiert werden, um ihn zu unterstützen.
  • Bestimmte Anbieter haben vielleicht eigene Verlinker, aber das Argument für Für sie gelten auch ld.mc.
Laden
  • libRSCpuRef lädt das gemeinsam genutzte Objekt. Wenn es ein HAL-Versions-Bump erforderlich ist.
  • Anbieter verlassen sich beim Laden der freigegebenen Datei entweder auf libRSCpuRef oder ein eigenes Objekt implementieren.

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 Standardimplementierung android.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:

  1. 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.
  2. System-Bcc: /system/bin/bcc mit einem vom Anbieter bereitgestellten bcc 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.

  1. Kopieren Sie libclcore.bc in die Partition /vendor. Dieses stellt libclcore.bc, libLLVM.so und libbcc.so sind synchronisiert.
  2. Ändern Sie den Pfad in die ausführbare Datei bcc, indem Sie Folgendes festlegen: RsdCpuScriptImpl::BCC_EXE_PATH aus der RS HAL-Implementierung.
<ph type="x-smartling-placeholder">

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:

  1. PRODUCT_SHIPPING_API_LEVEL ist niedriger als 26.
  2. 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: