VIVE VR Rendering Prestatie Gebruikershandleiding

VR-renderingprestaties
Tuning en optimalisaties

Invoering

Het bereiken van een optimale VR-ervaring op hardware met beperkte resources is essentieel voor een soepele en comfortabele gebruikerservaring. Als de framesnelheid van de contentweergave daalt of instabiel wordt onder de vernieuwingsfrequentie van het apparaat, leidt dit tot frame-judder en haperingen, bewegingsziekte, enz., wat uiteindelijk een negatieve invloed heeft op de gebruikerservaring. Daarom is het optimaliseren van de contentprestaties erg belangrijk om een ​​prettige ervaring te garanderen.
Voordat u met prestatie-tuning begint, is het belangrijk om te begrijpen waar de prestatieknelpunten zitten om inefficiënte tuning te voorkomen. Dit document is bedoeld om ontwikkelaars te helpen prestatieknelpunten te identificeren en oplossingen te bieden voor problemen met de renderingprestaties.
Het document is onderverdeeld in de volgende secties:

• Hoofdstuk 2: Identificeer de knelpunten – Deze sectie helpt ontwikkelaars bij het identificeren van de knelpunten.
• Hoofdstuk 3 en 4: VIVE Wave- en VIVE OpenXR-instellingen – Deze secties beschrijven specifieke instellingen die van invloed kunnen zijn op de CPU-/GPU-prestaties van VIVE Wave- en OpenXR-apps. Ontwikkelaars kunnen experimenteren met het in- of uitschakelen van deze functies op basis van de aangetroffen prestatieknelpunten om te bepalen of er verbetering optreedt.
• Hoofdstuk 5: Algemene optimalisatie – In dit gedeelte worden enkele algemene optimalisatiepraktijken en -ervaringen besproken.

Identificeer de knelpunten

Wanneer HMD beweegt, en de VR/MR-app last heeft van framejitter of een zwarte rand, enz., dan wordt dit meestal veroorzaakt door een probleem met slechte renderingprestaties. Problemen met renderingprestaties kunnen doorgaans worden onderverdeeld in twee typen: CPU-gebonden of GPU-gebonden. Het is erg belangrijk om te begrijpen welke typen binding voor uw app van tevoren zijn vastgesteld om inefficiënte tuning te voorkomen.
In dit hoofdstuk vindt u eenvoudige stappen waarmee u snel kunt vaststellen waar de prestatieproblemen zich voordoen.

2.1 Controleer de FPS van de inhoudsweergave
Eerst controleren we de FPS van de content, oftewel het aantal frames dat de content per seconde rendert. Deze moet gelijk blijven aan de framerate van het scherm en stabiel blijven. Anders kunnen er frame jitters ontstaan.
Als uw applicatie-SDK VIVE WAVE SDK 6.0.0 of later gebruikt, kunt u de volgende adb-opdracht gebruiken om de FPS te controleren. DK 6.0.0
$adb Logcat -s VRMetric
U ziet de volgende loggegevens.
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” Het eerste getal geeft de FPS van de inhoud weer, terwijl het tweede getal de framerate van de weergave weergeeft.
Als uw Wave SDK-versie lager is dan 6.0.0, raden we u aan om te upgraden naar de nieuwste versie om de renderingprestaties en andere optimalisaties te verbeteren.
Als uw applicatie-SDK is gebouwd met VIVE OpenXR, kunt u de volgende adb-opdracht gebruiken om de FPS te controleren.
$adb Logcat -s RENDER_ATW
U ziet de volgende loggegevens
RENDER_ATW: [FPS] nieuwe textuur: 90.00
RENDER_ATW: [FPS] R aanwezig: 90.00 overslaan: 0 317, -0.0155 0.805527, 0.006788)
RENDER_ATW: [FPS] L aanwezig: 90.00 overslaan: 0 (0.592301, -0.015502, 0.805539, 0.006773)

Het getal na "nieuwe textuur" geeft de huidige FPS van de content weer. Het getal na "R aanwezig" en "L aanwezig" geeft de framerate van de weergave weer.
Soms kan er een klein verschil zijn tussen de FPS van de inhoud en de framerate die wordt weergegeven.
BijvoorbeeldampIn bovenstaand geval kan 89.8 FPS dus als 90 FPS worden beschouwd.
Als de FPS van de app-content consistent lager is dan de framerate van het scherm of instabiel blijft, wijst dit op een probleem met de renderingprestaties. De volgende stap is daarom om te bepalen of de bottleneck bij de CPU of de GPU ligt.
2.2 Controleer CPU- en GPU-gebruik
Als de SDK van uw toepassing VIVE WAVE SDK 6.0.0 of later gebruikt, kunt u de volgende adb-opdracht gebruiken om de FPS te controleren.
$adb logcat -s VRMetric
U ziet de volgende loggegevens.
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
Zoals u in het bovenstaande logresultaat kunt zien, bedraagt ​​het CPU-gebruik 27% en het GPU-gebruik 72%. Als uw Wave SDK-versie lager is dan 6.0.0, raden wij u aan om te upgraden naar de nieuwste versie om de renderingprestaties en andere optimalisaties te verbeteren.
Voor de VIVE OpenXR-app kunt u de volgende opdracht gebruiken om het CPU- en GPU-gebruik te controleren.
# op Linux/Ubuntu
$ adb logcat | grep CPU_GEBRUIK
# op PowerShell
$ adb logcat | Select-String -Patroon CPU_USAGE
U ziet het volgende logboek
CPU Gem. CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 GPU CPU_GEBRUIK [BELASTING] 25.67% 32.22% 25.29% 30.77% 29.35% 21.35% 22.09% 18.39% 24.14% 73 %
Als u merkt dat de FPS de framesnelheid van het scherm niet kan handhaven en het GPU-gebruik ook erg hoog is, meestal meer dan 85%, kunt u proberen de Eyebuffer-resolutie aan te passen (paragraaf 3.1.2, paragraaf 4.1.2) om te zien of dit de FPS verbetert. Als deze aanpassing tot betere resultaten leidt,
prestaties, kunnen we concluderen dat het probleem aan de GPU ligt en onze optimalisatie-inspanningen hierop afstemmen.
Als het aanpassen van de Eyebuffer-resolutie echter niet leidt tot een merkbare verbetering van de prestaties, ligt de bottleneck waarschijnlijk bij de CPU en moeten we ons richten op het optimaliseren van de CPU-prestaties.
Het is ook mogelijk dat de applicatie tegelijkertijd CPU- en GPU-gebonden is. In dergelijke gevallen moeten optimalisaties worden toegepast op zowel de CPU als de GPU om evenwichtige prestatieverbeteringen te bereiken.
2.3 GPU-gebonden
Wanneer een VR-app GPU-gebonden is, betekent dit dat de GPU de primaire bottleneck is en de renderingseisen van de applicatie niet kan bijhouden. Om GPU-gebonden problemen te beperken, kunt u de volgende aanbevelingen overwegen:
Gebruik eerst profileringshulpmiddelen zoals RenderDoc of Game Engine Profiler (Unity Profile(r, Unreal Insights) om te analyseren waar de GPU het grootste deel van zijn tijd doorbrengt. Identificeer de duurste bewerkingen en concentreer u op de optimalisatie ervan.
Voor Native Developers kunt u RenderDoc gebruiken om te identificeren welke draw call overmatige GPU-belasting veroorzaakt.
Voor Unity Developer kunt u dit document volgen of RenderDoc gebruiken om problemen met de renderingprestaties te analyseren. Raadpleeg de documentatie voor grafische optimalisatie van Unity voor hulp bij het optimaliseren van uw toepassing.
Voor Unreal Developer kunt u GPU Visualizer of RenderDoc gebruiken om problemen met de renderingprestaties te analyseren. Volg de Unreal Performance Guidelines voor hulp bij het optimaliseren van uw toepassing.
Ten tweede kunt u proberen bepaalde Wave-functies of -instellingen aan te passen om de GPU-belasting te verminderen.

1. Vernieuwingsfrequentie van het beeldscherm lager instellen (sectie 3.1.1, sectie 4.1.1)
2.  Oogbufferresolutie aanpassen (sectie 3.1.2, sectie 4.1.2), 14.1.1)
3.  Probeer Foveation in te schakelen (sectie 3.1.4, sectie 4.1.4).

Als uw app ook een MR-app is, kunt u ook de Passthrough-instellingen aanpassen.

1. Pas de passthrough-beeldkwaliteit lager aan. (paragraaf 3.2.1)
2. Pas de passthrough-framerate aan zodat deze langzamer wordt (sectie 3.2.2).

Raadpleeg Hoofdstuk 2.6 voor meer andere instellingen over GPU-prestaties.

2.4 CPU-gebonden
Als een VR-app CPU-gebonden is, betekent dit dat de CPU de primaire bottleneck is. Houd rekening met de volgende aanbevelingen:
Gebruik eerst profileringshulpmiddelen zoals Systrace of Game Engine Profiler (Unity Profiler, Unreal Insights) om te analyseren en te identificeren welke delen van uw code de meeste CPU-bronnen verbruiken. Concentreer u op het optimaliseren van deze gebieden en het herstructureren van rekenintensieve algoritmen om de CPU-belasting te verminderen.

• Voor Native Developer kunt u Systrace gebruiken omfileuw project.
• Voor Unity Developer kunt u CPU Usage Pro gebruikenfiler-module om CPU-prestatieproblemen te vinden.
• Voor Unreal Developer kunt u Unreal's Insights gebruiken om CPU-prestatieproblemen te vinden.

Ten tweede kunt u proberen bepaalde Wave-functies of -instellingen aan te passen om de GPU-belasting te verminderen.

1. Vernieuwingsfrequentie van het beeldscherm lager instellen (sectie 3.1.1, sectie 4.1.1)
2.  Gebruik Multi-View Rendering (sectie 3.1.4, sectie 4.1.4)

Als uw app ook een MR-app is, kunt u ook de Passthrough-instellingen aanpassen.

1. Pas de passthrough-framerate aan zodat deze langzamer wordt (sectie 3.2.2).

Raadpleeg Hoofdstuk 2.6 voor meer andere instellingen over CPU-prestaties.

2.5 Samenvatting
Tot slot hebben we de bovenstaande workflow voor prestatiecontrole in Figuur 2-5-1 ondergebracht. Begin met het controleren van de FPS van de content. Als deze lager is dan de framerate van het scherm of instabiel blijft, analyseer dan het GPU/CPU-gebruik om te bepalen of dit GPU-gebonden of CPU-gebonden is. Gebruik ten slotte een professionelefileom mogelijke prestatieproblemen te identificeren of Wave-functies of -instellingen aan te passen om de CPU-prestaties te optimaliseren.

2.6 Snelle referentie Welke instellingen kunnen de CPU/GPU-belasting verbeteren?

Geef hieronder de SDK-instellingen weer die betrekking hebben op de CPU/GPU-belasting. U kunt de relevante optimalisatie-instellingen controleren op basis van de bottleneck van de app.

Gerelateerd aan CPU:

• VIVE Wave SDK-instellingen
  o VR-inhoud
  ▪ 3.1.1 Vernieuwingsfrequentie van het scherm
  ▪ 3.1.4 MeerdereView Renderen
  ▪ 3.1.6 Adaptieve kwaliteit
  ▪ 3.1.7 Adaptieve bewegingscompositor
  o MR-inhoud
  ▪ 3.2.2 Passthrough-framesnelheid aanpassen
• VIVE OpenXR SDK-instelling
  o VR-inhoud
  ▪ 4.1.1 Vernieuwingsfrequentie van het scherm
  ▪ 4.1.4 MeerdereView Renderen
• Algemene optimalisatie
  o 5.5 CPU-piek

Gerelateerd aan GPU:

• VIVE Wave SDK-instellingen
  o VR-inhoud
  ▪ 3.1.1 Vernieuwingsfrequentie van het scherm
  ▪ 3.1.2 Oogbufferresolutie
  ▪ 3.1.3 MeerdereView Renderen
  ▪ 3.1.4 Foveatie
  ▪ 3.1.5 Verbetering van framescherpte (FSE)
  ▪ 3.1.6 Adaptieve kwaliteit
  ▪ 3.1.7 Adaptieve bewegingscompositor
  ▪ 3.1.8 Render Mask [Not Support Unreal]
  o MR-inhoud
  ▪ 3.2.1 Pas de passthrough-kwaliteit aan
  ▪ 3.2.2 Passthrough-framesnelheid aanpassen
• VIVE OpenXR SDK-instelling
  o VR-inhoud
  ▪ 4.1.1 Vernieuwingsfrequentie van het scherm
  ▪ 4.1.2 Oogbufferresolutie
  ▪ 4.1.3 MeerdereView Renderen
  ▪ 4.1.4 Foveation [Not Support Unreal]
  ▪ 4.1.5 Render Mask [Not Support Unreal]
• Algemene optimalisatie
  o 5.1 Schakel de modus Hoge prestaties uit
  o 5.2 Multisampleng
  o 5.3 GMEM laden/opslaan
  o 5.4 Compositielaag (meerdere lagen)

VIVE Wave-instelling

VIVE Wave is een open platform en toolset waarmee je eenvoudig VR-content kunt ontwikkelen en hoogwaardige apparaatoptimalisatie voor externe partners biedt. VIVE Wave ondersteunt de game-engines Unity en Unreal.
Omdat we de SDK voortdurend optimaliseren en oplossen, raden we u aan de SDK up-to-date te houden.
Momenteel ondersteunt VIVE Wave alleen OpenGL ES. Hieronder staan ​​de functies gerangschikt naar hun invloed op de GPU-prestaties. We verdelen dit in twee delen: VR-content en MR-content.
3.1 VR-inhoud
3.1.1 Vernieuwingsfrequentie van het scherm

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.

• Voor native ontwikkelaars, zie WVR_SetFrameRate.
• Voor Unity-ontwikkelaars: raadpleeg deze handleiding.
• Voor Unreal-ontwikkelaars is deze handleiding van toepassing.

3.1.2 Oogbufferresolutie
De resolutie van de oogbuffer is de textuurgrootte van de inhoud van de app die moet worden gerenderd. De gerenderde textuur wordt naar de runtime verzonden voor een plaatsingsproces en wordt weergegeven op het HMD-scherm.
Hoewel een grotere oogbuffer kan resulteren in helderdere en gedetailleerdere beelden, legt het ook een aanzienlijke belasting op de GPU. Daarom is het vinden van de juiste balans tussen beeldkwaliteit en prestaties essentieel.
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.

• Voor native ontwikkelaars, zie WVR_ObtainTextureQueue. Bij het aanpassen van de grootte moet u de breedte en hoogte vermenigvuldigen met een verhouding.
• Voor Unity-ontwikkelaars: zie WaveXRSettings.
  U kunt er ook voor kiezen om wijzigingen aan te brengen via de onderstaande code.
  XRSettings.eyeTextureResolutionScale = ResolutieScaleWaarde; // C#
• Voor Unreal-ontwikkelaars: zie SetPixelDensity.

3.1.3 MeerdereView Renderen
Bij traditionele rendering tekenen we het linker- en rechteroog apart, wat twee tekenopdrachten voor dezelfde scène vereist.View Rendering lost dit probleem op door slechts één draw call uit te voeren.
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.

• Voor Native-ontwikkelaars kunt u verwijzen naar wvr_native_hellovr sampik.
• Voor Unity-ontwikkelaars, zie de Rendermodus, single pass is multi-view functie.
• Voor Unreal-ontwikkelaars is deze handleiding van toepassing.

3.1.4 Foveatie
Foveated rendering is primair ontworpen om de GPU-belasting te verminderen. Het vermindert de framedetails in de periferie van het scherm en behoudt details met een hoge resolutie in het midden van het beeldveld. viewAls de app een GPU-gebonden probleem heeft, kun je proberen Foveation-rendering in te schakelen.

Er zijn een paar dingen waar u op moet letten bij het gebruik van foveatie:

➢ Gebruikers merken doorgaans de verminderde details in perifere gebieden niet op bij toepassing van de standaard foveatiemodus. Maar als de perifere kwaliteit van de foveatie te laag is ingesteld, kan dit voor de gebruiker wel merkbaar worden.
➢ De effecten van foveatie kunnen duidelijker zichtbaar zijn bij bepaalde materialen of texturen, wat de aandacht van de gebruiker kan trekken. Ontwikkelaars moeten zich hiervan bewust zijn en dit dienovereenkomstig evalueren.
➢ Het inschakelen van de foveated rendering-functie brengt een vaste GPU-prestatiekost met zich mee, die kan variëren van 1% tot 6%, afhankelijk van de grootte van de oogbuffer. Bij gebruik van een eenvoudige shader in de scène kan de prestatiewinst door het besparen van resources lager zijn dan de vaste GPU-prestatiekost, wat resulteert in een prestatiedaling.

• Voor native ontwikkelaars is deze handleiding van toepassing.
• Raadpleeg deze handleiding voor Unity-ontwikkelaars. Wanneer u nabewerking of HDR inschakelt, kan foveation niet volledig worden benut. Dit komt doordat Unity objecten rendert op de eigen gegenereerde rendertextuur, in plaats van op de door de runtime gegenereerde rendertextuur die foveation ondersteunt.
• Voor Unreal-ontwikkelaars: raadpleeg deze handleiding. Foveation kan met name niet volledig worden benut op Multi-View Rendering, omdat Unreal objecten niet rechtstreeks kan renderen op de door de runtime gegenereerde rendertextuur die foveatie ondersteunt.

3.1.5 Verbetering van framescherpte (FSE)
De FSE zorgt voor scherpere renderingresultaten door het toevoegen van een scherptefilter. Dit kan de content duidelijker maken en de helderheid van de tekst in de scène aanzienlijk verbeteren. Als de app problemen heeft met de GPU, kunt u overwegen FSE uit te schakelen als dit niet essentieel is.

• Voor native ontwikkelaars is deze handleiding van toepassing.
• Voor Unity-ontwikkelaars: raadpleeg deze handleiding.
• Voor Unreal-ontwikkelaars is deze handleiding van toepassing.

3.1.6 Adaptieve kwaliteit
Om de batterij te sparen en de weergaveprestaties van het apparaat te behouden, past deze functie automatisch de prestatieniveaus van de CPU/GPU-klok aan op basis van het gebruik. Daarnaast kunnen andere strategieën worden geïmplementeerd om de prestaties te verbeteren, zoals het automatisch in- en uitschakelen van Foveation of het automatisch aanpassen van content bij hoge/lage belastinggebeurtenissen.

• Voor native ontwikkelaars is deze handleiding van toepassing.
• Voor Unity-ontwikkelaars: raadpleeg deze handleiding. In onze Unity-plugin kan de oogbuffergrootte automatisch worden aangepast op basis van de huidige prestaties. De tekstgrootte filtert te kleine schaalwaarden uit de resolutielijst. We raden een tekstgrootte van minimaal 20 dmm of groter aan.
• Voor Unreal-ontwikkelaars is deze handleiding van toepassing.

3.1.7 Adaptieve bewegingscompositor
Deze functie is experimenteel en omvat UMC en PMC. UMC halveert de framerate en extrapoleert nieuwe frames in realtime om de visuele vloeiendheid te behouden. Dit brengt echter wel wat latentie, artefacten en GPU-belasting met zich mee.
PMC gebruikt voornamelijk de dieptebuffer om ATW in staat te stellen rekening te houden met HMD-translatie en deze uit te breiden tot een compensatie van 6 frames. Deze functie kan de translatielatentie met 1 tot 2 frames verminderen, maar de GPU-belasting verhogen.

• Voor native ontwikkelaars is deze handleiding van toepassing.
• Voor Unity-ontwikkelaars: raadpleeg deze handleiding.
• Voor Unreal-ontwikkelaars is deze handleiding van toepassing.

3.1.8 Rendermasker [Unreal wordt niet ondersteund]
Pixels aan de randen worden na vervorming bijna onzichtbaar. Het rendermasker wijzigt de dieptebufferwaarden van deze onzichtbare pixels. Als u dieptetests inschakelt, worden deze onzichtbare pixels vanwege early-z niet gerenderd, waardoor de GPU-belasting wordt verminderd. Deze functie is handig als er zwaar belaste renderingobjecten in deze onzichtbare gebieden staan. Als er geen renderingobjecten in deze gebieden staan, is het raadzaam deze uit te schakelen, omdat dit een geringe GPU-belasting met zich meebrengt.

• Voor native ontwikkelaars: raadpleeg deze handleiding. U moet de dieptebuffer binden voordat u RenderMask aanroept, anders is het niet effectief.
• Voor Unity-ontwikkelaars: raadpleeg deze handleiding.
• Voor Unreal-ontwikkelaars: de Render Mask-functie wordt momenteel niet ondersteund.

3.2 MR-inhoud
3.2.1 Pas de passthrough-kwaliteit aan
Er zijn 3 niveaus voor passthrough-beeldkwaliteit:
➢ WVR_PassthroughImageQuality_DefaultMode – geschikt voor MR-inhoud zonder specifieke vraag.
➢ WVR_PassthroughImageQuality_PerformanceMode – geschikt voor MR-inhoud die meer GPU-bronnen nodig heeft voor het renderen van virtuele scènes.
➢ WVR_PassthroughImageQuality_QualityMode – geschikt voor MR-inhoud waarmee gebruikers de omgeving duidelijk kunnen zien, maar de virtuele scène met inhoud moet nauwkeuriger worden afgesteld voor betere prestaties.
U kunt de Passthrough-kwaliteit aanpassen naar PerformanceMode om het GPU-gebruik te verminderen.

• Native-, Unreal- of Unity-ontwikkelaars kunnen deze handleiding raadplegen.

3.2.2 Passthrough-framesnelheid aanpassen
Net als de vernieuwingsfrequentie van het scherm zorgt een hogere passthrough-framerate voor vloeiendere beelden, maar dit gaat ten koste van een hogere systeembelasting. Omgekeerd verminderen lagere vernieuwingsfrequenties de systeembelasting, maar resulteren ze in minder vloeiende beelden. Er zijn twee modi voor passthrough-framerate: Boost en Normaal.

• Native ontwikkelaars kunnen de passthrough-kwaliteit aanpassen met WVR_SetPassthroughImageRate.
• Voor Unity-ontwikkelaars, kan via code worden gewijzigd, bijv.ampde instellingen zijn als volgt // C#
  Interop.WVR_SetPassthroughImageQuality(WVR_PassthroughImageQuality.PerformanceMode);
• Voor Unreal-ontwikkelaars: zie het blauwdrukknooppunt in Afbeelding 3-2-2 voor de instellingsmethode.

VIVE OpenXR-instelling

OpenXR is een open standaard die een gemeenschappelijke set API's biedt voor de ontwikkeling van XR-applicaties die werken op een breed scala aan VR-apparaten. Deze standaard is ontwikkeld door de Khronos Group. De VIVE Focus 3 en VIVE XR Elite ondersteunen ook OpenXR. De VIVE OpenXR SDK biedt uitgebreide ondersteuning voor HTC VR-apparaten, waardoor ontwikkelaars All-in-One en content met Unity en de Unreal Engine op HTC VR-apparaten kunnen bouwen. We optimaliseren en lossen voortdurend diverse bugs op, dus het is raadzaam dat ontwikkelaars de FOTA-versie van hun apparaat bijwerken om deze up-to-date te houden. Momenteel ondersteunt de VIVE OpenXR SDK OpenGL ES en Vulkan.

4.1 VR-inhoud
4.1.1 Vernieuwingsfrequentie van het scherm
Het concept hier is vergelijkbaar met 3.1.1 Vernieuwingsfrequentie van het beeldscherm.

• Voor Native ontwikkelaars, zie XrEventDataDisplayRefreshRateChangedFB.
• Voor Unity-ontwikkelaars: raadpleeg deze handleiding.
• Voor Unreal-ontwikkelaars is deze handleiding van toepassing.

4.1.2 Oogbufferresolutie
Het concept hier is vergelijkbaar met 3.1.2 Eyebuffer Resolution. We raden aan om de schaalfactor niet lager dan 0.7 te maken, omdat dit kan resulteren in onacceptabele visuele kwaliteit.

• Voor native ontwikkelaars, zie xrCreateSwapchain. Bij het aanpassen van de grootte moet u de breedte en hoogte vermenigvuldigen met een verhouding.
• Voor Unity-ontwikkelaars, zie het volgende voorbeeldample // C#
  XRSettings.eyeTextureResolutionScale = 0.7f; //aanbevolen 1.0f~0.7f
• Raadpleeg deze handleiding voor Unreal-instellingen.

4.1.3 MeerdereView Renderen
Het concept hier is vergelijkbaar met 3.1.3 Multi-View Rendering. Deze functie vermindert de belasting van de CPU, maar GPU heeft ook enkele voordelen. We raden aan deze functie in te schakelen.

• Voor native ontwikkelaars biedt KhronosGroup een OpenXR Multi-View exampRaadpleeg hiervoor deze handleiding.
• Voor Unity-ontwikkelaars, zie de Rendermodus, single pass is multi-view functie.
• Voor Unreal-ontwikkelaars en VIVE Wave-instellingen kunt u deze handleiding raadplegen.

4.1.4 Foveation [Unreal niet ondersteund]
Het concept hier is vergelijkbaar met 3.1.4 Foveation. Foveated rendering is primair ontworpen om de GPU-belasting te verminderen, maar het inschakelen ervan brengt een vaste GPU-prestatiekost met zich mee. Als foveation te laag is ingesteld en bepaalde materialen of texturen worden gebruikt, kan het zeer moeilijk worden.
merkbaar voor de gebruiker. Het is daarom raadzaam om de functie in of uit te schakelen op basis van uw specifieke vereisten en prestatieoverwegingen. Momenteel wordt Foveated-functionaliteit alleen ondersteund in OpenGL ES op VIVE OpenXR SDK.

• Voor native ontwikkelaars is deze functie beschikbaar, maar momenteel is er geen examplesjes worden verstrekt.
• Voor Unity-ontwikkelaars: raadpleeg deze handleiding.
• Voor Unreal-ontwikkelaars: deze functie wordt momenteel niet ondersteund.

4.1.5 Rendermasker [Unreal wordt niet ondersteund]
Het concept hier is vergelijkbaar met 3.1.8 Render Mask.

• Voor native ontwikkelaars: gebruik XrVisibilityMaskKHR om het mesh te verkrijgen. Vul vóór het renderen van de scène de dieptebufferwaarden in met dit mesh.
• Voor Unity-ontwikkelaars is de Render Mask-functie standaard ingeschakeld voor OpenGL ES en kan worden uitgeschakeld met de volgende code; Vulkan ondersteunt deze functie momenteel niet. //C# UnityEngine.XR.XRSettings.occlusionMaskScale = 0.0f;
• Voor Unreal-ontwikkelaars: de Render Mask-functie wordt momenteel niet ondersteund.

4.2 MR-inhoud
OpenXR ondersteunt momenteel geen instellingen voor passthrough-kwaliteit en framesnelheid. We blijven de passthrough-functie optimaliseren en verbeteren. Daarom raden we ontwikkelaars aan de FOTA-versie van het apparaat bij te werken om deze up-to-date te houden.

Algemene optimalisatie

5.1 Schakel de modus Hoge prestaties uit
Het uitschakelen van de "Hoge prestatiemodus" kan de schermgrootte van het apparaat verkleinen, waardoor het GPU-gebruik afneemt. Het nadeel is een lagere schermresolutie. U kunt kwaliteit en prestaties afwegen om te beslissen of u deze modus wilt inschakelen.
De instellocatie voor VIVE Focus 3 wordt weergegeven in Figuur 5-1-1:

De instellingslocatie voor VIVE XR Elite wordt weergegeven in Afbeelding 5-1-2:

5.2 Multi'sampling Anti-Aliasing
Meerdereampling 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.

• Voor native ontwikkelaars, MSAA OpenGL ES exsample kan hiernaar verwijzen; MSAA Vulkan exampler kan hiernaar verwijzen.
  De Adreno GPU biedt een uitbreiding die MSAA optimaliseert.
• Unity-ontwikkelaars kunnen terecht bij deze gilde.
• For Unreal developer, refer to this guild. Unreal also has provide post processing anti-aliasing, refer to this guild.

5.3 GMEM laden/opslaan
In de Adreno GPU-architectuur is er een functie waarmee, bij het koppelen van een Render Target, de waarden in de Render Target niet worden gewist of ongeldig gemaakt. Telkens wanneer er wordt gerenderd, worden de waarden in de Render Target in het grafisch geheugen geladen. Dit wordt GMEM Load genoemd. Als de vorige waarden niet nodig zijn, kan het wissen of ongeldig maken van de Render Target vóór het renderen deze situatie voorkomen en de GPU-prestaties verbeteren.
U kunt GMEM Load vermijden met de volgende methoden. In OpenGL ES kunt u, na het binden van de FBO, glClear en glClearDepth aanroepen om de kleur-, diepte- en stencilbuffer te wissen, of glInvalidateFramebuffer aanroepen om het opgegeven Render Target ongeldig te maken. In Vulkan zijn aanvullende instructies niet nodig; u kunt expliciet instellen of de bijlage vóór gebruik moet worden gewist in VkAttachmentDescription.loadOp.
Het opslaan van het resultaat van een Tile Render vanuit het grafische geheugen naar het hoofdgeheugen wordt ook wel GMEM Store genoemd; deze bewerking is ook kostbaar voor de GPU. Om dit te voorkomen, raden we aan alleen de vereiste Render Targets te binden om onnodige Store-bewerkingen te voorkomen.

5.4 Compositielaag (meerdere lagen)
Texturen die met Multi-Layer worden weergegeven, hebben een betere visuele kwaliteit. Deze functie verhoogt echter de GPU-prestaties aanzienlijk met het aantal lagen en de grootte van de texturen. We raden aan om niet meer dan drie lagen te gebruiken.

• Voor native ontwikkelaars,
  o VIVE Wave SDK gebruikt WVR_SubmitFrameLayers om gegevens voor elke laag door te geven.
  o VIVE OpenXR SDK plaatst laaggegevens in XrFrameEndInfo en verzendt deze via xrEndFrame.
• Voor Unity-ontwikkelaars,
  o VIVE Wave SDK-instellingen, raadpleeg deze handleiding,
  Voor VIVE OpenXR-instellingen, raadpleeg deze handleiding.
• Voor Unreal-ontwikkelaars,
  Voor de VIVE Wave SDK-instellingen raadpleegt u deze handleiding.
  Voor VIVE OpenXR-instellingen, raadpleeg deze handleiding.

5.5 CPU-piek
Wanneer de CPU zwaarder wordt belast, kunnen sommige achtergrondprocessen met een hoge prioriteit de native uitvoering verstoren. We kunnen niet garanderen dat de Content Application niet door andere threads wordt onderbroken.
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.

• Voor Unity Developer, raadpleeg de Android-threadconfiguratiefunctie. Als u de VIVE Wave SDK gebruikt, is er een functie in WaveXRSettings waarmee u de prioriteit kunt aanpassen, zoals weergegeven in Afbeelding 5-5-2. De lagere waarde staat voor een hogere prioriteit.

• Unreal heeft geen methode om de gamethread, rendering thread en RHI-threadprioriteit te wijzigen via externe instellingen, tenzij je de enginecode aanpast.

Copyright © 2024 HTC Corporation. Alle rechten voorbehouden.