Russian Qt Forum

Добрый день

Сейчас в приложении используется один GLSL шейдер "на все случаи жизни", который давно превратился в монстра и работает медленно. Основной метод ускорения в GLSL - разбивка большого шейдера на более мелкие. При этом неважно что из большого шейдера активно только, к примеру, 10% кода, он все равно остается медленным, неактивный код все равно потребляет ресурсы GPU (до сих пор не могу у этому привыкнуть).

Сама по себе разбивка трудностей не вызывает. Упрощенный пример: объект имеет текстуры - генерим для него один шейдер, не имеет - другой. Объект должен рисоваться wireframe - третий, с "заливкой" (phong) - четвертый и.т.д. Хотя реально этих вариантов больше, но общее число шейдеров остается небольшим, в пределах десятков, если, конечно неиспользуемые шейдеры будут удаляться, а созданные юзаться 2-мя и более объектами. Вроде обычная логика "шаред", но не соображу как это оформить.

Вот все случаи когда для объекта нужно сменить шейдер - сгенерить новый (если такого еще нет) и/или
удалить старый если нет больше объектов его использующих

1) Юзер может создать/удалить объект
2) Юзер может изменить опции самого объекта (напр назначить или убрать текстуру)
3) Юзер может открыть/закрыть каждое окно в котором рисуется объект, или изменить опции окна. Напр в одном окне объект должен рисоваться только wireframe, в другом - только с заливкой, а в третьем юзер решает как.

Как же мне построить такую мапу (или несколько)?

Спасибо

Фантастическая активность :) Ладно, попробуем с др стороны. Обычная схема: eсть "клиент" - объект который использует шейдер.

C++ (Qt)
typedef QMap<MyObject *, QSharedPointer<Shader> > TShaderMap;
 

Недостаток в том что оказывается очень хлопотно отслеживать эту мапу. Клиент может быть удален или "пересесть" на др шейдер, или использовать еще шейдер(ы). Заботиться обо всем этом в десятках (или даже сотнях) мест явно не хочется.

В принципе вариант "максимум 100 (или др число) шейдеров" (простецкий LRU) вполне бы устроил. Если грохнули какой-то шейдер - не беда, его всегда можно опять создать, главное чтобы это не случалось при каждом рисовании. Но не с потолка же брать это 100. Итак что есть на руках

- MyObject * известен на момент рисования (ID имеется)
- Начало и конец рисования в данном окне (вот правда окон много)
- Ну и конечно "ключ" шейдера (по которому он ищется/создается)

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

Вы говорили, что у вас есть некий менеджер шейдеров, можно ему доверить хранить все программы.
Пусть объект обладает методом, который будет возвращать флаги, на основании которых можно подобрать нужный шейдер.
Допустим типа flags = Phong | Textures. Менеджер вам прикрутит необходимую для данного объекта программу.
Кстати, удобно будет хранить в члене менеджера типа QMap соотношение флагов и шейдеров.

Я как-то так это вижу.

Потому что число материалов (т.е. вариантов) не фиксировано, юзер может их свободно создавать/удалять.

Там флажков уже десятка 2 набралось :) Напр сколько текстур (от 0 до 8 ). Как мапятся текстуры (от 0 до 5) и.т.д.

Ничего страшного, int вмещает 32 флажка. Можно и bitset задействовать при необходимости.

Я не работал плотно с текстурами. Примеры из книги предлагали использовать одну программу для наложения нескольких текстур. А что у вас под этими цифрами 0..8, 0..5?

0..7 число используемых текстур (и соответственно самплеров). Не все операции с текстурами можно уложить в for. А 0..5 как мапятся. Напр кубик карта солидный кусок кода который нужен редко. Ну и вообще с "материалом" (хоть и без текстур) стоит только начать - польется сразу. Это только в книге маленький ошметок  :)