Базовый процесс оптимизации для приложений Meta Quest
Обновлено: 9 дек 2024 г.
В этом разделе описан базовый процесс оптимизации, в котором используется профилирование для выявления узких мест и проблем в сборках приложений для разработки.
Вопросы оптимизации часто подразумевают исключительно количество кадров в секунду (FPS), однако более точной метрикой, на которую стоит обратить внимание при оптимизации приложений, может быть количество миллисекунд на кадр. Измерение длительности каждого кадра в миллисекундах позволяет достичь более конкретной цели. Чтобы достичь определенной частоты кадров, каждый кадр должен завершить работу ЦП и графического процессора за определенное время, которое обычно измеряется в миллисекундах.
Если в качестве метрики используется количество миллисекунд на кадр, у каждого кадра есть требование относительно ресурсов (т. е. определенное время, в которое он должен уложиться). Целевые показатели производительности для соответствующих частот кадров выглядят следующим образом:
- 60 FPS = 16,6 мс/кадр;
- 72 FPS = 13,9 мс/кадр;
- 90 FPS = 11,1 мс/кадр;
- 120 FPS = 8,3 мс/кадр.
Все приложения для Meta Quest должны поддерживать частоту не менее 72 FPS, чтобы пройти проверку виртуальной реальности (VRC). Meta Quest 3 и Meta Quest 3S также поддерживают частоту обновления дисплея 90 Гц и 120 Гц, что соответствует указанным выше бюджетам кадров — 90 FPS и 120 FPS. В следующем разделе этого руководства показано, как профилирование может помочь вам достичь целевой частоты кадров за счет выявления областей для оптимизации.
Рабочий процесс профилирования
При профилировании в этом рабочем процессе первая цель — выяснить, привязано ли приложение к графическому (ГП) или к центральному процессору (ЦП). Простой способ сделать это — ничего не рендерить. Просто отключите камеру рендеринга и дайте приложению продолжать работу. Это избавит вас от затрат на конвейер рендеринга, в том числе на отбрасывание, отправку вызовов отрисовки, запуск шейдеров и т. д. Следите за частотой кадров приложения и за тем, сколько миллисекунд необходимо для завершения каждого кадра.
Закончив тестирование, посмотрите на результаты и определитесь:
- если производительность приложения, когда оно ничего не рендерит, не меняется или меняется очень незначительно, то, скорее всего, приложение привязано к ЦП;
- если производительность значительно увеличивается, то, скорее всего, приложение привязано к ГП.
Решение проблем с приложениями, привязанными к центральному процессору
К общим причинам, по которым приложение может быть привязано к ЦП, относятся сложность логики приложения и моделирования физики, задержки сборки мусора и т. д. Отследить причины снижения производительности может инструментальный профилировщик, например Unity Profiler. Сосредоточьтесь на оптимизации только самых затратных участков кода. Любую логику приложения, отнимающую более двух миллисекунд, скорее всего, можно оптимизировать.
Решение проблем для приложений, привязанных к ГП
Обычно приложения, привязанные к ГП, делятся на две категории:
- приложения с привязкой к вершинам имеют проблемы со сложностью сцен;
- приложения с привязкой к фрагментам имеют проблемы со сложностью шейдеров.
Способ проверить это — отрисовать меньшее количество пикселей. Это можно сделать, выбрав небольшой масштаб рендеринга приложения, например 0,01. Это приведет к рендерингу меньшего количества фрагментов, но сохранит сложность сцены.
Закончив тестирование, посмотрите на результаты и определитесь:
- если производительность не изменилась, приложение, скорее всего, привязано к вершинам;
- если производительность повышается, приложение, скорее всего, привязано к фрагментам (также называется привязкой к заливке).
Метод, используемый для определения привязки приложения к ЦП или ГП (отключение всех камер рендеринга), означает, что некоторые вычисления на стороне ЦП, такие как отбрасывание фрагментов, считаются операциями, привязанными к вершинам. Хотя это не совсем точно, эти операции часто оптимизируются так же, как привязанные к вершинам приложения. Наиболее распространенные проблемы для приложений с привязкой к вершинам:
- отбрасывание объектов занимает слишком много времени;
- выполняется слишком много вызовов отрисовки;
- отрисовывается слишком много вершин.
Чтобы выявить эти узкие места, используйте в той части приложения, где имеются проблемы, отладчик кадров, например
RenderDoc для Oculus. Зачастую решить эти проблемы можно упрощением сложной геометрии и уменьшением количества вызовов отрисовки. В зависимости от ситуации вам может понадобиться система LOD или пакетная обработка вызовов отрисовки.
Если приложение привязано к заливке, оптимизировать нужно один или несколько его шейдеров. В большинстве случаев основная проблема для шейдеров, привязанных к заливке, — пиксельная сложность.
Используйте полученные результаты для решения основной проблемы, выявленной в рабочем процессе. Профилирование и оптимизация — это итерационный процесс. В большинстве случаев устранение одной проблемы не приведет к достижению желаемого уровня производительности. Чтобы достичь желаемой производительности, обычно требуется несколько раундов оптимизации. Каждый раз после оптимизации проходите весь рабочий процесс заново. Если сначала приложение было привязано к ЦП, то после оптимизации оно может оказаться привязанным к фрагментам.