Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Renderscript

RenderScript es un marco para la ejecución de tareas computacionalmente intensivas a un alto rendimiento en Android. Está diseñado para usarse con cómputo de datos en paralelo, aunque las cargas de trabajo en serie también pueden beneficiarse. El tiempo de ejecución de RenderScript paraleliza el trabajo en los procesadores disponibles en un dispositivo, como las CPU y GPU de varios núcleos, lo que permite a los desarrolladores centrarse en expresar algoritmos en lugar de programar el trabajo. RenderScript es especialmente útil para aplicaciones que realizan procesamiento de imágenes, fotografía computacional o visión por computadora.

Los dispositivos que ejecutan Android 8.0 y versiones posteriores utilizan el siguiente marco de RenderScript y los HAL del proveedor:

Figura código 1. Vendor vinculación a libs internos

Las diferencias con RenderScript en Android 7.xy versiones anteriores incluyen:

  • Dos instancias de bibliotecas internas de RenderScript en un proceso. Un conjunto es para ruta de CPU de reserva y es de directamente en /system/lib ; el otro conjunto es para ruta de GPU y es de /system/lib/vndk-sp .
  • RS libs internos en /system/lib se construyen como parte de la plataforma y se actualizan a medida system.img se actualiza. Sin embargo, en libs /system/lib/vndk-sp se construyen para el vendedor y no se actualizan cuando system.img se actualiza (mientras que pueden ser actualizados para una revisión de seguridad, su ABI sigue siendo el mismo).
  • Código de proveedor (RS HAL, RS conductor, y el bcc plugin ) están vinculados contra los libs internos renderScript situados en /system/lib/vndk-sp . No pueden enlazar con libs en /system/lib porque libs de ese directorio se construyen para la plataforma y por lo tanto puede no ser compatible con el código de proveedor (es decir, los símbolos se puede retirar). Hacerlo haría imposible una OTA de solo marco.

Diseño

Las siguientes secciones detallan el diseño de RenderScript en Android 8.0 y versiones posteriores.

Libs de RenderScript disponibles para proveedores

En esta sección se enumeran las bibliotecas de RenderScript (conocidas como NDK de proveedor para HAL del mismo proceso o VNDK-SP) que están disponibles para el código de proveedor y con las que se pueden vincular. También detalla 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, consulte /system/etc/ld.config.txt .

Libs de RenderScript Libs que no son de 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

Configuración del espacio de nombres del vinculador

La restricción de vinculación que evita que las bibliotecas que no están en VNDK-SP sean utilizadas por el código del proveedor se aplica en tiempo de ejecución mediante el espacio de nombres del vinculador. (Para más detalles, consulte la VNDK Diseño presentación).

En un dispositivo con Android 8.0 y superior, todos HAL mismo proceso (SP-HAL) excepto RenderScript se cargan en el interior del enlazador espacio de nombres sphal . RenderScript se carga en el espacio de nombres específicos RenderScript- rs , un lugar que permita la aplicación de un poco más flojo en las librerías renderScript. Debido a que las necesidades de implementación RS para cargar el código binario compilado, /data/*/*.so se añade a la trayectoria de la rs espacio de nombres (otros SP-HAL no se les permite libs de carga desde la partición de datos).

Además, el rs espacio de nombres permite que más librerías que el estipulado por otros espacios de nombres. libmediandk.so y libft2.so están expuestos al rs espacio de nombres porque libRS_internal.so tiene una dependencia interna de estas bibliotecas.

Configuración de la figura 2. Espacio de nombres para enlazador

Cargando controladores

Ruta de respaldo de la CPU

En función de la existencia de la RS_CONTEXT_LOW_LATENCY poco al crear un contexto RS, se selecciona la CPU o GPU ruta. Cuando se selecciona la trayectoria de CPU, libRS_internal.so (la implementación principal del marco RS) es directamente dlopen ed del espacio de nombres enlazador predeterminada en la que la versión de la plataforma de RS se proporcionan libs.

El RS aplicación HAL desde el proveedor no se utiliza en absoluto cuando se toma el camino de la CPU de reserva, y un RsContext objeto se crea con nula mVendorDriverName . libRSDriver.so es (por defecto) dlopen ed y la lib conductor se carga desde el default espacio de nombres debido a que la persona que llama ( libRS_internal.so ) también se carga en el default espacio de nombres.

Figura trayectoria de retorno 4. CPU

Ruta de la GPU

Por el camino GPU, la libRS_internal.so se carga de manera diferente. En primer lugar, libRS.so utiliza android.hardware.renderscript@1.0.so (y su subyacente libhidltransport.so ) para cargar android.hardware.renderscript@1.0-impl.so (una aplicación de proveedor de RS HAL) en un espacio de nombres enlazador diferente llamado sphal . El RS Hal entonces dlopen s libRS_internal.so en un enlazador otro espacio de nombres llamados rs .

Los vendedores pueden proporcionar su propio controlador RS estableciendo el indicador del tiempo de construcción OVERRIDE_RS_DRIVER , que se incrusta en el RS aplicación HAL ( hardware/interfaces/renderscript/1.0/default/Context.cpp ). Este nombre del controlador es entonces dlopen ed para el contexto RS para la trayectoria de la GPU.

La creación de la RsContext objeto se delega a la aplicación RS HAL. Las llamadas HAL atrás al marco RS utilizando rsContextCreateVendor() función con el nombre del conductor para su uso como un argumento. El marco RS continuación, carga el controlador especificado cuando el RsContext se inicializa. En este caso, la biblioteca del controlador se carga en el rs espacio de nombres debido a que el RsContext se crea en el interior del objeto rs espacio de nombres y /vendor/lib está en la ruta de búsqueda del espacio de nombres.

Figura camino de retorno 5. GPU

Cuando la transición de la default de espacio de nombres para el sphal espacio de nombres, libhidltransport.so los usos android_load_sphal_library() la función para ordenar explícitamente el enlazador dinámico para cargar el -impl.so biblioteca de la sphal espacio de nombres.

Cuando la transición de la sphal espacio de nombres al rs espacio de nombres, la carga se hace indirectamente por la línea siguiente en /system/etc/ld.config.txt :

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

Esta línea especifica el enlazador dinámico se debe cargar libRS_internal.so de la rs espacio de nombres cuando el lib no se pueden encontrar / cargado desde el sphal espacio de nombres (que es siempre el caso debido a sphal espacio de nombres no busca /system/lib/vndk-sp donde libRS_internal.so reside). Con esta configuración, un simple dlopen() llamada a libRS_internal.so es suficiente para hacer la transición del espacio de nombres.

Cargando complemento Bcc

bcc plugin es una biblioteca proporcionado por el proveedor cargado en la bcc compilador. Debido bcc es un proceso del sistema en el /system/bin directorio, el bcc plugin biblioteca puede ser considerado como un SP-HAL (es decir, un HAL proveedor que puede ser cargado directamente en el proceso de sistema sin ser revestidas con un aglutinante). Como un SP-HAL, la bcc-plugin de biblioteca:

  • No se puede enlazar con marco de sólo librerías como libLLVM.so .
  • Se puede vincular solo con las bibliotecas VNDK-SP disponibles para el proveedor.

Esta restricción es impuesta por la carga del bcc plugin en el sphal espacio de nombres usando el android_sphal_load_library() función. En las versiones anteriores de Android, el nombre del plugin se especificó usando el -load opción y el lib se cargó utilizando el sencillo dlopen() por libLLVM.so . En Android 8.0 y superior, esto se especifica en el -plugin opción y de la librería se carga directamente por el bcc en sí. Esta opción habilita una ruta no específica de Android al proyecto LLVM de código abierto.

Figura 6. Cargando bcc plugin, 7.x Android e inferior


Figura 7. Cargando bcc plugin, Android 8.0 y superior

Rutas de búsqueda para ld.mc

Al ejecutar ld.mc , algunas librerías RS tiempo de ejecución se dan como entradas al enlazador. El código de bits RS de la aplicación está vinculado con las bibliotecas en tiempo de ejecución y cuando el código de bits convertido se carga en un proceso de la aplicación, las bibliotecas en tiempo de ejecución se vinculan nuevamente dinámicamente desde el código de bits convertido.

Las bibliotecas en tiempo de ejecución incluyen:

  • libcompiler_rt.so
  • libm.so
  • libc.so
  • RS controlador (ya sea libRSDriver.so o OVERRIDE_RS_DRIVER )

Al cargar el código binario compilado en el proceso de aplicación, proporcionar la misma biblioteca exacta que fue utilizado por ld.mc . De lo contrario, es posible que el código de bits compilado no encuentre un símbolo que estuviera disponible cuando se vinculó.

Para ello, el marco RS utiliza diferentes rutas de búsqueda para las bibliotecas de tiempo de ejecución al ejecutar ld.mc , dependiendo de si el marco RS sí se carga desde /system/lib o desde /system/lib/vndk-sp . Esto se puede determinar mediante la lectura de la dirección de un símbolo arbitrario de un marco lib RS y el uso de dladdr() para obtener la ruta del archivo asignado a la dirección.

Política de SELinux

Como resultado de los cambios en la política de SELinux en Android 8.0 y posteriores, debe seguir reglas específicas (forzadas a través neverallows ) al etiquetar los archivos adicionales en vendor partición:

  • vendor_file debe ser la etiqueta por defecto en todos los archivos de vendor partición. La política de la plataforma requiere esto para acceder a las implementaciones de HAL de paso.
  • Todas las novedades exec_types añadidas en vendor partición a través de proveedores SEPolicy deben tener vendor_file_type atributo. Esto se aplica a través neverallows .
  • Para evitar conflictos con la plataforma de futuro / actualizaciones marco, archivos de etiquetado evitar otros que exec_types en vendor partición.
  • Todas las dependencias de bibliotecas para identificados-AOSP mismos HAL proceso deben ser etiquetados como same_process_hal_file .

Para más detalles sobre la política de SELinux, consulte Security-Enhanced Linux en Android .

Compatibilidad ABI para código de bits

Si no se agregan nuevas API, lo que significa que no hay cambios en la versión de HAL, los marcos de RS seguirán usando el controlador de GPU (HAL 1.0) existente.

Para cambios menores de HAL (HAL 1.1) que no afectan al código de bits, los marcos deberían recurrir a la CPU para estas API recién agregadas y seguir usando el controlador GPU (HAL 1.0) en otros lugares.

Para cambios importantes de HAL (HAL 2.0) que afectan la compilación / vinculación de código de bits, los marcos de RS deben optar por no cargar controladores de GPU proporcionados por el proveedor y, en su lugar, usar la ruta de CPU o Vulkan para la aceleración.

El consumo de código de bits de RenderScript se produce en tres etapas:

Escenario Detalles
Compilar
  • El código binario de entrada (.BC) para bcc debe estar en LLVM 3.2 formato de código binario y bcc debe ser compatible con aplicaciones (legacy) existentes.
  • Sin embargo, los metadatos en .bc podrían cambiar (podría haber nuevas funciones en tiempo de ejecución, por ejemplo, establecedores de asignación, captadores, funciones matemáticas, etc.). Parte de las funciones de tiempo de ejecución vive en libclcore.bc , parte de ellos vive en LibRSDriver o proveedor equivalente.
  • Las nuevas funciones en tiempo de ejecución o los cambios importantes en los metadatos requieren incrementar el nivel de API de código de bits. Debido a que los controladores de los proveedores no podrán consumirlo, la versión HAL también debe incrementarse.
  • Los vendedores pueden tener sus propios compiladores, pero las conclusiones / requisitos para bcc también se aplican a los compiladores.
Enlace
  • El .o compilado estará vinculado con controlador del proveedor, por ejemplo, libRSDriver_foo.so , y libcompiler_rt.so . El camino de la CPU se enlazará con libRSDriver.so .
  • Si el .o requiere una nueva API de tiempo de ejecución de libRSDriver_foo , el controlador del proveedor tiene que ser actualizado para apoyarlo.
  • Ciertos proveedores pueden tener sus propias enlazadores, pero el argumento a favor de ld.mc también se aplican a ellos.
Carga
  • libRSCpuRef carga el objeto compartido. Si hay cambios en esta interfaz, se necesita un aumento de la versión HAL.
  • Los vendedores o bien depender de libRSCpuRef para cargar el objeto compartido, o poner en práctica su propia cuenta.

Además de HAL, las API de tiempo de ejecución y los símbolos exportados también son interfaces. Ninguna interfaz ha cambiado desde Android 7.0 (API 24) y no hay planes inmediatos para cambiarla en Android 8.0 y posteriores. Sin embargo, si la interfaz cambia, la versión HAL también aumentará.

Implementaciones de proveedores

Android 8.0 y superior requiere algunos cambios en el controlador de GPU para que el controlador de GPU funcione correctamente.

Módulos de controlador

  • Módulos de los controladores no deben depender de ninguna librería del sistema que no están en la lista .
  • El conductor debe proporcionar su propia android.hardware.renderscript@1.0-impl_{NAME} , o declarar la implementación predeterminada android.hardware.renderscript@1.0-impl como su dependencia.
  • Aplicación de la CPU libRSDriver.so es un buen ejemplo de cómo quitar dependencias no VNDK-SP.

Compilador de código de bits

Puede compilar el código de bits de RenderScript para el controlador del proveedor de dos formas:

  1. Invoke específico del proveedor RenderScript compilador en /vendor/bin/ (método preferido de compilación GPU). Al igual que en otros módulos de los controladores, el binario proveedor compilador no puede depender de cualquier biblioteca de sistema que no está en la lista de RenderScript librerías disponibles para los vendedores .
  2. Invoke sistema bcc: /system/bin/bcc con un proveedor proporcionado por bcc plugin ; este plugin no puede depender de cualquier biblioteca de sistema que no está en la lista de RenderScript librerías disponibles para los vendedores .

Si el vendedor bcc plugin necesidades a interferir con la compilación de la CPU y su dependencia de libLLVM.so no se puede quitar fácilmente, el vendedor debe copiar bcc (y todas las dependencias de la no-LL-NDK, incluyendo libLLVM.so , libbcc.so ) en /vendor partición.

Además, los proveedores deben realizar los siguientes cambios:

Figura 8. Los cambios en controlador del proveedor
  1. Copiar libclcore.bc a /vendor partición. Esto asegura libclcore.bc , libLLVM.so , y libbcc.so están sincronizados.
  2. Cambiar la ruta de acceso al bcc ejecutable mediante el establecimiento de RsdCpuScriptImpl::BCC_EXE_PATH de la aplicación HAL RS.

Política de SELinux

La política de SELinux afecta tanto al controlador como a los ejecutables del compilador. Todos los módulos de los controladores deben estar etiquetados same_process_hal_file en el dispositivo de file_contexts . Por ejemplo:

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

El ejecutable compilador debe ser capaz de ser invocado por un proceso de aplicación, como lo hace la copia proveedor de bcc ( /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:

  1. PRODUCT_SHIPPING_API_LEVEL es inferior a 26.
  2. PRODUCT_FULL_TREBLE_OVERRIDE no está definido.

Para los dispositivos de legado, no se aplican las restricciones al actualizar a Android 8.0 y superior, es decir, los conductores pueden seguir un enlace a las bibliotecas en /system/lib[64] . Sin embargo, debido al cambio de la arquitectura relacionada con OVERRIDE_RS_DRIVER , android.hardware.renderscript@1.0-impl debe estar instalado a /vendor partición; si no lo hace, el tiempo de ejecución de RenderScript vuelve a la ruta de la CPU.

Para obtener información acerca de la motivación de la desaprobación renderScript, ver el Android Blog de desarrolladores: Android GPU Calcular ir adelante . La información de recursos para esta desaprobación incluye lo siguiente: