Servicequalität

Ab Android 11 bietet die NNAPI eine bessere Dienstqualität, da eine App die relativen Prioritäten ihrer Modelle, die erwartete maximale Vorbereitungszeit für ein bestimmtes Modell und die für die Ausführung einer bestimmten Ausführung erwartete maximale Zeit 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 durchführen kann.

Priorität

Ab Android 11 werden Modelle mit einer Priorität in NN HAL 1.3 vorbereitet. Diese Priorität ist relativ zu anderen vorbereiteten Modellen derselben Anwendung. Ausführungen mit höherer Priorität können mehr Rechenressourcen als Ausführungen mit niedrigerer Priorität verwenden und Ausführungen mit niedrigerer Priorität vorzeitig beenden oder vermindern.

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 die Cache-Argumente einbezieht.

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 mehrere Strategien:

• Bei Treibern mit integrierter Prioritätsunterstützung geben Sie das Feld Priority direkt an den Beschleuniger weiter.
• Verwenden Sie eine anwendungsspezifische Prioritätswarteschlange, um verschiedene Prioritäten zu unterstützen, noch bevor eine Ausführung den Beschleuniger erreicht.

• Sie können ausgeführte Modelle mit niedriger Priorität pausieren oder abbrechen, um den Beschleuniger für die Ausführung von Modellen mit hoher Priorität freizugeben. Dazu können Sie entweder Checkpoints in Modelle mit niedriger Priorität einfügen, die bei Erreichen eines Flags ein Flag abfragen, um zu bestimmen, ob die aktuelle Ausführung vorzeitig angehalten werden soll, oder das Modell in Untermodelle partitionieren und zwischen Untermodellausführungen das Flag abfragen. Die Verwendung von Prüfpunkten oder Untermodellen in Modellen, die mit einer Priorität erstellt wurden, kann zusätzlichen Aufwand verursachen, der für Modelle ohne Priorität in Versionen niedriger als NN HAL 1.3 nicht fällig 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 zu einem späteren Zeitpunkt fortzusetzen.
  • Eine vollständige Unterstützung des vorzeitigen Beendens ist nicht erforderlich, sodass der Ausführungskontext nicht beibehalten werden muss. Da NNAPI-Modellausführungen deterministisch sind, können Ausführungen später neu gestartet werden.

Android ermöglicht es Diensten, zwischen verschiedenen Anruf-Apps zu unterscheiden, indem sie eine AID (Android-UID) verwenden. HIDL hat integrierte Mechanismen, um die UID der aufrufenden App über die Methode ::android::hardware::IPCThreadState::getCallingUid abzurufen. 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, haben die Möglichkeit, die Aufgabe mit dieser Frist abzubrechen, wenn sie davon ausgehen, dass die Aufgabe nicht vor Ablauf der Frist erledigt werden kann. Ebenso ermöglicht die Frist dem Fahrer, eine laufende Aufgabe abzubrechen, von der es erwartet, dass sie nicht vor Ablauf der Frist abgeschlossen wird. Das Terminargument erzwingt einen Treiber nicht, eine Aufgabe abzubrechen, wenn die Aufgabe nicht innerhalb der Frist abgeschlossen wird oder die Frist abgelaufen ist. Mit dem Argument dafür können Sie Rechenressourcen innerhalb des Treibers freigeben und die Steuerung schneller an die Anwendung zurückgeben, als dies ohne Frist möglich ist.

Folgende NN HAL 1.3-Aufrufe, die OptionalTimePoint-Zeitlimits 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 ihre 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

In Android 10 oder niedriger konnte ein Treiber einen Fehler nur über den Fehlercode GENERAL_FAILURE anzeigen. 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 der Treiber vorhergesagt hat, dass die Arbeitslast bis zum Ablauf der Frist nicht abgeschlossen werden würde. 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 Treiber mit vorherigen oder ressourcenintensiven Aufgaben beschäftigt ist, aber dass die neue Aufgabe erfolgreich abgeschlossen werden würde, wenn der Fahrer nicht mit den vorherigen Arbeiten beschäftigt ist. Die PERSISTENT-Version beider Fehler gibt an, dass zukünftige Aufrufe derselben Aufgabe immer fehlschlagen. Dieser Fehlercode sollte beispielsweise zurückgegeben werden, wenn der Treiber davon ausgeht, dass die Aufgabe selbst unter perfekten Bedingungen nicht innerhalb der Frist abgeschlossen werden würde oder dass das Modell von Natur aus zu groß ist und die Ressourcen des Treibers überschreitet.

Zertifizierungsstufe

Die Funktionalität der Dienstqualität wird in den NNAPI-VTS-Tests (VtsHalNeuralnetworksV1_3Target) getestet. Dazu gehören eine Reihe von Tests zur Validierung (TestGenerated/ValidationTest#Test/), mit denen sichergestellt wird, 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 handhabt.