RenderScript

RenderScript è un framework per eseguire operazioni ad alta intensità di calcolo di attività con prestazioni elevate su Android. È progettata per essere usata con il calcolo parallelo dei dati, sebbene possano trarne vantaggio anche i carichi di lavoro seriali. La Il runtime di RenderScript carica in contemporanea il lavoro tra i processori disponibili come CPU e GPU multi-core, che consentono agli sviluppatori di concentrarsi esprimere gli algoritmi anziché programmare il lavoro. RenderScript è particolarmente utile per app che eseguono l'elaborazione di immagini, fotografia o visione artificiale.

I dispositivi con Android 8.0 e versioni successive utilizzano il seguente RenderScript e gli HAL dei fornitori:

Figura 1. Codice fornitore collegato alle librerie interne.

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

  • Due istanze di librerie interne di RenderScript in un processo. Un set è per Percorso di riserva della CPU e proviene direttamente da /system/lib; l'altro impostato è per il percorso GPU e proviene da /system/lib/vndk-sp.
  • Le librerie RS interne in /system/lib fanno parte del e vengono aggiornati ogni volta che viene eseguito l'upgrade di system.img. Tuttavia, libs in /system/lib/vndk-sp sono creati per il fornitore e non sono aggiornate al momento dell'upgrade di system.img (mentre possono essere aggiornate per una correzione di sicurezza, la relativa ABI rimane la stessa).
  • Codice del fornitore (RS HAL, driver RS e bcc plugin) collegato alle librerie interne di RenderScript all'indirizzo /system/lib/vndk-sp. Non possono collegarsi a librerie in /system/lib perché le librerie presenti nella directory vengono create per piattaforma e, di conseguenza, potrebbe non essere compatibile con il codice del fornitore (ovvero, simboli potrebbe essere rimossa). Così facendo sarebbe impossibile creare un'agenzia di viaggi online basata solo sul framework.

Design

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

Librerie di RenderScript disponibili per i fornitori

Questa sezione elenca le librerie RenderScript (note come NDK del fornitore per lo stesso processo HAL o VNDK-SP) disponibili per il codice del fornitore e che possono essere collegati contro i guasti. Descrive inoltre altre librerie non correlate a ma che vengono fornite anche al codice del fornitore.

Anche se il seguente elenco di librerie potrebbe differire tra una release di Android e l'altra, è immutabile per una specifica release di Android; per avere un elenco aggiornato librerie disponibili, consulta la sezione /system/etc/ld.config.txt.

Libre di RenderScript Libre non di rendering
  • 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 linker

La limitazione di collegamento che impedisce l'utilizzo da parte delle librerie che non si trovano in VNDK-SP viene applicato in fase di runtime tramite lo spazio dei nomi del linker. Per maggiori dettagli, consulta la sezione VNDK Design presentazione.)

Su un dispositivo con Android 8.0 e versioni successive, tutti gli HAL (SP-HAL) con processo uguale ad eccezione di RenderScript vengono caricati all'interno dello spazio dei nomi del linker sphal. RenderScript viene caricato nello script rs, una posizione che consente una maggiore per le librerie di RenderScript. Poiché l'implementazione RS deve caricare dal bitcode compilato, /data/*/*.so viene aggiunto al percorso del rs (altri SP-HAL non possono caricare librerie dal partizione dati).

Inoltre, lo spazio dei nomi rs consente più librerie rispetto a quelle fornite da altri spazi dei nomi. libmediandk.so e libft2.so sono esposte allo spazio dei nomi rs perché libRS_internal.so ha una dipendenza interna da queste librerie.

Figura 2. Configurazione dello spazio dei nomi per il linker.

Carica i driver

Percorso di riserva della CPU

A seconda dell'esistenza del bit RS_CONTEXT_LOW_LATENCY quando crei un contesto RS, viene selezionato il percorso della CPU o della GPU. Quando Il percorso CPU è selezionato, libRS_internal.so (l'implementazione principale del framework RS) viene dlopendirettamente dal linker predefinito spazio dei nomi in cui viene fornita la versione della piattaforma delle librerie RS.

L'implementazione RS HAL del fornitore non viene utilizzata se la CPU è già in uso e viene creato un oggetto RsContext null mVendorDriverName. libRSDriver.so è (di predefinita) dlopened e il driver lib viene caricato dal default perché il chiamante (libRS_internal.so) viene caricato anche in default nello spazio dei nomi.

Figura 3. Percorso di riserva della CPU.

Percorso GPU

Per il percorso GPU, libRS_internal.so viene caricato in modo diverso. Innanzitutto, libRS.so utilizza android.hardware.renderscript@1.0.so (e i relativi sottostanti libhidltransport.so) per caricare android.hardware.renderscript@1.0-impl.so (un fornitore di RS HAL) in uno spazio dei nomi diverso del linker chiamato sphal. L'RS HAL quindi dlopen di libRS_internal.so in un altro dello spazio dei nomi del linker denominato rs.

I fornitori possono fornire il proprio driver RS impostando il flag tempo di creazione OVERRIDE_RS_DRIVER, incorporato in RS HAL implementazione (hardware/interfaces/renderscript/1.0/default/Context.cpp). Questo il nome del driver viene quindi dlopenper il contesto RS del percorso GPU.

La creazione dell'oggetto RsContext è delegata all'HAL RS implementazione. L'HAL richiama il framework RS utilizzando Funzione rsContextCreateVendor() con il nome del conducente per da usare come argomento. Il framework RS carica quindi il driver specificato quando RsContext è stato inizializzato. In questo caso, la libreria dei driver caricato nello spazio dei nomi rs perché RsContext viene creato all'interno dello spazio dei nomi rs /vendor/lib si trova nel percorso di ricerca dello spazio dei nomi.

Figura 4. Percorso di riserva della GPU.

Quando si passa dallo spazio dei nomi default allo spazio dei nomi sphal, libhidltransport.so utilizza lo spazio dei nomi android_load_sphal_library() per ordinare in modo esplicito linker dinamico per caricare la libreria -impl.so dal sphal.

Quando si passa dallo spazio dei nomi sphal allo spazio dei nomi rs, il caricamento viene eseguito indirettamente dalla riga seguente in /system/etc/ld.config.txt: 

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

Questa riga specifica che il Linker dinamico deve caricare libRS_internal.so dallo spazio dei nomi rs quando non può essere trovata/caricata dallo spazio dei nomi sphal (che è sempre del caso perché lo spazio dei nomi sphal non esegue ricerche /system/lib/vndk-sp dove libRS_internal.so . Con questa configurazione, è sufficiente una semplice chiamata dlopen() libRS_internal.so è sufficiente per eseguire la transizione dello spazio dei nomi.

Carica il plug-in bcc

bcc plugin è una libreria fornita dal fornitore caricata in compilatore bcc. Poiché bcc è un processo di sistema /system/bin, la libreria bcc plugin può essere considerata un SP-HAL (ovvero un HAL del fornitore che può essere caricato direttamente processo di sistema senza essere vincolati). In qualità di SP-HAL, Libreria bcc-plugin:

  • Impossibile collegarsi a librerie solo framework come libLLVM.so.
  • Può collegarsi solo alle librerie VNDK-SP a disposizione del fornitore.

Questa restrizione viene applicata caricando bcc plugin nel sphal utilizzando android_sphal_load_library(). Nelle versioni precedenti di Android, il nome del plug-in è stato specificato utilizzando l'opzione -load e la libreria è stata caricata usando il semplice dlopen() libLLVM.so. In Android 8.0 e versioni successive, questo valore viene specificato -plugin e la lib viene caricata direttamente bcc. Questa opzione consente un percorso non specifico di Android per il progetto LLVM open source.

Figura 5. Caricamento del plug-in bcc, Android 7.x e versioni precedenti.



Figura 6. Caricamento del plug-in bcc, Android 8.0 e versioni successive.

Percorsi di ricerca per ld.mc

Durante l'esecuzione di ld.mc, alcune librerie di runtime RS vengono fornite come input al linker. Il bitcode RS dell'app è collegato alle librerie di runtime e quando il bitcode convertito viene caricato in un processo dell'app, le librerie di runtime vengono nuovamente collegati in modo dinamico dal bitcode convertito.

Le librerie di runtime includono:

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

Quando carichi il bitcode compilato nel processo dell'app, fornisci esattamente lo stesso libreria utilizzata da ld.mc. Altrimenti, il codice bitcode compilato potrebbe non trovare un simbolo disponibile al momento del collegamento.

Per farlo, il framework RS utilizza percorsi di ricerca diversi per le librerie di runtime quando eseguire ld.mc, a seconda che il framework RS stesso sia caricato da /system/lib o da /system/lib/vndk-sp. Ciò può essere determinato leggendo l'indirizzo di un simbolo arbitrario di RS framework lib e utilizzare dladdr() per ottenere il percorso del file mappato l'indirizzo.

Criterio SELinux

In seguito alle modifiche al criterio SELinux in Android 8.0 e versioni successive, è necessario seguono regole specifiche (applicate fino al giorno neverallows) quando etichettatura di file aggiuntivi nella partizione vendor:

  • vendor_file deve essere l'etichetta predefinita per tutti i file in vendor partizione. I criteri della piattaforma richiedono questa autorizzazione per accedere implementazioni HAL passthrough.
  • Tutti i nuovi exec_types aggiunti nella partizione vendor tramite SEPolicy del fornitore deve avere l'attributo vendor_file_type. Questa impostazione viene applicata tramite neverallows.
  • Per evitare conflitti con aggiornamenti futuri della piattaforma/del framework, evita di etichettare diversi da exec_types nella partizione vendor.
  • Tutte le dipendenze della libreria per gli HAL con lo stesso processo identificati da AOSP devono essere con etichetta same_process_hal_file.

Per maggiori dettagli sul criterio SELinux, consulta Linux avanzato su Android.

Compatibilità ABI per bitcode

Se non vengono aggiunte nuove API, il che significa che non è stato eseguito il pull della versione dell'HAL, i framework RS continuerà a utilizzare il driver GPU (HAL 1.0) esistente.

Per modifiche minori all'HAL (HAL 1.1) che non interessano il bitcode, i framework devono utilizza la CPU per le API appena aggiunte e continua a utilizzare il driver GPU (HAL 1.0) altrove.

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

L'utilizzo del bitcode di RenderScript avviene in tre fasi:

Palcoscenico Dettagli
Compilazione
  • Il bitcode di input (.bc) per bcc deve essere in Il formato bitcode LLVM 3.2 e bcc devono essere precedenti compatibili con le app esistenti (legacy).
  • Tuttavia, i metadati in .bc potrebbero cambiare (potrebbero cambiare funzioni, ad esempio Selettori di allocazione ∓ getter, funzioni matematiche e così via). Componente delle funzioni di runtime si trova in libclcore.bc, parte di esse si trova in LibRSDriver o in un fornitore equivalente.
  • Le nuove funzioni di runtime o l'interruzione delle modifiche ai metadati richiedono un incremento il livello API bitcode. Poiché i conducenti dei fornitori non potranno utilizzarli, deve essere incrementata anche la versione HAL.
  • I fornitori possono avere i propri compilatori, ma le conclusioni/i requisiti per bcc si applicano anche ai compilatori.
Link
  • Il file .o compilato verrà collegato al driver del fornitore, ad esempio libRSDriver_foo.so e libcompiler_rt.so. La CPU il percorso si collegherà a libRSDriver.so.
  • Se .o richiede una nuova API di runtime da libRSDriver_foo, il driver del fornitore deve essere aggiornato per supportarlo.
  • Alcuni fornitori possono avere i propri linker, ma l'argomento ld.mc si applicano anche a questi.
Carica
  • libRSCpuRef carica l'oggetto condiviso. Se ci sono modifiche a questa interfaccia, è necessario un bumper di versione HAL.
  • I fornitori farebbero affidamento su libRSCpuRef per caricare i file o implementarne uno proprio.

Oltre all'HAL, sono disponibili anche le API di runtime e i simboli esportati interfacce. Nessuna delle due interfacce è cambiata da Android 7.0 (API 24) e lì non abbiamo in programma di cambiarla a breve su Android 8.0 e versioni successive. Tuttavia, se a ogni modifica dell'interfaccia, verrà incrementata anche la versione dell'HAL.

Implementazioni dei fornitori

Android 8.0 e versioni successive richiede alcune modifiche al driver GPU perché il driver GPU funzionino correttamente.

Moduli driver

  • I moduli driver non devono dipendere da librerie di sistema che non si trovano l'elenco.
  • Il conducente deve fornire la propria android.hardware.renderscript@1.0-impl_{NAME}, oppure dichiara il implementazione predefinita android.hardware.renderscript@1.0-impl come e la sua dipendenza.
  • L'implementazione della CPU libRSDriver.so è un buon esempio di come per rimuovere le dipendenze non VNDK-SP.

Compilatore bitcode

Puoi compilare il bitcode di RenderScript per il driver del fornitore in due modi:

  1. Richiama il compilatore RenderScript specifico del fornitore in /vendor/bin/ (metodo preferito per la compilazione GPU). Analogamente ad altri moduli driver, Il programma binario del compilatore del fornitore non può dipendere da librerie di sistema che non sono elenco di libr di RenderScript disponibili per i fornitori.
  2. Richiama Ccn del sistema: /system/bin/bcc con un fornitore fornito dal fornitore bcc plugin; questo plug-in non può dipendere da alcuna libreria di sistema non è nell'elenco di Librerie RenderScript disponibili ai fornitori.

Se il fornitore bcc plugin deve interferire con la CPU e la sua dipendenza da libLLVM.so non possono essere rimosso, il fornitore deve copiare bcc (e tutti i tag non LL-NDK delle dipendenze, tra cui libLLVM.so, libbcc.so) /vendor partizione.

Inoltre, i fornitori devono apportare le seguenti modifiche:

Figura 7. Modifiche al driver del fornitore.

  1. Copia libclcore.bc nella partizione /vendor. Questo garantisce che libclcore.bc, libLLVM.so e libbcc.so sono sincronizzati.
  2. Modifica il percorso dell'eseguibile bcc impostandolo RsdCpuScriptImpl::BCC_EXE_PATH dell'implementazione di RS HAL.
di Gemini Advanced.

Criterio SELinux

Il criterio SELinux influisce sia sul driver sia sugli eseguibili del compilatore. Tutti i moduli driver devono avere l'etichetta same_process_hal_file nel file_contexts del dispositivo. Ad esempio: 

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

L'eseguibile del compilatore deve poter essere richiamato da un processo dell'app, così come la copia del fornitore in Ccn (/vendor/bin/bcc). Ad 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 limitazioni non vengono applicate quando si esegue l'upgrade Android 8.0 e versioni successive, il che significa che i driver possono continuare a collegarsi alle librerie a /system/lib[64]. Tuttavia, a causa del cambiamento dell'architettura correlati a OVERRIDE_RS_DRIVER, È necessario installare android.hardware.renderscript@1.0-impl per /vendor partizione; se non lo fa, forza il runtime di RenderScript di riserva al percorso della CPU.

Per informazioni sul motivo del ritiro di Renderscript, consulta il forum degli sviluppatori Android Blog: Android GPU Computing Forward. Le informazioni sulle risorse relative a questo ritiro includono quanto segue: