Войти
ПрограммированиеФорумГрафика

GLSL min, max или if (2 стр)

Страницы: 1 2 3 4 Следующая »
#15
(Правка: 18:11) 18:10, 26 июля 2020

phridrich
> Обе ветки выполнятся если в границах текущего варпа условие неконсистентно (то есть есть и небо и пейзаж). У тебя такое нечасто случается
У меня такое случается постоянно - https://www.youtube.com/watch?v=79SqIC2bNcM
Не думаю что вы видели шейдера сложнее тех, что я использовал в этом ролике. Вопросы производительности шейдеров я изучал не по книжкам, я весь прогресс в этой сфере прочуствовал на своем горбу начиная с 2005 года.
С точки зрения ПРАКТИЧЕСКОГО использования if давно уже не являются узким местом. Самое тяжелое было (и остается) чтение текстур. А с логикой и арифметикой современнеы карты справляются отлично. Нет никакого смысла шлифовать колеса паровоза до микрон, если рельсы щербатые.


#16
21:02, 26 июля 2020

san
> Не думаю что вы видели шейдера сложнее тех, что я использовал в этом ролике.
Ммм, сильно. Ну скинь ссылку на код что ли.
> Вопросы производительности шейдеров я изучал не по книжкам, я весь прогресс в этой сфере прочуствовал на своем горбу начиная с 2005 года.
Тут есть одна проблема - эти вопросы нужно изучать и по книжкам тоже. С методом тыка далеко не уедешь.
> А с логикой и арифметикой современнеы карты справляются отлично.
Ну вставь в шейдер цикл от 0 до 100000 * global thread id X, в теле пропиши инкремент shared переменной. Ну как, справляется твоя карта?

Вообще я не понимаю зачем ты это все написал. Я четко описал в какой ситуации выполняются обе ветки, с чем ты несогласен?

#17
(Правка: 22:22) 21:48, 26 июля 2020

san

Поэтому могу ответственно сказать, что "две ветки" не считаются. Выполняется одна, которая соответствует условию. Не знаю что там на телефонах, возможно они повторяют то, что на картах было 10 лет назад.

Пишем очень тупой шейдер (но чтобы компилятор не смог урезать), рисуем на полный экран, подбираем параметры, чтобы нагрузить свой GPU под завязку:

pload MODELING VISUALIZATION

set aShaderVert "
out vec4 VertColor;
void main() {
  VertColor = occColor;
  gl_Position = occProjectionMatrix * occWorldViewMatrix * occModelWorldMatrix * occVertex;
}"

set aShaderFrag "
in vec4 VertColor;
float getFact(in int theN) {
  float aRes = 2.0;
  for(int i = 1; i <= theN; ++i) {
    aRes *= float(i);
  }
  return aRes;
}
void main() {
  float aRed   = 0.0;
  float aGreen = 0.0;
  if (int (mod (gl_FragCoord.x - 0.5, 2.0)) != 1) // column interlaced
  //if (int (mod (gl_FragCoord.x / 64.0 - 0.5, 2.0)) != 1) { // thick column interlaced
    aRed   = getFact(int(VertColor.r * 100000.0));
  } else {
    aGreen = getFact(int(VertColor.g * 100000.0));
  }
  occFragColor = vec4(aRed, aGreen, 0.0, 1.0);
}" 

# draw a box
box b 1 2 3
vcaps -core -vsync 0
vclear
vinit View1 -w 1920 -h 1080
vaxo
vdisplay -dispMode 1 -mutable b
vfit
vzoom 10
vrotate 0.2 0.0 0.0
vshaderprog b -vert $aShaderVert -frag $aShaderFrag -header "#version 150"
vsetcolor b 0.5 0.5 0.5

На не самом древнем GPU (Radeon RX Vega, на телефон не похож) имеем:
- Условие меняется через пиксель в ряд
  FPS: 6.5
- Условие меняется через 64 пикселя в ряд
  FPS: 12.3
- Комментируем if/else и считаем оба условия (aRed и aGreen)
  FPS: 6.4
- Комментируем также одну ветку
  FPS: 12.9

Явно наблюдается влияние WARP'a, описанное phridrich'ом - когда шейдер заходит в оба условия в рамках одного WARP'a (груп пикселей / вершин), то время увеличивается на вычисление обоих условий; если же условие меняется вне пределов одного WARP'a, то вычисляется только одно из двух условий.

То есть если условие зависит от uniform переменной - то if будет работать почти идеально на современных GPU; если зависит от редко/плавно меняющейся функции - то if будет выполнять оба условия только для небольшого количества WARP'ов, что не особенно страшно; если зависит от какой-то стохастической функции / часто и резко меняющейся - то if будет выполнять условия почти всегда, но за счёт звериной мощности современных GPU это может быть не особенно заметно на фоне других вычислений и других неоптимальных мест в рендерере.

Неужели новые GeForce научили более крутым трюкам с if'ами в WARP'e?

#18
21:55, 26 июля 2020

phridrich
> Тут есть одна проблема - эти вопросы нужно изучать и по книжкам тоже. С методом тыка далеко не уедешь.
Ну я как-то не совсем от сохи. Оптимизацией шейдеров я занимался например когда работал в компании - разработчике VR хедсета. И я там отвечал как раз за разработку шейдера пост-обработки. Временные рамки в VR очень жесткие.  Мы плотно взаимодействовали с командой из AMD которые занимались драйверами, до сих пор нахожусь с ними в дружеских отношениях.

Я не спорю с тобой, я обьясняю автору поста, что if теперь не является узком местом для шейдеров. Ранше - было. Теперь - нет. Ты можешь найти какую-то экономию в доли процента если начнешь как-то пытаться обойти ветвление, но погоды это точно не сделает.

> Ну скинь ссылку на код что ли.
Вообще-то я не только выложил коды 40 шейдеров вроде этого, но и дал возможность юзерам создавать свои собственные фрактальные миры не имея понятия о программировании.
Вот тут лежит аппликация: https://store.steampowered.com/app/1318030/Fractal_Alchemist_VR/
А вот как создаются шейдера: https://www.youtube.com/watch?v=ZNLc_-jIHvw
Шейдера там в открытом доступе. Но поскольку у тебя наверно нет хедсета и жалко платить 25 баксов, то могу кинуть код, но сомневаюсь что тебе это на самом деле нужно. Могу только сказать, что там реализован алгоритм марч-трейсинга и на каждый пиксель делается около 1000 шагов, на каждом из которых вычисляестя довольно сложная формула, в которой еще несколько циклов по 8-12 шагов. Везде if'ы и for'ы. Короче сложнее что-то сложно представить.

#19
14:42, 27 июля 2020

san
Ты конечно молодец, но правее ты от этого не становишься. If может быть серьезной проблемой производительности. Ты мог эту проблему не замечать, но это не значит что ее нет.

> на каждый пиксель делается около 1000 шагов, на каждом из которых вычисляестя довольно сложная формула, в которой еще несколько циклов по 8-12 шагов.
А, ну хоть понятно откуда 30-40 ms. Каждому свое, но я бы не гордился шейдером с таким таймингом.

#20
(Правка: 18:04) 17:27, 27 июля 2020

phridrich
>If может быть серьезной проблемой производительности.
Дай реальный пример где это становится серьезной проблемой.

> А, ну хоть понятно откуда 30-40 ms. Каждому свое, но я бы не гордился шейдером с таким таймингом.
Ты можешь сделать быстрее? Отлично. Вот тут лежит код шейдера: 3D фрактал шейдер
который формирует такую картинку:
test | GLSL min, max или if
Сам шейдер лежит в файле Fractal/ComputShader.hlsl, освещение - Render.hlsl, формула - Fractal/Algorithm.hlsl
Обрати внимание на обилие ифов. Попробуй соптимизировать.

#21
17:53, 27 июля 2020

san
> Дай реальный пример где это становится серьезной проблемой.
Я всё еще жду от него случай, когда компилятор не оптимизирует if в min/max и произойдёт то, чего он сам не понимает.

#22
(Правка: 21:02) 20:32, 28 июля 2020

san
> Дай реальный пример где это становится серьезной проблемой.

float p = ...;
uint s = ...;
for (uint i = 0; i < s; ++i)
    p *= p;

//-———————

float p = ...;
[unroll(1600)]
for (uint i = 0; i < 1600; ++i)
    p *= p;

1600 - потому что брал за s ширину окна. Запускал на каждый тред на 1600x900, размер группы - 16x16. Первый вариант выполняется 1400 мкс, второй - 600 мкс (мерял в RGP). Видеокарта - 5700 XT.

> Ты можешь сделать быстрее?
Дело не в том, могу ли я сделать быстрее. Продукт твой, и за качеством должен был следить ты. 30-40 ms - это не качественно.
А я, даже если и мог бы ускорить - никак не смогу запустить и проверить/подебажить, надеюсь ты это реально понимаешь а не начнешь приплясывать как АкронимЛета будто я типа слился. По коду первое что в бросилось глаза - маленькая группа (по дефолту 16x16 норм), обилие ифов в Formula.hlsl, многие из которых вряд ли соптимизируются в conditional move и Dalet - тригонометрия это еще хуже чем if, лучше посчитать sin как p.x/sqrt(p.x*p.x+p.y*p.y) и cos как p.y/sqrt(p.x*p.x+p.y*p.y).
Ну и я ж не осуждаю тебя ни в чем, че ты кипятишься. Шейдер действительно сложный, да. Просто меня бы такой тайминг не устроил.

#23
20:43, 28 июля 2020

phridrich
> лучше посчитать sin как p.x/sqrt(p.x*p.x+p.y*p.y) и cos как
> p.x/sqrt(p.x*p.x+p.y*p.y)
Э, а в чем отличия формулы sin и cos тут? Ошибка закралась? Если не лень, то поправь, было бы интересно запомнить эти вещи.

#24
(Правка: 22:59) 21:04, 28 июля 2020

Vlad2001_MFS
Спс, поправил, там была опечатка естественно. Вообще это ж вычисление sin/cos как отношения катета к гипотенузе просто.

#25
21:26, 28 июля 2020

phridrich
> надеюсь ты это реально понимаешь а не начнешь приплясывать как АкронимЛета
> будто я типа слился.
Так ты реально сделал вброс и слился. Я тебе трижды давал шанс доказать, что ты не сказал полную чушь. Но даже ты понимаешь, что это нереально.

#26
22:59, 28 июля 2020

АкронимЛета
Ты спросил какая разница между if и min/max сразу после того, как я это объяснил. Из чего я сделал вывод что ты просто хочешь побросаться продуктами жизнедеятельности.

#27
23:10, 28 июля 2020

phridrich
Понятно, очередной сумасшедший. Я не спрашивал какая разница между if и min/max. Можешь открыть #10, если плохо с памятью или восприятием.

#28
23:28, 28 июля 2020

АкронимЛета
> > Это мягко говоря неверно. Если в границах варпа условие имеет разное значение -
> > выполнятся обе ветки. Не замечать разницу в скорости ты можешь из-за того, что
> > компилятор оптимизирует твой if в тот самый min/max.
> >
> > Используй min/max, if может оптимизироваться, а может и нет.
> Эм, а если не оптимизирует, то что произойдёт? Смоделируешь мне ситуацию?
Ты спросил, что будет если if не оптимизируется в min/max. Это и есть разница между if и min/max. А если все вокруг кажутся сумасшедшими - подумай как нибудь, точно ли с ними что-то не так, а не с тобой.

#29
0:15, 29 июля 2020

phridrich
> Продукт твой, и за качеством должен был следить ты. 30-40 ms - это не качественно.

Видишь ли, скорость выполнения шейдера зависит от возможностей железа и сложности задачи. Говорить "40мс - это не качественно" по меньшей мере неумно. Это "не качественно" если ты делаешь освещение и шейдер тормозит рендер. Но если ты формируешь текстуру даже за 200-300 мс на компьют шейдере и это делается параллельно с графическим пейплайном, т.е. не влияет на fps рендера, то какие проблемы? У меня в "Алхимике" стереоскопические панорамы разрешением 8K x 8K на GTX 970 формируются до 10 секунд, но юзер может сделать шаг и крутить головой (рефреш 90 Hz) и не замечать, что "пейзаж" за его спиной еще не до конца перестроился.

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

Страницы: 1 2 3 4 Следующая »
ПрограммированиеФорумГрафика