Diese Seite bietet einen Überblick über die Implementierung einer Neural Networks API (NNAPI)
. Weitere Informationen finden Sie in der Dokumentation in der HAL-Definition
Dateien in
hardware/interfaces/neuralnetworks
Ein Beispiel für eine Treiberimplementierung befindet sich in
frameworks/ml/nn/driver/sample
Weitere Informationen zur Neural Networks API finden Sie unter Neural Networks API
Neuronale Netzwerke HAL
Das HAL für neuronale Netzwerke (NN) definiert eine Abstraktion der verschiedenen Geräte,
etwa Grafikprozessoren (GPUs) und digitale Signalprozessoren (DSP),
die sich in einem Produkt befinden (z. B. auf einem Smartphone oder Tablet). Die Gründe für diese
Geräte müssen NN HAL entsprechen. Die Schnittstelle wird in der HAL angegeben
Definitionsdateien in
hardware/interfaces/neuralnetworks
Der allgemeine Fluss der Schnittstelle zwischen dem Framework und einem Treiber wird dargestellt. in Abbildung 1.
Abbildung 1: Fluss neuronaler Netzwerke
Initialisierung
Bei der Initialisierung fragt das Framework
den Treiber nach seinen Funktionen ab,
IDevice::getCapabilities_1_3
Die Struktur @1.3::Capabilities
enthält alle Datentypen und
die nicht gelockerte Leistung
mithilfe eines Vektors darstellt.
Um zu bestimmen, wie den verfügbaren Geräten Berechnungen zugewiesen werden, nutzt die Fähigkeiten, um zu verstehen, wie schnell und jeder Treiber eine Ausführung ausführen kann. Um diese Informationen bereitzustellen, muss der Treiber standardisierte Leistungszahlen basierend auf der Ausführung von Referenzarbeitslasten.
Um die Werte zu bestimmen, die der Treiber als Antwort auf
IDevice::getCapabilities_1_3
, messen Sie mit der NNAPI-Benchmark-App die
für die entsprechenden Datentypen. Die MobileNet v1 und v2, asr_float
,
und tts_float
werden für die Leistungsmessung über 32-Bit empfohlen.
Gleitkommawerte und die quantisierten Modelle von MobileNet v1 und v2
empfohlen für quantisierte 8-Bit-Werte. Weitere Informationen finden Sie unter
Android Machine Learning Test Suite
In Android 9 und niedriger umfasst die Capabilities
-Struktur die Treiberleistung
nur Informationen für Gleitkommazahlen und quantisierte Tensoren enthält.
skalaren Datentypen.
Im Rahmen des Initialisierungsprozesses kann das Framework weitere Informationen,
mit
IDevice::getType
,
IDevice::getVersionString
IDevice:getSupportedExtensions
und
IDevice::getNumberOfCacheFilesNeeded
Zwischen Produktneustarts erwartet das Framework alle hier beschriebenen Abfragen um immer die gleichen Werte für einen bestimmten Treiber zu melden. Andernfalls wird eine App kann dies zu Leistungseinbußen oder falschem Verhalten führen.
Compilation
Das Framework bestimmt, welche Geräte verwendet werden, wenn eine Anfrage von einem In Android 10 können Apps und geben Sie die Geräte an, die das Framework auswählt. Weitere Informationen finden Sie unter Geräteerkennung und -zuweisung:
Zum Zeitpunkt der Modellkompilierung sendet das Framework das Modell an jeden Kandidaten.
über den Anruf
IDevice::getSupportedOperations_1_3
Jeder Treiber gibt ein Array mit booleschen Werten zurück, die angeben,
des Modells unterstützt. Ein Fahrer kann feststellen,
aus verschiedenen Gründen unterstützt. Beispiel:
- Der Treiber unterstützt den Datentyp nicht.
- Der Treiber unterstützt nur Vorgänge mit bestimmten Eingabeparametern. Für Beispiel: Ein Treiber unterstützt möglicherweise 3x3 und 5x5, aber keine 7x7-Faltung. Geschäftsabläufe.
- Aufgrund von Speichereinschränkungen kann der Treiber keine großen Grafiken oder Eingaben vor.
Während der Kompilierung werden die Eingabe, die Ausgabe und die internen Operanden des Modells, wie
beschrieben in
OperandLifeTime
,
unbekannte Dimensionen oder
einen unbekannten Rang haben. Weitere Informationen finden Sie unter
Ausgabeform.
Das Framework weist jeden ausgewählten Treiber an, sich auf die Ausführung
durch Aufrufen von
IDevice::prepareModel_1_3
Jeder Treiber kompiliert dann seine Teilmenge. Beispielsweise könnte ein Fahrer
Code generieren oder eine neu angeordnete Kopie der Gewichtungen erstellen. Da die Zahl der
zwischen der Kompilierung des Modells und dem
ausgeführt werden, sollten Ressourcen wie
große Speicherblöcke auf dem Gerät
während der Kompilierung zugewiesen werden.
Bei Erfolg gibt der Fahrer ein @1.3::IPreparedModel
zurück.
Alias. Gibt der Treiber bei der Vorbereitung seiner Teilmenge des
-Modell führt das Framework das gesamte Modell auf der CPU aus.
Um den Zeitaufwand für die Kompilierung beim Start einer App zu reduzieren, kann ein Treiber Kompilierungsartefakte im Cache speichern. Weitere Informationen finden Sie unter Kompilierung Caching.
Umsetzung
Wenn eine Anwendung das Framework anfordert, eine Anfrage auszuführen, ruft das Framework
die
IPreparedModel::executeSynchronously_1_3
HAL-Methode standardmäßig eine synchrone Ausführung für ein vorbereitetes Modell.
Eine Anfrage kann auch asynchron mit der Methode
execute_1_3
die Methode
executeFenced
(siehe Abgegrenzte Ausführung)
oder unter Verwendung eines
Burst-Ausführung.
Synchrone Ausführungsaufrufe verbessern die Leistung und reduzieren Threading im Vergleich zu asynchronen Aufrufen, da die Steuerung an den nachdem die Ausführung abgeschlossen ist. Das bedeutet, dass der braucht der Fahrer keinen separaten Mechanismus, um den App-Prozess zu benachrichtigen, die Ausführung abgeschlossen wird.
Mit der asynchronen execute_1_3
-Methode wird die Steuerung an den
nachdem die Ausführung gestartet wurde, und der Treiber muss
nach Abschluss der Ausführung über das Framework
@1.3::IExecutionCallback
Der Request
-Parameter, der an die Ausführungsmethode übergeben wird, listet die Ein- und Ausgabe auf
Operanden, die für die Ausführung verwendet werden. Der Speicher, in dem die Operandendaten gespeichert werden, muss
Verwenden Sie die Zeilenreihenfolge, wobei die erste Dimension die langsamste Iteration verwendet.
Abstand zum Ende einer Zeile festlegen. Weitere Informationen zu den Operandentypen
Siehe
Operanden:
Für NN HAL 1.2-Treiber oder höher, wenn eine Anfrage abgeschlossen, Fehlerstatus, Ausgabeform und Zeitangaben zurückgegeben, bis hin zum Framework. Während der Ausführung können Ausgabe- oder interne Operanden des Modells eine oder mehrere unbekannte Dimensionen oder einen unbekannten Rang haben. Wenn mindestens eine Ausgabe Operand eine unbekannte Dimension oder einen unbekannten Rang hat, muss der Treiber zurückgeben. Ausgabeinformationen mit dynamischer Größe.
Für Treiber mit NN HAL 1.1 oder niedriger wird nur der Fehlerstatus zurückgegeben, wenn ein abgeschlossen ist. Die Dimensionen für Eingabe- und Ausgabeoperanden müssen vollständig sein angegeben ist, damit die Ausführung erfolgreich abgeschlossen werden kann. Interne Operanden können haben eine oder mehrere unbekannte Dimensionen, für sie muss jedoch ein Rang angegeben sein.
Bei Nutzeranfragen, die sich über mehrere Treiber erstrecken, sorgt das Framework und für die Sequenzierung der Aufrufe an jeden Treiber.
Es können mehrere Anfragen parallel auf einem
@1.3::IPreparedModel
Der Treiber kann Anfragen parallel ausführen oder die Ausführungen serialisieren.
Das Framework kann einen Treiber auffordern, mehr als ein vorbereitetes Modell zu führen. Für
Beispiel: Modell m1
vorbereiten, m2
vorbereiten, Anfrage r1
auf m1
ausführen, ausführen
r2
am m2
, r3
unter m1
ausführen, r4
auf m2
ausführen, Release (siehe
Bereinigen) m1
und gib m2
frei.
Um eine langsame erste Ausführung zu vermeiden, die zu einer schlechten Nutzererfahrung führen könnte (für z. B. wenn der erste Frame ins Stocken gerät, sollte der Treiber die meisten Initialisierungen durchführen. in der Kompilierungsphase. Die Initialisierung bei der ersten Ausführung sollte auf Folgendes beschränkt sein: Aktionen, die sich frühzeitig negativ auf den Systemzustand auswirken, z. B. das Reservieren großer temporärer Puffer oder das Erhöhen der Taktrate eines Geräts. Treiber, die nur eine begrenzte Anzahl gleichzeitiger Modelle vorbereiten können, haben möglicherweise um die Initialisierung bei der ersten Ausführung durchzuführen.
Unter Android 10 oder höher, falls mehrere Ausführungen mit demselben vorbereiteten Modell schnell hintereinander ausgeführt werden, kann der Kunde Burst-Objekt zur Kommunikation zwischen Anwendungs- und Treiberprozessen. Weitere Informationen finden Sie unter Burst Executions und schnelle Message Queues.
Um die Leistung bei mehreren Ausführungen schnell hintereinander zu verbessern, temporäre Puffer einbehalten oder die Taktraten erhöhen. Watchdog erstellen Thread wird empfohlen, um Ressourcen freizugeben, wenn nach dem Erstellen keine neuen Anfragen für einen festen Zeitraum.
Ausgabeform
Für Anfragen, bei denen ein oder mehrere Ausgabeoperanden nicht alle Dimensionen haben
angegeben ist, muss der Treiber eine Liste von Ausgabeformen bereitstellen, die die
Dimensionsinformationen für jeden Ausgabeoperanden nach der Ausführung. Weitere Informationen
Informationen zu Dimensionen finden Sie unter
OutputShape
Wenn eine Ausführung aufgrund eines zu großen Ausgabepuffers fehlschlägt, muss der Treiber gibt an, welche Ausgabeoperanden eine unzureichende Puffergröße in der Liste der Ausgabeformen und sollte so viele räumliche Informationen wie möglich bereitstellen, mit Null für unbekannte Dimensionen.
Timing
In Android 10 kann eine App die Ausführung anfordern
wenn die App
ein einzelnes Gerät für den Kompilierungsprozess angegeben hat. Für
finden Sie unter
MeasureTiming
und Geräteerkennung und -zuweisung.
In diesem Fall
NN HAL 1.2-Treiber muss die Ausführungsdauer messen oder UINT64_MAX
(an
angezeigt wird, wenn eine Anfrage ausgeführt wird. Der Fahrer
sollte Leistungseinbußen minimieren, die sich aus der Ausführung der Messung ergeben.
Dauer
Der Treiber meldet die folgende Dauer in Mikrosekunden im
Timing
Struktur:
- Ausführungszeit auf dem Gerät:Die Ausführungszeit wird nicht in den der auf dem Host-Prozessor ausgeführt wird.
- Ausführungszeit im Treiber:Beinhaltet die Ausführungszeit auf dem Gerät.
Diese Dauer muss die Zeit enthalten, zu der die Ausführung ausgesetzt ist, z. B. wenn die Ausführung durch andere Aufgaben vorzeitig beendet wurde warten darauf, dass eine Ressource verfügbar ist.
Wenn der Treiber nicht aufgefordert wurde, die Ausführungsdauer zu messen,
Ausführungsfehler vorliegt, muss der Treiber die Dauer
UINT64_MAX
Auch wenn der Fahrer aufgefordert wurde, die Ausführung
Dauer, können stattdessen UINT64_MAX
für die Zeit auf dem Gerät, die Zeit im
oder beides. Wenn der Fahrer beide Dauer als einen anderen Wert als
UINT64_MAX
, muss die Ausführungszeit im Treiber der Zeit für
auf dem Gerät.
Umzäunte Ausführung
In Android 11 ermöglicht NNAPI es Ausführungen, auf eine
mit sync_fence
-Handles und gibt optional ein sync_fence
-Objekt zurück, das
wird signalisiert, wenn die Ausführung abgeschlossen ist. Dies senkt den Aufwand für kleine
Sequenzmodelle und Streaming-Anwendungsfälle. Die eingegrenzte Ausführung ermöglicht auch
eine effiziente Interoperabilität mit anderen Komponenten,
sync_fence
Weitere Informationen zu sync_fence
finden Sie unter
Synchronisierungs-Framework.
Bei einer Fencing-Ausführung nennt das Framework
IPreparedModel::executeFenced
um eine abgegrenzte, asynchrone Ausführung für ein vorbereitetes Modell mit einer
Vektor von Synchronisierungszäunen, auf die gewartet werden soll. Wenn die asynchrone Aufgabe vor dem
der Aufruf zurückgegeben wird, kann für sync_fence
ein leeres Handle zurückgegeben werden. Eine
Das Objekt IFencedExecutionCallback
muss ebenfalls zurückgegeben werden, um das Framework zuzulassen.
um Informationen zum Fehlerstatus und zur Dauer abzufragen.
Nach Abschluss einer Ausführung werden
timing-Werte
wie die Ausführungsdauer gemessen wird,
IFencedExecutionCallback::getExecutionInfo
timingLaunched
: Dauer ab dem Aufruf vonexecuteFenced
bis zum ZeitpunktexecuteFenced
signalisiert die zurückgegebenensyncFence
.timingFenced
: Dauer ab dem Zeitpunkt aller Synchronisierungszäune auf die die Ausführung wartet, werden signalisiert, wennexecuteFenced
-Signale die zurückgegebenesyncFence
.
Ablauf steuern
Für Geräte mit Android 11 oder höher wird die NNAPI
enthält zwei Ablaufsteuerungsvorgänge, IF
und WHILE
, die andere Modelle verwenden.
als Argumente und führen Sie sie bedingt (IF
) oder wiederholt (WHILE
) aus. Für
Weitere Informationen zur Implementierung finden Sie unter
Ablauf steuern:
Servicequalität
In Android 11 bietet die NNAPI eine verbesserte Qualität Dienstqualität, da eine App die relativen Prioritäten ihrer Modelle, die erwartete maximale Zeit für die Vorbereitung eines Modells die maximale Zeit, die für die Ausführung einer Ausführung erwartet wird. Für finden Sie unter Dienstqualität.
Bereinigung
Wenn eine App die Verwendung eines vorbereiteten Modells beendet, wird das Framework veröffentlicht
dessen Verweis auf die
@1.3::IPreparedModel
-Objekt enthält. Wenn nicht mehr auf das IPreparedModel
-Objekt verwiesen wird, ist es
automatisch in dem Treiberdienst
vernichtet, mit dem er erstellt wurde. Modellspezifisch
Ressourcen können jetzt bei der Treiberimplementierung des
Destruktor. Wenn der Treiberdienst möchte, dass das Objekt IPreparedModel
automatisch gelöscht werden, wenn der Kunde sie nicht mehr benötigt,
alle Verweise auf das IPreparedModel
-Objekt nach dem IPreparedeModel
-Objekt
wurden zurückgegeben über
IPreparedModelCallback::notify_1_3
CPU-Auslastung
Es wird erwartet, dass Treiber die CPU verwenden, um Berechnungen einzurichten. Fahrer sollten die CPU für Graphberechnungen verwenden, da dies Fähigkeit des Frameworks, Arbeit richtig zuzuordnen. Der Fahrer sollte Folgendes melden: die Teile, die es nicht handhaben kann, und überlasse das Framework die Ruhe.
Das Framework bietet eine CPU-Implementierung für alle NNAPI-Vorgänge mit Ausnahme von anbieterdefinierten Abläufen. Weitere Informationen finden Sie unter Erweiterungen des Anbieters:
Die in Android 10 eingeführte Abläufe (API-Level 29) nur über eine Referenz-CPU-Implementierung verfügen, um zu überprüfen, ob die CTS- und VTS-Tests richtig sind. Optimierte Implementierungen für mobiles maschinelles Lernen Frameworks werden gegenüber der NNAPI-CPU-Implementierung bevorzugt.
Dienstprogrammfunktionen
Die NNAPI-Codebasis enthält Dienstfunktionen, die vom Treiber verwendet werden können Dienstleistungen.
Die
frameworks/ml/nn/common/include/Utils.h
-Datei verschiedene Dienstfunktionen enthält, z. B. für Logging und
für die Konvertierung zwischen verschiedenen NN HAL-Versionen.
VLogging:
VLOG
ist ein Wrapper-Makro für dasLOG
-Objekt von Android, das nur protokolliert die Nachricht, wenn das entsprechende Tag imdebug.nn.vlog
festgelegt ist Property.initVLogMask()
muss vor Aufrufen vonVLOG
aufgerufen werden. DasVLOG_IS_ON
-Makro kann wird verwendet, um zu prüfen, obVLOG
derzeit aktiviert ist, was ein kompliziertes Logging ermöglicht der übersprungen werden kann, wenn er nicht benötigt wird. Der Wert der Eigenschaft muss eines der folgenden:- Ein leerer String, der angibt, dass kein Logging erfolgen soll.
- Das Token
1
oderall
, das angibt, dass das gesamte Logging abgeschlossen sein soll. - Eine Liste von Tags, die durch Leerzeichen, Kommas oder Doppelpunkte getrennt sind,
und gibt an, welches
Logging durchgeführt werden soll. Die Tags sind
compilation
,cpuexe
,driver
,execution
,manager
undmodel
.
compliantWithV1_*
: Gibttrue
zurück, wenn ein NN HAL-Objekt konvertiert werden kann auf denselben Typ einer anderen HAL-Version, ohne Informationen zu verlieren. Für Wenn Sie beispielsweisecompliantWithV1_0
für eineV1_2::Model
aufrufen, wirdfalse
zurückgegeben, wenn Das Modell enthält in NN HAL 1.1 oder NN HAL 1.2 eingeführte Vorgangstypen.convertToV1_*
: Wandelt ein NN HAL-Objekt von einer Version in eine andere um. Es wird eine Warnung protokolliert, wenn bei der Conversion Daten verloren gehen (also ist, wenn die neue Version des Typs den Wert nicht vollständig wiedergeben kann).Funktionen:
nonExtensionOperandPerformance
undupdate
können Sie bei der ErstellungCapabilities::operandPerformance
ein.Attribute des Typs werden abgefragt:
isExtensionOperandType
,isExtensionOperationType
,nonExtensionSizeOfData
,nonExtensionOperandSizeOfData
,nonExtensionOperandTypeIsScalar
tensorHasUnspecifiedDimensions
Die
frameworks/ml/nn/common/include/ValidateHal.h
-Datei enthält Dienstfunktionen zur Validierung, dass ein NN HAL-Objekt gültig ist.
entsprechend der HAL-Versionsspezifikation.
validate*
: Gibttrue
zurück, wenn das NN HAL-Objekt gültig ist entsprechend der HAL-Versionsspezifikation. OEM- und Erweiterungstypen nicht validiert werden.validateModel
gibt beispielsweisefalse
zurück, wenn die enthält eine Operation, die auf einen Operandenindex verweist, der keine oder einen Vorgang, der in dieser HAL-Version nicht unterstützt wird.
Die
frameworks/ml/nn/common/include/Tracing.h
-Datei enthält Makros, um das Hinzufügen von
Systracing-Informationen in den Code neuronaler Netzwerke.
Ein Beispiel finden Sie in den NNTRACE_*
-Makroaufrufen in der
Beispieltreiber.
Die
frameworks/ml/nn/common/include/GraphDump.h
enthält eine Dienstprogrammfunktion zum Dump des Inhalts von Model
in grafischen
zu Debugging-Zwecken.
graphDump
: Schreibt eine Darstellung des Modells in Graphviz (.dot
) in den angegebenen Stream (falls angegeben) oder in den Logcat (wenn wird kein Stream bereitgestellt).
Zertifizierungsstufe
Testen Sie Ihre Implementierung der NNAPI mithilfe der VTS- und CTS-Tests in Android-Framework entwickelt. Die VTS übt Ihre Fahrer direkt (ohne die Framework), während CTS sie indirekt über das Framework ausführt. Diese jede API-Methode zu testen und zu überprüfen, ob alle Vorgänge, die vom Treiber ordnungsgemäß zu funktionieren und Ergebnisse liefern, die den Anforderungen an die Präzision entsprechen.
In CTS und VTS für NNAPI gelten folgende Präzisionsanforderungen:
Gleitkomma: abs(expected - actual) <= atol + rtol * abs(expected); Dabei gilt:
- Für fp32 gilt: atol = 1e-5f: rtol = 5.0f * 1,1920928955078125e-7
- Für fp16 atol = rtol = 5.0f * 0,0009765625f
Quantisiert:die Anzahl der Einzelfahrten (außer
mobilenet_quantized
, der um drei) liegt)Boolesch: genaue Übereinstimmung
CTS testet NNAPI z. B. durch die Erzeugung fester Pseudozufallsgrafiken.
zum Testen und Vergleichen der Ausführungsergebnisse der einzelnen Treiber mit den
NNAPI-Referenzimplementierung Für Treiber mit NN HAL 1.2 oder höher, wenn der
nicht die Genauigkeitskriterien erfüllen, meldet CTS einen Fehler und gibt einen
Spezifikationsdatei für das fehlgeschlagene Modell zur Fehlerbehebung unter /data/local/tmp
.
Weitere Informationen zu den Genauigkeitskriterien finden Sie unter
TestRandomGraph.cpp
und
TestHarness.h
Fuzzing-Test
Der Zweck von Fuzzing-Tests besteht darin, Abstürze, Assertions, Speicherverstöße, oder allgemeines, nicht definiertes Verhalten im zu testenden Code aufgrund von Faktoren wie unerwartete Eingaben. Für NNAPI-Fuzz-Tests verwendet Android Tests, die auf libFuzzer, die weil sie die Linienabdeckung früherer Testfälle verwenden, um neue Zufallseingaben zu generieren. Zum Beispiel bevorzugt libFuzzer Testfälle, die in neue Codezeilen ein. Dies reduziert den Zeitaufwand für die Tests zur Erkennung problematischen Code.
Um die Treiberimplementierung mithilfe von Fuzz-Tests zu validieren, ändern Sie
frameworks/ml/nn/runtime/test/android_fuzzing/DriverFuzzTest.cpp
im Testdienstprogramm libneuralnetworks_driver_fuzzer
, das Sie in AOSP finden,
Ihren Fahrercode. Weitere Informationen zu NNAPI-Fuzz-Tests finden Sie unter
frameworks/ml/nn/runtime/test/android_fuzzing/README.md
Sicherheit
Da App-Prozesse direkt mit dem Prozess
eines Fahrers kommunizieren,
Treiber müssen die Argumente der empfangenen Aufrufe validieren. Diese Validierung
wird von VTS überprüft. Der Validierungscode befindet sich in
frameworks/ml/nn/common/include/ValidateHal.h
Außerdem sollten die Fahrer darauf achten, dass Apps nicht andere Apps, wenn sie dasselbe Gerät verwenden.
Android Machine Learning Test Suite
Die Android Machine Learning Test Suite (MLTS) ist ein NNAPI-Benchmark, das in CTS und VTS zur Validierung der Genauigkeit realer Modelle auf den Geräten der Anbieter Die bewertet Latenz und Genauigkeit und vergleicht die Leistung Ergebnisse mit die Ergebnisse mithilfe von TF Lite, das auf der CPU ausgeführt wird, für dasselbe Modell und dieselben Datasets. So wird sichergestellt, dass die Genauigkeit als die CPU-Referenzimplementierung.
Android-Plattformentwickler verwenden außerdem MLTS, um die Latenz und Genauigkeit zu bewerten. von Fahrern zu erhalten.
Die NNAPI-Benchmark ist in zwei Projekten in AOSP zu finden:
platform/test/mlts/benchmark
(Benchmark-App)platform/test/mlts/models
(Modelle und Datasets)
Modelle und Datasets
Die NNAPI-Benchmark verwendet die folgenden Modelle und Datasets.
- MobileNetV1 float und u8 in verschiedenen Größen quantisiert, werden für eine kleine Teilmenge (1.500 Bilder) des Open Images Dataset v4.
- MobileNetV2 float und u8 in verschiedenen Größen quantisiert, werden für eine kleine Teilmenge (1.500 Bilder) des Open Images Dataset v4.
- Akustisches Modell für die Sprachausgabe, das auf Langzeitspeicher basiert mit einer kleinen Untergruppe der CMU Arctic.
- Auf LSTM basierendes Akustikmodell für automatische Spracherkennung eine kleine Teilmenge des LibriSpeech-Datasets.
Weitere Informationen finden Sie unter
platform/test/mlts/models
Stresstests
Die Android Machine Learning Test Suite enthält eine Reihe von Absturztests, die Belastbarkeit von Fahrern bei starker Auslastung oder in Kurven überprüfen. der Kundschaft verhalten.
Alle Absturztests bieten die folgenden Funktionen:
- Hang-Erkennung: Wenn der NNAPI-Client während eines Tests hängt, wird der
Test schlägt mit dem Fehlergrund
HANG
und der Test-Suite fehl geht zum nächsten Test. - NNAPI-Clientabsturzerkennung:Tests überstehen Clientabstürze und -tests
mit dem Fehlergrund
CRASH
fehlschlagen. - Fahrunfallerkennung:In Tests kann ein Fahrerunfall erkannt werden.
die einen Fehler bei einem NNAPI-Aufruf verursacht. Beachten Sie, dass es zu Abstürzen in
Treiberprozesse, die keinen NNAPI-Fehler und nicht den Test verursachen
scheitert. Um diese Art von Fehlern zu beheben, wird empfohlen, den
tail
auszuführen im Systemprotokoll nach treiberbezogenen Fehlern oder Abstürzen. - Targeting aller verfügbaren Beschleuniger: Die Tests werden für alle der verfügbaren Treiber.
Alle Absturztests haben die folgenden vier möglichen Ergebnisse:
SUCCESS
: Ausführung ohne Fehler abgeschlossen.FAILURE
: Fehler bei der Ausführung. Üblicherweise durch einen Fehler verursacht, wenn Testen eines Modells, das darauf hinweist, dass der Treiber nicht kompiliert oder ausgeführt werden konnte Modell zu verstehen.HANG
: Der Testprozess reagiert nicht mehr.CRASH
: Testprozess ist abgestürzt.
Weitere Informationen zu Stresstests und eine vollständige Liste der Absturztests findest du unter
platform/test/mlts/benchmark/README.txt
MLTS verwenden
So verwenden Sie das MLTS:
- Verbinden Sie ein Zielgerät mit Ihrer Workstation und stellen Sie sicher, dass es
erreichbar über
adb:
Zielgerät exportieren (
ANDROID_SERIAL
) , wenn mehrere Geräte verbunden sind. cd
in das Android-Quellverzeichnis der obersten Ebene.source build/envsetup.sh lunch aosp_arm-userdebug # Or aosp_arm64-userdebug if available. ./test/mlts/benchmark/build_and_run_benchmark.sh
Am Ende einer Benchmarkausführung werden die Ergebnisse als HTML-Seite dargestellt. und an
xdg-open
übergeben.
Weitere Informationen finden Sie unter
platform/test/mlts/benchmark/README.txt
HAL-Versionen für neuronale Netzwerke
In diesem Abschnitt werden die Änderungen in Android und Neural beschrieben. HAL-Versionen des Netzwerks.
Android 11
Android 11 führt NN HAL 1.3 ein, das die nach bedeutenden Änderungen.
- Unterstützung für signierte 8-Bit-Quantisierung in NNAPI. Fügt den Parameter
TENSOR_QUANT8_ASYMM_SIGNED
Operandtyp aus. Treiber mit NN HAL 1.3, die Vorgänge mit unsignierter Quantisierung müssen auch die signierten Varianten unterstützen. dieser Vorgänge. Bei der Ausführung signierter und unsignierter Versionen der meisten quantisierten Operationen die gleichen Ergebnisse liefern, einen Offset von 128. Von dieser Anforderung gibt es fünf Ausnahmen:CAST
,HASHTABLE_LOOKUP
,LSH_PROJECTION
,PAD_V2
undQUANTIZED_16BIT_LSTM
. DerQUANTIZED_16BIT_LSTM
-Vorgang unterstützt keine signierten Operanden und Die anderen vier Operationen unterstützen die signierte Quantisierung, erfordern aber keine Ergebnisse identisch sind. - Unterstützung für Fenced-Ausführungen, bei denen das Framework die
IPreparedModel::executeFenced
um eine abgegrenzte, asynchrone Ausführung für ein vorbereitetes Modell mit einer Vektor von Synchronisierungszäunen, auf die gewartet werden soll. Weitere Informationen finden Sie unter Abgegrenzte Ausführung. - Unterstützung für Ablaufsteuerung. Fügt die Vorgänge
IF
undWHILE
hinzu, die andere Modelle als Argumente und führen sie bedingt aus (IF
) oder wiederholt (WHILE
). Weitere Informationen finden Sie unter Ablauf steuern: - eine verbesserte Dienstqualität, da Apps die relative Prioritäten seiner Modelle, der maximal für ein Projekt zu erwartenden Modell vorbereitet werden soll, sowie die maximale Zeit, die für ein ausgeführt werden muss. Weitere Informationen finden Sie unter Dienstqualität.
- Unterstützung für Speicherdomains, die Zuweisungsschnittstellen für Treiber-verwalteten Zwischenspeichern. Dadurch können geräteeigene Erinnerungen über verschiedene Ausführungen hinweg, wodurch unnötige Datenkopien und -transformationen unterdrückt werden. aufeinanderfolgende Ausführungen auf demselben Treiber zu ermitteln. Weitere Informationen Siehe Memory-Domains.
Android 10
Android 10 führt NN HAL 1.2 ein, das die nach bedeutenden Änderungen.
- Die Struktur
Capabilities
enthält alle Datentypen, einschließlich skalarer Datentypen und stellt die unveränderliche Leistung mithilfe eines Vektors statt als benannte Felder. - Mit den Methoden
getVersionString
undgetType
kann das Framework Informationen zum Gerätetyp (DeviceType
) und zur Version abrufen. Weitere Informationen finden Sie unter Geräteerkennung und -zuweisung: - Die Methode
executeSynchronously
wird standardmäßig aufgerufen, um eine synchron ausgeführt werden. Die Methodeexecute_1_2
weist das Framework an, um eine Ausführung asynchron auszuführen. Siehe Ausführung. - Den
MeasureTiming
-Parameter fürexecuteSynchronously
,execute_1_2
, und die Burst-Ausführung gibt an, ob der Treiber die Ausführung Dauer Die Ergebnisse werden in derTiming
-Struktur aufgeführt. Weitere Informationen finden Sie unter Zeitplan: - Unterstützung für Ausführungen, bei denen ein oder mehrere Ausgabeoperanden einen unbekannten Wert haben Dimension oder Rang. Siehe Ausgabeform.
- Unterstützung von Anbietererweiterungen, d. h. Sammlungen anbieterdefinierter Erweiterungen
Operationen und Datentypen. Der Treiber meldet unterstützte Erweiterungen über
die Methode
IDevice::getSupportedExtensions
. Weitere Informationen finden Sie unter Erweiterungen des Anbieters: - Möglichkeit für ein Burst-Objekt, eine Reihe von Burst-Ausführungen mithilfe von Schnelle Nachrichtenwarteschlangen (Fast Message Queues, FMQs) für die Kommunikation zwischen Anwendung und Treiber Prozesse reduzieren und die Latenz reduzieren. Weitere Informationen finden Sie unter Burst Executions und schnelle Message Queues.
- Unterstützung für AHardwareBuffer, damit der Treiber Ausführungen ausführen kann ohne Daten zu kopieren. Weitere Informationen finden Sie unter AHardwareBuffer:
- Verbesserte Unterstützung für das Caching von Kompilierungsartefakten, um die Zeit zu verkürzen die beim Start einer App für die Kompilierung verwendet werden. Weitere Informationen finden Sie unter Kompilierung-Caching
Mit Android 10 werden die folgenden Operandentypen und Geschäftsabläufe.
-
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 enthält Updates für viele der Geschäftsabläufe. Die Änderungen sind hauptsächlich mit folgenden Themen:
- Unterstützung für das NCHW-Speicherlayout
- Unterstützung für Tensoren mit einem anderen Rang als 4 in Softmax und Normalisierungsvorgänge
- Unterstützung von erweiterten Faltungen
- Unterstützung für Eingaben mit gemischter Quantisierung in
ANEURALNETWORKS_CONCATENATION
In der Liste unten sehen Sie die Vorgänge, die in Android 10 Vollständige Details zu den Änderungen finden Sie unter Vorgangscode in der NNAPI-Referenzdokumentation.
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 wurde mit Android 9 eingeführt und umfasst Folgendes: Änderungen.
IDevice::prepareModel_1_1
enthält einExecutionPreference
. Damit kann der Fahrer seine Vorbereitung anpassen, denn er weiß, die App den Akku schont oder das Modell ausführt in kurzen, aufeinanderfolgenden Anrufen- Neun neue Vorgänge wurden hinzugefügt:
BATCH_TO_SPACE_ND
,DIV
,MEAN
,PAD
,SPACE_TO_BATCH_ND
,SQUEEZE
,STRIDED_SLICE
,SUB
undTRANSPOSE
- In einer Anwendung kann festgelegt werden, dass 32-Bit-Float-Berechnungen ausgeführt werden können.
16-Bit-Gleitkommazahl und/oder Genauigkeit, indem
Model.relaxComputationFloat32toFloat16
intrue
. DasCapabilities
Struktur hat das zusätzliche FeldrelaxedFloat32toFloat16Performance
, sodass damit der Treiber seine entspannte Leistung an das Framework melden kann.
Android 8.1
Der ursprüngliche HAL (1.0) für neuronale Netzwerke wurde in Android 8.1 veröffentlicht. Weitere Informationen
finden Sie unter
/neuralnetworks/1.0/