Neural Networks API-Treiber

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.

Fluss neuronaler Netzwerke

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 es zu Leistungseinbußen oder falschem Verhalten kommen.

Compilation

Das Framework bestimmt, welche Geräte verwendet werden, wenn es 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 begonnen hat, 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 die erste Dimension iteriert die langsamste und keine 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 von executeFenced bis zum Zeitpunkt executeFenced signalisiert die zurückgegebenen syncFence.
  • timingFenced: Dauer ab dem Zeitpunkt aller Synchronisierungszäune auf die die Ausführung wartet, werden signalisiert, wenn executeFenced-Signale die zurückgegebene syncFence.

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 .

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 das LOG-Objekt von Android, das nur protokolliert die Nachricht, wenn das entsprechende Tag im debug.nn.vlog festgelegt ist Property. initVLogMask() muss vor Aufrufen von VLOG aufgerufen werden. Das VLOG_IS_ON-Makro kann wird verwendet, um zu prüfen, ob VLOG 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 oder all, 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 und model.

  • compliantWithV1_*: Gibt true 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 beispielsweise compliantWithV1_0 für eine V1_2::Model aufrufen, wird false 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 und update können Sie bei der Erstellung Capabilities::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*: Gibt true zurück, wenn das NN HAL-Objekt gültig ist entsprechend der HAL-Versionsspezifikation. OEM- und Erweiterungstypen nicht validiert werden. validateModel gibt beispielsweise false 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:

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 das 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:

  1. 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.

  2. 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 und QUANTIZED_16BIT_LSTM. Der QUANTIZED_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 und WHILE 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 und getType 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 Methode execute_1_2 weist das Framework an, um eine Ausführung asynchron auszuführen. Siehe Ausführung.
  • Den MeasureTiming-Parameter für executeSynchronously, execute_1_2, und die Burst-Ausführung gibt an, ob der Treiber die Ausführung Dauer Die Ergebnisse werden in der Timing-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.

  • Operandtypen

    • 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

  • Betrieb

    • 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 Für 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 ein ExecutionPreference . 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 und TRANSPOSE
  • 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 in true. Das Capabilities Struktur hat das zusätzliche Feld relaxedFloat32toFloat16Performance, 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/