VR რენდერის შესრულება
ტიუნინგი და ოპტიმიზაცია

შესავალი

რესურსებით შეზღუდულ აპარატურაზე ოპტიმალური VR გამოცდილების მიღწევა მომხმარებლისთვის გლუვი და კომფორტული გამოცდილების უზრუნველყოფის გასაღებია. თუ კონტენტის რენდერინგის კადრების სიხშირე მოწყობილობის განახლების სიხშირეზე დაბლა დაეცემა ან არასტაბილური გახდება, ეს გამოიწვევს კადრების რხევას და შეფერხებას, მოძრაობის დროს გულისრევას და ა.შ., რაც საბოლოოდ უარყოფითად იმოქმედებს მომხმარებლის გამოცდილებაზე. ამიტომ, კონტენტის მუშაობის ოპტიმიზაცია ძალიან მნიშვნელოვანია სასიამოვნო გამოცდილების უზრუნველსაყოფად.
მუშაობის რეგულირების დაწყებამდე მნიშვნელოვანია გვესმოდეს, სად არის მუშაობის შემაფერხებელი ფაქტორები, რათა თავიდან იქნას აცილებული არაეფექტური რეგულირება. ეს დოკუმენტი შექმნილია იმისთვის, რომ დაეხმაროს დეველოპერებს მუშაობის შემაფერხებელი ფაქტორების იდენტიფიცირებაში და შესთავაზოს გადაწყვეტილებები რენდერინგის მუშაობის პრობლემების გადასაჭრელად.
დოკუმენტი ორგანიზებულია შემდეგ სექციებად:

• თავი 2: შეფერხების იდენტიფიცირება – ეს ნაწილი ეხმარება დეველოპერებს შეფერხებების იდენტიფიცირებაში.
• თავები 3 და 4: VIVE Wave-ის და VIVE OpenXR-ის პარამეტრები – ეს სექციები ასახავს კონკრეტულ პარამეტრებს, რომლებმაც შეიძლება გავლენა მოახდინონ VIVE Wave-ის და OpenXR აპლიკაციების CPU/GPU-ს მუშაობაზე. დეველოპერებს შეუძლიათ ექსპერიმენტი ჩაატარონ ამ ფუნქციების ჩართვაზე ან გამორთვაზე, წარმოქმნილი შესრულების შეფერხებების საფუძველზე, რათა დაადგინონ, არის თუ არა რაიმე გაუმჯობესება.
• თავი 5: ოპტიმიზაციის საერთო პრაქტიკა – ეს განყოფილება წარმოგვიდგენს ოპტიმიზაციის რამდენიმე საერთო პრაქტიკასა და გამოცდილებას.

შეფერხების ადგილის იდენტიფიცირება

როდესაც HMD მოძრაობს, თუ VR/MR აპლიკაციას აქვს კადრის რხევა ან შავი კიდეები და ა.შ., ეს, როგორც წესი, გამოწვეულია რენდერინგის ცუდი ეფექტურობით. როგორც წესი, რენდერინგის ეფექტურობის პრობლემები შეიძლება დაიყოს 2 ტიპად: პროცესორთან დაკავშირებული ან გრაფიკულ პროცესორთან დაკავშირებული. თავიდანვე ძალიან მნიშვნელოვანია იმის გაგება, თუ რომელი ტიპის კავშირია თქვენი აპლიკაციისთვის, რათა თავიდან აიცილოთ არაეფექტური რეგულირება.
ამ თავში ჩვენ გთავაზობთ მარტივ ნაბიჯებს, რომლებიც საშუალებას მოგცემთ სწრაფად ამოიცნოთ, სად არის შესრულების პრობლემები.

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-ით არის შექმნილი, FPS-ის შესამოწმებლად შეგიძლიათ გამოიყენოთ შემდეგი adb ბრძანება.
$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 მუდმივად დაბალია ეკრანის კადრების სიხშირეზე ან არასტაბილური რჩება, ეს მიუთითებს რენდერინგის მუშაობის პრობლემაზე. ამიტომ, შემდეგი ნაბიჯი არის იმის დადგენა, პრობლემა პროცესორიდან მოდის თუ გრაფიკული პროცესორიდან.
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-ს გამოყენების შესამოწმებლად.
# ლინუქსზე/უბუნტუზე
$ adb logcat | grep CPU_USAGE
# PowerShell-ზე
$ adb logcat | აირჩიეთ-სტრიქონი -ნიმუში 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-ის გარჩევადობის რეგულირება (ნაწილი 3.1.2, ნაწილი 4.1.2), რათა ნახოთ, აუმჯობესებს თუ არა ეს FPS-ს. თუ ეს რეგულირება უკეთეს შედეგს გამოიღებს
მუშაობის მხრივ, შეგვიძლია დავასკვნათ, რომ პრობლემა გრაფიკულ პროცესორს უკავშირდება და ჩვენი ოპტიმიზაციის ძალისხმევა შესაბამისად უნდა გავამახვილოთ.
მეორე მხრივ, თუ Eyebuffer-ის რეზოლუციის რეგულირება არ იწვევს მუშაობის შესამჩნევ გაუმჯობესებას, პრობლემა, სავარაუდოდ, პროცესორთანაა დაკავშირებული და ჩვენ უნდა გავამახვილოთ ყურადღება პროცესორის მუშაობის ოპტიმიზაციაზე.
ასევე შესაძლებელია, რომ აპლიკაცია ერთდროულად იყოს დაკავშირებული როგორც CPU-სთან, ასევე GPU-სთან. ასეთ შემთხვევებში, დაბალანსებული მუშაობის გაუმჯობესების მისაღწევად, ოპტიმიზაციის ძალისხმევა უნდა იქნას გამოყენებული როგორც CPU-ზე, ასევე GPU-ზე.
2.3 GPU-სთან დაკავშირებული
როდესაც VR აპლიკაცია GPU-სთანაა დაკავშირებული, ეს ნიშნავს, რომ GPU ძირითადი შემაფერხებელი ფაქტორია და მას არ შეუძლია აპლიკაციის რენდერინგის მოთხოვნების დაკმაყოფილება. GPU-სთან დაკავშირებული პრობლემების შესამცირებლად, გაითვალისწინეთ შემდეგი რეკომენდაციები:
პირველ რიგში, გამოიყენეთ პროფილირების ინსტრუმენტები, როგორიცაა RenderDoc ან Game Engine profiler (Unity Pro)filer, Unreal Insights) იმის გასაანალიზებლად, თუ სად ატარებს გრაფიკული პროცესორი დროის უმეტეს ნაწილს. გამოავლინეთ ყველაზე ძვირადღირებული ოპერაციები და ფოკუსირდით მათ ოპტიმიზაციაზე.
Native Developer-ის შემთხვევაში, RenderDoc-ის გამოყენებით შეგიძლიათ დაადგინოთ, თუ რომელი draw გამოძახება იწვევს GPU-ს ზედმეტ დატვირთვას.
Unity-ის დეველოპერებისთვის, შეგიძლიათ მიჰყვეთ Unity-ის ამ დოკუმენტს ან გამოიყენოთ RenderDoc რენდერინგის შესრულების პრობლემის გასაანალიზებლად და მიჰყევით Unity-ის გრაფიკული ოპტიმიზაციის დოკუმენტაციას თქვენი აპლიკაციის ოპტიმიზაციის ინსტრუქციისთვის.
Unreal Developer-ისთვის, შეგიძლიათ გამოიყენოთ GPU Visualizer ან RenderDoc რენდერინგის მუშაობის პრობლემის გასაანალიზებლად და მიჰყევით Unreal Performance Guidelines-ს თქვენი აპლიკაციის ოპტიმიზაციისთვის.
მეორეც, ასევე შეგიძლიათ სცადოთ Wave-ის გარკვეული ფუნქციების ან პარამეტრების კორექტირება GPU-ს დატვირთვის შესამცირებლად.

1. ეკრანის განახლების სიხშირის შენელება (ნაწილი 3.1.1, ნაწილი 4.1.1)
2.  თვალის ბუფერის გარჩევადობის რეგულირება (ნაწილი 3.1.2, ნაწილი 4.1.2), 14.1.1)
3.  სცადეთ Foveation-ის ჩართვა (ნაწილი 3.1.4, ნაწილი 4.1.4).

თუ თქვენი აპლიკაცია ასევე MR აპლიკაციაა, შეგიძლიათ Passthrough პარამეტრების კორექტირებაც.

1. შეამცირეთ გამჭოლი სურათის ხარისხი. (ნაწილი 3.2.1)
2. შეცვალეთ Passthrough კადრების სიხშირე უფრო დაბალია. (ნაწილი 3.2.2).

GPU-ს მუშაობის შესახებ სხვა პარამეტრებისთვის შეგიძლიათ იხილოთ თავი 2.6.

2.4 პროცესორთან დაკავშირებული
როდესაც VR აპლიკაცია პროცესორთანაა დაკავშირებული, ეს ნიშნავს, რომ პროცესორი ძირითადი შეფერხების ზონია, გაითვალისწინეთ შემდეგი რეკომენდაციები:
პირველ რიგში, გამოიყენეთ პროფილირების ინსტრუმენტები, როგორიცაა Systrace ან Game Engine profiler (Unity Pro)filer, Unreal Insights) თქვენი კოდის იმ ნაწილების გასაანალიზებლად და დასადგენად, რომლებიც ყველაზე მეტ CPU რესურსს მოიხმარენ. ფოკუსირება მოახდინეთ ამ სფეროების ოპტიმიზაციაზე და გადაამუშავეთ გამოთვლითი ინტენსივობის მქონე ალგორითმები CPU-ს დატვირთვის შესამცირებლად.

• Native Developer-ისთვის, შეგიძლიათ გამოიყენოთ Systrace პროფესიონალურად გამოსაყენებლად.fileთქვენი პროექტი.
• Unity Developer-ისთვის შეგიძლიათ გამოიყენოთ CPU Usage Profiler მოდული CPU-ს მუშაობის პრობლემის მოსაძებნად.
• Unreal-ის დეველოპერებისთვის, შეგიძლიათ გამოიყენოთ Unreal-ის Insights პროცესორის მუშაობის პრობლემის მოსაძებნად.

მეორეც, ასევე შეგიძლიათ სცადოთ Wave-ის გარკვეული ფუნქციების ან პარამეტრების კორექტირება GPU-ს დატვირთვის შესამცირებლად.

1. ეკრანის განახლების სიხშირის შენელება (ნაწილი 3.1.1, ნაწილი 4.1.1)
2.  გამოიყენეთ მრავალჯერადიView რენდერინგი (ნაწილი 3.1.4, ნაწილი 4.1.4)

თუ თქვენი აპლიკაცია ასევე MR აპლიკაციაა, შეგიძლიათ Passthrough პარამეტრების კორექტირებაც.

1. შეცვალეთ Passthrough კადრების სიხშირე უფრო დაბალია (ნაწილი 3.2.2).

პროცესორის მუშაობის შესახებ დამატებითი პარამეტრებისთვის, შეგიძლიათ იხილოთ თავი 2.6.

2.5 რეზიუმე
და ბოლოს, ზემოთ მოცემული შესრულების შემოწმების სამუშაო პროცესი 2-5-1 ნახაზზე დავაჯგუფეთ. დაიწყეთ კონტენტის FPS-ის შემოწმებით. თუ ის ეკრანის კადრების სიხშირეზე დაბალია ან არასტაბილური რჩება, გააანალიზეთ GPU/CPU-ს გამოყენება, რათა დაადგინოთ, GPU-სთანაა დაკავშირებული თუ CPU-სთან. და ბოლოს, გამოიყენეთ პროფესიონალი.filer პოტენციური შესრულების პრობლემების დასადგენად ან Wave-ის ფუნქციების ან პარამეტრების შესაცვლელად CPU-ს მუშაობის ოპტიმიზაციის მიზნით.

2.6 მოკლე ცნობარი, თუ რომელ პარამეტრებს შეუძლია პროცესორის/გრაფიკული პროცესორის ჩატვირთვის გაუმჯობესება

ქვემოთ ჩამოთვლილია SDK-ის პარამეტრები, რომლებიც დაკავშირებულია CPU/GPU-ს ჩატვირთვასთან. შეგიძლიათ აპლიკაციის შეფერხების საფუძველზე შეამოწმოთ შესაბამისი ოპტიმიზაციის პარამეტრები.

პროცესორთან დაკავშირებული:

• 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-ს პიკი

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 რენდერის ნიღაბი [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 ფოვეაცია [Unreal-ის მხარდაჭერა არ აქვს] ▪ 4.1.5 რენდერის ნიღაბი [Unreal-ის მხარდაჭერა არ აქვს]
• საერთო ოპტიმიზაცია
  o 5.1 მაღალი ხარისხის რეჟიმის გამორთვა
  o 5.2 მულტიampling
  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 ეკრანის განახლების სიხშირე

უფრო მაღალი განახლების სიხშირე უფრო გლუვ ვიზუალურ სურათს გვთავაზობს, თუმცა სისტემის დატვირთვის ზრდასთან ერთად ხდება. პირიქით, უფრო დაბალი განახლების სიხშირე ამცირებს სისტემის დატვირთვას, მაგრამ ვიზუალურ სურათს ნაკლებად გლუვს ხდის. თუ აპლიკაციას პროცესორთან/გრაფიკულ პროცესორთან დაკავშირებული პრობლემა აქვს, პრობლემის შესამსუბუქებლად შეგიძლიათ სცადოთ ეკრანის განახლების სიხშირის შემცირება.

• მშობლიური დეველოპერისთვის იხილეთ WVR_SetFrameRate.
• Unity-ის დეველოპერებისთვის იხილეთ ეს სახელმძღვანელო.
• Unreal-ის დეველოპერებისთვის იხილეთ ეს სახელმძღვანელო.

3.1.2 თვალის ბუფერის გარჩევადობა
Eyebuffer-ის გადაწყვეტა არის ტექსტურის ზომა, რომლის რენდერირებაც უნდა მოხდეს აპლიკაციის კონტენტში. რენდერირებული ტექსტურა გაიგზავნება გაშვების დროს გამოქვეყნების პროცესის განსახორციელებლად და HMD ეკრანზე წარმოსადგენად.
მიუხედავად იმისა, რომ თვალის ბუფერის უფრო დიდ ზომას შეუძლია უფრო მკაფიო და დეტალური ვიზუალის მიღება, ის ასევე მნიშვნელოვან დატვირთვას ახდენს გრაფიკულ პროცესორზე. ამიტომ, აუცილებელია ვიზუალური ხარისხისა და მუშაობის უნარის სწორი ბალანსის პოვნა.
თუ აპლიკაციას GPU-სთან დაკავშირებული პრობლემა აქვს, შეგიძლიათ სცადოთ eyebuffer-ის ზომის შემცირება მასშტაბის კოეფიციენტის გამრავლებით. თუმცა, გირჩევთ, მასშტაბის კოეფიციენტი 0.7-ზე ქვემოთ არ შეამციროთ, რადგან ამან შეიძლება მიუღებელი ვიზუალური ხარისხი გამოიწვიოს.

• ნატიური დეველოპერისთვის იხილეთ WVR_ObtainTextureQueue. ზომის რეგულირებისას, სიგანე და სიმაღლე უნდა გაამრავლოთ თანაფარდობაზე.
• Unity-ის დეველოპერისთვის იხილეთ WaveXRSettings.
  ალტერნატიულად, შეგიძლიათ ცვლილებები შეიტანოთ კოდის საშუალებით, როგორც belwoe.
  XRSettings.eyeTextureResolutionScale = ResolutionScaleValue; // C#
• Unreal-ის დეველოპერისთვის იხილეთ SetPixelDensity.

3.1.3 მრავალ-View რენდერირება
ტრადიციული რენდერინგის დროს მარცხენა და მარჯვენა თვალებს ცალ-ცალკე ვხატავთ, რაც ერთი და იგივე სცენისთვის ორ ხატვის ზარს მოითხოვს.View რენდერინგი ამ პრობლემას მხოლოდ ერთი draw გამოძახების შესრულებით აგვარებს.
ეს ფუნქცია ამცირებს პროცესორის დატვირთვას ხატვის გამოძახებების რაოდენობის შემცირებით. გრაფიკულ პროცესორსაც აქვს გარკვეული უპირატესობები, ვერტექს შეიდერის სამუშაო დატვირთვაც მცირდება, რადგან მას არ სჭირდება დამატებითი შეიდერის გაშვება მეორე თვალისთვის, მაგრამ ფრაგმენტის შეიდერის სამუშაო დატვირთვა უცვლელი რჩება, რადგან მას კვლავ სჭირდება ორივე თვალისთვის თითოეული პიქსელის შეფასება. ჩვენ გირჩევთ ამ ფუნქციის ჩართვას.

• ნატიური დეველოპერისთვის შეგიძლიათ იხილოთ wvr_native_hellovr s.ampლე.
• Unity-ის დეველოპერისთვის იხილეთ Render Mode, ერთი გავლა მრავალჯერადია.view თვისება.
• Unreal-ის დეველოპერებისთვის იხილეთ ეს სახელმძღვანელო.

3.1.4 ფოვეაცია
გადახრილი რენდერინგი ძირითადად შექმნილია GPU-ს დატვირთვის შესამცირებლად. ის ამცირებს კადრის დეტალებს ეკრანის პერიფერიულ ნაწილში და ინარჩუნებს მაღალი გარჩევადობის დეტალებს ეკრანის ველის ცენტრში. viewთუ აპლიკაციას GPU-სთან დაკავშირებული პრობლემა აქვს, შეგიძლიათ სცადოთ Foveation-ის რენდერინგის გააქტიურება.

ფოვეაციის გამოყენებისას ყურადღება უნდა მიაქციოთ რამდენიმე ფაქტორს:

➢ მომხმარებლები, როგორც წესი, ვერ ამჩნევენ პერიფერიულ რეგიონებში დეტალების შემცირებას ნაგულისხმევი ფოვეაციის რეჟიმის გამოყენებისას. თუმცა, თუ ფოვეაციის პერიფერიული ხარისხი ძალიან დაბალ დონეზეა დაყენებული, ის შეიძლება მომხმარებლისთვის შესამჩნევი გახდეს.
➢ ფოვეაციის ეფექტები შეიძლება უფრო შესამჩნევი იყოს გარკვეული ტექსტურების მქონე მასალების შემთხვევაში, რამაც შეიძლება მომხმარებლის ყურადღება მიიპყროს. დეველოპერებმა უნდა იცოდნენ ამის შესახებ და შესაბამისად შეაფასონ.
➢ ფოვეტირებული რენდერინგის ფუნქციის ჩართვა იწვევს GPU-ს ფიქსირებულ ხარჯებს, რომელიც შეიძლება მერყეობდეს 1%-დან 6%-მდე, თვალის ბუფერის ზომის მიხედვით. სცენაში მარტივი შადერის გამოყენებისას, რესურსების დაზოგვით მიღებული მოგება შეიძლება უფრო დაბალი იყოს, ვიდრე GPU-ს ფიქსირებული ხარჯი, რაც გამოიწვევს შესრულების შემცირებას.

• ნატიური დეველოპერისთვის იხილეთ ეს სახელმძღვანელო.
• Unity-ის დეველოპერებისთვის იხილეთ ეს სახელმძღვანელო. აღსანიშნავია, რომ როდესაც ჩართავთ პოსტ-დამუშავებას ან HDR-ს, ფოვეაციის სრულად გამოყენება შეუძლებელია. რადგან Unity ობიექტებს რენდერინგს გაუკეთებს საკუთარ გენერირებულ რენდერ ტექსტურაზე და არა გაშვების დროს გენერირებულ პრეზენტაციის რენდერ ტექსტურაზე, რომელიც მხარს უჭერს ფოვეაციას.
• Unreal-ის დეველოპერებისთვის იხილეთ ეს სახელმძღვანელო. აღსანიშნავია, რომ foveation-ის სრულად გამოყენება Multi-ზე შეუძლებელია.View რენდერინგი, რადგან Unreal-ს არ შეუძლია ობიექტების პირდაპირ რენდერირება გაშვების დროს გენერირებულ რენდერის ტექსტურაზე, რომელიც მხარს უჭერს ფოვეაციას.

3.1.5 კადრის სიმკვეთრის გაუმჯობესება (FSE)
FSE, რომელიც სიმკვეთრის ფილტრის შემოღებით უზრუნველყოფს რენდერინგის შედეგს, შეუძლია კონტენტი უფრო მკაფიო გახადოს და საკმაოდ სასარგებლო იყოს სცენაში ტექსტის სიცხადის გასაუმჯობესებლად. თუ აპლიკაციას GPU-სთან დაკავშირებული პრობლემა აქვს, შეგიძლიათ განიხილოთ FSE-ს გამორთვა, თუ ეს აუცილებელი არ არის.

• ნატიური დეველოპერისთვის იხილეთ ეს სახელმძღვანელო.
• Unity-ის დეველოპერებისთვის იხილეთ ეს სახელმძღვანელო.
• Unreal-ის დეველოპერებისთვის იხილეთ ეს სახელმძღვანელო.

3.1.6 ადაპტური ხარისხი
ბატარეის დაზოგვისა და მოწყობილობის რენდერინგის მუშაობის შესანარჩუნებლად, ეს ფუნქცია ავტომატურად არეგულირებს CPU/GPU საათის მუშაობის დონეებს მათი გამოყენების მიხედვით. გარდა ამისა, მუშაობის გასაუმჯობესებლად შესაძლებელია სხვა სტრატეგიების დანერგვა, როგორიცაა Foveation-ის ავტომატური ჩართვა/გამორთვა ან კონტენტის თვითრეგულირება მაღალი/დაბალი დატვირთვის მოვლენების მიღების შემთხვევაში.

• ნატიური დეველოპერისთვის იხილეთ ეს სახელმძღვანელო.
• Unity-ის დეველოპერებისთვის იხილეთ ეს სახელმძღვანელო. ჩვენს Unity დანამატში, თვალის ბუფერის ზომა ავტომატურად შეიძლება დარეგულირდეს მიმდინარე მუშაობის მიხედვით; ტექსტის ზომა გაფილტრავს მასშტაბის მნიშვნელობებს, რომლებიც ძალიან მცირეა გარჩევადობის სიაში. ჩვენ გირჩევთ ტექსტს, რომლის ზომაა მინიმუმ 20 dmm ან მეტი.
• Unreal-ის დეველოპერებისთვის იხილეთ ეს სახელმძღვანელო.

3.1.7 ადაპტური მოძრაობის კომპოზიტორი
ეს ფუნქცია ექსპერიმენტულია და მოიცავს UMC-სა და PMC-ს. UMC ორჯერ შეამცირებს კადრების სიხშირეს და რეალურ დროში ექსტრაპოლაციას გაუკეთებს ახალ კადრებს ვიზუალური სიგლუვის შესანარჩუნებლად. თუმცა, მას თან ახლავს გარკვეული შეყოვნება, არტეფაქტები და GPU დატვირთვა.
PMC ძირითადად იყენებს სიღრმის ბუფერს, რათა ATW-მ გაითვალისწინოს HMD თარგმანი, რომელიც 6-დოფის კომპენსაციამდე ვრცელდება. ამ ფუნქციას შეუძლია თარგმანის შეყოვნების შემცირება 1~2 კადრით, მაგრამ გაზარდოს GPU-ს დატვირთვა.

• ნატიური დეველოპერისთვის იხილეთ ეს სახელმძღვანელო.
• Unity-ის დეველოპერებისთვის იხილეთ ეს სახელმძღვანელო.
• Unreal-ის დეველოპერებისთვის იხილეთ ეს სახელმძღვანელო.

3.1.8 რენდერის ნიღაბი [Unreal-ს მხარდაჭერა არ აქვს]
კიდეებზე არსებული პიქსელები დამახინჯების შემდეგ თითქმის უხილავი ხდება, რენდერის ნიღაბი ცვლის ამ უხილავი პიქსელების სიღრმის ბუფერის მნიშვნელობებს. თუ ჩართავთ სიღრმის ტესტირებას, early-z-ის გამო, ეს უხილავი პიქსელები არ იქნება რენდერირებული, რითაც შემცირდება GPU-ს დატვირთვა. ეს ფუნქცია სასარგებლოა, თუ ამ უხილავ ადგილებში არის დიდი რაოდენობით რენდერის ობიექტები; წინააღმდეგ შემთხვევაში, თუ ამ ადგილებში არ არის რენდერის ობიექტები, რეკომენდებულია მისი გამორთვა, რადგან ის მცირე რაოდენობით GPU-ს მოიხმარს.

• ნატიური დეველოპერებისთვის იხილეთ ეს სახელმძღვანელო. RenderMask-ის გამოძახებამდე აუცილებელია სიღრმის ბუფერის შებოჭვა; წინააღმდეგ შემთხვევაში, ის არაეფექტური იქნება.
• Unity-ის დეველოპერებისთვის იხილეთ ეს სახელმძღვანელო.
• Unreal-ის დეველოპერებისთვის, ამჟამად არ არის მხარდაჭერილი Render Mask ფუნქცია.

3.2 MR შინაარსი
3.2.1 გავლის ხარისხის რეგულირება
გადამცემი გამოსახულების ხარისხის 3 დონე არსებობს:
➢ WVR_PassthroughImageQuality_DefaultMode – შესაფერისია MR კონტენტისთვის კონკრეტული მოთხოვნის გარეშე.
➢ WVR_PassthroughImageQuality_PerformanceMode – შესაფერისია MR კონტენტისთვის, რომელსაც ვირტუალური სცენის რენდერინგისთვის მეტი GPU რესურსი სჭირდება.
➢ WVR_PassthroughImageQuality_QualityMode – შესაფერისია MR კონტენტისთვის, რომელიც მომხმარებლებს საშუალებას აძლევს ნათლად დაინახონ გარემო, მაგრამ კონტენტის ვირტუალურ სცენას უფრო დახვეწილი რეგულირება სჭირდება შესრულებისთვის.
GPU-ს გამოყენების შესამცირებლად, შეგიძლიათ Passthrough quality დააყენოთ PerformanceMode-ზე.

• Native, Uunity ან Unreal დეველოპერებისთვის იხილეთ ეს სახელმძღვანელო.

3.2.2 გავლის კადრების სიხშირის რეგულირება
ეკრანის განახლების სიხშირის მსგავსად, უფრო მაღალი გავლის კადრების სიხშირე უფრო გლუვ ვიზუალურ ეფექტს გვთავაზობს, თუმცა სისტემის დატვირთვის ზრდას იწვევს. პირიქით, უფრო დაბალი განახლების სიხშირე ამცირებს სისტემის დატვირთვას, მაგრამ ვიზუალურ ეფექტს ნაკლებად გლუვს ხდის. გავლის კადრების სიხშირის 2 რეჟიმი არსებობს: Boost და Normal.

• მშობლიური დეველოპერებისთვის, გავლის ხარისხის რეგულირება შესაძლებელია WVR_SetPasthroughImageRate-ის გამოყენებით.
• Unity-ის დეველოპერისთვის, შეცვლა შესაძლებელია კოდის საშუალებით, მაგ.ampპარამეტრები შემდეგია // C#
  Interop.WVR_SetPasthroughImageQuality(WVR_PasthroughImageQuality.PerformanceMode);
• Unreal-ის დეველოპერის დაყენების მეთოდისთვის იხილეთ ნახაზის 3-2-2 ბლუთრუ კვანძი.

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 ეკრანის განახლების სიხშირის მსგავსია.

• მშობლიური დეველოპერისთვის იხილეთ XrEventDataDisplayRefreshRateChangedFB.
• Unity-ის დეველოპერებისთვის იხილეთ ეს სახელმძღვანელო.
• Unreal-ის დეველოპერებისთვის იხილეთ ეს სახელმძღვანელო.

4.1.2 თვალის ბუფერის გარჩევადობა
აქ კონცეფცია 3.1.2 Eyebuffer Resolution-ის მსგავსია. ჩვენ გირჩევთ, რომ მასშტაბის კოეფიციენტი 0.7-ზე ქვემოთ არ შეამციროთ, რადგან ამან შეიძლება მიუღებელი ვიზუალური ხარისხი გამოიწვიოს.

• ნატიური დეველოპერისთვის იხილეთ xrCreateSwapchain. ზომის რეგულირებისას, სიგანე და სიმაღლე უნდა გაამრავლოთ თანაფარდობაზე.
• Unity-ის დეველოპერისთვის იხილეთ შემდეგი მაგალითიample // C#
  XRSettings.eyeTextureResolutionScale = 0.7f; //რეკომენდებულია 1.0f~0.7f
• არარეალური პარამეტრებისთვის იხილეთ ეს სახელმძღვანელო.

4.1.3 მრავალ-View რენდერირება
აქ კონცეფცია 3.1.3 მრავალმხრივი კონცეფციის მსგავსია.View რენდერინგი. ეს ფუნქცია ამცირებს დატვირთვას პროცესორზე, გრაფიკულ პროცესორსაც აქვს გარკვეული უპირატესობები. გირჩევთ, ჩართოთ ეს ფუნქცია.

• მშობლიური დეველოპერებისთვის, KhronosGroup გთავაზობთ OpenXR Multi-View exampლე, იხილეთ ეს სახელმძღვანელო.
• Unity-ის დეველოპერისთვის იხილეთ Render Mode, ერთი გავლა მრავალჯერადია.view თვისება.
• Unreal-ის დეველოპერის პარამეტრებისთვის, ისევე როგორც VIVE Wave-ის შემთხვევაში, იხილეთ ეს სახელმძღვანელო.

4.1.4 ფოვეაცია [არ უჭერს მხარს Unreal-ს]
აქ კონცეფცია 3.1.4 Foveation-ის მსგავსია. Foveated რენდერინგი ძირითადად შექმნილია GPU-ს დატვირთვის შესამცირებლად, მაგრამ მისი ჩართვა გამოიწვევს GPU-ს მუშაობის ფიქსირებულ ხარჯებს და თუ foveation ძალიან დაბალ დონეზეა დაყენებული და გამოყენებულია გარკვეული მასალები ან ტექსტურები, ის შეიძლება ძალიან...
მომხმარებლისთვის შესამჩნევი. ამიტომ, სასურველია ფუნქციის ჩართვა ან გამორთვა თქვენი კონკრეტული მოთხოვნებისა და შესრულების მოსაზრებების საფუძველზე. ამჟამად, Foveated ფუნქციონალი მხარდაჭერილია მხოლოდ OpenGL ES-ში VIVE OpenXR SDK-ზე.

• მშობლიური დეველოპერისთვის ეს ფუნქცია ხელმისაწვდომია, მაგრამ ამჟამად არ არის.ampარის გათვალისწინებული.
• Unity-ის დეველოპერებისთვის იხილეთ ეს სახელმძღვანელო.
• Unreal-ის დეველოპერებისთვის, ამ ფუნქციას ამჟამად არ უჭერს მხარს.

4.1.5 რენდერის ნიღაბი [Unreal-ს მხარდაჭერა არ აქვს]
აქ კონცეფცია 3.1.8 Render Mask-ის მსგავსია.

• ნატიური დეველოპერებისთვის, Mesh-ის მისაღებად გამოიყენეთ XrVisibilityMaskKHR. სცენის რენდერირებამდე, გამოიყენეთ ეს Mesh სიღრმის ბუფერის მნიშვნელობების შესავსებად სცენის რენდერირებამდე.
• Unity-ის დეველოპერებისთვის, Render Mask ფუნქცია OpenGL ES-ისთვის ნაგულისხმევად ჩართულია და მისი გამორთვა შესაძლებელია შემდეგი კოდით; Vulkan ამჟამად არ უჭერს მხარს ამ ფუნქციას. //C# UnityEngine.XR.XRSettings.occlusionMaskScale = 0.0f;
• Unreal-ის დეველოპერებისთვის, ამჟამად არ არის მხარდაჭერილი Render Mask ფუნქცია.

4.2 MR შინაარსი
OpenXR ამჟამად არ უჭერს მხარს გავლის ხარისხისა და კადრების სიხშირის დაყენებას. ჩვენ გავაგრძელებთ გავლის ფუნქციის ოპტიმიზაციას და გამოსწორებას, ამიტომ რეკომენდებულია, რომ დეველოპერებმა განაახლონ მოწყობილობის FOTA ვერსია, რათა ის განახლებული იყოს.

საერთო ოპტიმიზაცია

5.1 მაღალი ხარისხის რეჟიმის გამორთვა
„მაღალი ხარისხის რეჟიმის“ გამორთვით შესაძლებელია მოწყობილობის ეკრანის ზომის შემცირება, რითაც მცირდება გრაფიკული პროცესორის გამოყენება. ნაკლი ეკრანის გარჩევადობის შემცირებაა. მისი ჩართვის ან ჩართვისთვის შეგიძლიათ ხარისხისა და შესრულების დაბალანსება.
VIVE Focus 3-ის დაყენების ადგილმდებარეობა ნაჩვენებია სურათ 5-1-1-ზე:

VIVE XR Elite-ის დაყენების ადგილმდებარეობა ნაჩვენებია სურათ 5-1-2-ზე:

5.2 მულტიampლინგის ანტი-ალიასინგი
მულტიampling არის ანტი-ალიასინგის ტექნიკა, რომელიც გამოიყენება დაკბილული კიდეების გასასწორებლად და, როგორც წესი, აჩქარებულია აპარატურით, რაც იწვევს გრაფიკული პროცესორის მუშაობის ხარჯებს. ჩვენ გირჩევთ, არ დააყენოთ MSAA 2-ზე მეტი, რადგან სიმაღლის უფრო მაღალი მნიშვნელობა გამოიწვევს გრაფიკული პროცესორის მეტ გამოყენებას.

• მშობლიური დეველოპერისთვის, MSAA OpenGL ES exsample შეიძლება მიმართოს ამას; MSAA Vulkan ყოფილიampლერს შეუძლია ამაზე მიუთითოს.
  Adreno GPU გთავაზობთ გაფართოებას, რომელიც ოპტიმიზაციას უკეთებს MSAA-ს.
• Unity-ის დეველოპერებისთვის იხილეთ ეს გილდია.
• Unreal-ის დეველოპერებისთვის იხილეთ ეს გილდია. Unreal-ს ასევე აქვს პოსტ-დამუშავების ანტი-ალიასინგი, იხილეთ ეს გილდია.

5.3 GMEM-ის ჩატვირთვა/შენახვა
Adreno GPU არქიტექტურაში არსებობს ფუნქცია, რომლის მიხედვითაც, რენდერის სამიზნესთან დაკავშირებისას, თუ რენდერის სამიზნე არ გაიწმინდება ან არ ფუნქციონირებს, რენდერის ყოველი განხორციელებისას რენდერის სამიზნეში არსებული მნიშვნელობები იტვირთება გრაფიკულ მეხსიერებაში, რასაც GMEM ჩატვირთვა ეწოდება. თუ წინა მნიშვნელობები არ არის საჭირო, რენდერის დაწყებამდე რენდერის სამიზნეს გასუფთავება ან არ ფუნქციონირებს, რაც ხელს შეუწყობს ამ სიტუაციის თავიდან აცილებას GPU-ს მუშაობის გაუმჯობესების მიზნით.
GMEM ჩატვირთვის თავიდან აცილება შემდეგი მეთოდების გამოყენებით შეგიძლიათ. OpenGL ES-ში, FBO-ს შეკავშირების შემდეგ, შეგიძლიათ გამოიძახოთ glClear და glClearDepth Color, Depth და Stencil ბუფერის გასასუფთავებლად, ან გამოიძახოთ glInvalidateFramebuffer მითითებული Render Target-ის გასაუქმებლად. Vulkan-ში დამატებითი ინსტრუქციები საჭირო არ არის; VkAttachmentDescription.loadOp-ში შეგიძლიათ ცალსახად დააყენოთ, წაიშალოს თუ არა დანართი გამოყენებამდე.
ანალოგიურად, Tile Render-ის შედეგის გრაფიკული მეხსიერებიდან მთავარ მეხსიერებაში შენახვას GMEM Store ეწოდება; ეს ოპერაცია ასევე ძვირია GPU-სთვის. ამის თავიდან ასაცილებლად, ჩვენ გირჩევთ, რომ მხოლოდ საჭირო Render Target-ები დააკავშიროთ, რათა თავიდან აიცილოთ არასაჭირო შენახვის ოპერაციები.

5.4 კომპოზიციის ფენა (მრავალშრიანი)
მრავალშრიანი ფუნქციით ნაჩვენებ ტექსტურებს უკეთესი ვიზუალური ხარისხი აქვთ. თუმცა, ეს ფუნქცია მნიშვნელოვნად ზრდის GPU-ს მუშაობას ფენების რაოდენობისა და ტექსტურების ზომის მიხედვით. ჩვენ არ გირჩევთ სამ ფენაზე მეტის გამოყენებას.

• მშობლიური დეველოპერისთვის,
  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-ს დატვირთვა უფრო ინტენსიურია, ზოგიერთი ფონური პროცესი მაღალი პრიორიტეტის მქონე ნაკადებს იყენებს, რამაც შეიძლება ხელი შეუშალოს მშობლიურ შესრულებას. ჩვენ არ შეგვიძლია გარანტია, რომ კონტენტ აპლიკაცია სხვა ნაკადებით არ შეწყდება.
თუ ასეთი პრობლემები წარმოიქმნება, შეგიძლიათ სცადოთ ძაფის პრიორიტეტის გაზრდა, რათა ნახოთ, მოაგვარებს თუ არა ეს პრობლემას. თუმცა, თუ ძაფის კონფიგურაციას მოწყობილობებისთვის ოპტიმიზაციისთვის შეცვლით, უნდა შეამოწმოთ, აქვს თუ არა ამას რაიმე უარყოფითი გავლენა.

• Unity Developer-ისთვის იხილეთ Android-ის ძაფების კონფიგურაციის ფუნქცია. თუ იყენებთ VIVE Wave SDK-ს, WaveXRSettings-ში გვაქვს ფუნქცია, რომელიც საშუალებას გაძლევთ დაარეგულიროთ პრიორიტეტი, როგორც ეს ნაჩვენებია ნახაზ 5-5-2-ზე. უფრო მცირე მნიშვნელობა წარმოადგენს უფრო მაღალ პრიორიტეტს.

• არარეალურია თამაშის თემის, თემის რენდერინგის და RHI თემის პრიორიტეტის შეცვლის არანაირი მეთოდი გარე პარამეტრების მეშვეობით, თუ ძრავის კოდს არ შეცვლით.

საავტორო უფლება © 2024 HTC Corporation. ყველა უფლება დაცულია

დოკუმენტები / რესურსები

VIVE VR რენდერინგის შესრულება [pdf] მომხმარებლის სახელმძღვანელო VR რენდერინგის ეფექტურობა, რენდერინგის ეფექტურობა, შესრულება

ცნობები

• მომხმარებლის სახელმძღვანელო