Кіраўніцтва карыстальніка па прадукцыйнасці рэндэрынгу VIVE 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 прысутнічае:90.00 пропуск:0 (0.592301, -0.015502, 0.805539, 0.006773)

Лічба пасля «новай тэкстуры» паказвае бягучую частату кадраў у секунду (FPS) кантэнту. Лічба пасля «R present» і «L present» паказвае частату кадраў дысплея.
Часам 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 | Выберыце радок - шаблон 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%, вы можаце паспрабаваць змяніць дазвол вочнага буфера (раздзел 3.1.2, раздзел 4.1.2), каб паглядзець, ці палепшыць гэта FPS. Калі гэтая карэкціроўка прывядзе да паляпшэння
прадукцыйнасці, мы можам зрабіць выснову, што праблема звязана з графічным працэсарам, і адпаведна сканцэнтраваць свае намаганні па аптымізацыі.
З іншага боку, калі карэкціроўка дазволу вочнага буфера не прыводзіць да прыкметнага паляпшэння прадукцыйнасці, вузкае месца, верагодна, звязана з працэсарам, і нам варта засяродзіцца на аптымізацыі прадукцыйнасці працэсара.
Таксама магчыма, што праграма адначасова абмежаваная выкарыстаннем як працэсара, так і графічнага працэсара. У такіх выпадках аптымізацыю варта накіраваць як на працэсар, так і на графічны працэсар, каб дасягнуць збалансаванага паляпшэння прадукцыйнасці.
2.3 Прывязаны да графічнага працэсара
Калі праграма VR залежыць ад графічнага працэсара, гэта азначае, што графічны працэсар з'яўляецца асноўным вузкім месцам і не можа справіцца з патрабаваннямі праграмы да рэндэрынгу. Каб вырашыць праблемы, звязаныя з графічным працэсарам, выкарыстоўвайце наступныя рэкамендацыі:
Спачатку выкарыстоўвайце інструменты прафілявання, такія як RenderDoc або Game Engine Pro.filer (Unity Profiler, Unreal Insights), каб прааналізаваць, дзе графічны працэсар праводзіць большую частку свайго часу. Вызначце найбольш затратныя аперацыі і засяродзьцеся на іх аптымізацыі.
Для Native Developer вы можаце выкарыстоўваць RenderDoc, каб вызначыць, які выклік малявання выклікае празмерную нагрузку на графічны працэсар.
Распрацоўшчыкі 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), каб прааналізаваць і вызначыць, якія часткі вашага кода спажываюць найбольш рэсурсаў працэсара. Засяродзьцеся на аптымізацыі гэтых абласцей і рэфактарынгуйце вылічальна інтэнсіўныя алгарытмы, каб знізіць нагрузку на працэсар.

• Для натыўных распрацоўшчыкаў вы можаце выкарыстоўваць Systrace для прафесійнагаfileваш праект.
• Для распрацоўшчыкаў Unity вы можаце выкарыстоўваць CPU Usage ProfileМодуль r для пошуку праблем з прадукцыйнасцю працэсара.
• Распрацоўшчыкі Unreal могуць выкарыстоўваць Unreal Insights для пошуку праблем з прадукцыйнасцю працэсара.

Па-другое, вы таксама можаце паспрабаваць змяніць пэўныя функцыі або налады Wave, каб паменшыць нагрузку на графічны працэсар.

1. Устанавіць частату абнаўлення дысплея ніжэй (раздзел 3.1.1, раздзел 4.1.1)
2.  Выкарыстоўвайце мульты-View Рэндэрынг (раздзел 3.1.4, раздзел 4.1.4)

Калі ваша праграма таксама з'яўляецца праграмай MR, вы таксама можаце змяніць параметры прапускання.

1. Зменшце частату кадраў пры праходжанні (раздзел 3.2.2).

Каб даведацца больш пра налады прадукцыйнасці працэсара, звярніцеся да раздзела 2.6.

2.5 Рэзюмэ
Нарэшце, мы арганізавалі вышэйзгаданы працоўны працэс праверкі прадукцыйнасці ў выглядзе малюнка 2-5-1. Пачніце з праверкі FPS кантэнту. Калі ён ніжэйшы за частату кадраў дысплея або застаецца нестабільным, прааналізуйце выкарыстанне графічнага працэсара/працэсара, каб вызначыць, ці звязана гэта з графічным працэсарам або працэсарам. Нарэшце, выкарыстоўвайце прафесійны...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 Разрозненне вочнага буфера
  ▪ 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
  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 Выключэнне рэжыму высокай прадукцыйнасці
  5.2 Мультыampлінг
  5.3 Загрузка/захаванне GMEM
  5.4 Кампазіцыйны пласт (шматслаёвы)

Налада хвалі VIVE

VIVE Wave — гэта адкрытая платформа і набор інструментаў, якія дазваляюць лёгка распрацоўваць VR-кантэнт і забяспечваюць высокапрадукцыйную аптымізацыю прылад для старонніх партнёраў. VIVE Wave падтрымлівае гульнявыя рухавічкі Unity і Unreal.
Мы пастаянна аптымізуем і выпраўляем розныя памылкі, таму рэкамендуем падтрымліваць SDK у актуальным стане.
У цяперашні час VIVE Wave падтрымлівае толькі OpenGL ES. Тут пералічаны функцыі ў парадку ўплыву на прадукцыйнасць графічнага працэсара. Мы падзелім іх на дзве часткі: VR-кантэнт і MR-кантэнт.
3.1 VR-кантэнт
3.1.1 Частата абнаўлення дысплея

Больш высокая частата абнаўлення забяспечвае больш плаўную графіку, але пры гэтым павялічваецца нагрузка на сістэму. І наадварот, больш нізкая частата абнаўлення зніжае нагрузку на сістэму, але прыводзіць да менш плаўнай графікі. Калі ў праграмы ёсць праблемы з прывязкай да працэсара/графічнага працэсара, вы можаце паспрабаваць знізіцьasinчастату абнаўлення дысплея, каб вырашыць праблему.

• Для распрацоўшчыкаў Native глядзіце WVR_SetFrameRate.
• Для распрацоўшчыкаў Unity звярніцеся да гэтага кіраўніцтва.
• Для распрацоўшчыкаў Unreal звярніцеся да гэтага кіраўніцтва.

3.1.2 Разрозненне буфера вачэй
Разрозненне вочнага буфера — гэта памер тэкстуры, які будзе адлюстроўвацца ў дадатку. Апрасаваная тэкстура будзе адпраўлена ў асяроддзе выканання для публікацыі і адлюстравання на дысплеі HMD.
Хоць большы памер буфера вока можа прывесці да больш выразнай і дэталізаванай графікі, ён таксама стварае значную нагрузку на графічны працэсар. Таму вельмі важна знайсці правільны баланс паміж якасцю выявы і прадукцыйнасцю.
Калі ў праграмы ёсць праблемы з прывязкай да графічнага працэсара, вы можаце паспрабаваць decreasinПамножце памер буфера вачэй на маштабны каэфіцыент. Аднак мы не рэкамендуем змяншаць маштабны каэфіцыент ніжэй за 0.7, бо гэта можа прывесці да непрымальнай якасці выявы.

• Для распрацоўшчыкаў Native глядзіце WVR_ObtainTextureQueue. Пры карэкціроўцы памеру трэба памножыць шырыню і вышыню на каэфіцыент.
• Для распрацоўшчыкаў Unity звярніцеся да WaveXRSettings.
  Акрамя таго, вы можаце ўнесці змены з дапамогай кода, паказанага ніжэй.
  XRSettings.eyeTextureResolutionScale = ResolutionScaleValue; // C#
• Для распрацоўшчыкаў Unreal звярніцеся да SetPixelDensity.

3.1.3 Мульты-View Аказанне
Пры традыцыйным рэндэрынгу мы малюем левае і правае вока асобна, што патрабуе двух выклікаў малявання для адной і той жа сцэны.View Рэндэрынг вырашае гэтую праблему, выконваючы толькі адзін выклік малявання.
Гэтая функцыя зніжае нагрузку на працэсар наasinколькасць выклікаў малявання. Графічны працэсар таксама мае некаторыя перавагі, нагрузка вяршыннага шэйдара таксама змяншаецца, бо яму не трэба запускаць дадатковы шэйдар для другога вока, але нагрузка фрагментнага шэйдара застаецца нязменнай, бо яму ўсё яшчэ трэба ацэньваць кожны піксель для абодвух вачэй. Мы рэкамендуем уключыць гэтую функцыю.

• Для распрацоўшчыкаў Native вы можаце звярнуцца да wvr_native_hellovrampле.
• Для распрацоўшчыкаў 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 функцыя рэндэрынгу маскі ў цяперашні час не падтрымліваецца.

3.2 Змест МР
3.2.1 Рэгуляванне якасці прапускання
Існуе 3 узроўні якасці скразнога малюнка:
➢ WVR_PassthroughImageQuality_DefaultMode – падыходзіць для MR-кантэнту без канкрэтных патрабаванняў.
➢ WVR_PassthroughImageQuality_PerformanceMode – падыходзіць для MR-кантэнту, якому патрабуецца больш рэсурсаў графічнага працэсара для рэндэрынгу віртуальнай сцэны.
➢ WVR_PassthroughImageQuality_QualityMode – падыходзіць для MR-кантэнту, які дазваляе карыстальнікам выразна бачыць навакольнае асяроддзе, але віртуальная сцэна кантэнту патрабуе больш тонкай налады для прадукцыйнасці.
Вы можаце наладзіць якасць прапускання ў рэжыме PerformanceMode, каб паменшыць выкарыстанне графічнага працэсара.

• Для распрацоўшчыкаў Native, Uunity або Unreal звярніцеся да гэтага кіраўніцтва.

3.2.2 Рэгуляванне частаты кадраў прапускання
Як і частата абнаўлення дысплея, больш высокая частата кадраў пры праходжанні забяспечвае больш плаўную графіку, але пры гэтым павялічваецца нагрузка на сістэму. І наадварот, ніжэйшая частата абнаўлення зніжае нагрузку на сістэму, але прыводзіць да менш плаўнай графікі. Існуе 2 рэжымы частаты кадраў пры праходжанні: Boost і Normal.

• Для натыўных распрацоўшчыкаў якасць прапускання можна наладзіць з дапамогай WVR_SetPassthroughImageRate.
• Для распрацоўшчыка Unity, можна змяніць праз код, напрыкладampналады наступныя // C#
  Interop.WVR_SetPassthroughImageQuality(WVR_PassthroughImageQuality.PerformanceMode);
• Для распрацоўшчыка Unreal, метад налады глядзіце ў вузле blueprint на малюнку 3-2-2.

Налада VIVE OpenXR

OpenXR — гэта адкрыты стандарт, распрацаваны Khronos Group, які забяспечвае агульны набор API для распрацоўкі XR-прыкладанняў, якія працуюць на шырокім дыяпазоне VR-прылад. VIVE Focus 3 і VIVE XR Elite таксама падтрымліваюць OpenXR. VIVE OpenXR SDK забяспечвае поўную падтрымку VR-прылад HTC, дазваляючы распрацоўшчыкам ствараць універсальныя прылады і кантэнт з рухавікамі Unity і Unreal на прыладах 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, бо гэта можа прывесці да непрымальнай якасці выявы.

• Для натыўных распрацоўшчыкаў звярніцеся да xrCreateSwapchain. Пры карэкціроўцы памеру трэба памножыць шырыню і вышыню на каэфіцыент.
• Для распрацоўшчыкаў Unity звярніцеся да наступнага прыкладуampле // C#
  XRSettings.eyeTextureResolutionScale = 0.7f; //рэкамендуецца 1.0f~0.7f
• Інфармацыю пра налады Unreal глядзіце ў гэтым кіраўніцтве.

4.1.3 Мульты-View Аказанне
Канцэпцыя тут падобная да 3.1.3 Мульты-View Рэндэрынг. Гэтая функцыя зніжае нагрузку на працэсар, графічны працэсар таксама мае некаторыя перавагі. Мы рэкамендуем уключыць гэту функцыю.

• Для натыўных распрацоўшчыкаў KhronosGroup прапануе шматфункцыянальны OpenXRView exampле, звярніцеся да гэтага кіраўніцтва.
• Для распрацоўшчыкаў Unity звярніцеся да рэжыму рэндэрынгу, адзін праход — гэта шматпраходны рэжым.view асаблівасць.
• Для распрацоўшчыкаў Unreal, як і для налад VIVE Wave, звярніцеся да гэтага кіраўніцтва.

4.1.4 Фовеацыя [Не падтрымлівае Unreal]
Канцэпцыя падобная да версіі 3.1.4 Фовеацыя. Фовеацыя ў першую чаргу прызначана для зніжэння нагрузкі на графічны працэсар, але яе ўключэнне пацягне за сабой фіксаваныя выдаткі на прадукцыйнасць графічнага працэсара, і калі фавеацыя ўстаноўлена занадта нізка і выкарыстоўваюцца пэўныя матэрыялы або тэкстуры, яна можа стаць вельмі
прыкметна для карыстальніка. Таму рэкамендуецца ўключаць або адключаць гэту функцыю ў залежнасці ад вашых канкрэтных патрабаванняў і меркаванняў па прадукцыйнасці. У цяперашні час функцыянальнасць Foveated падтрымліваецца толькі ў OpenGL ES на VIVE OpenXR SDK.

• Для натыўных распрацоўшчыкаў гэтая функцыя даступная, але ў цяперашні час неampпрадастаўляюцца лес.
• Для распрацоўшчыкаў Unity звярніцеся да гэтага кіраўніцтва.
• Для распрацоўшчыкаў Unreal гэтая функцыя пакуль не падтрымліваецца.

4.1.5 Маска рэндэрынгу [Не падтрымлівае Unreal]
Канцэпцыя тут падобная да версіі 3.1.8 Render Mask.

• Для распрацоўшчыкаў Native выкарыстоўвайце XrVisibilityMaskKHR для атрымання сеткі. Перад рэндэрынгам сцэны выкарыстоўвайце гэтую сетку для запаўнення значэнняў буфера глыбіні перад рэндэрынгам сцэны.
• Для распрацоўшчыкаў Unity функцыя Render Mask уключана па змаўчанні для OpenGL ES і можа быць адключана з дапамогай наступнага кода; Vulkan у цяперашні час не падтрымлівае гэту функцыю. //C# UnityEngine.XR.XRSettings.occlusionMaskScale = 0.0f;
• Для распрацоўшчыкаў Unreal функцыя рэндэрынгу маскі ў цяперашні час не падтрымліваецца.

4.2 Змест МР
OpenXR у цяперашні час не падтрымлівае наладу якасці перадачы дадзеных і частаты кадраў. Мы будзем працягваць аптымізацыю і выпраўленне функцыі перадачы дадзеных, таму рэкамендуем распрацоўшчыкам абнаўляць версію FOTA прылады, каб падтрымліваць яе ў актуальным стане.

Агульная аптымізацыя

5.1 Выключэнне рэжыму высокай прадукцыйнасці
Адключэнне «Рэжыму высокай прадукцыйнасці» можа паменшыць памер дысплея прылады, тым самым зніжаючы выкарыстанне графічнага працэсара. Недахопам з'яўляецца зніжэнне разрознення экрана. Вы можаце збалансаваць якасць і прадукцыйнасць, каб вырашыць, ці ўключаць яго.
Месца ўстаноўкі VIVE Focus 3 паказана на малюнку 5-1-1:

Месца ўстаноўкі VIVE XR Elite паказана на малюнку 5-1-2:

5.2 МультыampЛінг Анты-Аліasing
МультыampЛінг — гэта анты-аліasinТэхніка g, якая выкарыстоўваецца для згладжвання няроўных краёў, звычайна паскараецца апаратным забеспячэннем, што прыводзіць да зніжэння прадукцыйнасці графічнага працэсара. Мы не рэкамендуем усталёўваць MSAA вышэй за 2x, таму што большае значэнне height прывядзе да большага спажывання рэсурсаў графічнага працэсара.

• Для натыўных распрацоўшчыкаў, MSAA OpenGL ES exsample можа спасылацца на гэта; MSAA Vulkan exampлер можа спасылацца на гэта.
  Графічны працэсар Adreno прапануе пашырэнне, якое аптымізуе MSAA.
• Для распрацоўшчыкаў Unity звярніцеся да гэтай гільдыі.
• Распрацоўшчыкам Unreal варта звярнуцца ў гэтую гільдыю. Unreal таксама прапануе пост-апрацоўку і Anti-Ali.asinг, звярніцеся да гэтай гільдыі.

5.3 Загрузка/захаванне GMEM
У архітэктуры графічнага працэсара Adreno ёсць функцыя, пры якой пры прывязцы да мэты рэндэрынгу, калі яна не ачышчаецца або не анулюецца, кожны раз, калі адбываецца рэндэрынг, значэнні з мэты рэндэрынгу загружаюцца ў графічную памяць, што называецца загрузкай GMEM. Калі папярэднія значэнні не патрэбныя, ачысціце або анулюйце мэта рэндэрынгу перад рэндэрынгам, каб пазбегнуць гэтай сітуацыі і палепшыць прадукцыйнасць графічнага працэсара.
Вы можаце пазбегнуць загрузкі GMEM, выкарыстоўваючы наступныя метады. У OpenGL ES, пасля прывязкі FBO, вы можаце выклікаць glClear і glClearDepth, каб ачысціць буфер колеру, глыбіні і трафарэта, або выклікаць glInvalidateFramebuffer, каб зрабіць несапраўдным пазначаны Render Target. У Vulkan дадатковыя інструкцыі не патрэбныя; вы можаце відавочна ўказаць, ці ачышчаць укладанне перад выкарыстаннем, у VkAttachmentDescription.loadOp.
Падобным чынам, захаванне выніку рэндэрынгу пліткі з графічнай памяці назад у асноўную памяць называецца GMEM Store; гэтая аперацыя таксама дарагая для графічнага працэсара. Каб пазбегнуць гэтага, мы рэкамендуем прывязваць толькі неабходныя мэты рэндэрынгу, каб прадухіліць непатрэбныя аперацыі захоўвання.

5.4 Кампазіцыйны пласт (шматслаёвы)
Тэкстуры, якія адлюстроўваюцца з дапамогай шматслаёвага рэжыму, маюць лепшую візуальную якасць. Аднак гэтая функцыя значна павялічвае прадукцыйнасць графічнага працэсара з-за колькасці слаёў і памеру тэкстур. Мы рэкамендуем не выкарыстоўваць больш за тры пласты.

• Для натыўнага распрацоўшчыка,
  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 пік нагрузкі на працэсар
Калі нагрузка на працэсар высокая, некаторыя фонавыя працэсы з высокім прыярытэтам могуць перапыніць убудаванае выкананне. Мы не можам гарантаваць, што праграма кантэнту не будзе перапынена іншымі патокамі.
Калі ўзнікнуць такія праблемы, вы можаце паспрабаваць павялічыцьasinЗмяніце прыярытэт патоку, каб паглядзець, ці вырашыць гэта праблему. Але калі вы зменіце канфігурацыю патоку для аптымізацыі прылад, вам трэба праверыць, ці мае гэта які-небудзь негатыўны ўплыў.

• Для распрацоўшчыкаў Unity звярніцеся да функцыі канфігурацыі патокаў Android. Калі вы выкарыстоўваеце VIVE Wave SDK, у WaveXRSettings ёсць функцыя, якая дазваляе рэгуляваць прыярытэт, як паказана на малюнку 5-5-2. Меншае значэнне азначае больш высокі прыярытэт.

• Няма спосабу змяніць гульнявы ​​паток, паток рэндэрынгу і прыярытэт патокаў RHI праз знешнія налады, калі вы не зменіце код рухавічка.

Аўтарскае права © 2024 HTC Corporation. Усе правы абаронены