Servicequalitä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. Darüber hinaus werden in Android 11 zusätzliche NNAPI-Fehlerwerte eingeführt, damit ein Dienst genauer angeben kann, was beim Auftreten eines Fehlers schiefgelaufen ist, sodass die Client-App besser reagieren und die Wiederherstellung ausführen 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.

Abhängig von den Fähigkeiten des Treibers und des Beschleunigers 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.

    • Behalten Sie den Ausführungskontext einschließlich des nächsten auszuführenden Vorgangs oder Untermodells und aller relevanten Operandendaten bei, um ein vorzeitiges Beenden zu ermöglichen. 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, zwischen verschiedenen Anruf-Apps zu unterscheiden, indem sie eine AID (Android-UID) verwenden. HIDL bietet integrierte Mechanismen zum Abrufen der UID der aufrufenden App über die Methode ::android::hardware::IPCThreadState::getCallingUid. Eine Liste der AIDs finden Sie in libcutils/include/cutils/android_filesystem_config.h.

Fristen

Ab Android 11 können Modellvorbereitung und -ausführungen mit dem Zeitlimit-Argument OptionalTimePoint gestartet werden. Fahrer, die abschätzen können, wie lange eine Aufgabe dauert, können sie vor Beginn abbrechen, wenn sie der Meinung sind, dass sie nicht vor Ablauf des Termins 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 Deadline-Argument können Rechenressourcen innerhalb des Treibers freigegeben und die Steuerung schneller an die Anwendung zurückgegeben werden, als dies ohne Frist möglich ist.

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 Fehlerberichte zu verbessern. So können Fahrer ihren Status und Apps besser kommunizieren und eine ordnungsgemäße Wiederherstellung vornehmen. Dies 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 angeben, 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. Mit den beiden RESOURCE_EXHAUSTED-Fehlercodes kann angegeben werden, dass die Aufgabe aufgrund einer Ressourcenbeschränkung innerhalb des Treibers fehlgeschlagen ist, z. B. weil 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.