Jakość usługi

Wycofane: w Androidzie 15 (wersja eksperymentalna AOSP) interfejs NNAPI (NDK API) został wycofany. Interfejs HAL Neural Networks jest nadal obsługiwany.

Więcej informacji znajdziesz w przewodniku po migracji NNAPI.

Począwszy od Androida 11 NNAPI oferuje lepszą jakość usług (QoS), ponieważ umożliwia aplikacji wskazanie względnych priorytetów swoich modeli, maksymalnego czasu oczekiwanego na przygotowanie danego modelu i maksymalnego czasu potrzebnego na wykonanie danego wykonania. Dodatkowo Android 11 wprowadza dodatkowe wartości błędów NNAPI, które pozwalają usłudze dokładniej wskazywać, co poszło nie tak w przypadku awarii, dzięki czemu aplikacja kliencka może lepiej zareagować i przywracać dane.

Priorytet

Na potrzeby 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, w którym wyraźnym argumentem jest Priority, to IDevice::prepareModel_1_3. Pamiętaj, że funkcja IDevice::prepareModelFromCache_1_3 domyślnie zawiera Priority w argumentach pamięci podręcznej.

W zależności od możliwości użytkownika i akceleratora istnieje wiele strategii pomagania w realizacji priorytetów. Oto kilka strategii:

• W przypadku sterowników z wbudowaną obsługą priorytetów prześlij pole Priority bezpośrednio do akceleratora.
• Korzystaj z kolejki priorytetów dla poszczególnych aplikacji, aby obsługiwać różne priorytety, jeszcze zanim wykonanie dotrze do akceleratora.

• Wstrzymaj lub anuluj wykonywane modele o niskim priorytecie, aby zwolnić akcelerator do wykonywania 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życie punktów kontrolnych lub podmodeli w modelach przygotowanych z priorytetem może spowodować dodatkowy narzut, który nie występuje w przypadku modeli bez priorytetu w wersjach starszych niż NN HAL 1.3.

  • Aby zapewnić możliwość wywłaszczania, zachowaj kontekst wykonania, w tym kolejną operację lub podmodel do wykonania, a także wszystkie odpowiednie dane pośrednie operandu. Użyj tego kontekstu wykonania, aby wznowić wykonywanie w późniejszym czasie.
  • Pełna obsługa tymczasowego przerwania nie jest wymagana, więc kontekst wykonania nie musi być zachowywany. 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 za pomocą AID (Android UID). HIDL ma wbudowane mechanizmy, które pobierają identyfikator UID aplikacji wywołującej za pomocą metody ::android::hardware::IPCThreadState::getCallingUid. Ich listę znajdziesz na stronie 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. W przypadku kierowców, którzy potrafią oszacować, ile czasu zajmie wykonanie zadania, ten termin umożliwia kierowcy przerwanie zadania przed jego rozpoczęciem, jeśli kierowca uzna, że nie da się go ukończyć przed upływem wyznaczonego terminu. Podobnie termin ten pozwala kierowcy przerwać trwające zadanie, którego według szacunków nie zostanie ono wykonane przed wyznaczonym terminem. Argument dotyczący terminu nie zmusza kierowcy do przerwania zadania, jeśli zadanie nie zostanie wykonane w terminie lub minął termin. Argumentu terminu można użyć 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, w których jako argument podano terminy OptionalTimePoint, 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 w przypadku każdej z powyższych metod, zapoznaj się z przykładowym sterownikiem NNAPI dostępnym 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 usprawnia raportowanie błędów i umożliwia kierowcom lepsze informowanie o stanie oraz płynniejsze przywracanie działania aplikacji. Oto wartości kodów błędu w funkcji 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ń kierowcy, że zadanie nie zostanie ukończone w wyznaczonym terminie. Dwa kody błędów RESOURCE_EXHAUSTED mogą wskazywać, że zadanie nie zostało wykonane z powodu ograniczenia zasobów w sterowniku, na przykład gdy sterownik nie ma wystarczającej ilości pamięci, by wykonać wywołanie.

Wersja TRANSIENT obu błędów wskazuje, że problem jest tymczasowy i że przyszłe wywołania tego samego zadania mogą po krótkim opóźnieniu zostać zrealizowane. Ten kod błędu powinien być zwracany na przykład wtedy, gdy sterownik jest zajęty zadaniami, które wcześniej były długotrwałe lub wymagały dużych ilości zasobów, ale nowe zadanie zostałoby ukończone, jeśli sterownik nie był zajęty przez poprzednią pracę. 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

Jakość usługi jest testowana za pomocą testów NNAPI VTS (VtsHalNeuralnetworksV1_3Target). Obejmuje to zestaw testów do walidacji (TestGenerated/ValidationTest#Test/), w ramach których kierowca odrzuca nieprawidłowe priorytety, oraz zestaw testów o nazwie DeadlineTest (TestGenerated/DeadlineTest#Test/), który pozwala sprawdzić, czy kierowca prawidłowo dotrzymuje terminów.