Jakość usługi

Począwszy od Androida 11, NNAPI oferuje lepszą jakość usług (QoS), umożliwiając aplikacji wskazanie względnych priorytetów jej modeli, maksymalny czas oczekiwany na przygotowanie danego modelu i maksymalny czas oczekiwany na dana egzekucja do wykonania. Ponadto system Android 11 wprowadza dodatkowe wartości błędów NNAPI, dzięki czemu usługa może dokładniej wskazywać, co poszło nie tak, gdy wystąpi awaria, dzięki czemu aplikacja kliencka może lepiej reagować i odzyskiwać dane.

Priorytet

Dla Androida 11 lub nowszego modele są przygotowywane z priorytetem w NN HAL 1.3. Ten priorytet dotyczy innych przygotowanych modeli należących do tej samej aplikacji. Wykonania o wyższym priorytecie mogą zużywać więcej zasobów obliczeniowych niż wykonania o niższym priorytecie i mogą wywłaszczać lub blokować wykonania o niższym priorytecie.

Wywołanie NN HAL 1.3, które zawiera Priority jako jawny argument, to IDevice::prepareModel_1_3 . Zauważ, że IDevice::prepareModelFromCache_1_3 niejawnie zawiera Priority w argumentach pamięci podręcznej.

Istnieje wiele możliwych strategii wspierania priorytetów w zależności od możliwości kierowcy i pedału przyspieszenia. Oto kilka strategii:

  • W przypadku sterowników, które mają wbudowaną obsługę priorytetów, propaguj bezpośrednio pole Priority do akceleratora.
  • Użyj kolejki priorytetów dla aplikacji, aby obsługiwać różne priorytety, nawet zanim wykonanie dotrze do akceleratora.

  • Wstrzymaj lub anuluj modele o niskim priorytecie, które są obecnie wykonywane, aby zwolnić akcelerator do wykonywania modeli o wysokim priorytecie. Zrób to, wstawiając punkty kontrolne w modelach o niskim priorytecie, które po osiągnięciu, wysyłają zapytanie do flagi, aby określić, czy bieżące wykonanie powinno zostać przedwcześnie zatrzymane, lub dzieląc model na podmodele i wysyłając zapytanie o flagę między wykonaniami podmodeli. Należy pamiętać, że użycie punktów kontrolnych lub podmodeli w modelach przygotowanych z priorytetem może wprowadzić dodatkowe obciążenie, którego nie ma dla modeli bez priorytetu w wersjach niższych niż NN HAL 1.3.

    • Aby obsługiwać wywłaszczanie, zachowaj kontekst wykonania, w tym następną operację lub podmodel do wykonania oraz wszelkie odpowiednie dane operandu pośredniego. Użyj tego kontekstu wykonania, aby wznowić wykonanie w późniejszym czasie.
    • Pełna obsługa wywłaszczania nie jest konieczna, więc kontekst wykonania nie musi być zachowywany. Ponieważ wykonania modelu NNAPI są deterministyczne, wykonania można ponownie uruchomić od zera w późniejszym czasie.

Android umożliwia usługom rozróżnianie różnych aplikacji do wykonywania połączeń za pomocą identyfikatora AID (Android UID). HIDL ma wbudowane mechanizmy pobierania UID aplikacji wywołującej za pomocą metody ::android::hardware::IPCThreadState::getCallingUid . Listę AID można znaleźć w libcutils/include/cutils/android_filesystem_config.h .

Terminy

Począwszy od systemu Android 11, przygotowanie i wykonanie modelu można uruchomić za pomocą argumentu terminu OptionalTimePoint . W przypadku kierowców, którzy mogą oszacować, ile czasu zajmuje zadanie, ten termin umożliwia kierowcy przerwanie zadania przed jego rozpoczęciem, jeśli kierowca oszacuje, że zadanie nie może zostać ukończone przed terminem. Podobnie termin ostateczny umożliwia kierowcy przerwanie bieżącego zadania, które według szacunków nie zostanie ukończone przed upływem terminu. Argument terminu nie zmusza kierowcy do przerwania zadania, jeśli zadanie nie zostało ukończone w terminie lub jeśli termin minął. Argument terminu może zostać wykorzystany do zwolnienia zasobów obliczeniowych w sterowniku i zwrócenia kontroli do aplikacji szybciej niż jest to możliwe bez terminu.

Wywołania NN HAL 1.3 zawierające terminy OptionalTimePoint jako argument to:

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

Aby zobaczyć referencyjną implementację funkcji terminu ostatecznego dla każdej z powyższych metod, zobacz przykładowy sterownik NNAPI pod adresem frameworks/ml/nn/driver/sample/SampleDriver.cpp .

Kody błędów

Android 11 zawiera cztery wartości kodów błędów w NN HAL 1.3, które usprawniają raportowanie błędów, dzięki czemu sterowniki mogą lepiej komunikować swój stan i aplikacje w celu łatwiejszego odzyskiwania. Są to wartości kodów błędów w ErrorStatus .

  • MISSED_DEADLINE_TRANSIENT
  • MISSED_DEADLINE_PERSISTENT
  • RESOURCE_EXHAUSTED_TRANSIENT
  • RESOURCE_EXHAUSTED_PERSISTENT

W systemie Android 10 lub starszym sterownik mógł wskazać awarię tylko za pomocą kodu błędu GENERAL_FAILURE . W systemie Android 11 dwa kody błędów MISSED_DEADLINE mogą służyć do wskazania, że ​​obciążenie zostało przerwane, ponieważ osiągnięto termin lub ponieważ sterownik przewidywał, że obciążenie nie zostanie ukończone w terminie. Dwa kody błędów RESOURCE_EXHAUSTED mogą służyć do wskazania, że ​​zadanie nie powiodło się z powodu ograniczenia zasobów w sterowniku, takiego jak brak pamięci dla sterownika.

Wersja TRANSIENT obu błędów wskazuje, że problem jest tymczasowy i że przyszłe wywołania tego samego zadania mogą się powieść po krótkim opóźnieniu. Na przykład ten kod błędu powinien zostać zwrócony, gdy kierowca jest zajęty wcześniejszą długotrwałą lub wymagającą dużej ilości zasobów pracą, ale nowe zadanie zakończy się pomyślnie, jeśli kierowca nie był zajęty poprzednią pracą. Wersja PERSISTENT obu błędów wskazuje, że przyszłe wywołania tego samego zadania zawsze będą się kończyć niepowodzeniem. Na przykład ten kod błędu powinien zostać zwrócony, gdy kierowca szacuje, że zadanie nie zostanie ukończone w terminie, nawet w idealnych warunkach, lub gdy model jest z natury zbyt duży i przekracza zasoby sterownika.

Walidacja

Jakość funkcjonalności usługi jest testowana w testach NNAPI VTS ( VtsHalNeuralnetworksV1_3Target ). Obejmuje to zestaw testów do walidacji ( TestGenerated/ValidationTest#Test/ ), aby upewnić się, że sterownik odrzuca nieprawidłowe priorytety, oraz zestaw testów o nazwie DeadlineTest ( TestGenerated/DeadlineTest#Test/ ), aby upewnić się, że sterownik prawidłowo obsługuje terminy.