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 quesystem.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 desystem.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
.
Bibliothèques RenderScript | Bibliothèques non-RenderScript |
---|---|
|
|
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) dlopen
ed 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
ouOVERRIDE_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 partitionvendor
. 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 partitionvendor
via le fournisseur SEPolicy doit comporter l'attributvendor_file_type
. Cette règle est appliquée vianeverallows
. - 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 partitionvendor
. - 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 |
|
Lien |
|
Chargement |
|
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éfautandroid.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:
- 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. - Appeler le champ Cci du système:
/system/bin/bcc
avec une valeur fournie par le fournisseurbcc 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.
- Copiez
libclcore.bc
dans la partition/vendor
. Ce garantitlibclcore.bc
,libLLVM.so
etlibbcc.so
sont synchronisés. - Modifiez le chemin d'accès à l'exécutable
bcc
en définissantRsdCpuScriptImpl::BCC_EXE_PATH
à partir de l'implémentation RS HAL.
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:
- PRODUCT_SHIPPING_API_LEVEL est inférieur à 26.
- 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:
- Migrer depuis Renderscript
- Exemple RenderScriptMigration
- Kit de remplacement des fonctionnalités intrinsèques README
- Remplacement des fonctionnalités intrinsèquesToolkit.kt