Renderscript

RenderScript è un framework per l'esecuzione di compiti computazionalmente intensive ad alte prestazioni su Android. È progettato per l'uso con il calcolo parallelo dei dati, sebbene anche i carichi di lavoro seriali possano trarne vantaggio. Il runtime di RenderScript parallelizza il lavoro tra i processori disponibili su un dispositivo, come CPU e GPU multi-core, consentendo agli sviluppatori di concentrarsi sull'espressione di algoritmi piuttosto che sulla pianificazione del lavoro. RenderScript è particolarmente utile per le applicazioni che eseguono l'elaborazione delle immagini, la fotografia computazionale o la visione artificiale.

I dispositivi con Android 8.0 e versioni successive utilizzano il framework RenderScript e gli HAL del fornitore seguenti:

Figura 1. Codice fornitore di collegamento a librerie interne

Le differenze da RenderScript in Android 7.x e versioni precedenti includono:

  • Due istanze di librerie interne RenderScript in un processo. Un set è per il percorso di ripiego CPU ed è da direttamente a /system/lib ; l'altra serie è per via GPU e dista /system/lib/vndk-sp .
  • RS libs interne in /system/lib sono costruite come parte della piattaforma e vengono aggiornati come system.img viene aggiornato. Tuttavia, librerie in /system/lib/vndk-sp sono costruiti per il venditore e non vengono aggiornati quando system.img viene aggiornato (mentre possono essere aggiornati per una correzione di sicurezza, la loro ABI rimane la stessa).
  • Codice fornitore (RS HAL, conducente RS, e il bcc plugin ) sono collegati contro le librerie interne RenderScript situate /system/lib/vndk-sp . Non possono collegare contro librerie in /system/lib perché librerie in quella directory sono costruiti per la piattaforma e quindi non può essere compatibile con il codice fornitore (cioè, simboli può essere rimosso). Ciò renderebbe impossibile un'OTA solo per framework.

Design

Le sezioni seguenti descrivono in dettaglio la progettazione di RenderScript in Android 8.0 e versioni successive.

Librerie RenderScript disponibili per i fornitori

Questa sezione elenca le librerie RenderScript (conosciute come Vendor NDK for Same-Process HAL o VNDK-SP) che sono disponibili per il codice del fornitore e che possono essere collegate. Descrive inoltre ulteriori librerie che non sono correlate a RenderScript ma che sono fornite anche al codice del fornitore.

Sebbene il seguente elenco di librerie possa differire tra le versioni di Android, è immutabile per una specifica versione di Android; per un elenco aggiornato di librerie disponibili, fare riferimento a /system/etc/ld.config.txt .

Librerie RenderScript Librerie non 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

Configurazione dello spazio dei nomi del linker

La restrizione di collegamento che impedisce alle librerie non presenti in VNDK-SP di essere utilizzate dal codice del fornitore viene applicata in fase di esecuzione utilizzando lo spazio dei nomi del linker. (Per i dettagli, consultare la VNDK design di presentazione.)

Su un dispositivo con sistema operativo Android 8.0 e versioni successive, tutte HAL con lo stesso processo (SP-Hals), ad eccezione RenderScript vengono caricati all'interno del linker namespace sphal . RenderScript viene caricato nei RenderScript-specifici namespace rs , una posizione che permette un'applicazione più comoda per librerie RenderScript. Perché le esigenze di implementazione RS per caricare il codice binario che compilato, /data/*/*.so viene aggiunto al percorso della rs namespace (altri SP-HAL non sono autorizzati a librerie di carico dalla partizione dati).

Inoltre, la rs namespace consente a più librerie di quanto previsto da altri spazi dei nomi. libmediandk.so e libft2.so sono esposti al rs namespace perché libRS_internal.so ha una dipendenza interna a queste librerie.

Configurazione Figura 2. Namespace per linker

Caricamento driver

Percorso di fallback della CPU

A seconda della esistenza del RS_CONTEXT_LOW_LATENCY po 'durante la creazione di un contesto RS, si seleziona la CPU o il percorso GPU. Quando si seleziona il percorso della CPU, libRS_internal.so (la principale attuazione del quadro RS) è direttamente dlopen cata dallo spazio dei nomi linker predefinita in cui vengono forniti la versione della piattaforma di RS librerie.

RS attuazione HAL dal fornitore non viene usato affatto quando viene acquistata percorso fallback CPU, e un RsContext oggetto viene creato con null mVendorDriverName . libRSDriver.so è (per impostazione predefinita) dlopen Ed e lib driver viene caricato dal default namespace perché il chiamante ( libRS_internal.so ) viene caricato anche nel default namespace.

Figura 4. CPU percorso fallback

Percorso GPU

Per il percorso GPU, il libRS_internal.so viene caricato in modo diverso. In primo luogo, libRS.so utilizza android.hardware.renderscript@1.0.so (e la sua basilare libhidltransport.so ) per caricare android.hardware.renderscript@1.0-impl.so (un'implementazione fornitore di RS HAL) in un diverso namespace linker chiamato sphal . La RS Hal poi dlopen s libRS_internal.so in un'altra linker namespace chiamato rs .

I fornitori possono fornire il loro driver RS impostando il flag tempo di costruzione OVERRIDE_RS_DRIVER , che è incorporato nella porta RS implementazione HAL ( hardware/interfaces/renderscript/1.0/default/Context.cpp ). Questo nome driver è quindi dlopen ed per il contesto RS per il percorso GPU.

La creazione del RsContext oggetto è delegata alla realizzazione RS HAL. Le chiamate HAL indietro al quadro RS utilizzando rsContextCreateVendor() funzione con il nome del conducente di utilizzare come argomento. Il quadro RS quindi carica il driver specificato quando il RsContext viene inizializzato. In questo caso, la libreria di driver viene caricato nella rs namespace perché l' RsContext oggetto viene creato all'interno della rs spazio dei nomi e /vendor/lib è nel percorso di ricerca dello spazio dei nomi.

Figura 5. GPU percorso fallback

Durante la transizione dal default namespace al sphal namespace, libhidltransport.so usi il android_load_sphal_library() la funzione di ordinare in modo esplicito il linker dinamico per caricare il -impl.so libreria dal sphal namespace.

Durante la transizione dal sphal namespace alla rs spazio dei nomi, il caricamento viene effettuato indirettamente dalla seguente riga in /system/etc/ld.config.txt :

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

Questa riga specifica il linker dinamico deve caricare libRS_internal.so dalla rs spazio dei nomi quando il lib non può essere trovato / caricato dal sphal namespace (che è sempre il caso perché sphal namespace non cerca /system/lib/vndk-sp dove libRS_internal.so risiede). Con questa configurazione, un semplice dlopen() chiamata a libRS_internal.so è sufficiente a rendere la transizione dello spazio dei nomi.

Caricamento plugin bcc

bcc plugin è una libreria vendor-fornito caricato nel bcc compilatore. Perché bcc è un processo di sistema nel /system/bin directory, il bcc plugin libreria può essere considerato un SP-HAL (vale a dire, un HAL fornitore che può essere caricato direttamente nel processo di sistema senza essere binderized). In qualità di SP-HAL, la bcc-plugin libreria:

  • Impossibile collegare contro quadro di sola librerie come libLLVM.so .
  • Può collegarsi solo alle librerie VNDK-SP disponibili per il fornitore.

Questa restrizione viene applicata caricando il bcc plugin nella sphal spazio dei nomi utilizzando il android_sphal_load_library() la funzione. Nelle versioni precedenti di Android, il nome del plugin è stato specificato usando l' -load opzione e la lib è stato caricato utilizzando il semplice dlopen() per libLLVM.so . In Android 8.0 e superiore, ciò è specificato nella -plugin opzione e lib viene caricato direttamente dal bcc stessa. Questa opzione abilita un percorso non specifico di Android per il progetto LLVM open source.

Figura 6. Caricare bcc plug, 7.x Android e inferiore


Figura 7. Caricare bcc plugin Android 8.0 e superiori

Percorsi di ricerca per ld.mc

Nell'eseguire ld.mc , librerie alcune RS runtime sono forniti come ingressi al linker. Il codice bit RS dell'app è collegato alle librerie di runtime e quando il codice bit convertito viene caricato in un processo dell'app, le librerie di runtime vengono nuovamente collegate dinamicamente dal codice bit convertito.

Le librerie di runtime includono:

  • libcompiler_rt.so
  • libm.so
  • libc.so
  • Conducente RS (sia libRSDriver.so o OVERRIDE_RS_DRIVER )

Quando si carica il codice binario che compilato nel processo di applicazione, fornire la stessa libreria esatto che è stato utilizzato da ld.mc . In caso contrario, il codice bit compilato potrebbe non trovare un simbolo che era disponibile quando è stato collegato.

Per fare ciò, RS quadro utilizza diversi percorsi di ricerca per le librerie di runtime durante l'esecuzione ld.mc , a seconda che il quadro RS si è caricato dal /system/lib oppure da /system/lib/vndk-sp . Questo può essere determinato leggendo l'indirizzo di un simbolo arbitrario di un lib RS quadro e utilizzando dladdr() per ottenere il percorso del file mappato l'indirizzo.

Politica SELinux

Come risultato dei cambiamenti di politica di SELinux in Android 8.0 e versioni successive, è necessario seguire specifiche regole (applicate tramite neverallows ) per l'etichettatura file aggiuntivi in vendor partizione:

  • vendor_file deve essere l'etichetta predefinita in per tutti i file di vendor partizione. La policy della piattaforma lo richiede per accedere alle implementazioni HAL passthrough.
  • Tutti i nuovi exec_types aggiunti in vendor partizione attraverso vendor SEPolicy devono avere vendor_file_type attributo. Questo viene applicata attraverso neverallows .
  • Per evitare conflitti con futura piattaforma / aggiornamenti quadro, i file di etichettatura di evitare altri exec_types in vendor partizione.
  • Tutte le dipendenze delle librerie per lo stesso HAL processo AOSP-identificati devono essere etichettati come same_process_hal_file .

Per i dettagli sulla policy di SELinux, vedere Security-Enhanced Linux in Android .

Compatibilità ABI per bitcode

Se non vengono aggiunte nuove API, il che significa nessun aumento della versione HAL, i framework RS continueranno a utilizzare il driver GPU (HAL 1.0) esistente.

Per modifiche minori all'HAL (HAL 1.1) che non influiscono sul bitcode, i framework dovrebbero eseguire il fallback alla CPU per queste API appena aggiunte e continuare a utilizzare il driver GPU (HAL 1.0) altrove.

Per le principali modifiche all'HAL (HAL 2.0) che interessano la compilazione/il collegamento del codice bit, i framework RS dovrebbero scegliere di non caricare i driver GPU forniti dal fornitore e utilizzare invece il percorso CPU o Vulkan per l'accelerazione.

Il consumo del codice bit RenderScript avviene in tre fasi:

Palcoscenico Particolari
Compilare
  • Il codice binario che ingresso (.BC) per bcc deve essere in LLVM 3.2 formato codice binario che e bcc deve essere compatibile con le applicazioni (legacy) esistenti.
  • Tuttavia, i meta-dati in .bc potrebbero cambiare (potrebbero esserci nuove funzioni di runtime, ad es. Setter di allocazione ∓ getter, funzioni matematiche, ecc.). Parte delle funzioni di runtime vive in libclcore.bc , parte di essi vive in LibRSDriver o fornitore equivalente.
  • Le nuove funzioni di runtime o l'interruzione delle modifiche ai metadati richiedono l'incremento del livello API del codice bit. Poiché i driver del fornitore non saranno in grado di utilizzarlo, anche la versione HAL deve essere incrementata.
  • I fornitori possono avere le proprie compilatori, ma le conclusioni / requisiti per bcc applicano anche a quei compilatori.
Collegamento
  • Il .o compilato sarà collegato con conducente fornitore, ad esempio, libRSDriver_foo.so e libcompiler_rt.so . Il percorso CPU collegherà con libRSDriver.so .
  • Se il .o richiede una nuova API runtime dal libRSDriver_foo , il fornitore del driver deve essere aggiornato per sostenerlo.
  • Alcuni fornitori possono avere le proprie linker, ma l'argomento per ld.mc valere anche per loro.
Carico
  • libRSCpuRef carichi l'oggetto condiviso. Se ci sono modifiche a questa interfaccia, è necessario un aumento della versione di HAL.
  • Fornitori dovrebbero o invocare libRSCpuRef per caricare l'oggetto condiviso, o implementare il proprio.

Oltre all'HAL, anche le API di runtime e i simboli esportati sono interfacce. Nessuna delle due interfacce è cambiata da Android 7.0 (API 24) e non ci sono piani immediati per cambiarla in Android 8.0 e versioni successive. Tuttavia, se l'interfaccia cambia, aumenterà anche la versione HAL.

Implementazioni del fornitore

Android 8.0 e versioni successive richiedono alcune modifiche al driver GPU affinché il driver GPU funzioni correttamente.

Moduli driver

  • I moduli conducente non deve dipendere da eventuali librerie di sistema che non sono nella lista .
  • Conducente deve fornire il proprio android.hardware.renderscript@1.0-impl_{NAME} , o dichiarare l'implementazione predefinita android.hardware.renderscript@1.0-impl come la sua dipendenza.
  • Implementazione CPU libRSDriver.so è un buon esempio di come rimuovere le dipendenze non VNDK-SP.

Compilatore di bitcode

Puoi compilare il codice bit RenderScript per il driver del fornitore in due modi:

  1. Invoke vendor-specifica RenderScript compilatore in /vendor/bin/ (metodo preferito di compilazione GPU). Simile ad altri moduli del driver, il binario produttore del compilatore non può dipendere da qualsiasi libreria di sistema che non è nella lista dei RenderScript librerie a disposizione dei fornitori .
  2. Invoke Sistema bcc: /system/bin/bcc con un fornitore-ha fornito bcc plugin ; questo plugin non può dipendere da qualsiasi libreria di sistema che non è nella lista dei RenderScript librerie a disposizione dei fornitori .

Se il venditore bcc plugin esigenze di interferire con la compilazione della CPU e la sua dipendenza libLLVM.so non può essere facilmente rimosso, il venditore deve copiare bcc (e tutte le dipendenze non-LL-NDK, tra cui libLLVM.so , libbcc.so ) in /vendor partizione.

Inoltre, i fornitori devono apportare le seguenti modifiche:

Figura 8. Modifiche al fornitore di driver
  1. Copia libclcore.bc a /vendor partizione. Ciò assicura libclcore.bc , libLLVM.so , e libbcc.so sono in sincronia.
  2. Modificare il percorso del bcc eseguibile impostando RsdCpuScriptImpl::BCC_EXE_PATH dalle RS HAL di implementazione.

Politica SELinux

La politica di SELinux influenza sia il driver che gli eseguibili del compilatore. Tutti i moduli di pilotaggio devono essere etichettati same_process_hal_file nella del dispositivo file_contexts . Per esempio:

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

L'eseguibile compilatore deve poter essere invocata da un processo di applicazione, così come la copia fornitore di bcc ( /vendor/bin/bcc ). Per esempio:

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

Dispositivi legacy

I dispositivi legacy sono quelli che soddisfano le seguenti condizioni:

  1. PRODUCT_SHIPPING_API_LEVEL è inferiore a 26.
  2. PRODUCT_FULL_TREBLE_OVERRIDE non è definito.

Per i dispositivi legacy, le restrizioni non vengono applicate durante l'aggiornamento ad Android 8.0 e versioni successive, cioè i piloti possono continuare a link per librerie in /system/lib[64] . Tuttavia, a causa del cambiamento dell'architettura relativa a OVERRIDE_RS_DRIVER , android.hardware.renderscript@1.0-impl deve essere installato a /vendor partizione; in caso contrario, viene forzato il fallback del runtime di RenderScript nel percorso della CPU.

Per informazioni circa la motivazione per la deprecazione Renderscript, vedere il blog Android Developers: Android GPU Compute Andando avanti . Le informazioni sulle risorse per questa deprecazione includono quanto segue: