Производителност на VR рендиране
Настройка и оптимизация

Въведение

Постигането на оптимално VR изживяване на хардуер с ограничени ресурси е ключово за осигуряване на плавно и комфортно потребителско изживяване. Ако честотата на кадрите при рендиране на съдържанието падне или е нестабилна под честотата на опресняване на устройството, това ще доведе до трептене и заекване на кадрите, морска болест и др., което в крайна сметка ще се отрази негативно на потребителското изживяване. Следователно, оптимизирането на производителността на съдържанието е много важно за осигуряване на приятно изживяване.
Преди да започнете оптимизация на производителността, е важно да разберете къде са пречките в производителността, за да избегнете неефективна оптимизация. Този документ е предназначен да помогне на разработчиците да идентифицират пречките в производителността и да предложат решения за разрешаване на проблеми с производителността на рендирането.
Документът е организиран в следните раздели:

• Глава 2: Идентифициране на пречките – Този раздел помага на разработчиците да идентифицират къде са пречките.
• Глава 3 и 4: Настройки на VIVE Wave и VIVE OpenXR – Тези раздели очертават специфични настройки, които могат да повлияят на производителността на процесора/графичния процесор за приложенията VIVE Wave и OpenXR. Разработчиците могат да експериментират с активиране или деактивиране на тези функции въз основа на срещаните проблеми с производителността, за да определят дали има някакво подобрение.
• Глава 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, можете да използвате следната 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 present:90.00 skip:0 (0.592301, -0.015502, 0.805539, 0.006773)

Числото след „нова текстура“ представлява текущите FPS на съдържанието. Числото след „налично R“ и „налично L“ представлява честотата на кадрите на дисплея.
Понякога FPS на съдържанието и кадровата честота на дисплея може да имат леко несъответствие.
Напримерampт.е. в горния случай 89.8 FPS може да се счита за 90 FPS.
Ако FPS на съдържанието на приложението е постоянно по-нисък от кадровата честота на дисплея или остава нестабилен, това показва проблем с производителността на рендирането. Следователно, следващата стъпка е да се определи дали проблемът идва от процесора или графичния процесор.
2.2 Проверете използването на процесора и графичния процесор
Ако вашият 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
Както можете да видите в резултата от лога по-горе, използването на процесора е 27%, а използването на графичния процесор е 72%. Ако версията на вашия Wave SDK е под 6.0.0, се препоръчва да надстроите до най-новата версия, за да подобрите производителността на рендирането и други оптимизации.
За приложението VIVE OpenXR можете да използвате следната команда, за да проверите използването на процесора и графичния процесор.
# на Linux/Ubuntu
$ adb logcat | grep CPU_USAGE
# на PowerShell
$ adb logcat | Select-String -Pattern CPU_USAGE
Ще видите следния лог
Средно натоварване на процесора 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 не може да поддържа кадровата честота на дисплея и използването на графичния процесор е много високо, обикновено надвишава 85%, можете да опитате да коригирате резолюцията на Eyebuffer (раздел 3.1.2, раздел 4.1.2), за да видите дали това подобрява FPS. Ако тази корекция води до по-добро
производителност, можем да заключим, че проблемът е свързан с графичния процесор и да съсредоточим усилията си за оптимизация съответно.
От друга страна, ако коригирането на резолюцията на Eyebuffer не доведе до забележимо подобрение в производителността, проблемът вероятно е свързан с процесора и трябва да се съсредоточим върху оптимизирането на производителността на процесора.
Възможно е приложението да е едновременно обвързано с процесора и графичния процесор. В такива случаи, усилията за оптимизация трябва да се приложат както към процесора, така и към графичния процесор, за да се постигнат балансирани подобрения в производителността.
2.3 Свързано с графичния процесор
Когато едно VR приложение е обвързано с графичния процесор (GPU), това означава, че графичният процесор (GPU) е основното пречка и не е в състояние да се справи с изискванията за рендиране на приложението. За да смекчите проблемите, свързани с GPU, разгледайте следните препоръки:
Първо, използвайте инструменти за профилиране като RenderDoc или Game Engine Profiler (Unity Profiler, Unreal Insights), за да анализирате къде графичният процесор прекарва по-голямата част от времето си. Идентифицирайте най-скъпите операции и се съсредоточете върху оптимизирането им.
За Native Developer можете да използвате RenderDoc, за да идентифицирате кое извикване на draw причинява прекомерно натоварване на графичния процесор.
За разработчици на Unity, можете да следвате този документ на Unity или да използвате RenderDoc, за да анализирате проблема с производителността на рендирането, и да следвате документацията за оптимизация на графики на Unity за насоки за оптимизиране на приложението ви.
За Unreal Developer можете да използвате GPU Visualizer или RenderDoc, за да анализирате проблеми с производителността на рендирането и да следвате насоките за производителност на Unreal за насоки за оптимизиране на приложението си.
Второ, можете също да опитате да коригирате определени функции или настройки на Wave, за да намалите натоварването на графичния процесор.

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 приложение, можете да коригирате и настройките за преминаване.

1. Намалете качеството на изображението при преминаване. (раздел 3.2.1)
2. Настройте скоростта на кадрите в секунда на по-бавен режим (раздел 3.2.2).

За още настройки относно производителността на графичния процесор, можете да се обърнете към Глава 2.6.

2.4 Ограничен от процесора
Когато VR приложение е ограничено от процесора, това означава, че процесорът е основното пречка. Обмислете следните препоръки:
Първо, използвайте инструменти за профилиране като Systrace или Game Engine Profiler (Unity Profiler, Unreal Insights), за да анализирате и идентифицирате кои части от вашия код консумират най-много процесорни ресурси. Съсредоточете се върху оптимизирането на тези области и рефакторирайте изчислително интензивни алгоритми, за да намалите натоварването на процесора.

• За Native Developer можете да използвате Systrace за професионализъм.fileвашия проект.
• За Unity Developer можете да използвате CPU Usage Profiler модул за откриване на проблем с производителността на процесора.
• За Unreal Developer можете да използвате Unreal's Insights, за да откриете проблем с производителността на процесора.

Второ, можете също да опитате да коригирате определени функции или настройки на Wave, за да намалите натоварването на графичния процесор.

1. Задайте по-бавна честота на опресняване на дисплея (раздел 3.1.1, раздел 4.1.1)
2.  Използвайте мулти-View Рендиране (раздел 3.1.4, раздел 4.1.4)

Ако приложението ви е и MR приложение, можете да коригирате и настройките за преминаване.

1. Настройте Passthrough Framerate на по-бавно (раздел 3.2.2).

За повече настройки относно производителността на процесора, можете да се обърнете към Глава 2.6.

2.5 Резюме
Накрая, организирахме горния работен процес за проверка на производителността във Фигура 2-5-1. Започнете с проверка на FPS на съдържанието. Ако е по-нисък от кадровата честота на дисплея или остава нестабилен, анализирайте използването на GPU/CPU, за да определите дали е ограничено от GPU или CPU. Накрая, използвайте професионален...filer, за да идентифицирате потенциални проблеми с производителността или да коригирате функциите или настройките на Wave, за да оптимизирате производителността на процесора.

2.6 Бърз справочник Кои настройки могат да подобрят натоварването на процесора/графичния процесор

Избройте настройките на SDK, които са свързани с натоварването на процесора/графичния процесор, както е показано по-долу. Можете да проверите съответните настройки за оптимизация въз основа на пречките в приложението.

Свързано с процесора:

• Настройка на VIVE Wave SDK
  VR съдържание
  ▪ 3.1.1 Честота на опресняване на дисплея
  ▪ 3.1.4 Много-View Изобразяване
  ▪ 3.1.6 Адаптивно качество
  ▪ 3.1.7 Адаптивен композитор на движение
  o MR съдържание
  ▪ 3.2.2 Регулиране на честотата на кадрите при преминаване
• Настройка на VIVE OpenXR SDK
  VR съдържание
  ▪ 4.1.1 Честота на опресняване на дисплея
  ▪ 4.1.4 Много-View Изобразяване
• Обща оптимизация
  5.5 пик на процесора

Свързано с графичния процесор:

• Настройка на VIVE Wave SDK
  VR съдържание
  ▪ 3.1.1 Честота на опресняване на дисплея
  ▪ 3.1.2 Разделителна способност на eyebuffer
  ▪ 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
  VR съдържание
  ▪ 4.1.1 Честота на опресняване на дисплея
  ▪ 4.1.2 Разделителна способност на eyebuffer
  ▪ 4.1.3 Много-View Изобразяване
  ▪ 4.1.4 Фовеация [Не поддържа Unreal] ▪ 4.1.5 Маска за рендериране [Не поддържа Unreal]
• Обща оптимизация
  o 5.1 Изключване на режима за висока производителност
  o 5.2 Мултиampлинг
  o 5.3 Зареждане/съхранение на GMEM
  o 5.4 Композиционен слой (многослоен)

Настройка на VIVE Wave

VIVE Wave е отворена платформа и набор от инструменти, които ви позволяват лесно да разработвате VR съдържание и осигуряват високопроизводителна оптимизация на устройства за трети страни. VIVE Wave поддържа игровите енджинове Unity и Unreal.
Ние непрекъснато оптимизираме и отстраняваме различни грешки, затова препоръчваме да поддържате SDK актуален.
В момента VIVE Wave поддържа само OpenGL ES. Тук са изброени функциите, подредени по влияние върху производителността на графичния процесор. Ще ги разделим на две части: VR съдържание и MR съдържание.
3.1 VR съдържание
3.1.1 Честота на опресняване на дисплея

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.

• За Native разработчик, вижте WVR_SetFrameRate.
• За разработчици на Unity, вижте това ръководство.
• За разработчици на Unreal вижте това ръководство.

3.1.2 Разделителна способност на очната мъгла
Разделителната способност на eyebuffer е размерът на текстурата, с която съдържанието на приложението ще се рендира. Рендираната текстура ще бъде изпратена към средата за изпълнение, за да се извърши процес на публикуване и да се представи на дисплея на HMD.
Макар че по-големият размер на буфера за очи може да доведе до по-ясни и по-детайлни визуализации, той също така натоварва значително графичния процесор. Следователно, намирането на правилния баланс между визуално качество и производителност е от съществено значение.
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.

• За Native разработчик, вижте WVR_ObtainTextureQueue. Когато коригирате размера, трябва да умножите ширината и височината по съотношение.
• За разработчици на Unity, вижте WaveXRSettings.
  Като алтернатива, можете да направите промени чрез код, както е показано по-долу.
  XRSettings.eyeTextureResolutionScale = ResolutionScaleValue; // C#
• За разработчик на Unreal вижте SetPixelDensity.

3.1.3 Мулти-View Изобразяване
При традиционното рендиране рисуваме лявото и дясното око отделно, което изисква две извиквания на draw за една и съща сцена.View Рендирането решава този проблем, като извършва само едно извикване на draw.
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.

• За Native разработчик, можете да се обърнете към wvr_native_hellovr sampле.
• За разработчици на Unity, вижте режима на рендериране, еднократният проход е многократен.view функция.
• За разработчици на Unreal вижте това ръководство.

3.1.4 Фовеация
Фовейираното рендериране е предназначено предимно за намаляване на натоварването на графичния процесор. То намалява детайлите на кадъра в периферията на дисплея и поддържа детайли с висока резолюция в центъра на полето на изображението. viewАко приложението има проблем с графичния процесор, можете да опитате да разрешите рендерирането на Foveation.

Има нещо, което трябва да се отбележи, когато се използва фовеация:

➢ Потребителите обикновено не забелязват намалените детайли в периферните области, прилагайки режима на фовеация по подразбиране. Но ако периферното качество на фовеацията е зададено твърде ниско, това може да стане забележимо за потребителя.
➢ Ефектите от фовеацията може да са по-забележими при определени материали или текстури, което би могло да привлече вниманието на потребителя. Разработчиците трябва да са наясно с това и да го оценят съответно.
➢ Активирането на функцията за фовеирано рендиране води до фиксирани разходи за производителност на графичния процесор, които могат да варират между 1% и 6% в зависимост от размера на буфера за очи. Когато се използва прост шейдър в сцената, печалбата от производителност от спестяването на ресурси може да е по-ниска от фиксираните разходи за производителност на графичния процесор, което води до спад в производителността.

• За Native разработчик, вижте това ръководство.
• За разработчици на Unity, вижте това ръководство. Важно е да се отбележи, че когато активирате последваща обработка или HDR, фовеацията не може да бъде използвана напълно. Защото Unity ще рендира обекти върху собствената си генерирана текстура за рендиране, а не върху генерираната от изпълнението текстура за рендиране на настоящия продукт, която поддържа фовеацията.
• За разработчици на Unreal вижте това ръководство. Важно е да се отбележи, че фовеацията не може да се използва напълно в Multi-View Рендиране, защото Unreal не може директно да рендира обекти върху генерираната по време на изпълнение текстура за рендиране, която поддържа фовеация.

3.1.5 Подобряване на рязкостта на кадъра (FSE)
FSE осигурява изостряне на резултатите от рендирането чрез въвеждане на филтър за изостряне, който може да направи съдържанието по-ясно и да бъде доста полезен за подобряване на яснотата на текста в сцената. Ако приложението има проблем с графичния процесор, можете да помислите за деактивиране на FSE, ако не е от съществено значение.

• За Native разработчик, вижте това ръководство.
• За разработчици на Unity, вижте това ръководство.
• За разработчици на Unreal вижте това ръководство.

3.1.6 Адаптивно качество
За да се пести батерията и да се поддържа производителността на устройството при рендиране, тази функция автоматично настройва нивата на производителност на тактовата честота на процесора/графичния процесор въз основа на тяхното използване. Освен това могат да се внедрят и други стратегии за подобряване на производителността, като например автоматично включване/изключване на Foveation или самонастройване на съдържанието при получаване на събития с високо/ниско натоварване.

• За Native разработчик, вижте това ръководство.
• За разработчици на Unity, вижте това ръководство. В нашия плъгин за Unity, размерът на буфера за очи може да се регулира автоматично въз основа на текущата производителност; Размерът на текста ще филтрира стойностите на мащаба, които са твърде малки в списъка с резолюция. Препоръчваме текст с размер поне 20 dmm или по-голям.
• За разработчици на Unreal вижте това ръководство.

3.1.7 Адаптивен композитор на движение
Тази функция е експериментална и включва UMC и PMC. UMC ще намали честотата на кадрите наполовина и ще екстраполира новия кадър в реално време, за да запази визуалната плавност. Въпреки това, тя е свързана с известно забавяне, артефакти и натоварване на графичния процесор.
PMC използва предимно буфера за дълбочина, за да позволи на ATW да отчита транслацията на HMD, разширена до компенсация от 6 степени на свобода. Тази функция може да намали латентността на транслацията с 1~2 кадъра, но да увеличи натоварването на графичния процесор.

• За Native разработчик, вижте това ръководство.
• За разработчици на Unity, вижте това ръководство.
• За разработчици на Unreal вижте това ръководство.

3.1.8 Маска за рендериране [Не поддържа Unreal]
Пикселите по краищата стават почти невидими след изкривяване, маската за рендериране променя стойностите на буфера за дълбочина на тези невидими пиксели. Ако активирате тестване на дълбочината, поради early-z, тези невидими пиксели няма да бъдат рендерирани, като по този начин се намалява натоварването на графичния процесор. Тази функция е полезна, ако в тези невидими области има силно натоварени обекти за рендериране; в противен случай, ако в тези области няма обекти за рендериране, се препоръчва да я деактивирате, тъй като ще консумира малко количество енергия на графичния процесор.

• За 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 съдържание, което позволява на потребителите да виждат околната среда ясно, но виртуалната сцена на съдържанието изисква по-фина настройка за по-добра производителност.
Можете да настроите качеството на преминаване на PerformanceMode, за да намалите използването на графичния процесор.

• За Native, Uunity или Unreal разработчик, вижте това ръководство.

3.2.2 Регулиране на честотата на кадрите при преминаване
Подобно на честотата на опресняване на дисплея, по-високата честота на кадрите при преминаване предлага по-плавна графика, но е за сметка на увеличено натоварване на системата. Обратно, по-ниските честоти на опресняване намаляват натоварването на системата, но водят до по-малко плавна графика. Има 2 режима на честота на кадрите при преминаване: Boost и Normal.

• За Native разработчици, качеството на преминаване може да се регулира с помощта на WVR_SetPassthroughImageRate.
• За разработчик на Unity, може да се променя чрез код, напр.ampнастройките на файла са както следва // C#
  Interop.WVR_SetPassthroughImageQuality(WVR_PassthroughImageQuality.PerformanceMode);
• За Unreal Developer, методът на настройка вижте възела blueprint на Фигура 3-2-2.

Настройка на VIVE OpenXR

OpenXR е отворен стандарт, който предоставя общ набор от API за разработване на XR приложения, работещи на широк спектър от VR устройства, разработени от Khronos Group. VIVE Focus 3 и VIVE XR Elite също поддържат OpenXR. VIVE OpenXR SDK предоставя цялостна поддръжка за HTC VR устройства, позволявайки на разработчиците да изграждат All-in-One и съдържание с Unity и Unreal Engine на HTC VR устройства. Ние непрекъснато оптимизираме и отстраняваме различни грешки, така че се препоръчва разработчиците да актуализират FOTA версията на своите устройства, за да я поддържат актуална. В момента VIVE OpenXR SDK поддържа OpenGL ES и Vulkan.

4.1 VR съдържание
4.1.1 Честота на опресняване на дисплея
Концепцията тук е подобна на тази от 3.1.1 Честота на опресняване на дисплея.

• За Native разработчик, вижте XrEventDataDisplayRefreshRateChangedFB.
• За разработчици на Unity, вижте това ръководство.
• За разработчици на Unreal вижте това ръководство.

4.1.2 Разделителна способност на очната мъгла
Концепцията тук е подобна на 3.1.2 Разделителна способност на очната шубра. Препоръчваме да не намалявате коефициента на мащабиране под 0.7, тъй като това може да доведе до неприемливо визуално качество.

• За Native разработчик, вижте xrCreateSwapchain. Когато коригирате размера, трябва да умножите ширината и височината по съотношение.
• За разработчици на Unity, вижте следния примерampле // C#
  XRSettings.eyeTextureResolutionScale = 0.7f; //препоръчително 1.0f~0.7f
• За настройките на Unreal вижте това ръководство.

4.1.3 Мулти-View Изобразяване
Концепцията тук е подобна на тази в 3.1.3 Много-View Рендиране. Тази функция намалява натоварването на процесора, а графичният процесор също има някои предимства. Препоръчваме да активирате тази функция.

• За Native разработчици, KhronosGroup предоставя OpenXR Multi-View exampле, вижте това ръководство.
• За разработчици на Unity, вижте режима на рендериране, еднократният проход е многократен.view функция.
• За настройките на Unreal Developer, както и за VIVE Wave, вижте това ръководство.

4.1.4 Фовеация [Не поддържа Unreal]
Концепцията тук е подобна на тази в 3.1.4 Фовеация. Фовеационното рендиране е предназначено предимно за намаляване на натоварването на графичния процесор, но активирането му ще доведе до фиксирани разходи за производителност на графичния процесор и ако фовеацията е зададена твърде ниско и се използват определени материали или текстури, тя може да стане много...
забележимо за потребителя. Следователно е препоръчително да активирате или деактивирате функцията въз основа на вашите специфични изисквания и съображения за производителност. В момента функционалността Foveated се поддържа само в OpenGL ES на VIVE OpenXR SDK.

• За Native разработчици тази функция е налична, но в момента нямаamples са предоставени.
• За разработчици на Unity, вижте това ръководство.
• За разработчици на Unreal, тази функция не се поддържа в момента.

4.1.5 Маска за рендериране [Не поддържа Unreal]
Концепцията тук е подобна на тази в 3.1.8 Render Mask.

• За Native разработчици, използвайте XrVisibilityMaskKHR, за да получите мрежата (Mesh). Преди рендиране на сцената, използвайте тази мрежа, за да попълните стойностите на буфера за дълбочина.
• За разработчиците на Unity, функцията Render Mask е активирана по подразбиране за OpenGL ES и може да бъде деактивирана със следния код; Vulkan в момента не поддържа тази функция. //C# UnityEngine.XR.XRSettings.occlusionMaskScale = 0.0f;
• За разработчици на Unreal, в момента не се поддържа функцията Render Mask.

4.2 Съдържание на МР
OpenXR в момента не поддържа задаване на качество и честота на кадрите за преминаване. Ще продължим да оптимизираме и поправяме функцията за преминаване, затова препоръчваме на разработчиците да актуализират версията на FOTA на устройството, за да я поддържат актуална.

Обща оптимизация

5.1 Изключване на режима за висока производителност
Изключването на „Режим на висока производителност“ може да намали размера на дисплея на устройството, като по този начин намали използването на графичния процесор. Недостатъкът е намаляване на разделителната способност на екрана. Можете да балансирате качеството и производителността, за да решите дали да го активирате.
Мястото за настройка на VIVE Focus 3 е показано на Фигура 5-1-1:

Мястото за настройка на VIVE XR Elite е показано на Фигура 5-1-2:

5.2 Мултиampling Anti-Aliasing
Мултиampling 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.

• За Native разработчик, MSAA OpenGL ES exsample може да се позовава на това; MSAA Vulkan exampлер може да се позове на това.
  Графичният процесор Adreno предоставя разширение, което оптимизира MSAA.
• За разработчици на Unity, вижте тази гилдия.
• For Unreal developer, refer to this guild. Unreal also has provide post processing anti-aliasing, refer to this guild.

5.3 Зареждане/съхранение на GMEM
В архитектурата на графичния процесор Adreno има функция, при която при свързване на Render Target, ако той не се изчисти или невалидира, всеки път, когато се извърши рендериране, стойностите в Render Target се зареждат в графичната памет, което се нарича GMEM Load. Ако предишните стойности не са необходими, изчистването или невалидирането на Render Target преди рендериране може да избегне тази ситуация и да подобри производителността на графичния процесор.
Можете да избегнете зареждането на GMEM, като използвате следните методи. В OpenGL ES, след свързване на FBO, можете да извикате glClear и glClearDepth, за да изчистите буфера за цвят, дълбочина и шаблон, или да извикате glInvalidateFramebuffer, за да анулирате посочения Render Target. Във Vulkan не са необходими допълнителни инструкции; можете изрично да зададете дали да изчистите прикачения файл преди употреба във VkAttachmentDescription.loadOp.
По подобен начин, съхраняването на резултата от рендериране на плочки обратно в основната памет от графичната памет се нарича GMEM Store; тази операция е скъпа и за графичния процесор. За да избегнете това, препоръчваме да обвържете само необходимите цели за рендериране, за да предотвратите ненужни операции за съхранение.

5.4 Композиционен слой (многослоен)
Текстурите, показани с помощта на многослойна функция, имат по-добро визуално качество. Тази функция обаче значително увеличава производителността на графичния процесор с броя на слоевете и размера на текстурите. Препоръчваме да не се използват повече от три слоя.

• За Native разработчик,
  VIVE Wave SDK използва WVR_SubmitFrameLayers за предаване на данни за всеки слой.
  o VIVE OpenXR SDK поставя данните за слоевете в XrFrameEndInfo и ги изпраща чрез xrEndFrame.
• За разработчика на Unity,
  o Настройки на VIVE Wave SDK, вижте това ръководство,
  o Настройки на VIVE OpenXR, вижте това ръководство.
• За разработчика на Unreal,
  o За настройките на VIVE Wave SDK вижте това ръководство.
  o Настройки на VIVE OpenXR, вижте това ръководство.

5.5 Пик на процесора
Когато натоварването на процесора е по-високо, някои фонови процеси с висок приоритет могат да прекъснат оригиналното изпълнение. Не можем да гарантираме, че приложението за съдържание няма да бъде прекъснато от други нишки.
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.

• За Unity Developer, вижте функцията за конфигуриране на нишки в Android. Ако използвате VIVE Wave SDK, имаме функция в WaveXRSettings, която ви позволява да регулирате приоритета, както е показано на Фигура 5-5-2. По-малката стойност представлява по-висок приоритет.

• Няма начин да промените нишките на играта, нишките за рендериране и приоритета на RHI нишките чрез външни настройки, освен ако не промените кода на двигателя.

Авторско право © 2024 HTC Corporation. Всички права запазени.

Документи / Ресурси

Производителност на рендиране на VIVE VR [pdf] Ръководство за потребителя Ефективност на рендиране на VR, Ефективност на рендиране, Ефективност

Референции

• Ръководство за потребителя