Sterowniki interfejsu Neural Networks API

Ta strona zawiera omówienie sposobu implementacji interfejsu Neural Networks API (NNAPI) sterownika. Więcej informacji znajdziesz w dokumentacji definicji HAL. pliki w hardware/interfaces/neuralnetworks Przykładowa implementacja sterownika jest dostępna frameworks/ml/nn/driver/sample

Więcej informacji o interfejsie Neural Networks API znajdziesz tutaj Neural Networks API.

HAL sieci neuronowych

HAL (NN) sieci neuronowych definiuje abstrakcję różnych urządzeń, takie jak procesory graficzne (GPU) i procesory sygnału cyfrowego (DSP), związane z produktem (np. telefonem lub tabletem). Czynniki wpływające na te możliwości urządzenia muszą spełniać wymagania normy NN HAL. Interfejs jest określony w HAL pliki definicji w hardware/interfaces/neuralnetworks

Przedstawiono ogólny przepływ interfejsu między platformą a kierowcą. na ilustracji 1.

Przepływ sieci neuronowych

Rysunek 1. Przepływ sieci neuronowych

Inicjalizacja

Podczas inicjowania platforma wysyła do sterownika zapytanie o swoje możliwości za pomocą IDevice::getCapabilities_1_3 Struktura @1.3::Capabilities obejmuje wszystkie typy danych przedstawia wydajność bez odprężenia za pomocą wektora.

Aby określić sposób przydziału obliczeń do dostępnych urządzeń, wykorzystuje możliwości, aby zrozumieć, jak szybko i jaki jest zużycie energii wydajnie, aby każdy sterownik mógł wykonać zadanie. Aby podać te informacje, sterownik musi podać ustandaryzowane statystyki wydajności oparte na wykonaniu zadań referencyjnych.

Aby określić wartości, które kierowca zwraca w odpowiedzi IDevice::getCapabilities_1_3, użyj aplikacji do analizy porównawczej NNAPI, skuteczności dla poszczególnych typów danych. MobileNet w wersjach 1 i 2, asr_float, i tts_float zalecane są modele do pomiaru wydajności w architekturze 32-bitowej wartości zmiennoprzecinkowe oraz kwantyzowane modele MobileNet v1 i v2 są zalecane dla 8-bitowych wartości kwantyzowanych. Więcej informacji: Android Machine Learning Test Suite.

W Androidzie 9 i starszych wersjach struktura Capabilities uwzględnia wydajność sterownika tylko dla tensorów zmiennoprzecinkowych i kwantowych i nie uwzględnia skalarne typy danych.

W ramach procesu inicjowania platforma może wysyłać zapytania o więcej informacji, za pomocą IDevice::getType, IDevice::getVersionString, IDevice:getSupportedExtensions oraz IDevice::getNumberOfCacheFilesNeeded.

Po ponownym uruchomieniu usługi platforma oczekuje wszystkich zapytań opisanych w tym aby zawsze raportować te same wartości dla danego kierowcy. W przeciwnym razie aplikacja korzystanie z tego sterownika może wykazywać zmniejszoną wydajność lub nieprawidłowe działanie.

Kompilacja

Określa ona, z których urządzeń należy korzystać po otrzymaniu żądania z . W Androidzie 10 aplikacje mogą wykrywać i określ urządzenia, wybrane dla platformy. Więcej informacji: Wykrywanie i przypisywanie urządzeń.

W czasie kompilacji modelu platforma wysyła model do każdego kandydata kierowcy, dzwoniąc IDevice::getSupportedOperations_1_3 Każdy sterownik zwraca tablicę wartości logicznych wskazujących, obsługiwane operacje modelu. Kierowca może stwierdzić, że nie może obsługuje daną operację z różnych powodów. Na przykład:

  • Sterownik nie obsługuje tego typu danych.
  • Sterownik obsługuje tylko operacje o określonych parametrach wejściowych. Dla: na przykład sterownik może obsługiwać splot 3x3 i 5x5, ale nie splot 7x7 operacji.
  • Sterownik ma ograniczenia pamięci, które uniemożliwiają mu obsługę dużych ilości wykresy i dane wejściowe.

Podczas kompilacji dane wejściowe, wyjściowe i wewnętrzne modelu, takie jak opisane w OperandLifeTime, mogą mieć nieznane wymiary lub pozycję w rankingu. Więcej informacji: Kształt wyjściowy.

Struktura instruuje każdego wybranego kierowcę, aby przygotować się do wykonania podzbioru model przez wywołanie IDevice::prepareModel_1_3 Każdy sterownik następnie kompiluje swój podzbiór. Kierowca może na przykład: wygenerować kod lub utworzyć nową kopię wag. Ponieważ ich obecność znaczący czas między kompilacją modelu a nie mogą wykonywać żądań, więc zasoby, takie jak duże kawałki pamięci urządzenia, nie powinny być przypisany podczas kompilacji.

Po udanym działaniu kierowca zwraca @1.3::IPreparedModel uchwytu. Jeśli sterownik zwróci kod błędu podczas przygotowywania swojego podzbioru platforma uruchamia na CPU cały model.

Aby skrócić czas potrzebny na kompilację danych przy uruchamianiu aplikacji, kierowca może artefaktów kompilacji pamięci podręcznej. Więcej informacji znajdziesz w artykule Kompilacja Buforowanie.

Realizacja

Gdy aplikacja prosi platformę o wykonanie żądania, platforma wywołuje IPreparedModel::executeSynchronously_1_3 Metoda HAL domyślnie wykonująca synchronicznie na gotowym modelu. Żądanie można też wykonać asynchronicznie za pomocą funkcji execute_1_3 metoda executeFenced (patrz Wykonywanie zabezpieczone), lub wykonane za pomocą wykonanie seryjne.

Synchroniczne wywołania wykonania zwiększają wydajność i zmniejszają liczbę wątków w porównaniu z wywołaniami asynchronicznymi, ponieważ kontrola jest zwracana proces tworzenia aplikacji dopiero po zakończeniu jej działania. Oznacza to, że nie potrzebuje osobnego mechanizmu do powiadomienia procesu aplikacji, wykonanie zapytania.

W przypadku asynchronicznej metody execute_1_3 element sterujący wraca do proces aplikacji po rozpoczęciu, a kierowca musi powiadomić o tym platformy po zakończeniu wykonywania, przy użyciu operatora @1.3::IExecutionCallback

Parametr Request przekazywany do metody wykonywania zawiera listę danych wejściowych i wyjściowych operandy użyte do wykonania. Pamięć, w której przechowywane są dane operandu, musi użyj kolejności wierszy dużych, przy czym pierwszy wymiar powtarza najwolniejszą i nie ma dopełnienie na końcu dowolnego wiersza. Aby uzyskać więcej informacji o typach operandów, zobacz Operacje.

W przypadku sterowników NN HAL 1.2 lub nowszych, gdy żądanie jest stan błędu, kształt wyniku są zwracane informacje o czasie. w zasadzie. Podczas wykonywania dane wyjściowe i wewnętrzne operandy modelu mogą mają co najmniej jeden nieznany rozmiar lub nieznaną pozycję w rankingu. Gdy co najmniej jeden wynik operand ma nieznany wymiar lub pozycję, sterownik musi zwrócić informacje wyjściowe o dynamicznie dobranych rozmiarach.

W przypadku sterowników z NN HAL 1.1 lub starszym zwracany jest tylko stan błędu w przypadku . Wymiary argumentów wejściowych i wyjściowych muszą być w pełni danych, których wykonanie ma zakończyć się pomyślnie. Wewnętrzne operandy mogą mają co najmniej jeden nieznany wymiar, ale muszą mieć określoną pozycję.

W przypadku żądań użytkowników, które obejmują wiele sterowników, platforma odpowiada za rezerwuje pamięć pośrednią i do sekwencjonowania wywołań każdego kierowcy.

W tym samym miejscu może być inicjowane równolegle wiele żądań @1.3::IPreparedModel Sterownik może wykonywać żądania równolegle lub zserializować wykonania.

Platforma może poprosić sterownika o zachowanie więcej niż 1 gotowego modelu. Dla: przykład, przygotowanie modelu m1, przygotowanie m2, wykonanie żądania r1 w: m1, wykonanie r2 w systemie m2, r3 na m1, r4 na m2, wersja (opisana w Czyszczenie) m1 i wersja m2.

Aby uniknąć powolnego, pierwszego wykonania, które mogłoby pogorszyć wrażenia użytkowników (na np. zacinanie się pierwszej klatki), sterownik powinien wykonywać większość zainicjowania w fazie kompilacji. Inicjacja przy pierwszym wykonaniu powinna być ograniczona do wczesnych działań negatywnie wpływających na stan systemu, takich jak: rezerwowanie dużych tymczasowych buforów lub zwiększanie częstotliwości zegara urządzenia. Sterowniki, które potrafią przygotować tylko ograniczoną liczbę równoczesnych modeli, mogą mieć przeprowadzić ich zainicjowanie przy pierwszym uruchomieniu.

Na Androidzie 10 lub nowszym, w przypadku uruchomienia z tym samym gotowym modelem są wykonywane w krótkich odstępach czasu, klient może zdecydować się na wykonanie obiekt burst do komunikacji między procesami aplikacji i sterownika. Więcej Więcej informacji zawiera Uruchomienia serii i kolejki szybkich wiadomości.

Aby w krótkich odstępach czasu poprawić wydajność wielu uruchomień, system może zachowywać tymczasowe bufory lub przyspieszać taktowanie. Tworzenie watchdoga Wątek jest zalecany w celu zwolnienia zasobów, jeśli po tym czasie nie zostaną utworzone żadne nowe żądania przez ustalony czas.

Kształt wyjściowy

W przypadku żądań, w których co najmniej 1 operand wyjściowy nie ma wszystkich wymiarów już określony, sterownik musi dostarczyć listę kształtów wyjściowych zawierających informacje o wymiarach każdego operandu wyjściowego po wykonaniu kodu. Więcej informacji na temat wymiarów, OutputShape

Jeśli wykonanie nie powiedzie się z powodu zbyt małego bufora wyjściowego, sterownik musi wskaż, które operandy wyjściowe mają niewystarczający rozmiar bufora na liście kształty wyjściowe i powinna podawać jak najwięcej informacji o wymiarach, używając 0 dla nieznanych wymiarów.

Czas

W Androidzie 10 aplikacja może prosić o wykonanie jeśli aplikacja wskazano jedno urządzenie, które ma być używane podczas procesu kompilacji. Dla: szczegóły, patrz MeasureTiming oraz Wykrywanie i przypisywanie urządzeń. W tym przypadku Sterownik NN HAL 1.2 musi zmierzyć czas wykonania lub zgłosić UINT64_MAX (do wskazują, że czas trwania jest niedostępny) podczas wykonywania żądania. Kierowca powinno zminimalizować wszelkie pogorszenie wydajności wynikające z pomiaru skuteczności czas trwania kampanii.

Sterownik zgłasza następujące czasy trwania w mikrosekundach w Timing struktura:

  • Czas wykonywania na urządzeniu: nie uwzględnia czasu wykonywania w sterownika, który działa na procesorze hosta.
  • Czas wykonywania w sterowniku: uwzględnia czas wykonywania na urządzeniu.

Okresy te muszą obejmować czas zawieszenia wykonania, przez np. gdy wykonanie zostało wywłaszczone przez inne zadania lub gdy oczekiwanie na dostępność zasobu.

Jeśli sterownik nie poproszono o zmierzenie czasu wykonywania lub kiedy wystąpi błąd wykonania, kierowca musi zgłaszać czasy trwania jako UINT64_MAX Nawet jeśli kierowca został poproszony o mierzenie wykonania kodu może zamiast tego podać wartość UINT64_MAX dla czasu na urządzeniu, godziny w lub oba te tryby. Gdy kierowca zgłasza oba czasy trwania jako wartość inną niż UINT64_MAX, czas wykonywania w sterowniku musi być równy lub dłuższy niż czas w urządzenia.

Zabezpieczona realizacja

W Androidzie 11 interfejs NNAPI umożliwia wykonaniom oczekiwanie na listę uchwytów sync_fence i opcjonalnie zwracanie obiektu sync_fence, który jest sygnalizowany po zakończeniu wykonywania kodu. Pozwala to zmniejszyć koszty ogólne w przypadku modeli sekwencji i przypadkach użycia strumieniowania. Pełna ochrona przed wdrożeniem pozwala też efektywne współdziałanie z innymi komponentami, które mogą sygnalizować lub oczekiwać sync_fence Więcej informacji na temat sync_fence: Platforma synchronizacji.

W ramach chroniona platforma wywołuje metodę IPreparedModel::executeFenced aby uruchomić ogrodzone, asynchroniczne wykonanie na gotowym modelu z wektor granic synchronizacji. Jeśli zadanie asynchroniczne zostało zakończone przed wywołanie zostanie zwrócone, dla sync_fence może zostać zwrócony pusty nick. An Aby umożliwić platformie, musisz też zwrócić obiekt IFencedExecutionCallback , aby uzyskać informacje o stanie błędu i czasie jego trwania.

Po zakończeniu wykonywania następujące 2 kolejne wartości czasu Można wykonywać zapytania dotyczące pomiaru czasu trwania wykonania IFencedExecutionCallback::getExecutionInfo.

  • timingLaunched: Czas od wywołania executeFenced do executeFenced wskazuje zwrócone syncFence.
  • timingFenced: Czas trwania odejścia wszystkich synchronizacji na które czeka wykonanie, są sygnalizowane sygnałem executeFenced zwróconego syncFence.

Sterowanie przepływem pracy

Na urządzeniach z Androidem 11 lub nowszym interfejs NNAPI obejmuje 2 operacje przepływu sterowania (IF i WHILE), które przyjmują inne modele jako argumenty i wykonywać je warunkowo (IF) lub wielokrotnie (WHILE). Dla: więcej informacji na temat jego wdrożenia można znaleźć w Kontroluj przepływ pracy.

Jakość usługi

W Androidzie 11 NNAPI zapewnia ulepszoną jakość usługi (QoS), umożliwiając aplikacji określenie względnych priorytetów jej maksymalnego czasu potrzebnego na przygotowanie modelu oraz maksymalny spodziewany czas zakończenia wykonania. Dla: więcej informacji znajdziesz w Jakość usługi.

Uporządkuj

Gdy aplikacja skończy z użyciem przygotowanego modelu, platforma zostanie udostępniona jego odniesienie do @1.3::IPreparedModel obiektu. Jeśli do obiektu IPreparedModel nie ma już odniesienia, automatycznie zniszczone w usłudze sterownika, która ją utworzyła. W zależności od modelu zasobów można odzyskać już w trakcie implementacji lub niszczyciela. Jeśli usługa sterownika wymaga, aby obiekt IPreparedModel był automatycznie zniszczone, gdy klient nie jest już potrzebny, nie może przechowywać wszystkie odwołania do obiektu IPreparedModel po obiekcie IPreparedeModel zostało zwrócone przez IPreparedModelCallback::notify_1_3.

Wykorzystanie procesora

Sterowniki powinny używać procesora do konfigurowania obliczeń. Kierowcy nie powinni i używa procesora do przeprowadzania obliczeń grafów, ponieważ zakłóca to działanie funkcji zdolność platformy do prawidłowego przydzielania pracy. Kierowca powinien zgłosić które nie są w stanie obsłużyć struktury, więc powinna ona obsługiwać odpoczynek.

Platforma zapewnia implementację procesora na potrzeby wszystkich operacji NNAPI z wyjątkiem operacji zdefiniowanych przez dostawcę. Więcej informacji: Vendor Extensions (Rozszerzenia dostawców).

operacje wprowadzone w Androidzie 10 (poziom API 29) masz tylko referencyjną implementację procesora, by sprawdzić, czy testy CTS i VTS są poprawne. Zoptymalizowane implementacje dostępne w mobilnych systemach uczących się platformy są preferowane zamiast implementacji CPU NNAPI.

Funkcje użytkowe

Baza kodu NNAPI zawiera funkcje użytkowe, których może używać sterownik usług Google.

frameworks/ml/nn/common/include/Utils.h który zawiera różnego rodzaju funkcje użytkowe, takie jak te służące do logowania do konwersji między różnymi wersjami NN HAL.

  • VLogging: VLOG to makro kodu otaczające tag LOG Androida, które rejestruje komunikat, jeśli w debug.nn.vlog jest ustawiony odpowiedni tag usłudze. initVLogMask() musi być wywoływany przed wywołaniem VLOG. Makro VLOG_IS_ON może być służy do sprawdzania, czy usługa VLOG jest obecnie włączona, co włącza skomplikowane logowanie do pominięcia, jeśli nie jest potrzebny. Wartość właściwości musi być jedną z tych wartości:

    • Pusty ciąg znaków wskazujący, że nie jest wymagane logowanie.
    • Token 1 lub all, który wskazuje, że logowanie jest wymagane.
    • Lista tagów rozdzielonych spacjami, przecinkami lub dwukropkami wskazujący, które logowanie należy przeprowadzić. Tagi: compilation, cpuexe, driver, execution, manager i model.

  • compliantWithV1_*: zwraca wartość true, jeśli można przekonwertować NN obiekt HAL na ten sam typ innej wersji HAL bez utraty informacji. Dla: na przykład wywołanie compliantWithV1_0 na V1_2::Model zwraca false, jeśli model zawiera typy operacji wprowadzone w NN HAL 1.1 lub NN HAL 1.2.

  • convertToV1_*: konwertuje obiekt NN HAL z jednej wersji na inną. Jeśli konwersja spowoduje utratę informacji (np. w sytuacji, gdy nowa wersja typu nie może w pełni przedstawiać wartości).

  • Uprawnienia: nonExtensionOperandPerformance i update można wykorzystać do stworzenia Capabilities::operandPerformance. .

  • Właściwości zapytań typów: isExtensionOperandType, isExtensionOperationType, nonExtensionSizeOfData nonExtensionOperandSizeOfData, nonExtensionOperandTypeIsScalar, tensorHasUnspecifiedDimensions.

frameworks/ml/nn/common/include/ValidateHal.h zawiera funkcje użytkowe do sprawdzania, czy obiekt NN HAL jest prawidłowy zgodnie ze specyfikacją jego wersji HAL.

  • validate*: zwraca wartość true, jeśli obiekt NN HAL jest prawidłowy zgodnie ze specyfikacją jego wersji HAL. Typy OEM i rozszerzenia nie są weryfikowane. Na przykład funkcja validateModel zwraca false, jeśli model zawiera operację odwołującą się do indeksu operandu, który nie lub operacja, która nie jest obsługiwana w danej wersji HAL.

frameworks/ml/nn/common/include/Tracing.h zawiera makra ułatwiające dodawanie systracing na kodzie sieci neuronowych. Przykład znajdziesz w wywołaniach makr NNTRACE_* w sekcji przykładowy sterownik.

frameworks/ml/nn/common/include/GraphDump.h zawiera funkcję narzędzia do zrzutu zawartości pliku Model w postaci graficznej do debugowania.

  • graphDump: zapisuje reprezentację modelu w Grafviz (.dot) do określonego strumienia (jeśli został podany) lub do logcat (jeśli został podany) strumień nie jest dostępny).

Weryfikacja

Aby przetestować implementację NNAPI, użyj testów VTS i CTS zawartych w platformy Android. VTS ćwiczy kierowców bezpośrednio (bez ), natomiast zespół CTS wykorzystuje ją pośrednio. Te przetestować każdą metodę interfejsu API i sprawdzić, czy wszystkie operacje obsługiwane przez sterowniki działają poprawnie i podają wyniki spełniające wymagania dotyczące dokładności.

Wymagania dotyczące dokładności w przypadku CTS i VTS dla NNAPI są następujące:

  • Liczba zmiennoprzecinkowa: abs(oczekiwane – rzeczywiste) <= atol + rtol * abs(expected); gdzie:

    • W przypadku fp32, atol = 1e-5f, rtol = 5.0f * 1.1920928955078125e-7
    • W przypadku FP16 atol = rtol = 5.0f * 0,0009765625f

  • Poddane kwantyzacji: pojedynczo (z wyjątkiem mobilenet_quantized, (czyli od trzech).

  • Wartość logiczna: dopasowanie ścisłe.

Jednym ze sposobów testowania NNAPI przez CTS jest generowanie stałych pseudorandomowych grafów wykorzystane do testowania i porównania wyników każdego sterownika z wynikami Implementacja referencji NNAPI. W przypadku sterowników z NN HAL 1.2 lub nowszym, jeśli które nie spełniają kryteriów dokładności, narzędzie do analizy zagrożeń zgłasza błąd i zrzuca specyfikacji modelu z błędem w pakiecie /data/local/tmp do debugowania. Więcej informacji o kryteriach dokładności znajdziesz tutaj TestRandomGraph.cpp oraz TestHarness.h

Testowanie rozmycia

Celem testów wymazywania jest wykrywanie awarii, asercji, naruszeń pamięci lub ogólne niezdefiniowane zachowanie w testowanym kodzie z powodu takich czynników jak nieoczekiwane dane wejściowe. Do testowania rozmycia NNAPI Android używa testów na podstawie libFuzzer, które są są skuteczne w rozmywaniu, ponieważ korzystają z zasięgu linii z poprzednich przypadków testowych, i generować nowe losowe dane wejściowe. Na przykład libFuzzer faworyzuje przypadki testowe w nowych wierszach kodu. To znacznie skraca czas potrzebny na znalezienie odpowiedzi problematyczny kod.

Aby przeprowadzić test pobieżny w celu zweryfikowania implementacji sterownika, zmodyfikuj frameworks/ml/nn/runtime/test/android_fuzzing/DriverFuzzTest.cpp w narzędziu testowym libneuralnetworks_driver_fuzzer dostępnym w AOSP, aby uwzględnić kod sterownika. Więcej informacji o testowaniu rozmycia NNAPI znajdziesz tutaj: frameworks/ml/nn/runtime/test/android_fuzzing/README.md

Bezpieczeństwo

Procesy aplikacji komunikują się bezpośrednio z procesem kierowcy, kierowcy muszą potwierdzić argumenty otrzymywanych wywołań. Ta weryfikacja jest weryfikowana przez VTS. Kod weryfikacyjny znajduje się w frameworks/ml/nn/common/include/ValidateHal.h

Kierowcy powinni też upewnić się, że aplikacje nie mogą zakłócać działania innych podczas korzystania z tego samego urządzenia.

Android Machine Learning Test Suite

Android Machine Learning Test Suite (MLTS) to test porównawczy NNAPI, który obejmuje CTS i VTS do weryfikowania dokładności rzeczywistych modeli na urządzeniach dostawców. ocenia czas oczekiwania i dokładność oraz porównuje wyników z wyniki za pomocą funkcji TF Lite działający na CPU, dla tych samych modeli i zbiorów danych. Dzięki temu dokładność kierowcy nie będzie jest gorsza niż w przypadku odniesień do procesora.

Deweloperzy platform Android używają również MLTS do oceny czasu oczekiwania i dokładności kierowców.

Test porównawczy NNAPI można znaleźć w 2 projektach w AOSP:

Modele i zbiory danych

Test porównawczy NNAPI wykorzystuje poniższe modele i zbiory danych.

  • Obiekty zmiennoprzecinkowe MobileNetV1 i u8 poddane kwantyzacji w różnych rozmiarach, są uruchamiane mały podzbiór (1500 obrazów) zbioru danych Open Images Dataset w wersji 4.
  • Obiekty zmiennoprzecinkowe MobileNetV2 i u8 poddane kwantyzacji w różnych rozmiarach, są uruchamiane mały podzbiór (1500 obrazów) zbioru danych Open Images Dataset w wersji 4.
  • Model akustyczny oparty na pamięci krótkotrwałej (LSTM) do zamiany tekstu na mowę jest przeprowadzana z niewielkim podzbiorem zbioru arktycznego CMU.
  • Oparty na LSTM model akustyczny do automatycznego rozpoznawania mowy, uruchamiany przed tylko niewielki podzbiór zbioru danych LibriSpeech.

Więcej informacji: platform/test/mlts/models

Testy stresu

Android Machine Learning Test Suite obejmuje serię testów po awarii, w celu sprawdzenia odporności kierowców w trudnych warunkach użytkowania lub w narożnych przypadków zachowanie użytkownika.

Wszystkie testy awarii obejmują te funkcje:

  • Wykrywanie zawieszenia: jeśli klient NNAPI zawiesi się podczas testu, test zakończony niepowodzeniem z powodu błędu HANG i zestawu testów przechodzi do następnego testu.
  • Wykrywanie awarii klienta NNAPI: testy eliminują awarie i testy klienta. niepowodzenie z powodu błędu: CRASH.
  • Wykrywanie wypadków kierowcy: testy wykrywają wypadek kierowcy. który powoduje niepowodzenie w wywołaniu NNAPI. Pamiętaj, że mogą wystąpić awarie w procesów sterownika, które nie powodują awarii NNAPI i nie powodują testu; niepowodzenie. Aby obsłużyć tego rodzaju awarie, zalecamy uruchomienie tail w dzienniku systemowym pod kątem błędów lub awarii sterowników.
  • Kierowanie wszystkich dostępnych akceleratorów: testy są przeprowadzane pod kątem wszystkich dostępnych akceleratorów. dostępnych sterowników.

Wszystkie testy awarii mogą mieć 4 możliwe wyniki:

  • SUCCESS: wykonanie zostało ukończone bez błędu.
  • FAILURE: nie udało się wykonać. Zwykle jest to spowodowane awarią urządzenia podczas testowanie modelu, co wskazuje, że sterownika nie skompilował lub nie wykonał żadnego działania w modelu.
  • HANG: proces testowy nie odpowiada.
  • CRASH: proces testowy uległ awarii.

Więcej informacji o testach stresu i pełnej liście takich testów znajdziesz na stronie platform/test/mlts/benchmark/README.txt

Korzystanie z MLTS

Aby korzystać z MLTS:

  1. Podłącz urządzenie docelowe do stacji roboczej i sprawdź, czy jest osiągalne przez adb. Eksportowanie urządzenia docelowego ANDROID_SERIAL zmienną środowiskową, jeśli jest podłączone więcej niż jedno urządzenie.

  2. cd do katalogu źródłowego najwyższego poziomu Androida.

    source build/envsetup.sh
lunch aosp_arm-userdebug # Or aosp_arm64-userdebug if available.
./test/mlts/benchmark/build_and_run_benchmark.sh

    Na koniec testu porównawczego wyniki są wyświetlane w postaci strony HTML i przekazano do xdg-open.

Więcej informacji: platform/test/mlts/benchmark/README.txt

Wersje HAL Neural Networks

W tej sekcji opisano zmiany wprowadzone w Androidzie i w funkcjach Neural Wersje HAL sieci.

Android 11

Android 11 wprowadza NN HAL 1.3, po wprowadzeniu istotnych zmian.

  • Obsługa kwantyzacji ze znakiem 8-bitowego w NNAPI. Dodaje parametr TENSOR_QUANT8_ASYMM_SIGNED typu operandu. Sterowniki z NN HAL 1.3, które obsługują operacje z kwantyzacją bez podpisu muszą też obsługiwać podpisane warianty tych działań. Podczas korzystania z podpisanych i niepodpisanych wersji większości operacji kwantowych, sterowniki muszą zapewniać te same wyniki do przesunięcie 128. Istnieje pięć wyjątków od tego wymogu: CAST, HASHTABLE_LOOKUP, LSH_PROJECTION, PAD_V2 i QUANTIZED_16BIT_LSTM. Operacja QUANTIZED_16BIT_LSTM nie obsługuje podpisanych operandów i pozostałe 4 operacje obsługują kwantyzację z podpisem, ale nie wymagają aby wyniki były takie same.
  • Obsługa blokowanych wykonań, w których platforma wywołuje metodę IPreparedModel::executeFenced aby uruchomić ogrodzone, asynchroniczne wykonanie na gotowym modelu z wektor granic synchronizacji. Więcej informacji: Wykonywanie zabezpieczone.
  • Obsługa procesu sterowania. Dodaje operacje IF i WHILE, które wykonują inne modele jako argumenty i wykonuj je warunkowo (IF) lub (WHILE). Więcej informacji: Kontroluj przepływ pracy.
  • Poprawiona jakość obsługi (QoS), ponieważ aplikacje mogą określać względną wartość priorytety swoich modeli, maksymalny czas oczekiwany przez model do przygotowania modelu oraz maksymalny czas spodziewany dla do wykonania. Więcej informacji: Jakość usługi.
  • Obsługa domen pamięci, które udostępniają interfejsy alokatora dla w buforach zarządzanych przez sterownika. Umożliwia to przekazywanie natywnych pamięci urządzenia między uruchomieniami, eliminując niepotrzebne kopiowanie i przekształcanie danych między kolejnymi uruchomieniami na tym samym sterowniku. Aby dowiedzieć się więcej, zobacz Domeny pamięci.

Android 10

Android 10 wprowadza NN HAL 1.2, po wprowadzeniu istotnych zmian.

  • Struktura Capabilities obejmuje wszystkie typy danych, w tym typy skalarne typów danych i przedstawia nierelaksowaną wydajność przy użyciu modelu wektorowego, niż w polach nazwanych.
  • Metody getVersionString i getType umożliwiają platformie pobrania informacji o typie urządzenia (DeviceType) i wersji. Zobacz Wykrywanie i przypisywanie urządzeń.
  • Metoda executeSynchronously jest domyślnie wywoływana, aby wykonać synchronicznie. Metoda execute_1_2 informuje platformę, asynchronicznie. Zobacz Wykonanie.
  • Parametr MeasureTiming do metod executeSynchronously, execute_1_2, i wykonanie burst określa, czy sterownik ma mierzyć wykonanie czas trwania kampanii. Wyniki są raportowane w strukturze Timing. Zobacz Czas.
  • Obsługa wykonań, w których co najmniej jeden operand wyjściowy ma nieznaną wartość wymiarów lub pozycji w rankingu. Zobacz Kształt wyjściowy.
  • Obsługa rozszerzeń dostawców, czyli kolekcji zdefiniowanych przez dostawcę operacji i typów danych. Sterownik zgłasza obsługiwane rozszerzenia przez metodę IDevice::getSupportedExtensions. Zobacz Vendor Extensions (Rozszerzenia dostawców).
  • Możliwość sterowania zestawem wykonań burst przez obiekt burst przy użyciu szybkie kolejki komunikatów (FMQ) do komunikacji między aplikacją a kierowcą i zmniejsza czas oczekiwania. Zobacz Uruchomienia serii i kolejki szybkich wiadomości.
  • Obsługa AHardwareBuffer, która umożliwia sterownikowi wykonywanie wykonań bez kopiowania danych. Zobacz AHardwareBuffer –
  • Ulepszona obsługa buforowania artefaktów kompilacji w celu skrócenia czasu. używany do kompilacji przy uruchamianiu aplikacji. Zobacz Buforowanie kompilacji.

Android 10 wprowadza poniższe typy operandów i operacji.

  • Typy argumentów

    • ANEURALNETWORKS_BOOL
    • ANEURALNETWORKS_FLOAT16
    • ANEURALNETWORKS_TENSOR_BOOL8
    • ANEURALNETWORKS_TENSOR_FLOAT16
    • ANEURALNETWORKS_TENSOR_QUANT16_ASYMM
    • ANEURALNETWORKS_TENSOR_QUANT16_SYMM
    • ANEURALNETWORKS_TENSOR_QUANT8_SYMM
    • ANEURALNETWORKS_TENSOR_QUANT8_SYMM_PER_CHANNEL

  • Operacje

    • ANEURALNETWORKS_ABS
    • ANEURALNETWORKS_ARGMAX
    • ANEURALNETWORKS_ARGMIN
    • ANEURALNETWORKS_AXIS_ALIGNED_BBOX_TRANSFORM
    • ANEURALNETWORKS_BIDIRECTIONAL_SEQUENCE_LSTM
    • ANEURALNETWORKS_BIDIRECTIONAL_SEQUENCE_RNN
    • ANEURALNETWORKS_BOX_WITH_NMS_LIMIT
    • ANEURALNETWORKS_CAST
    • ANEURALNETWORKS_CHANNEL_SHUFFLE
    • ANEURALNETWORKS_DETECTION_POSTPROCESSING
    • ANEURALNETWORKS_EQUAL
    • ANEURALNETWORKS_EXP
    • ANEURALNETWORKS_EXPAND_DIMS
    • ANEURALNETWORKS_GATHER
    • ANEURALNETWORKS_GENERATE_PROPOSALS
    • ANEURALNETWORKS_GREATER
    • ANEURALNETWORKS_GREATER_EQUAL
    • ANEURALNETWORKS_GROUPED_CONV_2D
    • ANEURALNETWORKS_HEATMAP_MAX_KEYPOINT
    • ANEURALNETWORKS_INSTANCE_NORMALIZATION
    • ANEURALNETWORKS_LESS
    • ANEURALNETWORKS_LESS_EQUAL
    • ANEURALNETWORKS_LOG
    • ANEURALNETWORKS_LOGICAL_AND
    • ANEURALNETWORKS_LOGICAL_NOT
    • ANEURALNETWORKS_LOGICAL_OR
    • ANEURALNETWORKS_LOG_SOFTMAX
    • ANEURALNETWORKS_MAXIMUM
    • ANEURALNETWORKS_MINIMUM
    • ANEURALNETWORKS_NEG
    • ANEURALNETWORKS_NOT_EQUAL
    • ANEURALNETWORKS_PAD_V2
    • ANEURALNETWORKS_POW
    • ANEURALNETWORKS_PRELU
    • ANEURALNETWORKS_QUANTIZE
    • ANEURALNETWORKS_QUANTIZED_16BIT_LSTM
    • ANEURALNETWORKS_RANDOM_MULTINOMIAL
    • ANEURALNETWORKS_REDUCE_ALL
    • ANEURALNETWORKS_REDUCE_ANY
    • ANEURALNETWORKS_REDUCE_MAX
    • ANEURALNETWORKS_REDUCE_MIN
    • ANEURALNETWORKS_REDUCE_PROD
    • ANEURALNETWORKS_REDUCE_SUM
    • ANEURALNETWORKS_RESIZE_NEAREST_NEIGHBOR
    • ANEURALNETWORKS_ROI_ALIGN
    • ANEURALNETWORKS_ROI_POOLING
    • ANEURALNETWORKS_RSQRT
    • ANEURALNETWORKS_SELECT
    • ANEURALNETWORKS_SIN
    • ANEURALNETWORKS_SLICE
    • ANEURALNETWORKS_SPLIT
    • ANEURALNETWORKS_SQRT
    • ANEURALNETWORKS_TILE
    • ANEURALNETWORKS_TOPK_V2
    • ANEURALNETWORKS_TRANSPOSE_CONV_2D
    • ANEURALNETWORKS_UNIDIRECTIONAL_SEQUENCE_LSTM
    • ANEURALNETWORKS_UNIDIRECTIONAL_SEQUENCE_RNN

Android 10 wprowadza aktualizacje do wielu operacji. Aktualizacje są głównie z następujących powodów:

  • Obsługa układu pamięci NCHW
  • Obsługa tensorów o rankingu innej niż 4 w softmax i operacje normalizacji
  • Obsługa splotów rozszerzonych
  • Obsługa danych wejściowych z kwantyzacją mieszaną w ANEURALNETWORKS_CONCATENATION

Poniższa lista przedstawia operacje zmodyfikowane w Android 10. Pełny Więcej informacji na ten temat można znaleźć Kod operacji w dokumentacji referencyjnej NNAPI.

  • ANEURALNETWORKS_ADD
  • ANEURALNETWORKS_AVERAGE_POOL_2D
  • ANEURALNETWORKS_BATCH_TO_SPACE_ND
  • ANEURALNETWORKS_CONCATENATION
  • ANEURALNETWORKS_CONV_2D
  • ANEURALNETWORKS_DEPTHWISE_CONV_2D
  • ANEURALNETWORKS_DEPTH_TO_SPACE
  • ANEURALNETWORKS_DEQUANTIZE
  • ANEURALNETWORKS_DIV
  • ANEURALNETWORKS_FLOOR
  • ANEURALNETWORKS_FULLY_CONNECTED
  • ANEURALNETWORKS_L2_NORMALIZATION
  • ANEURALNETWORKS_L2_POOL_2D
  • ANEURALNETWORKS_LOCAL_RESPONSE_NORMALIZATION
  • ANEURALNETWORKS_LOGISTIC
  • ANEURALNETWORKS_LSH_PROJECTION
  • ANEURALNETWORKS_LSTM
  • ANEURALNETWORKS_MAX_POOL_2D
  • ANEURALNETWORKS_MEAN
  • ANEURALNETWORKS_MUL
  • ANEURALNETWORKS_PAD
  • ANEURALNETWORKS_RELU
  • ANEURALNETWORKS_RELU1
  • ANEURALNETWORKS_RELU6
  • ANEURALNETWORKS_RESHAPE
  • ANEURALNETWORKS_RESIZE_BILINEAR
  • ANEURALNETWORKS_RNN
  • ANEURALNETWORKS_ROI_ALIGN
  • ANEURALNETWORKS_SOFTMAX
  • ANEURALNETWORKS_SPACE_TO_BATCH_ND
  • ANEURALNETWORKS_SPACE_TO_DEPTH
  • ANEURALNETWORKS_SQUEEZE
  • ANEURALNETWORKS_STRIDED_SLICE
  • ANEURALNETWORKS_SUB
  • ANEURALNETWORKS_SVDF
  • ANEURALNETWORKS_TANH
  • ANEURALNETWORKS_TRANSPOSE

Android 9

Wersja NN HAL 1.1 została wprowadzona w Androidzie 9 i zawiera następujące ważne elementy: zmian.

  • IDevice::prepareModel_1_1 obejmuje: ExecutionPreference . Kierowca może wykorzystać tę informację, aby odpowiednio przygotować się do pracy, aplikacja preferuje oszczędzanie baterii lub ma uruchamiać model w szybkich, kolejnych rozmowach.
  • Dodano 9 nowych operacji: BATCH_TO_SPACE_ND, DIV, MEAN, PAD, SPACE_TO_BATCH_ND, SQUEEZE, STRIDED_SLICE, SUB, TRANSPOSE.
  • Aplikacja może określić, że 32-bitowe obliczenia zmiennoprzecinkowe mogą być uruchamiane z użyciem 16-bitowego zakresu zmiennoprzecinkowego lub precyzji, ustawiając Model.relaxComputationFloat32toFloat16 do true. Capabilities struct ma dodatkowe pole relaxedFloat32toFloat16Performance, więc że kierowca może raportować swoje zrelaksowane działanie w ramach platformy.

Android 8.1

Pierwsza wersja HAL Neural Networks (1.0) została opublikowana w Androidzie 8.1. Więcej Więcej informacji zawiera /neuralnetworks/1.0/