Организация шейдеров GLSL в движке OpenGL - PullRequest
Новая
       4

Организация шейдеров GLSL в движке OpenGL

35 голосов
/ 10 января 2011

Что лучше?

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

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

Ответы [ 3 ]

28 голосов
/ 10 января 2011

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

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

15 голосов
/ 10 января 2011

Как правило, вариант 2 будет быстрее / лучше, если у вас действительно огромное количество программ.Вы также можете использовать буферные объекты, совместно используемые программами, так что вам не нужно сбрасывать какие-либо значения при смене программ.

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

0 голосов
/ 14 августа 2016

Я склонен полагать, что это зависит от конкретного применения.И да, так как было бы более эффективно, скажем, запустить 100 программ, в каждой из которых может быть по 2-16 форм;может быть лучше иметь компромисс между двумя.Я склонен думать, что, скажем, 10-20 программ для ваших самых распространенных методов затенения будет достаточно или даже несколько.Например, вы можете захотеть иметь одну программу / шейдер для выполнения всех ваших рельефных карт, одну для всех эффектов тумана, одну для отражения, одну для преломления.

Теперь, выходя за рамки вашего вопроса, я думаю, что это также относится и к этому, одна вещь, которую нужно включить в ваш движок, это настройка класса BatchProcess & BatchManager, чтобы уменьшить количество вызовов CPU - GPU по шине, так какэто также оказалось бы эффективным.Я не думаю, что существует 1 подходящее решение для вашего вопроса, так как я считаю, что это будет зависеть от конкретного приложения, так же как и установление отношения между тем, сколько пакетов (сегментов) вершин (примитивов) будет иметь ваш движок, и скольковершины каждая из этих партий будет содержать.

Чтобы попытаться прояснить ситуацию: в одной игре может быть 4 контейнера или партии, в которых каждая партия может содержать до 10 000 вершин, которые должны считаться заполненными до того, как BatchManager решит очистить эту корзину, отправив всете вершины на видеокарту для конвейера рендеринга, которые нужно обработать и нарисовать, когда в другой игре может быть 10 блоков с 5000 вершин, или в другой игре может быть 8 блоков с 12,0000 вершин.

Так что может быть компромисс между попыткой объединить их в соответствии с вашими потребностями.Если у вас есть 1 программа с сотнями униформ;Одной программой легче управлять внутри конвейера, но шейдеры будут слишком громоздкими для чтения и управления.С другой стороны, иметь шейдеры с очень небольшим количеством униформ довольно легко для чтения и управления, но с сотнями программ управлять процессором немного сложнее, чем связывать и отправлять их для правильной визуализации.Лично я бы попытался найти золотую середину, чтобы у меня было достаточно программ для выполнения каждой конкретной задачи, которая абсолютно уникальна, например, создание плотности тумана на одной и объемное отображение теней на другой, где у каждой программы достаточно всего лишь униформ для выполнения.требуемые расчеты.

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

...