RenderScript

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

RenderScript est un framework permettant d'exécuter des charges de travail nécessitant beaucoup de ressources de calcul des tâches avec des performances élevées sur Android. Il est conçu pour être utilisé avec le calcul parallélisé des données, bien que les charges de travail en série puissent également en bénéficier. La L'environnement d'exécution RenderScript parallélise les tâches sur les processeurs disponibles sur un tels que les processeurs et GPU multicœurs, ce qui permet aux développeurs de se concentrer d'exprimer des algorithmes plutôt que de planifier le travail. RenderScript est particulièrement Il est utile pour les applications qui traitent des images, la photographie ou la vision par ordinateur.

Les appareils équipés d'Android 8.0 ou version ultérieure utilisent le RenderScript suivant les HAL du framework et des fournisseurs:

Figure 1 : Code fournisseur redirigeant vers les bibliothèques internes.

Les différences par rapport à RenderScript sur Android 7.x et versions antérieures incluent les suivantes:

  • Deux instances de bibliothèques internes RenderScript dans un processus. Un ensemble est pour Chemin de remplacement du processeur ; il provient directement de /system/lib ; l'autre correspond au chemin d'accès au GPU et provient de /system/lib/vndk-sp.
  • Les bibliothèques internes RS dans /system/lib sont créées dans le et sont mises à jour en même temps que system.img. En revanche, les bibliothèques dans /system/lib/vndk-sp sont conçus pour le fournisseur et ne sont pas mis à jour lors de la mise à niveau de system.img (bien qu'ils puissent être mis à jour) pour un correctif de sécurité, leur ABI reste la même).
  • Le code fournisseur (RS HAL, pilote RS et bcc plugin) est le suivant : lié aux bibliothèques internes RenderScript situées dans /system/lib/vndk-sp Ils ne peuvent pas être associés à des bibliothèques /system/lib, car les bibliothèques de ce répertoire sont conçues pour plate-forme et peuvent donc ne pas être compatibles avec le code fournisseur (c'est-à-dire les symboles peuvent être supprimées). Cela rendrait une OTA uniquement basée sur le framework impossible.

Conception

Les sections suivantes détaillent la conception de RenderScript dans Android 8.0 et versions ultérieures.

Bibliothèques RenderScript disponibles pour les fournisseurs

Cette section présente les bibliothèques RenderScript (appelées NDK fournisseur pour Same-Process). HAL ou VNDK-SP) disponibles pour le code fournisseur et pouvant être associées par rapport à. Il détaille également des bibliothèques supplémentaires sans rapport avec RenderScript, mais qui sont également fournis au code du fournisseur.

Bien que la liste de bibliothèques suivante puisse différer selon les versions d'Android, il est immuable pour une version spécifique d'Android. pour obtenir une liste à jour bibliothèques disponibles, consultez /system/etc/ld.config.txt.

<ph type="x-smartling-placeholder">
Bibliothèques RenderScript Bibliothèques non-RenderScript
  • 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

Configuration de l'espace de noms Linker

Restriction d'association qui empêche l'utilisation des bibliothèques non présentes dans VNDK-SP le code du fournisseur est appliqué au moment de l'exécution à l'aide de l'espace de noms de l'éditeur de liens. (Pour en savoir plus, consultez le document VNDK Design présentation.)

Sur un appareil équipé d'Android 8.0 ou version ultérieure, toutes les HAL Same-Process (SP-HAL) à l'exception de RenderScript, sont chargés dans l'espace de noms de l'éditeur de liens. sphal RenderScript est chargé dans la classe spécifique à RenderScript espace de noms rs, un emplacement qui permet pour les bibliothèques RenderScript. Comme l'implémentation RS doit charger le bitcode compilé, /data/*/*.so, est ajouté au chemin d'accès Espace de noms rs (les autres SP-HAL ne sont pas autorisés à charger des bibliothèques à partir du partition de données).

De plus, l'espace de noms rs autorise plus de bibliothèques que celles fournies pour par d'autres espaces de noms. libmediandk.so et libft2.so sont exposés à l'espace de noms rs, car libRS_internal.so possède une dépendance interne à ces bibliothèques.

Figure 2. Configuration de l'espace de noms pour l'éditeur de liens.

Charger les pilotes

Chemin de remplacement pour le processeur

En fonction de l'existence du bit RS_CONTEXT_LOW_LATENCY lors de la création d'un contexte RS, le chemin d'accès au processeur ou au GPU est sélectionné. Lorsque Le chemin d'accès au processeur est sélectionné, libRS_internal.so (l'implémentation principale du framework RS) est directement dlopen liée à l'éditeur de liens par défaut. espace de noms dans lequel la version de plate-forme des bibliothèques RS est fournie.

L'implémentation RS HAL du fournisseur n'est pas du tout utilisée lorsque le CPU chemin de remplacement est utilisé, et un objet RsContext est créé avec mVendorDriverName nul. libRSDriver.so est (par (default) dlopened et la bibliothèque du pilote est chargée à partir du default, car l'appelant (libRS_internal.so) est également chargé dans default. espace de noms.

Figure 3. Chemin d'accès de remplacement pour le processeur.

Chemin d'accès au GPU

Pour le chemin d'accès au GPU, libRS_internal.so est chargé différemment. Tout d'abord, libRS.so utilise android.hardware.renderscript@1.0.so (et ses propriétés sous-jacentes libhidltransport.so) à charger android.hardware.renderscript@1.0-impl.so (un fournisseur mise en œuvre de RS HAL) dans un espace de noms d'éditeur de liens différent appelé sphal The RS HAL, puis dlopen libRS_internal.so dans un autre espace de noms de l'éditeur de liens appelé rs.

Les fournisseurs peuvent fournir leur propre pilote RS en définissant l'indicateur de durée de compilation OVERRIDE_RS_DRIVER, qui est intégré au RS HAL implémentation (hardware/interfaces/renderscript/1.0/default/Context.cpp). Ce le nom du pilote est ensuite dlopen pour le contexte RS du chemin d'accès au GPU.

La création de l'objet RsContext est déléguée au RS HAL la mise en œuvre. Le HAL appelle le framework RS à l'aide de rsContextCreateVendor() par le nom du pilote à utiliser comme argument. Le framework RS charge ensuite le pilote spécifié lorsque le RsContext est initialisé. Dans ce cas, la bibliothèque de pilotes est chargé dans l'espace de noms rs, car la commande RsContext est créé dans l'espace de noms rs et /vendor/lib se trouve dans le chemin de recherche de l'espace de noms.

Figure 4. Chemin d'accès de remplacement pour le GPU.

Lors de la transition de l'espace de noms default vers sphal, libhidltransport.so utilise android_load_sphal_library() pour ordonner explicitement l'éditeur de liens dynamique pour charger la bibliothèque -impl.so à partir de sphal.

Lors de la transition de l'espace de noms sphal vers rs, le chargement est effectué indirectement par la ligne suivante dans /system/etc/ld.config.txt: 

namespace.sphal.link.rs.shared_libs = libRS_internal.so

Cette ligne indique que l'éditeur de liens dynamique doit se charger. libRS_internal.so à partir de l'espace de noms rs lorsque la commande ne peut pas être trouvé/chargé à partir de l'espace de noms sphal (qui est toujours car l'espace de noms sphal ne recherche pas /system/lib/vndk-sp où libRS_internal.so se trouve). Avec cette configuration, un simple appel dlopen() libRS_internal.so est suffisant pour effectuer la transition de l'espace de noms.

Charger le plug-in Cci

bcc plugin est une bibliothèque fournie par le fournisseur et chargée dans le Compilateur bcc. Comme bcc est un processus système dans /system/bin, la bibliothèque bcc plugin peut être considéré comme un SP-HAL (c'est-à-dire un HAL de fournisseur pouvant être chargé directement dans processus système sans être liés). En tant que SP-HAL, Bibliothèque bcc-plugin:

  • Impossible d'établir un lien avec des bibliothèques uniquement basées sur le framework, telles que libLLVM.so
  • Ne peut être associée qu'aux bibliothèques VNDK-SP disponibles pour le fournisseur.

Cette restriction est appliquée en chargeant bcc plugin dans sphal à l'aide de l'espace de noms Fonction android_sphal_load_library(). Dans les versions précédentes de Android, le nom du plug-in a été spécifié à l'aide de l'option -load. la bibliothèque a été chargée à l'aide du simple dlopen() en libLLVM.so Dans Android 8.0 et versions ultérieures, cela est spécifié dans le -plugin. La bibliothèque est chargée directement par la bcc. Cette option active un chemin d'accès non spécifique à Android vers le projet Open Source LLVM.

Figure 5. Chargement du plug-in Cci, Android 7.x et versions antérieures.



Figure 6. Chargement du plug-in Cci, Android 8.0 ou version ultérieure.

Chemins de recherche pour ld.mc

Lors de l'exécution de ld.mc, certaines bibliothèques d'exécution RS sont fournies en tant qu'entrées à l'éditeur de liens. Le bitcode RS de l'application est associé aux bibliothèques d'exécution Lorsque le bitcode converti est chargé dans un processus d'application, les bibliothèques d'exécution sont à nouveau liés dynamiquement à partir du bitcode converti.

Les bibliothèques d'exécution incluent:

  • libcompiler_rt.so
  • libm.so
  • libc.so
  • Pilote RS (libRSDriver.so ou OVERRIDE_RS_DRIVER).

Lors du chargement du bitcode compilé dans le processus de l'application, fournissez exactement la même utilisée par ld.mc. Sinon, le bitcode compilé peut ne pas trouver un symbole qui était disponible lors de l'association.

Pour ce faire, le framework RS utilise différents chemins de recherche pour les bibliothèques d'exécution lorsque exécuter ld.mc, selon que le framework RS lui-même est chargé depuis /system/lib ou /system/lib/vndk-sp. Cela peut être déterminé en lisant l'adresse d'un symbole arbitraire d'une RS framework lib et en utilisant dladdr() pour mapper le chemin d'accès au fichier l'adresse.

Règles SELinux

En raison des modifications apportées aux règles SELinux dans Android 8.0 et versions ultérieures, vous devez suivre des règles spécifiques (appliquées via neverallows) lorsque : ajout de libellés à des fichiers supplémentaires dans la partition vendor:

  • vendor_file doit être le libellé par défaut pour tous les fichiers de la partition vendor. La règle de la plate-forme l'exige pour accéder implémentations HAL passthrough.
  • Toutes les nouvelles exec_types ont été ajoutées à la partition vendor via le fournisseur SEPolicy doit comporter l'attribut vendor_file_type. Cette règle est appliquée via neverallows.
  • Pour éviter les conflits avec les futures mises à jour de la plate-forme/du framework, évitez d'ajouter des libellés. des fichiers autres que exec_types dans la partition vendor.
  • Toutes les dépendances de bibliothèque pour les HAL de processus identiques identifiées par AOSP doivent être libellé same_process_hal_file.

Pour plus d'informations sur les règles relatives à SELinux, consultez Linux avec sécurité renforcée sur Android

Compatibilité avec les ABI pour le bitcode

Si aucune nouvelle API n'est ajoutée (ce qui signifie qu'il n'y a pas de version HAL), les frameworks RS continuera d'utiliser le pilote de GPU existant (HAL 1.0).

Pour les modifications HAL mineures (HAL 1.1) n'affectant pas le bitcode, les frameworks doivent utiliser le processeur de remplacement pour ces nouvelles API et continuer à utiliser le pilote de GPU (HAL 1.0) ; ailleurs.

Pour les modifications HAL importantes (HAL 2.0) affectant la compilation/l'association de bitcode, RS les frameworks doivent choisir de ne pas charger les pilotes de GPU fournis par le fournisseur utilisez le chemin du processeur ou de Vulkan pour l'accélération.

L'utilisation du bitcode RenderScript s'effectue en trois étapes:

Étape Détails
Compiler
  • Le bitcode d'entrée (.bc) pour bcc doit être au format Le format de bitcode LLVM 3.2 et la valeur bcc doivent être inversés compatible avec les anciennes applications existantes.
  • Cependant, les métadonnées de .bc pourraient changer (de nouveaux paramètres d'exécution fonctions (par exemple, Setters d'allocation &mp; les getters, les fonctions mathématiques, etc.). Partie des fonctions d'exécution se trouvent dans libclcore.bc, dont une partie réside dans LibRSDriver ou son équivalent fournisseur.
  • Les nouvelles fonctions d'exécution ou les modifications destructives de métadonnées nécessitent une incrémentation le niveau d'API bitcode. Comme les pilotes de fournisseurs ne pourront pas les utiliser, la version HAL doit également être incrémentée.
  • Les fournisseurs peuvent avoir leurs propres compilateurs, mais les conclusions/exigences pour bcc s'appliquent également à ces compilateurs.
Lien
  • Le .o compilé sera associé au pilote du fournisseur, par exemple libRSDriver_foo.so et libcompiler_rt.so. Le processeur chemin d'accès sera associé à libRSDriver.so.
  • Si le fichier .o nécessite une nouvelle API d'exécution depuis libRSDriver_foo, le pilote du fournisseur doit être mis à jour pour le prendre en charge.
  • Certains fournisseurs peuvent avoir leurs propres liens, mais l'argument de Les ld.mc s'appliquent également.
Chargement
  • libRSCpuRef charge l'objet partagé. S'il y a modifications apportées à cette interface, une mise à niveau de la version HAL est nécessaire.
  • Les fournisseurs s'appuient sur libRSCpuRef pour charger le fichier ou d'implémenter les leurs.

Outre le HAL, les API d'exécution et les symboles exportés sont également de commande. Aucune de ces deux interfaces n'a changé depuis Android 7.0 (API 24), nous ne prévoyons pas de le changer dans l'immédiat sous Android 8.0 et versions ultérieures. Toutefois, si le l'interface change, la version HAL s'incrémente également.

Implémentations par les fournisseurs

Android 8.0 ou version ultérieure nécessite certaines modifications du pilote de GPU pour que celui-ci puisse fonctionnent correctement.

Modules pilotes

  • Les modules pilotes ne doivent dépendre d'aucune bibliothèque système la liste.
  • Le conducteur doit fournir ses propres android.hardware.renderscript@1.0-impl_{NAME}, ou déclarez le implémentation par défaut android.hardware.renderscript@1.0-impl en tant que sa dépendance.
  • L'implémentation du processeur libRSDriver.so est un bon exemple de la méthode à suivre supprimer les dépendances non-VNDK-SP.

Compilateur de bitcode

Vous pouvez compiler le bitcode RenderScript pour le pilote du fournisseur de deux manières:

  1. Appeler le compilateur RenderScript spécifique au fournisseur dans /vendor/bin/ (méthode préférée de compilation GPU). Comme pour les autres modules pilotes, Le binaire du compilateur du fournisseur ne peut pas dépendre d'une bibliothèque système qui ne figure pas dans le liste des bibliothèques RenderScript disponibles pour les fournisseurs.
  2. Appeler le champ Cci du système: /system/bin/bcc avec une valeur fournie par le fournisseur bcc plugin; ce plug-in ne peut pas dépendre d'une bibliothèque système qui ne figure pas dans la liste des Bibliothèques RenderScript disponibles aux fournisseurs.

Si le fournisseur bcc plugin doit interférer avec le processeur la compilation et sa dépendance à libLLVM.so ne peuvent pas être supprimé, le fournisseur doit copier bcc (et tous les composants autres que LL-NDK) dépendances, y compris libLLVM.so, libbcc.so) dans Partition /vendor.

Les fournisseurs doivent également apporter les modifications suivantes:

Figure 7. Modifications apportées au pilote du fournisseur.

  1. Copiez libclcore.bc dans la partition /vendor. Ce garantit libclcore.bc, libLLVM.so et libbcc.so sont synchronisés.
  2. Modifiez le chemin d'accès à l'exécutable bcc en définissant RsdCpuScriptImpl::BCC_EXE_PATH à partir de l'implémentation RS HAL.
<ph type="x-smartling-placeholder">

Règles SELinux

La règle SELinux s'applique à la fois au pilote et aux exécutables du compilateur. Tout les modules pilotes doivent être libellés same_process_hal_file dans file_contexts de votre appareil. Exemple : 

/vendor/lib(64)?/libRSDriver_EXAMPLE\.so     u:object_r:same_process_hal_file:s0

L'exécutable du compilateur doit pouvoir être appelé par un processus d'application, comme le fait la copie du Cci (/vendor/bin/bcc) du fournisseur. Par exemple: 

device/vendor_foo/device_bar/sepolicy/file_contexts:
/vendor/bin/bcc                    u:object_r:same_process_hal_file:s0

Anciens appareils

Les anciens appareils sont ceux qui remplissent les conditions suivantes:

  1. PRODUCT_SHIPPING_API_LEVEL est inférieur à 26.
  2. PRODUCT_FULL_TREBLE_OVERRIDE n'est pas défini.

Pour les anciens appareils, les restrictions ne sont pas appliquées lors de la mise à niveau vers Android 8.0 ou version ultérieure, ce qui signifie que les pilotes peuvent continuer à être associés à des bibliothèques dans /system/lib[64]. Toutefois, en raison du changement d'architecture en lien avec OVERRIDE_RS_DRIVER, android.hardware.renderscript@1.0-impl doit être installé pour Partition /vendor ; en cas d'échec, l'exécution de RenderScript sera forcée au chemin d'accès au processeur.

Pour en savoir plus sur les raisons de l'abandon de Renderscript, consultez la documentation Blog: Android GPU Compute Going Forward (À venir sur le calcul GPU Android). Les informations sur les ressources liées à cet abandon incluent les suivantes: