Skrypt renderowania

RenderScript to platforma do uruchamiania wymagających obliczeń zadania z dużą wydajnością na Androidzie. Przeznaczony do stosowania w ramach obliczeń równoległych, chociaż zadania szeregowe też mogą być korzystne. Środowisko wykonawcze RenderScript zapewnia równoległą pracę na różnych procesorach dostępnych na takich jak procesory wielordzeniowe i GPU, dzięki czemu deweloperzy mogą skupić się za pomocą algorytmów, a nie na planowania pracy. Skrypt RenderScript jest szczególnie ważny przydatne w aplikacjach do przetwarzania obrazu, fotografii i rozpoznawania obrazów.

Urządzenia z Androidem 8.0 lub nowszym używają tego skryptu RenderScript platformy i listy HAL dostawców:

Rysunek 1. Kod dostawcy zawierający link do wewnętrznych bibliotek.

Różnice w stosunku do metody RenderScript w Androidzie 7.x i starszych:

  • 2 wystąpienia wewnętrznych bibliotek RenderScript w procesie. Jeden zestaw dotyczy Ścieżka zastępcza procesora pochodzi bezpośrednio z /system/lib; drugi ustawiono dla ścieżki GPU i pochodzi z /system/lib/vndk-sp.
  • Wewnętrzne biblioteki RS w /system/lib są częścią i są aktualizowane wraz z uaktualnieniem usługi system.img. Jednak libs w /system/lib/vndk-sp są tworzone dla dostawcy i nie są aktualizowana po uaktualnieniu system.img (w czasie, gdy można je aktualizować dla poprawki zabezpieczeń, interfejs ABI pozostaje bez zmian).
  • Kod dostawcy (RS HAL, sterownik RS i bcc plugin) to: połączone z wewnętrznymi bibliotekami RenderScript na stronie /system/lib/vndk-sp Nie mogą tworzyć powiązań z bibliotekami w /system/lib, ponieważ biblioteki lib w tym katalogu są tworzone dla i z tego powodu mogą być niezgodne z kodem dostawcy (tj. symbolami mogą zostać usunięte). W przeciwnym razie nie byłoby możliwe wdrożenie OTA obejmujące tylko platformę.

Projektowanie

W poniższych sekcjach znajdziesz szczegółowe informacje o projekcie RenderScript w Androidzie 8.0 i nowszych.

Biblioteki RenderScript dostępne dla dostawców

Ta sekcja zawiera listę bibliotek RenderScript (używanych jako plik NDK dostawcy w przypadku Same-Process) HAL lub VNDK-SP) dostępne dla kodu dostawcy, które można połączyć przeciwko Google. Zawiera również szczegóły dodatkowych bibliotek, które nie są związane z RenderScript, ale są one też przekazywane kodowi dostawcy.

Ta lista bibliotek może się różnić w zależności od wersji Androida: jest niezmienna w przypadku konkretnej wersji Androida; aby poznać aktualną listę dostępnych bibliotek, sprawdź /system/etc/ld.config.txt.

Biblioteki RenderScript Biblioteki inne niż renderScript
  • android.hardware.graphics.renderscript@1.0.so
  • libRS_internal.so
  • libRSCpuRef.so
  • libblas.so
  • libbcinfo.so
  • libcompiler_rt.so
  • libRSDriver.so
  • libc.so
  • libm.so
  • libdl.so
  • libstdc++.so
  • liblog.so
  • libnativewindow.so
  • libsync.so
  • libvndksupport.so
  • libbase.so
  • libc++.so
  • libcutils.so
  • libutils.so
  • libhardware.so
  • libhidlbase.so
  • libhidltransport.so
  • libhwbinder.so
  • liblzma.so
  • libz.so
  • libEGL.so
  • libGLESv1_CM.so
  • libGLESv2.so

Konfiguracja przestrzeni nazw tagu łączącego

Ograniczenie łączenia, które uniemożliwia użycie bibliotek spoza VNDK-SP przez kod dostawcy jest wymuszany w czasie działania za pomocą przestrzeni nazw tagu łączącego. Aby dowiedzieć się więcej, zapoznaj się z dokumentem VNDK Design prezentacji).

na urządzeniu z Androidem 8.0 lub nowszym ze wszystkimi kodami HAL Same-Process (SP-HAL). oprócz RenderScriptu, które są ładowane w przestrzeni nazw kreatora linków sphal Skrypt RenderScript jest wczytywany do przestrzeń nazw rs, lokalizacja, która umożliwia nieco luźniejsze wymuszania na podstawie bibliotek RenderScript. Ponieważ implementacja RS musi się wczytać skompilowanego kodu bitowego, do ścieżki parametru /data/*/*.so Przestrzeń nazw rs (inne identyfikatory SP-HAL nie mogą ładować libs z biblioteki partycji danych).

Oprócz tego przestrzeń nazw rs zezwala na większą liczbę bibliotek, niż podano w przypadku przez inne przestrzenie nazw. libmediandk.so i libft2.so są dostępne w przestrzeni nazw rs, ponieważ Biblioteka libRS_internal.so jest związana z tymi bibliotekami wewnętrznie.

Rysunek 2. Konfiguracja przestrzeni nazw na potrzeby tagu łączącego.

Wczytaj sterowniki

Ścieżka kreacji zastępczej procesora

W zależności od istnienia RS_CONTEXT_LOW_LATENCY bitu podczas tworzenia kontekstu RS, wybierana jest ścieżka CPU lub GPU. Gdy Wybrana ścieżka procesora: libRS_internal.so (główna implementacja platformy RS) jest bezpośrednio blokowana z poziomu domyślnego tagu łączącego (dlopen). przestrzeń nazw, w której podana jest wersja platformy RS libs.

Implementacja RS HAL od dostawcy w ogóle nie jest używana, gdy procesor ścieżki zastępczej, i tworzony jest obiekt RsContext, wartość null mVendorDriverName. libRSDriver.so to (wg dlopened, a biblioteka sterownika jest wczytywana z biblioteki Przestrzeń nazw default, ponieważ element wywołujący (libRS_internal.so) jest również wczytywany w: default przestrzeni nazw.

Rysunek 3. Ścieżka zastępcza procesora.

Ścieżka GPU

W przypadku ścieżki GPU obiekt libRS_internal.so jest ładowany w inny sposób. Po pierwsze, libRS.so używa android.hardware.renderscript@1.0.so (i jej bazowa) libhidltransport.so), aby wczytać android.hardware.renderscript@1.0-impl.so (dostawca implementacji kodu RS HAL) w innej przestrzeni nazw tagu łączącego o nazwie sphal. Wspólnota HAL, a potem dlopen s libRS_internal.so w kolejnym przestrzeń nazw tagu łączącego o nazwie rs.

Dostawcy mogą dodać własnego sterownika RS, ustawiając flagę czasu kompilacji OVERRIDE_RS_DRIVER, który jest umieszczony w RS HAL wdrożenie (hardware/interfaces/renderscript/1.0/default/Context.cpp). Ten nazwa sterownika jest następnie poprzedzana dlopen w kontekście RS w ścieżce GPU.

Tworzenie obiektu RsContext jest delegowane do RS HAL implementacji. HAL wywołuje platformę RS za pomocą parametru rsContextCreateVendor() o nazwie sterownika do użyć jako argumentu. Platforma RS następnie wczytuje określony sterownik, gdy Zainicjowano RsContext. W tym przypadku biblioteka sterowników to wczytano do przestrzeni nazw rs, ponieważ RsContext obiekt jest tworzony w przestrzeni nazw rs, /vendor/lib wskazuje ścieżkę wyszukiwania przestrzeni nazw.

Rysunek 4. Ścieżka zastępcza GPU.

Podczas przechodzenia z przestrzeni nazw default do Przestrzeń nazw sphal, libhidltransport.so używa android_load_sphal_library() do jawnego uporządkowania argumentu dynamiczny tag łączący, aby wczytać bibliotekę -impl.so z tagu Przestrzeń nazw sphal.

Podczas przechodzenia z przestrzeni nazw sphal do rs; wczytywanie odbywa się pośrednio przez następujący wiersz w /system/etc/ld.config.txt: 

namespace.sphal.link.rs.shared_libs = libRS_internal.so

Ten wiersz określa, jak powinien wczytać dynamiczny tag łączący libRS_internal.so z przestrzeni nazw rs, gdy lib nie można znaleźć/wczytać z przestrzeni nazw sphal (która zawsze jest ten przypadek, bo przestrzeń nazw sphal nie przeszukuje /system/lib/vndk-sp, gdzie libRS_internal.so ). W przypadku tej konfiguracji proste wywołanie dlopen() Do przeprowadzenia przejścia w przestrzeni nazw wystarczy libRS_internal.so.

Wczytaj wtyczkę UDW

bcc plugin to biblioteka dostarczana przez dostawcę wczytana do Kompilator bcc. Ponieważ bcc jest procesem systemowym w /system/bin, biblioteka bcc plugin może być uznaje się za SP-HAL (tj. HAL dostawcy, który można bezpośrednio wczytać do proces systemu bez powiązania). Jako SP-HAL Biblioteka bcc-plugin:

  • Nie można połączyć z bibliotekami działającymi wyłącznie na platformie, takimi jak libLLVM.so
  • Można łączyć tylko z bibliotekami VNDK-SP dostępnymi dla dostawcy.

To ograniczenie jest egzekwowane przez wczytanie zasady bcc plugin w Przestrzeń nazw sphal korzystająca z parametru android_sphal_load_library(). W poprzednich wersjach na Androida nazwa wtyczki została określona za pomocą opcji -load i Biblioteka lib została wczytana za pomocą prostego polecenia dlopen() przez libLLVM.so W Androidzie 8.0 i nowszych jest to określone w -plugin, a biblioteka lib jest ładowana bezpośrednio przez bcc. Ta opcja umożliwia zastosowanie ścieżki niezwiązanej z Androidem projektu LLVM (open source).

Rysunek 5. Wczytuję wtyczkę UDW (Android 7.x lub starszy).



Rysunek 6. Wczytuję wtyczkę UDW (Android 8.0 lub nowszy).

Ścieżki wyszukiwania adresów ld.mc

Podczas wykonywania zadania ld.mc niektóre biblioteki środowiska wykonawczego RS są podawane jako dane wejściowe do tagu łączącego. Kod bitowy RS z aplikacji jest połączony z bibliotekami środowiska wykonawczego a gdy przekonwertowany kod bitowy jest wczytywany do procesu aplikacji, biblioteka środowiska wykonawczego są ponownie dynamicznie łączone z przekonwertowanego kodu bitowego.

Biblioteki środowiska wykonawczego obejmują:

  • libcompiler_rt.so
  • libm.so
  • libc.so
  • Kierowca RS (libRSDriver.so lub OVERRIDE_RS_DRIVER).

Podczas wczytywania skompilowanego kodu bitowego do procesu aplikacji podaj dokładnie taki sam kod z biblioteki używanej przez usługę ld.mc. W przeciwnym razie skompilowany kod bitowy może nie znaleźć symbolu, który był dostępny podczas łączenia.

Platforma RS używa do tego różnych ścieżek wyszukiwania w bibliotece środowiska wykonawczego, gdy wykonując zadanie ld.mc, w zależności od tego, czy sama platforma RS jest wczytano z /system/lib lub /system/lib/vndk-sp. Można to określić, odczytując adres dowolnego symbolu RS Framework lib i używaniem dladdr() do zmapowania ścieżki pliku adres.

Zasada SELinux

W związku ze zmianami zasad SELinux w Androidzie 8.0 i nowszych musisz postępuj zgodnie z określonymi regułami (egzekwowanymi przez neverallows), gdy oznaczanie dodatkowych plików etykietami w partycji vendor:

  • vendor_file musi być etykietą domyślną dla wszystkich plików w vendor partycja. Zasady platformy wymagają tego, aby mieć dostęp przekazujących implementacji HAL.
  • Wszystkie nowe exec_types zostały dodane w partycji vendor za pośrednictwem SEPolicy dostawcy musi mieć atrybut vendor_file_type. Jest to wymuszane przez neverallows.
  • Aby uniknąć konfliktów z przyszłymi aktualizacjami platformy lub platformy, unikaj oznaczania etykietami pliki inne niż exec_types w partycji vendor.
  • Wszystkie zależności bibliotek w przypadku kluczy HAL z tym samym procesem zidentyfikowanym przez AOSP muszą być oznaczony jako same_process_hal_file.

Szczegółowe informacje na temat zasad SELinux znajdziesz w sekcji Ulepszone zabezpieczenia w systemie Linux

Zgodność z interfejsem ABI w przypadku kodu bitowego

Jeśli nie zostaną dodane żadne nowe interfejsy API, co oznacza, że nie będzie aktualizacji wersji HAL, platformy RS będzie nadal korzystać z dotychczasowego sterownika GPU (HAL 1.0).

W przypadku niewielkich zmian HAL (HAL 1.1), które nie mają wpływu na kod bitowy, platforma powinna w przypadku tych nowo dodanych interfejsów API przełącz się na procesor graficzny (HAL 1.0) i nadal używaj sterownika GPU (HAL 1.0) w innym miejscu.

W przypadku większych zmian HAL (HAL 2.0) wpływających na kompilację/łączenie kodów bitowych, RS platformy powinny nie wczytywać sterowników GPU udostępnionych przez dostawcę, użyj procesora lub ścieżki Vulkan do przyspieszania działania.

Przetwarzanie kodu bitowego RenderScript odbywa się w 3 etapach:

Etap Szczegóły
Kompilowanie
  • Wejściowy kod bitowy (.bc) dla funkcji bcc musi być w formacie Format kodu bitowego LLVM 3.2, a bcc musi być wsteczny zgodne z dotychczasowymi (starszymi) aplikacjami.
  • Metadane w pliku .bc mogą się jednak zmienić (istnieje nowe środowisko wykonawcze, funkcji, np. Zestawy ustalające alokacji ∓ getry, funkcje matematyczne itp.). Część funkcji środowiska wykonawczego znajduje się w libclcore.bc, a częściowo z nich znajduje się w narzędziu LibRSDriver lub jego odpowiedniku od dostawcy.
  • Nowe funkcje środowiska wykonawczego lub niezgodność zmian metadanych wymagają zwiększania na poziomie interfejsu API kodu bitowego. Sterowniki dostawców nie mogą ich wykorzystać, wersji HAL również należy zwiększyć.
  • Dostawcy mogą mieć własne kompilatory, ale wnioski/wymagania dla bcc mają zastosowanie również do tych kompilatorów.
Link
  • Skompilowany plik .o zostanie połączony ze sterownikiem dostawcy, np. libRSDriver_foo.so i libcompiler_rt.so. Procesor ścieżka będzie łączyć się z libRSDriver.so.
  • Jeśli domena .o wymaga nowego interfejsu API środowiska wykonawczego z libRSDriver_foo, sterownik dostawcy wymaga aktualizacji, aby go obsługiwał.
  • Niektórzy dostawcy mogą mieć własne linki łączące, ale argument i ld.mc.
Wczytaj
  • libRSCpuRef wczytuje udostępniony obiekt. Jeśli zmian w interfejsie, konieczne jest zwiększenie wersji HAL.
  • Dostawcy mogą użyć tagu libRSCpuRef do wczytywania udostępnionych danych lub zaimplementować własny obiekt.

Oprócz kodu HAL interfejsy API środowiska wykonawczego i wyeksportowane symbole są również i interfejsów. Od Androida 7.0 (API 24) żaden interfejs nie uległ zmianie nie planujecie w najbliższym czasie jej zmienić w Androidzie 8.0 i nowszych. Jeśli jednak zmienia się interfejs, wersja HAL również zwiększa się.

Implementacje dostawców

Android 8.0 lub nowszy wymaga pewnych zmian sterownika GPU, aby można było nie działają poprawnie.

Moduły sterowników

  • Moduły sterowników nie mogą korzystać z żadnych bibliotek systemowych, które nie znajdują się w listę.
  • Kierowca musi przesłać własny android.hardware.renderscript@1.0-impl_{NAME} lub zadeklaruj domyślna implementacja android.hardware.renderscript@1.0-impl jako jej zależności.
  • Implementacja procesora libRSDriver.so to dobry przykład usuń zależności inne niż VNDK-SP.

Kompilator kodu bitowego

Kod bitowy RenderScript na potrzeby sterownika dostawcy możesz skompilować na 2 sposoby:

  1. Wywołaj specyficzny dla dostawcy kompilator RenderScript w języku /vendor/bin/ (preferowana metoda kompilacji GPU). Podobnie jak w przypadku innych modułów sterownikowych, plik binarny kompilatora dostawcy nie może zależeć od żadnej biblioteki systemowej, która nie jest lista bibliotek RenderScript dla dostawców.
  2. Wywołaj pole UDW systemu: /system/bin/bcc z użyciem adresu dostawcy bcc plugin ten dodatek nie może korzystać z biblioteki systemowej, nie znajduje się na liście Dostępne biblioteki RenderScript dostawcom.

Jeśli dostawca bcc plugin musi zakłócać działanie procesora kompilacja i jej zależność od libLLVM.so nie mogą być łatwe usunięty, dostawca powinien skopiować bcc (oraz wszystkie pliki inne niż LL-NDK w tym libLLVM.so i libbcc.so) w /vendor partycja.

Dodatkowo dostawcy muszą wprowadzić te zmiany:

Rysunek 7. Zmiany sterownika dostawcy.

  1. Skopiuj libclcore.bc do partycji /vendor. Ten zapewnia libclcore.bc, libLLVM.so i Lista libbcc.so jest zsynchronizowana.
  2. Zmień ścieżkę do pliku wykonywalnego bcc za pomocą ustawienia RsdCpuScriptImpl::BCC_EXE_PATH z implementacji RS HAL.
.

Zasada SELinux

Zasada SELinux wpływa zarówno na pliki wykonywalne sterownika, jak i na pliki wykonywalne kompilatora. Wszystkie moduły sterownika muszą być oznaczone etykietą same_process_hal_file w file_contexts na urządzeniu. Na przykład: 

/vendor/lib(64)?/libRSDriver_EXAMPLE\.so     u:object_r:same_process_hal_file:s0

Proces aplikacji również musi mieć możliwość wywołania pliku wykonywalnego kompilatora kopię pola UDW (/vendor/bin/bcc) od dostawcy. Na przykład: 

device/vendor_foo/device_bar/sepolicy/file_contexts:
/vendor/bin/bcc                    u:object_r:same_process_hal_file:s0

Starsze urządzenia

Starsze urządzenia to urządzenia, które spełniają te warunki:

  1. PRODUCT_SHIPPING_API_LEVEL ma wartość mniejszą niż 26.
  2. Nie zdefiniowany jest PRODUCT_FULL_TREBLE_OVERRIDE.

W przypadku urządzeń starszego typu ograniczenia nie są egzekwowane przy przechodzeniu na Androida 8.0 lub nowszego, co oznacza, że sterowniki mogą nadal łączyć się z bibliotekami. w usłudze /system/lib[64]. Jednak ze względu na zmianę architektury związane z: OVERRIDE_RS_DRIVER, android.hardware.renderscript@1.0-impl musi być zainstalowany, aby /vendor partycja; Jeśli tego nie zrobisz, wymuszane jest środowisko wykonawcze RenderScript w przypadku ścieżki procesora.

Informacje o powodach wycofania technologii Renderscript znajdziesz na stronie dla deweloperów aplikacji na Androida Blog: Android GPU Compute – dalej. Oto informacje o zasobach: