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

IF в шейдерах (2 стр)

Страницы: 1 2 3 Следующая »
#15
10:05, 19 апр. 2021

/A\
> У меня были проблемы, когда я менял только константу, шейдер не менялся, пока
> не перезапустишь приложение.

на OpenCL с nvidia было похожее


#16
10:57, 19 апр. 2021

Suslik
> поэтому если ты где-то уверен, что branch тебе не понадобится, имеет смысл
> лишний раз подумать, нужен ли тебе для этого именно if.

ты, правда, не указал что это static branching - а есть ещё dynamic

#17
11:24, 19 апр. 2021

Вечно можно делать три вещи: смотреть как течет вода, смотреть как горит огонь и пытаться объяснить san'у, к чему приводит if в SIMD архитектуре :)

#18
(Правка: 12:11) 11:51, 19 апр. 2021

SIMD архитектура не имеет условных операций, например на подобии cmove !
И правильных GPU алгоритмов(что бы не замедлять и не сбивать конвейер GPU) для ветвлений.
Это как раз и создает много проблем.

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

Вот как раз if тому и пример.

#19
(Правка: 12:00) 11:55, 19 апр. 2021

phridrich
> к чему приводит if в SIMD архитектуре :)
да, только я напомню, что в nvidia уже давным-давно нет simd вообще. там чистой воды simt, каждый тред оперирует со скалярами, и, например:

vec4 a, b, c;
c = a + b;
сгенерит ровно такой же код, который выполнится за ровно такое же количество инструкций, как и код
float a[4];
float b[4];
float c[4];
c[0] = a[0] + b[0];
c[1] = a[1] + b[1];
c[2] = a[2] + b[2];
c[3] = a[3] + b[3];
причём не потому что второй код векторизуется и получится первый, а потому что векторизованный код выполняется скалярно, то есть первый код выполнится точно так же, как и второй.

поэтому когда говорят о SIMD на GPU, следует понимать, что не vec4 будет лежать в широком регистре SIMD, а каждая отдельная компонента vec4 будет представлена в отдельном треде, а суммирование они будут выполнять синхронно в локстепе: сначала c[0], потом c[1], потом c[2] и c[3], каждый раз выполняя столько суммирований, сколько тредов в варпе. это сильно отличается от того, что понимают под SIMD на CPU, где за одну инструкцию c = a + b просуммировалось бы 4 float'а. в этом смысле GPU'шный SIMT скорее похож на SoAoS вроде такого:

template<typename X>
struct vec4_X
{
  float x[X];
  float y[X];
  float z[X];
  float w[X];
};
#define WARP_SIZE 16
vec4_X<WARP_SIZE > data[N / WARP_SIZE];
где X — размер warp'а, а float[X] — это данные, с которыми один варп работает за одну операцию (каждый тред внутри варпа работает с одним скаляром за раз). для сравнения то, что понимают под SIMD на CPU, можно представить псевдокодом так (AoS):
struct vec4
{
  __mm128 xyzw;
};
vec4 data[N];

#20
13:04, 19 апр. 2021

Suslik
> поэтому когда говорят о SIMD на GPU, следует понимать, что не vec4 будет лежать в широком регистре SIMD, а каждая отдельная компонента vec4 будет представлена в отдельном треде
Ну это да. Хотя, на мобилках вроде как еще сохранились архитектуры с vec4-SIMD'ом, без SIMT вообще, но это уже сравнительно устаревшие образцы.

#21
13:30, 19 апр. 2021

всегда забавляло, когда начинают умничать про всякие варпы и прочие - ну на фиксированной железке понятно - но когда целый зоопарк ? рассмотрите конкретные примеры бранчинга и сравните...
вот есть earlyOut, можно сравнить где есть какой прирост или стало хуже

#22
(Правка: 14:24) 14:22, 19 апр. 2021

innuendo

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

Куда уж конкретнее?

Разбираться конкретно, когда игра статтерит это не норм или это норм?

#23
14:53, 19 апр. 2021

nonamezerox
> Эм, как бы суслег конкретный пример проблемы приводил, когда в пое внезапно
> статтерфест возник

и причём тут warp? wave?

#24
15:20, 19 апр. 2021

Suslik
> да, только я напомню, что в nvidia уже давным-давно нет simd вообще. там чистой воды simt
Различия между SIMD и SIMT чисто маркетинговые. Я бы сказал, что SIMD даже шире, ибо может содержать инструкции, которые в концепцию фиксированного числа тредов не ложатся.

> для сравнения то, что понимают под SIMD на CPU, можно представить псевдокодом так (AoS):
Это SIMD двоечников, настоящий SIMD на проце такой же, как на GPU. Например, уже AVX 8-ми компонентный (если во float-ах), никакие xyzw туда не подходят. А уж AVX-512, вообще, выросло из экспериментов интела по конструированию видеокарт.

#25
(Правка: 16:12) 16:11, 19 апр. 2021

}:+()___ [Smile]

Интел нас заставила верить что SIMD === аппаратное ускорение линейной алгебры и ниипет.

И большая часть заявленных SSE посвящена именнно линалу.

#26
(Правка: 17:02) 16:32, 19 апр. 2021

Suslik
> ...делается через saturate или через clamp — это и читать проще и ошибиться сложнее
Да ну? Неужели:

c = lerp(_Color1, _Color2, clamp((IN.worldPos.y - _Y1) / (_Y2 - _Y1), 0, 1));
"читать проще" чем:
 if (IN.worldPos.y < _Y2)  
   c = _Color2;
  else if (IN.worldPos.y > _Y1)
    c = _Color1;
  else
  {
    c = lerp(_Color1, _Color2, (IN.worldPos.y - _Y1) / (_Y2 - _Y1));
  }
Да, так короче. Но короче не значит понятнее. Да и экономия строчек не эквивалентна экономии времени выполнения, особо в данном случае.

> такие if-ы это плохо не только в шейдерах, а в любом коде.

Не нужно любое правило возводить в абсолют. Это утверждение сродни "goto это ужас-ужас-ужас". Можно используя goto написать нечитаемую программу? Да можно. Но с этим многие справляются и без этого. А вот когда нужно выскочить из нескольких вложенных циклов, то в священной попытке обойтись без "крамольного" оператора получается никак не "проще и понятнее".  С if та же история. Можно без них обойтись? Ну наверно во многих случаях можно, вопрос только зачем? Что бы стало "проще"? Сомнительно. Что бы стало работать быстрее? Еще более сомнительно. Короче это дело вкуса а никак не общее правило.

#27
17:05, 19 апр. 2021

san
Ифы читать сложнее. clamp+lerp уанлайнеры проще. Тоесть ты сразу скейлишь значения. А не придумываешь иф-елс значения.

#28
(Правка: 17:42) 17:40, 19 апр. 2021

lookid
>Ифы читать сложнее. clamp+lerp уанлайнеры проще.
Нужно добавить "мне".
Не пойму почему тебе продираться через горизонтальный код проще чем через вертикальный, но могу поверить. Я знал одного программера который весь код писал в одну бесконечно длинную строку. Он говорил, что при этом он экономит строчки кода. Причем он легко в этом ужасе ориентировался.
Еще раз - это дело вкуса. Но совсем не общее правило.

#29
17:40, 19 апр. 2021

lookid
> Ифы читать сложнее.

смотря какие

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