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

Marco de sincronización

Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

El marco de sincronización describe explícitamente las dependencias entre diferentes operaciones asincrónicas en el sistema de gráficos de Android. El marco proporciona una API que permite que los componentes indiquen cuándo se liberan los búferes. El marco también permite que se pasen primitivas de sincronización entre controladores desde el kernel al espacio de usuario y entre los propios procesos del espacio de usuario.

Por ejemplo, una aplicación puede poner en cola el trabajo que se realizará en la GPU. La GPU comienza a dibujar esa imagen. Aunque la imagen aún no se ha dibujado en la memoria, el puntero del búfer se pasa al compositor de la ventana junto con una valla que indica cuándo terminará el trabajo de la GPU. El compositor de ventanas comienza a procesar antes de tiempo y pasa el trabajo al controlador de pantalla. De manera similar, el trabajo de la CPU se realiza con anticipación. Una vez que la GPU finaliza, el controlador de pantalla muestra inmediatamente la imagen.

El marco de sincronización también permite a los implementadores aprovechar los recursos de sincronización en sus propios componentes de hardware. Finalmente, el marco brinda visibilidad en la canalización de gráficos para ayudar con la depuración.

Sincronización explícita

La sincronización explícita permite a los productores y consumidores de búferes de gráficos señalar cuando han terminado de usar un búfer. La sincronización explícita se implementa en el espacio del núcleo.

Los beneficios de la sincronización explícita incluyen:

  • Menos variación de comportamiento entre dispositivos
  • Mejor soporte de depuración
  • Métricas de prueba mejoradas

El marco de sincronización tiene tres tipos de objetos:

  • sync_timeline
  • sync_pt
  • sync_fence

sincronizar_cronología

sync_timeline es una línea de tiempo que aumenta de forma monótona que los proveedores deben implementar para cada instancia de controlador, como un contexto GL, controlador de pantalla o blitter 2D. sync_timeline cuenta los trabajos enviados al kernel para una determinada pieza de hardware. sync_timeline proporciona garantías sobre el orden de las operaciones y permite implementaciones específicas de hardware.

Siga estas pautas cuando implemente sync_timeline :

  • Proporcione nombres útiles para todos los controladores, escalas de tiempo y vallas para simplificar la depuración.
  • Implemente los operadores timeline_value_str y pt_value_str en las líneas de tiempo para que la salida de depuración sea más legible.
  • Implemente el relleno driver_data para brindar a las bibliotecas de espacio de usuario, como la biblioteca GL, acceso a datos privados de la línea de tiempo, si lo desea. data_driver permite a los proveedores pasar información sobre sync_fence y sync_pts inmutables para construir líneas de comando basadas en ellos.
  • No permita que el espacio de usuario cree o señale explícitamente una valla. La creación explícita de señales/vallas da como resultado un ataque de denegación de servicio que detiene la funcionalidad de la canalización.
  • No acceda explícitamente a los elementos sync_timeline , sync_pt o sync_fence . La API proporciona todas las funciones requeridas.

sincronizar_pt

sync_pt es un único valor o punto en sync_timeline . Un punto tiene tres estados: activo, señalado y error. Los puntos comienzan en el estado activo y pasan a los estados señalados o de error. Por ejemplo, cuando un consumidor de imágenes ya no necesita un búfer, se señala un sync_pt para que un productor de imágenes sepa que está bien escribir en el búfer nuevamente.

sincronización_valla

sync_fence es una colección de valores de sync_pt que a menudo tienen diferentes padres de sync_timeline (como para el controlador de pantalla y la GPU). sync_fence , sync_pt y sync_timeline son las principales primitivas que utilizan los controladores y el espacio de usuario para comunicar sus dependencias. Cuando se señala una valla, se garantiza que todos los comandos emitidos antes de la valla estén completos porque el controlador del kernel o el bloque de hardware ejecuta los comandos en orden.

El marco de sincronización permite que múltiples consumidores o productores señalen cuando han terminado de usar un búfer, comunicando la información de dependencia con un parámetro de función. Las vallas están respaldadas por un descriptor de archivo y se pasan del espacio del kernel al espacio del usuario. Por ejemplo, una valla puede contener dos valores sync_pt que indican cuándo dos consumidores de imágenes separados han terminado de leer un búfer. Cuando se señala la valla, los productores de imágenes saben que ambos consumidores han terminado de consumir.

Las cercas, como los valores de sync_pt , comienzan activas y cambian de estado según el estado de sus puntos. Si todos los valores de sync_pt se señalizan, sync_fence se señaliza. Si un sync_pt cae en un estado de error, todo el sync_fence tiene un estado de error.

La pertenencia a sync_fence es inmutable después de crear la valla. Para obtener más de un punto en una cerca, se lleva a cabo una combinación donde los puntos de dos cercas distintas se agregan a una tercera cerca. Si uno de esos puntos estaba señalizado en la valla de origen y el otro no, la tercera valla tampoco estará en estado señalizado.

Para implementar la sincronización explícita, proporcione lo siguiente:

  • Un subsistema de espacio de kernel que implementa el marco de sincronización para un controlador de hardware en particular. Los controladores que deben tener en cuenta las vallas son generalmente cualquier cosa que acceda o se comunique con el Compositor de hardware. Los archivos clave incluyen:
    • Implementación básica:
      • kernel/common/include/linux/sync.h
      • kernel/common/drivers/base/sync.c
    • Documentación en kernel/common/Documentation/sync.txt
    • Biblioteca para comunicarse con el espacio del núcleo en platform/system/core/libsync
  • El proveedor debe proporcionar las vallas de sincronización apropiadas como parámetros para las funciones validateDisplay() y presentDisplay() en la HAL.
  • Dos extensiones GL relacionadas con vallas ( EGL_ANDROID_native_fence_sync y EGL_ANDROID_wait_sync ) y compatibilidad con vallas en el controlador de gráficos.

Estudio de caso: Implementación de un controlador de pantalla

Para usar la API compatible con la función de sincronización, desarrolle un controlador de pantalla que tenga una función de búfer de pantalla. Antes de que existiera el marco de sincronización, esta función recibiría objetos dma-buf , colocaría esos búfer en la pantalla y bloquearía mientras el búfer estuviera visible. Por ejemplo:

/*
 * assumes buffer is ready to be displayed.  returns when buffer is no longer on
 * screen.
 */
void display_buffer(struct dma_buf *buffer);

Con el marco de sincronización, la función display_buffer es más compleja. Al exhibir un búfer, el búfer se asocia con una cerca que indica cuándo estará listo el búfer. Puede hacer cola e iniciar el trabajo después de que se despeje la cerca.

Hacer cola e iniciar el trabajo después de que se despeja la cerca no bloquea nada. Inmediatamente devuelve su propia valla, lo que garantiza cuándo el búfer estará fuera de la pantalla. A medida que pone en cola los búferes, el núcleo enumera las dependencias con el marco de sincronización:

/*
 * displays buffer when fence is signaled.  returns immediately with a fence
 * that signals when buffer is no longer displayed.
 */
struct sync_fence* display_buffer(struct dma_buf *buffer, struct sync_fence
*fence);

Integración de sincronización

Esta sección explica cómo integrar el marco de trabajo de sincronización del espacio del kernel con las partes del espacio de usuario del marco de trabajo de Android y los controladores que deben comunicarse entre sí. Los objetos del espacio del kernel se representan como descriptores de archivo en el espacio del usuario.

Convenciones de integración

Siga las convenciones de la interfaz HAL de Android:

  • Si la API proporciona un descriptor de archivo que hace referencia a un sync_pt , el controlador del proveedor o la HAL que usa la API deben cerrar el descriptor de archivo.
  • Si el controlador del proveedor o la HAL pasan un descriptor de archivo que contiene un sync_pt a una función API, el controlador del proveedor o la HAL no deben cerrar el descriptor de archivo.
  • Para continuar utilizando el descriptor de archivo de vallas, el controlador del proveedor o el HAL deben duplicar el descriptor.

Se cambia el nombre de un objeto de valla cada vez que pasa por BufferQueue. La compatibilidad con cercas del núcleo permite que las cercas tengan cadenas para los nombres, por lo que el marco de sincronización usa el nombre de la ventana y el índice del búfer que se pone en cola para nombrar la cerca, como SurfaceView:0 . Esto es útil en la depuración para identificar la fuente de un interbloqueo, ya que los nombres aparecen en la salida de /d/sync y en los informes de errores.

Integración de ANativeWindow

ANativeWindow es consciente de las vallas. dequeueBuffer , queueBuffer y cancelBuffer tienen parámetros de valla.

Integración con OpenGL ES

La integración de sincronización de OpenGL ES se basa en dos extensiones EGL:

  • EGL_ANDROID_native_fence_sync proporciona una manera de encapsular o crear descriptores de archivos de vallas nativos de Android en objetos EGLSyncKHR .
  • EGL_ANDROID_wait_sync permite paradas del lado de la GPU en lugar de del lado de la CPU, lo que hace que la GPU espere EGLSyncKHR . La extensión EGL_ANDROID_wait_sync es la misma que la extensión EGL_KHR_wait_sync .

Para utilizar estas extensiones de forma independiente, implemente la extensión EGL_ANDROID_native_fence_sync junto con la compatibilidad con el kernel asociado. A continuación, habilite la extensión EGL_ANDROID_wait_sync en su controlador. La extensión EGL_ANDROID_native_fence_sync consta de un tipo de objeto EGLSyncKHR de valla nativo distinto. Como resultado, las extensiones que se aplican a los tipos de objetos EGLSyncKHR existentes no se aplican necesariamente a los objetos EGL_ANDROID_native_fence , lo que evita interacciones no deseadas.

La extensión EGL_ANDROID_native_fence_sync emplea un atributo de descriptor de archivo de valla nativo correspondiente que se puede configurar solo en el momento de la creación y no se puede consultar directamente desde un objeto de sincronización existente. Este atributo se puede establecer en uno de dos modos:

  • Un descriptor de archivo de valla válido envuelve un descriptor de archivo de valla nativo de Android existente en un objeto EGLSyncKHR .
  • -1 crea un descriptor de archivo de cerca nativo de Android a partir de un objeto EGLSyncKHR .

Utilice la llamada a la función DupNativeFenceFD() para extraer el objeto EGLSyncKHR del descriptor de archivo de cerca nativo de Android. Esto tiene el mismo resultado que consultar el atributo establecido, pero se adhiere a la convención de que el destinatario cierra la cerca (de ahí la operación de duplicado). Finalmente, al destruir el objeto EGLSyncKHR se cierra el atributo de valla interna.

Integración del compositor de hardware

El compositor de hardware maneja tres tipos de vallas de sincronización:

  • Los setLayerBuffer y setClientTarget . Estos representan una escritura pendiente en el búfer y deben enviar una señal antes de que SurfaceFlinger o HWC intente leer del búfer asociado para realizar la composición.
  • Las vallas de liberación se recuperan después de la llamada a presentDisplay mediante la llamada getReleaseFences . Estos representan una lectura pendiente del búfer anterior en la misma capa. Una valla de liberación señala cuando el HWC ya no está usando el búfer anterior porque el búfer actual ha reemplazado al búfer anterior en la pantalla. Los límites de liberación se devuelven a la aplicación junto con los búferes anteriores que se reemplazarán durante la composición actual. La aplicación debe esperar hasta que una valla de liberación señale antes de escribir nuevos contenidos en el búfer que se les devolvió.
  • Se devuelven vallas presentes , una por fotograma, como parte de la llamada a presentDisplay . Las vallas presentes representan cuando la composición de este marco ha finalizado, o alternativamente, cuando ya no se necesita el resultado de la composición del marco anterior. Para pantallas físicas, presentDisplay devuelve vallas presentes cuando el marco actual aparece en la pantalla. Una vez que se devuelven las vallas actuales, es seguro volver a escribir en el búfer de destino de SurfaceFlinger, si corresponde. Para las pantallas virtuales, las vallas presentes se devuelven cuando es seguro leerlas desde el búfer de salida.