tags: [vr-ar]
Профілювання використання GPU ресурсів у VR іграх
Коли VR гра не утримує цільову частоту кадрів, перше, що роблять розробники — зменшують розрішення або прибирають об'єкти. Це допомагає, але не вирішує проблему: після наступного спринту з новим контентом все повторюється. Правильний підхід — знайти конкретні GPU вузькі місця через профілювання та усунути саме їх.
Специфіка VR: на Quest без підключення до ПК немає повноцінного GPU capture. Інструменти потрібно підбирати під платформу. Для standalone Quest — OVR Metrics Tool та Snapdragon Profiler. Для PCVR (SteamVR, OpenXR на PC) — RenderDoc, NVIDIA Nsight або AMD Radeon GPU Profiler. Для Quest через Link — гібридний варіант.
RenderDoc: як правильно читати GPU capture у VR
RenderDoc — стандарт для аналізу рендер-pipeline. Для VR проектів у Unity підключається через RenderDoc Integration або вручну через UnityEngine.Rendering.DebugManager. У Single Pass Instanced режимі у RenderDoc видні два viewport в одному draw call — це нормально, не варто лякатися.
Що шукати першим ділом: вид Timeline у RenderDoc показує тривалість кожного проходу в мілісекундах. У типовій VR сцені найдорожчі pass-и — Shadow Map rendering, Opaque rendering, Transparent rendering. Якщо Shadow Map займає 3+ мс при бюджеті 8–9 мс на кадр — це перша ціль.
У списку drawcall шукаємо повторюючі паттерни: одні й ті ж вызови, які не батчаться. Якщо Mesh Renderer відрисовується 50 разів окремими вызовами замість одного інстансованого — це CPU-overhead, не GPU. Вони видні по іконці у RenderDoc та по тому, що часи маленькі, але вызовів багато.
Для пошуку GPU bottleneck використовуємо PIX markers (у Unity встановлюються через CommandBuffer.BeginSample/EndSample) — вони розбивають frame на іменовані блоки та одразу показують, скільки GPU-часу займає кожен блок. Без маркерів доводиться гадати, до якої ділянки коду належить конкретний draw call.
Snapdragon Profiler для Meta Quest
RenderDoc не працює безпосередньо на Android-based Quest без PCVR Link. Тут основний інструмент — Snapdragon Profiler від Qualcomm. Підключається до Quest через ADB (adb connect), вимагає режиму розробника на шлемі.
Ключові метрики у Snapdragon Profiler: GPU Busy %, Fragment ALU Instructions/Vertex, Textures Fetches per Cycle, L2 Cache Hit Rate. Якщо GPU Busy постійно 95–100% — GPU-bound. Якщо нижче 70% при дропах — CPU-bound, і оптимізувати GPU безглуздо.
Overdraw у Snapdragon Profiler показується як Visibility Ratio — співвідношення відрисованих пікселів до фінально видимих. Для мобільного VR нормою вважається 1.5–2x. Вище 3x — серйозна проблема з сортуванням прозорих об'єктів або з draw order непрозорої геометрії.
Тайлова архітектура GPU на Quest (Tile-Based Deferred Rendering) принципово відрізняється від desktop GPU. Записи у render target не зберігаються у RAM одразу, а буферизуються у on-chip tile memory. Якщо шейдер або постобробка порушують цей потік (наприклад, читають з render target, у який щойно писали), відбувається tile flush — дані вивантажуються у RAM та знову завантажуються. Це дорого. У Snapdragon Profiler це видно по spike у Tile Flush Count.
Кейс: 43% GPU-часу на один ефект туману
Проект — пригодницька VR-гра для Quest 2. Скарга: стабільно 60–65 fps при цільових 72, без явних важких об'єктів у сцені.
Профілювання через Snapdragon Profiler виявило: 43% GPU-часу у outdoor-сценах йде на volumetric fog. Ефект був портований напрямку з PC-версії: full-screen ray marching з 64 кроками на піксель. На Quest це катастрофа — кожен піксель робить 64 выборки текстури.
Рішення: заміна volumetric fog на псевдооб'ємний туман через Depth Fog у шейдері (туман за глибиною) плюс кілька крупних particle-plane з туманною текстурною атласом на ближніх планах. GPU-час — з 4.2 мс до 0.3 мс. Візуально — практично невідрізне для кінцевого користувача у VR, де сприйняття деталей знижено через дистанцію та рух.
Етапи роботи
Профілювання починається з визначення платформи та встановлення інструментів. Для Quest — фізичний шлем у режимі розробника, Snapdragon Profiler, ADB. Для PCVR — RenderDoc на цільовому GPU. Збір базових метрик у кількох репрезентативних сценах.
Після аналізу складається пріоритизований список проблем: за внеском у GPU-час та складністю усунення. Звичайно 3–5 пунктів дають 60–70% приросту продуктивності. Решта — робота за спадною дохідністю.
| Етап | Строки |
|---|---|
| Профілювання + звіт з рекомендаціями | 3–5 днів |
| Профілювання + усунення топ-3 проблем | 1–2 тижні |
| Повний цикл оптимізації з верифікацією | 3–5 тижнів |
Вартість розраховується індивідуально після отримання доступу до проекту та інформації про цільову платформу.