La señal VSYNC sincroniza la canalización de la pantalla. La pantalla incluye la renderización de apps, la composición de SurfaceFlinger y el hardware Composer (HWC) presenta imágenes en la pantalla. VSYNC sincroniza las hora a la que se activan las apps para comenzar a renderizarlas, la hora a la que se activa SurfaceFlinger compone la pantalla y el ciclo de actualización de pantalla. Esta sincronización elimina las interrupciones y mejora el rendimiento visual de los gráficos.
El HWC genera eventos VSYNC y los envía a SurfaceFlinger mediante la devolución de llamada:
typedef void (*HWC2_PFN_VSYNC)(hwc2_callback_data_t callbackData, hwc2_display_t display, int64_t timestamp);
SurfaceFlinger controla si el HWC genera eventos VSYNC o no
llamando a setVsyncEnabled. SurfaceFlinger habilita
setVsyncEnabled para generar eventos de VSYNC a fin de que se pueda sincronizar con
el ciclo de actualización de la pantalla. Cuando SurfaceFlinger se sincroniza con el
ciclo de actualización de la pantalla, SurfaceFlinger inhabilita setVsyncEnabled para
detener el HWC de generar eventos VSYNC. Si SurfaceFlinger detecta un
diferencia entre el VSYNC real y el que estableció anteriormente
SurfaceFlinger vuelve a habilitar la generación de eventos de VSYNC.
Compensación de VSYNC
La aplicación de sincronización y el renderizado de SurfaceFlinger se repiten en bucle VSYNC de hardware. En un evento VSYNC, la pantalla comienza a mostrar el marco N mientras SurfaceFlinger comienza a componer ventanas para el marco N + 1. La app controla entrada pendiente y genera el marco N+2.
La sincronización con VSYNC proporciona una latencia coherente. Reduce los errores en y SurfaceFlinger, y minimiza las pantallas que entran y salen de fase entre sí. Esto supone app y SurfaceFlinger por fotograma los tiempos no varían mucho. La latencia es de al menos dos fotogramas.
Para solucionar esto, puedes usar desplazamientos de VSYNC a fin de reducir la cantidad de entradas y salidas latencia haciendo que las señales de la app y de composición sean relativas al hardware VSYNC. Esto es posible porque la app y la composición suelen tardar menos a 33 ms.
El resultado del desplazamiento de VSYNC son tres señales con el mismo período y desplazamiento fase:
HW_VSYNC_0: La pantalla comienza a mostrar el siguiente fotograma.VSYNC: La app lee la entrada y genera el siguiente fotograma.SF_VSYNC: SurfaceFlinger comienza la composición para el siguiente fotograma.
Con el desplazamiento de VSYNC, SurfaceFlinger recibe el búfer y compone el fotograma mientras la app procesa y renderiza la entrada de forma simultánea del marco.
DispSync
DispSync mantiene un modelo de los eventos periódicos VSYNC basados en hardware de una y usa ese modelo para ejecutar devoluciones de llamada en una fase específica de los eventos de VSYNC de hardware.
DispSync es un bucle de bloqueo de fase (PLL) de software que genera Las señales VSYNC y SF_VSYNC que usan Choreographer y SurfaceFlinger, incluso si no se desplaza con el VSYNC de hardware.
Figura 1: Flujo de DispSync
DispSync tiene las siguientes características:
- Referencia: HW_VSYNC_0.
- Salida: VSYNC y SF_VSYNC.
- Comentarios: Retira las marcas de tiempo de los indicadores de valla del compositor de hardware.
Compensación de VSYNC/retirada
La marca de tiempo de la señal de las vallas de retiro debe coincidir con HW VSYNC, incluso en dispositivos. que no usan la fase de compensación. De lo contrario, los errores parecen ser más graves de lo que son. Los paneles inteligentes suelen tener un delta en el que la valla de retiro es el final de acceso directo a la memoria (DMA) para mostrar la memoria, pero el interruptor y HW VSYNC llega después.
PRESENT_TIME_OFFSET_FROM_VSYNC_NS se establece en el
Archivo makefile BoardConfig.mk. Se basa en el panel y el controlador de la pantalla.
del usuario. El tiempo desde la marca de tiempo de valla de retiro hasta HW VSYNC
se mide en nanosegundos.
Compensaciones de VSYNC y SF_VSYNC
VSYNC_EVENT_PHASE_OFFSET_NS y
Las SF_VSYNC_EVENT_PHASE_OFFSET_NS se configuran de forma conservadora en función de
casos de uso de carga alta, como la composición parcial de GPU durante la transición de ventanas
o que Chrome se desplace por una página web que contenga animaciones. Estas compensaciones
permiten un tiempo prolongado de renderización de la app y de composición de GPU.
Se nota más de uno o dos milisegundos de latencia. Para minimizar la latencia sin aumentar significativamente la cantidad de errores, integre una integración completa y pruebas.