Referencia de estructura vr_module

Referencia de estructura vr_module

#include < vr.h >

Campos de información

estructura hw_module_t común
vacío(* inicio )(struct vr_module *módulo)
vacío(* set_vr_mode )(struct vr_module *módulo, bool habilitado)
vacío * reservado [8-2]

Descripción detallada

Implemente este HAL para recibir devoluciones de llamadas cuando se utilice una aplicación de realidad virtual (VR). Las aplicaciones de realidad virtual se caracterizan por tener una serie de requisitos especiales de visualización y rendimiento, que incluyen:

  • Baja latencia del sensor: la latencia total de extremo a extremo desde la IMU, el acelerómetro y el giroscopio hasta una devolución de llamada visible en la aplicación debe ser extremadamente baja (normalmente <5 ms). Esto es necesario para la compatibilidad con sensores HIFI.
  • Latencia de visualización baja: la latencia total de un extremo a otro desde las llamadas de extracción de la GPU hasta la actualización de la pantalla real debe ser lo más baja posible. Esto se logra usando SurfaceFlinger en un modo de búfer único y asegurando que las llamadas de extracción se sincronicen correctamente con la exploración de la pantalla. Este comportamiento se expone a través de una extensión EGL para las aplicaciones. Consulte a continuación las extensiones EGL necesarias para esto.
  • Pantalla de baja persistencia: la configuración de persistencia de la pantalla debe establecerse lo más baja posible y al mismo tiempo mantener un brillo razonable. Para una pantalla típica que funciona a 60 Hz, los píxeles deben iluminarse durante <= 3,5 ms para que se consideren de baja persistencia. Esto evita las imágenes fantasma durante los movimientos en una configuración de realidad virtual y debe habilitarse desde las luces.h HAL cuando se establece BRIGHTNESS_MODE_LOW_PERSISTENCE.
  • Rendimiento constante de la GPU y la CPU: cuando se le asigna una carga de trabajo mixta de GPU/CPU para una aplicación de realidad virtual con ráfagas de trabajo a intervalos regulares varias veces por cuadro, la programación de la CPU debe garantizar que el trabajo del subproceso de procesamiento de la aplicación se ejecute de manera consistente dentro de 1 ms de cuando programado y completado antes del final de la ventana de sorteo. Con este fin, se debe reservar un único núcleo de CPU únicamente para el subproceso de procesamiento de la aplicación de realidad virtual que se está ejecutando actualmente mientras está en modo de realidad virtual, y debe estar disponible en el conjunto de CPU de la "aplicación superior". Del mismo modo, se debe mantener una CPU, GPU y velocidad de reloj de bus adecuadas para garantizar que la carga de trabajo de renderizado finalice dentro del tiempo asignado para renderizar cada fotograma cuando el indicador POWER_HINT_SUSTAINED_PERFORMANCE se ha configurado en power.h HAL mientras está en modo VR cuando el dispositivo está no estar estrangulado térmicamente.
  • Las extensiones EGL requeridas deben estar presentes: se requiere cualquier configuración de GPU necesaria para permitir las capacidades anteriores, incluidas las extensiones EGL: EGL_ANDROID_create_native_client_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_EXT_protected_content, EGL_KHR_mutable_render_buffer, EGL_KHR_reusable_sync y EGL_KHR_wait_sync.
  • Informes térmicos precisos: las temperaturas y límites térmicos precisos deben informarse en el HAL térmico.h . Específicamente, la temperatura actual de la piel debe informarse con precisión para DEVICE_TEMPERATURE_SKIN y el vr_throttling_threshold informado para este dispositivo debe informar con precisión el límite de temperatura por encima del cual el regulador térmico del dispositivo acelera la CPU, la GPU y/o las velocidades de reloj del bus por debajo del mínimo necesario para un rendimiento constante ( ver el punto anterior).

En general, se espera que los proveedores que implementan este HAL utilicen set_vr_mode como sugerencia para habilitar el ajuste de rendimiento específico de la realidad virtual necesario para cualquiera de los requisitos anteriores y para activar cualquier característica óptima del dispositivo para los modos de visualización de la realidad virtual. Es posible que la llamada set_vr_mode simplemente no haga nada si no hay optimizaciones disponibles o necesarias para cumplir con los requisitos anteriores.

No se llamará ningún método en este HAL simultáneamente desde el marco de trabajo de Android.

Definición en la línea 82 del archivo vr.h.

Documentación de campo

estructura hw_module_t común

Métodos comunes del módulo. Este debe ser el primer miembro de vr_module ya que los usuarios de esta estructura pueden convertir un hw_module_t a un puntero vr_module en contextos donde se sabe que hw_module_t hace referencia a un vr_module .

Definición en la línea 89 del archivo vr.h.

void(* inicio)(struct vr_module *módulo)

Método conveniente para que la implementación HAL configure cualquier estado necesario al inicio del tiempo de ejecución. Esto se llama una vez desde VrManagerService durante su fase de inicio. No se llamará ningún método de este HAL antes del inicio.

Definición en la línea 96 del archivo vr.h.

nulo* reservado[8-2]

Definición en la línea 110 del archivo vr.h.

void(* set_vr_mode)(struct vr_module *módulo, bool habilitado)

Establezca el estado del modo VR. Los posibles estados del parámetro habilitado son: falso: el modo VR está deshabilitado, desactive todas las configuraciones específicas de VR. verdadero: el modo VR está habilitado, active todas las configuraciones específicas de VR.

Esto se llama cada vez que el sistema Android entra o sale del modo VR. Esto suele ocurrir cuando el usuario cambia hacia o desde una aplicación de realidad virtual que realiza renderizado estereoscópico.

Definición en la línea 107 del archivo vr.h.


La documentación para esta estructura se generó a partir del siguiente archivo:
  • hardware/libhardware/include/hardware/ vr.h