А блендить как будешь?

Красный с зелёным через цвет детской неожиданности? :)

я буду работать с текстурой 11 11 10, а потом в конце её на экран выводить с коррекцией постпроцессом

А, с флоатами sRGB и не надо, у них же распределение и так ведёт себя примерно, как sRGB

Для тёмных куча точности, при приближении к 0 падает экспонента, а для мантиссы остаётся столько же бит

11.11.10 sRGB формата и не бывает

8.8.8 только на запись

Не совсем, там довольно заметное отличие если график построить, но хз как на глаз, это раз, а во-вторых хз как загнать это в обычный rgba8 экранный по хитрому, потому делаю постпроцессом честную гамма-коррекцию

Тонмаппинг, кстати, даёт результат уже в гамме, а не линейный

Это как?

Гамма-коррекция с флоатом для промежуточных результатов не нужна, она нужна, чтобы в 8 бит впихнуть на глаз тёмные цвета

Чтобы у unorm было перцептуально,а не линейно однородное распределение значений

Ну это понятно мне надо чтобы на экране это было нормально выведено

// asin pow2.71 80
// sin log 200
// mod smoothstep 300
// sign sqrt fract mix step 400
// inversesqrt * / pow2 floor ceil min max clamp degrees radians 600
// abs 800

float w=0.0;
for(int i=0;i<LIMIT;i++){
 w=OPERATION(w-0.001);
}

Сколько раз операцию можно повторить в пиксельном шейдере, при рендере 512*512, чтобы fps=30 на мобилке, mali 400

Оказывается компилятор для glsl весьма умен и умеет делать оптимизации где можно, например pow(x,2.0)

И оказывается что все функции весьма быстрые. Нет ничего что отличалось бы по скорости более чем в 10 раз, что радует.

Некоторые вещи неочевидно что отличаются по скорости типа sin VS asin, sqrt VS inversesqrt

Если просто блитить флоаты на экран получится не верно

Кривая там мапит из яркости света в значения, которые приятны глазу

"приятны глазу" звучит как вкусовщина

Компилятор в каждом драйвере свой == не можешь полагаться ни на какие подобные оптимизации

Filmic всякие это и есть вкусовщина, и настраиваются параметры художниками

ну, да

но как rule of thumb пойдет