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 zależny od innych przygotowanych modeli należących do tej samej aplikacji. Uruchomienia o wyższym priorytecie mogą wykorzystywać więcej zasobów obliczeniowych niż wykonania o niższym priorytecie i mogą wywłaszczać wykonania o niższym priorytecie lub je wyprzedzać.

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 Priority w argumentach pamięci podręcznej.

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

  • W przypadku sterowników z wbudowaną obsługą priorytetów prześlij pole Priority bezpośrednio do akceleratora.
  • Użyj kolejki priorytetów na poziomie aplikacji, aby obsługiwać różne priorytety jeszcze przed tym, jak wykonanie dotrze do akceleratora.

  • Wstrzymaj lub anuluj wykonywane modele o niskim priorytecie, aby umożliwić akceleratorowi wykonywanie modeli o wysokim priorytecie. Zrób to przez wstawienie punktów kontrolnych do modeli o niskim priorytecie, które po osiągnięciu wartości wysyłają zapytanie do flagi w celu określenia, czy bieżące wykonanie powinno zostać przedwcześnie wstrzymane, albo partycjonując model w podmodelach i wysyłając zapytanie do flagi między uruchomieniami modelu podrzędnego. Pamiętaj, że używanie punktów kontrolnych lub podmodeli w modelach przygotowanych z użyciem priorytetu może spowodować dodatkowy narzut, 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ć wykonywanie w późniejszym czasie.
    • Pełne wsparcie preempcji nie jest konieczne, więc kontekst wykonania nie musi być zachowany. Ponieważ wykonania modelu NNAPI są deterministyczne, wykonania można później ponownie uruchamiać od zera.

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

Począwszy od Androida 11 przygotowanie i wykonanie modelu można uruchamiać za pomocą argumentu terminu OptionalTimePoint. Kierowcy, którzy potrafią 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 ten pozwala kierowcy przerwać trwające zadanie, którego według szacunków nie zostanie ono wykonane przed wyznaczonym terminem. Argument deadline nie powoduje, że kierowca musi przerwać zadanie, jeśli nie zostało ono ukończone do terminu lub jeśli termin minął. Argument deadline można użyć, aby zwolnić zasoby obliczeniowe w sterowniku i szybciej zwrócić kontrolę nad aplikacją niż jest to możliwe bez użycia argumentu deadline.

Następujące wywołania NN HAL 1.3 zawierają w argumencie 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 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, 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 może wskazać awarię tylko za pomocą kodu błędu GENERAL_FAILURE. Od Androida 11 za pomocą 2 kodów błędów MISSED_DEADLINE można wskazać, że zadanie zostało przerwane z powodu osiągnięcia terminu lub przewidywań przez kierowcę, że zadanie nie zostanie ukończone w wyznaczonym terminie. Te 2 kody błędów RESOURCE_EXHAUSTED mogą wskazywać, że zadanie nie powiodło się z powodu ograniczenia 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 intensywnym 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 zakończą się niepowodzeniem. Ten kod błędu powinien być zwracany na przykład wtedy, gdy kierowca szacuje, że zadanie nie zostanie wykonane w terminie, nawet przy idealnych warunkach, lub że model z natury jest za duży i przekracza zasoby kierowcy.

Weryfikacja

Funkcje jakości usługi są testowane 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.