С точки зрения производительности код Disaurde был примером того, как не стоит писать шейдеры. Приложение состояло из одного файла на 2000 строк. В них было смешано всё: и логика на Java Script, и интерфейс, и шейдинг на языке GLSL. Но главной проблемой была не громоздкость кода, а его неправильная структура.
Худшее, что можно было придумать, это начать писать GLSL-шейдеры как JS-код, с множеством условных операторов и циклов. Именно так я и сделал, не понимая насколько отличаются эти языки. В результате все блоки с эффектами были объединены в один общий шейдер, который состоял из бесконечных
if (mode == 1.0)... if (mode == 2.0)... Шейдерные вычисления устроены таким образом, что «скорость армии определяется скоростью самого медленного солдата». Это значит, что пока какой-то поток GPU-вычислений погружается в условия и циклы, остальные потоки простаивают без дела. Условно говоря, все пиксели изображения ждут, пока обработается какой-то самый сложный пиксель.
Чтобы приложение работало быстрее, мне пришлось минимизировать шейдерный код. Все условия по выбору и активации эффектов были вынесены из шейдинга в JS-часть программы. Там они выполнялись только один раз, при компиляции фильтра, а не в каждом кадре.
Таким образом, при создании эффектов JS-функция брала нужные блоки GLSL-кода и склеивала из них компактный шейдер без ответвлений. На профессиональном уровне для этих же целей используются директивы вроде
#IFDEF . Конечная цель таких оптимизаций — сразу указать видеокарте «где копать, а где не копать», чтобы не замедлять ее размышлениями об условиях работы.Изображения сняты через фильтры:
[micima, mamu] - «Enough to write two words»
[mima] - «Catching the distance»
[mimamumi] - «Ototolycus sylvestris»
[mima(di)mu] - «Horse maggot watch cover»
▹ Disaurde v303 — приложение, в котором сделаны эти снимки.