Rendiment de renderització de realitat virtual
Afinació i optimitzacions

Introducció

Aconseguir una experiència de realitat virtual òptima en maquinari amb recursos limitats és clau per oferir una experiència d'usuari fluida i còmoda. Si la freqüència d'imatges del renderitzat del contingut baixa o és inestable per sota de la freqüència d'actualització del dispositiu, això provocarà tremolors i entrebancs dels fotogrames, mareig, etc., que finalment afectaran negativament l'experiència de l'usuari. Per tant, optimitzar el rendiment del contingut és molt important per garantir una experiència agradable.
Abans de començar l'ajustament del rendiment, és important entendre on són els colls d'ampolla del rendiment per evitar un ajust ineficient. Aquest document està dissenyat per ajudar els desenvolupadors a identificar els colls d'ampolla del rendiment i oferir solucions per resoldre els problemes de rendiment del renderitzat.
El document s'organitza en les següents seccions:

• Capítol 2: Identificar el coll d'ampolla: aquesta secció ajuda els desenvolupadors a identificar on es troben els colls d'ampolla.
• Capítols 3 i 4: Configuració del VIVE Wave i del VIVE OpenXR: aquestes seccions descriuen configuracions específiques que poden afectar el rendiment de la CPU/GPU per a les aplicacions del VIVE Wave i OpenXR. Els desenvolupadors poden experimentar amb l'activació o la desactivació d'aquestes funcions en funció dels colls d'ampolla de rendiment que trobin per determinar si hi ha alguna millora.
• Capítol 5: Optimització comuna: aquesta secció comparteix algunes pràctiques i experiències comunes d'optimització.

Identifica el coll d'ampolla

Quan HMD està en moviment, si l'aplicació VR/MR té tremolors de fotogrames o vores negres, etc., normalment és degut a un problema de rendiment de renderització deficient. Normalment, els problemes de rendiment de renderització es poden classificar en 2 tipus: vinculats a la CPU o vinculats a la GPU. Entendre quins tipus de vinculació per a la teva aplicació és molt important al principi per evitar un ajust ineficient.
En aquest capítol, proporcionem passos senzills que us permeten identificar ràpidament on són els problemes de rendiment.

2.1 Comprovar els FPS de renderització de contingut
Primer, comencem comprovant els FPS del contingut, és a dir, el nombre de fotogrames que el contingut pot renderitzar per segon. S'ha de mantenir a la velocitat de fotogrames de la pantalla i estable. En cas contrari, podria causar tremolors dels fotogrames.
Si el vostre SDK d'aplicació utilitza el VIVE WAVE SDK 6.0.0 o posterior, podeu utilitzar l'ordre adb següent per comprovar els FPS. DK 6.0.0
$adb Logcat -s VRMetric
Veureu les dades de registre següents.
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 els FPS del contingut, mentre que el segon número representa la freqüència d'imatges de la pantalla.
Si la versió del vostre SDK de Wave és inferior a la 6.0.0, es recomana actualitzar-lo a la darrera versió per millorar el rendiment de renderització i altres optimitzacions.
Si el SDK de la vostra aplicació s'ha creat amb VIVE OpenXR, podeu utilitzar l'ordre adb següent per comprovar els FPS.
$adb Logcat -s RENDER_ATW
Veureu les dades de registre següents
RENDER_ATW: [FPS] nova textura: 90.00
RENDER_ATW: [FPS] R present:90.00 ometre:0 317, -0.0155 0.805527, 0.006788)
RENDER_ATW: [FPS] L present:90.00 salt:0 (0.592301, -0.015502, 0.805539, 0.006773)

El número que segueix a "nova textura" representa els FPS del contingut actual. El número que segueix a "R present" i "L present" representa la freqüència d'imatges de la pantalla.
De vegades, la freqüència d'imatges per segon (FPS) del contingut i la freqüència d'imatges de la pantalla poden tenir una lleugera discrepància.
Per exampés a dir, en el cas anterior, 89.8 FPS es poden considerar com a 90 FPS.
Si els FPS del contingut de l'aplicació són constantment inferiors a la freqüència de fotogrames de la pantalla o romanen inestables, indica un problema de rendiment de renderització. Per tant, el següent pas és identificar si el coll d'ampolla prové de la CPU o de la GPU.
2.2 Comprovar l'ús de la CPU i la GPU
Si el vostre SDK d'aplicació utilitza el VIVE WAVE SDK 6.0.0 o posterior, podeu utilitzar l'ordre adb següent per comprovar els FPS.
$adb logcat -s VRMetric
Veureu les dades de registre següents.
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
Com podeu veure al resultat del registre superior, l'ús de la CPU és del 27% i l'ús de la GPU és del 72%. Si la versió del vostre SDK de Wave és inferior a la 6.0.0, es recomana actualitzar a la darrera versió per millorar el rendiment de renderització i altres optimitzacions.
Per a l'aplicació VIVE OpenXR, podeu utilitzar l'ordre següent per comprovar l'ús de la CPU i la GPU.
# a linux/ubuntu
$ adb logcat | grep CPU_USAGE
# al PowerShell
$ adb logcat | Selecció de cadena -Patró CPU_USAGE
Veureu el registre següent
Mitjana de la CPU CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 GPU ÚS_CPU [CÀRREGA] 25.67% 32.22% 25.29% 30.77% 29.35% 21.35% 22.09% 18.39% 24.14% 73%
Si observeu que els FPS no poden mantenir la velocitat de fotogrames de la pantalla i l'ús de la GPU també és molt alt, normalment supera el 85%, podeu provar d'ajustar la resolució de l'Eyebuffer (secció 3.1.2, secció 4.1.2) per veure si millora els FPS. Si aquest ajust condueix a una millor
rendiment, podem concloure que el problema està lligat a la GPU i centrar els nostres esforços d'optimització en conseqüència.
D'altra banda, si ajustar la resolució de l'Eyebuffer no produeix una millora notable del rendiment, és probable que el coll d'ampolla estigui lligat a la CPU i ens hauríem de centrar en optimitzar el rendiment de la CPU.
També és possible que l'aplicació estigui vinculada a la CPU i a la GPU simultàniament. En aquests casos, s'haurien d'aplicar esforços d'optimització tant a la CPU com a la GPU per aconseguir millores de rendiment equilibrades.
2.3 Limitat a la GPU
Quan una aplicació de realitat virtual està vinculada a la GPU, vol dir que la GPU és el principal coll d'ampolla i no pot satisfer les demandes de renderització de l'aplicació. Per mitigar els problemes vinculats a la GPU, tingueu en compte les recomanacions següents:
Primer, feu servir eines de perfilació com ara RenderDoc o Game Engine pro.filer (Unity Pro)filer, Unreal Insights) per analitzar on la GPU passa la major part del temps. Identificar les operacions més costoses i centrar-se en optimitzar-les.
Per a desenvolupadors natius, podeu utilitzar RenderDoc per identificar quina crida de dibuix està causant una càrrega excessiva de la GPU.
Per a desenvolupadors d'Unity, podeu seguir aquest document d'Unity o utilitzar RenderDoc per analitzar els problemes de rendiment de renderització i seguir la documentació d'optimització de gràfics d'Unity per obtenir orientació sobre com optimitzar la vostra aplicació.
Per a Unreal Developer, podeu utilitzar GPU Visualizer o RenderDoc per analitzar els problemes de rendiment de renderització i seguir les Directrius de rendiment d'Unreal per obtenir orientació per optimitzar la vostra aplicació.
En segon lloc, també podeu provar d'ajustar certes funcions o configuracions de Wave per reduir la càrrega de la GPU.

1. Estableix la freqüència d'actualització de la pantalla més lenta (secció 3.1.1, secció 4.1.1)
2.  Ajusta la resolució de l'Eyebuffer (secció 3.1.2, secció 4.1.2), 14.1.1)
3.  Intenta habilitar Foveation (secció 3.1.4, secció 4.1.4).

Si la teva aplicació també és una aplicació MR, també pots ajustar la configuració de Passthrough.

1. Ajusta la qualitat d'imatge de pas a través a la part inferior. (secció 3.2.1)
2. Ajusta la velocitat de fotograma a pas de pas més lentament. (secció 3.2.2).

Per a més informació sobre el rendiment de la GPU, podeu consultar el capítol 2.6.

2.4 Limitació de la CPU
Quan una aplicació de realitat virtual està limitada a la CPU, vol dir que la CPU és el coll d'ampolla principal. Tingueu en compte les recomanacions següents:
Primer, feu servir eines de perfilació com Systrace o Game Engine profiler (Unity Pro)filer, Unreal Insights) per analitzar i identificar quines parts del vostre codi consumeixen més recursos de CPU. Centreu-vos en l'optimització d'aquestes àrees i refactoritzeu algoritmes computacionalment intensius per reduir la càrrega de la CPU.

• Per a desenvolupadors nadius, podeu utilitzar Systrace per a professionals.fileel teu projecte.
• Per a Unity Developer, podeu utilitzar CPU Usage ProfileMòdul r per trobar problemes de rendiment de la CPU.
• Per a desenvolupadors d'Unreal, podeu utilitzar Unreal's Insights per trobar problemes de rendiment de la CPU.

En segon lloc, també podeu provar d'ajustar certes funcions o configuracions de Wave per reduir la càrrega de la GPU.

1. Estableix la freqüència d'actualització de la pantalla més lenta (secció 3.1.1, secció 4.1.1)
2.  Utilitza Multi-View Renderització (secció 3.1.4, secció 4.1.4)

Si la teva aplicació també és una aplicació MR, també pots ajustar la configuració de Passthrough.

1. Ajusta la freqüència de fotogrames de Passthrough a una velocitat més lenta (secció 3.2.2).

Per a més informació sobre el rendiment de la CPU, podeu consultar el capítol 2.6.

2.5 Resum
Finalment, hem organitzat el flux de treball de comprovació del rendiment anterior a la Figura 2-5-1. Comenceu comprovant els FPS del contingut. Si són inferiors a la freqüència de fotogrames de la pantalla o romanen inestables, analitzeu l'ús de la GPU/CPU per determinar si està limitat a la GPU o a la CPU. Finalment, utilitzeu un professional.filer per identificar possibles problemes de rendiment o ajustar les funcions o la configuració de Wave per optimitzar el rendiment de la CPU.

2.6 Referència ràpida Quines configuracions poden millorar la càrrega de la CPU/GPU

Enumereu els paràmetres de l'SDK relacionats amb la càrrega de la CPU/GPU tal com s'indica a continuació. Podeu basar-vos en el coll d'ampolla de l'aplicació per comprovar els paràmetres d'optimització rellevants.

Relacionat amb la CPU:

• Configuració del SDK de VIVE Wave
  o Contingut de realitat virtual
  ▪ 3.1.1 Freqüència d'actualització de la pantalla
  ▪ 3.1.4 Multi-View Renderització
  ▪ 3.1.6 Qualitat adaptativa
  ▪ 3.1.7 Compositor de moviment adaptatiu
  o Contingut de MR
  ▪ 3.2.2 Ajustar la freqüència d'imatges de pas a través
• Configuració del SDK de VIVE OpenXR
  o Contingut de realitat virtual
  ▪ 4.1.1 Freqüència d'actualització de la pantalla
  ▪ 4.1.4 Multi-View Renderització
• Optimització comuna
  o Pic de CPU de 5.5

Relacionat amb la GPU:

• Configuració del SDK de VIVE Wave
  o Contingut de realitat virtual
  ▪ 3.1.1 Freqüència d'actualització de la pantalla
  ▪ 3.1.2 Resolució de la memòria intermèdia
  ▪ 3.1.3 Multi-View Renderització
  ▪ 3.1.4 Foveació
  ▪ 3.1.5 Millora de la nitidesa del fotograma (FSE)
  ▪ 3.1.6 Qualitat adaptativa
  ▪ 3.1.7 Compositor de moviment adaptatiu
  ▪ 3.1.8 Màscara de renderització [No compatible amb Unreal] o Contingut MR
  ▪ 3.2.1 Ajustar la qualitat de pas a través
  ▪ 3.2.2 Ajustar la freqüència d'imatges de pas a través
• Configuració del SDK de VIVE OpenXR
  o Contingut de realitat virtual
  ▪ 4.1.1 Freqüència d'actualització de la pantalla
  ▪ 4.1.2 Resolució de la memòria intermèdia
  ▪ 4.1.3 Multi-View Renderització
  ▪ 4.1.4 Foveació [No compatible amb Unreal] ▪ 4.1.5 Màscara de renderització [No compatible amb Unreal]
• Optimització comuna
  o 5.1 Desactiva el mode d'alt rendiment
  o 5.2 Multisampling
  o 5.3 Càrrega/emmagatzematge de GMEM
  o 5.4 Capa de composició (multicapa)

Configuració d'ona VIVE

VIVE Wave és una plataforma oberta i un conjunt d'eines que permet desenvolupar fàcilment contingut de realitat virtual i proporciona optimització de dispositius d'alt rendiment per a socis externs. VIVE Wave és compatible amb els motors de joc Unity i Unreal.
Optimitzem i resolem diversos errors contínuament, per això recomanem mantenir l'SDK actualitzat.
Actualment, VIVE Wave només admet OpenGL ES. Aquí s'enumeren les característiques ordenades per la seva influència en el rendiment de la GPU. Ho dividirem en dues parts: contingut de realitat virtual i contingut de realitat virtual.
3.1 Contingut de realitat virtual
3.1.1 Freqüència d'actualització 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.

• Per a desenvolupadors nadius, consulteu WVR_SetFrameRate.
• Per a desenvolupadors d'Unity, consulteu aquesta guia.
• Per a desenvolupadors d'Unreal, consulteu aquesta guia.

3.1.2 Resolució de la memòria intermèdia
La resolució de l'eyebuffer és la mida de la textura que l'aplicació de contingut que es renderitzarà. La textura renderitzada s'enviarà al temps d'execució per fer el procés de publicació i presentar-se a la pantalla HMD.
Tot i que una mida de memòria intermèdia més gran pot donar lloc a imatges més clares i detallades, també imposa una càrrega significativa a la GPU. Per tant, trobar l'equilibri adequat entre la qualitat visual i el rendiment és essencial.
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.

• Per a desenvolupadors nadius, consulteu WVR_ObtainTextureQueue. Quan ajusteu la mida, heu de multiplicar l'amplada i l'alçada per una proporció.
• Per a desenvolupadors d'Unity, consulteu WaveXRSettings.
  Alternativament, podeu fer canvis mitjançant el codi que s'indica a continuació.
  XRSettings.eyeTextureResolutionScale = ResolutionScaleValue; // C#
• Per a desenvolupadors d'Unreal, consulteu SetPixelDensity.

3.1.3 Multi-View Renderització
En el renderitzat tradicional, dibuixem els ulls esquerre i dret per separat, cosa que requereix dues crides de dibuix per a la mateixa escena.View La renderització soluciona aquest problema realitzant només una crida de dibuix.
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.

• Per a desenvolupadors nadius, podeu consultar wvr_native_hellovr.ample.
• Per a desenvolupadors d'Unity, consulteu el Mode de renderització, una sola passada és multi-view característica.
• Per a desenvolupadors d'Unreal, consulteu aquesta guia.

3.1.4 Foveació
El renderitzat foveat està dissenyat principalment per reduir la càrrega de la GPU. Redueix el detall del fotograma a la perifèria de la pantalla i manté un detall d'alta resolució al centre del camp de viewSi l'aplicació té un problema de vinculació a la GPU, podeu provar d'implementar el renderitzat Foveation.

Hi ha alguna cosa que cal tenir en compte a l'hora d'utilitzar la foveació:

➢ Els usuaris normalment no noten la reducció de detalls a les regions perifèriques quan apliquen el mode de foveació per defecte. Però si la qualitat perifèrica de la foveació està massa baixa, l'usuari podria notar-ho.
➢ Els efectes de la foveació poden ser més notables amb certs materials o textures, cosa que podria captar l'atenció de l'usuari. Els desenvolupadors haurien de ser conscients d'això i avaluar-ho en conseqüència.
➢ L'activació de la funció de renderització foveated comporta un cost fix de rendiment de la GPU, que pot variar entre l'1% i el 6% depenent de la mida del buffer de l'ull. Quan s'utilitza un shader simple a l'escena, el guany de rendiment derivat de l'estalvi de recursos pot ser inferior al cost fix de rendiment de la GPU, cosa que provoca una disminució del rendiment.

• Per a desenvolupadors nadius, consulteu aquesta guia.
• Per a desenvolupadors d'Unity, consulteu aquesta guia. Cal destacar que, quan activeu el postprocessament o l'HDR, la foveació no es pot utilitzar completament. Perquè Unity renderitzarà els objectes en la seva pròpia textura de renderització generada, en lloc de la textura de renderització del present generat en temps d'execució que admet la foveació.
• Per a desenvolupadors d'Unreal, consulteu aquesta guia. Cal destacar que la foveació no es pot utilitzar completament en Multi-View Renderització, perquè Unreal no pot renderitzar directament objectes a la textura de renderització generada en temps d'execució que admet la foveació.

3.1.5 Millora de la nitidesa del fotograma (FSE)
L'FSE proporciona un resultat de renderització més nítid mitjançant la introducció d'un filtre d'enfoque, que pot fer que el contingut sigui més clar i ser força útil per millorar la claredat del text a l'escena. Si l'aplicació té un problema de vinculació a la GPU, podeu considerar desactivar l'FSE si no és essencial.

• Per a desenvolupadors nadius, consulteu aquesta guia.
• Per a desenvolupadors d'Unity, consulteu aquesta guia.
• Per a desenvolupadors d'Unreal, consulteu aquesta guia.

3.1.6 Qualitat adaptativa
Per estalviar bateria i mantenir el rendiment de renderització del dispositiu, aquesta funció ajusta automàticament els nivells de rendiment del rellotge de la CPU/GPU en funció del seu ús. A més, es poden implementar altres estratègies per millorar el rendiment, com ara activar/desactivar automàticament Foveation o que el contingut es pugui ajustar si rep esdeveniments de càrrega alta/baixa.

• Per a desenvolupadors nadius, consulteu aquesta guia.
• Per a desenvolupadors d'Unity, consulteu aquesta guia. Al nostre connector d'Unity, la mida de la memòria intermèdia es pot ajustar automàticament en funció del rendiment actual; la mida del text filtrarà els valors d'escala que siguin massa petits a la llista Resolució. Recomanem un text de mida mínima de 20 dmm o superior.
• Per a desenvolupadors d'Unreal, consulteu aquesta guia.

3.1.7 Compositor de moviment adaptatiu
Aquesta funció és experimental i inclou UMC i PMC. L'UMC reduirà la freqüència d'imatges a la meitat i extrapolarà els nous fotogrames en temps real per mantenir la suavitat visual. Tanmateix, presenta certa latència, artefactes i càrrega de la GPU.
PMC utilitza principalment el Depth Buffer per permetre que ATW tingui en compte la traducció HMD, estenent-la fins a una compensació de 6 graus de llibertat. Aquesta funció pot reduir la latència de la traducció en 1 o 2 fotogrames, però augmenta la càrrega de la GPU.

• Per a desenvolupadors nadius, consulteu aquesta guia.
• Per a desenvolupadors d'Unity, consulteu aquesta guia.
• Per a desenvolupadors d'Unreal, consulteu aquesta guia.

3.1.8 Màscara de renderització [No compatible amb Unreal]
Els píxels de les vores es tornen gairebé invisibles després de la distorsió, la màscara de renderització modifica els valors de la memòria intermèdia de profunditat d'aquests píxels invisibles. Si activeu les proves de profunditat, a causa de la z primerenca, aquests píxels invisibles no es renderitzaran, cosa que reduirà la càrrega de la GPU. Aquesta funció és útil si hi ha objectes de renderització amb molta càrrega en aquestes àrees invisibles; en cas contrari, si no hi ha objectes de renderització en aquestes àrees, es recomana desactivar-la perquè consumirà un petit ús de la GPU.

• Per a desenvolupadors nadius, consulteu aquesta guia. Heu de vincular el buffer de profunditat abans de cridar RenderMask; en cas contrari, no serà efectiu.
• Per a desenvolupadors d'Unity, consulteu aquesta guia.
• Per als desenvolupadors d'Unreal, actualment no és compatible amb la funció de màscara de renderització.

3.2 Contingut de RM
3.2.1 Ajustar la qualitat de pas a través
Hi ha 3 nivells de qualitat d'imatge de pas a través:
➢ WVR_PassthroughImageQuality_DefaultMode: adequat per al contingut MR sense la demanda específica.
➢ WVR_PassthroughImageQuality_PerformanceMode: adequat per al contingut MR que necessita més recursos de GPU per a la renderització d'escenes virtuals.
➢ WVR_PassthroughImageQuality_QualityMode: adequat per al contingut MR que permet als usuaris veure l'entorn amb claredat, però l'escena virtual del contingut ha de tenir un ajustament més fi per al rendiment.
Podeu ajustar la qualitat de Passthrough a PerformanceMode per reduir l'ús de la GPU.

• Per a desenvolupadors de Native, Uunity o Unreal, consulteu aquesta guia.

3.2.2 Ajustar la freqüència d'imatges de pas a través
Igual que la freqüència d'actualització de la pantalla, una freqüència d'imatges de passthrough més alta ofereix visuals més suaus, però té com a cost una major càrrega del sistema. Per contra, les freqüències d'actualització més baixes redueixen la càrrega del sistema, però donen lloc a visuals menys suaus. Hi ha 2 modes de freqüència d'imatges de passthrough: Boost i Normal.

• Per a desenvolupadors nadius, es pot ajustar la qualitat del passthrough mitjançant WVR_SetPassthroughImageRate.
• Per a desenvolupadors d'Unity, es pot canviar mitjançant codi, per exempleampla configuració del fitxer és la següent // C#
  Interop.WVR_SetPassthroughImageQuality(WVR_PassthroughImageQuality.PerformanceMode);
• Per al desenvolupador d'Unreal, el mètode de configuració es pot veure al node blueprint de la Figura 3-2-2.

Configuració de VIVE OpenXR

OpenXR és un estàndard obert que proporciona un conjunt comú d'API per desenvolupar aplicacions XR que s'executen en una àmplia gamma de dispositius de realitat virtual, desenvolupats pel Khronos Group. El VIVE Focus 3 i el VIVE XR Elite també són compatibles amb OpenXR. El VIVE OpenXR SDK ofereix compatibilitat completa amb dispositius HTC VR, permetent als desenvolupadors crear contingut All-in-One amb Unity i Unreal engine en dispositius HTC VR. Optimitzem i resolem contínuament diversos errors, per la qual cosa es recomana que els desenvolupadors actualitzin la versió FOTA del seu dispositiu per mantenir-lo actualitzat. Actualment, el VIVE OpenXR SDK admet OpenGL ES i Vulkan.

4.1 Contingut de realitat virtual
4.1.1 Freqüència d'actualització de la pantalla
El concepte aquí és similar al de 3.1.1 Freqüència d'actualització de la pantalla.

• Per a desenvolupadors nadius, consulteu XrEventDataDisplayRefreshRateChangedFB.
• Per a desenvolupadors d'Unity, consulteu aquesta guia.
• Per a desenvolupadors d'Unreal, consulteu aquesta guia.

4.1.2 Resolució de la memòria intermèdia
El concepte aquí és similar a 3.1.2 Resolució de l'Eyebuffer. Recomanem no reduir el factor d'escala per sota de 0.7, ja que això pot resultar en una qualitat visual inacceptable.

• Per a desenvolupadors nadius, consulteu xrCreateSwapchain. Quan ajusteu la mida, heu de multiplicar l'amplada i l'alçada per una proporció.
• Per a desenvolupadors d'Unity, consulteu el següent exempleample // C#
  XRSettings.eyeTextureResolutionScale = 0.7f; //es recomana 1.0f~0.7f
• Per a la configuració d'Unreal, consulteu aquesta guia.

4.1.3 Multi-View Renderització
El concepte aquí és similar al de 3.1.3 Multi-View Renderització. Aquesta funció redueix la càrrega de la CPU, la GPU també té alguns avantatges. Recomanem activar aquesta funció.

• Per a desenvolupadors nadius, KhronosGroup ofereix una plataforma multifunció OpenXR.View exampés a dir, consulteu aquesta guia.
• Per a desenvolupadors d'Unity, consulteu el Mode de renderització, una sola passada és multi-view característica.
• Per a desenvolupadors d'Unreal, igual que amb la configuració de VIVE Wave, consulteu aquesta guia.

4.1.4 Foveació [No compatible amb Unreal]
El concepte aquí és similar al de 3.1.4 Foveació. El renderitzat foveat està dissenyat principalment per reduir la càrrega de la GPU, però activar-lo comportarà un cost fix de rendiment de la GPU i si la foveació s'estableix massa baixa i s'utilitzen certs materials o textures, pot arribar a ser molt...
perceptible per a l'usuari. Per tant, és recomanable activar o desactivar la funció segons els vostres requisits específics i les consideracions de rendiment. Actualment, la funcionalitat Foveated només és compatible amb OpenGL ES al VIVE OpenXR SDK.

• Per als desenvolupadors nadius, aquesta funció està disponible, però actualment no hi ha cap característica.ampes proporcionen les.
• Per a desenvolupadors d'Unity, consulteu aquesta guia.
• Per als desenvolupadors d'Unreal, aquesta funció no és compatible en aquest moment.

4.1.5 Màscara de renderització [No compatible amb Unreal]
El concepte aquí és similar al de 3.1.8 Màscara de renderització.

• Per a desenvolupadors nadius, utilitzeu XrVisibilityMaskKHR per obtenir la malla. Abans de renderitzar l'escena, utilitzeu aquesta malla per omplir els valors de la memòria intermèdia de profunditat abans de renderitzar l'escena.
• Per als desenvolupadors d'Unity, la funció Render Mask està habilitada per defecte per a OpenGL ES i es pot desactivar amb el codi següent; actualment, Vulkan no admet aquesta funció. //C# UnityEngine.XR.XRSettings.occlusionMaskScale = 0.0f;
• Per als desenvolupadors d'Unreal, actualment no és compatible amb la funció de màscara de renderització.

4.2 Contingut de RM
Actualment, OpenXR no admet la configuració de la qualitat de passthrough i la freqüència d'imatges. Continuarem optimitzant i corregint la funció de passthrough, per la qual cosa recomanem que els desenvolupadors actualitzin la versió FOTA del dispositiu per mantenir-lo actualitzat.

Optimització comuna

5.1 Desactiva el mode d'alt rendiment
Desactivar el "Mode d'alt rendiment" pot reduir la mida de la pantalla del dispositiu, cosa que redueix l'ús de la GPU. L'inconvenient és una disminució de la resolució de la pantalla. Podeu equilibrar la qualitat i el rendiment per decidir si l'activeu.
La ubicació de configuració per al VIVE Focus 3 es mostra a la Figura 5-1-1:

La ubicació de configuració per a VIVE XR Elite es mostra a 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.

• Per a desenvolupadors nadius, MSAA OpenGL ES exsamppodem fer referència a això; MSAA Vulkan exampler pot referir-se a això.
  La GPU Adreno proporciona una extensió que optimitza l'MSAA.
• Per a desenvolupadors d'Unity, consulteu aquesta guia.
• For Unreal developer, refer to this guild. Unreal also has provide post processing anti-aliasing, refer to this guild.

5.3 Càrrega/emmagatzematge de GMEM
A l'arquitectura de la GPU Adreno, hi ha una característica que permet, en vincular un objectiu de renderització, si aquest no s'esborra o s'invalida, cada vegada que es produeix una renderització, els valors de l'objectiu de renderització es carreguen a la memòria gràfica, que s'anomena càrrega GMEM. Si els valors anteriors no són necessaris, esborrar o invalidar l'objectiu de renderització abans de la renderització pot evitar aquesta situació i millorar el rendiment de la GPU.
Podeu evitar la càrrega de GMEM mitjançant els mètodes següents. A OpenGL ES, després d'enllaçar l'FBO, podeu cridar glClear i glClearDepth per esborrar el buffer de Color, Depth i Stencil, o cridar glInvalidateFramebuffer per invalidar l'objectiu de renderització especificat. A Vulkan, no calen instruccions addicionals; podeu definir explícitament si voleu esborrar l'adjunt abans d'utilitzar-lo a VkAttachmentDescription.loadOp.
De la mateixa manera, emmagatzemar el resultat d'un renderitzat de mosaic a la memòria principal des de la memòria gràfica s'anomena emmagatzematge GMEM; aquesta operació també és costosa per a la GPU. Per evitar-ho, recomanem vincular només els objectius de renderització necessaris per evitar operacions d'emmagatzematge innecessàries.

5.4 Capa de composició (multicapa)
Les textures que es mostren amb Multi-Layer tenen una millor qualitat visual. Tanmateix, aquesta funció augmenta significativament el rendiment de la GPU amb el nombre de capes i la mida de les textures. No recomanem més de tres capes.

• Per a desenvolupadors nadius,
  El VIVE Wave SDK utilitza WVR_SubmitFrameLayers per passar dades de cada capa.
  El SDK de VIVE OpenXR col·loca les dades de capa a XrFrameEndInfo i les envia mitjançant xrEndFrame.
• Per a desenvolupadors d'Unity,
  o Configuració de l'SDK de VIVE Wave, consulteu aquesta guia.
  o Configuració de VIVE OpenXR, consulteu aquesta guia.
• Per al desenvolupador d'Unreal,
  o Configuració del SDK de VIVE Wave, consulteu aquesta guia.
  o Configuració de VIVE OpenXR, consulteu aquesta guia.

Pic de CPU de 5.5
Quan la càrrega de la CPU és més pesada, alguns fils de processos en segon pla amb prioritat alta poden interrompre l'execució nativa. No podem garantir que l'aplicació de contingut no sigui interrompuda per altres fils.
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.

• Per a Unity Developer, consulteu la funció de configuració de fils d'Android. Si utilitzeu el VIVE Wave SDK, tenim una funció a WaveXRSettings que us permet ajustar la prioritat, tal com es mostra a la Figura 5-5-2. El valor més petit representa una prioritat més alta.

• No hi ha mètode per canviar el fil del joc, el fil de renderització i la prioritat del fil RHI a través de configuracions externes, tret que modifiquis el codi del motor.

Drets d'autor © 2024 HTC Corporation. Tots els drets reservats.

Documents/Recursos

Rendiment de renderització de VIVE VR [pdfGuia de l'usuari Rendiment de renderització de realitat virtual, Rendiment de renderització, Rendiment

Referències

• Manual d'usuari