Servicequalität

Ab Android 11 bietet die NNAPI eine bessere Servicequalität (QoS), indem sie einer App ermöglicht, die relativen Prioritäten ihrer Modelle, die maximale Zeit, die für die Vorbereitung eines bestimmten Modells erwartet wird, und die maximale Zeit, die erwartet wird, anzugeben eine bestimmte Ausführung muss abgeschlossen werden. Darüber hinaus führt Android 11 zusätzliche NNAPI-Fehlerwerte ein, die es einem Dienst ermöglichen, bei einem Fehler genauer anzugeben, was schief gelaufen ist, sodass die Client-App besser reagieren und eine Wiederherstellung durchführen kann.

Priorität

Für Android 11 oder höher sind Modelle mit Priorität im 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 vorwegnehmen oder ausschließen.

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 Fahrers und des Beschleunigers gibt es viele mögliche Strategien zur Unterstützung der 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 Prioritätswarteschlange pro App, um unterschiedliche Prioritäten zu unterstützen, noch bevor eine Ausführung den Beschleuniger erreicht.

• Unterbrechen oder brechen Sie die Ausführung von Modellen mit niedriger Priorität ab, um den Beschleuniger für die Ausführung von Modellen mit hoher Priorität freizugeben. Tun Sie dies, indem Sie entweder Prüfpunkte in Modelle mit niedriger Priorität einfügen, die bei Erreichen ein Flag abfragen, um zu bestimmen, ob die aktuelle Ausführung vorzeitig angehalten werden soll, oder indem Sie das Modell in Untermodelle unterteilen und das Flag zwischen Untermodellausführungen abfragen. Beachten Sie, dass die Verwendung von Prüfpunkten oder Untermodellen in Modellen, die mit einer Priorität erstellt wurden, zu einem zusätzlichen Overhead führen kann, der bei Modellen ohne Priorität in Versionen vor NN HAL 1.3 nicht vorhanden ist.

  • Um die vorzeitige Beendigung zu unterstützen, bewahren Sie den Ausführungskontext einschließlich der nächsten auszuführenden Operation oder des nächsten auszuführenden Untermodells und aller relevanten Zwischenoperandendaten auf. Verwenden Sie diesen Ausführungskontext, um die Ausführung zu einem späteren Zeitpunkt fortzusetzen.
  • Eine vollständige Preemption-Unterstützung ist nicht erforderlich, daher muss der Ausführungskontext nicht beibehalten werden. 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, mithilfe einer AID (Android UID) zwischen verschiedenen aufrufenden Apps zu unterscheiden. 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 in libcutils/include/cutils/android_filesystem_config.h .

Fristen

Ab Android 11 können Modellvorbereitung und -ausführung mit einem OptionalTimePoint Fristargument gestartet werden. Für Fahrer, die abschätzen können, wie lange eine Aufgabe dauert, ermöglicht diese Frist dem Fahrer, die Aufgabe abzubrechen, bevor sie beginnt, wenn der Fahrer schätzt, dass die Aufgabe nicht vor Ablauf der Frist abgeschlossen werden kann. Ebenso ermöglicht die Frist dem Fahrer, eine laufende Aufgabe abzubrechen, von der er annimmt, dass sie nicht vor Ablauf der Frist abgeschlossen werden wird. Das Deadline-Argument zwingt einen Treiber nicht dazu, eine Aufgabe abzubrechen, wenn die Aufgabe nicht bis zum Deadline abgeschlossen ist oder wenn die Deadline verstrichen ist. Das Deadline-Argument kann verwendet werden, um Rechenressourcen innerhalb des Treibers freizugeben und die Kontrolle schneller an die App zurückzugeben, als dies ohne die Deadline möglich wäre.

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-Beispieltreiber unter frameworks/ml/nn/driver/sample/SampleDriver.cpp .

Fehlercodes

Android 11 enthält in NN HAL 1.3 vier Fehlercodewerte, um die Fehlerberichterstattung zu verbessern, sodass Fahrer ihren Status besser kommunizieren können 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 konnte ein Treiber einen Fehler nur über den Fehlercode GENERAL_FAILURE anzeigen. Ab Android 11 können die beiden Fehlercodes MISSED_DEADLINE verwendet werden, um anzuzeigen, dass die Arbeitslast abgebrochen wurde, weil die Frist erreicht wurde oder weil der Treiber vorhergesagt hat, dass die Arbeitslast nicht bis zur Frist abgeschlossen sein würde. Die beiden Fehlercodes RESOURCE_EXHAUSTED können verwendet werden, um anzuzeigen, dass die Aufgabe aufgrund einer Ressourcenbeschränkung innerhalb des Treibers fehlgeschlagen ist, beispielsweise weil der Treiber nicht über genügend Speicher für den Aufruf verfügt.

Die TRANSIENT Version beider Fehler weist darauf hin, dass das Problem vorübergehend ist und dass zukünftige Aufrufe derselben Aufgabe nach einer kurzen Verzögerung erfolgreich sein könnten. Dieser Fehlercode sollte beispielsweise zurückgegeben werden, wenn der Treiber mit vorherigen 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 wäre. Die PERSISTENT Version beider Fehler weist darauf hin, dass künftige Aufrufe derselben Aufgabe voraussichtlich immer fehlschlagen werden. Dieser Fehlercode sollte beispielsweise zurückgegeben werden, wenn der Treiber davon ausgeht, dass die Aufgabe selbst unter perfekten Bedingungen nicht fristgerecht abgeschlossen werden würde oder dass das Modell von Natur aus zu groß ist und die Ressourcen des Treibers überschreitet.

Validierung

Die Quality-of-Service-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 namens DeadlineTest ( TestGenerated/DeadlineTest#Test/ ), um sicherzustellen, dass der Treiber Fristen korrekt verarbeitet.