Jakość usługi

Począwszy od Androida 11 interfejs NNAPI zapewnia lepszą jakość usług (QoS), ponieważ pozwala aplikacji wskazywać względne priorytety swoich modeli, maksymalny czas przygotowania danego modelu oraz maksymalny czas oczekiwania na zakończenie danego wykonania. Ponadto Android 11 wprowadza dodatkowe wartości błędów NNAPI, które umożliwiają usługom dokładniejsze wskazanie, co poszło nie tak, gdy wystąpił błąd. Dzięki temu aplikacja kliencka może lepiej zareagować i przywrócić działanie.

Priorytet

W przypadku Androida 11 lub nowszego modele są przygotowywane z priorytetem w NN HAL 1.3. Ten priorytet jest określany w stosunku do innych przygotowanych modeli należących do tej samej aplikacji. Modele o wyższym priorytecie mogą korzystać z większej ilości zasobów obliczeniowych niż modele o niższym priorytecie, a także mogą wywłaszczać lub blokować modele o niższym priorytecie.

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

Istnieje wiele strategii wspierania priorytetów w zależności od możliwości kierowcy i przyspieszacza. Oto kilka strategii:

  • W przypadku kierowców, którzy mają wbudowaną obsługę priorytetową, bezpośrednio przeprowadź pole Priority do akceleratora.
  • Użyj kolejki priorytetów dla poszczególnych aplikacji, aby obsługiwać różne priorytety jeszcze przed dotarciem wykonania do akceleratora.

  • Wstrzymaj lub anuluj modele o niskim priorytecie, które są wykonywane, aby zwolnić akcelerator na potrzeby wykonywania modeli o wyższym priorytecie. Można to zrobić, umieszczając punkty kontrolne w modelach o niskim priorytecie, które po osiągnięciu sprawdzają flagę, aby określić, czy bieżące wykonanie powinno zostać przerwane, lub dzieląc model na modele podrzędne i sprawdzając flagę między wykonaniami modelu podrzędnego. Pamiętaj, że używanie punktów kontrolnych lub podmodeli w modelach przygotowanych z użyciem priorytetu może spowodować dodatkowe obciążenie, którego nie ma w przypadku modeli bez priorytetu w wersjach starszych niż NN HAL 1.3.

    • Aby obsługiwać wymuszanie, zachowaj kontekst wykonania, w tym kolejną operację lub podmodel do wykonania oraz wszystkie istotne dane pośrednie. Użyj tego kontekstu wykonania, aby wznowić wykonanie w późniejszym czasie.
    • Pełne wsparcie preempcji nie jest konieczne, więc kontekst wykonania nie musi być zachowany. Wykonywanie modeli za pomocą interfejsu NNAPI jest zdeterminowane, więc można je wznowić od początku w dowolnym momencie.

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

Terminy

Od Androida 11 przygotowanie modelu i jego wykonywanie można uruchamiać za pomocą argumentu OptionalTimePoint. Kierowcy, którzy mogą oszacować czas wykonania zadania, mogą je przerwać przed rozpoczęciem, jeśli uznają, że nie uda im się ukończyć go przed terminem. Podobnie termin pozwala kierowcy przerwać bieżące zadanie, które według niego nie zostanie ukończone przed terminem. Argument deadline nie zmusza kierowcy do przerwania zadania, jeśli nie zostało ono ukończone przed terminem lub jeśli termin minął. Argument deadline można użyć do zwolnienia zasobów obliczeniowych w sterowniku i szybszego przekazania kontroli nad aplikacją niż jest to możliwe bez użycia argumentu deadline.

Następujące wywołania NN HAL 1.3 zawierają jako argument terminy OptionalTimePoint:

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

Aby zobaczyć referencyjne wdrożenie funkcji deadline w przypadku każdej z wymienionych wyżej metod, zapoznaj się z próbnym 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, aby ulepszyć raportowanie błędów. Dzięki temu sterowniki mogą lepiej komunikować swój stan, a aplikacje szybciej się uruchamiają. Są to wartości kodów błędów w pliku 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ą kodu błędu GENERAL_FAILURE. Od Androida 11 można używać 2 kodów błędu MISSED_DEADLINE, aby wskazać, że zadanie zostało przerwane, ponieważ upłynął termin jego realizacji lub kierowca przewidział, że nie zostanie ono ukończone do tego czasu. Dwa kody błędów RESOURCE_EXHAUSTED mogą wskazywać, że zadanie nie zostało wykonane z powodu ograniczeń zasobów w sterowniku, np. gdy sterownik nie ma wystarczającej ilości pamięci na wywołanie.

W przypadku obu błędów wersja TRANSIENT oznacza, że problem jest przejściowy i przyszłe wywołania tego samego zadania mogą się powieść po krótkim opóźnieniu. Ten kod błędu powinien zostać zwrócony, gdy sterownik jest zajęty poprzednim długotrwałym lub wymagającym dużej ilości zasobów zadaniem, ale nowe zadanie zostanie ukończone pomyślnie, jeśli sterownik nie był zajęty poprzednim zadaniem. Wersja PERSISTENT obu błędów wskazuje, że przyszłe wywołania tego samego zadania zawsze się nie powiedzą. Ten kod błędu powinien zostać zwrócony, gdy według kierowcy zadanie nie zostanie ukończone do terminu nawet w idealnych warunkach lub gdy model jest zbyt duży i przekracza zasoby kierowcy.

Weryfikacja

Funkcja jakości usługi jest testowana w ramach testów VTS NNAPI (VtsHalNeuralnetworksV1_3Target). Obejmuje to zestaw testów weryfikacyjnych (TestGenerated/ValidationTest#Test/), które mają na celu zapewnienie, że sterownik odrzuca nieprawidłowe priorytety, oraz zestaw testów o nazwie DeadlineTest (TestGenerated/DeadlineTest#Test/), które mają na celu zapewnienie, że sterownik poprawnie obsługuje terminy.