Dienstqualität

Ab Android 11 bietet die NNAPI eine bessere Dienstqualität (Quality of Service, QoS), da eine App die relativen Prioritäten ihrer Modelle, die maximale Zeit, die für die Vorbereitung eines bestimmten Modells benötigt wird, und die maximale Zeit, die für die Ausführung einer bestimmten Ausführung benötigt 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 schiefgelaufen 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 ist relativ zu anderen vorbereiteten Modellen derselben App. 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 unterbrechen oder ausbremsen.

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

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

  • Bei Treibern mit integrierter Prioritätsunterstützung leiten Sie das Feld Priority direkt an den Accelerator weiter.
  • Verwenden Sie eine prioritätsbasierte Warteschlange pro App, um unterschiedliche Prioritäten zu unterstützen, noch bevor eine Ausführung den Accelerator erreicht.

  • Pausieren oder beenden Sie Modelle mit niedriger Priorität, die gerade ausgeführt werden, um den Accelerator für die Ausführung von Modellen mit hoher Priorität freizugeben. Dazu können Sie entweder Checkpunkte 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 partitionieren und das Flag zwischen den Ausführungen der Untermodelle abfragen. Die Verwendung von Checkpoints oder Untermodellen in Modellen, die mit einer Priorität erstellt wurden, kann zu zusätzlichem Overhead führen, der bei Modellen ohne Priorität in Versionen niedriger als NN HAL 1.3 nicht vorhanden ist.

    • Um die Voraktivierung zu unterstützen, bewahren Sie den Ausführungskontext auf, einschließlich des nächsten auszuführenden Vorgangs oder Untermodells und aller relevanten Zwischenoperandendaten. Verwenden Sie diesen Ausführungskontext, um die Ausführung später fortzusetzen.
    • Eine vollständige Unterstützung der Voremption ist nicht erforderlich, sodass der Ausführungskontext nicht beibehalten werden muss. Da NNAPI-Modellausführungen deterministisch sind, können sie zu einem späteren Zeitpunkt neu gestartet werden.

Android ermöglicht es Diensten, mithilfe einer AID (Android-UID) zwischen verschiedenen Anruf-Apps zu unterscheiden. HIDL bietet integrierte Mechanismen zum Abrufen der UID der aufrufenden App über die Methode ::android::hardware::IPCThreadState::getCallingUid. Eine Liste der AIDs findest du unter libcutils/include/cutils/android_filesystem_config.h.

Fristen

Ab Android 11 können die Modellvorbereitung und ‑ausführung mit einem OptionalTimePoint-Argument für den Termin gestartet werden. Fahrer, die abschätzen können, wie lange eine Aufgabe dauert, können diese Frist nutzen, um die Aufgabe vor Beginn abzubrechen, wenn sie der Meinung sind, dass sie nicht vor Ablauf der Frist abgeschlossen werden kann. Ebenso kann der Fahrer eine laufende Aufgabe abbrechen, die voraussichtlich nicht vor dem Termin abgeschlossen wird. Das Argument „deadline“ zwingt einen Treiber nicht dazu, eine Aufgabe abzubrechen, wenn sie nicht bis zum Termin abgeschlossen ist oder der Termin verstrichen ist. Mit dem Argument „deadline“ können Sie Rechenressourcen im Treiber freigeben und die Kontrolle schneller an die App zurückgeben, als es ohne das Argument möglich wäre.

Die NN HAL 1.3-Aufrufe, die OptionalTimePoint-Termine 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-Beispieltreiber unter frameworks/ml/nn/driver/sample/SampleDriver.cpp.

Fehlercodes

Android 11 enthält vier Fehlercodewerte in NN HAL 1.3, um die Fehlermeldung 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 der Termin erreicht wurde oder weil der Treiber vorhersagte, dass die Arbeitslast nicht bis zum Termin abgeschlossen werden kann. Die beiden RESOURCE_EXHAUSTED-Fehlercodes können darauf hinweisen, dass die Aufgabe aufgrund einer Ressourcenbeschränkung im Treiber fehlgeschlagen ist, z. B. wenn der Treiber nicht genügend Arbeitsspeicher für den Aufruf hat.

Die TRANSIENT-Version beider Fehler gibt an, dass das Problem vorübergehend ist und dass zukünftige Aufrufe derselben Aufgabe nach einer kurzen Verzögerung erfolgreich sein können. Dieser Fehlercode sollte beispielsweise zurückgegeben werden, wenn der Fahrer mit einer vorherigen langwierigen oder ressourcenintensiven Arbeit beschäftigt ist, die neue Aufgabe aber erfolgreich abgeschlossen werden würde, wenn der Fahrer nicht mit der vorherigen Arbeit beschäftigt wäre. Die PERSISTENT-Version beider Fehler gibt an, dass zukünftige Aufrufe derselben Aufgabe immer fehlschlagen. Dieser Fehlercode sollte beispielsweise zurückgegeben werden, wenn der Fahrer schätzt, dass die Aufgabe selbst unter idealen Bedingungen nicht bis zum Termin abgeschlossen werden kann, oder wenn das Modell von Natur aus zu groß ist und die Ressourcen des Fahrers übersteigt.

Zertifizierungsstufe

Die Dienstqualität wird in den NNAPI-VTS-Tests (VtsHalNeuralnetworksV1_3Target) geprüft. Dazu gehören eine Reihe von Validierungstests (TestGenerated/ValidationTest#Test/), mit denen sichergestellt wird, dass der Treiber ungültige Prioritäten ablehnt, und eine Reihe von Tests namens DeadlineTest (TestGenerated/DeadlineTest#Test/), mit denen sichergestellt wird, dass der Treiber Fristen richtig handhabt.