RenderScript es un marco de trabajo para ejecutar aplicaciones de procesamiento intensivo. tareas con alto rendimiento en Android. Está diseñada para usarse con del procesamiento paralelo de datos, aunque las cargas de trabajo en serie también pueden beneficiarse. El El entorno de ejecución de RenderScript permite trabajar en paralelo con todos los procesadores disponibles en un de procesamiento de datos, como CPU y GPU de varios núcleos, lo que permite a los desarrolladores enfocarse para expresar algoritmos, en lugar de programar el trabajo. RenderScript es especialmente útil para las apps que realizan procesamiento de imágenes, procesamiento fotografía o visión artificial.
Los dispositivos con Android 8.0 y versiones posteriores usan el siguiente RenderScript HALs de framework y proveedores:
Figura 1: Vinculación de código de proveedor a bibliotecas internas
Entre las diferencias con RenderScript en Android 7.x y versiones anteriores, se incluyen las siguientes:
- Dos instancias de bibliotecas internas de RenderScript en un proceso. Un conjunto es para
Ruta de acceso de resguardo de la CPU que proviene directamente de
/system/lib
. el otro es para la ruta de GPU y es de/system/lib/vndk-sp
. - Las bibliotecas internas de RS en
/system/lib
se compilan como parte del y se actualizan a medida que se actualizasystem.img
. Sin embargo, las bibliotecas en/system/lib/vndk-sp
se compilan para el proveedor y no se se actualizará cuando se actualicesystem.img
(mientras se puede actualizar) para recibir una solución de seguridad, su ABI sigue siendo la misma). - El código del proveedor (RS HAL, controlador RS y
bcc plugin
) son los siguientes: se vincula con las bibliotecas internas de RenderScript ubicadas en/system/lib/vndk-sp
No pueden vincularse a bibliotecas de/system/lib
porque las bibliotecas de ese directorio se compilan para el y, por lo tanto, puede no ser compatible con el código del proveedor (es decir, símbolos puede quitarse). Si lo hicieras, sería imposible implementar una tecnología inalámbrica solo en el framework.
Diseño
En las siguientes secciones, se detalla el diseño de RenderScript en Android 8.0 y versiones posteriores.
Bibliotecas de RenderScript disponibles para los proveedores
En esta sección, se enumeran las bibliotecas de RenderScript (conocidas como Vendor NDK for Same-Process) HAL o VNDK-SP) que están disponibles para el código del proveedor y se pueden vincular. y defenderte. También detalla las bibliotecas adicionales que no están relacionadas con RenderScript, pero que también se proporcionan al código del proveedor.
Si bien la siguiente lista de bibliotecas puede diferir entre las versiones de Android,
es inmutable para una versión específica de Android; para obtener una lista actualizada de
las bibliotecas disponibles, consulta /system/etc/ld.config.txt
.
Bibliotecas de RenderScript | Bibliotecas que no son de RenderScript |
---|---|
|
|
Configuración del espacio de nombres del vinculador
La restricción de vinculación que impide que se usen bibliotecas que no están en VNDK-SP el código del proveedor se aplica en el entorno de ejecución mediante el espacio de nombres del vinculador. (Para obtener más información, consulta la página de diseño de VNDK. la presentación).
En un dispositivo con Android 8.0 o una versión posterior, todas las HAL del mismo proceso (SP-HAL)
excepto RenderScript que se cargan dentro del espacio de nombres del vinculador
sphal
RenderScript se carga en la API específica de RenderScript
el espacio de nombres rs
, una ubicación que habilita un ancho un poco más flexible
aplicación forzosa para las bibliotecas de RenderScript. Debido a que la implementación de RS necesita cargar
el código de bits compilado, /data/*/*.so
se agrega a la ruta de acceso del
rs
(otras HAL de SP no pueden cargar bibliotecas del
partición de datos).
Además, el espacio de nombres rs
permite más bibliotecas que las proporcionadas para
otros espacios de nombres. libmediandk.so
y libft2.so
están expuestos al espacio de nombres rs
porque
libRS_internal.so
tiene una dependencia interna a estas bibliotecas.
Figura 2: Configuración del espacio de nombres para el vinculador.
Controladores de carga
Ruta de resguardo de la CPU
Según la existencia del bit RS_CONTEXT_LOW_LATENCY
Cuando se crea un contexto de RS, se selecciona la ruta de la CPU o la GPU. Cuando
Se seleccionó la ruta de acceso de la CPU, libRS_internal.so
(la implementación principal
del framework de RS) se realiza directamente dlopen
del vinculador predeterminado
espacio de nombres en el que se proporciona la versión de plataforma de las bibliotecas de RS.
La implementación de RS HAL del proveedor no se usa en absoluto cuando la CPU
se toma la ruta de resguardo y se crea un objeto RsContext
con
mVendorDriverName
nulo libRSDriver.so
es (por
(configuración predeterminada) dlopen
, y la biblioteca del controlador se carga desde el
Espacio de nombres default
porque el llamador
(libRS_internal.so
) también se carga en default
espacio de nombres.
Figura 3: Ruta de resguardo de la CPU.
Ruta de acceso de la GPU
Para la ruta de acceso de la GPU, libRS_internal.so
se carga de manera diferente.
Primero, libRS.so
usa
android.hardware.renderscript@1.0.so
(y sus políticas
libhidltransport.so
) para cargar
android.hardware.renderscript@1.0-impl.so
(un proveedor
de RS HAL) en un espacio de nombres de vinculador diferente llamado
sphal
La RS
HAL luego dlopen
libRS_internal.so
en otra
del vinculador llamado rs
.
Los proveedores pueden proporcionar su propio controlador de RS si configuran la marca de tiempo de compilación
OVERRIDE_RS_DRIVER
, que está incorporado en la HAL de RS
implementación
(hardware/interfaces/renderscript/1.0/default/Context.cpp
) Esta
El nombre del controlador se aplica a dlopen
para el contexto RS de la ruta de acceso de la GPU.
La creación del objeto RsContext
se delega a la HAL de RS
para implementarlos. La HAL vuelve a llamar al framework de RS con
Función rsContextCreateVendor()
con el nombre del controlador a
usar como argumento. El framework de RS carga el controlador especificado cuando el
Se inicializó RsContext
. En este caso, la biblioteca del controlador es
se cargan en el espacio de nombres rs
porque RsContext
se crea dentro del espacio de nombres rs
/vendor/lib
está en la ruta de búsqueda del espacio de nombres.
Figura 4: Ruta de resguardo de GPU.
Cuando realizas la transición del espacio de nombres default
al
El espacio de nombres sphal
, libhidltransport.so
usa el
android_load_sphal_library()
para ordenar de forma explícita los
vinculador dinámico para cargar la biblioteca -impl.so
desde el
Espacio de nombres sphal
.
Cuando realizas la transición del espacio de nombres sphal
al
rs
, la carga se realiza de forma indirecta mediante la siguiente línea de
/system/etc/ld.config.txt
:
namespace.sphal.link.rs.shared_libs = libRS_internal.so
Esta línea especifica que se debe cargar el vinculador dinámico.
libRS_internal.so
del espacio de nombres rs
cuando la biblioteca
no pueden encontrarse/cargarse desde el espacio de nombres sphal
(que siempre es
este es el caso porque el espacio de nombres sphal
no busca
/system/lib/vndk-sp
, donde libRS_internal.so
el sitio web). Con esta configuración, una simple llamada dlopen()
a
libRS_internal.so
es suficiente para realizar la transición del espacio de nombres.
Cargar complemento Cco
bcc plugin
es una biblioteca que proporciona el proveedor y que se carga en la
Compilador bcc
. Como bcc
es un proceso del sistema
/system/bin
, la biblioteca bcc plugin
se puede
considera una SP-HAL (es decir, una HAL de proveedor que puede cargarse directamente en la
proceso del sistema sin ser vinculante). Como una SP-HAL, el
Biblioteca bcc-plugin
:
- No se pueden vincular con bibliotecas exclusivas del framework, como
libLLVM.so
- Se puede vincular solo con las bibliotecas de VNDK-SP disponibles para el proveedor.
Para aplicar esta restricción, se debe cargar bcc plugin
en la
sphal
con el elemento
Función android_sphal_load_library()
. En versiones anteriores de
Android, el nombre del complemento se especificó con la opción -load
y
la biblioteca se cargó usando el simple dlopen()
libLLVM.so
En Android 8.0 y versiones posteriores, esto se especifica en el
-plugin
, y la biblioteca cargará directamente la biblioteca
bcc
. Esta opción habilita una ruta de acceso no específica de Android a
el proyecto de LLVM de código abierto.
Figura 5: Cargando el complemento Cco, Android 7.x y versiones anteriores.
Figura 6: Cargando el complemento Cco, Android 8.0 y versiones posteriores.
Rutas de búsqueda para ld.mc
Cuando se ejecuta ld.mc
, algunas bibliotecas de tiempo de ejecución de RS se proporcionan como entradas.
al vinculador. El código de bits RS de la app se vincula con las bibliotecas de tiempo de ejecución.
y, cuando se carga el código de bits convertido en un proceso de la app, las bibliotecas de entorno de ejecución
están vinculadas de forma dinámica
desde el código de bits convertido.
Las bibliotecas de entorno de ejecución incluyen lo siguiente:
libcompiler_rt.so
libm.so
libc.so
- Controlador de RS (ya sea
libRSDriver.so
oOVERRIDE_RS_DRIVER
)
Cuando cargues el código de bits compilado en el proceso de la app, proporciona la misma
biblioteca usada por ld.mc
. De lo contrario, el código de bits compilado
Es posible que no encuentre un símbolo que estaba disponible cuando se vinculó.
Para ello, el framework de RS usa diferentes rutas de búsqueda para las bibliotecas de entorno de ejecución cuando
mediante la ejecución de ld.mc
, dependiendo de si el framework de RS está
cargado desde /system/lib
o desde /system/lib/vndk-sp
.
Esto se puede determinar leyendo la dirección de un símbolo arbitrario de una RS.
la biblioteca de framework y cómo usar dladdr()
para obtener la ruta del archivo asignada a
la dirección.
Política de SELinux
Como resultado de los cambios en la política de SELinux en Android 8.0 y versiones posteriores, debes
sigue reglas específicas (aplicadas a través de neverallows
) cuando
etiquetar archivos adicionales en la partición vendor
:
vendor_file
debe ser la etiqueta predeterminada para todos los archivos devendor
. La política de la plataforma requiere esto para acceder implementaciones de HAL de transferencia.- Se agregaron todos los
exec_types
nuevos en la particiónvendor
a través de SEPolicy del proveedor debe tener el atributovendor_file_type
. Esto se aplica medianteneverallows
. - Para evitar conflictos con futuras actualizaciones de la plataforma o el framework, evita el etiquetado
otros archivos que no sean
exec_types
en una particiónvendor
. - Todas las dependencias de bibliotecas para las mismas HAL de proceso identificadas por AOSP se deben
etiquetado como
same_process_hal_file
.
Para obtener detalles sobre la política de SELinux, consulta Security-Enhanced Linux en Android:
Compatibilidad de ABI para código de bits
Si no se agregan APIs nuevas, lo que significa que no hay cambio de versión de HAL, los frameworks de RS seguirá usando el controlador de GPU existente (HAL 1.0).
En el caso de los cambios menores en la HAL (HAL 1.1) que no afectan el código de bits, los frameworks deben recurrir a la CPU para estas APIs recién agregadas y seguir usando el controlador de GPU (HAL 1.0) en otro lugar.
Para cambios importantes en la HAL (HAL 2.0) que afectan la compilación/vinculación de código de bits, RS los frameworks deben elegir no cargar los controladores de GPU que proporciona el proveedor y, en su lugar, usar la ruta de CPU o de Vulkan para acelerar la ejecución.
El consumo del código de bits de RenderScript se produce en tres etapas:
Etapa | Detalles |
---|---|
Compilar |
|
Vínculo |
|
Carga |
|
Además de la HAL, las APIs de tiempo de ejecución y los símbolos exportados interfaces. Ninguna de las interfaces ha cambiado desde Android 7.0 (nivel de API 24) y, no hay planes inmediatos de cambiarlo en Android 8.0 y versiones posteriores. Sin embargo, si el cambia la versión de HAL, también aumentará.
Implementaciones de proveedores
Android 8.0 y las versiones posteriores requieren algunos cambios en el controlador de GPU para que este se ejecute funcionen correctamente.
Módulos de controladores
- Los módulos de controlador no deben depender de ninguna biblioteca del sistema que no esté en la lista.
- El conductor debe proporcionar un
android.hardware.renderscript@1.0-impl_{NAME}
o declara el implementación predeterminadaandroid.hardware.renderscript@1.0-impl
como su dependencia. - La implementación de CPU
libRSDriver.so
es un buen ejemplo de cómo quita las dependencias que no pertenecen al VNDK-SP.
Compilador de códigos de bits
Puedes compilar el código de bits de RenderScript para el controlador del proveedor de dos maneras:
- Invoca el compilador RenderScript específico del proveedor en
/vendor/bin/
. (método preferido de compilación de GPU). Al igual que otros módulos de controlador, el El objeto binario del compilador del proveedor no puede depender de ninguna biblioteca del sistema que no se encuentre en el lista de bibliotecas de RenderScript disponibles para los proveedores. - Invoca el campo Cco del sistema:
/system/bin/bcc
con un valor proporcionado por el proveedorbcc plugin
; este complemento no puede depender de ninguna biblioteca del sistema que no está en la lista de Bibliotecas de RenderScript disponibles a los proveedores.
Qué hacer si el proveedor bcc plugin
necesita interferir en la CPU
compilación y su dependencia en libLLVM.so
no se pueden
el proveedor, deberá copiar bcc
(y todas las instancias
dependencias, incluidas libLLVM.so
y libbcc.so
) en
/vendor
.
Además, los proveedores deben realizar los siguientes cambios:
Figura 7: Cambios en el controlador de proveedor.
- Copia
libclcore.bc
en la partición/vendor
. Esta garantiza quelibclcore.bc
,libLLVM.so
ylibbcc.so
están sincronizados. - Cambiar la ruta de acceso al ejecutable
bcc
mediante la configuraciónRsdCpuScriptImpl::BCC_EXE_PATH
de la implementación de RS HAL
Política de SELinux
La política de SELinux afecta al controlador y a los ejecutables del compilador. Todo
los módulos de controlador deben tener la etiqueta same_process_hal_file
en el
file_contexts
del dispositivo. Por ejemplo:
/vendor/lib(64)?/libRSDriver_EXAMPLE\.so u:object_r:same_process_hal_file:s0
El ejecutable del compilador debe poder invocarse a través de un proceso de la app, al igual que
la copia del proveedor de Cco (/vendor/bin/bcc
). Por ejemplo:
device/vendor_foo/device_bar/sepolicy/file_contexts: /vendor/bin/bcc u:object_r:same_process_hal_file:s0
Dispositivos heredados
Los dispositivos heredados son aquellos que cumplen las siguientes condiciones:
- PRODUCT_SHIPPING_API_LEVEL es inferior a 26.
- PRODUCT_FULL_TREBLE_OVERRIDE no está definido.
En el caso de los dispositivos heredados, las restricciones no se aplican cuando se actualiza a
Android 8.0 y versiones posteriores, lo que significa que los controladores pueden seguir vinculando a las bibliotecas
en /system/lib[64]
. Sin embargo, debido a los cambios en la arquitectura
relacionadas con OVERRIDE_RS_DRIVER
,
Se debe instalar android.hardware.renderscript@1.0-impl
en
/vendor
partición; De lo contrario, se fuerza el entorno de ejecución de RenderScript.
y el resguardo de la ruta de acceso de la CPU.
Para obtener información sobre los motivos por los que Renderscript dejó de estar disponible, consulta la página de Android Developers Blog: El procesamiento con GPU de Android: El futuro. La información de los recursos de esta baja incluye la siguiente información:
- Cómo migrar desde Renderscript
- Ejemplo de RenderScriptMigration
- Kit de herramientas de reemplazo de funciones intrínsecas README
- Reemplazo de funciones intrínsecasToolkit.kt