Отдельные этапы программы OpenGL

Я изучаю относительно новую функцию GL_ARB_separate_program_object. Я понимаю, что мне нужно создать объект конвейера, который должен содержать шейдеры из этапов, которые отображаются там через glUseProgramStages.

Это заставляет меня задуматься о двух возможностях использования нескольких шейдеров:

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

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

glUseProgramStages

Меня больше всего беспокоит производительность. Какой вариант более эффективен?


graphics opengl opengl-4
person Michael IV    schedule 07.04.2013    source источник
comment
Вы оба измерили? Кроме того, я думаю, вы должны хранить объекты Pipeline, потому что они относительно дешевы, не так ли?   -  person Bartek Banachewicz    schedule 07.04.2013
comment
Я внедрил сегодня эту систему и не вижу снижения производительности. Но нужно посмотреть, влияет ли частое обновление объектов конвейера.   -  person Michael IV    schedule 08.04.2013

Ответы (1)


arrow_upward
2
arrow_downward

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

EXT_separate_shader_objects был первым воплощением этой функциональности. Самая большая разница между ними заключалась в следующем: вы не могли использовать пользовательские варианты с версией EXT. Вы должны были использовать старые входы/выходы совместимости, такие как gl_TexCoord.

Ошибка №2 в спецификации EXT_separate_shader_objects попытка оправдать это непонятное надзоробъясняет это следующим образом:

С точки зрения производительности нежелательно пытаться поддерживать «рандеву по имени» для произвольных отдельных шейдеров, потому что отдельные шейдеры не будут естественным образом скомпилированы для сопоставления их различных входных и выходных данных с одинаковыми именами без специального шага связывания. Такая специальная ссылка привела бы к дополнительным затратам на проверку привязки отдельных шейдеров. Сама ссылка должна быть отложена до времени glBegin, поскольку отдельные шейдеры не будут совпадать при переходе от одного набора согласованных шейдеров к другому. Эта специальная ссылка по-прежнему будет создавать ошибки или неопределенное поведение, когда имена входных и выходных переменных совпадают, но их типы не совпадают.

Это говорит о том, что причина не полагаться на сопоставление имен, помимо некомпетентности, была связана с производительностью (если вы не можете сказать, я не очень высокого мнения о EXT_SSO). Производительность «рандеву по имени» зависит от необходимости делать это при каждом вызове отрисовки, а не от возможности сделать это один раз.

ARB_separate_shader_objects инкапсулирует набор программ в объект. Следовательно, объект может хранить все данные о «рандеву». Первый вызов отрисовки может быть медленнее, но последующие использования того же PPO будут быстрыми, если вы не присоедините к нему новые программы.

Поэтому я бы воспринял это как свидетельство того, что на PPO должны быть установлены программы, а затем оставлены в покое. В общем, по возможности следует избегать изменения объектов вложений. Вот почему вам рекомендуется не добавлять и не удалять текстуры/рендербуферы из FBO.

person Nicol Bolas    schedule 07.04.2013
comment
Итак, простыми словами вы говорите - создавайте столько конвейеров, сколько вам нужно, и переключайтесь между ними вместо того, чтобы менять их каждый раз, когда требуется новая комбинация шейдеров. Вы это имеете в виду? - person Michael IV; 07.04.2013