Arquitectura de la pantalla del hipervisor de Qualcomm
La imagen a continuación es el marco de visualización para el hipervisor de Qualcomm que se puede ver en el documento de Qualcomm, pero parece que no hay una introducción de documento relevante sobre cómo interactúan QNX y el lado de LA.
Recientemente, me encontré con algunos problemas relacionados con la pantalla. Aprovechando este estancamiento, investigué un poco sobre cómo los lados QNX y LA interactúan entre sí.
Análisis de los detalles de la arquitectura Hypervisor Display
La siguiente figura es un complemento a los detalles de la figura anterior.
1. Todas las llamadas relacionadas con la aplicación y la pantalla en el lado de Los Ángeles eventualmente serán manejadas por SurfaceFlinger
2. SurfaceFlinger eventualmente llamará al servicio [email protected]
3. El servicio [email protected] llamará a algunos archivos de biblioteca de Qcom (lamentablemente, el código fuente de estas bibliotecas no es de código abierto)
4. El archivo de biblioteca finalmente llama a la interfaz ioctl del controlador GPU HGSL en el lado LA
5. El controlador HGSL llamará a la interfaz de comunicación hab para comunicarse con el servicio wfd_be en el lado QNX
6. El servicio wfd_be analizará los paquetes de datos recibidos desde el lado LA
7. Llame a diferentes interfaces openwfd según el tipo de comando en el paquete de datos. Cabe señalar que la interfaz aquí se convierte. Por ejemplo, wfdEnumerateDevices_Host, esta interfaz en realidad llamará a la función wfdEnumerateDevices después de la conversión.
8. Una vez completadas todas las operaciones, si es necesario, activará el sitio commit&vsync de wfd_be y notificará a openwfd para actualizar la pantalla.
Un diagrama de bloques más detallado:
Suplemento de concepto relacionado
Acerca de las confirmaciones:
En OpenWFD u otros sistemas gráficos, el concepto de "compromiso" generalmente se refiere a aplicar una serie de cambios o actualizaciones al sistema gráfico, haciendo que estos cambios sean visibles en la pantalla.
Después de realizar una serie de cambios en el sistema, como cambiar las propiedades de los objetos gráficos o cambiar los comandos de dibujo, estos cambios se realizan en la memoria, pero no se reflejan inmediatamente en la pantalla. Esto se debe a que actualizar la pantalla inmediatamente hará que la pantalla se actualice con frecuencia, lo que consume una gran cantidad de recursos del sistema y puede hacer que la pantalla parpadee. Entonces puede hacer todos sus cambios en la memoria, y luego, cuando haya terminado con todos sus cambios, aplicarlos a la pantalla de una sola vez llamando a la operación "confirmar".
En OpenWFD, hay una función API llamada "wfdDeviceCommit", y su función es realizar esta operación de "confirmación". Cuando llame a esta función, se aplicarán todos los cambios anteriores en el dispositivo (como la configuración de las propiedades del dispositivo o el cambio del modo de puerto), y estos cambios serán visibles en la próxima actualización de la pantalla.
Este mecanismo de "confirmación" es común en muchos sistemas de gráficos, incluidos OpenWFD y Wayland, que utilizan este mecanismo para optimizar las actualizaciones de pantalla y reducir el uso de recursos.
Acerca de vsync:
"VSync" es un acrónimo de "Vertical Synchronization", una técnica comúnmente utilizada en gráficos por computadora para resolver problemas de desgarro de pantalla. El desgarro de pantalla ocurre cuando la unidad de procesamiento de gráficos (GPU) de la computadora genera una frecuencia de cuadro que excede la frecuencia de actualización del monitor, y las mitades superior e inferior de un cuadro se desincronizan, lo que hace que parezca que la imagen se está rasgando.
La tecnología V-Sync evita el desgarro de la pantalla al sincronizar la velocidad de salida de fotogramas de la GPU con la frecuencia de actualización del monitor. Específicamente, cuando VSync está habilitado, la GPU espera hasta que la pantalla complete una actualización vertical completa (actualizando todos los píxeles de arriba a abajo) antes de comenzar a renderizar el siguiente cuadro. Esto garantiza que solo se envíe un cuadro de datos a la pantalla cada vez que se actualice la pantalla, evitando que la pantalla se rompa.
Sin embargo, la sincronización vertical también tiene algunas desventajas. Dado que la GPU debe esperar a que la pantalla termine de actualizarse, esto puede hacer que el rendimiento de la GPU se subutilice si la GPU se procesa muy rápido. Además, si la velocidad de fotogramas de la GPU es menor que la frecuencia de actualización de la pantalla, el usuario puede experimentar un efecto de tartamudeo. Por lo tanto, habilitar la sincronización vertical y configurar la sincronización vertical a menudo depende de los requisitos específicos de la aplicación y el rendimiento del hardware.
En OpenWFD, puede haber API o configuraciones relacionadas para controlar la sincronización vertical, pero la implementación y el uso específicos pueden variar según las diferentes implementaciones y configuraciones de hardware de OpenWFD.