VIVE VR Rendering Performance Guía de usuario

Rendemento de renderización de realidade virtual
Axuste e optimizacións

Introdución

Conseguir unha experiencia de realidade virtual óptima en hardware con recursos limitados é fundamental para ofrecer unha experiencia de usuario fluída e cómoda. Se a taxa de fotogramas da renderización de contido cae ou é inestable por debaixo da taxa de actualización do dispositivo, isto provocará tremores e atrasos nos fotogramas, mareos, etc., o que acabará por afectar negativamente á experiencia do usuario. Polo tanto, optimizar o rendemento do contido é moi importante para garantir unha experiencia agradable.
Antes de comezar co axuste do rendemento, é importante comprender onde están os obstáculos para evitar un axuste ineficiente. Este documento está deseñado para axudar aos desenvolvedores a identificar os obstáculos e ofrecer solucións para resolver os problemas de renderización.
O documento está organizado nas seguintes seccións:

• Capítulo 2: Identificar o pescozo de botella: esta sección axuda aos desenvolvedores a identificar onde están os pescozos de botella.
• Capítulos 3 e 4: Configuración de VIVE Wave e VIVE OpenXR: nestas seccións descríbense configuracións específicas que poden afectar ao rendemento da CPU/GPU para as aplicacións de VIVE Wave e OpenXR. Os desenvolvedores poden experimentar coa activación ou desactivación destas funcións en función dos obstáculos de rendemento que atopen para determinar se hai algunha mellora.
• Capítulo 5: Optimización común: nesta sección móstranse algunhas prácticas e experiencias comúns de optimización.

Identificar o pescozo de botella

Cando o HMD está en movemento, se a aplicación VR/MR ten tremores de fotogramas ou bordos negros, etc., adoita deberse a un problema de rendemento de renderización deficiente. Normalmente, os problemas de rendemento de renderización pódense clasificar en 2 tipos: vinculados á CPU ou vinculados á GPU. Comprender que tipos de vinculación para a túa aplicación é moi importante ao principio para evitar un axuste ineficiente.
Neste capítulo, ofrecemos pasos sinxelos que che permiten identificar rapidamente onde están os problemas de rendemento.

2.1 Comprobar os FPS da renderización de contido
Primeiro, comezamos comprobando o FPS do contido, que é o número de fotogramas que o contido pode renderizar por segundo. Debe manterse na taxa de fotogramas da pantalla e estable. Se non, podería causar tremores nos fotogramas.
Se o SDK da túa aplicación usa o SDK VIVE WAVE 6.0.0 ou posterior, podes usar o seguinte comando adb para comprobar os FPS. DK 6.0.0
$adb Logcat -s VRMetric
Verás os seguintes datos de rexistro.
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» O primeiro número representa os FPS do contido, mentres que o segundo número representa a taxa de fotogramas da pantalla.
Se a versión do teu SDK de Wave é inferior á 6.0.0, recoméndase actualizar á última versión para mellorar o rendemento da renderización e outras optimizacións.
Se o SDK da túa aplicación foi compilado con VIVE OpenXR, podes usar o seguinte comando adb para comprobar os FPS.
$adb Logcat -s RENDER_ATW
Verás os seguintes datos de rexistro
RENDER_ATW: [FPS] nova textura:90.00
RENDER_ATW: [FPS] R presente:90.00 omitir:0 317, -0.0155 0.805527, 0.006788)
RENDER_ATW: [FPS] L presente:90.00 salto:0 (0.592301, -0.015502, 0.805539, 0.006773)

O número que segue a "nova textura" representa os FPS do contido actual. O número que segue a "R presente" e "L presente" representa a taxa de fotogramas da pantalla.
Ás veces, os FPS do contido e a taxa de fotogramas da pantalla poden ter unha lixeira discrepancia.
Por exampé dicir, no caso anterior, 89.8 FPS pódense considerar como 90 FPS.
Se o FPS do contido da aplicación é sistematicamente inferior á taxa de fotogramas da pantalla ou permanece inestable, indica un problema de rendemento de renderización. Polo tanto, o seguinte paso é identificar se o pescozo de botella provén da CPU ou da GPU.
2.2 Comprobar o uso da CPU e da GPU
Se o SDK da túa aplicación usa o SDK VIVE WAVE 6.0.0 ou posterior, podes usar o seguinte comando adb para comprobar os FPS.
$adb logcat -s VRMetric
Verás os seguintes datos de rexistro.
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 podes ver no resultado do rexistro anterior, o uso da CPU é do 27 % e o uso da GPU é do 72 %. Se a versión do teu SDK de Wave é inferior á 6.0.0, recoméndase actualizar á última versión para mellorar o rendemento da renderización e outras optimizacións.
Para a aplicación VIVE OpenXR, podes usar o seguinte comando para comprobar o uso da CPU e da GPU.
# en linux/ubuntu
$ adb logcat | grep USO_CPU
# en PowerShell
$ adb logcat | Seleccionar-cadea -Patrón CPU_USAGE
Verás o seguinte rexistro
Media da CPU CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 GPU USO_DA_CPU [CARGA] 25.67 % 32.22 % 25.29 % 30.77 % 29.35 % 21.35 % 22.09 % 18.39 % 24.14 % 73 %
Se observas que os FPS non poden manter a taxa de fotogramas da pantalla e que o uso da GPU tamén é moi alto, normalmente supera o 85 %, podes tentar axustar a Resolución do búfer de ollos (sección 3.1.2, sección 4.1.2) para ver se mellora os FPS. Se este axuste leva a unha mellor
rendemento, podemos concluír que o problema está ligado á GPU e centrar os nosos esforzos de optimización en consecuencia.
Por outra banda, se axustar a resolución do búfer de ollos non produce unha mellora notable no rendemento, é probable que o colo de botella estea limitado á CPU e deberiamos centrarnos en optimizar o rendemento da CPU.
Tamén é posible que a aplicación estea vinculada á CPU e á GPU simultaneamente. Nestes casos, os esforzos de optimización deberían aplicarse tanto á CPU como á GPU para lograr melloras de rendemento equilibradas.
2.3 Limitado á GPU
Cando unha aplicación de realidade virtual está vinculada á GPU, significa que a GPU é o principal obstáculo e non pode manterse ao día coas demandas de renderización da aplicación. Para mitigar os problemas vinculados á GPU, teña en conta as seguintes recomendacións:
Primeiro, usa ferramentas de creación de perfís como RenderDoc ou Game Engine profiler (Unity Profiler, Unreal Insights) para analizar onde a GPU pasa a maior parte do tempo. Identificar as operacións máis custosas e centrarse en optimizalas.
Para desenvolvedores nativos, podes usar RenderDoc para identificar que chamada de debuxo está a causar unha carga excesiva na GPU.
Para desenvolvedores de Unity, podes seguir este documento de Unity ou usar RenderDoc para analizar o problema de rendemento de renderización e seguir a documentación de optimización gráfica de Unity para obter orientación sobre como optimizar a túa aplicación.
Para Unreal Developer, podes usar GPU Visualizer ou RenderDoc para analizar o problema de rendemento de renderización e seguir as Directrices de rendemento de Unreal para obter orientación sobre como optimizar a túa aplicación.
En segundo lugar, tamén podes tentar axustar certas funcións ou configuracións de Wave para reducir a carga da GPU.

1. Definir a frecuencia de actualización da pantalla para que sexa máis lenta (sección 3.1.1, sección 4.1.1)
2.  Axustar a resolución do búfer ocular (sección 3.1.2, sección 4.1.2), 14.1.1)
3.  Tenta activar Foveation (sección 3.1.4, sección 4.1.4).

Se a túa aplicación tamén é unha aplicación MR, tamén podes axustar a configuración de Passthrough.

1. Axusta a calidade da imaxe de paso a través para abaixo. (sección 3.2.1)
2. Axusta a taxa de fotogramas de paso a través para que sexa máis lenta (sección 3.2.2).

Para obter máis información sobre a configuración do rendemento da GPU, podes consultar o Capítulo 2.6.

2.4 Limitado á CPU
Cando unha aplicación de realidade virtual está limitada á CPU, significa que a CPU é o principal colo de botella; teña en conta as seguintes recomendacións:
Primeiro, usa ferramentas de creación de perfís como Systrace ou Game Engine profiler (Unity Profiler, Unreal Insights) para analizar e identificar que partes do teu código están a consumir máis recursos de CPU. Céntrate en optimizar estas áreas e refactoriza algoritmos computacionalmente intensivos para reducir a carga da CPU.

• Para desenvolvedores nativos, podes usar Systrace para profesionais.fileo teu proxecto.
• Para Unity Developer, podes usar CPU Usage ProfileMódulo r para atopar problemas de rendemento da CPU.
• Para desenvolvedores de Unreal, podes usar Unreal's Insights para atopar problemas de rendemento da CPU.

En segundo lugar, tamén podes tentar axustar certas funcións ou configuracións de Wave para reducir a carga da GPU.

1. Definir a frecuencia de actualización da pantalla para que sexa máis lenta (sección 3.1.1, sección 4.1.1)
2.  Usar Multi-View Renderización (sección 3.1.4, sección 4.1.4)

Se a túa aplicación tamén é unha aplicación MR, tamén podes axustar a configuración de Passthrough.

1. Axusta a taxa de fotogramas de paso a través para que sexa máis lenta (sección 3.2.2).

Para obter máis información sobre a configuración do rendemento da CPU, podes consultar o Capítulo 2.6.

2.5 Resumo
Finalmente, organizamos o fluxo de traballo de comprobación do rendemento anterior na Figura 2-5-1. Comeza comprobando os FPS do contido. Se son inferiores á taxa de fotogramas da pantalla ou permanecen inestables, analiza o uso da GPU/CPU para determinar se está limitado á GPU ou á CPU. Por último, usa un profesional.filer para identificar posibles problemas de rendemento ou axustar as características ou a configuración de Wave para optimizar o rendemento da CPU.

2.6 Referencia rápida Que configuracións poden mellorar a carga da CPU/GPU

Enumera a configuración do SDK relacionada coa carga da CPU/GPU como se indica a continuación. Podes basearte no colo de botella da aplicación para comprobar a configuración de optimización relevante.

Relacionado coa CPU:

• Configuración do SDK de VIVE Wave
  contido de realidade virtual
  ▪ 3.1.1 Frecuencia de actualización da pantalla
  ▪ 3.1.4 Multi-View Renderizado
  ▪ 3.1.6 Calidade adaptativa
  ▪ 3.1.7 Compositor de movemento adaptativo
  o contido de MR
  ▪ 3.2.2 Axustar a taxa de fotogramas de paso a través
• Configuración do SDK de VIVE OpenXR
  contido de realidade virtual
  ▪ 4.1.1 Frecuencia de actualización da pantalla
  ▪ 4.1.4 Multi-View Renderizado
• Optimización común
  Pico de CPU de 5.5

Relacionado coa GPU:

• Configuración do SDK de VIVE Wave
  contido de realidade virtual
  ▪ 3.1.1 Frecuencia de actualización da pantalla
  ▪ 3.1.2 Resolución do búfer ocular
  ▪ 3.1.3 Multi-View Renderizado
  ▪ 3.1.4 Foveación
  ▪ 3.1.5 Mellora da nitidez do fotograma (FSE)
  ▪ 3.1.6 Calidade adaptativa
  ▪ 3.1.7 Compositor de movemento adaptativo
  ▪ 3.1.8 Render Mask [Not Support Unreal]
  o contido de MR
  ▪ 3.2.1 Axustar a calidade de paso a través
  ▪ 3.2.2 Axustar a taxa de fotogramas de paso a través
• Configuración do SDK de VIVE OpenXR
  contido de realidade virtual
  ▪ 4.1.1 Frecuencia de actualización da pantalla
  ▪ 4.1.2 Resolución do búfer ocular
  ▪ 4.1.3 Multi-View Renderizado
  ▪ 4.1.4 Foveation [Not Support Unreal]
  ▪ 4.1.5 Render Mask [Not Support Unreal]
• Optimización común
  5.1 Desactivar o modo de alto rendemento
  5.2 Multisampling
  o 5.3 Cargar/almacenar GMEM
  o 5.4 Capa de composición (multicapa)

Configuración de onda VIVE

VIVE Wave é unha plataforma aberta e un conxunto de ferramentas que che permite desenvolver contido de realidade virtual facilmente e proporciona optimización de dispositivos de alto rendemento para socios externos. VIVE Wave é compatible cos motores de xogos Unity e Unreal.
Optimizamos e resolvemos varios erros continuamente, polo que recomendamos manter o SDK actualizado.
Actualmente, VIVE Wave só admite OpenGL ES. Aquí enuméranse as características ordenadas segundo a súa influencia no rendemento da GPU. Dividirémolas en dúas partes: contido de realidade virtual e contido de realidade virtual.
3.1 Contido de realidade virtual
3.1.1 Frecuencia de actualización da pantalla

As taxas de actualización máis altas ofrecen imaxes máis suaves, pero teñen como consecuencia unha maior carga do sistema. Pola contra, as taxas de actualización máis baixas reducen a carga do sistema, pero resultan en imaxes menos suaves. Se a aplicación ten un problema coa CPU/GPU, podes tentar diminuír.asinaxustar a frecuencia de actualización da pantalla para aliviar o problema.

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

3.1.2 Resolución do búfer ocular
A resolución do búfer de ollos é o tamaño da textura coa que se renderizará o contido da aplicación. A textura renderizada enviarase ao tempo de execución para realizar o proceso de publicación e presentarase na pantalla HMD.
Aínda que un tamaño de búfer ocular maior pode resultar en imaxes máis nítidas e detalladas, tamén impón unha carga significativa na GPU. Polo tanto, atopar o equilibrio axeitado entre a calidade visual e o rendemento é esencial.
Se a aplicación ten un problema de vinculación á GPU, podes tentar diminuírasinmultiplicando o tamaño do búfer ocular por un factor de escala. Non obstante, recomendamos non reducir o factor de escala por debaixo de 0.7, xa que isto pode resultar nunha calidade visual inaceptable.

• Para desenvolvedores nativos, consulte WVR_ObtainTextureQueue. Ao axustar o tamaño, debe multiplicar o ancho e o alto por unha proporción.
• Para desenvolvedores de Unity, consulte WaveXRSettings.
  Alternativamente, podes facer cambios mediante o código que aparece a continuación.
  XRSettings.eyeTextureResolutionScale = ResolutionScaleValue; // C#
• Para desenvolvedores de Unreal, consulte SetPixelDensity.

3.1.3 Multi-View Renderizado
Na renderización tradicional, debuxamos os ollos esquerdo e dereito por separado, o que require dúas chamadas de debuxo para a mesma escena.View A renderización soluciona este problema realizando só unha chamada de debuxo.
Esta funcionalidade reduce a carga da CPU en decrementoasinaumentando o número de chamadas de debuxo. A GPU tamén ten algunhas vantaxes, a carga de traballo do sombreador de vértices tamén se reduce xa que non necesita executar un sombreador adicional para o outro ollo, pero a carga de traballo do sombreador de fragmentos permanece sen cambios xa que aínda necesita avaliar cada píxel para ambos os ollos. Recomendamos activar esta funcionalidade.

• Para desenvolvedores nativos, podes consultar wvr_native_hellovr.ample.
• Para desenvolvedores de Unity, consulte o Modo de renderización; unha única pasada é múltiple.view característica.
• Para desenvolvedores de Unreal, consulte esta guía.

3.1.4 Foveación
A renderización con fondo está deseñada principalmente para reducir a carga da GPU. Reduce o detalle do fotograma na periferia da pantalla e mantén o detalle de alta resolución no centro do campo de viewSe a aplicación ten un problema coa GPU, podes probar a renderización con Foveation.

Hai algo que cómpre ter en conta ao usar a foveación:

➢ Normalmente, os usuarios non notan a redución dos detalles nas rexións periféricas ao aplicar o modo de foveación predeterminado. Pero se a calidade periférica da foveación se define demasiado baixa, o usuario podería notala.
➢ Os efectos da foveación poden ser máis notorios con certos materiais ou texturas, o que podería chamar a atención do usuario. Os desenvolvedores deben ter en conta isto e avalialo en consecuencia.
➢ Activar a función de renderización con fondo de pantalla supón un custo fixo de rendemento da GPU, que pode variar entre o 1 % e o 6 % dependendo do tamaño do búfer do ollo. Ao usar un sombreador simple na escena, a ganancia de rendemento derivada do aforro de recursos pode ser inferior ao custo fixo de rendemento da GPU, o que provoca unha caída do rendemento.

• Para desenvolvedores nativos, consulte esta guía.
• Para desenvolvedores de Unity, consulte esta guía. É importante destacar que, cando activa o posprocesamento ou o HDR, a foveación non se pode utilizar plenamente porque Unity renderizará os obxectos na súa propia textura de renderización xerada, en lugar de na textura de renderización do presente xerado no tempo de execución que admite a foveación.
• Para desenvolvedores de Unreal, consulte esta guía. É importante salientar que a foveación non se pode utilizar totalmente en Multi-View Renderización, porque Unreal non pode renderizar obxectos directamente na textura de renderización xerada no tempo de execución que admite a foveación.

3.1.5 Mellora da nitidez do fotograma (FSE)
O FSE proporciona un resultado de renderización máis nítido mediante a introdución dun filtro de nitidez, o que pode facer que o contido sexa máis claro e ser bastante útil para mellorar a claridade do texto na escena. Se a aplicación ten un problema limitado á GPU, podes considerar desactivar o FSE se non é esencial.

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

3.1.6 Calidade adaptativa
Para aforrar batería e manter o rendemento de renderización do dispositivo, esta funcionalidade axusta automaticamente os niveis de rendemento do reloxo da CPU/GPU en función do seu uso. Ademais, pódense implementar outras estratexias para mellorar o rendemento, como activar/desactivar automaticamente Foveation ou que o contido se axuste por si mesmo se recibe eventos de carga alta/baixa.

• Para desenvolvedores nativos, consulte esta guía.
• Para desenvolvedores de Unity, consulte esta guía. No noso complemento de Unity, o tamaño do búfer ocular pódese axustar automaticamente en función do rendemento actual; o tamaño do texto filtrará os valores de escala que sexan demasiado pequenos na lista Resolución. Recomendamos texto cun tamaño de polo menos 20 dmm ou maior.
• Para desenvolvedores de Unreal, consulte esta guía.

3.1.7 Compositor de movemento adaptativo
Esta funcionalidade é experimental e inclúe UMC e PMC. A UMC reducirá a taxa de fotogramas á metade e extrapolará os novos fotogramas en tempo real para manter a fluidez visual. Non obstante, presenta certa latencia, artefactos e carga da GPU.
PMC usa principalmente o Depth Buffer para permitir que ATW teña en conta a tradución HMD, estendéndose a unha compensación de 6 dof. Esta característica pode reducir a latencia da tradución en 1~2 fotogramas, pero aumenta a carga da GPU.

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

3.1.8 Máscara de renderización [Non compatible con Unreal]
Os píxeles nos bordos vólvense case invisibles despois da distorsión, a máscara de renderizado modifica os valores do búfer de profundidade destes píxeles invisibles. Se activas as probas de profundidade, debido a z anticipada, estes píxeles invisibles non se renderizarán, o que reduce a carga da GPU. Esta función é útil se hai obxectos de renderizado con carga pesada nestas áreas invisibles; en caso contrario, se non hai obxectos de renderizado nestas áreas, recoméndase desactivala porque consumirá un pequeno uso da GPU.

• Para desenvolvedores nativos, consulte esta guía. Debe vincular o búfer de profundidade antes de chamar a RenderMask; se non, será ineficaz.
• Para desenvolvedores de Unity, consulte esta guía.
• Para desenvolvedores de Unreal, actualmente non é compatible coa función de máscara de renderización.

3.2 Contido de RM
3.2.1 Axustar a calidade de paso a través
Hai 3 niveis para a calidade da imaxe de paso a través:
➢ WVR_PassthroughImageQuality_DefaultMode: axeitado para o contido MR sen a demanda específica.
➢ WVR_PassthroughImageQuality_PerformanceMode: axeitado para contido MR que precisa máis recursos de GPU para a renderización de escenas virtuais.
➢ WVR_PassthroughImageQuality_QualityMode: axeitado para contido de RM que permite aos usuarios ver o entorno circundante con claridade, pero a escena virtual do contido debe ter un axuste máis fino para o rendemento.
Podes axustar a calidade de Passthrough a PerformanceMode para reducir o uso da GPU.

• Para desenvolvedores de Native, Uunity ou Unreal, consulte esta guía.

3.2.2 Axustar a taxa de fotogramas de paso a través
Do mesmo xeito que a frecuencia de actualización da pantalla, unha maior frecuencia de fotogramas de passthrough ofrece imaxes máis suaves, pero ten como consecuencia unha maior carga do sistema. Pola contra, as frecuencias de actualización máis baixas reducen a carga do sistema, pero dan lugar a imaxes menos suaves. Hai 2 modos de frecuencia de fotogramas de passthrough: Boost e Normal.

• Para desenvolvedores nativos, pode axustar a calidade do paso a través usando WVR_SetPassthroughImageRate.
• Para desenvolvedores de Unity, pode cambiar mediante código, por exemploampa configuración do ficheiro é a seguinte // C#
  Interop.WVR_SetPassthroughImageQuality(WVR_PassthroughImageQuality.PerformanceMode);
• Para o desenvolvedor de Unreal, o método de configuración véxase o nodo do plano na Figura 3-2-2.

Configuración de VIVE OpenXR

OpenXR é un estándar aberto que proporciona un conxunto común de API para desenvolver aplicacións XR que se executan nunha ampla gama de dispositivos de realidade virtual, desenvolvido por Khronos Group. VIVE Focus 3 e VIVE XR Elite tamén son compatibles con OpenXR. O SDK de VIVE OpenXR ofrece compatibilidade completa cos dispositivos HTC VR, o que permite aos desenvolvedores crear contido e todo en un con Unity e Unreal engine en dispositivos HTC VR. Optimizamos e resolvemos continuamente varios erros, polo que se recomenda que os desenvolvedores actualicen a versión FOTA dos seus dispositivos para mantelos actualizados. Actualmente, o SDK de VIVE OpenXR admite OpenGL ES e Vulkan.

4.1 Contido de realidade virtual
4.1.1 Frecuencia de actualización da pantalla
O concepto aquí é similar ao de 3.1.1 Frecuencia de actualización da pantalla.

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

4.1.2 Resolución do búfer ocular
O concepto aquí é similar ao de 3.1.2 Resolución do búfer ocular. Recomendamos non reducir o factor de escala por debaixo de 0.7, xa que isto pode resultar nunha calidade visual inaceptable.

• Para desenvolvedores nativos, consulte xrCreateSwapchain. Ao axustar o tamaño, debe multiplicar o ancho e o alto por unha proporción.
• Para desenvolvedores de Unity, consulte o seguinte exemploample // C#
  XRSettings.eyeTextureResolutionScale = 0.7f; //recomendado 1.0f~0.7f
• Para a configuración de Unreal, consulta esta guía.

4.1.3 Multi-View Renderizado
O concepto aquí é similar ao de 3.1.3 Multi-View Renderización. Esta funcionalidade reduce a carga da CPU; a GPU tamén ten algunhas vantaxes. Recomendamos activala.

• Para desenvolvedores nativos, KhronosGroup ofrece unha solución multifunción para OpenXRView examplei, consulte esta guía.
• Para desenvolvedores de Unity, consulte o Modo de renderización; unha única pasada é múltiple.view característica.
• Para desenvolvedores de Unreal, do mesmo xeito que coa configuración de VIVE Wave, consulte esta guía.

4.1.4 Foveación [Non compatible con Unreal]
O concepto aquí é similar ao de 3.1.4 Foveación. A renderización con foveación está deseñada principalmente para reducir a carga da GPU, pero activala incorrerá nun custo fixo de rendemento da GPU e, se a foveación se define demasiado baixa e se usan certos materiais ou texturas, pode chegar a ser moi...
perceptible para o usuario. Polo tanto, é aconsellable activar ou desactivar a funcionalidade segundo os seus requisitos específicos e consideracións de rendemento. Actualmente, a funcionalidade Foveated só é compatible con OpenGL ES no SDK de VIVE OpenXR.

• Para desenvolvedores nativos, esta funcionalidade está dispoñible, pero actualmente non hai ningunha versión.ampprodúcense os.
• Para desenvolvedores de Unity, consulte esta guía.
• Para os desenvolvedores de Unreal, esta funcionalidade non é compatible polo momento.

4.1.5 Máscara de renderización [Non compatible con Unreal]
O concepto aquí é similar ao de 3.1.8 Máscara de renderización.

• Para desenvolvedores nativos, use XrVisibilityMaskKHR para obter a malla. Antes de renderizar a escena, use esta malla para poboar os valores do búfer de profundidade antes de renderizar a escena.
• Para os desenvolvedores de Unity, a funcionalidade Máscara de renderización está activada por defecto para OpenGL ES e pódese desactivar co seguinte código; Vulkan non admite esta funcionalidade actualmente. //C# UnityEngine.XR.XRSettings.occlusionMaskScale = 0.0f;
• Para desenvolvedores de Unreal, actualmente non é compatible coa función de máscara de renderización.

4.2 Contido de RM
Actualmente, OpenXR non admite a configuración da calidade de paso e a taxa de fotogramas. Continuaremos a optimizar e corrixir a función de paso, polo que se recomenda que os desenvolvedores actualicen a versión FOTA do dispositivo para mantelo actualizado.

Optimización común

5.1 Desactivar o modo de alto rendemento
Desactivar o "Modo de alto rendemento" pode reducir o tamaño da pantalla do dispositivo, o que reduce o uso da GPU. O inconveniente é unha diminución da resolución da pantalla. Podes equilibrar a calidade e o rendemento para decidir se o activas ou non.
A localización da configuración para VIVE Focus 3 móstrase na Figura 5-1-1:

A localización da configuración para VIVE XR Elite móstrase na Figura 5-1-2:

5.2 VariosampLing Anti-Aliasing
MultisampLing é un anti-aliasinA técnica g empregada para suavizar os bordos irregulares adoita acelerarse mediante hardware, o que supón un custo no rendemento da GPU. Recomendamos non configurar un MSAA superior a 2x porque un valor máis alto consumirá máis uso da GPU.

• Para desenvolvedores nativos, MSAA OpenGL ES exsample pode referirse a isto; MSAA Vulkan exampler pode referirse a isto.
  A GPU Adreno proporciona unha extensión que optimiza o MSAA.
• Para desenvolvedores de Unity, consulte esta asociación.
• Para desenvolvedores de Unreal, consulte esta asociación. Unreal tamén ofrece antialias de posprocesamento.asing, consulta esta asociación.

5.3 Cargar/almacenar GMEM
Na arquitectura da GPU Adreno, existe unha funcionalidade pola que, ao vincular un destino de renderización, se este non se borra ou se invalida, cada vez que se produce a renderización, os valores do destino de renderización cárganse na memoria gráfica, o que se denomina carga de GMEM. Se os valores anteriores non son necesarios, borrar ou invalidar o destino de renderización antes da renderización pode evitar esta situación para mellorar o rendemento da GPU.
Podes evitar a carga de GMEM usando os seguintes métodos. En OpenGL ES, despois de vincular o FBO, podes chamar a glClear e glClearDepth para limpar o búfer de cor, profundidade e plantilla, ou chamar a glInvalidateFramebuffer para invalidar o obxectivo de renderización especificado. En Vulkan, non son necesarias instrucións adicionais; podes definir explicitamente se queres limpar o anexo antes do seu uso en VkAttachmentDescription.loadOp.
Do mesmo xeito, almacenar o resultado dunha renderización de mosaicos de volta á memoria principal desde a memoria gráfica chámase almacenamento GMEM; esta operación tamén é custosa para a GPU. Para evitar isto, recomendamos vincular só os obxectivos de renderización requiridos para evitar operacións de almacenamento innecesarias.

5.4 Capa de composición (multicapa)
As texturas que se mostran con Multi-Layer teñen unha mellor calidade visual. Non obstante, esta funcionalidade aumenta significativamente o rendemento da GPU co número de capas e o tamaño das texturas. Recomendamos non superar as tres capas.

• Para desenvolvedores nativos,
  O SDK de VIVE Wave usa WVR_SubmitFrameLayers para pasar datos de cada capa.
  O SDK de VIVE OpenXR coloca os datos de capa en XrFrameEndInfo e envíaos a través de xrEndFrame.
• Para desenvolvedores de Unity,
  Configuración do SDK de VIVE Wave, consulte esta guía,
  Para a configuración de VIVE OpenXR, consulte esta guía.
• Para o desenvolvedor de Unreal,
  Configuración do SDK de VIVE Wave, consulte esta guía.
  Para a configuración de VIVE OpenXR, consulte esta guía.

Pico de CPU de 5.5
Cando a carga da CPU é maior, algúns fíos de procesos en segundo plano teñen alta prioridade, o que pode interromper a execución nativa. Non podemos garantir que a aplicación de contido non sexa interrompida por outros fíos.
Se xorden estes problemas, podes tentar aumentarasinmodificando a prioridade do fío para ver se resolve o problema. Pero se cambias a configuración do fío para optimizala para os dispositivos, debes comprobar se isto ten algún impacto negativo.

• Para Unity Developer, consulta a funcionalidade de configuración de fíos de Android. Se estás a usar o SDK de VIVE Wave, temos unha funcionalidade en WaveXRSettings que che permite axustar a prioridade, como se mostra na Figura 5-5-2. O valor máis pequeno representa unha prioridade máis alta.

• Non hai método para cambiar o fío do xogo, o fío de renderizado e a prioridade do fío RHI a través de configuracións externas a menos que modifiques o código do motor.

Dereitos de autor © 2024 HTC Corporation. Todos os dereitos reservados.