Dienstqualität

Ab Android 11 bietet die NNAPI eine bessere Dienstqualität, da eine App die relativen Prioritäten ihrer Modelle, die maximale Zeit, die für die Vorbereitung eines bestimmten Modells erwartet wird, und die maximale Zeit, die für die Ausführung eines bestimmten Modells erwartet wird, angeben kann. Außerdem werden in Android 11 zusätzliche NNAPI-Fehlerwerte eingeführt, mit denen ein Dienst genauer angeben kann, was bei einem Fehler passiert ist, damit die Client-App besser reagieren und sich erholen kann.

Priorität

Bei Android 11 oder höher werden Modelle mit einer Priorität in der NN HAL 1.3 vorbereitet. Diese Priorität bezieht sich auf andere vorbereitete Modelle, die derselben App gehören. Ausführungen mit höherer Priorität können mehr Rechenressourcen nutzen als Ausführungen mit niedrigerer Priorität und Ausführungen mit niedrigerer Priorität unterbrechen oder verhindern.

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

Je nach den Möglichkeiten des Treibers und des Beschleunigers gibt es viele mögliche Strategien zur Unterstützung von Prioritäten. Hier sind einige Strategien:

  • Bei Treibern mit integriertem Priority-Support muss das Feld Priority direkt an den Accelerator weitergegeben werden.
  • Verwenden Sie eine Prioritätswarteschlange pro App, um unterschiedliche Prioritäten zu unterstützen, noch bevor eine Ausführung den Beschleuniger erreicht.

  • Pausieren oder beenden Sie Modelle mit niedriger Priorität, die gerade ausgeführt werden, um den Beschleuniger für die Ausführung von Modellen mit hoher Priorität freizugeben. Dazu können Sie entweder Prüfpunkte in Modelle mit niedriger Priorität einfügen, die bei Erreichen ein Flag abfragen, um festzustellen, ob die aktuelle Ausführung vorzeitig beendet werden soll, oder das Modell in Untermodelle aufteilen und das Flag zwischen den Ausführungen der Untermodelle abfragen. Die Verwendung von Checkpoints oder Untermodellen in Modellen, die mit einer Priorität vorbereitet wurden, kann zusätzlichen Overhead verursachen, der bei Modellen ohne Priorität in Versionen unter NN HAL 1.3 nicht vorhanden ist.

    • Um die Unterbrechung zu unterstützen, muss der Ausführungskontext beibehalten werden, einschließlich des nächsten auszuführenden Vorgangs oder Untermodells und aller relevanten Zwischenoperanden. Mit diesem Ausführungskontext können Sie die Ausführung später fortsetzen.
    • Eine vollständige Unterbrechungsunterstützung ist nicht erforderlich, daher muss der Ausführungskontext nicht beibehalten werden. Da die Ausführung von NNAPI-Modellen deterministisch ist, können Ausführungen zu einem späteren Zeitpunkt von Grund auf neu gestartet werden.

Android ermöglicht es Diensten, zwischen verschiedenen Anruf-Apps zu unterscheiden, indem eine AID (Android UID) verwendet wird. HIDL verfügt über integrierte Mechanismen zum Abrufen der UID der aufrufenden App über die Methode ::android::hardware::IPCThreadState::getCallingUid. Eine Liste der AIDs finden Sie unter libcutils/include/cutils/android_filesystem_config.h.

Fristen

Ab Android 11 können Modellvorbereitung und ‑ausführung mit dem Argument OptionalTimePoint für die Frist gestartet werden. Bei Treibern, die schätzen können, wie lange eine Aufgabe dauert, kann der Treiber die Aufgabe vor dem Start abbrechen, wenn er schätzt, dass die Aufgabe nicht vor dem Ablauf des Zeitlimits abgeschlossen werden kann. Ebenso kann der Treiber eine laufende Aufgabe abbrechen, wenn er schätzt, dass sie nicht vor dem Ablauf der Frist abgeschlossen wird. Das Argument „deadline“ zwingt einen Fahrer nicht, eine Aufgabe abzubrechen, wenn die Aufgabe bis zum Ablauf der Frist nicht abgeschlossen ist oder die Frist abgelaufen ist. Mit dem Argument „deadline“ können Rechenressourcen im Treiber freigegeben und die Steuerung schneller an die App zurückgegeben werden, als es ohne die Frist möglich ist.

Die NN HAL 1.3-Aufrufe, die OptionalTimePoint-Fristen als Argument enthalten, sind:

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

Eine Referenzimplementierung der Deadline-Funktion für jede der oben genannten Methoden finden Sie im NNAPI-Beispieldriver unter frameworks/ml/nn/driver/sample/SampleDriver.cpp.

Fehlercodes

Android 11 enthält vier Fehlercode-Werte in NN HAL 1.3, um die Fehlerberichterstattung zu verbessern. So können Treiber ihren Status besser kommunizieren und Apps können sich besser erholen. Das sind die Fehlercodewerte in ErrorStatus.

  • MISSED_DEADLINE_TRANSIENT
  • MISSED_DEADLINE_PERSISTENT
  • RESOURCE_EXHAUSTED_TRANSIENT
  • RESOURCE_EXHAUSTED_PERSISTENT

Unter Android 10 oder niedriger konnte ein Treiber einen Fehler nur über den Fehlercode GENERAL_FAILURE angeben. Ab Android 11 können die beiden MISSED_DEADLINE-Fehlercodes verwendet werden, um anzugeben, dass die Arbeitslast abgebrochen wurde, weil die Frist erreicht wurde oder weil der Treiber vorhergesagt hat, dass die Arbeitslast nicht bis zur Frist abgeschlossen werden würde. Die beiden RESOURCE_EXHAUSTED-Fehlercodes können verwendet werden, um anzugeben, dass die Aufgabe aufgrund einer Ressourcenbeschränkung im Treiber fehlgeschlagen ist, z. B. weil der Treiber nicht genügend Speicher für den Aufruf hatte.

Die TRANSIENT-Version beider Fehler weist darauf hin, dass das Problem vorübergehend ist und zukünftige Aufrufe derselben Aufgabe nach einer kurzen Verzögerung erfolgreich sein könnten. Dieser Fehlercode sollte beispielsweise zurückgegeben werden, wenn der Fahrer mit einer vorherigen, zeitaufwendigen oder ressourcenintensiven Aufgabe beschäftigt ist, die neue Aufgabe aber erfolgreich abgeschlossen werden könnte, wenn der Fahrer nicht mit der vorherigen Aufgabe beschäftigt wäre. Die PERSISTENT-Version beider Fehler weist darauf hin, dass zukünftige Aufrufe derselben Aufgabe immer fehlschlagen werden. Dieser Fehlercode sollte beispielsweise zurückgegeben werden, wenn der Treiber schätzt, dass die Aufgabe auch unter perfekten Bedingungen nicht bis zum Ablauf der Frist abgeschlossen werden kann, oder wenn das Modell von Natur aus zu groß ist und die Ressourcen des Treibers übersteigt.

Zertifizierungsstufe

Die QoS-Funktionalität wird in den NNAPI-VTS-Tests (VtsHalNeuralnetworksV1_3Target) getestet. Dazu gehören eine Reihe von Tests zur Validierung (TestGenerated/ValidationTest#Test/), um sicherzustellen, dass der Treiber ungültige Prioritäten ablehnt, und eine Reihe von Tests mit dem Namen DeadlineTest (TestGenerated/DeadlineTest#Test/), um sicherzustellen, dass der Treiber Fristen korrekt verarbeitet.