Pagganap ng VR Rendering
Pag-tono at Pag-optimize

Panimula

Ang pagkamit ng pinakamainam na karanasan sa VR sa hardware na limitado sa mapagkukunan ay susi sa paghahatid ng maayos at kumportableng karanasan ng user. Kung bumaba o hindi stable ang frame rate ng pag-render ng content sa ibaba ng refresh rate ng device, hahantong ito sa frame judder at stutting, mga sakit sa paggalaw, atbp,. sa wakas ay negatibong nakakaapekto sa karanasan ng gumagamit. Samakatuwid, ang pag-optimize sa pagganap ng nilalaman ay napakahalaga para sa pagtiyak ng isang kasiya-siyang karanasan.
Bago simulan ang pag-tune ng pagganap, mahalagang maunawaan kung nasaan ang mga bottleneck ng pagganap upang maiwasan ang hindi mahusay na pag-tune. Ang dokumentong ito ay idinisenyo upang matulungan ang mga developer na matukoy ang mga bottleneck sa pagganap at mag-alok ng mga solusyon upang malutas ang mga isyu sa pagganap ng pag-render.
Ang dokumento ay isinaayos sa mga sumusunod na seksyon:

• Kabanata 2: Kilalanin ang Bottleneck – Tinutulungan ng seksyong ito ang mga developer sa pagtukoy kung nasaan ang mga bottleneck.
• Kabanata 3 at 4: Mga Setting ng VIVE Wave at VIVE OpenXR – Binabalangkas ng mga seksyong ito ang mga partikular na setting na maaaring makaapekto sa performance ng CPU/GPU para sa VIVE Wave at OpenXR app. Maaaring mag-eksperimento ang mga developer sa pagpapagana o pag-disable sa mga feature na ito batay sa mga bottleneck ng performance na naranasan upang matukoy kung mayroong anumang pagpapabuti.
• Kabanata 5: Karaniwang Pag-optimize – Ang seksyong ito ay nagbabahagi ng ilang karaniwang mga kasanayan at karanasan sa pag-optimize.

Kilalanin Ang Bottleneck

Kapag gumagalaw ang HMD, kung ang VR/MR app ay may frame jitter o black edge, atbp., kadalasang sanhi ito ng hindi magandang isyu sa performance ng pag-render. Karaniwan, ang mga problema sa pagganap sa pag-render ay maaaring ikategorya sa 2 uri: CPU-bound o GPU-bound. Unawain kung aling mga uri ng bound para sa iyong app ang napakahalaga sa simula upang maiwasan ang hindi mahusay na pag-tune.
Sa kabanatang ito, nagbibigay kami ng mga simpleng hakbang na nagbibigay-daan sa iyong mabilis na matukoy kung nasaan ang mga isyu sa pagganap.

2.1 Suriin ang Pag-render ng Nilalaman FPS
Una, magsisimula tayo sa pamamagitan ng pagsuri sa content FPS na ang bilang ng mga frame na ginagawa ng content con bawat segundo. Dapat itong panatilihin sa framerate ng display at panatilihing matatag. Kung hindi, maaari itong magdulot ng pagkabalisa sa frame.
Kung ang iyong application SDK ay gumagamit ng VIVE WAVE SDK 6.0.0 o mas bago, maaari mong gamitin ang sumusunod na adb command upang suriin ang FPS. DK 6.0.0
$adb Logcat -s VRMetric
Makikita mo ang sumusunod na data ng log.
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” Ang unang numero ay kumakatawan sa nilalamang FPS, habang ang pangalawang numero ay kumakatawan sa display framerate.
Kung ang iyong bersyon ng Wave SDK ay mas mababa sa 6.0.0, inirerekomendang mag-upgrade sa pinakabagong bersyon upang mapahusay ang pagganap ng pag-render at pag-optimize ng iba.
Kung ang iyong application SDK ay binuo gamit ang VIVE OpenXR. Maaari mong gamitin ang sumusunod na adb command upang suriin ang FPS.
$adb Logcat -s RENDER_ATW
Makikita mo ang sumusunod na data ng log
RENDER_ATW: [FPS] bagong texture:90.00
RENDER_ATW: [FPS] R kasalukuyan:90.00 laktawan:0 317, -0.0155 0.805527, 0.006788)
RENDER_ATW: [FPS] L kasalukuyan:90.00 laktawan:0 (0.592301, -0.015502, 0.805539, 0.006773)

Ang bilang na sumusunod sa "bagong texture" ay kumakatawan sa kasalukuyang nilalamang FPS. Ang numerong kasunod ng “R present” at “L present” ay kumakatawan sa display framerate.
Minsan, ang content na FPS at ang display framerate ay maaaring may kaunting pagkakaiba.
Para kay example, sa kaso sa itaas, ang 89.8 FPS ay maaaring ituring na 90 FPS.
Kung ang FPS ng content ng app ay patuloy na mas mababa kaysa sa framerate ng display o nananatiling hindi stable, nagsasaad ito ng isyu sa pagganap ng pag-render. Samakatuwid, ang susunod na hakbang ay upang matukoy kung ang bottleneck ay nagmumula sa CPU o sa GPU.
2.2 Suriin ang paggamit ng CPU at GPU
Kung ang iyong application SDK ay gumagamit ng VIVE WAVE SDK 6.0.0 o mas bago, maaari mong gamitin ang sumusunod na adb command upang suriin ang FPS.
$adb logcat -s VRMetric
Makikita mo ang sumusunod na data ng log.
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
Gaya ng nakikita mo sa resulta ng log sa itaas, ang paggamit ng CPU ay 27% at ang paggamit ng GPU ay 72% Kung ang iyong bersyon ng Wave SDK ay mas mababa sa 6.0.0, inirerekomendang mag-upgrade sa pinakabagong bersyon upang mapahusay ang pagganap ng pag-render at iba pang pag-optimize.
Para sa VIVE OpenXR app, maaari mong gamitin ang sumusunod na command upang suriin ang paggamit ng CPU at GPU.
# sa linux/ubuntu
$ adb logcat | grep CPU_USAGE
# sa powershell
$ adb logcat | Select-String -Pattern CPU_USAGE
Makikita mo ang sumusunod na log
CPU Avg. CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 GPU CPU_USAGE [LOAD] 25.67% 32.22% 25.29% 30.77% 29.35% 21.35% 22.09% 18.39% 24.14% 73 %
Kung mapapansin mo na hindi mapapanatili ng FPS ang display frame rate at napakataas din ng paggamit ng GPU, karaniwang lumalampas sa 85%, maaari mong subukang ayusin ang Eyebuffer Resolution (seksyon 3.1.2, seksyon 4.1.2) upang makita kung nagpapabuti ito ng FPS. Kung ang pagsasaayos na ito ay humantong sa mas mahusay
pagganap, maaari naming tapusin na ang isyu ay nakasalalay sa GPU at ituon ang aming mga pagsusumikap sa pag-optimize nang naaayon.
Sa kabilang banda, kung ang pagsasaayos sa Eyebuffer Resolution ay hindi magreresulta sa isang kapansin-pansing pagpapabuti ng pagganap, ang bottleneck ay malamang na nakasalalay sa CPU, at dapat tayong tumuon sa pag-optimize ng pagganap ng CPU.
Posible rin na ang application ay parehong CPU-bound at GPU-bound nang sabay-sabay. Sa ganitong mga kaso, ang mga pagsusumikap sa pag-optimize ay dapat ilapat sa parehong CPU at GPU upang makamit ang balanseng mga pagpapabuti sa pagganap.
2.3 GPU-bound
Kapag ang isang VR app ay nakatali sa GPU, nangangahulugan ito na ang GPU ang pangunahing bottleneck, at hindi nito magawang makasabay sa mga hinihingi sa pag-render ng application. Upang mapagaan ang mga isyu sa GPU, isaalang-alang ang mga sumusunod na rekomendasyon:
Una, gumamit ng mga tool sa pag-profile tulad ng RenderDoc o Game Engine profiler (Unity Profiler, Unreal Insights) upang suriin kung saan ginugugol ng GPU ang halos lahat ng oras nito. Tukuyin ang mga pinakamahal na operasyon at tumuon sa pag-optimize ng mga ito.
Para sa Native Developer, maaari mong gamitin ang RenderDoc para matukoy kung aling draw call ang nagdudulot ng labis na pag-load ng GPU.
Para sa Unity Developer, maaari mong sundin ang Unity na dokumentong ito o gamitin ang RenderDoc para suriin ang isyu sa performance ng pag-render, at sundin ang dokumentasyon ng Unity graphics optimization para sa gabay upang ma-optimize ang iyong application.
Para sa Unreal Developer, maaari mong gamitin ang GPU Visualizer o gamitin ang RenderDoc upang suriin ang isyu sa pagganap ng pag-render, at sundin ang Mga Alituntunin sa Hindi Tunay na Pagganap para sa gabay upang ma-optimize ang iyong application.
Pangalawa, maaari mo ring subukang ayusin ang ilang partikular na feature o setting ng Wave para mabawasan ang paglo-load ng GPU.

1. Itakda ang Display Refresh Rate nang mas mabagal (seksyon 3.1.1, seksyon 4.1.1)
2.  Ayusin ang Eyebuffer Resolution (seksyon 3.1.2, seksyon 4.1.2), 14.1.1)
3.  Subukang paganahin ang Foveation (seksyon 3.1.4, seksyon 4.1.4).

Kung ang iyong app ay isa ring MR app, maaari mo ring isaayos ang mga setting ng Passthrough.

1. Ayusin ang Passthrough na Kalidad ng Imahe nang mas mababa. (seksyon 3.2.1)
2. Ayusin ang Passthrough Framerate nang mas mabagal. (seksyon 3.2.2).

Para sa higit pang iba pang mga setting tungkol sa pagganap ng GPU, maaari kang sumangguni sa Kabanata 2.6.

2.4 CPU-bound
Kapag ang isang VR app ay nakatali sa CPU, nangangahulugan ito na ang CPU ang pangunahing bottleneck, isaalang-alang ang mga sumusunod na rekomendasyon:
Una, gumamit ng mga tool sa pag-profile tulad ng Systrace o Game Engine profiler (Unity Profiler, Unreal Insights) upang suriin at tukuyin kung aling mga bahagi ng iyong code ang gumagamit ng pinakamaraming mapagkukunan ng CPU. Tumutok sa pag-optimize sa mga lugar na ito at i-refactor ang computationally intensive algorithm para mabawasan ang CPU load.

• Para sa Native Developer, maaari mong gamitin ang Systrace sa profiler iyong proyekto.
• Para sa Unity Developer, maaari mong gamitin ang CPU Usage Profiler module upang mahanap ang isyu sa pagganap ng CPU.
• Para sa Unreal Developer, maaari mong gamitin ang Unreal's Insights para mahanap ang isyu sa performance ng CPU.

Pangalawa, maaari mo ring subukang ayusin ang ilang partikular na feature o setting ng Wave para mabawasan ang paglo-load ng GPU.

1. Itakda ang Display Refresh Rate nang mas mabagal (seksyon 3.1.1, seksyon 4.1.1)
2.  Gumamit ng Multi-View Pag-render (seksyon 3.1.4, seksyon 4.1.4)

Kung ang iyong app ay isa ring MR app, maaari mo ring isaayos ang mga setting ng Passthrough.

1. Ayusin ang Passthrough Framerate nang mas mabagal (seksyon 3.2.2).

Para sa higit pang iba pang mga setting tungkol sa pagganap ng CPU, maaari kang sumangguni sa Kabanata 2.6.

2.5 Buod
Sa wakas, inayos namin ang daloy ng trabaho sa pagsusuri ng pagganap sa itaas sa Figure 2-5-1. Magsimula sa pamamagitan ng pagsuri sa FPS ng nilalaman. Kung mas mababa ito kaysa sa framerate ng display o nananatiling hindi matatag, suriin ang paggamit ng GPU/CPU upang matukoy kung ito ay GPU-bound o CPUbound. Panghuli, gumamit ng profiler upang matukoy ang mga potensyal na isyu sa performance o isaayos ang mga feature o setting ng Wave para ma-optimize ang performance ng CPU.

2.6 Mabilis na Sanggunian Aling Mga Setting ang Maaaring Pahusayin ang paglo-load ng CPU/GPU

Ilista ang mga setting ng SDK na nauugnay sa paglo-load ng CPU/GPU tulad ng sa ibaba. Maaari kang maging batay sa bottleneck ng app upang suriin ang mga nauugnay na setting ng pag-optimize.

Nauugnay sa CPU:

• Setting ng VIVE Wave SDK
  o Nilalaman ng VR
  ▪ 3.1.1 Rate ng Pag-refresh ng Display
  ▪ 3.1.4 Multi-View Nagre-render
  ▪ 3.1.6 Adaptive na Kalidad
  ▪ 3.1.7 Adaptive Motion Compositor
  o Nilalaman ng MR
  ▪ 3.2.2 Isaayos ang Passthrough Frame Rate
• Setting ng VIVE OpenXR SDK
  o Nilalaman ng VR
  ▪ 4.1.1 Rate ng Pag-refresh ng Display
  ▪ 4.1.4 Multi-View Nagre-render
• Karaniwang Pag-optimize
  o 5.5 CPU Spike

Nauugnay sa GPU:

• Setting ng VIVE Wave SDK
  o Nilalaman ng VR
  ▪ 3.1.1 Rate ng Pag-refresh ng Display
  ▪ 3.1.2 Resolusyon sa Eyebuffer
  ▪ 3.1.3 Multi-View Nagre-render
  ▪ 3.1.4 Foveation
  ▪ 3.1.5 Frame Sharpness Enhancement (FSE)
  ▪ 3.1.6 Adaptive na Kalidad
  ▪ 3.1.7 Adaptive Motion Compositor
  ▪ 3.1.8 Render Mask [Not Support Unreal] o MR Content
  ▪ 3.2.1 Isaayos ang Kalidad ng Passthrough
  ▪ 3.2.2 Isaayos ang Passthrough Frame Rate
• Setting ng VIVE OpenXR SDK
  o Nilalaman ng VR
  ▪ 4.1.1 Rate ng Pag-refresh ng Display
  ▪ 4.1.2 Resolusyon sa Eyebuffer
  ▪ 4.1.3 Multi-View Nagre-render
  ▪ 4.1.4 Foveation [Not Support Unreal] ▪ 4.1.5 Render Mask [Not Support Unreal]
• Karaniwang Pag-optimize
  o 5.1 I-off ang High Performance Mode
  o 5.2 Multisampling
  o 5.3 GMEM Load/Store
  o 5.4 Komposisyon Layer (Multi Layer)

Setting ng VIVE Wave

Ang VIVE Wave ay isang bukas na platform at toolset na nagbibigay-daan sa iyong madaling bumuo ng VR na nilalaman at nagbibigay ng mataas na pagganap na pag-optimize ng device para sa mga third-party na kasosyo. Sinusuportahan ng VIVE Wave ang Unity at Unreal game engine.
Patuloy naming ino-optimize at niresolba ang iba't ibang mga bug, kaya inirerekomenda naming panatilihing napapanahon ang SDK.
Sa kasalukuyan, sinusuportahan lamang ng VIVE Wave ang OpenGL ES. Dito nakalista ang mga feature na inayos ayon sa impluwensya sa pagganap ng GPU. Hahatiin namin ito sa dalawang bahagi: VR content at MR content.
3.1 Nilalaman ng VR
3.1.1 Display Refresh Rate

Ang mas mataas na refresh rate ay nag-aalok ng mas maayos na visual, ngunit may kaakibat na pagtaas ng system load. Sa kabaligtaran, ang mas mababang refresh rate ay nakakabawas sa system load, ngunit nagreresulta sa hindi gaanong maayos na visual. Kung ang App ay may isyu sa CPU/GPU bound, maaari mong subukang bawasan ang...asinbaguhin ang refresh rate ng display upang maibsan ang isyu.

• Para sa Native developer, sumangguni sa WVR_SetFrameRate.
• Para sa developer ng Unity, sumangguni sa gabay na ito.
• Para sa Unreal developer, sumangguni sa gabay na ito.

3.1.2 Resolusyon sa Eyebuffer
Ang eyebuffer resoultion ay ang laki ng texture na ire-render ng content App, ire-render na texture sa runtime para gawin ang proseso ng pag-post at ipapakita sa HMD display.
Habang ang mas malaking laki ng buffer ng mata ay maaaring magresulta sa mas malinaw at mas detalyadong mga visual, ngunit nagpapataw din ito ng malaking pagkarga sa GPU. Samakatuwid, ang paghahanap ng tamang balanse sa pagitan ng visual na kalidad at pagganap ay mahalaga.
Kung ang App ay may isyu sa GPU bound, maaari mong subukang i-decreasinI-multiply ang laki ng eyebuffer sa pamamagitan ng pagpaparami ng scale factor. Gayunpaman, inirerekomenda naming huwag bawasan ang scale factor sa ibaba ng 0.7, dahil maaaring magresulta ito sa hindi katanggap-tanggap na kalidad ng paningin.

• Para sa Native developer, sumangguni sa WVR_ObtainTextureQueue. Kapag inaayos ang laki, dapat mong i-multiply ang lapad at taas sa isang ratio.
• Para sa developer ng Unity, sumangguni sa WaveXRSettings.
  Bilang kahalili, maaari kang gumawa ng mga pagbabago sa pamamagitan ng code bilang belwoe.
  XRSettings.eyeTextureResolutionScale = ResolutionScaleValue; // C#
• Para sa Unreal developer, sumangguni sa SetPixelDensity.

3.1.3 Multi-View Nagre-render
Sa tradisyunal na pag-render, iginuhit namin ang kaliwa at kanang mata nang hiwalay, na nangangailangan ng dalawang draw call para sa parehong eksena. marami-View Tinutugunan ng rendering ang isyung ito sa pamamagitan ng pagsasagawa lamang ng isang draw call.
Binabawasan ng feature na ito ang CPU load nang paunti-untiasinang bilang ng mga draw call. Mayroon ding ilang benepisyo ang GPU, nababawasan din ang workload ng vertex shader dahil hindi na nito kailangang magpatakbo ng karagdagang shader para sa kabilang mata, ngunit nananatiling hindi nagbabago ang workload ng fragment shader dahil kailangan pa rin nitong suriin ang bawat pixel para sa magkabilang mata. Inirerekomenda namin ang pag-enable sa feature na ito.

• Para sa Native developer, maaari kang sumangguni sa wvr_native_hellovr sample.
• Para sa developer ng Unity, sumangguni sa Render Mode, ang single pass ay multi-view tampok.
• Para sa Unreal developer, sumangguni sa gabay na ito.

3.1.4 Foveation
Pangunahing idinisenyo ang foveated rendering para bawasan ang GPU load. Binabawasan nito ang detalye ng frame sa peripheral ng display at pinapanatili ang detalye ng mataas na resolution sa gitna ng field ng view. Kung may GPU bound issue ang App, maaari mong subukang i-enable ang pag-render ng Foveation.

Mayroong isang bagay na kailangang mapansin habang gumagamit ng foveation:

➢ Karaniwang hindi napapansin ng mga user ang pinababang detalye sa mga peripheral na rehiyon na naglalapat ng default na foveation mode. Ngunit kung masyadong mababa ang peripheral na kalidad ng foveation, maaari itong maging kapansin-pansin sa gumagamit.
➢ Ang mga epekto ng foveation ay maaaring mas kapansin-pansin sa ilang mga materyales ng mga texture, na maaaring makatawag ng pansin ng gumagamit. Dapat itong malaman ng mga developer at suriin ito nang naaayon.
➢ Ang pagpapagana ng foveated rendering feature ay magkakaroon ng fixed GPU performance cost, na maaaring mag-iba sa pagitan ng 1% hanggang 6% depende sa laki ng eye buffer. Kapag gumagamit ng simpleng shader sa eksena, maaaring mas mababa ang performance gain mula sa pag-save ng mga mapagkukunan kaysa sa nakapirming gastos sa performance ng GPU, na nagreresulta sa pagbaba ng performance.

• Para sa Native developer, sumangguni sa gabay na ito.
• Para sa developer ng Unity, sumangguni sa gabay na ito. Kapansin-pansin, kapag pinagana mo ang post-processing o HDR, hindi magagamit nang lubusan ang foveation. Dahil ang Unity ay magre-render ng mga bagay sa sarili nitong nabuong render texture, sa halip na ang runtime-generated present's render texture na sumusuporta sa foveation.
• Para sa Unreal developer, sumangguni sa gabay na ito. Kapansin-pansin, ang foveation ay hindi maaaring ganap na magamit sa Multi-View Pag-render, dahil ang Unreal ay hindi maaaring direktang mag-render ng mga bagay sa runtime-generated na render texture na sumusuporta sa foveation.

3.1.5 Frame Sharpness Enhancement (FSE)
Ang FSE na nagbibigay ng sharpen rendering na resulta sa pamamagitan ng pagpapasok ng sharpen filter, maaari nitong gawing mas malinaw ang content at makatutulong ito sa pagpapabuti ng kalinawan ng text sa eksena. Kung ang App ay may isyu sa GPU, maaari mong isaalang-alang ang pag-disable sa FSE kung hindi ito mahalaga.

• Para sa Native developer, sumangguni sa gabay na ito.
• Para sa developer ng Unity, sumangguni sa gabay na ito.
• Para sa Unreal developer, sumangguni sa gabay na ito.

3.1.6 Adaptive na Kalidad
Para makatipid ng baterya at mapanatili ang performance ng pag-render ng device, awtomatikong inaayos ng feature na ito ang mga antas ng performance ng CPU/GPU clock batay sa paggamit ng mga ito. Bukod pa rito, maaaring ipatupad ang iba pang mga diskarte para mapahusay ang performance, gaya ng awtomatikong paganahin/paganahin ang Foveation o maaaring ayusin ng content ang sarili nito kung nakakatanggap ng mga event na may mataas/mababang pag-load.

• Para sa Native developer, sumangguni sa gabay na ito.
• Para sa developer ng Unity, sumangguni sa gabay na ito. Sa aming Unity plugin, ang laki ng buffer ng mata ay maaaring awtomatikong iakma batay sa kasalukuyang pagganap; Ipi-filter ng laki ng text ang mga value ng scale na masyadong maliit sa listahan ng Resolution. Inirerekomenda namin ang text na may sukat na hindi bababa sa 20 dmm o mas malaki.
• Para sa Unreal developer, sumangguni sa gabay na ito.

3.1.7 Adaptive Motion Compositor
Ang feature na ito ay pang-eksperimentong feature na kinabibilangan ng UMC at PMC. Babawasan ng UMC ang Frame Rate ng kalahati at i-extrapolate ang bagong frame sa real time upang mapanatili ang pagiging makinis ng visual. Gayunpaman, may kasama itong ilang latency, artifact at paglo-load ng GPU.
Pangunahing ginagamit ng PMC ang Depth Buffer upang payagan ang ATW na i-account ang pagsasalin ng HMD, na umaabot sa 6-dof na kabayaran. Maaaring bawasan ng feature na ito ang latency ng pagsasalin ng 1~2 frame, ngunit pataasin ang pag-load ng GPU.

• Para sa Native developer, sumangguni sa gabay na ito.
• Para sa developer ng Unity, sumangguni sa gabay na ito.
• Para sa Unreal developer, sumangguni sa gabay na ito.

3.1.8 Render Mask [Not Support Unreal]
Ang mga pixel sa mga gilid ay halos hindi nakikita pagkatapos ng pagbaluktot, binabago ng render mask ang mga halaga ng depth buffer ng mga hindi nakikitang pixel na ito. Kung ie-enable mo ang malalim na pagsubok, dahil sa early-z, hindi ire-render ang mga invisible na pixel na ito, at sa gayon ay mababawasan ang pag-load ng GPU. Ang tampok na ito ay kapaki-pakinabang kung mayroong mabigat na naglo-load na mga bagay sa pag-render sa mga hindi nakikitang lugar na ito; kung hindi, kung walang mga bagay sa pag-render sa mga lugar na ito, inirerekomenda na huwag paganahin ito dahil kakausapin nito ang isang maliit na paggamit ng GPU..

• Para sa Native developer, sumangguni sa gabay na ito. Dapat mong itali ang depth buffer bago tumawag sa RenderMask; kung hindi, ito ay magiging hindi epektibo.
• Para sa developer ng Unity, sumangguni sa gabay na ito.
• Para sa Unreal developer, kasalukuyang hindi sumusuporta sa feature na Render Mask.

3.2 Nilalaman ng MR
3.2.1 Isaayos ang Kalidad ng Passthrough
Mayroong 3 antas para sa kalidad ng passthrough na imahe:
➢ WVR_PassthroughImageQuality_DefaultMode – angkop para sa nilalaman ng MR na walang partikular na pangangailangan.
➢ WVR_PassthroughImageQuality_PerformanceMode – angkop para sa nilalaman ng MR na nangangailangan ng higit pang mapagkukunan ng GPU para sa pag-render ng virtual na eksena.
➢ WVR_PassthroughImageQuality_QualityMode – angkop para sa nilalaman ng MR na nagbibigay-daan sa mga user na makita nang malinaw ang nakapalibot na kapaligiran, ngunit ang virtual na eksena ng nilalaman ay dapat magkaroon ng mas pinong pag-tune para sa pagganap.
Maaari mong isaayos ang kalidad ng Passthrough sa PerformanceMode para mabawasan ang paggamit ng GPU.

• Para sa Native, Uunity o Unreal developer, sumangguni sa gabay na ito.

3.2.2 Isaayos ang Passthrough Frame Rate
Tulad ng rate ng pag-refresh ng Display, ang mas mataas na Passthrough framerate ay nag-aalok ng mas malinaw na mga visual, ngunit dumating sa halaga ng tumaas na pag-load ng system. Sa kabaligtaran, binabawasan ng mas mababang mga rate ng pag-refresh ang pag-load ng system, ngunit nagreresulta sa hindi gaanong makinis na mga visual. Mayroong 2 mode ng passthrough framerate: Boost at Normal.

• Para sa Native developer, maaaring isaayos ang passthrough na kalidad gamit ang WVR_SetPassthroughImageRate.
• Para sa developer ng Unity, maaaring magbago sa pamamagitan ng code, halampAng mga setting ay ang mga sumusunod // C#
  Interop.WVR_SetPassthroughImageQuality(WVR_PassthroughImageQuality.PerformanceMode);
• Para sa Unreal developer, ang paraan ng pagtatakda ay tingnan ang blueprint node sa Figure 3-2-2.

Setting ng VIVE OpenXR

Ang OpenXR ay open standard na nagbibigay ng karaniwang hanay ng mga API para sa pagbuo ng mga XR application na tumatakbo sa malawak na hanay ng mga VR device, na binuo ng Khronos Group. Sinusuportahan din ng VIVE Focus 3 at VIVE XR Elite ang OpenXR, ang VIVE OpenXR SDK ay nagbibigay ng komprehensibong suporta para sa mga HTC VR device, na nagpapahintulot sa mga developer na bumuo ng Allin-One at content sa Unity at Unreal engine sa mga HTC VR device. Patuloy naming ino-optimize at niresolba ang iba't ibang mga bug, kaya inirerekomenda na i-update ng mga developer ang bersyon ng FOTA ng kanilang device upang panatilihin itong napapanahon. Sa kasalukuyan, sinusuportahan ng VIVE OpenXR SDK ang OpenGL ES at Vulkan.

4.1 Nilalaman ng VR
4.1.1 Display Refresh Rate
Ang konsepto dito ay katulad ng 3.1.1 Display Refresh Rate.

• Para sa Native developer, sumangguni sa XrEventDataDisplayRefreshRateChangedFB.
• Para sa developer ng Unity, sumangguni sa gabay na ito.
• Para sa Unreal developer, sumangguni sa gabay na ito.

4.1.2 Resolusyon sa Eyebuffer
Ang konsepto dito ay katulad ng 3.1.2 Eyebuffer Resolution. inirerekomenda namin na huwag bawasan ang scale factor sa ibaba 0.7, dahil maaaring magresulta ito sa hindi katanggap-tanggap na kalidad ng visual.

• Para sa Native developer, sumangguni sa xrCreateSwapchain. Kapag inaayos ang laki, dapat mong i-multiply ang lapad at taas sa isang ratio. ,
• Para sa developer ng Unity, sumangguni sa sumusunod na halample // C#
  XRSettings.eyeTextureResolutionScale = 0.7f; //inirerekomenda ang 1.0f~0.7f
• Para sa mga hindi totoong setting, sumangguni sa gabay na ito.

4.1.3 Multi-View Nagre-render
Ang konsepto dito ay katulad ng 3.1.3 Multi-View Nagre-render. Binabawasan ng feature na ito ang load sa CPU, may ilang benefits din ang GPU. Inirerekumenda namin na i-enable ang feature na ito.

• Para sa Native developer, ang KhronosGroup ay nagbibigay ng OpenXR Multi-View example, sumangguni sa gabay na ito.
• Para sa developer ng Unity, sumangguni sa Render Mode, ang single pass ay multi-view tampok.
• Para sa Unreal developer, tulad ng sa mga setting ng VIVE Wave, sumangguni sa gabay na ito.

4.1.4 Foveation [Not Support Unreal]
Ang konsepto dito ay katulad ng 3.1.4 Foveation. Pangunahing idinisenyo ang foveated rendering upang bawasan ang pag-load ng GPU ngunit ang pagpapagana nito ay magkakaroon ng nakapirming gastos sa pagganap ng GPU at kung ang foveation ay nakatakdang masyadong mababa at ang ilang partikular na materyales o texture ay ginagamit, maaari itong maging napakababa.
kapansin-pansin sa gumagamit. Samakatuwid, ipinapayong paganahin o huwag paganahin ang tampok batay sa iyong mga partikular na kinakailangan at pagsasaalang-alang sa pagganap Sa kasalukuyan, ang Foveated functionality ay sinusuportahan lamang sa OpenGL ES sa VIVE OpenXR SDK.

• Para sa Native developer, available ang feature na ito, ngunit sa kasalukuyan, walang examples ay ibinigay.
• Para sa developer ng Unity, sumangguni sa gabay na ito.
• Para sa Unreal developer, hindi sinusuportahan ang feature na ito sa ngayon.

4.1.5 Render Mask [Not Support Unreal]
Ang konsepto dito ay katulad ng 3.1.8 Render Mask.

• Para sa Native developer, gamitin ang XrVisibilityMaskKHR para makuha ang Mesh. Bago i-render ang eksena, gamitin ang Mesh na ito para i-populate ang mga value ng depth buffer bago i-render ang eksena.
• Para sa developer ng Unity, ang tampok na Render Mask ay pinagana bilang default para sa OpenGL ES, at maaaring i-disable gamit ang sumusunod na code; Kasalukuyang hindi sinusuportahan ng Vulkan ang tampok na ito. //C# UnityEngine.XR.XRSettings.occlusionMaskScale = 0.0f;
• Para sa Unreal developer, kasalukuyang hindi sumusuporta sa feature na Render Mask.

4.2 Nilalaman ng MR
Kasalukuyang hindi sinusuportahan ng OpenXR ang pagtatakda ng Passthrough Quality at Frame Rate. Patuloy naming i-optimize at aayusin ang feature na Passthrough, kaya inirerekomenda na i-update ng mga developer ang bersyon ng FOTA ng device upang mapanatili itong napapanahon.

Karaniwang Pag-optimize

5.1 I-off ang High Performance Mode
Ang pag-off sa "High performance mode" ay maaaring mabawasan ang laki ng display ng device, at sa gayon ay mabawasan ang paggamit ng GPU. Ang disbentaha ay ang pagbaba sa resolution ng screen. Maaari mong balansehin ang kalidad at pagganap upang magpasya kung paganahin ito.
Ang lokasyon ng setting para sa VIVE Focus 3 ay ipinapakita sa Figure 5-1-1:

Ang lokasyon ng setting para sa VIVE XR Elite ay ipinapakita sa Figure 5-1-2:

5.2 MultisampLing Anti-Aliasing
MultisampSi Ling ay isang anti-aliasinAng pamamaraang g na ginagamit upang pakinisin ang mga tulis-tulis na gilid ay kadalasang pinapabilis sa pamamagitan ng hardware, na nagdudulot ng gastos sa pagganap ng GPU. Inirerekomenda namin na huwag itakda ang MSAA nang mas mataas sa 2x dahil ang mas mataas na halaga ay kumokonsumo ng mas maraming paggamit ng GPU.

• Para sa Native developer, MSAA OpenGL ES exsample maaaring sumangguni sa ito; MSAA Vulkan exampmaaaring sumangguni dito.
  Ang Adreno GPU ay nagbibigay ng extension na nag-o-optimize ng MSAA.
• Para sa developer ng Unity, sumangguni sa guild na ito.
• Para sa Unreal developer, sumangguni sa guild na ito. Nagbibigay din ang Unreal ng post processing anti-aliasing, sumangguni sa guild na ito.

5.3 GMEM Load/Store
Sa arkitektura ng Adreno GPU, mayroong feature kung saan, kapag nagbi-binding ng Render Target, kung ang Render Target ay hindi na-clear o na-invalidate, sa tuwing magaganap ang pag-render, ang mga value sa Render Target ay nilo-load sa Graphics Memory, na tinatawag na GMEM Load. Kung hindi kailangan ang mga dating value, i-clear o i-invalidate ang Render Target befaure rendering, maiiwasan ang sitwasyong ito para mapahusay ang performance ng GPU.
Maiiwasan mo ang GMEM Load gamit ang mga sumusunod na pamamaraan. Sa OpenGL ES, pagkatapos i-binding ang FBO, maaari mong tawagan ang glClear at glClearDepth para i-clear ang Color, Depth, at Stencil buffer, o tawagan ang glInvalidateFramebuffer para i-invalidate ang tinukoy na Render Target. Sa Vulkan, hindi kinakailangan ang mga karagdagang tagubilin; maaari mong tahasang itakda kung tatanggalin ang attachment bago gamitin sa VkAttachmentDescription.loadOp.
Katulad nito, ang pag-iimbak ng resulta ng isang Tile Render pabalik sa Main Memory mula sa Graphics Memory ay tinatawag na GMEM Store; mahal din ang operasyong ito para sa GPU. Para maiwasan ito, inirerekomenda namin na isailalim lang ang mga kinakailangang Render Target para maiwasan ang mga hindi kinakailangang operasyon ng Store.

5.4 Komposisyon Layer(Multi Layer)
Ang mga texture na ipinapakita gamit ang Multi-Layer ay may mas magandang visual na kalidad. Gayunpaman, ang tampok na ito ay makabuluhang nagpapataas ng pagganap ng GPU sa bilang ng mga layer at laki ng mga texture. Inirerekomenda namin ang hindi higit sa tatlong layer.

• Para sa Native developer,
  o Gumagamit ang VIVE Wave SDK ng WVR_SubmitFrameLayers upang magpasa ng data para sa bawat layer.
  o Ang VIVE OpenXR SDK ay naglalagay ng data ng layer sa XrFrameEndInfo at isinusumite ito sa pamamagitan ng xrEndFrame.
• Para sa developer ng Unity,
  o Mga setting ng VIVE Wave SDK, sumangguni sa gabay na ito,
  o mga setting ng VIVE OpenXR, sumangguni sa gabay na ito.
• Para sa Unreal developer,
  o Mga setting ng VIVE Wave SDK, sumangguni sa gabay na ito.
  o mga setting ng VIVE OpenXR, sumangguni sa gabay na ito.

5.5 CPU Spike
Kapag mas mabigat ang paglo-load ng CPU, pinoproseso ng ilang background ang mga thread na may mataas na priyoridad, maaari itong makagambala sa native execution. Hindi namin magagarantiya na ang Content Application ay hindi maaantala ng ibang thread.
Kung may ganitong mga isyung lumitaw, maaari mong subukang dagdaganasinSuriin ang thread priority para makita kung nareresolba nito ang problema. Ngunit kung babaguhin mo ang thread configuration para ma-optimize para sa mga device, kailangan mong suriin kung mayroon itong anumang negatibong epekto.

• Para sa Unity Developer, sumangguni sa feature ng configuration ng thread ng Android. Kung gumagamit ka ng VIVE Wave SDK, mayroon kaming feature sa WaveXRSettings na nagbibigay-daan sa iyong ayusin ang priority, tulad ng ipinapakita sa Figure 5-5-2. Ang mas maliit na halaga ay kumakatawan sa mas mataas na priyoridad.

• Hindi totoong walang paraan para baguhin ang thread ng laro, pag-render ng thread at priority ng thread ng RHI sa pamamagitan ng mga external na setting maliban kung babaguhin mo ang engine code.

Copyright © 2024 HTC Corporation. Lahat ng karapatan ay nakalaan

Mga Dokumento / Mga Mapagkukunan

Pagganap ng VIVE VR Rendering [pdf] Gabay sa Gumagamit Pagganap ng Pag-render ng VR, Pagganap ng Pag-render, Pagganap

Mga sanggunian

• User Manual