Получите эти полезные советы по продвинутому профилированию

В июне мы провели вебинар с участием экспертов из Arm, команды Unity Studio Productions и SYBO Games, создателя Subway Surfers. В результате круглого стола мы сосредоточились на советах и стратегиях профилирования мобильных игр, бизнес-импликациях плохой производительности и том, как SYBO выпустила успешную мобильную игру с 3 миллиардами загрузок на данный момент.

Давайте углубимся в некоторые из последующих вопросов, которые мы не успели обсудить во время вебинара. Вы также можете посмотреть полную запись.

Мы много слышим о профайлере Unity в связи с профилированием ЦП, но не так много о Анализаторе профиля (доступен как пакет Unity). Есть ли планы по его улучшению или интеграции в основной набор инструментов профайлеров?

В настоящее время нет немедленных планов по интеграции Анализатора профиля в основной редактор, но это может измениться по мере развития наших инструментов профилирования.

Есть ли у Unity планы добавить опцию для модуля профилирования использования GPU, чтобы он отображался в процентах, как это делается в миллисекундах?

Это отличная идея, и хотя мы не можем сказать да или нет на момент написания этого блога, это запрос, который был передан нашим командам НИОКР для возможного будущего рассмотрения.

Есть ли у вас планы по решению ошибок "Приложение не отвечает" (ANR), которые сообщаются магазином Google Play и не содержат никакого трассировочного стека?

Хотя у нас в данный момент нет конкретных планов по отслеживанию ANR без трассировочного стека, мы рассмотрим это для будущей дорожной карты.

Как я могу поделиться своим мнением, чтобы помочь повлиять на будущее развитие инструментов профилирования Unity?

Вы можете следить за предстоящими функциями и делиться отзывами через нашу доску продуктов и форумы. Мы также проводим опрос, чтобы узнать больше о опыте наших клиентов с инструментами профилирования. Если вы использовали инструменты профилирования ранее (ежедневно или всего лишь один раз) или работаете над проектом, который требует оптимизации, мы будем рады получить ваш отзыв. Опрос разработан так, чтобы занять не более 5–10 минут.

Участвуя, вы также получите возможность согласиться на последующее интервью, чтобы поделиться дополнительными отзывами непосредственно с командой разработчиков, включая возможность обсудить потенциальные прототипы новых функций.

Существует ли хорошее правило для определения того, что считается жизнеспособным устройством низкого уровня для целевой аудитории?

Правило, которое мы слышим от многих разработчиков игр на Unity, заключается в том, чтобы нацеливаться на устройства, которым пять лет на момент выхода вашей игры, так как это помогает обеспечить наибольшую пользовательскую базу. Но мы также видим, что команды сокращают свои сроки выхода до устройств, которым всего три года, если они нацелены на более высокое качество графики. Визуально сложное 3D-приложение, например, будет иметь более высокие требования к устройству, чем простое 2D-приложение. Этот подход позволяет установить более высокие "минимальные спецификации", но уменьшает размер начальной базы установок. Это, по сути, бизнес-решение: Будет ли стоить больше разрабатывать и поддерживать старые устройства, чем то, что ваша игра заработает на них?

Иногда технические требования вашей игры будут диктовать ваши минимальные целевые спецификации. Так что, если ваша игра использует большое количество текстурной памяти даже после оптимизации, но вы абсолютно не можете снизить качество или разрешение, это, вероятно, исключает возможность запуска на телефонах с недостаточной памятью. Если ваше решение для рендеринга требует вычислительных шейдеров, это, вероятно, исключает устройства с драйверами, которые не поддерживают OpenGL ES 3.1, Metal или Vulkan.

Хорошая идея - посмотреть на рыночные данные для вашей приоритетной целевой аудитории. Например, спецификации мобильных устройств могут сильно различаться между странами и регионами. Не забудьте определить некоторые целевые "бюджеты", чтобы цели бенчмаркинга для того, что приемлемо, были установлены до выбора устройств низкого уровня для тестирования.

Для игр с живым сервисом, которые будут работать в течение многих лет, вам нужно будет постоянно следить за их совместимостью и адаптироваться со временем на основе как вашей фактической пользовательской базы, так и текущих устройств на рынке.

Достаточно ли тестировать производительность исключительно на устройствах низкого уровня, чтобы гарантировать, что игра также будет работать плавно на устройствах высокого уровня?

Может быть, если у вас однородная нагрузка на всех устройствах. Тем не менее, вам все равно нужно учитывать вариации между аппаратным обеспечением от разных производителей и/или версиями драйверов.

Обычно для графически насыщенных игр существуют уровни графической четкости - чем выше визуальный уровень, тем больше ресурсов требуется на способных устройствах. Этот выбор уровня может быть автоматическим, но все чаще пользователи сами могут контролировать выбор через меню графических настроек. Для этого стиля разработки вам нужно протестировать как минимум одно устройство с "минимальными характеристиками" для каждого уровня функций/нагрузки, которые поддерживает ваша игра.

Если ваша игра определяет возможности устройства, на котором она работает, и адаптирует графический вывод по мере необходимости, она может работать по-разному на более мощных устройствах. Поэтому обязательно протестируйте на ряде устройств с различными уровнями качества, для которых вы программировали игру.

Примечание. В этом разделе мы указали, является ли эксперт, отвечающий на вопрос, из Arm или Unity.

У вас есть советы по определению диапазона мощности устройства для поддержки автоматических настроек качества, особенно для мобильных устройств?

Arm: Мы обычно видим, что разработчики делают грубую группировку возможностей на основе моделей CPU и GPU, а также количества ядер шейдеров GPU. Это никогда не идеально, но это "приблизительно правильно". Многие студии собирают живую аналитику с развернутых устройств, чтобы дополнить автоматическую группировку возможностями конкретных устройств с опцией включения/выключения, чтобы обойти проблемы, когда группировка возможностей недостаточно точна.

Что касается предыдущего вопроса, для графически насыщенного контента мы наблюдаем тенденцию в мобильных устройствах к меню настроек, где пользователи могут выбирать, включать или отключать эффекты, тем самым позволяя им делать выбор производительности, который соответствует их предпочтениям.

Unity: Память устройства и разрешение экрана также являются важными факторами при выборе настроек качества. Что касается текстур, разработчики должны быть осведомлены о том, что Текстуры рендеринга, используемые эффектами или постобработкой, могут стать проблемой на устройствах с экранами высокого разрешения, но без достаточного объема памяти.

Учитывая разнообразие доступных конфигураций (CPU, GPU, SOC, память, мобильные, настольные, консольные и т. д.), можете ли вы предложить способ классификации устройств, чтобы сократить количество уровней, для которых нужно оптимизировать?

Arm: Количество уровней, для которых ваша команда оптимизирует, на самом деле является решением в области дизайна игр и бизнеса и должно основываться на том, насколько важно повышать визуальное качество для ценностного предложения игры. Для некоторых жанров это может не иметь значения, но для других пользователи будут иметь высокие ожидания по визуальной четкости.

Различается ли лимит памяти текстур среди моделей и брендов устройств Android, которые имеют одинаковое количество общей системной памяти?

Arm: При первом приближении мы ожидаем, что общее количество памяти текстур будет схожим среди производителей и поколений оборудования. Будут небольшие различия, вызванные компоновкой памяти и ограничениями выравнивания, поэтому это не будет точно так же.

Это использование ЦПУ или ГПУ, которое больше всего способствует перегреву мобильных устройств?

Arm: Это полностью зависит от содержания. ЦПУ, ГПУ или DRAM могут индивидуально перегревать высококачественное устройство, если их сильно нагружать, даже если вы полностью игнорируете другие два. Точное соотношение будет варьироваться в зависимости от рабочей нагрузки, которую вы выполняете.

Какие советы вы можете дать для профилирования на устройствах, которые имеют термическое ограничение? Какую маржу вы бы нацелились, чтобы избежать термического ограничения (т.е. нацеливаясь на 20 мс вместо 33 мс)?

ARM: Оптимизация времени кадра может быть обманчивой на Android, потому что устройства постоянно регулируют частоту для оптимизации потребления энергии, что делает время кадра неполной мерой само по себе. Предпочтительно, следите за циклами ЦПУ и ГПУ на кадр, а также за пропускной способностью памяти ГПУ на кадр, чтобы получить значение, независимое от частоты. Целевой цикл, который вам нужен, будет зависеть от проектирования чипа каждого устройства, поэтому вам нужно будет поэкспериментировать.

Любая оптимизация помогает в управлении потреблением энергии, даже если она не улучшает частоту кадров напрямую. Например, снижение циклов ЦПУ уменьшит тепловую нагрузку, даже если ЦПУ не является критическим путем для вашей игры.

Кроме того, оптимизация пропускной способности памяти является одной из самых больших экономий, которые вы можете сделать. Доступ к DRAM в несколько раз дороже, чем доступ к локальным данным на чипе, поэтому следите за своим бюджетом треугольников и держите типы данных в памяти как можно меньше.

Unity: Чтобы ограничить влияние частоты тактового сигнала ЦПУ на показатели производительности, мы рекомендуем пытаться работать при постоянной температуре. Существует несколько подходов для этого:

• Работайте в тепле: Запустите устройство на некоторое время, чтобы оно достигло стабильного теплого состояния перед профилированием.
• Работайте в холоде: Оставьте устройство остывать на некоторое время перед профилированием. Эта стратегия может устранить путаницу и несоответствия в сессиях профилирования, делая захваты, которые вряд ли будут термически ограничены. Тем не менее, такие захваты всегда будут представлять собой наилучшие показатели производительности, которые пользователь увидит, а не то, что они могут фактически увидеть после длительных игровых сессий. Эта стратегия также может задержать время между запусками профилирования из-за необходимости сначала дождаться периода охлаждения.

С некоторым оборудованием вы можете зафиксировать тактовую частоту для более стабильных показателей производительности. Тем не менее, это не является представительным для большинства устройств, которые будут использовать ваши пользователи, и не будет сообщать точную реальную производительность. В основном, это удобная техника, если вы используете настройку непрерывной интеграции для проверки изменений производительности в вашей кодовой базе с течением времени.

Есть ли мысли о Vulkan против OpenGL ES 3 на Android? Vulkan, как правило, медленнее с точки зрения производительности. В то же время многие устройства не поддерживают различные функции на ES3.

Arm: Недавние драйверы и сборки движков значительно улучшили качество доступных реализаций Vulkan; поэтому для эквивалентной нагрузки не должно быть разрыва в производительности между OpenGL ES и Vulkan (если он есть, пожалуйста, дайте нам знать). Переход на Vulkan набирает скорость, и мы ожидаем, что все больше людей будут выбирать Vulkan по умолчанию в течение следующего года или двух. Если у вас есть контрпримеры областей, где Vulkan не работает хорошо, пожалуйста, свяжитесь с нами. Нам было бы приятно услышать от вас.

Какие инструменты мы можем использовать для мониторинга пропускной способности памяти (RAM <-> VRAM)?

Arm: Профайлер Streamline в Arm Mobile Studio может измерять пропускную способность между графическими процессорами Mali и внешней DRAM (или системным кэшем).

Следует ли разделять графические активы по уровням устройств или разрешению устройств?

Arm: Вы можете получить наилучший результат, перенастраивая активы, но это дорого. Начните с уменьшения разрешения и частоты кадров или отключения некоторых необязательных эффектов постобработки.

Какой лучший способ записывать статистику производительности из нашей сборки разработки?

Arm: Вы можете использовать инструмент Performance Advisor в Arm Mobile Studio, чтобы автоматически захватывать и экспортировать показатели производительности из Mali GPU, хотя это имеет свои ограничения: Генерация JSON отчетов требует лицензии Professional Edition.

Unity: Профайлер Unity можно использовать для просмотра общих метрик рендеринга, таких как количество вершин и треугольников в модуле рендеринга. Кроме того, вы можете включить пользовательские пакеты, такие как System Metrics Mali, в ваш проект, чтобы добавить низкоуровневые метрики Mali GPU в профайлер Unity.

Каковы ваши рекомендации по профилированию кода шейдеров?

Вам нужен профайлер GPU для этого. Выбор зависит от вашей целевой платформы. Например, на устройствах iOS профайлер GPU Xcode включает в себя Профайлер шейдеров, который разбивает производительность шейдеров по строкам.

Arm Mobile Studio поддерживает Mali Offline Compiler, инструмент статического анализа для кода шейдеров и вычислительных ядер. Этот инструмент предоставляет общие оценки производительности и рекомендации для семейства GPU Arm Mali.

При профилировании общее правило заключается в том, чтобы тестировать вашу игру или приложение на целевом устройстве(ях). С учетом того, что индустрия движется к большему количеству типов чипсетов (Apple M1, Arm, x86 от Intel, AMD и т.д.), как разработчики могут профилировать и выявлять проблемы на многих различных аппаратных конфигурациях в разумные сроки?

Распространение чипсетов в первую очередь является проблемой на настольных платформах. Существует ограниченное количество аппаратных архитектур для тестирования консольных игр. На мобильных устройствах есть серия A от Apple для устройств iOS и ряд архитектур Arm и Qualcomm для Android – но выбрать управляемый список представительных мобильных устройств довольно просто.

На настольных ПК это сложнее, потому что существует широкий спектр доступных чипсетов и архитектур, а покупка Mac и ПК для тестирования может быть дорогой. Наш лучший совет – делать то, что вы можете. Ни одна студия не имеет бесконечного времени и денег на тестирование. Мы обычно не ожидаем никаких больших сюрпризов при сравнении производительности между процессором Intel x86 и аналогичным процессором AMD, например. Пока игра работает комфортно на вашем минимальном специфицированном компьютере, вы можете быть разумно уверены в других машинах. Также стоит рассмотреть возможность использования аналитики, такой как Unity Analytics, для записи частоты кадров, системных характеристик и настроек опций игрока, чтобы выявить проблемные места или конфигурации.

Мы видим, что все больше студий переходят на использование хотя бы некоторого уровня автоматизированного тестирования для регулярного профилирования на устройстве, с опубликованными сводными статистическими данными, которые вся команда может отслеживать для оценки производительности на различных целевых устройствах. С хорошо спроектированными тестовыми сценами это обычно можно превратить в механический процесс, подходящий для автоматизации, так что вам не нужен опытный технический художник или тестировщик QA, который вручную проводит сборки через процесс.

Вы когда-нибудь видите проблемы с производительностью на высококлассных устройствах, которые не возникают на низкоклассных?

Это редко, но мы это видели. Часто проблема заключается в том, как проект настроен, например, с использованием сложных шейдеров и текстур высокого разрешения на высококлассных устройствах, что может создавать дополнительную нагрузку на GPU или память. Иногда высококлассное мобильное устройство или консоль будет использовать экран телефона высокого разрешения или 4K TV вывод в качестве точки продажи, но не обязательно иметь достаточно мощности GPU или памяти, чтобы соответствовать этому обещанию без дальнейшей оптимизации.

Если вы используете текущие версии системы задач C#, проверьте, есть ли накладные расходы на планирование задач, которые увеличиваются с количеством рабочих потоков, которые, в свою очередь, увеличиваются с количеством ядер CPU. Это может привести к коду, который работает медленнее на Threadripper™ с 64+ ядрами, чем на скромном 4-ядерном или 8-ядерном CPU. Эта проблема будет решена в будущих версиях Unity, но в то же время попробуйте ограничить количество рабочих потоков задач, установив JobsUtility.JobWorkerCount.

Какие советы по установке хорошего бюджета кадров?

Большую часть времени, когда мы говорим о бюджетах кадров, мы говорим о общем временном бюджете для кадра. Вы рассчитываете 1000/целевые кадры в секунду (fps), чтобы получить ваш бюджет кадров: 33.33 мс для 30 fps, 16.66 мс для 60 fps, 8.33 мс для 120 Гц и т.д. Сократите это число примерно на 35%, если вы на мобильном устройстве, чтобы дать чипам возможность остыть между каждым кадром. Разделение бюджета для получения конкретных подбюджетов для различных функций и/или систем, вероятно, является избыточным, за исключением проектов с очень специфическими, предсказуемыми системами или тех, которые активно используют Time Slicing.

В общем, профилирование – это процесс нахождения самых больших узких мест – и, следовательно, самых больших потенциальных приростов производительности. Поэтому, вместо того чтобы сказать: «Физика занимает 1,2 мс, когда бюджет позволяет только 1 мс», вы можете посмотреть на кадр и сказать: «Рендеринг занимает 6 мс, что делает его самой большой затратой ЦП основного потока в кадре." Как мы можем это уменьшить?

Кажется, что профилирование рано и часто все еще не является общим знанием. Каковы ваши мысли о том, почему это может быть так?

Создание, выпуск, продвижение и управление игрой - это сложная работа на нескольких фронтах. Поэтому всегда будет множество приоритетов, борющихся за внимание разработчика, и профилирование может оказаться на обочине. Они знают, что это то, что они должны делать, но, возможно, они не знакомы с инструментами и не чувствуют, что у них есть время учиться. Или они не знают, как вписать профилирование в свои рабочие процессы, потому что их подталкивают к завершению функций, а не к оптимизации производительности.

Так же, как и с ошибками и техническим долгом, проблемы с производительностью дешевле и менее рискованно решать на ранних стадиях, а не позже в цикле разработки проекта. Наше внимание сосредоточено на том, чтобы помочь развеять мифы о инструментах и техниках профилирования для тех разработчиков, которые с ними не знакомы. Вот что поддерживает профилирование электронная книга и связанные с ней пост в блоге и вебинар.

Существует ли способ исключить определенные методы из инструментирования или включить только конкретные методы при использовании глубокого профилирования в профайлере Unity? При использовании большого количества задач async/await мы создаем большие трассировки стека, но как мы можем избежать замедления как клиента, так и профайлера при глубоком профилировании?

Вы можете включить Стек вызовов выделения, чтобы увидеть полные стеки вызовов, которые приводят к управляемым выделениям (показанным как пурпурный в представлении временной шкалы профайлера ЦП Unity). Кроме того, вы можете - и должны! - вручную инструментировать длительные методы и процессы, добавляя Маркировки профайлера по всему вашему коду. В настоящее время нет способа автоматически включить глубокое профилирование или полностью отключить профилирование в определенных частях вашего приложения. Но ручное добавление Маркировок профайлера и включение стеков вызовов выделения, когда это необходимо, может помочь вам углубиться в проблемные области, не прибегая к глубокому профилированию.

С версии Unity 2022.2 вы также можете использовать наш IgnoredByDeepProfilerAttribute, чтобы предотвратить захват вызовов методов профайлером Unity. Просто добавьте атрибут IgnoredByDeepProfiler к классам, структурам и методам.

Где я могу найти больше информации о глубоком профилировании в Unity?

Глубокое профилирование описано в нашей документации по профилировщику. Затем есть самый подробный, единый ресурс для информации о профилировании, Ультимативное руководство по профилированию игр на Unity в формате электронной книги, которое ссылается на соответствующую документацию и другие ресурсы.

Правильно ли, что глубокое профилирование полезно только для профилировщика аллокаций и что оно искажает результаты настолько, что не полезно для поиска задержек в игре?

Глубокое профилирование можно использовать для нахождения конкретных причин управляемых аллокаций, хотя стеки вызовов аллокаций могут делать то же самое с меньшими накладными расходами в целом. В то же время глубокое профилирование может быть полезным для быстрого расследования, почему один конкретный ProfilerMarker, кажется, занимает так много времени, так как его удобнее включить, чем добавлять множество ProfilerMarkers в ваши скрипты и пересобирать вашу игру. Но да, оно действительно сильно искажает производительность, поэтому его не следует включать для общего профилирования.

Стоит ли устанавливать VSync на каждый VBlank?} Моя мобильная игра работает на очень низком fps, когда он отключен.

Мобильные устройства заставляют VSync быть включенным на уровне драйвера/аппаратного обеспечения, поэтому отключение его в настройках качества Unity не должно иметь значения на этих платформах. Мы не слышали о случаях, когда отключение VSync негативно сказывалось на производительности. Попробуйте сделать захват профиля с включенным VSync, а также другой захват той же сцены, но с отключенным VSync. Затем сравните захваты, используя Анализатор профилей, чтобы попытаться понять, почему производительность так отличается.

Как можно определить, ждет ли основной поток GPU, а не наоборот?

Это описано в Ультимативном руководстве по профилированию игр на Unity. Вы также можете получить больше информации в блоге, Обнаружение узких мест производительности с помощью менеджера временных кадров Unity.

Говоря в общем, явным признаком является то, что основной поток ждет поток рендеринга, в то время как поток рендеринга ждет GPU. Конкретные имена маркеров будут отличаться в зависимости от вашей целевой платформы и графического API, но вам следует обратить внимание на маркеры с такими именами, как "PresentFrame" или "WaitForPresent."

Существует ли надежный процесс для поиска утечек памяти в профилировании?

Используйте Профилировщик памяти, чтобы сравнить снимки памяти и проверить на утечки. Например, вы можете сделать снимок в главном меню, войти в свою игру, а затем выйти, вернуться в главное меню и сделать второй снимок. Сравнение этих двух покажет вам, остались ли какие-либо объекты/выделения из игры в памяти.

Имеет ли смысл оптимизировать и переписывать часть кода для системы DOTS, для мобильных устройств, включая VR/AR? Вы используете эту систему в своих проектах?

Некоторые игровые проекты теперь используют части Data-Oriented Technology Stack (DOTS). Native Containers, C# Job System, Mathematics и Burst compiler — это полностью поддерживаемые пакеты, которые вы можете использовать прямо сейчас для написания оптимального, параллельного, высокопроизводительного кода C# (HPC#), чтобы улучшить производительность ЦП вашего проекта.

Меньшее количество проектов также использует Entities и связанные пакеты, такие как Hybrid Renderer, Unity Physics и NetCode. Однако в настоящее время перечисленные пакеты являются экспериментальными, и их использование связано с определенной степенью технического риска. Этот риск возникает из-за API, который все еще развивается, отсутствующих или неполных функций, а также кривой обучения в инженерии, необходимой для понимания Data-Oriented Design (DOD), чтобы извлечь максимальную пользу из системы компонентов сущностей (ECS) Unity. Инженер Unity Стив МакГриал написал руководство по лучшим практикам DOTS, которое включает некоторые основы DOD и советы по улучшению производительности ECS.

Как вы устанавливаете ограничения на вызовы SetPass или сложность шейдеров? Можете ли вы даже установить ограничения заранее?

Рендеринг — это сложный процесс, и нет практического способа установить жесткое ограничение на максимальное количество вызовов SetPass или метрику для сложности шейдеров. Даже на фиксированной аппаратной платформе, такой как одна консоль, ограничения будут зависеть от того, какую сцену вы хотите отрендерить, и какой другой работы происходит на ЦП и ГП во время кадра.

Вот почему правило, когда профилировать, — «рано и часто». Команды, как правило, создают демонстрацию «вертикального среза» на раннем этапе производства — обычно это короткий всплеск игрового процесса, разработанный до уровня визуальной достоверности, предусмотренного для финальной игры. Это ваша первая возможность профилировать рендеринг и выяснить, какие оптимизации и ограничения могут понадобиться. Процесс профилирования следует повторять каждый раз, когда добавляется новая область или другой крупный элемент визуального контента.

Вот дополнительные ресурсы для изучения оптимизации производительности:

Блоги

• Оптимизация производительности вашей мобильной игры: Советы экспертов по графике и активам
• Оптимизация производительности вашей мобильной игры: Советы экспертов по физике, пользовательскому интерфейсу и настройкам звука
• Оптимизация производительности вашей мобильной игры: Советы экспертов по профилированию, памяти и архитектуре кода от лучших инженеров Unity
• Советы экспертов по оптимизации графики вашей игры для консолей
• Профилирование в Unity 2021 LTS: Что, когда и как

Страницы с инструкциями

• Инструменты профилирования и отладки
• Как профилировать память в Unity
• Лучшие практики для профилирования производительности игр

Электронные книги

• Оптимизация производительности игр для консолей и ПК
• Оптимизация производительности вашей мобильной игры
• Полное руководство по профилированию игр в Unity

Учебные пособия

• Профилирование производительности ЦП в сборках Android с помощью Android Studio
• Профилирование приложений – Сделано с Unity

Скоро появится еще более продвинутый технический контент – а пока, пожалуйста, не стесняйтесь предлагать темы для обсуждения на форуме и посмотрите запись полного вебинара.