Prestazioni di rendering VR
Ottimizzazioni e messe a punto

Introduzione

Ottenere un'esperienza VR ottimale su hardware con risorse limitate è fondamentale per offrire un'esperienza utente fluida e confortevole. Se il frame rate del rendering dei contenuti scende o è instabile al di sotto della frequenza di aggiornamento del dispositivo, ciò porterà a scatti e scatti dei frame, cinetosi, ecc., che alla fine avranno un impatto negativo sull'esperienza utente. Pertanto, ottimizzare le prestazioni dei contenuti è molto importante per garantire un'esperienza piacevole.
Prima di iniziare l'ottimizzazione delle prestazioni, è importante capire dove si trovano i colli di bottiglia delle prestazioni per evitare un'ottimizzazione inefficiente. Questo documento è progettato per aiutare gli sviluppatori a identificare i colli di bottiglia delle prestazioni e offrire soluzioni per risolvere i problemi di prestazioni di rendering.
Il documento è organizzato nelle seguenti sezioni:

• Capitolo 2: Identificare il collo di bottiglia – Questa sezione aiuta gli sviluppatori a identificare dove si trovano i colli di bottiglia.
• Capitolo 3 e 4: Impostazioni di VIVE Wave e VIVE OpenXR – Queste sezioni descrivono impostazioni specifiche che potrebbero influire sulle prestazioni di CPU/GPU per le app VIVE Wave e OpenXR. Gli sviluppatori possono sperimentare l'abilitazione o la disabilitazione di queste funzionalità in base ai colli di bottiglia riscontrati per determinare se si verificano miglioramenti.
• Capitolo 5: Ottimizzazione comune – Questa sezione condivide alcune pratiche ed esperienze comuni di ottimizzazione.

Identificare il collo di bottiglia

Quando l'HMD è in movimento, se l'app VR/MR presenta jitter o bordi neri, ecc., ciò è solitamente dovuto a problemi di prestazioni di rendering. In genere, i problemi di prestazioni di rendering possono essere classificati in due tipologie: legati alla CPU o alla GPU. Capire quali tipi di vincoli sono presenti nella tua app è fondamentale fin dall'inizio per evitare un'ottimizzazione inefficiente.
In questo capitolo forniamo semplici passaggi che consentono di identificare rapidamente dove si verificano problemi di prestazioni.

2.1 Controlla il rendering del contenuto FPS
Per prima cosa, controlliamo gli FPS del contenuto, ovvero il numero di fotogrammi al secondo che il contenuto elabora. Dovrebbero essere mantenuti al frame rate del display e stabili. In caso contrario, potrebbero verificarsi scatti.
Se l'SDK dell'applicazione utilizza VIVE WAVE SDK 6.0.0 o versione successiva, è possibile utilizzare il seguente comando adb per controllare gli FPS. DK 6.0.0
$adb Logcat -s VRMetric
Verranno visualizzati i seguenti dati di 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" Il primo numero rappresenta l'FPS del contenuto, mentre il secondo numero rappresenta il frame rate dello schermo.
Se la versione del Wave SDK è precedente alla 6.0.0, si consiglia di aggiornarla alla versione più recente per migliorare le prestazioni di rendering e altre ottimizzazioni.
Se l'SDK dell'applicazione è stato creato con VIVE OpenXR, puoi usare il seguente comando adb per verificare gli FPS.
$adb Logcat -s RENDER_ATW
Verranno visualizzati i seguenti dati di registro
RENDER_ATW: [FPS] nuova texture: 90.00
RENDER_ATW: [FPS] R presente:90.00 salta:0 317, -0.0155 0.805527, 0.006788)
RENDER_ATW: [FPS] L presente:90.00 salta:0 (0.592301, -0.015502, 0.805539, 0.006773)

Il numero che segue "nuova texture" rappresenta gli FPS attualmente disponibili. Il numero che segue "R presente" e "L presente" rappresenta il frame rate visualizzato.
A volte, l'FPS del contenuto e il frame rate dello schermo potrebbero presentare una leggera discrepanza.
Per esempioampAd esempio, nel caso di cui sopra, 89.8 FPS possono essere considerati come 90 FPS.
Se gli FPS dei contenuti dell'app sono costantemente inferiori al frame rate del display o rimangono instabili, ciò indica un problema di prestazioni di rendering. Pertanto, il passo successivo è identificare se il collo di bottiglia proviene dalla CPU o dalla GPU.
2.2 Controllare l'utilizzo della CPU e della GPU
Se l'SDK della tua applicazione utilizza VIVE WAVE SDK 6.0.0 o versione successiva, puoi usare il seguente comando adb per controllare gli FPS.
$adb logcat -s VRMetric
Verranno visualizzati i seguenti dati di 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
Come puoi vedere nel risultato del log sopra, l'utilizzo della CPU è del 27% e l'utilizzo della GPU è del 72%. Se la tua versione Wave SDK è precedente alla 6.0.0, si consiglia di aggiornarla alla versione più recente per migliorare le prestazioni di rendering e altre ottimizzazioni.
Per l'app VIVE OpenXR, puoi usare il seguente comando per controllare l'utilizzo di CPU e GPU.
# su linux/ubuntu
$ adb logcat | grep CPU_USAGE
# su PowerShell
$ adb logcat | Seleziona-Stringa -Modello CPU_USAGE
Vedrai il seguente registro
CPU Media CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 GPU CPU_USAGE [CARICO] 25.67% 32.22% 25.29% 30.77% 29.35% 21.35% 22.09% 18.39% 24.14% 73 %
Se osservi che l'FPS non riesce a mantenere il frame rate del display e anche l'utilizzo della GPU è molto elevato, in genere supera l'85%, puoi provare a regolare la risoluzione dell'Eyebuffer (sezione 3.1.2, sezione 4.1.2) per vedere se migliora l'FPS. Se questa regolazione porta a un migliore
prestazioni, possiamo concludere che il problema è legato alla GPU e concentrare di conseguenza i nostri sforzi di ottimizzazione.
D'altro canto, se la regolazione della risoluzione dell'Eyebuffer non determina un miglioramento evidente delle prestazioni, è probabile che il collo di bottiglia sia legato alla CPU e dovremmo concentrarci sull'ottimizzazione delle prestazioni della CPU.
È anche possibile che l'applicazione sia sia legata alla CPU che alla GPU contemporaneamente. In tali casi, gli sforzi di ottimizzazione dovrebbero essere applicati sia alla CPU che alla GPU per ottenere miglioramenti bilanciati delle prestazioni.
2.3 Vincolato alla GPU
Quando un'app VR è vincolata alla GPU, significa che la GPU rappresenta il principale collo di bottiglia e non è in grado di soddisfare le esigenze di rendering dell'applicazione. Per mitigare i problemi legati alla GPU, si consiglia di considerare i seguenti consigli:
Per prima cosa, usa strumenti di profilazione come RenderDoc o Game Engine profiler (Unità Profiler, Unreal Insights) per analizzare dove la GPU trascorre la maggior parte del tempo. Identifica le operazioni più costose e concentrati sulla loro ottimizzazione.
Per gli sviluppatori nativi, è possibile utilizzare RenderDoc per identificare quale draw call sta causando un carico eccessivo sulla GPU.
Per gli sviluppatori Unity, è possibile seguire questo documento di Unity o utilizzare RenderDoc per analizzare i problemi di prestazioni di rendering e seguire la documentazione di ottimizzazione grafica di Unity per ottenere indicazioni su come ottimizzare l'applicazione.
Per Unreal Developer, puoi utilizzare GPU Visualizer o RenderDoc per analizzare i problemi di prestazioni di rendering e seguire le Unreal Performance Guidelines per ottenere indicazioni su come ottimizzare la tua applicazione.
In secondo luogo, puoi anche provare a regolare alcune funzionalità o impostazioni di Wave per ridurre il carico sulla GPU.

1. Imposta una frequenza di aggiornamento dello schermo più lenta (sezione 3.1.1, sezione 4.1.1)
2.  Regola la risoluzione dell'Eyebuffer (sezione 3.1.2, sezione 4.1.2), 14.1.1)
3.  Provare ad abilitare la foveazione (sezione 3.1.4, sezione 4.1.4).

Se la tua app è anche un'app MR, puoi anche modificare le impostazioni Passthrough.

1. Impostare la qualità dell'immagine passthrough su un valore inferiore. (sezione 3.2.1)
2. Regola il Framerate Passthrough più lento. (sezione 3.2.2).

Per ulteriori impostazioni sulle prestazioni della GPU, fare riferimento al Capitolo 2.6.

2.4 Limitato alla CPU
Quando un'app VR è vincolata alla CPU, significa che la CPU è il collo di bottiglia principale. Si consiglia di tenere in considerazione i seguenti consigli:
Per prima cosa, usa strumenti di profilazione come Systrace o Game Engine Profiler (Unità Profiler, Unreal Insights) per analizzare e identificare quali parti del codice consumano più risorse della CPU. Concentratevi sull'ottimizzazione di queste aree e riorganizzate gli algoritmi computazionalmente intensivi per ridurre il carico della CPU.

• Per gli sviluppatori nativi, puoi usare Systrace perfileper il tuo progetto.
• Per Unity Developer, puoi utilizzare CPU Usage ProfileModulo r per individuare problemi di prestazioni della CPU.
• Per gli sviluppatori Unreal, è possibile utilizzare Unreal Insights per individuare problemi di prestazioni della CPU.

In secondo luogo, puoi anche provare a regolare alcune funzionalità o impostazioni di Wave per ridurre il carico sulla GPU.

1. Imposta una frequenza di aggiornamento dello schermo più lenta (sezione 3.1.1, sezione 4.1.1)
2.  Utilizzare Multi-View Rendering (sezione 3.1.4, sezione 4.1.4)

Se la tua app è anche un'app MR, puoi anche modificare le impostazioni Passthrough.

1. Regola il Framerate Passthrough più lento (sezione 3.2.2).

Per ulteriori impostazioni sulle prestazioni della CPU, fare riferimento al Capitolo 2.6.

2.5 Riepilogo
Infine, abbiamo organizzato il flusso di lavoro di controllo delle prestazioni di cui sopra nella Figura 2-5-1. Inizia controllando l'FPS del contenuto. Se è inferiore al frame rate del display o rimane instabile, analizza l'utilizzo di GPU/CPU per determinare se è legato alla GPU o alla CPU. Infine, usa un profiler per identificare potenziali problemi di prestazioni o regolare le funzionalità o le impostazioni di Wave per ottimizzare le prestazioni della CPU.

2.6 Riferimento rapido Quali impostazioni possono migliorare il caricamento della CPU/GPU

Elenca le impostazioni dell'SDK relative al caricamento CPU/GPU come di seguito. Puoi basarti sul collo di bottiglia dell'app per controllare le impostazioni di ottimizzazione pertinenti.

Relativo alla CPU:

• Impostazione SDK VIVE Wave
  o Contenuto VR
  ▪ 3.1.1 Frequenza di aggiornamento dello schermo
  ▪ 3.1.4 Multi-View Rendering
  ▪ 3.1.6 Qualità adattiva
  ▪ 3.1.7 Compositore di movimento adattivo
  o Contenuto MR
  ▪ 3.2.2 Regola il frame rate passthrough
• Impostazione SDK VIVE OpenXR
  o Contenuto VR
  ▪ 4.1.1 Frequenza di aggiornamento dello schermo
  ▪ 4.1.4 Multi-View Rendering
• Ottimizzazione comune
  o 5.5 Picco della CPU

Relativo alla GPU:

• Impostazione SDK VIVE Wave
  o Contenuto VR
  ▪ 3.1.1 Frequenza di aggiornamento dello schermo
  ▪ 3.1.2 Risoluzione Eyebuffer
  ▪ 3.1.3 Multi-View Rendering
  ▪ 3.1.4 Foveazione
  ▪ 3.1.5 Miglioramento della nitidezza dei fotogrammi (FSE)
  ▪ 3.1.6 Qualità adattiva
  ▪ 3.1.7 Compositore di movimento adattivo
  ▪ 3.1.8 Maschera di rendering [Non supporta Unreal] o Contenuto MR
  ▪ 3.2.1 Regola la qualità del passthrough
  ▪ 3.2.2 Regola il frame rate passthrough
• Impostazione SDK VIVE OpenXR
  o Contenuto VR
  ▪ 4.1.1 Frequenza di aggiornamento dello schermo
  ▪ 4.1.2 Risoluzione Eyebuffer
  ▪ 4.1.3 Multi-View Rendering
  ▪ 4.1.4 Foveazione [Non supporta Unreal] ▪ 4.1.5 Maschera di rendering [Non supporta Unreal]
• Ottimizzazione comune
  o 5.1 Disattivare la modalità ad alte prestazioni
  o 5.2 Multiampmolva
  o 5.3 Caricamento/memorizzazione GMEM
  o 5.4 Livello di composizione (multistrato)

Impostazione dell'onda VIVE

VIVE Wave è una piattaforma e un set di strumenti aperti che ti consente di sviluppare facilmente contenuti VR e fornisce un'ottimizzazione dei dispositivi ad alte prestazioni per partner terzi. VIVE Wave supporta i motori di gioco Unity e Unreal.
Ottimizziamo e risolviamo costantemente vari bug, pertanto consigliamo di mantenere aggiornato l'SDK.
Attualmente, VIVE Wave supporta solo OpenGL ES. Qui sono elencate le funzionalità ordinate in base all'influenza sulle prestazioni della GPU. Le divideremo in due parti: contenuto VR e contenuto MR.
3.1 Contenuto VR
3.1.1 Frequenza di aggiornamento dello schermo

Frequenze di aggiornamento più elevate offrono immagini più fluide, ma comportano un aumento del carico di sistema. Al contrario, frequenze di aggiornamento più basse riducono il carico di sistema, ma comportano immagini meno fluide. Se l'app ha un problema di CPU/GPU bound, puoi provare a ridurre la frequenza di aggiornamento del display per alleviare il problema.

• Per gli sviluppatori nativi, fare riferimento a WVR_SetFrameRate.
• Per gli sviluppatori Unity, fare riferimento a questa guida.
• Per gli sviluppatori Unreal, fare riferimento a questa guida.

3.1.2 Risoluzione Eyebuffer
La risoluzione Eyebuffer è la dimensione della texture che l'app deve elaborare; la texture elaborata verrà inviata al runtime per il processo di pubblicazione e presentata sul display HMD.
Mentre una dimensione maggiore dell'eye buffer può dare origine a immagini più nitide e dettagliate, impone anche un carico significativo sulla GPU. Pertanto, trovare il giusto equilibrio tra qualità visiva e prestazioni è essenziale.
Se l'app ha un problema di GPU bound, puoi provare a ridurre la dimensione dell'eyebuffer moltiplicando un fattore di scala. Tuttavia, ti consigliamo di non ridurre il fattore di scala al di sotto di 0.7, poiché ciò potrebbe causare una qualità visiva inaccettabile.

• Per gli sviluppatori nativi, fare riferimento a WVR_ObtainTextureQueue. Quando si regolano le dimensioni, è necessario moltiplicare la larghezza e l'altezza per un rapporto.
• Per gli sviluppatori Unity, fare riferimento a WaveXRSettings.
  In alternativa, è possibile apportare modifiche tramite il codice riportato di seguito.
  XRSettings.eyeTextureResolutionScale = ResolutionScaleValue; // C#
• Per gli sviluppatori Unreal, fare riferimento a SetPixelDensity.

3.1.3 Multi-View Rendering
Nel rendering tradizionale, disegniamo separatamente l'occhio sinistro e quello destro, il che richiede due chiamate di disegno per la stessa scena. Multi-View Il rendering risolve questo problema eseguendo una sola chiamata di disegno.
Questa funzionalità riduce il carico della CPU riducendo il numero di draw call. Anche la GPU offre alcuni vantaggi: il carico di lavoro del vertex shader si riduce, poiché non deve eseguire uno shader aggiuntivo per l'altro occhio, mentre il carico di lavoro del fragment shader rimane invariato, poiché deve comunque valutare ogni pixel per entrambi gli occhi. Consigliamo di abilitare questa funzionalità.

• Per gli sviluppatori nativi, puoi fare riferimento a wvr_native_hellovr samplui.
• Per gli sviluppatori Unity, fare riferimento alla modalità di rendering, il passaggio singolo è multiploview caratteristica.
• Per gli sviluppatori Unreal, fare riferimento a questa guida.

3.1.4 Foveazione
Il rendering foveato è progettato principalmente per ridurre il carico della GPU. Riduce il dettaglio dei fotogrammi nella periferia del display e mantiene un dettaglio ad alta risoluzione al centro del campo di viewSe l'app presenta problemi di GPU bound, puoi provare ad abilitare il rendering Foveation.

Ci sono alcune cose che bisogna tenere a mente quando si usa la foveazione:

➢ In genere, gli utenti non notano la riduzione del dettaglio nelle regioni periferiche quando si applica la modalità di foveazione predefinita. Tuttavia, se la qualità periferica della foveazione è impostata su un valore troppo basso, potrebbe risultare evidente all'utente.
➢ Gli effetti della foveazione potrebbero essere più evidenti con alcuni materiali o texture, il che potrebbe catturare l'attenzione dell'utente. Gli sviluppatori dovrebbero tenerne conto e valutarlo di conseguenza.
➢ L'abilitazione della funzionalità di rendering foveato comporta un costo fisso in termini di prestazioni della GPU, che può variare dall'1% al 6% a seconda delle dimensioni dell'eye buffer. Quando si utilizza uno shader semplice nella scena, il guadagno in termini di prestazioni derivante dal risparmio di risorse potrebbe essere inferiore al costo fisso in termini di prestazioni della GPU, con conseguente calo delle prestazioni.

• Per gli sviluppatori nativi, fare riferimento a questa guida.
• Per gli sviluppatori Unity, fare riferimento a questa guida. In particolare, quando si abilita la post-elaborazione o l'HDR, la foveazione non può essere sfruttata appieno. Questo perché Unity renderizzerà gli oggetti sulla propria texture di rendering generata, anziché sulla texture di rendering del presente generata in fase di runtime che supporta la foveazione.
• Per gli sviluppatori Unreal, fare riferimento a questa guida. In particolare, la foveazione non può essere utilizzata completamente su Multi-View Rendering, perché Unreal non può eseguire il rendering diretto degli oggetti sulla texture di rendering generata in fase di esecuzione che supporta la foveazione.

3.1.5 Miglioramento della nitidezza dei fotogrammi (FSE)
L'FSE fornisce un risultato di rendering più nitido tramite l'introduzione di un filtro di nitidezza, può rendere il contenuto più chiaro ed essere molto utile per migliorare la chiarezza del testo nella scena. Se l'app ha un problema di GPU bound, puoi prendere in considerazione la disattivazione dell'FSE se non è essenziale.

• Per gli sviluppatori nativi, fare riferimento a questa guida.
• Per gli sviluppatori Unity, fare riferimento a questa guida.
• Per gli sviluppatori Unreal, fare riferimento a questa guida.

3.1.6 Qualità adattiva
Per risparmiare la batteria e mantenere le prestazioni di rendering del dispositivo, questa funzionalità regola automaticamente i livelli di prestazioni del clock CPU/GPU in base al loro utilizzo. Inoltre, possono essere implementate altre strategie per migliorare le prestazioni, come abilitare/disabilitare automaticamente la foveazione o il contenuto che può regolarsi da solo se riceve eventi di carico alto/basso.

• Per gli sviluppatori nativi, fare riferimento a questa guida.
• Per gli sviluppatori Unity, fare riferimento a questa guida. Nel nostro plugin Unity, la dimensione del buffer oculare può essere regolata automaticamente in base alle prestazioni correnti; la dimensione del testo filtrerà i valori di scala troppo piccoli nell'elenco Risoluzione. Si consiglia un testo di almeno 20 dmm o superiore.
• Per gli sviluppatori Unreal, fare riferimento a questa guida.

3.1.7 Compositore di movimento adattivo
Questa funzionalità è una funzionalità sperimentale che include UMC e PMC. UMC ridurrà il Frame Rate della metà ed estrapolerà nuovi frame in tempo reale per mantenere la fluidità visiva. Tuttavia, presenta un po' di latenza, artefatti e caricamento GPU.
PMC utilizza principalmente il Depth Buffer per consentire ad ATW di tenere conto della traduzione HMD, estendendola a una compensazione a 6 gradi di libertà. Questa funzionalità può ridurre la latenza di traduzione di 1~2 frame, ma aumentare il caricamento della GPU.

• Per gli sviluppatori nativi, fare riferimento a questa guida.
• Per gli sviluppatori Unity, fare riferimento a questa guida.
• Per gli sviluppatori Unreal, fare riferimento a questa guida.

3.1.8 Maschera di rendering [Non supporta Unreal]
I pixel ai bordi diventano quasi invisibili dopo la distorsione; la maschera di rendering modifica i valori del buffer di profondità di questi pixel invisibili. Se si abilita il test di profondità, a causa dell'effetto early-z, questi pixel invisibili non verranno renderizzati, riducendo così il carico sulla GPU. Questa funzione è utile se sono presenti oggetti di rendering pesanti in queste aree invisibili; in caso contrario, se non sono presenti oggetti di rendering in queste aree, si consiglia di disattivarla perché consumerà una piccola quantità di GPU.

• Per gli sviluppatori nativi, fare riferimento a questa guida. È necessario associare il depth buffer prima di chiamare RenderMask; in caso contrario, la chiamata non sarà efficace.
• Per gli sviluppatori Unity, fare riferimento a questa guida.
• Per gli sviluppatori Unreal, attualmente non supporta la funzionalità Render Mask.

3.2 Contenuto MR
3.2.1 Regola la qualità del passthrough
Esistono 3 livelli per la qualità dell'immagine passthrough:
➢ WVR_PassthroughImageQuality_DefaultMode – adatto per contenuti MR senza requisiti specifici.
➢ WVR_PassthroughImageQuality_PerformanceMode: adatto per contenuti MR che necessitano di maggiori risorse GPU per il rendering di scene virtuali.
➢ WVR_PassthroughImageQuality_QualityMode: adatto per i contenuti MR che consentono agli utenti di vedere chiaramente l'ambiente circostante, ma la scena virtuale del contenuto deve avere una messa a punto più precisa per le prestazioni.
È possibile regolare la qualità Passthrough su PerformanceMode per ridurre l'utilizzo della GPU.

• Per gli sviluppatori Native, Uunity o Unreal, fare riferimento a questa guida.

3.2.2 Regola il frame rate passthrough
Come la frequenza di aggiornamento del display, un frame rate Passthrough più elevato offre immagini più fluide, ma comporta un maggiore carico di sistema. Al contrario, frequenze di aggiornamento più basse riducono il carico di sistema, ma comportano immagini meno fluide. Sono disponibili due modalità di frame rate Passthrough: Boost e Normale.

• Gli sviluppatori nativi possono regolare la qualità del passthrough utilizzando WVR_SetPassthroughImageRate.
• Per gli sviluppatori Unity, è possibile modificare tramite codice, ad esempioample impostazioni sono le seguenti // C#
  Interop.WVR_SetPassthroughImageQuality(WVR_PassthroughImageQuality.PerformanceMode);
• Per gli sviluppatori Unreal, per impostare il metodo, vedere il nodo blueprint nella Figura 3-2-2.

Impostazione VIVE OpenXR

OpenXR è uno standard aperto che fornisce un set comune di API per lo sviluppo di applicazioni XR che funzionano su un'ampia gamma di dispositivi VR, sviluppato da Khronos Group. Anche VIVE Focus 3 e VIVE XR Elite supportano OpenXR, VIVE OpenXR SDK fornisce un supporto completo per i dispositivi HTC VR, consentendo agli sviluppatori di creare All-in-One e contenuti con Unity e Unreal Engine sui dispositivi HTC VR. Ottimizziamo e risolviamo continuamente vari bug, quindi si consiglia agli sviluppatori di aggiornare la versione FOTA del proprio dispositivo per mantenerla aggiornata. Attualmente, VIVE OpenXR SDK supporta OpenGL ES e Vulkan.

4.1 Contenuto VR
4.1.1 Frequenza di aggiornamento dello schermo
Il concetto qui è simile a quello della frequenza di aggiornamento del display 3.1.1.

• Per gli sviluppatori nativi, fare riferimento a XrEventDataDisplayRefreshRateChangedFB.
• Per gli sviluppatori Unity, fare riferimento a questa guida.
• Per gli sviluppatori Unreal, fare riferimento a questa guida.

4.1.2 Risoluzione Eyebuffer
Il concetto qui è simile a quello della risoluzione Eyebuffer 3.1.2. Si consiglia di non ridurre il fattore di scala al di sotto di 0.7, poiché ciò potrebbe comportare una qualità visiva inaccettabile.

• Per gli sviluppatori nativi, fare riferimento a xrCreateSwapchain. Quando si modificano le dimensioni, è necessario moltiplicare la larghezza e l'altezza per un rapporto.
• Per gli sviluppatori Unity, fare riferimento al seguente esempioample // C#
  XRSettings.eyeTextureResolutionScale = 0.7f; //consigliato 1.0f~0.7f
• Per le impostazioni Unreal, fare riferimento a questa guida.

4.1.3 Multi-View Rendering
Il concetto qui è simile a 3.1.3 Multi-View Rendering. Questa funzionalità riduce il carico sulla CPU, anche la GPU ha alcuni vantaggi. Raccomandiamo di abilitare questa funzionalità.

• Per gli sviluppatori nativi, KhronosGroup fornisce un OpenXR Multi-View exampfare riferimento a questa guida.
• Per gli sviluppatori Unity, fare riferimento alla modalità di rendering, il passaggio singolo è multiploview caratteristica.
• Per gli sviluppatori Unreal, come per le impostazioni VIVE Wave, fare riferimento a questa guida.

4.1.4 Foveazione [Non supportato irreale]
Il concetto qui è simile a quello della Foveazione 3.1.4. Il rendering foveato è progettato principalmente per ridurre il carico della GPU, ma abilitarlo comporterà un costo fisso in termini di prestazioni della GPU e se la foveazione è impostata su un valore troppo basso e vengono utilizzati determinati materiali o texture, può diventare molto
Percepibile dall'utente. Pertanto, si consiglia di abilitare o disabilitare la funzionalità in base alle proprie esigenze specifiche e alle prestazioni. Attualmente, la funzionalità Foveated è supportata solo in OpenGL ES su VIVE OpenXR SDK.

• Per gli sviluppatori nativi, questa funzionalità è disponibile, ma al momento non è disponibile alcunaampvengono forniti.
• Per gli sviluppatori Unity, fare riferimento a questa guida.
• Per gli sviluppatori Unreal, questa funzionalità non è al momento supportata.

4.1.5 Maschera di rendering [Non supporta Unreal]
Il concetto qui è simile a quello della maschera di rendering 3.1.8.

• Per gli sviluppatori nativi, utilizzare XrVisibilityMaskKHR per ottenere la mesh. Prima di renderizzare la scena, utilizzare questa mesh per popolare i valori del buffer di profondità.
• Per gli sviluppatori Unity, la funzionalità Render Mask è abilitata per impostazione predefinita per OpenGL ES e può essere disabilitata con il seguente codice; Vulkan attualmente non supporta questa funzionalità. //C# UnityEngine.XR.XRSettings.occlusionMaskScale = 0.0f;
• Per gli sviluppatori Unreal, attualmente non supporta la funzionalità Render Mask.

4.2 Contenuto MR
OpenXR al momento non supporta l'impostazione di Passthrough Quality e Frame Rate. Continueremo a ottimizzare e correggere la funzionalità Passthrough, quindi consigliamo agli sviluppatori di aggiornare la versione FOTA del dispositivo per mantenerla aggiornata.

Ottimizzazione comune

5.1 Disattivare la modalità ad alte prestazioni
Disattivare la "Modalità ad alte prestazioni" può ridurre le dimensioni del display del dispositivo, riducendo così l'utilizzo della GPU. Lo svantaggio è una riduzione della risoluzione dello schermo. È possibile bilanciare qualità e prestazioni per decidere se attivarla o meno.
La posizione di impostazione per VIVE Focus 3 è mostrata nella Figura 5-1-1:

La posizione di impostazione per VIVE XR Elite è mostrata nella Figura 5-1-2:

5.2 MultiampAnti-aliasing
multisampling è una tecnica anti-aliasing usata per smussare i bordi frastagliati, solitamente è accelerata tramite hardware, il che comporta un costo in termini di prestazioni della GPU. Si consiglia di non impostare MSAA su un valore superiore a 2x perché un valore più alto consumerà più GPU.

• Per sviluppatori nativi, MSAA OpenGL ES exsamppossiamo fare riferimento a questo; MSAA Vulkan exampler può fare riferimento a questo.
  La GPU Adreno fornisce un'estensione che ottimizza MSAA.
• Per gli sviluppatori Unity, fare riferimento a questa gilda.
• Per gli sviluppatori Unreal, fare riferimento a questa gilda. Unreal fornisce anche l'anti-aliasing in post-elaborazione, fare riferimento a questa gilda.

5.3 Caricamento/memorizzazione GMEM
Nell'architettura GPU Adreno, c'è una funzionalità per cui, quando si associa un Render Target, se il Render Target non si cancella o non si invalida, ogni volta che si verifica il rendering, i valori nel Render Target vengono caricati nella memoria grafica, che si chiama GMEM Load. Se i valori precedenti non sono necessari, cancellare o invalidare il Render Target prima del rendering può evitare questa situazione per migliorare le prestazioni della GPU.
È possibile evitare GMEM Load utilizzando i seguenti metodi. In OpenGL ES, dopo aver associato l'FBO, è possibile chiamare glClear e glClearDepth per cancellare il buffer Color, Depth e Stencil, oppure chiamare glInvalidateFramebuffer per invalidare il Render Target specificato. In Vulkan, non sono necessarie istruzioni aggiuntive; è possibile impostare esplicitamente se cancellare l'allegato prima dell'uso in VkAttachmentDescription.loadOp.
Allo stesso modo, l'archiviazione del risultato di un Tile Render nella Main Memory dalla Graphics Memory è chiamata GMEM Store; questa operazione è anche costosa per la GPU. Per evitarlo, consigliamo di associare solo i Render Target richiesti per impedire operazioni Store non necessarie.

5.4 Livello di composizione (multistrato)
Le texture visualizzate tramite Multi-Layer hanno una migliore qualità visiva. Tuttavia, questa funzionalità aumenta significativamente le prestazioni della GPU con il numero di layer e la dimensione delle texture. Consigliamo di non superare i tre layer.

• Per gli sviluppatori nativi,
  o VIVE Wave SDK utilizza WVR_SubmitFrameLayers per trasmettere i dati per ciascun livello.
  o VIVE OpenXR SDK inserisce i dati del livello in XrFrameEndInfo e li invia tramite xrEndFrame.
• Per gli sviluppatori Unity,
  o Impostazioni VIVE Wave SDK, fare riferimento a questa guida,
  o Per le impostazioni di VIVE OpenXR, fare riferimento a questa guida.
• Per gli sviluppatori Unreal,
  o Per le impostazioni di VIVE Wave SDK, fare riferimento a questa guida.
  o Per le impostazioni di VIVE OpenXR, fare riferimento a questa guida.

Picco della CPU 5.5
Quando il carico della CPU è più elevato, alcuni thread di processi in background con priorità elevata potrebbero interrompere l'esecuzione nativa. Non possiamo garantire che l'applicazione Content non venga interrotta da altri thread.
Se si verificano problemi di questo tipo, puoi provare ad aumentare la priorità del thread per vedere se il problema si risolve. Tuttavia, se modifichi la configurazione del thread per ottimizzarla per i dispositivi, devi verificare se ciò abbia un impatto negativo.

• Per Unity Developer, fare riferimento alla funzionalità di configurazione dei thread di Android. Se si utilizza VIVE Wave SDK, è disponibile una funzionalità in WaveXRSettings che consente di regolare la priorità, come mostrato nella Figura 5-5-2. Un valore più basso rappresenta una priorità più alta.

• Non esiste un metodo per modificare il thread di gioco, il thread di rendering e la priorità del thread RHI tramite impostazioni esterne, a meno che non si modifichi il codice del motore.

Copyright © 2024 HTC Corporation. Tutti i diritti riservati

Documenti / Risorse

Prestazioni di rendering VIVE VR [pdf] Guida utente Prestazioni di rendering VR, Prestazioni di rendering, Prestazioni

Riferimenti

• Manuale d'uso