Servicequalität

Ab Android 11 bietet die NNAPI eine bessere Dienstqualität (QoS), indem sie es einer App ermöglicht, die relativen Prioritäten ihrer Modelle, die maximal zu erwartende Zeit für die Vorbereitung eines bestimmten Modells und die maximal erwartete Zeit für eine bestimmte Ausführung abgeschlossen werden. Darüber hinaus führt Android 11 zusätzliche NNAPI-Fehlerwerte ein, die es einem Dienst ermöglichen, genauer anzuzeigen, was schief gelaufen ist, wenn ein Fehler auftritt, damit die Client-App besser reagieren und sich wiederherstellen kann.

Priorität

Für Android 11 oder höher werden Modelle mit Priorität in der NN HAL 1.3 vorbereitet. Diese Priorität ist relativ zu anderen vorbereiteten Modellen, die derselben App gehören. Ausführungen mit höherer Priorität können mehr Rechenressourcen verbrauchen als Ausführungen mit niedrigerer Priorität und können Ausführungen mit niedrigerer Priorität verhindern oder aushungern.

Der NN HAL 1.3 Aufruf, die folgende beinhaltet Priority als explizites Argument ist IDevice::prepareModel_1_3 . Beachten Sie, dass IDevice::prepareModelFromCache_1_3 implizit enthält Priority in den Cache - Argumente.

Je nach Fähigkeiten von Fahrer und Gaspedal gibt es viele mögliche Strategien zur Unterstützung von Prioritäten. Hier sind mehrere Strategien:

  • Für Fahrer , die Vorzugs - Support-in gebaut, direkt die propagieren Priority Feld auf das Gaspedal.
  • Verwenden Sie eine Prioritätswarteschlange pro App, um verschiedene Prioritäten zu unterstützen, noch bevor eine Ausführung den Accelerator erreicht.
  • Pausieren oder brechen Sie Modelle mit niedriger Priorität ab, die derzeit ausgeführt werden, um den Beschleuniger für die Ausführung von Modellen mit hoher Priorität freizugeben. Tun Sie dies entweder durch Einfügen von Checkpoints in niedriger Priorität Modelle , die, wenn sie erreicht wird , Abfrage ein Flag , um zu bestimmen , ob die aktuelle Ausführung vorzeitig oder durch Unterteilen des Modells in Teilmodelle und Abfrage der Flagge zwischen submodel Hinrichtungen gestoppt werden sollte. Beachten Sie, dass die Verwendung von Prüfpunkten oder Untermodellen in Modellen, die mit einer Priorität vorbereitet wurden, zusätzlichen Overhead verursachen kann, der für Modelle ohne Priorität in Versionen niedriger als NN HAL 1.3 nicht vorhanden ist.

    • Um das Vorkaufsrecht zu unterstützen, bewahren Sie den Ausführungskontext einschließlich der nächsten auszuführenden Operation oder des nächsten auszuführenden Untermodells und alle relevanten Zwischenoperandendaten auf. Verwenden Sie diesen Ausführungskontext, um die Ausführung zu einem späteren Zeitpunkt wieder aufzunehmen.
    • Es ist keine vollständige Unterstützung für die vorzeitige Verwendung erforderlich, sodass der Ausführungskontext nicht beibehalten werden muss. Da NNAPI-Modellausführungen deterministisch sind, können Ausführungen zu einem späteren Zeitpunkt von Grund auf neu gestartet werden.

Android ermöglicht es Diensten, durch die Verwendung einer AID (Android UID) zwischen verschiedenen Anruf-Apps zu unterscheiden. HIDL hat eingebaute Mechanismen der anrufenden App UID durch die Methode zum Abrufen ::android::hardware::IPCThreadState::getCallingUid . Eine Liste von AIDS zu finden in libcutils/include/cutils/android_filesystem_config.h .

Fristen

Ausgehend von Android 11, Modellvorbereitung und Ausführungen können mit einer gestartet werden OptionalTimePoint Frist Argument. Für Fahrer, die abschätzen können, wie lange eine Aufgabe dauert, ermöglicht diese Frist es dem Fahrer, die Aufgabe vor ihrem Beginn abzubrechen, wenn der Fahrer schätzt, dass die Aufgabe nicht vor Ablauf der Frist abgeschlossen werden kann. In ähnlicher Weise ermöglicht die Frist dem Fahrer, eine laufende Aufgabe abzubrechen, von der er schätzt, dass sie nicht vor Ablauf der Frist abgeschlossen ist. Das Argument Frist zwingt einen Treiber nicht, eine Aufgabe abzubrechen, wenn die Aufgabe nicht bis zum Stichtag abgeschlossen ist oder wenn der Stichtag abgelaufen ist. Das Argument Frist kann verwendet werden, um Rechenressourcen innerhalb des Treibers freizugeben und die Kontrolle schneller an die App zurückzugeben, als dies ohne die Frist möglich ist.

Die NN HAL 1.3 Anrufe , die umfassen OptionalTimePoint Fristen als Argument sind:

  • IDevice::prepareModel_1_3
  • IDevice::prepareModelFromCache_1_3
  • IPreparedModel::execute_1_3
  • IPreparedModel::executeSynchronously_1_3
  • IPreparedModel::executeFenced

Um für jedes der obigen Verfahren eine Referenzimplementierung der Frist Merkmal zu sehen, sehen die NNAPI Beispieltreiber bei frameworks/ml/nn/driver/sample/SampleDriver.cpp .

Fehlercodes

Android 11 enthält vier Fehlercodewerte in NN HAL 1.3, um die Fehlerberichterstattung zu verbessern, sodass Fahrer ihren Status besser kommunizieren und Apps eine reibungslosere Wiederherstellung durchführen können. Dies sind die Fehlercodewerte in ErrorStatus .

  • MISSED_DEADLINE_TRANSIENT
  • MISSED_DEADLINE_PERSISTENT
  • RESOURCE_EXHAUSTED_TRANSIENT
  • RESOURCE_EXHAUSTED_PERSISTENT

In Android 10 oder niedriger, könnte ein Fahrer anzeigen , nur einen Fehler durch den GENERAL_FAILURE Fehlercode. Von Android 11, der beiden MISSED_DEADLINE kann Fehlercodes verwendet werden , um anzuzeigen , dass die Arbeitsbelastung wurde abgebrochen , weil die Frist erreicht wurde oder weil der Fahrer der Arbeitsbelastung vorhergesagt würde innerhalb der Frist nicht vollständig. Die beiden RESOURCE_EXHAUSTED Fehlercodes können verwendet werden , um anzuzeigen , dass die Aufgabe , aufgrund einer Ressourcenbegrenzung innerhalb des Treibers fehlgeschlagen ist , wie der Fahrer nicht ausreichend Speicher für den Anruf hat.

Die TRANSIENT Version beiden Fehler zeigt an, dass das Problem ist vorübergehend, und dass zukünftige Anrufe auf die gleiche Aufgabe nach einer kurzen Verzögerung gelingen könnte. Dieser Fehlercode sollte beispielsweise zurückgegeben werden, wenn der Treiber mit früheren lang andauernden oder ressourcenintensiven Arbeiten beschäftigt ist, die neue Aufgabe jedoch erfolgreich abgeschlossen werden würde, wenn der Treiber nicht mit der vorherigen Arbeit beschäftigt war. Die PERSISTENT Version beiden Fehler zeigt an, dass zukünftige Anrufe auf die gleiche Aufgabe immer zum Scheitern verurteilt zu erwarten. Dieser Fehlercode sollte beispielsweise zurückgegeben werden, wenn der Treiber schätzt, dass die Aufgabe selbst unter perfekten Bedingungen nicht zum Termin abgeschlossen wird oder dass das Modell von Natur aus zu groß ist und die Ressourcen des Treibers übersteigt.

Validierung

Die Qualität der Service - Funktionalität ist in den NNAPI VTS - Tests (getestet VtsHalNeuralnetworksV1_3Target ). Dazu gehört eine Reihe von Tests zur Validierung ( TestGenerated/ValidationTest#Test/ ) , um sicherzustellen , dass der Fahrer ungültig Prioritäten und eine Reihe von Tests genannt lehnt DeadlineTest ( TestGenerated/DeadlineTest#Test/ ) , dass die Fahrer Griffe Fristen korrekt zu gewährleisten.