Профилирование 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(). Coloured Marker в 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: visualize 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 без лишних затрат.

Unity Profiler Documentation — официальная документация по Profiler.