Brukerveiledning for VIVE VR Rendering Performance

VR-gjengivelsesytelse
Justering og optimaliseringer

Introduksjon

Å oppnå en optimal VR-opplevelse på ressursbegrenset maskinvare er nøkkelen til å levere en smidig og komfortabel brukeropplevelse. Hvis bildefrekvensen for innholdsgjengivelse faller eller er ustabil under enhetens oppdateringsfrekvens, vil det føre til bildevibrering og hakking, reisesyke osv. som til slutt vil påvirke brukeropplevelsen negativt. Derfor er det svært viktig å optimalisere innholdsytelsen for å sikre en hyggelig opplevelse.
Før du starter ytelsesjustering, er det viktig å forstå hvor ytelsesflaskehalsene er for å unngå ineffektiv justering. Dette dokumentet er utformet for å hjelpe utviklere med å identifisere ytelsesflaskehalser og tilby løsninger for å løse problemer med gjengivelsesytelse.
Dokumentet er organisert i følgende seksjoner:

• Kapittel 2: Identifiser flaskehalsen – Denne delen hjelper utviklere med å identifisere hvor flaskehalsene er.
• Kapittel 3 og 4: Innstillinger for VIVE Wave og VIVE OpenXR – Disse avsnittene beskriver spesifikke innstillinger som kan påvirke CPU/GPU-ytelsen for VIVE Wave- og OpenXR-apper. Utviklere kan eksperimentere med å aktivere eller deaktivere disse funksjonene basert på ytelsesflaskehalser som oppstår for å avgjøre om det er noen forbedringer.
• Kapittel 5: Vanlig optimalisering – Denne delen deler noen vanlige optimaliseringspraksiser og erfaringer.

Identifiser flaskehalsen

Når HMD beveger seg, og VR/MR-appen har bildeflimmer eller svart kant osv., skyldes det vanligvis dårlig gjengivelsesytelse. Vanligvis kan problemer med gjengivelsesytelse kategoriseres i to typer: CPU-bundet eller GPU-bundet. Det er svært viktig å forstå hvilke typer bindinger for appen din i begynnelsen for å unngå ineffektiv tuning.
I dette kapittelet gir vi enkle trinn som lar deg raskt identifisere hvor ytelsesproblemene er.

2.1 Sjekk innholdsgjengivelse FPS
Først begynner vi med å sjekke innholdets FPS, det vil si antall bilder innholdet gjengir per sekund. Den bør holdes innenfor skjermens bildefrekvens og holdes stabil. Ellers kan det føre til bildejitter.
Hvis applikasjons-SDK-en din bruker VIVE WAVE SDK 6.0.0 eller nyere, kan du bruke følgende adb-kommando for å sjekke FPS-en. DK 6.0.0
$adb Logcat -s VRMetric
Du vil se følgende loggdata.
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». Det første tallet representerer innholdets FPS, mens det andre tallet representerer skjermens bildefrekvens.
Hvis Wave SDK-versjonen din er eldre enn 6.0.0, anbefales det å oppgradere til den nyeste versjonen for å forbedre gjengivelsesytelsen og annen optimalisering.
Hvis applikasjons-SDK-en din er bygget med VIVE OpenXR, kan du bruke følgende adb-kommando for å sjekke FPS-en.
$adb Logcat -s RENDER_ATW
Du vil se følgende loggdata
RENDER_ATW: [FPS] ny tekstur: 90.00
RENDER_ATW: [FPS] R tilstede: 90.00 hopp over: 0 317, -0.0155 0.805527, 0.006788)
RENDER_ATW: [FPS] L present:90.00 skip:0 (0.592301, -0.015502, 0.805539, 0.006773)

Tallet etter «ny tekstur» representerer den nåværende FPS-en. Tallet etter «R til stede» og «L til stede» representerer bildefrekvensen på skjermen.
Noen ganger kan innholdets FPS og skjermens bildefrekvens ha et lite avvik.
For eksampI tilfellet ovenfor kan 89.8 FPS betraktes som 90 FPS.
Hvis appens innholds-FPS konsekvent er lavere enn skjermens bildefrekvens eller forblir ustabil, indikerer det et problem med gjengivelsesytelsen. Derfor er neste trinn å identifisere om flaskehalsen kommer fra CPU-en eller GPU-en.
2.2 Sjekk CPU- og GPU-bruk
Hvis applikasjons-SDK-en din bruker VIVE WAVE SDK 6.0.0 eller nyere, kan du bruke følgende adb-kommando for å sjekke FPS-en.
$adb logcat -s VRMetric
Du vil se følgende loggdata.
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
Som du kan se i loggresultatet ovenfor, er CPU-bruken 27 % og GPU-bruken 72 %. Hvis Wave SDK-versjonen din er eldre enn 6.0.0, anbefales det å oppgradere til den nyeste versjonen for å forbedre gjengivelsesytelsen og annen optimalisering.
For VIVE OpenXR-appen kan du bruke følgende kommando for å sjekke CPU- og GPU-bruken.
# på Linux/Ubuntu
$ adb logcat | grep CPU_USAGE
# på powershell
$ adb logcat | Velg-String -Mønster CPU_USAGE
Du vil se følgende logg
CPU-gjennomsnitt CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 GPU CPU_BRUK [LAST] 25.67 % 32.22 % 25.29 % 30.77 % 29.35 % 21.35 % 22.09 % 18.39 % 24.14 % 73 %
Hvis du observerer at FPS-en ikke kan opprettholde skjermens bildefrekvens, og GPU-bruken også er veldig høy, vanligvis over 85 %, kan du prøve å justere Eyebuffer-oppløsningen (avsnitt 3.1.2, avsnitt 4.1.2) for å se om det forbedrer FPS-en. Hvis denne justeringen fører til bedre
ytelse, kan vi konkludere med at problemet er GPU-bundet og fokusere optimaliseringsarbeidet vårt deretter.
Hvis justering av øyebufferoppløsningen derimot ikke resulterer i en merkbar ytelsesforbedring, er flaskehalsen sannsynligvis CPU-bundet, og vi bør fokusere på å optimalisere CPU-ytelsen.
Det er også mulig at applikasjonen er både CPU-bundet og GPU-bundet samtidig. I slike tilfeller bør optimaliseringstiltak iverksettes på både CPU og GPU for å oppnå balanserte ytelsesforbedringer.
2.3 GPU-bundet
Når en VR-app er GPU-bundet, betyr det at GPU-en er den primære flaskehalsen, og den klarer ikke å holde tritt med gjengivelseskravene til applikasjonen. For å redusere GPU-bundne problemer, bør du vurdere følgende anbefalinger:
Bruk først profileringsverktøy som RenderDoc eller Game Engine Profiler (Unity Profiler, Unreal Insights) for å analysere hvor GPU-en bruker mesteparten av tiden sin. Identifiser de mest kostbare operasjonene og fokuser på å optimalisere dem.
For Native Developer kan du bruke RenderDoc til å identifisere hvilket tegnekall som forårsaker overdreven GPU-belastning.
For Unity-utviklere kan du følge dette dokumentet for Unity eller bruke RenderDoc til å analysere problemer med gjengivelsesytelse, og følge dokumentasjonen for grafikkoptimalisering for Unity for veiledning for å optimalisere applikasjonen din.
For Unreal Developer kan du bruke GPU Visualizer eller RenderDoc til å analysere problemer med gjengivelsesytelse, og følge Unreal Performance Guidelines for veiledning for å optimalisere applikasjonen din.
For det andre kan du også prøve å justere visse Wave-funksjoner eller -innstillinger for å redusere GPU-belastningen.

1. Sett skjermoppdateringsfrekvensen til lavere (avsnitt 3.1.1, avsnitt 4.1.1)
2.  Juster øyebufferoppløsning (avsnitt 3.1.2, avsnitt 4.1.2), 14.1.1)
3.  Prøv å aktivere Foveation (avsnitt 3.1.4, avsnitt 4.1.4).

Hvis appen din også er en MR-app, kan du også justere Passthrough-innstillingene.

1. Juster Passthrough Image Quality lavere. (avsnitt 3.2.1)
2. Juster Passthrough-bildefrekvensen til en lavere hastighet (avsnitt 3.2.2).

For flere innstillinger om GPU-ytelse, kan du se kapittel 2.6.

2.4 CPU-bundet
Når en VR-app er CPU-bundet, betyr det at CPU-en er den primære flaskehalsen. Vurder følgende anbefalinger:
Bruk først profileringsverktøy som Systrace eller Game Engine Profiler (Unity Profiler, Unreal Insights) for å analysere og identifisere hvilke deler av koden din som bruker mest CPU-ressurser. Fokuser på å optimalisere disse områdene og refaktorer beregningsintensive algoritmer for å redusere CPU-belastningen.

• For Native Developers kan du bruke Systrace til profiletil prosjektet ditt.
• For Unity Developer kan du bruke CPU Usage Profiler-modulen for å finne problemer med CPU-ytelsen.
• For Unreal Developer kan du bruke Unreals Insights for å finne problemer med CPU-ytelse.

For det andre kan du også prøve å justere visse Wave-funksjoner eller -innstillinger for å redusere GPU-belastningen.

1. Sett skjermoppdateringsfrekvensen til lavere (avsnitt 3.1.1, avsnitt 4.1.1)
2.  Bruk Multi-View Rendering (avsnitt 3.1.4, avsnitt 4.1.4)

Hvis appen din også er en MR-app, kan du også justere Passthrough-innstillingene.

1. Juster Passthrough-bildefrekvensen til en lavere hastighet (avsnitt 3.2.2).

For flere innstillinger om CPU-ytelse, kan du se kapittel 2.6.

2.5 Sammendrag
Til slutt har vi organisert arbeidsflyten for ytelsessjekk ovenfor i figur 2-5-1. Start med å sjekke innholdets FPS. Hvis den er lavere enn skjermens bildefrekvens eller forblir ustabil, analyser GPU/CPU-bruken for å avgjøre om den er GPU-bundet eller CPU-bundet. Til slutt, bruk en profesjonellfiler for å identifisere potensielle ytelsesproblemer eller justere Wave-funksjoner eller -innstillinger for å optimalisere CPU-ytelsen.

2.6 Hurtigreferanse Hvilke innstillinger kan forbedre CPU/GPU-belastning

List opp innstillingene til SDK-en som er relatert til CPU/GPU-belastning som vist nedenfor. Du kan bruke appens flaskehals til å sjekke de relevante optimaliseringsinnstillingene.

Relatert til CPU:

• VIVE Wave SDK-innstilling
  o VR-innhold
  ▪ 3.1.1 Skjermens oppdateringsfrekvens
  ▪ 3.1.4 Multi-View Gjengivelse
  ▪ 3.1.6 Adaptiv kvalitet
  ▪ 3.1.7 Adaptiv bevegelseskompositor
  o MR-innhold
  ▪ 3.2.2 Juster gjennomgangsfrekvens for bilde
• VIVE OpenXR SDK-innstilling
  o VR-innhold
  ▪ 4.1.1 Skjermens oppdateringsfrekvens
  ▪ 4.1.4 Multi-View Gjengivelse
• Vanlig optimalisering
  o 5.5 CPU-topper

Relatert til GPU:

• VIVE Wave SDK-innstilling
  o VR-innhold
  ▪ 3.1.1 Skjermens oppdateringsfrekvens
  ▪ 3.1.2 Øyebufferoppløsning
  ▪ 3.1.3 Multi-View Gjengivelse
  ▪ 3.1.4 Foveasjon
  ▪ 3.1.5 Forbedring av bildeskarphet (FSE)
  ▪ 3.1.6 Adaptiv kvalitet
  ▪ 3.1.7 Adaptiv bevegelseskompositor
  ▪ 3.1.8 Render Mask [Not Support Unreal]
  o MR-innhold
  ▪ 3.2.1 Juster gjennomgangskvalitet
  ▪ 3.2.2 Juster gjennomgangsfrekvens for bilde
• VIVE OpenXR SDK-innstilling
  o VR-innhold
  ▪ 4.1.1 Skjermens oppdateringsfrekvens
  ▪ 4.1.2 Øyebufferoppløsning
  ▪ 4.1.3 Multi-View Gjengivelse
  ▪ 4.1.4 Foveation [Not Support Unreal]
  ▪ 4.1.5 Render Mask [Not Support Unreal]
• Vanlig optimalisering
  o 5.1 Slå av høyytelsesmodus
  o 5.2 Multisampling
  o 5.3 GMEM Last inn/lagre
  o 5.4 Komposisjonslag (flerlag)

VIVE Wave-innstilling

VIVE Wave er en åpen plattform og et verktøysett som lar deg enkelt utvikle VR-innhold og tilbyr enhetsoptimalisering med høy ytelse for tredjepartspartnere. VIVE Wave støtter spillmotorer for Unity og Unreal.
Vi optimaliserer og løser kontinuerlig diverse feil, så vi anbefaler å holde SDK-en oppdatert.
For øyeblikket støtter VIVE Wave bare OpenGL ES. Her er funksjonene sortert etter påvirkning på GPU-ytelse. Vi deler dette inn i to deler: VR-innhold og MR-innhold.
3.1 VR-innhold
3.1.1 Skjermens oppdateringsfrekvens

Høyere oppdateringsfrekvenser gir jevnere bilder, men kommer på bekostning av økt systembelastning. Omvendt reduserer lavere oppdateringsfrekvenser systembelastningen, men resulterer i mindre jevne bilder. Hvis appen har et problem med CPU/GPU-binding, kan du prøve å redusereasinjustere skjermens oppdateringsfrekvens for å løse problemet.

• For native utviklere, se WVR_SetFrameRate.
• For Unity-utviklere, se denne veiledningen.
• For Unreal-utviklere, se denne veiledningen.

3.1.2 Øyebufferoppløsning
Øyebufferoppløsningen er teksturstørrelsen som innholdsappen skal gjengis. Den gjengitte teksturen sendes til kjøretiden for å utføre publiseringsprosessen og vises på HMD-skjermen.
Selv om en større øyebufferstørrelse kan resultere i klarere og mer detaljerte bilder, legger det også en betydelig belastning på GPU-en. Derfor er det viktig å finne den rette balansen mellom visuell kvalitet og ytelse.
Hvis appen har et problem med GPU-binding, kan du prøve å redusereasinØk øyebufferstørrelsen ved å multiplisere med en skaleringsfaktor. Vi anbefaler imidlertid å ikke redusere skaleringsfaktoren til under 0.7, da dette kan føre til uakseptabel visuell kvalitet.

• For native utviklere, se WVR_ObtainTextureQueue. Når du justerer størrelsen, bør du multiplisere bredden og høyden med et forhold.
• For Unity-utviklere, se WaveXRSettings.
  Alternativt kan du gjøre endringer via koden som vist nedenfor.
  XRSettings.eyeTextureResolutionScale = ResolutionScaleValue; // C#
• For Unreal-utviklere, se SetPixelDensity.

3.1.3 Multi-View Gjengivelse
I tradisjonell rendering tegner vi venstre og høyre øye separat, noe som krever to tegneanrop for samme scene.View Rendering løser dette problemet ved å bare utføre ett tegnekall.
Denne funksjonen reduserer CPU-belastningen medasing antall tegnekall. GPU-en har også noen fordeler, arbeidsmengden til vertex-shaderen reduseres også siden den ikke trenger å kjøre en ekstra shader for det andre øyet, men arbeidsmengden til fragment-shaderen forblir uendret siden den fortsatt må evaluere hver piksel for begge øyne. Vi anbefaler å aktivere denne funksjonen.

• For native utviklere kan du se wvr_native_hellovr.ample.
• For Unity-utviklere, se Render Mode, enkeltpassering er flerpassering.view trekk.
• For Unreal-utviklere, se denne veiledningen.

3.1.4 Foveasjon
Foveated rendering er primært utformet for å redusere GPU-belastningen. Den reduserer bildedetaljer i skjermens periferi og opprettholder detaljer med høy oppløsning i midten av feltet. viewHvis appen har et problem med GPU-binding, kan du prøve å aktivere Foveation-gjengivelse.

Det er noe du må merke deg når du bruker foveation:

➢ Brukere legger vanligvis ikke merke til den reduserte detaljmengden i perifere områder når standard foveasjonsmodus brukes. Men hvis den perifere foveasjonskvaliteten er satt for lavt, kan det bli merkbart for brukeren.
➢ Effektene av foveasjon kan være mer merkbare med visse materialer eller teksturer, noe som kan fange brukerens oppmerksomhet. Utviklere bør være klar over dette og vurdere det deretter.
➢ Aktivering av foveated rendering-funksjonen medfører en fast GPU-ytelseskostnad, som kan variere mellom 1 % og 6 % avhengig av størrelsen på øyebufferen. Når man bruker en enkel shader i scenen, kan ytelsesgevinsten fra å spare ressurser være lavere enn den faste GPU-ytelseskostnaden, noe som resulterer i et ytelsesfall.

• For native utviklere, se denne veiledningen.
• For Unity-utviklere, se denne veiledningen. Merk at når du aktiverer etterbehandling eller HDR, kan ikke foveasjon utnyttes fullt. Fordi Unity vil gjengi objekter på sin egen genererte rendertekstur, i stedet for den kjøretidsgenererte presentasjonens rendertekstur som støtter foveasjon.
• For Unreal-utviklere, se denne veiledningen. Merk at foveation ikke kan utnyttes fullt ut på Multi-View Gjengivelse, fordi Unreal ikke kan gjengi objekter direkte på den kjøretidsgenererte gjengivelsesteksturen som støtter foveation.

3.1.5 Forbedring av bildeskarphet (FSE)
FSE gir skjerpet gjengivelse ved å introdusere skjerpefilter. Det kan gjøre innhold tydeligere og være svært nyttig for å forbedre klarheten til teksten i scenen. Hvis appen har et problem med GPU-binding, kan du vurdere å deaktivere FSE hvis det ikke er nødvendig.

• For native utviklere, se denne veiledningen.
• For Unity-utviklere, se denne veiledningen.
• For Unreal-utviklere, se denne veiledningen.

3.1.6 Adaptiv kvalitet
For å spare batteri og opprettholde enhetens gjengivelsesytelse justerer denne funksjonen automatisk ytelsesnivåene til CPU/GPU-klokken basert på bruken. I tillegg kan andre strategier implementeres for å forbedre ytelsen, for eksempel automatisk aktivering/deaktivering av Foveation eller at innhold kan justere seg selv hvis det mottar hendelser med høy/lav belastning.

• For native utviklere, se denne veiledningen.
• For Unity-utviklere, se denne veiledningen. I Unity-pluginen vår kan øyebufferstørrelsen justeres automatisk basert på gjeldende ytelse. Tekststørrelsen vil filtrere ut skaleringsverdier som er for små i oppløsningslisten. Vi anbefaler tekst med en størrelse på minst 20 dmm eller større.
• For Unreal-utviklere, se denne veiledningen.

3.1.7 Adaptiv bevegelseskompositor
Denne funksjonen er en eksperimentell funksjon som inkluderer UMC og PMC. UMC reduserer bildefrekvensen med halvparten og ekstrapolerer nye bilder i sanntid for å opprettholde visuell jevnhet. Den kommer imidlertid med noe latens, artefakter og GPU-belastning.
PMC bruker primært dybdebufferen for å la ATW ta hensyn til HMD-oversettelse, utvidet til en 6-dof-kompensasjon. Denne funksjonen kan redusere oversettelseslatensen med 1–2 bilder, men øke GPU-belastningen.

• For native utviklere, se denne veiledningen.
• For Unity-utviklere, se denne veiledningen.
• For Unreal-utviklere, se denne veiledningen.

3.1.8 Rendermaske [Støtter ikke Unreal]
Piksler i kantene blir nesten usynlige etter forvrengning. Rendermasken endrer dybdebufferverdiene for disse usynlige pikslene. Hvis du aktiverer dybdetesting, vil ikke disse usynlige pikslene bli gjengitt på grunn av early-z, noe som reduserer GPU-belastningen. Denne funksjonen er nyttig hvis det er gjengivelsesobjekter med høy belastning i disse usynlige områdene. Hvis det ellers ikke er noen gjengivelsesobjekter i disse områdene, anbefales det å deaktivere den, fordi den vil bruke lite GPU-bruk.

• For native utviklere, se denne veiledningen. Du må binde dybdebufferen før du kaller RenderMask; ellers vil den være ineffektiv.
• For Unity-utviklere, se denne veiledningen.
• For Unreal-utviklere støttes for øyeblikket ikke Render Mask-funksjonen.

3.2 MR-innhold
3.2.1 Juster gjennomgangskvalitet
Det er tre nivåer for gjennomgangsbildekvalitet:
➢ WVR_PassthroughImageQuality_DefaultMode – egnet for MR-innhold uten spesifikk etterspørsel.
➢ WVR_PassthroughImageQuality_PerformanceMode – egnet for MR-innhold som trenger mer GPU-ressurser for gjengivelse av virtuelle scener.
➢ WVR_PassthroughImageQuality_QualityMode – egnet for MR-innhold som lar brukerne se omgivelsene tydelig, men den virtuelle scenen med innhold må ha mer finjustering for ytelse.
Du kan justere Passthrough-kvaliteten til PerformanceMode for å redusere GPU-bruken.

• For Native-, Uunity- eller Unreal-utviklere, se denne veiledningen.

3.2.2 Juster gjennomgangsbildefrekvens
I likhet med skjermens oppdateringsfrekvens gir høyere gjennomgangsbildefrekvens jevnere bilder, men det kommer på bekostning av økt systembelastning. Omvendt reduserer lavere oppdateringsfrekvenser systembelastningen, men resulterer i mindre jevne bilder. Det finnes to moduser for gjennomgangsbildefrekvens: Boost og Normal.

• For native utviklere kan passthrough-kvaliteten justeres ved hjelp av WVR_SetPassthroughImageRate.
• For Unity-utviklere, kan endres via kode, f.eks.ampInnstillingene er som følger // C#
  Interop.WVR_SetPassthroughImageQuality(WVR_PassthroughImageQuality.PerformanceMode);
• For Unreal-utvikleren, se blåkopi-noden i figur 3-2-2 for å sette opp metoden.

VIVE OpenXR-innstilling

OpenXR er en åpen standard som tilbyr et felles sett med API-er for utvikling av XR-applikasjoner som kjører på tvers av et bredt spekter av VR-enheter, utviklet av Khronos Group. VIVE Focus 3 og VIVE XR Elite støtter også OpenXR. VIVE OpenXR SDK gir omfattende støtte for HTC VR-enheter, slik at utviklere kan bygge All-in-One og innhold med Unity og Unreal Engine på HTC VR-enheter. Vi optimaliserer og løser kontinuerlig ulike feil, så det anbefales at utviklere oppdaterer enhetens FOTA-versjon for å holde den oppdatert. For øyeblikket støtter VIVE OpenXR SDK OpenGL ES og Vulkan.

4.1 VR-innhold
4.1.1 Skjermens oppdateringsfrekvens
Konseptet her ligner på 3.1.1 Display Refresh Rate.

• For native utviklere, se XrEventDataDisplayRefreshRateChangedFB.
• For Unity-utviklere, se denne veiledningen.
• For Unreal-utviklere, se denne veiledningen.

4.1.2 Øyebufferoppløsning
Konseptet her ligner på 3.1.2 Eyebuffer Resolution. Vi anbefaler å ikke redusere skaleringsfaktoren til under 0.7, da dette kan føre til uakseptabel visuell kvalitet.

• For native utviklere, se xrCreateSwapchain. Når du justerer størrelsen, bør du multiplisere bredden og høyden med et forhold.
• For Unity-utviklere, se følgende eksempelample // C#
  XRSettings.eyeTextureResolutionScale = 0.7f; //anbefalt 1.0f~0.7f
• For Unreal-innstillinger, se denne veiledningen.

4.1.3 Multi-View Gjengivelse
Konseptet her ligner på 3.1.3 Multi-View Rendering. Denne funksjonen reduserer belastningen på CPU-en, og GPU-en har også noen fordeler. Vi anbefaler å aktivere denne funksjonen.

• For native utviklere tilbyr KhronosGroup en OpenXR Multi-View example, se denne veiledningen.
• For Unity-utviklere, se Render Mode, enkeltpassering er flerpassering.view trekk.
• For Unreal-utviklere, som med VIVE Wave-innstillinger, se denne veiledningen.

4.1.4 Foveasjon [Ikke støttet uvirkelig]
Konseptet her ligner på 3.1.4 Foveation. Foveated rendering er primært designet for å redusere GPU-belastningen, men aktivering vil medføre en fast GPU-ytelseskostnad, og hvis foveation er satt for lavt og visse materialer eller teksturer brukes, kan det bli veldig
merkbar for brukeren. Derfor anbefales det å aktivere eller deaktivere funksjonen basert på dine spesifikke krav og ytelseshensyn. For øyeblikket støttes Foveated-funksjonalitet bare i OpenGL ES på VIVE OpenXR SDK.

• For native utviklere er denne funksjonen tilgjengelig, men for øyeblikket ingen eksempleramples er gitt.
• For Unity-utviklere, se denne veiledningen.
• For Unreal-utviklere støtter ikke denne funksjonen for øyeblikket.

4.1.5 Rendermaske [Støtter ikke Unreal]
Konseptet her ligner på 3.1.8 Render Mask.

• For Native-utviklere, bruk XrVisibilityMaskKHR for å hente meshen. Før scenen gjengis, bruk denne meshen til å fylle ut dybdebufferverdiene før scenen gjengis.
• For Unity-utviklere er Render Mask-funksjonen aktivert som standard for OpenGL ES, og kan deaktiveres med følgende kode; Vulkan støtter for øyeblikket ikke denne funksjonen. //C# UnityEngine.XR.XRSettings.occlusionMaskScale = 0.0f;
• For Unreal-utviklere støttes for øyeblikket ikke Render Mask-funksjonen.

4.2 MR-innhold
OpenXR støtter for øyeblikket ikke innstilling av gjennomgangskvalitet og bildefrekvens. Vi vil fortsette å optimalisere og fikse gjennomgangsfunksjonen, så vi anbefaler at utviklere oppdaterer enhetens FOTA-versjon for å holde den oppdatert.

Vanlig optimalisering

5.1 Slå av høyytelsesmodus
Å slå av «Høy ytelsesmodus» kan redusere skjermstørrelsen på enheten, og dermed redusere GPU-bruken. Ulempen er en reduksjon i skjermoppløsningen. Du kan balansere kvalitet og ytelse for å bestemme om du vil aktivere det.
Innstillingsstedet for VIVE Focus 3 er vist i figur 5-1-1:

Innstillingsstedet for VIVE XR Elite er vist i figur 5-1-2:

5.2 Multierampling Anti-Aliasing
Multiampling er en anti-aliasing-teknikken som brukes til å glatte ut hakkete kanter, akselereres vanligvis av maskinvare, noe som medfører kostnader for GPU-ytelse. Vi anbefaler ikke å sette MSAA høyere enn 2x fordi en høyere høydeverdi vil forbruke mer GPU-bruk.

• For native utviklere, MSAA OpenGL ES exsample kan referere til dette; MSAA Vulkan eksampler kan referere til dette.
  Adreno GPU-en tilbyr en utvidelse som optimaliserer MSAA.
• For Unity-utviklere, se denne lauget.
• For Unreal-utviklere, se denne lauget. Unreal tilbyr også etterbehandling av anti-aliasing, referer til dette lauget.

5.3 Lasting/lagring av GMEM
I Adreno GPU-arkitekturen finnes det en funksjon der, når et Render Target bindes, hvis Render Target ikke fjernes eller ugyldiggjøres, lastes verdiene i Render Target inn i grafikkminnet hver gang rendering skjer, som kalles GMEM-innlasting. Hvis de foregående verdiene ikke er nødvendige, kan du fjerne eller ugyldiggjøre Render Target før rendering for å unngå denne situasjonen for å forbedre GPU-ytelsen.
Du kan unngå GMEM-innlasting ved å bruke følgende metoder. I OpenGL ES, etter å ha bundet FBO-en, kan du kalle glClear og glClearDepth for å tømme farge-, dybde- og sjablongbufferen, eller kalle glInvalidateFramebuffer for å ugyldiggjøre det angitte gjengivelsesmålet. I Vulkan er ikke ytterligere instruksjoner nødvendige; du kan eksplisitt angi om vedlegget skal tømmes før bruk i VkAttachmentDescription.loadOp.
På samme måte kalles lagring av resultatet av en flisrendering tilbake til hovedminnet fra grafikkminnet GMEM-lagring; denne operasjonen er også dyr for GPU-en. For å unngå dette anbefaler vi å bare binde de nødvendige renderingsmålene for å forhindre unødvendige lagringsoperasjoner.

5.4 Komposisjonslag (flerlag)
Teksturer som vises med flerlagsfunksjonalitet har bedre visuell kvalitet. Denne funksjonen øker imidlertid GPU-ytelsen betydelig med antall lag og størrelsen på teksturene. Vi anbefaler ikke over tre lag.

• For native utviklere,
  o VIVE Wave SDK bruker WVR_SubmitFrameLayers til å sende inn data for hvert lag.
  o VIVE OpenXR SDK plasserer lagdata i XrFrameEndInfo og sender dem inn via xrEndFrame.
• For Unity-utvikleren,
  o VIVE Wave SDK-innstillinger, se denne veiledningen,
  o VIVE OpenXR-innstillinger, se denne veiledningen.
• For Unreal-utvikleren,
  o VIVE Wave SDK-innstillinger, se denne veiledningen.
  o VIVE OpenXR-innstillinger, se denne veiledningen.

5.5 CPU-topper
Når CPU-belastningen er høy, og noen bakgrunnsprosesser med tråder har høy prioritet, kan det forstyrre den opprinnelige kjøringen. Vi kan ikke garantere at innholdsapplikasjonen ikke vil bli avbrutt av andre tråder.
Hvis slike problemer oppstår, kan du prøve å økeasinKontroller trådprioriteten for å se om det løser problemet. Men hvis du endrer trådkonfigurasjonen for å optimalisere for enheter, må du sjekke om dette har noen negativ innvirkning.

• For Unity-utviklere, se funksjonen for konfigurasjon av Android-tråder. Hvis du bruker VIVE Wave SDK, har vi en funksjon i WaveXRSettings som lar deg justere prioriteten, som vist i figur 5-5-2. Den minste verdien representerer høyere prioritet.

• Det er uvirkelig ingen metode for å endre prioriteten til spilltråden, gjengivelsestråden og RHI-tråden gjennom eksterne innstillinger med mindre du endrer motorkoden.

Opphavsrett © 2024 HTC Corporation. Alle rettigheter forbeholdt.