VR մատուցման կատարում
Կարգավորումներ և օպտիմալացումներ
Ներածություն
Սահմանափակ ռեսուրսներով սարքավորումների վրա օպտիմալ VR փորձի հասնելը սահուն և հարմարավետ օգտագործողի փորձառություն ապահովելու բանալին է: Եթե բովանդակության մատուցման կադրերի հաճախականությունը իջնում է կամ անկայուն է դառնում սարքի թարմացման հաճախականությունից ցածր, դա կհանգեցնի կադրերի թրթռման և կակազման, շարժման հիվանդության և այլնի, որոնք, ի վերջո, բացասաբար կանդրադառնան օգտագործողի փորձի վրա: Հետևաբար, բովանդակության արդյունավետության օպտիմալացումը շատ կարևոր է հաճելի փորձառություն ապահովելու համար:
Արդյունավետության կարգավորումը սկսելուց առաջ կարևոր է հասկանալ, թե որտեղ են գտնվում կատարողականի խոչընդոտները՝ անարդյունավետ կարգավորումից խուսափելու համար: Այս փաստաթուղթը նախատեսված է մշակողներին օգնելու բացահայտել կատարողականի խոչընդոտները և առաջարկել լուծումներ՝ մատուցման կատարողականի խնդիրները լուծելու համար:
Փաստաթուղթը կազմակերպված է հետևյալ բաժիններով.
- Գլուխ 2. Խոչընդոտների բացահայտում – Այս բաժինը օգնում է մշակողներին պարզել, թե որտեղ են գտնվում խոչընդոտները։
- Գլուխ 3 և 4. VIVE Wave և VIVE OpenXR կարգավորումներ – Այս բաժինները ներկայացնում են VIVE Wave և OpenXR հավելվածների CPU/GPU-ի աշխատանքի վրա ազդող կոնկրետ կարգավորումները: Մշակողները կարող են փորձարկել այս գործառույթները միացնելը կամ անջատելը` հիմնվելով աշխատանքի դժվարությունների վրա, որպեսզի որոշեն, թե արդյոք կա որևէ բարելավում:
- Գլուխ 5. Ընդհանուր օպտիմալացում – Այս բաժինը ներկայացնում է օպտիմալացման որոշ ընդհանուր գործելակերպեր և փորձ։
Ճանաչեք խոչընդոտը
Երբ HMD-ն շարժվում է, եթե VR/MR հավելվածը ունի կադրի թրթռում կամ սև եզրեր և այլն, դա սովորաբար առաջանում է վատ մատուցման աշխատանքի հետ կապված խնդրի պատճառով: Սովորաբար, մատուցման աշխատանքի հետ կապված խնդիրները կարելի է դասակարգել 2 տեսակի՝ կապված CPU-ի կամ GPU-ի հետ: Սկզբում շատ կարևոր է հասկանալ, թե ձեր հավելվածի համար որ տեսակի կապակցվածությունն է կարևոր՝ անարդյունավետ կարգավորումից խուսափելու համար:
Այս գլխում մենք ներկայացնում ենք պարզ քայլեր, որոնք թույլ կտան ձեզ արագորեն պարզել, թե որտեղ են գտնվում կատարողականի խնդիրները։
2.1 Ստուգեք բովանդակության մատուցման FPS-ը
Նախ, մենք սկսում ենք բովանդակության FPS-ը ստուգելուց, այսինքն՝ բովանդակության կողմից վայրկյանում նկարահանվող կադրերի քանակը։ Այն պետք է պահպանվի ցուցադրվող կադրերի հաճախականության սահմաններում և մնա կայուն։ Հակառակ դեպքում, դա կարող է կադրերի թրթռում առաջացնել։
Եթե ձեր ծրագրի SDK-ն օգտագործում է VIVE WAVE SDK 6.0.0 կամ ավելի նոր տարբերակ, կարող եք օգտագործել հետևյալ adb հրամանը՝ FPS-ը ստուգելու համար։ DK 6.0.0
$adb Logcat -s VRMetric
Դուք կտեսնեք հետևյալ գրանցամատյանի տվյալները։
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»: Առաջին թիվը ներկայացնում է բովանդակության FPS-ը, իսկ երկրորդ թիվը՝ ցուցադրման կադրերի հաճախականությունը։
Եթե ձեր Wave SDK տարբերակը 6.0.0-ից ցածր է, խորհուրդ է տրվում այն թարմացնել վերջին տարբերակին՝ մատուցման արդյունավետությունը բարելավելու և այլ գործառույթների օպտիմալացման համար։
Եթե ձեր ծրագրի SDK-ն կառուցված է VIVE OpenXR-ով, կարող եք օգտագործել հետևյալ adb հրամանը՝ FPS-ը ստուգելու համար։
$adb Logcat -s RENDER_ATW
Դուք կտեսնեք հետևյալ գրանցամատյանի տվյալները
RENDER_ATW: [FPS] նոր հյուսվածք՝ 90.00
RENDER_ATW: [FPS] R ներկա՝ 90.00 բաց թողնել՝ 0 317, -0.0155 0.805527, 0.006788)
RENDER_ATW՝ [FPS] L ներկա՝ 90.00 բաց թողնել՝ 0 (0.592301, -0.015502, 0.805539, 0.006773)
«Նոր հյուսվածք»-ին հաջորդող թիվը ներկայացնում է ներկայումս բավարար FPS-ը: «R առկա է» և «L առկա է» թվերին հաջորդող թիվը ներկայացնում է կադրերի հաճախականությունը:
Երբեմն բովանդակության FPS-ը և էկրանի կադրերի հաճախականությունը կարող են փոքր-ինչ տարբեր լինել։
Նախampօրինակ, վերը նշված դեպքում 89.8 FPS-ը կարող է համարվել 90 FPS։
Եթե հավելվածի բովանդակության FPS-ը մշտապես ցածր է էկրանի կադրերի հաճախականությունից կամ մնում է անկայուն, դա վկայում է մատուցման արդյունավետության խնդրի մասին: Հետևաբար, հաջորդ քայլը պարզելն է, թե արդյոք խոչընդոտը գալիս է CPU-ից, թե GPU-ից:
2.2 Ստուգեք CPU-ի և GPU-ի օգտագործումը
Եթե ձեր ծրագրի SDK-ն օգտագործում է VIVE WAVE SDK 6.0.0 կամ ավելի նոր տարբերակ, կարող եք օգտագործել հետևյալ adb հրամանը՝ FPS-ը ստուգելու համար։
$adb logcat -s VRMetric
Դուք կտեսնեք հետևյալ գրանցամատյանի տվյալները։
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
Ինչպես կարող եք տեսնել վերևում գրանցամատյանի արդյունքում, CPU-ի օգտագործումը կազմում է 27%, իսկ GPU-ի օգտագործումը՝ 72%: Եթե ձեր Wave SDK-ի տարբերակը 6.0.0-ից ցածր է, խորհուրդ է տրվում այն թարմացնել վերջին տարբերակին՝ մատուցման արդյունավետությունը բարելավելու և այլ գործառույթների օպտիմալացման համար:
VIVE OpenXR հավելվածի համար կարող եք օգտագործել հետևյալ հրամանը՝ CPU-ի և GPU-ի օգտագործումը ստուգելու համար։
# Linux/Ubuntu-ի վրա
$ adb logcat | grep CPU_USAGE
# PowerShell-ի վրա
$ adb logcat | Ընտրեք-String -Pattern CPU_USAGE
Դուք կտեսնեք հետևյալ գրանցամատյանը
CPU միջին CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 GPU CPU_USAGE [Բեռնված] 25.67% 32.22% 25.29% 30.77% 29.35% 21.35% 22.09% 18.39% 24.14% 73 %
Եթե նկատեք, որ FPS-ը չի կարող պահպանել ցուցադրման կադրերի հաճախականությունը, և GPU-ի օգտագործումը նույնպես շատ բարձր է, սովորաբար գերազանցում է 85%-ը, կարող եք փորձել կարգավորել Eyebuffer Resolution-ը (բաժին 3.1.2, բաժին 4.1.2)՝ տեսնելու համար, թե արդյոք դա բարելավում է FPS-ը: Եթե այս կարգավորումը հանգեցնում է ավելի լավ արդյունքի,
կատարողականության հետ կապված, կարող ենք եզրակացնել, որ խնդիրը կապված է GPU-ի հետ և մեր օպտիմալացման ջանքերը կենտրոնացնել համապատասխանաբար։
Մյուս կողմից, եթե Eyebuffer Resolution-ի կարգավորումը չի հանգեցնում կատարողականի նկատելի բարելավման, ապա խնդիրը, հավանաբար, պրոցեսորի հետ է կապված, և մենք պետք է կենտրոնանանք պրոցեսորի կատարողականի օպտիմալացման վրա։
Հնարավոր է նաև, որ ծրագիրը միաժամանակ կապված լինի և՛ պրոցեսորի, և՛ գրաֆիկական պրոցեսորի հետ։ Նման դեպքերում օպտիմալացման ջանքերը պետք է կիրառվեն և՛ պրոցեսորի, և՛ գրաֆիկական պրոցեսորի վրա՝ հավասարակշռված կատարողականության բարելավումներ ապահովելու համար։
2.3 GPU-ի հետ կապված
Երբ VR հավելվածը կապված է GPU-ի հետ, դա նշանակում է, որ GPU-ն հիմնական խոչընդոտն է, և այն չի կարողանում բավարարել հավելվածի մատուցման պահանջները: GPU-ի հետ կապված խնդիրները մեղմելու համար հաշվի առեք հետևյալ առաջարկությունները.
Նախ, օգտագործեք պրոֆիլավորման գործիքներ, ինչպիսիք են RenderDoc-ը կամ Game Engine pro-նfiler (Unity Pro)filer, Unreal Insights)՝ վերլուծելու համար, թե որտեղ է գրաֆիկական պրոցեսորը (GPU) անցկացնում իր ժամանակի մեծ մասը։ Նույնականացնել ամենաթանկ գործողությունները և կենտրոնանալ դրանց օպտիմալացման վրա։
Native Developer-ի դեպքում կարող եք օգտագործել RenderDoc-ը՝ պարզելու համար, թե որ draw կանչն է առաջացնում GPU-ի չափազանց մեծ ծանրաբեռնվածություն։
Unity Developer-ի համար կարող եք հետևել Unity-ի այս փաստաթղթին կամ օգտագործել RenderDoc-ը՝ մատուցման կատարողականի խնդիրը վերլուծելու համար, ինչպես նաև հետևել Unity-ի գրաֆիկայի օպտիմալացման փաստաթղթերին՝ ձեր ծրագիրը օպտիմալացնելու ուղեցույցի համար։
Unreal Developer-ի համար կարող եք օգտագործել GPU Visualizer-ը կամ RenderDoc-ը՝ մատուցման կատարողականության խնդիրը վերլուծելու համար, և հետևել Unreal Performance Guidelines-ին՝ ձեր ծրագիրը օպտիմալացնելու համար։
Երկրորդ, կարող եք նաև փորձել կարգավորել Wave-ի որոշակի գործառույթներ կամ կարգավորումներ՝ GPU-ի ծանրաբեռնվածությունը նվազեցնելու համար։
- Սահմանել էկրանի թարմացման հաճախականությունը ավելի դանդաղ (բաժին 3.1.1, բաժին 4.1.1)
- Աչքի բուֆերի լուծաչափի կարգավորում (բաժին 3.1.2, բաժին 4.1.2), 14.1.1)
- Փորձեք միացնել Foveation-ը (բաժին 3.1.4, բաժին 4.1.4):
Եթե ձեր հավելվածը նաև MR հավելված է, կարող եք նաև կարգավորել Passthrough կարգավորումները։
- Կարգավորեք անցնող պատկերի որակը ցածր (բաժին 3.2.1)
- Կարգավորեք անցման կադրերի հաճախականությունը (Passthrough Frame rate) ավելի դանդաղ։ (բաժին 3.2.2):
GPU-ի աշխատանքի վերաբերյալ այլ կարգավորումների համար կարող եք դիմել 2.6 գլխին։
2.4 CPU-ի հետ կապված
Երբ VR հավելվածը կապված է պրոցեսորի հետ, դա նշանակում է, որ պրոցեսորը հիմնական խոչընդոտն է, հաշվի առեք հետևյալ առաջարկությունները.
Նախ, օգտագործեք պրոֆիլավորման գործիքներ, ինչպիսիք են Systrace-ը կամ Game Engine pro-նfiler (Unity Pro)filer, Unreal Insights)՝ վերլուծելու և պարզելու համար, թե ձեր կոդի որ մասերն են ամենաշատը սպառում CPU-ի ռեսուրսները: Կենտրոնացեք այս ոլորտների օպտիմալացման վրա և վերափոխեք հաշվողականորեն ինտենսիվ ալգորիթմները՝ CPU-ի բեռը նվազեցնելու համար:
- Native Developer-ի համար կարող եք օգտագործել Systrace-ը՝ պրոֆեսիոնալիզմի համար։fileձեր նախագիծը։
- Unity Developer-ի համար կարող եք օգտագործել CPU Usage Pro-նfiler մոդուլ՝ պրոցեսորի աշխատանքի խնդիրը գտնելու համար։
- Unreal Developer-ի համար կարող եք օգտագործել Unreal-ի Insights-ը՝ CPU-ի աշխատանքի հետ կապված խնդիրը գտնելու համար։
Երկրորդ, կարող եք նաև փորձել կարգավորել Wave-ի որոշակի գործառույթներ կամ կարգավորումներ՝ GPU-ի ծանրաբեռնվածությունը նվազեցնելու համար։
- Սահմանել էկրանի թարմացման հաճախականությունը ավելի դանդաղ (բաժին 3.1.1, բաժին 4.1.1)
- Օգտագործեք բազմա-View Մատնանշում (բաժին 3.1.4, բաժին 4.1.4)
Եթե ձեր հավելվածը նաև MR հավելված է, կարող եք նաև կարգավորել Passthrough կարգավորումները։
- Կարգավորեք Passthrough կադրերի հաճախականության դանդաղեցումը (բաժին 3.2.2):
CPU-ի աշխատանքի վերաբերյալ այլ կարգավորումների համար կարող եք դիմել 2.6 գլխին։
2.5 Ամփոփում
Վերջապես, մենք վերը նշված կատարողականի ստուգման աշխատանքային հոսքը կազմակերպել ենք նկար 2-5-1-ում: Սկսեք բովանդակության FPS-ը ստուգելուց: Եթե այն ցածր է ցուցադրման կադրերի հաճախականությունից կամ մնում է անկայուն, ապա վերլուծեք GPU/CPU-ի օգտագործումը՝ որոշելու համար, թե արդյոք այն կապված է GPU-ի, թե CPU-ի հետ: Վերջապես, օգտագործեք պրոֆեսիոնալfiler՝ հնարավոր կատարողականության խնդիրները բացահայտելու կամ Wave-ի գործառույթները կամ կարգավորումները կարգավորելու համար՝ CPU-ի կատարողականությունը օպտիմալացնելու համար։
2.6 Հակիրճ հղումներ. Ո՞ր կարգավորումները կարող են բարելավել CPU/GPU բեռնվածությունը
Ստորև թվարկեք SDK-ի կարգավորումները, որոնք կապված են CPU/GPU բեռնման հետ: Կարող եք հիմնվել ծրագրի խոչընդոտի վրա՝ համապատասխան օպտիմալացման կարգավորումները ստուգելու համար:
CPU-ի հետ կապված՝
- VIVE Wave SDK-ի կարգավորում
o VR բովանդակություն
▪ 3.1.1 Էկրանի թարմացման հաճախականություն
▪ 3.1.4 Բազմա-View Ներկայացում
▪ 3.1.6 Հարմարվողական որակ
▪ 3.1.7 Ադապտիվ շարժման կոմպոզիտոր
o MR բովանդակություն
▪ 3.2.2 Կադրերի անցման հաճախականության կարգավորում - VIVE OpenXR SDK-ի կարգավորում
o VR բովանդակություն
▪ 4.1.1 Էկրանի թարմացման հաճախականություն
▪ 4.1.4 Բազմա-View Ներկայացում - Ընդհանուր օպտիմալացում
o 5.5 CPU Spike
Կապված GPU-ի հետ՝
- VIVE Wave SDK-ի կարգավորում
o VR բովանդակություն
▪ 3.1.1 Էկրանի թարմացման հաճախականություն
▪ 3.1.2 Աչքի բուֆերի լուծաչափ
▪ 3.1.3 Բազմա-View Ներկայացում
▪ 3.1.4 Ֆովեացիա
▪ 3.1.5 Կադրի սրության բարելավում (FSE)
▪ 3.1.6 Հարմարվողական որակ
▪ 3.1.7 Ադապտիվ շարժման կոմպոզիտոր
▪ 3.1.8 Render Mask [Not Support Unreal]
o MR բովանդակություն
▪ 3.2.1 Կարգավորել անցման որակը
▪ 3.2.2 Կադրերի անցման հաճախականության կարգավորում - VIVE OpenXR SDK-ի կարգավորում
o VR բովանդակություն
▪ 4.1.1 Էկրանի թարմացման հաճախականություն
▪ 4.1.2 Աչքի բուֆերի լուծաչափ
▪ 4.1.3 Բազմա-View Ներկայացում
▪ 4.1.4 Foveation [Not Support Unreal]
▪ 4.1.5 Render Mask [Not Support Unreal] - Ընդհանուր օպտիմալացում
o 5.1 Բարձր արդյունավետության ռեժիմի անջատում
o 5.2 բազմապատիկampլինգ
o 5.3 GMEM Բեռնում/Պահեստավորում
o 5.4 Կոմպոզիցիայի շերտ (բազմաշերտ)
VIVE ալիքի կարգավորում
VIVE Wave-ը բաց հարթակ և գործիքակազմ է, որը թույլ է տալիս հեշտությամբ մշակել VR բովանդակություն և ապահովում է բարձր արդյունավետությամբ սարքերի օպտիմալացում երրորդ կողմի գործընկերների համար: VIVE Wave-ը աջակցում է Unity և Unreal խաղային շարժիչներին:
Մենք անընդհատ օպտիմալացնում և լուծում ենք տարբեր սխալներ, ուստի խորհուրդ ենք տալիս SDK-ն թարմացված պահել։
Ներկայումս VIVE Wave-ը աջակցում է միայն OpenGL ES-ին: Ահա գործառույթները դասավորված ըստ GPU-ի աշխատանքի վրա ազդեցության: Մենք դրանք կբաժանենք երկու մասի՝ VR բովանդակություն և MR բովանդակություն:
3.1 VR բովանդակություն
3.1.1 Էկրանի թարմացման հաճախականություն
Ավելի բարձր թարմացման հաճախականությունները ապահովում են ավելի հարթ տեսողական էֆեկտներ, սակայն դրանք առաջանում են համակարգի ծանրաբեռնվածության ավելացման գնով։ Եվ հակառակը, ավելի ցածր թարմացման հաճախականությունները նվազեցնում են համակարգի ծանրաբեռնվածությունը, սակայն հանգեցնում են ավելի քիչ հարթ տեսողական էֆեկտների։ Եթե հավելվածն ունի CPU/GPU-ի հետ կապված խնդիր, կարող եք փորձել նվազեցնել։asing էկրանի թարմացման հաճախականությունը՝ խնդիրը մեղմելու համար։
- Native մշակողի համար դիմեք WVR_SetFrameRate-ին։
- Unity մշակողների համար դիմեք այս ուղեցույցին։
- Unreal մշակողների համար դիմեք այս ուղեցույցին։
3.1.2 Աչքի բուֆերի լուծաչափ
Eyebuffer-ի լուծումը տեքստուրայի չափն է, որը պետք է մշակվի հավելվածում։ Մշակված տեքստուրան կներկայացվի գործարկման ժամանակին՝ հրապարակման գործընթացը կատարելու և HMD էկրանին ներկայացնելու համար։
Թեև աչքի բուֆերի ավելի մեծ չափը կարող է հանգեցնել ավելի պարզ և մանրամասն տեսողական պատկերների, այն նաև զգալի ծանրաբեռնվածություն է ստեղծում GPU-ի վրա: Հետևաբար, կարևոր է գտնել տեսողական որակի և կատարողականության միջև ճիշտ հավասարակշռությունը:
Եթե հավելվածն ունի GPU-ի հետ կապված խնդիր, կարող եք փորձել decre-նasinԱչքի բուֆերի չափը բազմապատկեք մասշտաբի գործակիցը։ Այնուամենայնիվ, խորհուրդ ենք տալիս մասշտաբի գործակիցը չնվազեցնել 0.7-ից ցածր, քանի որ դա կարող է հանգեցնել անընդունելի տեսողական որակի։
- Native մշակողի համար դիմեք WVR_ObtainTextureQueue-ին: Չափը կարգավորելիս պետք է լայնությունը և բարձրությունը բազմապատկել որոշակի հարաբերակցությամբ:
- Unity մշակողի համար դիմեք WaveXRSettings-ին։
Այլընտրանքորեն, դուք կարող եք փոփոխություններ կատարել կոդի միջոցով, ինչպես օրինակ՝ belwoe։
XRSettings.eyeTextureResolutionScale = ResolutionScaleValue; // C# - Unreal մշակողի համար դիմեք SetPixelDensity-ին։
3.1.3 ԲազմաթիվView Ներկայացում
Ավանդական ռենդերինգի դեպքում մենք ձախ և աջ աչքերը նկարում ենք առանձին, ինչը նույն տեսարանի համար պահանջում է երկու նկարման կանչ։View Ռենդերիզացումը լուծում է այս խնդիրը՝ կատարելով միայն մեկ draw կանչ։
Այս գործառույթը նվազեցնում է պրոցեսորի ծանրաբեռնվածությունը մի քանի անգամasing-ն՝ նկարելու կանչերի քանակը։ GPU-ն նույնպես ունի որոշ առավելություններ, գագաթային շեյդերի աշխատանքային ծանրաբեռնվածությունը նույնպես կրճատվում է, քանի որ այն կարիք չունի լրացուցիչ շեյդեր աշխատեցնել մյուս աչքի համար, բայց ֆրագմենտային շեյդերի աշխատանքային ծանրաբեռնվածությունը մնում է անփոփոխ, քանի որ այն դեռ պետք է գնահատի յուրաքանչյուր պիքսելը երկու աչքերի համար։ Մենք խորհուրդ ենք տալիս միացնել այս գործառույթը։
- Native մշակողի համար կարող եք դիմել wvr_native_hellovr s-ին։ampլե.
- Unity մշակողի համար դիմեք Render Mode-ին, մեկ անցումը բազմակի էview հատկանիշ.
- Unreal մշակողների համար դիմեք այս ուղեցույցին։
3.1.4 Ֆովեացիա
Ֆովատացված ռենդերինգը հիմնականում նախատեսված է GPU-ի ծանրաբեռնվածությունը նվազեցնելու համար։ Այն նվազեցնում է կադրի մանրամասները էկրանի ծայրամասային մասում և պահպանում է բարձր թույլտվության մանրամասները դաշտի կենտրոնում։ viewԵթե հավելվածը GPU-ի հետ կապված խնդիր ունի, կարող եք փորձել Foveation-ի ռենդերինգի eanbling-ը։
Ֆովեացիան օգտագործելիս պետք է ուշադրություն դարձնել հետևյալին.
➢ Ֆովեացիայի լռելյայն ռեժիմը կիրառելիս օգտատերերը սովորաբար չեն նկատում ծայրամասային հատվածներում մանրամասների նվազումը։ Սակայն, եթե ֆովեացիայի ծայրամասային որակը սահմանված է չափազանց ցածր, այն կարող է նկատելի դառնալ օգտատիրոջ համար։
➢ Ֆովեացիայի ազդեցությունը կարող է ավելի նկատելի լինել որոշակի հյուսվածքային նյութերի դեպքում, որոնք կարող են գրավել օգտատիրոջ ուշադրությունը։ Մշակողները պետք է տեղյակ լինեն դրա մասին և համապատասխանաբար գնահատեն այն։
➢ Ֆովատացված ռենդերինգի գործառույթի միացումը ենթադրում է GPU-ի ֆիքսված կատարողականի ծախս, որը կարող է տատանվել 1%-ից մինչև 6%՝ կախված աչքի բուֆերի չափից։ Երբ տեսարանում օգտագործվում է պարզ շեյդեր, ռեսուրսների խնայողությունից ստացված կատարողականի աճը կարող է ավելի ցածր լինել, քան GPU-ի ֆիքսված կատարողականի արժեքը, ինչը հանգեցնում է կատարողականի անկման։
- Native մշակողի համար դիմեք այս ուղեցույցին։
- Unity մշակողների համար դիմեք այս ուղեցույցին: Հատկանշական է, որ երբ դուք միացնում եք հետմշակումը կամ HDR-ը, ֆովացիան չի կարող լիովին օգտագործվել: Քանի որ Unity-ն օբյեկտները կարտացոլի իր սեփական գեներացված ռենդեր հյուսվածքի վրա, այլ ոչ թե կատարման ժամանակ գեներացված ներկայացման ռենդեր հյուսվածքի վրա, որը աջակցում է ֆովացիան:
- Unreal մշակողների համար դիմեք այս ուղեցույցին։ Նշենք, որ foveation-ը չի կարող լիովին օգտագործվել Multi-ում։View Ռենդերինգ, քանի որ Unreal-ը չի կարող անմիջապես ռենդերինգ անել օբյեկտները Runtime-ի կողմից ստեղծված ռենդերինգի հյուսվածքի վրա, որն աջակցում է ֆովեացիան։
3.1.5 Կադրի սրության բարելավում (FSE)
FSE-ն, որը սրում է ռենդերինգի արդյունքը՝ սրման ֆիլտրի ներդրման միջոցով, կարող է բովանդակությունն ավելի պարզ դարձնել և բավականին օգտակար լինել տեսարանում տեքստի պարզությունը բարելավելու համար: Եթե հավելվածն ունի GPU-ի հետ կապված խնդիր, կարող եք դիտարկել FSE-ն անջատելու հնարավորությունը, եթե դա անհրաժեշտ չէ:
- Native մշակողի համար դիմեք այս ուղեցույցին։
- Unity մշակողների համար դիմեք այս ուղեցույցին։
- Unreal մշակողների համար դիմեք այս ուղեցույցին։
3.1.6 Հարմարվողական որակ
Մարտկոցի լիցքը խնայելու և սարքի մատուցման արդյունավետությունը պահպանելու համար այս գործառույթը ավտոմատ կերպով կարգավորում է CPU/GPU ժամացույցի աշխատանքի մակարդակները՝ հիմնվելով դրանց օգտագործման վրա: Բացի այդ, կարող են իրականացվել այլ ռազմավարություններ՝ աշխատանքը բարելավելու համար, ինչպիսիք են Foveation-ի ավտոմատ միացումը/անջատումը, կամ բովանդակությունը կարող է ինքնուրույն կարգավորվել, եթե ստանում է բարձր/ցածր բեռի իրադարձություններ:
- Native մշակողի համար դիմեք այս ուղեցույցին։
- Unity մշակողների համար դիմեք այս ուղեցույցին: Մեր Unity հավելվածում աչքի բուֆերի չափը կարող է ավտոմատ կերպով կարգավորվել՝ հիմնվելով ընթացիկ կատարողականության վրա. Տեքստի չափը կֆիլտրի մասշտաբի արժեքները, որոնք չափազանց փոքր են «Խնդիրների ցանկում»: Մենք խորհուրդ ենք տալիս տեքստը օգտագործել առնվազն 20 dmm կամ ավելի մեծ չափի:
- Unreal մշակողների համար դիմեք այս ուղեցույցին։
3.1.7 Ադապտիվ շարժման կոմպոզիտոր
Այս գործառույթը փորձարարական է, որը ներառում է UMC և PMC: UMC-ն կիսով չափ կնվազեցնի կադրերի հաճախականությունը և կարտապոլացնի նոր կադրերը իրական ժամանակում՝ տեսողական սահունությունը պահպանելու համար: Այնուամենայնիվ, այն ունի որոշակի լատենտություն, արտեֆակտներ և GPU բեռնվածություն:
PMC-ն հիմնականում օգտագործում է խորության բուֆերը՝ ATW-ին թույլ տալու համար հաշվի առնել HMD թարգմանությունը, մինչև 6-dof փոխհատուցում: Այս գործառույթը կարող է կրճատել թարգմանության լատենտությունը 1~2 կադրով, բայց մեծացնել GPU-ի բեռնվածությունը:
- Native մշակողի համար դիմեք այս ուղեցույցին։
- Unity մշակողների համար դիմեք այս ուղեցույցին։
- Unreal մշակողների համար դիմեք այս ուղեցույցին։
3.1.8 Ռենդերի դիմակ [Չի աջակցում Unreal-ը]
Աղավաղումից հետո եզրերի մոտ գտնվող պիքսելները գրեթե անտեսանելի են դառնում, ռենդերինգի դիմակը փոփոխում է այդ անտեսանելի պիքսելների խորության բուֆերի արժեքները: Եթե միացնեք խորության թեստավորումը, վաղ Z տարբերակի պատճառով այս անտեսանելի պիքսելները չեն ռենդերվի, այդպիսով նվազեցնելով GPU-ի ծանրաբեռնվածությունը: Այս գործառույթը օգտակար է, եթե այս անտեսանելի տարածքներում կան ծանրաբեռնված ռենդերինգի օբյեկտներ. հակառակ դեպքում, եթե այս տարածքներում ռենդերինգի օբյեկտներ չկան, խորհուրդ է տրվում անջատել այն, քանի որ այն կծախսի GPU-ի փոքր օգտագործումը:
- Native մշակողի համար դիմեք այս ուղեցույցին: RenderMask-ը կանչելուց առաջ դուք պետք է կապեք խորության բուֆերը, հակառակ դեպքում այն անարդյունավետ կլինի:
- Unity մշակողների համար դիմեք այս ուղեցույցին։
- Unreal մշակողների համար ներկայումս չի աջակցվում Render Mask գործառույթը։
3.2 ՄՌ պարունակություն
3.2.1 Կարգավորել անցման որակը
Անցումային պատկերի որակի համար կա 3 մակարդակ՝
➢ WVR_PassthroughImageQuality_DefaultMode – հարմար է MR բովանդակության համար՝ առանց որևէ հատուկ պահանջի։
➢ WVR_PassthroughImageQuality_PerformanceMode – հարմար է MR բովանդակության համար, որը վիրտուալ տեսարանի ռենդերինգի համար ավելի շատ GPU ռեսուրս է պահանջում։
➢ WVR_PassthroughImageQuality_QualityMode – հարմար է MR բովանդակության համար, որը թույլ է տալիս օգտատերերին հստակ տեսնել շրջակա միջավայրը, սակայն բովանդակության վիրտուալ տեսարանը պետք է ունենա ավելի նուրբ կարգավորում՝ արդյունավետության համար։
Դուք կարող եք Passthrough որակը կարգավորել PerformanceMode-ի՝ GPU-ի օգտագործումը նվազեցնելու համար։
- Native, Uunity կամ Unreal մշակողների համար դիմեք այս ուղեցույցին։
3.2.2 Կարգավորել կադրերի հաճախականությունը
Ինչպես էկրանի թարմացման հաճախականությունը, ավելի բարձր անցման կադրերի հաճախականությունը (Passthrough) ապահովում է ավելի հարթ պատկերներ, սակայն դա հանգեցնում է համակարգի ծանրաբեռնվածության ավելացման: Եվ հակառակը, ավելի ցածր թարմացման հաճախականությունները նվազեցնում են համակարգի ծանրաբեռնվածությունը, սակայն հանգեցնում են ավելի քիչ հարթ պատկերների: Կան անցման կադրերի հաճախականության 2 ռեժիմ՝ Boost և Normal:
- Native մշակողների համար կարող եք կարգավորել փոխանցման որակը՝ օգտագործելով WVR_SetPasthroughImageRate ֆունկցիան։
- Unity մշակողի համար կարող է փոխվել կոդի միջոցով, օրինակ՝ampկարգավորումները հետևյալն են // C#
Interop.WVR_SetPasthroughImageQuality(WVR_PasthroughImageQuality.PerformanceMode); - Unreal մշակողի, կարգավորման մեթոդի համար տե՛ս նկար 3-2-2-ում ներկայացված blueprint հանգույցը։
VIVE OpenXR կարգավորում
OpenXR-ը բաց ստանդարտ է, որը տրամադրում է API-ների ընդհանուր հավաքածու՝ XR հավելվածներ մշակելու համար, որոնք աշխատում են VR սարքերի լայն շրջանակում, մշակված Khronos Group-ի կողմից: VIVE Focus 3-ը և VIVE XR Elite-ը նույնպես աջակցում են OpenXR-ին, VIVE OpenXR SDK-ն ապահովում է HTC VR սարքերի համապարփակ աջակցություն՝ թույլ տալով մշակողներին ստեղծել Allin-One և բովանդակություն Unity և Unreal շարժիչներով HTC VR սարքերի վրա: Մենք անընդհատ օպտիմալացնում և լուծում ենք տարբեր սխալներ, ուստի խորհուրդ է տրվում, որ մշակողները թարմացնեն իրենց սարքի FOTA տարբերակը՝ այն թարմացված պահելու համար: Ներկայումս VIVE OpenXR SDK-ն աջակցում է OpenGL ES-ին և Vulkan-ին:
4.1 VR բովանդակություն
4.1.1 Էկրանի թարմացման հաճախականություն
Այստեղ գաղափարը նման է 3.1.1 Display Refresh Rate-ին։
- Native մշակողի համար դիմեք XrEventDataDisplayRefreshRateChangedFB-ին։
- Unity մշակողների համար դիմեք այս ուղեցույցին։
- Unreal մշակողների համար դիմեք այս ուղեցույցին։
4.1.2 Աչքի բուֆերի լուծաչափ
Այստեղ գաղափարը նման է 3.1.2 Eyebuffer Resolution-ին։ Մենք խորհուրդ ենք տալիս մասշտաբի գործակիցը չնվազեցնել 0.7-ից ցածր, քանի որ դա կարող է հանգեցնել անընդունելի տեսողական որակի։
- Native մշակողի համար դիմեք xrCreateSwapchain-ին: Չափը կարգավորելիս պետք է լայնությունը և բարձրությունը բազմապատկել որոշակի հարաբերակցությամբ:
- Unity մշակողի համար դիմեք հետևյալ օրինակինampլ // C#
XRSettings.eyeTextureResolutionScale = 0.7f; //խորհուրդ է տրվում 1.0f~0.7f - Անիրական կարգավորումների համար դիմեք այս ուղեցույցին։
4.1.3 ԲազմաթիվView Ներկայացում
Այստեղ հայեցակարգը նման է 3.1.3 Բազմա-View Մոդելավորում։ Այս գործառույթը նվազեցնում է պրոցեսորի ծանրաբեռնվածությունը, գրաֆիկական պրոցեսորը նույնպես ունի որոշ առավելություններ։ Մենք խորհուրդ ենք տալիս միացնել այս գործառույթը։
- Native մշակողների համար KhronosGroup-ը տրամադրում է OpenXR Multi-View exampլե, դիմեք այս ուղեցույցին։
- Unity մշակողի համար դիմեք Render Mode-ին, մեկ անցումը բազմակի էview հատկանիշ.
- Unreal մշակողի, ինչպես նաև VIVE Wave-ի կարգավորումների համար դիմեք այս ուղեցույցին։
4.1.4 Ֆովեացիա [Չի աջակցում Unreal-ին]
Այստեղ գաղափարը նման է 3.1.4 Foveation-ին։ Foveated rendering-ը հիմնականում նախատեսված է GPU-ի բեռը նվազեցնելու համար, բայց դրա միացումը կհանգեցնի GPU-ի կատարողականի ֆիքսված ծախսերի, և եթե foveation-ը սահմանված է չափազանց ցածր և օգտագործվում են որոշակի նյութեր կամ հյուսվածքներ, այն կարող է շատ...
նկատելի է օգտատիրոջ համար: Հետևաբար, խորհուրդ է տրվում միացնել կամ անջատել գործառույթը՝ հիմնվելով ձեր կոնկրետ պահանջների և կատարողականի նկատառումների վրա: Ներկայումս Foveated ֆունկցիոնալությունը աջակցվում է միայն OpenGL ES-ում VIVE OpenXR SDK-ի վրա:
- Native մշակողների համար այս գործառույթը հասանելի է, բայց ներկայումս՝ ոչ։ampտրամադրված են:
- Unity մշակողների համար դիմեք այս ուղեցույցին։
- Unreal մշակողների համար այս գործառույթը ներկայումս չի աջակցվում։
4.1.5 Ռենդերի դիմակ [Չի աջակցում Unreal-ը]
Այստեղ կոնցեպտը նման է 3.1.8 Render Mask-ին։
- Native մշակողների համար օգտագործեք XrVisibilityMaskKHR-ը՝ Mesh-ը ստանալու համար: Տեսարանը արտապատկերելուց առաջ օգտագործեք այս Mesh-ը՝ տեսարանը արտապատկերելուց առաջ խորության բուֆերի արժեքները լրացնելու համար:
- Unity մշակողների համար Render Mask գործառույթը OpenGL ES-ի համար լռելյայնորեն միացված է և կարող է անջատվել հետևյալ կոդով. Vulkan-ը ներկայումս չի աջակցում այս գործառույթը։ //C# UnityEngine.XR.XRSettings.occlusionMaskScale = 0.0f;
- Unreal մշակողների համար ներկայումս չի աջակցվում Render Mask գործառույթը։
4.2 ՄՌ պարունակություն
OpenXR-ը ներկայումս չի աջակցում անցման որակի և կադրերի հաճախականության կարգավորումները: Մենք կշարունակենք օպտիմալացնել և շտկել անցման գործառույթը, ուստի խորհուրդ է տրվում մշակողներին թարմացնել սարքի FOTA տարբերակը՝ այն թարմացված պահելու համար:
Ընդհանուր օպտիմալացում
5.1 Բարձր արդյունավետության ռեժիմի անջատում
«Բարձր արդյունավետության ռեժիմը» անջատելը կարող է փոքրացնել սարքի էկրանի չափը, այդպիսով նվազեցնելով GPU-ի օգտագործումը: Թերությունը էկրանի լուծաչափի նվազումն է: Դուք կարող եք հավասարակշռել որակը և արդյունավետությունը՝ որոշելու համար, թե արդյոք այն միացնել:
VIVE Focus 3-ի տեղադրման վայրը ցույց է տրված նկար 5-1-1-ում։
VIVE XR Elite-ի տեղադրման վայրը ցույց է տրված նկար 5-1-2-ում։
5.2 Multisampլինգ Անթի-Ալիasing
Multisampլինգը հակաալի էasing տեխնիկան, որն օգտագործվում է անկանոն եզրերը հարթեցնելու համար, սովորաբար արագացվում է սարքավորումների միջոցով, ինչը հանգեցնում է GPU-ի աշխատանքի ծախսերի: Մենք խորհուրդ ենք տալիս MSAA-ն չսահմանել 2x-ից բարձր, քանի որ բարձրության ավելի մեծ արժեքը կօգտագործի ավելի շատ GPU:
- Բնիկ մշակողի համար, MSAA OpenGL ES exsample կարող է անդրադառնալ այս; MSAA Vulkan նախկինampլեր կարող է անդրադառնալ սրան։
Adreno GPU-ն ապահովում է MSAA-ն օպտիմալացնող ընդլայնում։ - Unity մշակողների համար դիմեք այս գիլդիային։
- Unreal-ի մշակողների համար դիմեք այս գիլդիային: Unreal-ը նաև ապահովում է հետմշակումային հակաալի:asinգ, դիմեք այս գիլդիային։
5.3 GMEM Բեռնում/Պահեստավորում
Adreno GPU ճարտարապետության մեջ կա մի գործառույթ, որի դեպքում Render Target-ը կապելիս, եթե Render Target-ը չի մաքրվում կամ անվավեր է դառնում, ամեն անգամ, երբ տեղի է ունենում ռենդերինգ, Render Target-ի արժեքները բեռնվում են գրաֆիկական հիշողության մեջ, որը կոչվում է GMEM Load: Եթե նախորդ արժեքները անհրաժեշտ չեն, Render Target-ը մաքրելը կամ անվավեր դարձնելը ռենդերինգից առաջ կարող է խուսափել այս իրավիճակից՝ GPU-ի աշխատանքը բարելավելու համար:
Դուք կարող եք խուսափել GMEM բեռնումից՝ օգտագործելով հետևյալ մեթոդները: OpenGL ES-ում, FBO-ն կապելուց հետո, կարող եք կանչել glClear և glClearDepth՝ Color, Depth և Stencil բուֆերը մաքրելու համար, կամ կանչել glInvalidateFramebuffer՝ նշված Render Target-ը անվավեր ճանաչելու համար: Vulkan-ում լրացուցիչ հրահանգներ անհրաժեշտ չեն. VkAttachmentDescription.loadOp-ում կարող եք հստակորեն սահմանել, թե արդյոք մաքրել կցորդը օգտագործելուց առաջ:
Նմանապես, Tile Render-ի արդյունքը գրաֆիկական հիշողությունից գլխավոր հիշողություն հետ պահելը կոչվում է GMEM Store։ Այս գործողությունը նույնպես թանկ է GPU-ի համար։ Դրանից խուսափելու համար խորհուրդ ենք տալիս կապել միայն անհրաժեշտ Render Target-ները՝ ավելորդ Store գործողություններից խուսափելու համար։
5.4 Կոմպոզիցիայի շերտ (բազմաշերտ)
Բազմաշերտ տեխնոլոգիայի միջոցով ցուցադրվող հյուսվածքները ունեն ավելի լավ տեսողական որակ։ Այնուամենայնիվ, այս գործառույթը զգալիորեն բարձրացնում է GPU-ի աշխատանքը՝ շերտերի քանակի և հյուսվածքների չափի հետ մեկտեղ։ Մենք խորհուրդ չենք տալիս օգտագործել երեքից ավելի շերտ։
- Native մշակողի համար՝
VIVE Wave SDK-ն օգտագործում է WVR_SubmitFrameLayers-ը՝ յուրաքանչյուր շերտի համար տվյալներ փոխանցելու համար։
VIVE OpenXR SDK-ն շերտերի տվյալները տեղադրում է XrFrameEndInfo-ում և ուղարկում այն xrEndFrame-ի միջոցով։ - Unity մշակողի համար,
o VIVE Wave SDK կարգավորումներ, տե՛ս այս ուղեցույցը,
o VIVE OpenXR կարգավորումներ, տե՛ս այս ուղեցույցը։ - Unreal մշակողի համար,
o VIVE Wave SDK կարգավորումներ, տե՛ս այս ուղեցույցը։
o VIVE OpenXR կարգավորումներ, տե՛ս այս ուղեցույցը։
5.5 CPU-ի արագացում
Երբ CPU-ի ծանրաբեռնվածությունն ավելի մեծ է, որոշ ֆոնային պրոցեսներ բարձր առաջնահերթություն ունեցող թելերով կարող են ընդհատել բնօրինակ կատարումը։ Մենք չենք կարող երաշխավորել, որ Content Application-ը չի ընդհատվի այլ թելերով։
Եթե նման խնդիրներ առաջանան, կարող եք փորձել ավելացնելasing-ն սահմանում է թելերի առաջնահերթությունը՝ տեսնելու համար, թե արդյոք դա լուծում է խնդիրը։ Սակայն, եթե դուք փոխում եք թելերի կոնֆիգուրացիան՝ սարքերի համար օպտիմալացնելու համար, ապա պետք է ստուգեք, թե արդյոք դա որևէ բացասական ազդեցություն ունի։
- Unity Developer-ի համար դիմեք Android-ի թելերի կարգավորման գործառույթին: Եթե օգտագործում եք VIVE Wave SDK-ն, WaveXRSettings-ում մենք ունենք գործառույթ, որը թույլ է տալիս կարգավորել առաջնահերթությունը, ինչպես ցույց է տրված նկար 5-5-2-ում: Ավելի փոքր արժեքը ցույց է տալիս ավելի բարձր առաջնահերթություն:
- Անիրական է խաղի թելը, թելը մատուցելու և RHI թելերի առաջնահերթությունը արտաքին կարգավորումների միջոցով փոխելու ոչ մի մեթոդ, եթե չփոփոխեք շարժիչի կոդը։
Հեղինակային իրավունք © 2024 HTC Corporation: Բոլոր իրավունքները պաշտպանված են
Փաստաթղթեր / ռեսուրսներ
 | VR մատուցման կատարում |
Հղումներ
- Օգտագործողի ձեռնարկmanual.tools