Jakość usługi

Od Androida 11 interfejs NNAPI oferuje lepszą jakość usług (QoS), ponieważ umożliwia aplikacji określanie względnych priorytetów modeli, maksymalnego czasu oczekiwania na przygotowanie danego modelu i maksymalnego czasu oczekiwania na zakończenie danego wykonania. Android 11 wprowadza też dodatkowe wartości błędów NNAPI, które umożliwiają usłudze dokładniejsze wskazywanie, co poszło nie tak w przypadku wystąpienia błędu, aby aplikacja kliencka mogła lepiej reagować i odzyskiwać sprawność.

Priorytet

W przypadku Androida 11 lub nowszego modele są przygotowywane z priorytetem w NN HAL 1.3. Ten priorytet jest względny w stosunku do innych przygotowanych modeli należących do tej samej aplikacji. Wykonania o wyższym priorytecie mogą wykorzystywać więcej zasobów obliczeniowych niż wykonania o niższym priorytecie i mogą je wyprzedzać lub blokować.

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

Istnieje wiele możliwych strategii obsługi priorytetów w zależności od możliwości sterownika i akceleratora. Oto kilka strategii:

  • W przypadku sterowników z wbudowaną pomocą priorytetową bezpośrednio propaguj pole Priority do akceleratora.
  • Używaj kolejki priorytetowej dla poszczególnych aplikacji, aby obsługiwać różne priorytety jeszcze zanim wykonanie dotrze do akceleratora.

  • Wstrzymuj lub anuluj modele o niskim priorytecie, które są wykonywane, aby zwolnić akcelerator na potrzeby modeli o wysokim priorytecie. Możesz to zrobić, wstawiając punkty kontrolne w modelach o niskim priorytecie, które po osiągnięciu wysyłają zapytanie o flagę, 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. Pamiętaj, że używanie punktów kontrolnych lub podmodeli w modelach przygotowanych z priorytetem może wprowadzać dodatkowe obciążenie, które nie występuje w modelach bez priorytetu w wersjach starszych 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 operandów pośrednich. Użyj tego kontekstu wykonania, aby wznowić wykonanie w późniejszym czasie.
    • Pełna obsługa wywłaszczenia nie jest konieczna, więc kontekst wykonania nie musi być zachowany. Ponieważ wykonania modelu NNAPI są deterministyczne, można je później ponownie uruchomić od początku.

Android umożliwia usługom rozróżnianie różnych aplikacji do dzwonienia za pomocą identyfikatora AID (Android UID). HIDL ma wbudowane mechanizmy pobierania identyfikatora UID aplikacji wywołującej za pomocą metody ::android::hardware::IPCThreadState::getCallingUid. Listę identyfikatorów urządzeń znajdziesz libcutils/include/cutils/android_filesystem_config.h.

Terminy

Od Androida 11 przygotowywanie i wykonywanie modelu można uruchamiać z argumentem OptionalTimePoint deadline. W przypadku kierowców, którzy potrafią oszacować czas wykonania zadania, ten termin pozwala im przerwać zadanie przed jego rozpoczęciem, jeśli uznają, że nie da się go wykonać przed upływem terminu. Podobnie termin umożliwia kierowcy przerwanie trwającego zadania, które według jego szacunków nie zostanie ukończone przed upływem terminu. Argument deadline nie wymusza przerwania zadania przez kierowcę, jeśli nie zostanie ono wykonane do terminu lub jeśli termin minął. Argument deadline może służyć do zwalniania zasobów obliczeniowych w sterowniku i szybszego niż bez niego przekazywania kontroli nad aplikacją.

Wywołania NN HAL 1.3, które zawierają terminy OptionalTimePoint jako argument:

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

Aby zobaczyć implementację referencyjną funkcji terminu dla każdej z powyższych metod, zapoznaj się z przykładowym sterownikiem NNAPI na stronie frameworks/ml/nn/driver/sample/SampleDriver.cpp.

Kody błędów

Android 11 zawiera 4 wartości kodów błędów w NN HAL 1.3, co ulepsza raportowanie błędów i umożliwia sterownikom lepsze informowanie o swoim stanie, a aplikacjom – sprawniejsze przywracanie działania. Są to wartości kodów błędów w ErrorStatus.

  • MISSED_DEADLINE_TRANSIENT
  • MISSED_DEADLINE_PERSISTENT
  • RESOURCE_EXHAUSTED_TRANSIENT
  • RESOURCE_EXHAUSTED_PERSISTENT

W Androidzie 10 lub starszym sterownik mógł wskazywać błąd tylko za pomocą GENERAL_FAILUREkodu błędu. Od Androida 11 można używać 2 MISSED_DEADLINE kodów błędów, aby wskazać, że zbiór zadań został przerwany, ponieważ upłynął termin lub sterownik przewidział, że zbiór zadań nie zostanie ukończony przed upływem terminu. Te 2 kody błędów RESOURCE_EXHAUSTED mogą wskazywać, że zadanie nie powiodło się z powodu ograniczenia zasobów w sterowniku, np. sterownik nie ma wystarczającej ilości pamięci na potrzeby wywołania.

Wersja TRANSIENT obu błędów oznacza, ż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 być zwracany, gdy sterownik jest zajęty długotrwałym lub wymagającym dużych zasobów zadaniem, ale nowe zadanie zostałoby wykonane prawidłowo, gdyby sterownik nie był zajęty poprzednim zadaniem. Wersja PERSISTENT obu błędów oznacza, że przyszłe wywołania tego samego zadania zawsze będą kończyć się niepowodzeniem. Ten kod błędu powinien być zwracany np. wtedy, gdy sterownik szacuje, że zadanie nie zostanie wykonane przed terminem, nawet w idealnych warunkach, lub gdy model jest zbyt duży i przekracza zasoby sterownika.

Weryfikacja

Funkcja jakości usług jest testowana w testach VTS interfejsu NNAPI (VtsHalNeuralnetworksV1_3Target). Obejmuje to zestaw testów weryfikacyjnych (TestGenerated/ValidationTest#Test/), które sprawdzają, czy sterownik odrzuca nieprawidłowe priorytety, oraz zestaw testów o nazwie DeadlineTest (TestGenerated/DeadlineTest#Test/), które sprawdzają, czy sterownik prawidłowo obsługuje terminy.