GLSL множественные шейдерпрограммы VS форменные переключатели - PullRequest
Новая
       7

GLSL множественные шейдерпрограммы VS форменные переключатели

38 голосов
/ 30 июня 2011

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

1.Для каждой программы шейдера материала

=> Создать одну программу шейдера для материала, используемого в программе.

Потенциальные минусы:

  • Учитывая, что каждый объект может иметь свой собственный материал, он включаетмного вызовов glUseProgram.
  • Подразумевает создание большого количества объектов шейдерной программы.
  • Более сложная архитектура, чем у # 2.

Плюсы:

  • Код шейдера может быть сгенерирован специально для каждой «опции», используемой в материале.
  • Если я не ошибаюсь, униформу нужно задавать только один раз (при создании программы шейдера).

2.Глобальные шейдерные программы

=> Создайте одну шейдерную программу для каждой функции шейдера (молния, отражение, отображение параллакса ...) и используйте переменные конфигурации, чтобы включить или отменить параметры в зависимости от материала для рендеринга.

Потенциальные недостатки:

  • Униформы нужно менять много раз за кадр.

Плюсы:

  • Меньшее количество программ шейдеров.
  • Меньше SP swich (glUseProgram).

Возможно, вы заметили, что моя текущая тенденция - № 1, но я хотел бы узнать ваше мнение об этом.

  • Смещает ли начальная настройка униформ накладные расходы при вызове glUseProgram (я не особенно фанат скорости)?
  • В случае № 1, для любой памяти или производительности, я должен вызывать glLinkProgram только один раз, когда я создаю SP, или я должен отсоединять / связывать каждый раз, когда я вызываю glUseProgram?
  • Есть лилучшие решения?

Спасибо!

Ответы [ 3 ]

11 голосов
/ 01 июля 2011

Давайте посмотрим на # 1:

Учитывая, что каждый объект может иметь свой собственный материал, он включает в себя множество вызовов glUseProgram.

Это не так уж многосделки, правда.Менять программы сложно, но вы бы тоже поменялись текстурами, так что это не значит, что вы еще не меняете важное состояние.

Предполагается создание большого количества объектов шейдерной программы.

Это будет больно.Действительно, главная проблема с # 1 - взрывная комбинация шейдеров.Хотя ARB_separate_program_objects поможет, это все равно означает, что вам нужно написать много шейдеров или придумать способ не писать много шейдеров.

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

Так что я бы сказал, использовать # 1 с отложенным рендерингом.

9 голосов
/ 30 июня 2011

Это действительно зависит от вашего оборудования и конкретных требований вашего приложения.

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

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

Нет лучших решений. Практически каждый, кто пишет движок рендеринга, должен принять решение, с которым вы столкнулись.

1 голос
/ 24 февраля 2013

На мобильных устройствах ветвление в шейдере значительно увеличивает время рендеринга.Вы должны сделать некоторые измерения времени переключения программ по сравнению со сниженной скоростью прорисовки, связанной с ветвлением в повторяющейся операции на вершину / на тексель.Я бы порекомендовал метод # 1 и взглянул на то, как GPUImage настроен на хорошую шейдерную архитектуру.

https://github.com/BradLarson/GPUImage

...