Профілювання CPU та GPU ігор: знайдемо та усунемо гальма

Профілювання CPU та GPU ресурсів ігор: знайдемо та усунемо гальма

Зазначимо: коли гра гальмує, перший інстинкт — відкрити Stats у Game View і дивитися на FPS. Це марно. Stats показує усереднене значення, не бачить спайків, не розділяє CPU від GPU, не показує, який саме код з'їдає час. Для реальної діагностики потрібен Profiler у режимі Standalone на цільовому залізі. Наша команда з 10-річним досвідом та понад 50 успішними проєктами щодня вирішує такі завдання. Замість ворожіння на fps-лічильнику пропонуємо системний підхід: від зняття профілю до впровадження оптимізацій під ключ.

Різниця між «42 fps у середньому» та «42 fps з просадками до 18 на кожному третьому кадрі» — це різниця між комфортною грою та відчуттям, що гра зламана. І це видно тільки через frame time graph, не через fps-лічильник. Ми гарантуємо стабільний результат на цільових платформах.

Як відрізнити CPU bottleneck від GPU bottleneck?

Перше питання при будь-якій оптимізації: де вузьке місце. Якщо CPU гальмує → GPU чекає. Якщо GPU гальмує → CPU чекає. Змішувати методи оптимізації без розуміння цього — марна трата часу.

Діагностика в Unity Profiler: відкриваємо модуль CPU Usage, дивимося на Gfx.WaitForPresent або Graphics.PresentAndSync. Якщо ці маркери займають 8+ мс із 16.6 мс бюджету кадру — ви GPU-bound. CPU вже віддав усе GPU і просто чекає.

Якщо ж PlayerLoop, Physics.Processing або ваші скрипти займають більшу частину frame time, а Gfx.WaitForPresent мінімальний — ви CPU-bound.

Це принципово різні шляхи оптимізації. GPU-bound: зменшуємо складність шейдерів, overdraw, fill rate. CPU-bound: оптимізуємо скрипти, використовуємо Job System, скорочуємо кількість Update()-викликів.

Глибоке профілювання CPU

Deep Profile в Unity — потужний інструмент, але з overhead'ом: він інструментує кожен виклик методу, і сам по собі сповільнює гру. Використовуємо тільки для точкової діагностики конкретної підсистеми, не як постійний режим.

Зазначимо: що шукаємо в CPU профілі:

• Managed heap allocations у Update(). Кольоровий маркер у Profiler — GC.Alloc. Будь-яка алокація в гарячому шляху (Update, FixedUpdate, OnCollisionEnter) потенційно викличе GC.Collect у майбутньому. GC.Collect на мобільних пристроях — це 2–20 мс spike. Виправляється через кешування посилань, object pools, string interning, заміну LINQ на ручні цикли.

• Physics.Processing займає > 4 мс. Занадто складні Collider'и (Mesh Collider замість Capsule), надто маленький Fixed Timestep, занадто багато Rigidbody з ContinuousCollisionDetection. Перш за все — Physics Debugger: візуалізуємо sleep state усіх Rigidbody, шукаємо ті, що не сплять без причини.

• NavMesh.CalculatePath кожен кадр для 40 агентів. NavMeshAgent оновлюється за замовчуванням у кожному FixedUpdate. Для великої кількості агентів — розбиваємо на групи з оновленням через кадр або через N кадрів залежно від дистанції до гравця.

Коли використовувати RenderDoc замість Unity Frame Debugger?

RenderDoc — обов'язковий інструмент для будь-якого серйозного GPU-профілювання. Підключається до Android/PC, робить capture одного кадру, показує кожен draw call з часом на GPU, Input/Output текстури, pipeline state. Саме тут видно, який шейдер з'їдає 60% GPU time. RenderDoc дає в 10 разів більше деталей, ніж вбудований Frame Debugger.

Unity Frame Debugger — легший у використанні, але менш детальний. Показує порядок відмальовування, чому об'єкти не батчаться, стан render targets. Для первинної діагностики цілком достатній.

На мобільних пристроях — ARM Streamline (Mali) або Snapdragon Profiler (Adreno). Вони показують метрики, недоступні в Unity: bandwidth memory, ALU utilization, texture cache miss rate. Саме texture cache miss (багато маленьких текстур замість атласу) або високий bandwidth (текстури без mipmaps) часто є справжньою причиною гальм там, де Draw Calls здавалися в нормі.

Реальний кейс: мобільний аркадний раннер, 45 fps на Snapdragon 730. CPU профіль — чисто, скрипти займають < 3 мс. GPU — підозріло багато fill rate за даними Snapdragon Profiler. RenderDoc показав: кастомний distortion-шейдер на воді семплював GrabPass (Screen Space Texture) на кожному кадрі, плюс стояв у Transparent queue поверх трьох інших шарів з блендингом. Заміна GrabPass на попередньо запечену кубмап-текстуру для фонових віддзеркалень + перенесення water mesh нижче за Z-order прибрали 11 мс з GPU time. Підсумок: 58–60 fps стабільні.

Процес профілювання

Спочатку визначаємо цільові метрики: fps бюджет (30/60/120), допустимий frame time (16.6/8.3 мс), платформа. Без цільових метрик незрозуміло, що вважати «достатньо хорошим».

Профілюємо в кількох сценаріях: idle (персонаж стоїть), пікове навантаження (бій з максимальною кількістю ефектів), перехід між сценами. Кожен сценарій — окремий Profiler capture.

Створюємо звіт з конкретними bottleneck'ами, їхньою вагою в ms та пропозиціями щодо усунення. Пріоритизуємо за співвідношенням зусиль до приросту продуктивності.

Порівняння інструментів профілювання GPU

Що входить у роботу з профілювання

Після завершення аудиту ви отримуєте:

• Детальний звіт із зазначенням усіх вузьких місць та їхнім впливом на продуктивність.
• Виправлені сцени та налаштування проєкту з покращеннями.
• Рекомендації щодо подальшої підтримки та моніторингу.

Ми працюємо під ключ: від первинного аналізу до впровадження фіксів. Оцінимо ваш проєкт та запропонуємо оптимальний план. Зв'яжіться з нами, щоб отримати консультацію.

Вартість визначається після вивчення проєкту та цільових платформ.

Чому профілювання критичне для продуктивності?

Без профілювання ви витрачаєте час на здогади. Замість того щоб оптимізувати реальні вузькі місця, ви можете покращити те, що не потрібно. Статистика показує: до 70% проблем продуктивності ігор пов'язані з неправильною оцінкою bottleneck'ів. Ми за 10+ років роботи переконалися: кожна друга гра на стадії фінального полішу має приховані гальма, які виявляються тільки при профілюванні на цільовому залізі. Наш досвід гарантує, що ви отримаєте стабільний FPS без зайвих витрат.

Документація Profiler Unity — офіційна документація по Profiler.