Interfejsy API do zarządzania buforem HAL3 kamery

Android 10 wprowadza opcjonalne zmiany bufor HAL3 kamery za pomocą których wdrożenia logiki zarządzania buforem w celu uzyskania różnych ilości pamięci i przechwytywania kompromisów czasu oczekiwania w implementacjach HAL kamery.

HAL aparatu wymaga N żądań (gdzie N jest równe głębokość potoku) znajduje się w kolejce w potoku, ale często nie wymaga wszystkich N zbiorów buforowane w tym samym czasie.

Na przykład HAL może mieć w kolejce 8 żądań w potoku, wymaga buforów danych wyjściowych tylko dla dwóch żądań na ostatnich etapach ścieżki potoku. Na urządzeniach z Androidem 9 lub starszym system aparatów przypisuje buforuje, gdy żądanie zostanie umieszczone w kolejce w HAL, może więc być 6 zbiorów nieużywane bufory w HAL. W Androidzie 10 interfejsy API do zarządzania buforem HAL3 aparatu pozwalają na odłączenie danych wyjściowych aby zwolnić 6 zestawów buforów. Może to doprowadzić do oszczędność pamięci w megabajtach na zaawansowane urządzenia zaawansowane i może być korzystna również urządzeń z małą ilością pamięci.

Ilustracja 1 przedstawia schemat interfejsu HAL aparatu na uruchomionych urządzeniach Android 9 i starsze wersje. Rysunek 2. przedstawia interfejs HAL aparatu na Androidzie 10 z interfejsów API do zarządzania buforem HAL3 aparatu.

Zarządzanie buforami w 9 lub niższych

Rysunek 1. Interfejs HAL aparatu na Androidzie 9 i starszych

Zarządzanie buforami w Androidzie 10

Rysunek 2. Interfejs HAL aparatu na Androidzie 10 korzystający z interfejsów API do zarządzania buforem

Wdróż interfejsy API do zarządzania buforem

Aby można było wdrożyć interfejsy API do zarządzania buforem, interfejs HAL aparatu musi:

HAL aparatu używa requestStreamBuffers oraz returnStreamBuffers metod w zakresie ICameraDeviceCallback.hal żądania i zwracania buforów. HAL musi również implementować signalStreamFlush Metoda w ICameraDeviceSession.hal sygnalizuje, że HAL kamery zwraca bufory.

requestStreamBuffers

Użyj requestStreamBuffers żądania buforów z platformy kamery. Podczas korzystania z HAL3 aparatu do zarządzania buforem, żądania przechwytywania z platformy aparatu zawiera bufory wyjściowe, czyli pole bufferId w StreamBuffer. jest 0. Dlatego HAL aparatu musi używać żądania requestStreamBuffers. i buforuje dane z platformy kamery.

Metoda requestStreamBuffers umożliwia elementowi wywołującemu żądanie wielu buforów z wielu strumieni wyjściowych w jednym wywołaniu, co pozwala obniżyć liczbę HIDL IPC połączeń. Realizacja połączenia trwa jednak dłużej, jeśli w żądaniu co może negatywnie wpłynąć na łączny czas oczekiwania na wynik żądania. Poza tym, ponieważ połączenia do requestStreamBuffers są serializowane w kamerze , zalecamy, aby HAL kamery używała dedykowanego obiektu o wysokim priorytecie żądania buforów w wątku.

Jeśli żądanie buforowania nie powiedzie się, HAL kamery musi prawidłowo obsługiwać niekrytycznych błędów. Na liście poniżej znajdziesz typowe przyczyny buforowania i sposobu ich obsługi przez HAL kamery.

  • Aplikacja odłącza się od strumienia wyjściowego: To jest błąd niekrytyczny. HAL aparatu powinien wysłać ERROR_REQUEST dla dowolnego żądania zapisu które są kierowane na odłączony strumień i mogą być gotowe do przetwarzania kolejnych żądań. w zwykły sposób.
  • Czas oczekiwania: może wystąpić, gdy aplikacja jest zajęta wykonywaniem działania. intensywnego przetwarzania z zachowaniem pewnych buforów. HAL aparatu powinien wyślij ERROR_REQUEST dla żądań przechwytywania, których nie można zrealizować z powodu w wyniku przekroczenia limitu czasu i być gotowym do normalnego przetwarzania kolejnych żądań.
  • Platforma kamery przygotowuje nową konfigurację transmisji: HAL aparatu musi poczekać do następnego configureStreams. przed ponownym nawiązaniem połączenia z numerem requestStreamBuffers zostało zakończone.
  • HAL aparatu osiągnęła poziom limit bufora (pole maxBuffers): HAL aparatu powinien poczekać dopóki nie zwróci co najmniej 1 bufora strumienia przed wywołaniem requestStreamBuffers jeszcze raz.

ReturnStreamBuffers:

Użyj returnStreamBuffers która zwraca dodatkowe bufory do szkieletu kamery. HAL aparatu normalnie zwraca bufory do szkieletu kamery przez funkcję processCaptureResult , ale może uwzględniać tylko żądania przechwytywania, które zostały wysłane do HAL aparatu. Dzięki metodzie requestStreamBuffers możliwe jest, implementacja HAL aparatu, aby zatrzymać więcej buforów niż wymagana przez i konstrukcji kamery. W tym przypadku metoda returnStreamBuffers powinna być . Jeśli implementacja HAL nigdy nie przechowuje więcej buforów niż wymagana, funkcja Implementacja HAL kamery nie musi wywoływać interfejsu returnStreamBuffers .

sygnałStreamFlush

signalStreamFlush jest wywoływana przez platformę kamery w celu powiadomienia HAL kamery o konieczności zwrócenia i bufory. Ta funkcja jest zwykle wywoływana, gdy struktura kamery ma zostać zadzwoń configureStreams i musi opróżniać potok kamery. Podobne do returnStreamBuffers jeśli implementacja HAL aparatu nie przechowuje więcej buforów niż może istnieć pusta implementacja tej metody.

Po wywołaniu funkcji kamery signalStreamFlush platforma przestanie wysyłać nowe żądania przechwytywania do HAL kamery do momentu, do platformy kamery zostały zwrócone bufory. Gdy wszystkie bufory są , wywołania metody requestStreamBuffers kończą się niepowodzeniem, a kamera pozwala na kontynuowanie pracy w stanie nienaruszonym. Struktura kamery wywołuje configureStreams lub processCaptureRequest . Jeśli platforma kamery wywołuje metodę configureStreams, kamera HAL może ponownie zacząć żądać buforów po zwróceniu wywołania configureStreams . Jeśli platforma kamery wywołuje metodę processCaptureRequest, HAL kamery może zacząć żądać buforów w czasie processCaptureRequest .

Metody signalStreamFlush mają różne właściwości semantyczne flush. . Po wywołaniu metody flush HAL może przerwać przechwytywanie oczekujące na zatwierdzenie żądania z ERROR_REQUEST. tak aby jak najszybciej opróżnić potok. Kiedy gdy wywoływana jest metoda signalStreamFlush, HAL musi zakończyć wszystkie oczekujące żądania przechwytywania żądań w zwykły sposób i zwracają wszystkie bufory do platformy kamery.

Kolejną różnicą między metodą signalStreamFlush a innymi jest że signalStreamFlush jest metodą jednokierunkowej HIDL, co oznacza, że kamera platforma może wywołać inne interfejsy API blokujące, zanim HAL otrzyma signalStreamFlush połączenie. Oznacza to, że signalStreamFlush i inne metody (w szczególności configureStreams) może dotrzeć do HAL aparatu w innej kolejności niż w kolejności ich wywołania w ramach kamery. Aby rozwiązać ten problem problem asynchroniczny, pole streamConfigCounter zostało dodane do StreamConfiguration i dodano jako argument do tabeli signalStreamFlush . Implementacja HAL aparatu powinna korzystać z interfejsu streamConfigCounter argumentu w celu określenia, czy wywołanie signalStreamFlush pochodzi później niż jego odpowiadające odpowiedniemu wywołaniu configureStreams. Przykład znajdziesz na rys. 3.

Obsługa połączeń przychodzących z opóźnieniem

Rysunek 3. Jak HAL kamery powinna wykrywać i przetwarzać wywołania SignalsStreamFlush, które docierają spóźnione

Zmiany w działaniu po wdrożeniu interfejsów API do zarządzania buforem

Jeśli korzystasz z interfejsów API do zarządzania buforem, żeby wdrożyć logikę zarządzania buforem, rozważ następujące możliwe zmiany w działaniu kamery i implementacja HAL aparatu:

  • Żądania przechwytywania są szybsze i szybsze do HAL kamery często: bez interfejsów API do zarządzania buforem platforma kamery wysyła żądania bufory wyjściowe dla każdego żądania przechwytywania przed wysłaniem do HAL aparatu. Jeśli korzystasz z interfejsów API do zarządzania buforem, platforma kamery nie musi już czekać na bufory, więc może wysyłać żądania przechwytywania. do HAL aparatu.

    Bez interfejsów API do zarządzania buforem platforma kamery przestaje działać wysyłanie żądań przechwytywania, jeśli jeden ze strumieni wyjściowych przechwycenia żądania osiągnęło maksymalną liczbę buforów, jaką może przechowywać HAL jednorazowo (ta wartość jest wskazywana przez HAL aparatu w pole HalStream::maxBuffers w wartości zwracanej przez configureStreams. ). Dzięki interfejsom API do zarządzania buforem to ograniczanie nie działa już i implementacja HAL kamery nie może akceptować Funkcja processCaptureRequest wywołuje, gdy HAL ma zbyt wiele żądań przechwytywania dodano do kolejki.

  • Czas oczekiwania na połączenie z usługą requestStreamBuffers znacznie się różni: z wielu powodów, dla których połączenie requestStreamBuffers może trwać dłużej niż średnią. Na przykład:

    • W przypadku kilku pierwszych buforów nowo utworzonego strumienia wywołanie funkcji może potrwać dłużej, ponieważ urządzenie musi przydzielać pamięć.
    • Spodziewany czas oczekiwania zwiększa się proporcjonalnie do liczby bufory żądanego przy każdym wywołaniu.
    • Aplikacja przechowuje bufory i przetwarza dane. Ten może spowolnić wykonywanie żądań bufora lub przekroczyć limit czasu z powodu z brakiem buforów lub zajętym procesorem.

Strategie zarządzania buforami

Interfejsy API do zarządzania buforem pozwalają na różne rodzaje zarządzania buforem do wdrożenia. Przykłady:

  • Zgodność wsteczna: żądania HAL buforują dla żądania przechwytywania. podczas rozmowy processCaptureRequest. Ta strategia nie zapewnia oszczędności pamięci, ale może służyć jako pierwsza implementacja bufora do zarządzania interfejsami API i wymagających niewielu zmian w kodzie dotychczasowej biblioteki HAL aparatu.
  • Maksymalna oszczędność pamięci: HAL aparatu żąda tylko buforów wyjściowych bezpośrednio przed koniecznością wypełnienia. Ta strategia umożliwia zmaksymalizowana oszczędność pamięci. Potencjalnie wadliwym rozwiązaniem jest większa liczba kamer. zacina się, gdy realizacja żądań bufora trwa zbyt długo.
  • Kopia: HAL aparatu zapisuje w pamięci podręcznej kilka buforów, by zmniejszyć prawdopodobieństwo może być kilka żądań powolnego buforowania.

HAL aparatu może przyjąć różne strategie w zależności od przypadku użycia: na przykład w przypadku zastosowania strategii maksymalizacji oszczędzania pamięci w przypadkach, pamięci i zastosowania w innych przypadkach użycia zgodności wstecznej.

Przykładowa implementacja w zewnętrznej części HAL aparatu

Interfejs HAL zewnętrznego aparatu został wprowadzony w Androidzie 9 i można go znaleźć w drzewo źródłowe w hardware/interfaces/camera/device/3.5/ W Androidzie 10 dodaliśmy ExternalCameraDeviceSession.cpp implementacją interfejsu API do zarządzania buforem. HAL tego aparatu zewnętrznego stosuje strategię maksymalizacji oszczędności pamięci opisaną w sekcji Zarządzanie buforami w kilkustu wierszach Kod w C++.