Cette page explique comment implémenter une API Neural Networks (NNAPI)
pilote. Pour en savoir plus, consultez la documentation fournie dans la définition HAL
fichiers dans
hardware/interfaces/neuralnetworks
Un exemple d'implémentation de pilote
frameworks/ml/nn/driver/sample
Pour en savoir plus sur l'API Neural Networks, consultez API Neural Networks
HAL des réseaux de neurones
Le HAL des réseaux de neurones (NN) définit une abstraction des différents appareils,
tels que des processeurs graphiques (GPU) et des processeurs de signal numérique (DSP),
inclus dans un produit (par exemple, un téléphone ou une tablette). Les facteurs à l'origine de ces
doivent être conformes à la norme NN HAL. L'interface est spécifiée dans le HAL
fichiers de définition dans
hardware/interfaces/neuralnetworks
Le flux général de l'interface entre le framework et un pilote est représenté. comme illustré dans la figure 1.
Figure 1 : Flux de réseaux de neurones
Initialisation
Lors de l'initialisation, le framework interroge le pilote pour connaître ses capacités à l'aide de
IDevice::getCapabilities_1_3
La structure @1.3::Capabilities
inclut tous les types de données et
représente les performances non assouplies à l'aide d'un vecteur.
Pour déterminer comment allouer des calculs aux appareils disponibles, le utilise les capacités pour comprendre à quelle vitesse et dans quelle mesure de manière efficace, chaque pilote peut effectuer une exécution. Pour fournir ces informations, le pilote doit fournir des chiffres de performance standardisés en fonction de l'exécution de charges de travail de référence.
Pour déterminer les valeurs renvoyées par le pilote en réponse
IDevice::getCapabilities_1_3
, utilisez l'application de benchmark NNAPI pour mesurer le
des performances pour les types de données correspondants. Les applications MobileNet v1 et v2, asr_float
,
et tts_float
sont recommandés pour mesurer les performances des versions 32 bits
les valeurs à virgule flottante et les modèles quantifiés MobileNet v1 et v2 sont
recommandé pour les valeurs quantifiées sur 8 bits. Pour en savoir plus, consultez
Suite de test de machine learning Android
Sous Android 9 et versions antérieures, la structure Capabilities
inclut les performances du pilote
informations uniquement pour les Tensors quantifiés et à virgule flottante, et n'inclut pas
scalaires.
Lors du processus d'initialisation, le framework peut interroger davantage d'informations,
avec
IDevice::getType
IDevice::getVersionString
IDevice:getSupportedExtensions
et
IDevice::getNumberOfCacheFilesNeeded
.
Entre les redémarrages du produit, le framework attend toutes les requêtes décrites dans ce afin de toujours indiquer les mêmes valeurs pour un conducteur donné. Sinon, une application l'utilisation de ce pilote peut entraîner une baisse des performances ou un comportement incorrect.
Compilation
Le framework détermine les appareils à utiliser lorsqu'il reçoit une requête d'un l'application. Sous Android 10, les applications peuvent détecter et spécifier les appareils que le framework choisit. Pour en savoir plus, consultez Découverte et attribution des appareils :
Au moment de la compilation du modèle, le framework envoie le modèle à chaque candidat
le conducteur en appelant
IDevice::getSupportedOperations_1_3
Chaque pilote renvoie un tableau de valeurs booléennes indiquant quel pilote
les opérations du modèle sont prises en charge. Un conducteur peut déterminer
qu'il ne peut pas
ne prennent pas en charge une opération donnée
pour plusieurs raisons. Exemple :
- Le pilote n'est pas compatible avec ce type de données.
- Le pilote n'accepte que les opérations avec des paramètres d'entrée spécifiques. Pour Exemple : un pilote peut être compatible avec la convolution 3x3 et 5x5, mais pas avec la convolution 7x7 opérations.
- Le pilote présente des contraintes de mémoire qui l'empêchent de gérer de graphiques ou entrées.
Lors de la compilation, l'entrée, la sortie et les opérandes internes du modèle, tels que
décrits dans
OperandLifeTime
peuvent avoir des dimensions ou un classement inconnus. Pour en savoir plus, consultez
Forme de sortie :
Le framework demande à chaque pilote sélectionné de se préparer à exécuter un sous-ensemble de
le modèle en appelant
IDevice::prepareModel_1_3
Chaque pilote compile ensuite son sous-ensemble. Par exemple, un conducteur peut
générer du code ou créer une copie réorganisée des pondérations. Parce qu'il peut y avoir
un délai important entre la compilation du modèle et
des requêtes, les ressources telles que de grands segments de mémoire de l'appareil ne doivent pas
être attribuées lors de la compilation.
En cas de réussite, le pilote renvoie un code @1.3::IPreparedModel
.
identifiant. Si le pilote renvoie un code d'échec lors de la préparation de son sous-ensemble
le framework exécute l'ensemble du modèle sur le CPU.
Pour réduire le temps de compilation au démarrage d'une application, un pilote peut des artefacts de compilation du cache. Pour plus d'informations, consultez la section Compilation Mise en cache
Exécution
Lorsqu'une application demande au framework d'exécuter une requête, celui-ci appelle
la
IPreparedModel::executeSynchronously_1_3
HAL utilisée par défaut pour effectuer une exécution synchrone sur un modèle préparé.
Une requête peut également être exécutée de manière asynchrone à l'aide de la méthode
execute_1_3
, la méthode
executeFenced
(voir Exécution clôturée),
ou exécutées à l'aide d'un
l'exécution intensive.
Les appels d'exécution synchrones améliorent les performances et réduisent les threads par rapport aux appels asynchrones, car le contrôle est renvoyé de l'application qu'une fois l'exécution terminée. Cela signifie que pilote n'a pas besoin d'un mécanisme distinct pour avertir le processus de l'application que avant qu'une exécution ne soit terminée.
Avec la méthode execute_1_3
asynchrone, le contrôle revient à la méthode
processus d'application après le lancement de l'exécution, et le pilote doit en informer
le framework une fois l'exécution terminée,
@1.3::IExecutionCallback
Le paramètre Request
transmis à la méthode d'exécution répertorie l'entrée et la sortie
opérandes utilisés pour l'exécution. La mémoire qui stocke les données d'opérande
utilisez l'ordre "ligne principale", la première dimension étant itérative la plus lente, et n'avez pas
une marge intérieure à la fin de n'importe quelle ligne. Pour en savoir plus sur les types d'opérandes,
voir
Opérandes :
Pour les pilotes NN HAL version 1.2 ou ultérieure, lorsqu'une requête est terminée, l'état de l'erreur, la forme de sortie et les informations temporelles sont renvoyées ; au cadre. Pendant l'exécution, les opérandes de sortie ou internes du modèle peuvent présentent une ou plusieurs dimensions ou rangs inconnus. Lorsqu'au moins une sortie l'opérande a une dimension ou un rang inconnu, le conducteur doit renvoyer des informations de sortie dimensionnées de façon dynamique.
Pour les pilotes disposant de NN HAL version 1.1 ou antérieure, seul l'état d'erreur est renvoyé lorsqu'une soit traitée. Les dimensions des opérandes d'entrée et de sortie doivent être entièrement spécifié pour que l'exécution aboutisse. Les opérandes internes peuvent comportent une ou plusieurs dimensions inconnues, alors que leur rang doit être indiqué.
Pour les requêtes utilisateur couvrant plusieurs pilotes, le framework est responsable pour réserver la mémoire intermédiaire et le séquençage des appels à chaque pilote.
Plusieurs requêtes peuvent être lancées en parallèle sur le même
@1.3::IPreparedModel
Le pilote peut exécuter des requêtes en parallèle ou sérialiser les exécutions.
Le framework peut demander à un conducteur de conserver plusieurs modèles préparés. Pour
exemple, préparer le modèle m1
, préparer m2
, exécuter la requête r1
sur m1
, exécuter
r2
sur m2
, exécuter r3
sur m1
, exécuter r4
sur m2
, version (décrite dans
Cleanup) m1
et la version m2
.
Pour éviter une première exécution lente qui pourrait nuire à l'expérience utilisateur (par exemple, un premier saccades au niveau de la trame), le pilote doit effectuer la plupart des initialisations lors de la phase de compilation. Lors de la première exécution, l'initialisation doit être limitée à les actions qui ont un impact négatif sur l'état du système lorsqu'elles sont effectuées à un stade précoce, comme réserver des tampons temporaires volumineux ou augmenter la fréquence d'horloge d'un appareil. Les pilotes qui ne peuvent préparer qu'un nombre limité de modèles simultanés peuvent avoir pour s'initialiser à la première exécution.
Sous Android 10 ou version ultérieure, si plusieurs avec le même modèle préparé sont exécutées en succession rapide, le client peut choisir d'utiliser une méthode d'exécution objet d'utilisation intensive pour la communication entre les processus de l'application et du pilote. Pour plus pour en savoir plus, consultez Exécutions intensives et files d'attente de messages rapides.
Pour améliorer les performances de plusieurs exécutions successives, le pilote peut conserver des tampons temporaires ou augmenter les fréquences d'horloge. Créer un watchdog est recommandé pour libérer des ressources si aucune nouvelle requête n'est créée après pendant une période déterminée.
Forme de sortie
Pour les requêtes dans lesquelles un ou plusieurs opérandes de sortie n'ont pas toutes les dimensions
spécifié, le pilote doit fournir une liste de formes de sortie contenant
des informations de dimension pour chaque opérande de sortie après exécution. Pour plus
sur les dimensions, consultez
OutputShape
Si une exécution échoue en raison d'un tampon de sortie trop petit, le pilote doit indiquer quels opérandes de sortie ont une taille de mémoire tampon insuffisante dans la liste des des formes de sortie et doivent rapporter autant d'informations dimensionnelles que possible, en utilisant zéro pour les dimensions inconnues.
Durée
Sous Android 10, une application peut demander l'exécution
temps si l'application
a spécifié un seul appareil à utiliser
pendant le processus de compilation. Pour
détails, consultez
MeasureTiming
et Découverte et attribution des appareils.
Dans ce cas,
Le pilote NN HAL 1.2 doit mesurer la durée d'exécution ou signaler UINT64_MAX
(à
indiquer que la durée n'est pas disponible) lors de l'exécution d'une requête. Le conducteur
doit minimiser toute perte de performances résultant de la mesure de l'exécution
de la vidéo.
Le conducteur signale les durées suivantes en microsecondes dans le champ
Timing
structure:
- Temps d'exécution sur l'appareil:n'inclut pas le temps d'exécution dans le champ qui s'exécute sur le processeur hôte.
- Temps d'exécution dans le pilote:inclut le temps d'exécution sur l'appareil.
Ces durées doivent inclure le moment où l'exécution est suspendue, par exemple par exemple, lorsque l'exécution a été préemptée par d'autres tâches ou lorsqu'elle à attendre qu'une ressource soit disponible.
Lorsque le pilote n'a pas été invité à mesurer la durée de l'exécution ou lorsque
une erreur d'exécution se produit, le pilote doit signaler les durées au format
UINT64_MAX
Même lorsque le pilote a été invité à mesurer l'exécution
la durée réelle, il peut indiquer UINT64_MAX
pour l'heure sur l'appareil, l'heure dans
pilote, ou les deux. Lorsque le conducteur signale les deux durées en tant que valeur autre que
UINT64_MAX
, la durée d'exécution dans le pilote doit être égale ou supérieure à la durée de
l'appareil.
Exécution clôturée
Dans Android 11, NNAPI permet aux exécutions d'attendre un
liste de handle sync_fence
et renvoie éventuellement un objet sync_fence
, qui
est signalé à la fin de l'exécution. Cela réduit les frais généraux pour les petites
modèles de séquence et cas d'utilisation par flux. L'exécution délimitée permet également
une interopérabilité efficace avec d'autres composants, qui peuvent signaler ou attendre que
sync_fence
Pour en savoir plus sur sync_fence
, consultez
Framework de synchronisation.
Dans une exécution clôturée, le framework appelle
IPreparedModel::executeFenced
pour lancer une exécution asynchrone clôturée sur un modèle préparé avec une méthode
vecteur de barrières de synchronisation à attendre. Si la tâche asynchrone est terminée avant
l'appel, un handle vide peut être renvoyé pour sync_fence
. Une
L'objet IFencedExecutionCallback
doit également être renvoyé pour permettre au framework
pour interroger les informations
sur l'état et la durée des erreurs.
Une fois l'exécution terminée, les deux
Valeurs timing
mesurer la durée de l'exécution peut être interrogé
IFencedExecutionCallback::getExecutionInfo
timingLaunched
: Durée entre le moment oùexecuteFenced
est appelé et le moment oùexecuteFenced
indique lesyncFence
renvoyé.timingFenced
: Durée à partir du moment où la synchronisation se termine que l'exécution attend sont signalés lorsqueexecuteFenced
signaux lesyncFence
renvoyé.
Flux de contrôle
Pour les appareils équipés d'Android 11 ou version ultérieure,
comprend deux opérations de flux de contrôle, IF
et WHILE
, qui utilisent d'autres modèles
en tant qu'arguments et les exécuter de manière conditionnelle (IF
) ou de manière répétée (WHILE
). Pour
pour en savoir plus sur la mise en œuvre, consultez
Flux de contrôle.
Qualité de service
Dans Android 11, la NNAPI améliore la qualité en permettant à une application d'indiquer les priorités relatives de ses la durée maximale de préparation d'un modèle, la durée maximale attendue pour l'exécution d'une exécution. Pour Pour en savoir plus, consultez Qualité de service.
Effectuer un nettoyage
Lorsqu'une application a fini d'utiliser un modèle préparé, le framework publie
sa référence au
@1.3::IPreparedModel
. Lorsque l'objet IPreparedModel
n'est plus référencé, il est
automatiquement détruite dans le service
de pilote qui l'a créé. Selon le modèle
les ressources peuvent être récupérées à ce stade dans l'implémentation du pilote
destructeur. Si le service de chauffeur souhaite que l'objet IPreparedModel
soit
automatiquement détruites lorsque le client n'en a plus besoin, il ne doit pas contenir
toute référence à l'objet IPreparedModel
après l'objet IPreparedeModel
a été renvoyé via
IPreparedModelCallback::notify_1_3
Utilisation du processeur
Les pilotes doivent utiliser le processeur pour configurer les calculs. Les conducteurs ne devraient pas utilisent le processeur pour effectuer des calculs de graphe, car cela interfère avec la capacité du framework à répartir correctement le travail. Le conducteur doit signaler les parties qu'il ne peut pas gérer dans le framework et laissez-le gérer reste.
Le framework fournit une implémentation de processeur pour toutes les opérations NNAPI, à l'exception des les opérations définies par le fournisseur. Pour en savoir plus, consultez Extensions pour les fournisseurs.
La des opérations introduites dans Android 10 (niveau d'API 29) n'ont qu'une implémentation de processeur de référence pour vérifier que les tests CTS et VTS sont correctes. Les implémentations optimisées incluses dans le machine learning pour mobile sont à privilégier par rapport à l'implémentation de CPU NNAPI.
Fonctions utilitaires
Le codebase NNAPI inclut des fonctions utilitaires pouvant être utilisées par services.
La
frameworks/ml/nn/common/include/Utils.h
contient diverses fonctions utilitaires, telles que celles utilisées pour la journalisation
permettant d'effectuer la conversion
entre différentes versions HAL du réseau de neurones.
VLogging:
VLOG
est une macro de wrapper autour de l'élémentLOG
d'Android qui ne consigne le message si la balise appropriée est définie dansdebug.nn.vlog
.initVLogMask()
doit être appelé avant tout appel àVLOG
. La macroVLOG_IS_ON
peut être utilisé pour vérifier siVLOG
est actuellement activé, ce qui permet une journalisation compliquée à ignorer s'il n'est pas nécessaire. La valeur de la propriété doit être l'une des options suivantes:- Chaîne vide indiquant qu'aucune journalisation ne doit être effectuée.
- Le jeton
1
ouall
, indiquant que toute la journalisation doit être effectuée - Une liste de tags, délimités par des espaces, des virgules ou des deux-points,
indiquant quelle journalisation doit être effectuée. Les tags sont
compilation
,cpuexe
,driver
,execution
,manager
etmodel
.
compliantWithV1_*
: renvoietrue
si un objet NN HAL peut être converti vers le même type d'une autre version de HAL sans perdre d'informations. Pour Par exemple, l'appel decompliantWithV1_0
sur uneV1_2::Model
renvoiefalse
si le modèle inclut des types d'opérations introduits dans NN HAL 1.1 ou NN HAL 1.2.convertToV1_*
: convertit un objet HAL NN d'une version à une autre. Un avertissement est consigné si la conversion entraîne une perte d'informations si la nouvelle version du type ne peut pas représenter entièrement la valeur).Fonctionnalités:
nonExtensionOperandPerformance
etupdate
peuvent être utilisées pour créerCapabilities::operandPerformance
.Interroger les propriétés de types:
isExtensionOperandType
,isExtensionOperationType
,nonExtensionSizeOfData
,nonExtensionOperandSizeOfData
,nonExtensionOperandTypeIsScalar
,tensorHasUnspecifiedDimensions
La
frameworks/ml/nn/common/include/ValidateHal.h
contient des fonctions utilitaires permettant de vérifier la validité d'un objet NN HAL
conformément aux spécifications de sa version HAL.
validate*
: renvoietrue
si l'objet NN HAL est valide conformément aux spécifications de sa version HAL. Types d'OEM et d'extensions ne sont pas validées. Par exemple,validateModel
renvoiefalse
si le contient une opération qui référence un index d'opérande ou d'une opération incompatible avec cette version de HAL.
La
frameworks/ml/nn/common/include/Tracing.h
contient des macros pour simplifier l'ajout
les informations de traçage vers le code des réseaux de neurones.
Pour obtenir un exemple, consultez les appels de macro NNTRACE_*
dans la
exemple de pilote.
La
frameworks/ml/nn/common/include/GraphDump.h
contient une fonction utilitaire permettant de vider le contenu d'un Model
dans l'interface graphique
à des fins de débogage.
graphDump
: écrit une représentation du modèle dans Graphviz. (.dot
) dans le flux spécifié (le cas échéant) ou dans le fichier logcat (si aucun flux n'est fourni).
Validation
Pour tester votre implémentation de NNAPI, utilisez les tests VTS et CTS inclus dans le framework Android. Le VTS fait directement des exercices avec vos pilotes (sans utiliser le tandis que CTS les exerce indirectement via le framework. Ces tester chaque méthode d'API et vérifier que toutes les opérations compatibles avec fonctionnent correctement et fournissent des résultats qui répondent aux exigences de précision.
Dans CTS et VTS pour la NNAPI, les exigences de précision sont les suivantes:
Virgule flottante: abs(attendu - réel) <= atol + rtol * abs(attendu) ; où:
- Pour fp32, atol = 1e-5f, rtol = 5.0f * 1.1920928955078125e-7
- Pour fp16, atol = rtol = 5.0f * 0,0009765625f
Quantifiée:aucune par une (à l'exception de
mobilenet_quantized
, ce qui est décalé par trois)Booléen:mot clé exact
Une façon dont CTS teste NNAPI consiste à générer des graphiques pseudo-aléatoires fixes
utilisé pour tester et comparer les résultats d'exécution de chaque pilote avec le
Mise en œuvre de la documentation de référence NNAPI. Pour les conducteurs disposant de NN HAL version 1.2 ou ultérieure, si le
les résultats ne répondent pas aux critères de précision, CTS signale une erreur et
du modèle défaillant sous /data/local/tmp
pour le débogage.
Pour en savoir plus sur les critères de précision, consultez
TestRandomGraph.cpp
et
TestHarness.h
Tests de simulation
Le but du test fuzz est de trouver les plantages, les assertions, les violations de mémoire, ou comportement général non défini dans le code testé en raison de facteurs tels que des entrées inattendues. Pour les tests à données aléatoires NNAPI, Android utilise des tests basés sur libFuzzer, qui sont efficace pour le fuzzing, car il utilise la couverture de ligne des scénarios de test précédents pour générer de nouvelles entrées aléatoires. Par exemple, libFuzzer privilégie les scénarios de test qui s'exécutent sur de nouvelles lignes de code. Cela réduit considérablement le temps nécessaire aux tests pour trouver code qui pose problème.
Pour effectuer des tests à données aléatoires afin de valider l'implémentation de vos pilotes, modifiez
frameworks/ml/nn/runtime/test/android_fuzzing/DriverFuzzTest.cpp
dans l'utilitaire de test libneuralnetworks_driver_fuzzer
disponible dans AOSP pour inclure
votre code de pilote. Pour en savoir plus sur les tests à données aléatoires NNAPI, consultez
frameworks/ml/nn/runtime/test/android_fuzzing/README.md
Sécurité
Étant donné que les processus d'application
communiquent directement avec le processus du pilote,
les conducteurs doivent valider les arguments
des appels qu'ils reçoivent. Cette validation
est vérifiée par VTS. Le code de validation est
frameworks/ml/nn/common/include/ValidateHal.h
Les conducteurs doivent également s'assurer que les applications ne peuvent pas interférer avec d'autres applications lorsqu'ils utilisent le même appareil.
Suite de test de machine learning Android
La suite de tests de machine learning Android (MLTS) est un benchmark NNAPI inclus dans CTS et VTS pour valider la justesse de modèles réels sur les appareils des fournisseurs. La le benchmark évalue la latence et la précision, et compare les performances résultats avec les résultats en utilisant TF Lite s'exécutant sur le processeur pour le même modèle et les mêmes ensembles de données. Cela garantit que la précision d'un conducteur n'est pas moins bien que l'implémentation de référence du processeur.
Les développeurs de la plate-forme Android utilisent également MLTS pour évaluer la latence et la justesse. de conducteurs.
Le benchmark NNAPI se trouve dans deux projets dans AOSP:
platform/test/mlts/benchmark
(application d'analyse comparative)platform/test/mlts/models
(modèles et ensembles de données)
Modèles et ensembles de données
Le benchmark NNAPI utilise les modèles et ensembles de données suivants.
- MobileNetV1 float et u8 quantifiés en différentes tailles, comparés à un petit sous-ensemble (1 500 images) de l'ensemble de données Open Images v4.
- MobileNetV2 float et u8 quantifiés en différentes tailles, comparés à un petit sous-ensemble (1 500 images) de l'ensemble de données Open Images v4.
- Modèle acoustique basé sur la mémoire à long terme (LSTM) pour la synthèse vocale sur un petit sous-ensemble de l'ensemble CMU Arctic.
- Modèle acoustique basé sur LSTM pour la reconnaissance vocale automatique, exécuté sur dans un petit sous-ensemble de l'ensemble de données LibriSpeech.
Pour en savoir plus, consultez platform/test/mlts/models
.
Test de contrainte
La suite de tests de machine learning Android comprend une série de tests de plantage pour Valider la résilience des conducteurs dans des conditions d'utilisation intensives ou dans les virages des cas de clients comportemental.
Tous les tests de plantage offrent les fonctionnalités suivantes:
- Détection de blocage:si le client NNAPI se bloque lors d'un test,
Le test échoue avec le motif d'échec
HANG
et la suite de tests passe au test suivant. - Détection des plantages du client NNAPI:les tests survivent aux plantages et aux tests du client
échouent avec le motif
CRASH
. - Détection d'accident de conducteur:les tests peuvent détecter un accident de conduite.
qui entraîne l'échec d'un appel NNAPI. Notez que des plantages peuvent survenir
les processus du pilote qui ne provoquent pas de défaillance NNAPI et ne provoquent pas le test.
à l'échec. Pour couvrir ce type de défaillance, il est recommandé d'exécuter
tail
dans le journal système pour détecter les erreurs ou les plantages liés aux pilotes. - Ciblage de tous les accélérateurs disponibles:les tests sont exécutés sur tous les des pilotes disponibles.
Tous les tests de plantage peuvent donner les quatre résultats suivants:
SUCCESS
: exécution terminée sans erreur.FAILURE
: échec de l'exécution. Généralement causée par une défaillance tester un modèle, ce qui indique que le pilote n'a pas pu compiler ou exécuter le modèle.HANG
: le processus de test ne répond plus.CRASH
: le processus de test a planté.
Pour en savoir plus sur les tests de contrainte et obtenir la liste complète des tests de plantage, consultez
platform/test/mlts/benchmark/README.txt
Utiliser MLTS
Pour utiliser le MLTS:
- Connectez un appareil cible à votre poste de travail et assurez-vous qu'il est
accessible via
adb :
Exporter l'appareil cible
ANDROID_SERIAL
variable d'environnement si plusieurs appareils sont connectés. cd
dans le répertoire source Android de premier niveau.source build/envsetup.sh lunch aosp_arm-userdebug # Or aosp_arm64-userdebug if available. ./test/mlts/benchmark/build_and_run_benchmark.sh
À la fin d'une analyse comparative, les résultats sont présentés sous forme de page HTML et transmis à
xdg-open
.
Pour en savoir plus, consultez platform/test/mlts/benchmark/README.txt
.
Versions HAL des réseaux de neurones
Cette section décrit les modifications apportées à Android et Neural Versions HAL des réseaux.
Android 11
Android 11 introduit NN HAL 1.3, qui inclut le suite à des changements notables.
- Prise en charge de la quantification signée 8 bits dans NNAPI. Ajoute la méthode
TENSOR_QUANT8_ASYMM_SIGNED
d'opérande. Pilotes avec NN HAL 1.3 compatible avec les opérations avec quantification non signée doivent également être compatibles avec les variantes signées de ces opérations. Lors de l'exécution de versions signées et non signées de la plupart des les opérations quantifiées, les conducteurs doivent produire les mêmes résultats jusqu'à un décalage de 128. Il existe cinq exceptions à cette exigence:CAST
,HASHTABLE_LOOKUP
,LSH_PROJECTION
,PAD_V2
etQUANTIZED_16BIT_LSTM
. L'opérationQUANTIZED_16BIT_LSTM
n'est pas compatible avec les opérandes signés et les quatre autres opérations sont compatibles avec la quantification signée, mais ne nécessitent pas que les résultats soient identiques. - Prise en charge des exécutions cloisonnées où le framework appelle
IPreparedModel::executeFenced
pour lancer une exécution asynchrone clôturée sur un modèle préparé avec une méthode vecteur de barrières de synchronisation à attendre. Pour en savoir plus, consultez Exécution délimitée. - Prise en charge du flux de contrôle. Il ajoute les opérations
IF
etWHILE
, qui prennent d'autres modèles en tant qu'arguments et les exécuter de manière conditionnelle (IF
) ; à plusieurs reprises (WHILE
). Pour en savoir plus, consultez Flux de contrôle. - Amélioration de la qualité de service (QoS), car les applications peuvent indiquer les priorités de ses modèles, le temps maximal attendu le modèle à préparer, ainsi que la durée maximale attendue soit terminée. Pour en savoir plus, consultez Qualité de service.
- Prise en charge des domaines de mémoire qui fournissent des interfaces d'allocation pour gérés par le pilote. Cela permet de transmettre la mémoire native de l'appareil entre les exécutions, en supprimant la copie et la transformation inutiles de données entre des exécutions consécutives sur le même pilote. Pour plus d'informations, consultez la section Domaines de mémoire.
Android 10
Android 10 introduit NN HAL 1.2, qui inclut le suite à des changements notables.
- La structure
Capabilities
inclut tous les types de données, y compris les données scalaires et représente des performances non assouplies à l'aide d'un vecteur que les champs nommés. - Les méthodes
getVersionString
etgetType
permettent au framework de récupérer les informations sur le type d'appareil (DeviceType
) et la version. Voir Découverte et attribution des appareils : - La méthode
executeSynchronously
est appelée par défaut pour effectuer une une exécution synchrone. La méthodeexecute_1_2
indique au framework et effectuer une exécution asynchrone. Voir Exécution. - Le paramètre
MeasureTiming
surexecuteSynchronously
,execute_1_2
et l'exécution intensive spécifie si le pilote doit mesurer l'exécution de la vidéo. Les résultats sont indiqués dans la structureTiming
. Voir Calendrier : - Prise en charge des exécutions dans lesquelles un ou plusieurs opérandes de sortie ont une valeur inconnue une dimension ou un classement. Consultez Forme de sortie.
- Prise en charge des extensions de fournisseur, qui sont des ensembles de
des opérations et des types de données. Le pilote signale les extensions compatibles via
la méthode
IDevice::getSupportedExtensions
. Voir Extensions pour les fournisseurs. - Possibilité pour un objet d'utilisation intensive de contrôler un ensemble d'exécutions intensives à l'aide de Files d'attente de messages rapides (FMQ) pour la communication entre l'application et le pilote ce qui réduit la latence. Voir Exécutions intensives et files d'attente de messages rapides.
- Prise en charge de AHardwareBuffer pour permettre au pilote d'effectuer des exécutions sans copier de données. Voir AHardwareBuffer.
- Amélioration de la prise en charge de la mise en cache des artefacts de compilation pour réduire le temps utilisé pour la compilation au démarrage d'une application. Voir Mise en cache des compilations.
Android 10 introduit les types d'opérandes suivants et opérations.
-
ANEURALNETWORKS_BOOL
ANEURALNETWORKS_FLOAT16
ANEURALNETWORKS_TENSOR_BOOL8
ANEURALNETWORKS_TENSOR_FLOAT16
ANEURALNETWORKS_TENSOR_QUANT16_ASYMM
ANEURALNETWORKS_TENSOR_QUANT16_SYMM
ANEURALNETWORKS_TENSOR_QUANT8_SYMM
ANEURALNETWORKS_TENSOR_QUANT8_SYMM_PER_CHANNEL
-
ANEURALNETWORKS_ABS
ANEURALNETWORKS_ARGMAX
ANEURALNETWORKS_ARGMIN
ANEURALNETWORKS_AXIS_ALIGNED_BBOX_TRANSFORM
ANEURALNETWORKS_BIDIRECTIONAL_SEQUENCE_LSTM
ANEURALNETWORKS_BIDIRECTIONAL_SEQUENCE_RNN
ANEURALNETWORKS_BOX_WITH_NMS_LIMIT
ANEURALNETWORKS_CAST
ANEURALNETWORKS_CHANNEL_SHUFFLE
ANEURALNETWORKS_DETECTION_POSTPROCESSING
ANEURALNETWORKS_EQUAL
ANEURALNETWORKS_EXP
ANEURALNETWORKS_EXPAND_DIMS
ANEURALNETWORKS_GATHER
ANEURALNETWORKS_GENERATE_PROPOSALS
ANEURALNETWORKS_GREATER
ANEURALNETWORKS_GREATER_EQUAL
ANEURALNETWORKS_GROUPED_CONV_2D
ANEURALNETWORKS_HEATMAP_MAX_KEYPOINT
ANEURALNETWORKS_INSTANCE_NORMALIZATION
ANEURALNETWORKS_LESS
ANEURALNETWORKS_LESS_EQUAL
ANEURALNETWORKS_LOG
ANEURALNETWORKS_LOGICAL_AND
ANEURALNETWORKS_LOGICAL_NOT
ANEURALNETWORKS_LOGICAL_OR
ANEURALNETWORKS_LOG_SOFTMAX
ANEURALNETWORKS_MAXIMUM
ANEURALNETWORKS_MINIMUM
ANEURALNETWORKS_NEG
ANEURALNETWORKS_NOT_EQUAL
ANEURALNETWORKS_PAD_V2
ANEURALNETWORKS_POW
ANEURALNETWORKS_PRELU
ANEURALNETWORKS_QUANTIZE
ANEURALNETWORKS_QUANTIZED_16BIT_LSTM
ANEURALNETWORKS_RANDOM_MULTINOMIAL
ANEURALNETWORKS_REDUCE_ALL
ANEURALNETWORKS_REDUCE_ANY
ANEURALNETWORKS_REDUCE_MAX
ANEURALNETWORKS_REDUCE_MIN
ANEURALNETWORKS_REDUCE_PROD
ANEURALNETWORKS_REDUCE_SUM
ANEURALNETWORKS_RESIZE_NEAREST_NEIGHBOR
ANEURALNETWORKS_ROI_ALIGN
ANEURALNETWORKS_ROI_POOLING
ANEURALNETWORKS_RSQRT
ANEURALNETWORKS_SELECT
ANEURALNETWORKS_SIN
ANEURALNETWORKS_SLICE
ANEURALNETWORKS_SPLIT
ANEURALNETWORKS_SQRT
ANEURALNETWORKS_TILE
ANEURALNETWORKS_TOPK_V2
ANEURALNETWORKS_TRANSPOSE_CONV_2D
ANEURALNETWORKS_UNIDIRECTIONAL_SEQUENCE_LSTM
ANEURALNETWORKS_UNIDIRECTIONAL_SEQUENCE_RNN
Android 10 apporte des mises à jour à bon nombre opérations. Les mises à jour sont en lien avec les domaines suivants:
- Compatibilité avec la disposition de mémoire NCHW
- Prise en charge des Tensors dont le rang est différent de 4 dans softmax et opérations de normalisation
- Prise en charge des convolutions dilatées
- Compatibilité avec les entrées avec quantification mixte dans
ANEURALNETWORKS_CONCATENATION
La liste ci-dessous présente les opérations modifiées dans Android 10. Pleine pour en savoir plus sur les modifications, consultez Code d'opération dans la documentation de référence de NNAPI.
ANEURALNETWORKS_ADD
ANEURALNETWORKS_AVERAGE_POOL_2D
ANEURALNETWORKS_BATCH_TO_SPACE_ND
ANEURALNETWORKS_CONCATENATION
ANEURALNETWORKS_CONV_2D
ANEURALNETWORKS_DEPTHWISE_CONV_2D
ANEURALNETWORKS_DEPTH_TO_SPACE
ANEURALNETWORKS_DEQUANTIZE
ANEURALNETWORKS_DIV
ANEURALNETWORKS_FLOOR
ANEURALNETWORKS_FULLY_CONNECTED
ANEURALNETWORKS_L2_NORMALIZATION
ANEURALNETWORKS_L2_POOL_2D
ANEURALNETWORKS_LOCAL_RESPONSE_NORMALIZATION
ANEURALNETWORKS_LOGISTIC
ANEURALNETWORKS_LSH_PROJECTION
ANEURALNETWORKS_LSTM
ANEURALNETWORKS_MAX_POOL_2D
ANEURALNETWORKS_MEAN
ANEURALNETWORKS_MUL
ANEURALNETWORKS_PAD
ANEURALNETWORKS_RELU
ANEURALNETWORKS_RELU1
ANEURALNETWORKS_RELU6
ANEURALNETWORKS_RESHAPE
ANEURALNETWORKS_RESIZE_BILINEAR
ANEURALNETWORKS_RNN
ANEURALNETWORKS_ROI_ALIGN
ANEURALNETWORKS_SOFTMAX
ANEURALNETWORKS_SPACE_TO_BATCH_ND
ANEURALNETWORKS_SPACE_TO_DEPTH
ANEURALNETWORKS_SQUEEZE
ANEURALNETWORKS_STRIDED_SLICE
ANEURALNETWORKS_SUB
ANEURALNETWORKS_SVDF
ANEURALNETWORKS_TANH
ANEURALNETWORKS_TRANSPOSE
Android 9
NN HAL 1.1 est introduit dans Android 9 et inclut les fonctionnalités des modifications.
IDevice::prepareModel_1_1
inclut unExecutionPreference
. . Le conducteur peut l'utiliser pour ajuster sa préparation, sachant que L'application préfère économiser la batterie ou exécutera le modèle au cours d'appels successifs rapides.- Neuf opérations ont été ajoutées:
BATCH_TO_SPACE_ND
,DIV
,MEAN
,PAD
,SPACE_TO_BATCH_ND
,SQUEEZE
,STRIDED_SLICE
,SUB
etTRANSPOSE
. - Une application peut spécifier que des calculs à virgule flottante 32 bits peuvent être exécutés
à l'aide d'une plage de float 16 bits et/ou d'une précision en définissant
De
Model.relaxComputationFloat32toFloat16
àtrue
.Capabilities
struct contient le champ supplémentairerelaxedFloat32toFloat16Performance
. afin que le conducteur puisse indiquer au framework ses performances assouplies.
Android 8.1
La version 1.0 du HAL des réseaux de neurones a été publiée dans Android 8.1. Pour plus
pour en savoir plus, consultez
/neuralnetworks/1.0/