Guía del usuario sobre el rendimiento de renderizado de VIVE VR

Rendimiento de renderizado de VR
Ajustes y optimizaciones

Introducción

Lograr una experiencia de realidad virtual óptima en hardware con recursos limitados es fundamental para ofrecer una experiencia de usuario fluida y cómoda. Si la velocidad de fotogramas de la renderización del contenido disminuye o se vuelve inestable por debajo de la frecuencia de actualización del dispositivo, se producirán vibraciones y tirones en los fotogramas, mareos, etc., lo que finalmente afectará negativamente la experiencia del usuario. Por lo tanto, optimizar el rendimiento del contenido es fundamental para garantizar una experiencia agradable.
Antes de comenzar a ajustar el rendimiento, es importante comprender dónde se encuentran los cuellos de botella para evitar un ajuste ineficiente. Este documento está diseñado para ayudar a los desarrolladores a identificar cuellos de botella y ofrecer soluciones para resolver los problemas de renderizado.
El documento está organizado en las siguientes secciones:

• Capítulo 2: Identificar el cuello de botella: esta sección ayuda a los desarrolladores a identificar dónde están los cuellos de botella.
• Capítulos 3 y 4: Configuración de VIVE Wave y VIVE OpenXR: Estas secciones describen ajustes específicos que pueden afectar el rendimiento de la CPU/GPU en las aplicaciones de VIVE Wave y OpenXR. Los desarrolladores pueden experimentar habilitando o deshabilitando estas funciones según los cuellos de botella de rendimiento detectados para determinar si se produce alguna mejora.
• Capítulo 5: Optimización común: esta sección comparte algunas prácticas y experiencias de optimización comunes.

Identificar el cuello de botella

Cuando el HMD se mueve, si la aplicación de VR/MR presenta inestabilidad de fotogramas o bordes negros, etc., generalmente se debe a un problema de rendimiento de renderizado deficiente. Normalmente, los problemas de rendimiento de renderizado se pueden clasificar en dos tipos: limitados por la CPU o limitados por la GPU. Comprender qué tipo de limitación afecta a tu aplicación es fundamental desde el principio para evitar un ajuste ineficiente.
En este capítulo, proporcionamos pasos simples que le permitirán identificar rápidamente dónde están los problemas de rendimiento.

2.1 Comprobar FPS de renderizado de contenido
Primero, verificamos los FPS del contenido, es decir, la cantidad de fotogramas por segundo que el contenido renderiza. Debe mantenerse estable y a la misma velocidad de fotogramas que la pantalla. De lo contrario, podría causar vibraciones.
Si el SDK de su aplicación utiliza VIVE WAVE SDK 6.0.0 o posterior, puede usar el siguiente comando adb para comprobar los FPS. DK 6.0.0
$adb Logcat -s VRMetric
Verá los siguientes datos de registro.
VRMetric:FPS=89.8/89.8,CPU-27/1,GPU=72/3,GpuBd=0,LrCnt=1,2Stag=1,Pstat=2,AQ=1,FOVED=0/0, FSE=1,TWS-2,PT=0(0), RndrBK=0,GLTA=2D,EB=1720×1720
“FPS=89.8/89.8” El primer número representa los FPS del contenido, mientras que el segundo número representa la velocidad de cuadros de la pantalla.
Si la versión de su Wave SDK es inferior a 6.0.0, se recomienda actualizar a la última versión para mejorar el rendimiento de renderizado y otras optimizaciones.
Si el SDK de su aplicación está compilado con VIVE OpenXR, puede usar el siguiente comando adb para comprobar los FPS.
$adb Logcat -s RENDER_ATW
Verá los siguientes datos de registro
RENDER_ATW: [FPS] nueva textura: 90.00
RENDER_ATW: [FPS] R presente: 90.00 salto: 0 317, -0.0155 0.805527, 0.006788)
RENDER_ATW: [FPS] L presente:90.00 saltar:0 (0.592301, -0.015502, 0.805539, 0.006773)

El número después de "nueva textura" representa los FPS del contenido actual. Los números después de "R presente" y "L presente" representan la velocidad de fotogramas de la pantalla.
A veces, los FPS del contenido y la velocidad de cuadros de la pantalla pueden tener una ligera discrepancia.
Por ejemploampEs decir, en el caso anterior, 89.8 FPS pueden considerarse como 90 FPS.
Si los FPS del contenido de la aplicación son constantemente inferiores a la velocidad de fotogramas de la pantalla o se mantienen inestables, esto indica un problema de rendimiento de renderizado. Por lo tanto, el siguiente paso es identificar si el cuello de botella proviene de la CPU o de la GPU.
2.2 Verificar el uso de la CPU y la GPU
Si el SDK de su aplicación utiliza VIVE WAVE SDK 6.0.0 o posterior, puede usar el siguiente comando adb para verificar los FPS.
$adb logcat -s VRMetric
Verá los siguientes datos de registro.
VRMetric:FPS=89.8/89.8,CPU=27/1,GPU=72/3,GpuBd=0,LrCnt=1,2Stag=1,Pstat=2,AQ=1,FOVED=0 /0, FSE=1,TWS=2,PT=0(0),RndrBK=0,GLTA=2D,EB=1720×1720
Como puede ver en el resultado del registro anterior, el uso de la CPU es del 27 % y el uso de la GPU es del 72 %. Si su versión de Wave SDK es inferior a 6.0.0, se recomienda actualizar a la última versión para mejorar el rendimiento de renderizado y otras optimizaciones.
Para la aplicación VIVE OpenXR, puede usar el siguiente comando para verificar el uso de CPU y GPU.
# en linux/ubuntu
$ adb logcat | grep USO_CPU
# en powershell
$ adb logcat | Select-String -Pattern USO_CPU
Verá el siguiente registro
Promedio de CPU CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 GPU USO DE CPU [CARGA] 25.67 % 32.22 % 25.29 % 30.77 % 29.35 % 21.35 % 22.09 % 18.39 % 24.14 % 73 %
Si observa que los FPS no pueden mantener la velocidad de fotogramas de la pantalla y el uso de la GPU también es muy alto, generalmente supera el 85%, puede intentar ajustar la Resolución del Buffer Ocular (sección 3.1.2, sección 4.1.2) para ver si mejora los FPS. Si este ajuste mejora...
En cuanto al rendimiento, podemos concluir que el problema está relacionado con la GPU y centrar nuestros esfuerzos de optimización en consecuencia.
Por otro lado, si ajustar la resolución del Eyebuffer no produce una mejora notable en el rendimiento, es probable que el cuello de botella esté limitado a la CPU y deberíamos centrarnos en optimizar el rendimiento de la CPU.
También es posible que la aplicación dependa simultáneamente de la CPU y la GPU. En tales casos, se deben optimizar tanto la CPU como la GPU para lograr mejoras de rendimiento equilibradas.
2.3 Limitado a la GPU
Cuando una aplicación de RV está limitada por la GPU, significa que esta es el principal cuello de botella y no puede satisfacer las demandas de renderizado de la aplicación. Para mitigar los problemas relacionados con la GPU, considere las siguientes recomendaciones:
Primero, use herramientas de creación de perfiles como RenderDoc o Game Engine Profiler (Unity Profiler, Unreal Insights) para analizar dónde invierte la GPU la mayor parte del tiempo. Identifique las operaciones más costosas y concéntrese en optimizarlas.
Para desarrolladores nativos, puedes usar RenderDoc para identificar qué llamada de dibujo está generando una carga excesiva en la GPU.
Para desarrolladores de Unity, pueden seguir este documento de Unity o usar RenderDoc para analizar problemas de rendimiento de renderizado y seguir la documentación de optimización de gráficos de Unity para obtener orientación para optimizar su aplicación.
Para Unreal Developer, puede usar GPU Visualizer o usar RenderDoc para analizar problemas de rendimiento de renderizado y seguir las Pautas de rendimiento de Unreal como guía para optimizar su aplicación.
En segundo lugar, también puedes intentar ajustar ciertas funciones o configuraciones de Wave para reducir la carga de la GPU.

1. Establecer una frecuencia de actualización de pantalla más lenta (sección 3.1.1, sección 4.1.1)
2.  Ajustar la resolución del búfer ocular (sección 3.1.2, sección 4.1.2), 14.1.1)
3.  Intente habilitar Foveation (sección 3.1.4, sección 4.1.4).

Si tu aplicación también es una aplicación MR, también puedes ajustar la configuración de Passthrough.

1. Ajuste la calidad de la imagen de paso a menor nivel. (sección 3.2.1)
2. Ajuste la velocidad de cuadros de paso a través más lenta (sección 3.2.2).

Para conocer más configuraciones sobre el rendimiento de la GPU, puede consultar el Capítulo 2.6.

2.4 Limitado por la CPU
Cuando una aplicación de VR está limitada por la CPU, significa que la CPU es el cuello de botella principal. Tenga en cuenta las siguientes recomendaciones:
En primer lugar, utilice herramientas de creación de perfiles como Systrace o Game Engine Pro.filer (Unity Profiler, Unreal Insights) para analizar e identificar qué partes de tu código consumen más recursos de CPU. Céntrate en optimizar estas áreas y refactoriza los algoritmos de alto consumo computacional para reducir la carga de CPU.

• Para desarrolladores nativos, puede utilizar Systrace para profiler tu proyecto.
• Para desarrolladores de Unity, puedes usar CPU Usage ProfileMódulo r para encontrar problemas de rendimiento de la CPU.
• Para desarrolladores de Unreal, pueden usar Unreal Insights para encontrar problemas de rendimiento de la CPU.

En segundo lugar, también puedes intentar ajustar ciertas funciones o configuraciones de Wave para reducir la carga de la GPU.

1. Establecer una frecuencia de actualización de pantalla más lenta (sección 3.1.1, sección 4.1.1)
2.  Utilice Multi-View Representación (sección 3.1.4, sección 4.1.4)

Si tu aplicación también es una aplicación MR, también puedes ajustar la configuración de Passthrough.

1. Ajuste la velocidad de cuadros de paso a través para que sea más lenta (sección 3.2.2).

Para obtener más información sobre el rendimiento de la CPU, puede consultar el Capítulo 2.6.

2.5 Resumen
Finalmente, hemos organizado el flujo de trabajo de verificación de rendimiento anterior en la Figura 2-5-1. Comience por verificar los FPS del contenido. Si es inferior a la velocidad de fotogramas de la pantalla o permanece inestable, analice el uso de la GPU/CPU para determinar si está limitado por la GPU o la CPU. Por último, utilice un profesionalfiler para identificar posibles problemas de rendimiento o ajustar las características o configuraciones de Wave para optimizar el rendimiento de la CPU.

2.6 Referencia rápida ¿Qué configuraciones pueden mejorar la carga de la CPU/GPU?

A continuación, se enumeran las configuraciones del SDK relacionadas con la carga de la CPU/GPU. Puede consultar el cuello de botella de la aplicación para verificar la configuración de optimización pertinente.

Relacionado con la CPU:

• Configuración del SDK de VIVE Wave
  o Contenido de VR
  ▪ 3.1.1 Frecuencia de actualización de la pantalla
  ▪ 3.1.4 Multi-View Representación
  ▪ 3.1.6 Calidad adaptativa
  ▪ 3.1.7 Compositor de movimiento adaptativo
  o Contenido de MR
  ▪ 3.2.2 Ajustar la velocidad de cuadros de paso
• Configuración del SDK de VIVE OpenXR
  o Contenido de VR
  ▪ 4.1.1 Frecuencia de actualización de la pantalla
  ▪ 4.1.4 Multi-View Representación
• Optimización común
  o 5.5 picos de CPU

Relacionado con la GPU:

• Configuración del SDK de VIVE Wave
  o Contenido de VR
  ▪ 3.1.1 Frecuencia de actualización de la pantalla
  ▪ 3.1.2 Resolución del búfer ocular
  ▪ 3.1.3 Multi-View Representación
  ▪ 3.1.4 Foveación
  ▪ 3.1.5 Mejora de la nitidez del fotograma (FSE)
  ▪ 3.1.6 Calidad adaptativa
  ▪ 3.1.7 Compositor de movimiento adaptativo
  ▪ 3.1.8 Render Mask [Not Support Unreal]
  o Contenido de MR
  ▪ 3.2.1 Ajustar la calidad de paso
  ▪ 3.2.2 Ajustar la velocidad de cuadros de paso
• Configuración del SDK de VIVE OpenXR
  o Contenido de VR
  ▪ 4.1.1 Frecuencia de actualización de la pantalla
  ▪ 4.1.2 Resolución del búfer ocular
  ▪ 4.1.3 Multi-View Representación
  ▪ 4.1.4 Foveation [Not Support Unreal]
  ▪ 4.1.5 Render Mask [Not Support Unreal]
• Optimización común
  o 5.1 Desactivar el modo de alto rendimiento
  o 5.2 Multisampabadejo
  o 5.3 Carga/Almacenamiento GMEM
  o 5.4 Capa de composición (Multicapa)

Configuración de onda VIVE

VIVE Wave es una plataforma abierta y un conjunto de herramientas que facilita el desarrollo de contenido de RV y ofrece optimización de dispositivos de alto rendimiento para socios externos. VIVE Wave es compatible con los motores de juego Unity y Unreal.
Optimizamos y resolvemos continuamente varios errores, por lo que recomendamos mantener el SDK actualizado.
Actualmente, VIVE Wave solo es compatible con OpenGL ES. Aquí se enumeran las características ordenadas según su impacto en el rendimiento de la GPU. Las dividiremos en dos partes: contenido de RV y contenido de RM.
3.1 Contenido de VR
3.1.1 Frecuencia de actualización de la pantalla

Higher refresh rates offer smoother visuals, but come at the cost of increased system load. Conversely, lower refresh rates reduce system load, but result in less smooth visuals. If App has CPU/GPU bound issue, you can try decreasing the display refresh rate to alleviate the issue.

• Para desarrolladores nativos, consulte WVR_SetFrameRate.
• Para desarrolladores de Unity, consulte esta guía.
• Para desarrolladores de Unreal, consulte esta guía.

3.1.2 Resolución del búfer ocular
La resolución del búfer ocular es el tamaño de la textura que tendrá el contenido de la aplicación que se renderizará. La textura renderizada se enviará al tiempo de ejecución para realizar el proceso de publicación y presentarse en la pantalla HMD.
Si bien un mayor tamaño del búfer ocular puede generar imágenes más nítidas y detalladas, también supone una carga significativa para la GPU. Por lo tanto, es fundamental encontrar el equilibrio adecuado entre calidad visual y rendimiento.
If App has GPU bound issue, you can try decreasing the eyebuffer size by multiply a scale factor. Howerver, we recommend not reducing the scale factor below 0.7, as this may result in unacceptable visual quality.

• Para desarrolladores nativos, consulte WVR_ObtainTextureQueue. Al ajustar el tamaño, debe multiplicar el ancho y la altura por una proporción.
• Para desarrolladores de Unity, consulte WaveXRSettings.
  Alternativamente, puede realizar cambios a través del código como se muestra a continuación.
  XRSettings.eyeTextureResolutionScale = ResolutionScaleValue; // C#
• Para desarrolladores de Unreal, consulte SetPixelDensity.

3.1.3 Multi-View Representación
En el renderizado tradicional, dibujamos los ojos izquierdo y derecho por separado, lo que requiere dos llamadas de dibujo para la misma escena.View La representación soluciona este problema realizando solo una llamada de dibujo.
This feature reduces CPU load by decreasing the number of draw calls. The GPU also has some benefits, vertex shader’s workload is also reduced as it doesn’t need to run an additional shader for the other eye, but the fragment shader’s workload remains  unchanged since it still needs to evaluate each pixel for both eyes. We recommand enabling this feature.

• Para desarrolladores nativos, puede consultar wvr_native_hellovr sampel.
• Para desarrolladores de Unity, consulte el modo de renderizado; una sola pasada es multi-view característica.
• Para desarrolladores de Unreal, consulte esta guía.

3.1.4 Foveación
El renderizado foveado está diseñado principalmente para reducir la carga de la GPU. Reduce el detalle del fotograma en la periferia de la pantalla y mantiene un detalle de alta resolución en el centro del campo. viewSi la aplicación tiene problemas con la GPU, puedes intentar habilitar la representación de Foveation.

Hay algunas cosas que debemos tener en cuenta al utilizar la foveación:

➢ Los usuarios no suelen notar la reducción de detalle en las regiones periféricas con el modo de foveación predeterminado. Sin embargo, si la calidad periférica de la foveación es demasiado baja, podría ser notoria.
➢ Los efectos de foveación pueden ser más notorios con ciertos materiales o texturas, lo que podría captar la atención del usuario. Los desarrolladores deben tener esto en cuenta y evaluarlo en consecuencia.
➢ La activación de la función de renderizado foveado implica un coste fijo de rendimiento de la GPU, que puede variar entre el 1 % y el 6 % según el tamaño del búfer ocular. Al usar un sombreador simple en la escena, la ganancia de rendimiento al ahorrar recursos podría ser inferior al coste fijo de rendimiento de la GPU, lo que resulta en una disminución del rendimiento.

• Para desarrolladores nativos, consulte esta guía.
• Para desarrolladores de Unity, consulte esta guía. Cabe destacar que, al habilitar el posprocesamiento o HDR, la foveación no se puede aprovechar al máximo. Esto se debe a que Unity renderiza los objetos en su propia textura de renderizado generada, en lugar de la textura de renderizado actual generada en tiempo de ejecución que admite la foveación.
• Para desarrolladores de Unreal, consulten esta guía. Cabe destacar que la foveación no se puede utilizar completamente en Multi-View Renderizado, porque Unreal no puede renderizar objetos directamente en la textura de renderizado generada en tiempo de ejecución que admite foveación.

3.1.5 Mejora de la nitidez del fotograma (FSE)
El FSE proporciona un resultado de renderizado más nítido mediante la introducción de un filtro de nitidez. Esto puede hacer que el contenido sea más claro y resulta muy útil para mejorar la claridad del texto en la escena. Si la aplicación tiene problemas de GPU, puede considerar deshabilitar el FSE si no es esencial.

• Para desarrolladores nativos, consulte esta guía.
• Para desarrolladores de Unity, consulte esta guía.
• Para desarrolladores de Unreal, consulte esta guía.

3.1.6 Calidad adaptativa
Para ahorrar batería y mantener el rendimiento de renderizado del dispositivo, esta función ajusta automáticamente el rendimiento de la CPU/GPU según su uso. Además, se pueden implementar otras estrategias para mejorar el rendimiento, como activar o desactivar automáticamente Foveation o que el contenido se ajuste automáticamente al recibir eventos de carga alta o baja.

• Para desarrolladores nativos, consulte esta guía.
• Para desarrolladores de Unity, consulte esta guía. En nuestro plugin de Unity, el tamaño del búfer de ojos se puede ajustar automáticamente según el rendimiento actual. El tamaño del texto filtrará los valores de escala demasiado pequeños en la lista de Resolución. Recomendamos un tamaño de texto de al menos 20 dmm o superior.
• Para desarrolladores de Unreal, consulte esta guía.

3.1.7 Compositor de movimiento adaptativo
Esta función es experimental e incluye UMC y PMC. UMC reducirá la velocidad de fotogramas a la mitad y extrapolará nuevos fotogramas en tiempo real para mantener la fluidez visual. Sin embargo, conlleva latencia, artefactos y carga de la GPU.
PMC utiliza principalmente el búfer de profundidad para que ATW tenga en cuenta la traducción del HMD y la amplíe hasta una compensación de 6 grados de libertad. Esta función puede reducir la latencia de traducción en 1 o 2 fotogramas, pero aumenta la carga de la GPU.

• Para desarrolladores nativos, consulte esta guía.
• Para desarrolladores de Unity, consulte esta guía.
• Para desarrolladores de Unreal, consulte esta guía.

3.1.8 Máscara de renderizado [No compatible con Unreal]
Los píxeles en los bordes se vuelven casi invisibles tras la distorsión; la máscara de renderizado modifica los valores del búfer de profundidad de estos píxeles invisibles. Si se activan las pruebas de profundidad, debido al factor z temprano, estos píxeles invisibles no se renderizarán, lo que reduce la carga de la GPU. Esta función es útil si hay objetos de renderizado con mucha carga en estas áreas invisibles; de lo contrario, si no hay objetos de renderizado en estas áreas, se recomienda desactivarla, ya que consumirá poca GPU.

• Para desarrolladores nativos, consulte esta guía. Debe vincular el búfer de profundidad antes de llamar a RenderMask; de lo contrario, no será efectivo.
• Para desarrolladores de Unity, consulte esta guía.
• Para los desarrolladores de Unreal, actualmente no es compatible con la función Máscara de renderizado.

3.2 Contenido de MR
3.2.1 Ajustar la calidad de paso
Hay 3 niveles de calidad de imagen de paso:
➢ WVR_PassthroughImageQuality_DefaultMode: adecuado para el contenido MR sin la demanda específica.
➢ WVR_PassthroughImageQuality_PerformanceMode: adecuado para el contenido MR que necesita más recursos de GPU para la renderización de escenas virtuales.
➢ WVR_PassthroughImageQuality_QualityMode: adecuado para el contenido de RM que permite a los usuarios ver el entorno circundante con claridad, pero la escena virtual del contenido debe tener un ajuste más preciso para el rendimiento.
Puede ajustar la calidad de Passthrough en PerformanceMode para reducir el uso de la GPU.

• Para desarrolladores nativos, de Unity o de Unreal, consulte esta guía.

3.2.2 Ajustar la velocidad de cuadros de paso
Al igual que la frecuencia de actualización de la pantalla, una mayor frecuencia de fotogramas de paso a través ofrece imágenes más fluidas, pero conlleva una mayor carga del sistema. Por el contrario, una frecuencia de actualización más baja reduce la carga del sistema, pero resulta en imágenes menos fluidas. Hay dos modos de frecuencia de fotogramas de paso a través: Boost y Normal.

• Para los desarrolladores nativos, pueden ajustar la calidad de transferencia mediante WVR_SetPassthroughImageRate.
• Para el desarrollador de Unity, puede cambiar mediante código, por ejemploampLas configuraciones son las siguientes // C#
  Interop.WVR_SetPassthroughImageQuality(WVR_PassthroughImageQuality.PerformanceMode);
• Para los desarrolladores de Unreal, el método de configuración consulta el nodo de plano en la Figura 3-2-2.

Configuración de VIVE OpenXR

OpenXR es un estándar abierto que proporciona un conjunto común de API para el desarrollo de aplicaciones XR compatibles con una amplia gama de dispositivos de VR, desarrollado por Khronos Group. VIVE Focus 3 y VIVE XR Elite también son compatibles con OpenXR. El SDK de VIVE OpenXR ofrece compatibilidad completa con dispositivos HTC VR, lo que permite a los desarrolladores crear aplicaciones todo en uno y contenido con Unity y Unreal Engine en dispositivos HTC VR. Optimizamos y solucionamos errores continuamente, por lo que recomendamos a los desarrolladores que actualicen la versión FOTA de sus dispositivos para mantenerla actualizada. Actualmente, el SDK de VIVE OpenXR es compatible con OpenGL ES y Vulkan.

4.1 Contenido de VR
4.1.1 Frecuencia de actualización de la pantalla
El concepto aquí es similar a 3.1.1 Frecuencia de actualización de pantalla.

• Para desarrolladores nativos, consulte XrEventDataDisplayRefreshRateChangedFB.
• Para desarrolladores de Unity, consulte esta guía.
• Para desarrolladores de Unreal, consulte esta guía.

4.1.2 Resolución del búfer ocular
El concepto aquí es similar a 3.1.2 Resolución del búfer ocular. Recomendamos no reducir el factor de escala por debajo de 0.7, ya que esto puede generar una calidad visual inaceptable.

• Para desarrolladores nativos, consulte xrCreateSwapchain. Al ajustar el tamaño, debe multiplicar el ancho y la altura por una proporción.
• Para desarrolladores de Unity, consulte el siguiente ejemploampel // C#
  XRSettings.eyeTextureResolutionScale = 0.7f; //recomendado 1.0f~0.7f
• Para la configuración de Unreal, consulte esta guía.

4.1.3 Multi-View Representación
El concepto aquí es similar al 3.1.3 Multi-View Renderizado. Esta función reduce la carga de la CPU. La GPU también ofrece algunas ventajas. Recomendamos habilitarla.

• Para los desarrolladores nativos, KhronosGroup ofrece un OpenXR Multi-View example, consulte esta guía.
• Para desarrolladores de Unity, consulte el modo de renderizado; una sola pasada es multi-view característica.
• Para los desarrolladores de Unreal, al igual que con la configuración de VIVE Wave, consulte esta guía.

4.1.4 Foveación [No compatible con Unreal]
El concepto aquí es similar al de 3.1.4 Foveación. El renderizado foveado está diseñado principalmente para reducir la carga de la GPU, pero habilitarlo implicará un coste fijo de rendimiento de la GPU y, si la foveación se establece demasiado baja y se utilizan ciertos materiales o texturas, puede volverse muy...
Es perceptible para el usuario. Por lo tanto, se recomienda habilitar o deshabilitar la función según sus requisitos específicos y consideraciones de rendimiento. Actualmente, la función Foveated solo es compatible con OpenGL ES en el SDK de VIVE OpenXR.

• Para los desarrolladores nativos, esta función está disponible, pero actualmente no hay exampSe proporcionan archivos.
• Para desarrolladores de Unity, consulte esta guía.
• Para los desarrolladores de Unreal, esta función no es compatible por el momento.

4.1.5 Máscara de renderizado [No compatible con Unreal]
El concepto aquí es similar a 3.1.8 Máscara de renderizado.

• Para desarrolladores nativos, use XrVisibilityMaskKHR para obtener la malla. Antes de renderizar la escena, use esta malla para rellenar los valores del búfer de profundidad.
• Para los desarrolladores de Unity, la función Máscara de renderizado está habilitada de manera predeterminada para OpenGL ES y se puede deshabilitar con el siguiente código; Vulkan actualmente no admite esta función. //C# UnityEngine.XR.XRSettings.occlusionMaskScale = 0.0f;
• Para los desarrolladores de Unreal, actualmente no es compatible con la función Máscara de renderizado.

4.2 Contenido de MR
OpenXR actualmente no permite configurar la calidad de transferencia ni la velocidad de fotogramas. Seguiremos optimizando y corrigiendo la función de transferencia, por lo que recomendamos a los desarrolladores que actualicen la versión de FOTA del dispositivo para mantenerla actualizada.

Optimización común

5.1 Desactivar el modo de alto rendimiento
Desactivar el "Modo de alto rendimiento" puede reducir el tamaño de la pantalla del dispositivo, lo que reduce el uso de la GPU. La desventaja es la disminución de la resolución de la pantalla. Puedes equilibrar la calidad y el rendimiento para decidir si lo activas.
La ubicación de configuración del VIVE Focus 3 se muestra en la Figura 5-1-1:

La ubicación de configuración de VIVE XR Elite se muestra en la Figura 5-1-2:

5.2 multisampling Anti-Aliasing
multisampling is an anti-aliasing technique used to smooth out jagged edges, usually is accelerated through hardware, which incurs GPU performance cost. We recommend not setting MSAA higher than 2x because more hight value will consume more gpu usage.

• Para desarrolladores nativos, MSAA OpenGL ES exsamppodemos referirnos a esto; MSAA Vulkan exampler puede referirse a esto.
  La GPU Adreno proporciona una extensión que optimiza MSAA.
• Para desarrolladores de Unity, consulte este gremio.
• For Unreal developer, refer to this guild. Unreal also has provide post processing anti-aliasing, refer to this guild.

5.3 Carga/Almacenamiento GMEM
En la arquitectura de GPU Adreno, existe una función que permite, al vincular un objetivo de renderizado, que si este no se borra ni se invalida, cada vez que se renderiza, sus valores se cargan en la memoria gráfica (carga GMEM). Si los valores anteriores no son necesarios, borrar o invalidar el objetivo de renderizado antes de renderizar puede evitar esta situación y mejorar el rendimiento de la GPU.
Puede evitar la carga de GMEM mediante los siguientes métodos. En OpenGL ES, tras enlazar el FBO, puede llamar a glClear y glClearDepth para borrar los búferes de color, profundidad y plantilla, o llamar a glInvalidateFramebuffer para invalidar el objetivo de renderizado especificado. En Vulkan, no se necesitan instrucciones adicionales; puede configurar explícitamente si desea borrar el archivo adjunto antes de usarlo en VkAttachmentDescription.loadOp.
De forma similar, almacenar el resultado de un renderizado de mosaicos desde la memoria gráfica a la memoria principal se denomina almacenamiento GMEM; esta operación también es costosa para la GPU. Para evitarlo, recomendamos vincular únicamente los objetivos de renderizado necesarios para evitar operaciones de almacenamiento innecesarias.

5.4 Capa de composición (Multicapa)
Las texturas mostradas con Multicapa tienen una mejor calidad visual. Sin embargo, esta función aumenta significativamente el rendimiento de la GPU con el número de capas y el tamaño de las texturas. Recomendamos no usar más de tres capas.

• Para desarrolladores nativos,
  o VIVE Wave SDK utiliza WVR_SubmitFrameLayers para pasar datos para cada capa.
  o VIVE OpenXR SDK coloca datos de capa en XrFrameEndInfo y los envía a través de xrEndFrame.
• Para desarrolladores de Unity,
  o Configuración del SDK de VIVE Wave, consulte esta guía,
  o Configuración de VIVE OpenXR, consulte esta guía.
• Para desarrolladores de Unreal,
  o Configuración del SDK de VIVE Wave, consulte esta guía.
  o Configuración de VIVE OpenXR, consulte esta guía.

5.5 picos de CPU
Cuando la carga de la CPU es mayor, algunos subprocesos de procesos en segundo plano con alta prioridad podrían interrumpir la ejecución nativa. No podemos garantizar que la aplicación de contenido no sea interrumpida por otro subproceso.
If such issues arise, you can try increasing the thread priority to see if it resolves the problem. But if you change the thread configuration to optimize for devices, you need to check if this has any negative impact.

• Para desarrolladores de Unity, consulte la función de configuración de subprocesos de Android. Si utiliza el SDK de VIVE Wave, disponemos de una función en WaveXRSettings que permite ajustar la prioridad, como se muestra en la Figura 5-5-2. Cuanto menor sea el valor, mayor será la prioridad.

• En Unreal, no existe ningún método para cambiar la prioridad del hilo del juego, del hilo de renderizado y del hilo RHI a través de configuraciones externas a menos que modifiques el código del motor.

Copyright © 2024 HTC Corporation. Todos los derechos reservados.