Рекомендации по оптимизации производительности WebGL путем минимизации изменений шейдеров / состояний - PullRequest
3 голосов
/ 23 декабря 2010

Я пытаюсь получить представление о практичности WebGL для рендеринга больших внутренних сцен, состоящих из 100K треугольников. Эти треугольники распределены по многим объектам, и в сцене много материалов. С другой стороны, нет движущихся частей. И материалы, как правило, довольно просты, в основном на основе текстурных карт. Существует много общих текстурных карт, например, все стулья на сцене будут иметь общую карту. Существует также мультитекстурирование - до трех текстур накладываются на материал.

Я немного экспериментировал и читал, и понял, что частое переключение материалов во время прохождения рендеринга замедляет ход событий. Например, сцена с 200K треугольниками будет иметь значительные различия в производительности в зависимости от того, есть ли 10 или 1000 объектов, при условии, что каждый раз, когда объект отображается, устанавливается новый материал.

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

  • Каковы относительные затраты производительности, скажем, gl.useProgram(), gl.uniformMatrix4fv(), gl.drawElements()
  • я должен попытаться написать убершадеры, чтобы минимизировать переключение шейдеров?
  • если я попытаюсь объединить геометрию, чтобы минимизировать количество gl.drawElements() вызовов

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

1 Ответ

3 голосов
/ 05 января 2011

Читали ли вы партия, партия, партия ?Следует признать, что он сфокусирован на DirectX, но рассуждения в меньшей степени относятся и к Open / WebGL: каждый вызов API имеет значительную нагрузку на ЦП.Совет состоит в том, чтобы использовать все параметры API для совместного использования текстур, использовать создание экземпляров (если доступно), писать сложные шейдеры, чтобы избежать множества вызовов отрисовки.Так что если вы можете нарисовать весь дом как одну сетку за один звонок, это будет лучше, чем 1000 звонков для каждой комнаты.Рекомендуется писать ubershaders, но в основном потому, что это может позволить вам удалять вызовы отрисовки, а не потому, что переключение состояния графического процессора стоит дорого.

Это предполагает недавнее оборудование.Для младших платформ (iPad?) Или чипов Intel GMA узкие места будут в другом месте (как в программной обработке вершин).

...