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

FPS и мс/кадр

Вопросы оптимизации часто подразумевают исключительно количество кадров в секунду (FPS), однако более точной метрикой, на которую стоит обратить внимание при оптимизации приложений, может быть количество миллисекунд на кадр. Измерение длительности каждого кадра в миллисекундах позволяет достичь более конкретной цели. Чтобы достичь определенной частоты кадров, каждый кадр должен завершить работу ЦП и графического процессора за определенное время, которое обычно измеряется в миллисекундах.

Если в качестве метрики используется количество миллисекунд на кадр, у каждого кадра есть требование относительно ресурсов (т. е. определенное время, в которое он должен уложиться). Целевые показатели производительности для соответствующих частот кадров выглядят следующим образом:

60 FPS = 16,6 мс/кадр;

72 FPS = 13,7 мс/кадр.

Большинство приложений Meta Quest стремятся использовать 72 FPS. В следующем разделе этого руководства показано, как профилирование может помочь вам достичь целевой производительности 13,7 мс/кадр путем выявления областей для оптимизации.

Рабочий процесс профилирования

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

Закончив тестирование, посмотрите на результаты и определитесь:

если производительность приложения, когда оно ничего не рендерит, не меняется или меняется очень незначительно, то, скорее всего, приложение привязано к ЦП;

если производительность значительно увеличивается, то, скорее всего, приложение привязано к ГП.

Решение проблем для приложений, привязанных к ЦП

Распространенные причины, по которым приложение может быть привязано к ЦП, включают в себя сложность логики приложения и моделирования физики, задержки сборки мусора и т. д. Инструментальный профилировщик, например Unity Profiler, может отследить эти узкие места производительности.

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

Решение проблем для приложений, привязанных к ГП

Обычно приложения, привязанные к ГП, делятся на две категории:

приложения с привязкой к вершинам имеют проблемы со сложностью сцен;

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

Способ проверить это — отрисовать меньшее количество пикселей. Это можно сделать, выбрав небольшой масштаб рендеринга приложения, например 0,01. Это приведет к рендерингу меньшего количества фрагментов, но сохранит сложность сцены.

Закончив тестирование, посмотрите на результаты и определитесь:

если производительность не изменилась, приложение, скорее всего, привязано к вершинам;

если производительность повышается, приложение, скорее всего, привязано к фрагментам (также называется привязкой к заливке).

Примечание.

Привязка к вершинам

Метод, используемый для определения привязки приложения к ЦП или ГП (отключение всех камер рендеринга), означает, что некоторые вычисления на стороне ЦП, такие как отбрасывание фрагментов, считаются операциями, привязанными к вершинам. Хотя это не совсем точно, эти операции часто оптимизируются так же, как привязанные к вершинам приложения. Наиболее распространенные проблемы для приложений с привязкой к вершинам:

отбрасывание объектов занимает слишком много времени;

выполняется слишком много вызовов отрисовки;

отрисовывается слишком много вершин.

Чтобы выявить эти узкие места, используйте в той части приложения, где имеются проблемы, отладчик кадров, например RenderDoc для Oculus. Зачастую решить эти проблемы можно упрощением сложной геометрии и уменьшением количества вызовов отрисовки. В зависимости от ситуации вам может понадобиться система LOD или пакетная обработка вызовов отрисовки.

Привязка к заливке

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

Оптимизация и итерации

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