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

Никак не могу придумать, как посчитать интенсивность изображения с помощью compute shader

Страницы: 1 2 3 Следующая »
#0
22:11, 10 июня 2016

Приветствую, господа, планирую сделать HDR менее, чем за год.
У меня тут модные фичи, всё такое, хочу посчитать compute shaderом среднюю интенсивность изображения. Но, поскольку должен получиться один float, то не могу придумать как же это дело сосчитать так, чтобы удружить это дело с кучей потоков.
Делать мультипасс, с уменьшением изображения не очень хочется, инновации, все дела.
Interlocked операции работают только с uint/int данными. В текстуру, понятное дело, не запишешь. Между тред-группами, да и тредами данные тоже не передашь.
Есть какие-то идеи? Или я просто извращенец и должен сделать как все нормальные человеки?

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


#1
22:36, 10 июня 2016

от чтений из текстуры никуда не денешься. сократить их количество - хорошая идея. два этапа в шейдере с записью в shared memory пожалуй сработает, только вот не уверен, что это будет быстрее downsampling'a.
ещё можно гистограмму посчитать на атомиках и пройтись по ней...
а для чего тебе это?

#2
22:43, 10 июня 2016

агрессор
> от чтений из текстуры никуда не денешься. сократить их количество - хорошая
> идея. два этапа в шейдере с записью в shared memory пожалуй сработает, только
> вот не уверен, что это будет быстрее downsampling'a.
Даже если делать donwsampling, то его надо в несколько пассов делать, чтобы получить среднюю интенсивность. А читать текстуру... ну её все равно читать придется.

агрессор
> ещё можно гистограмму посчитать на атомиках и пройтись по ней...
Для 16 бит на канал длинная гистограмма-то получится :)

агрессор
> а для чего тебе это?
Автоматическая адаптация к яркости изображения.

#3
13:47, 11 июня 2016

ArchiDevil
> Даже если делать donwsampling, то его надо в несколько пассов делать, чтобы
> получить среднюю интенсивность
это ж делается очень быстро

в компьюте можно разбить на несколько блоков-тайлов и посчитать среднее для них, получишь N значений (N - общее кол-во блоков), сложить N на проце или использовать в буефере эти значения, но знать, что их несколько

если все одним блоком считать, то не распараллелить

в демке от нвидиа даунсемплят 4х и потом один блок в компьюте усредняют. Вообще даунсемплинг же быстрый, я через GenerateMIPMap делаю )

#4
15:15, 11 июня 2016

d.m.k
> в компьюте можно разбить на несколько блоков-тайлов и посчитать среднее для
> них, получишь N значений (N - общее кол-во блоков), сложить N на проце или
> использовать в буефере эти значения, но знать, что их несколько
Останавливать пайплайн для выдирания данных на CPU не хочется.

d.m.k
> Вообще даунсемплинг же быстрый, я через GenerateMIPMap делаю )
На D3D12? :)

Видимо, да, даунсемплить и считать в одном блоке разом всё.

#5
15:21, 11 июня 2016

Посмотри пример про нахождение суммы массива на CS. То что надо.

#6
15:50, 11 июня 2016

ArchiDevil
> d.m.k
> > в компьюте можно разбить на несколько блоков-тайлов и посчитать среднее для
> > них, получишь N значений (N - общее кол-во блоков), сложить N на проце или
> > использовать в буефере эти значения, но знать, что их несколько
> Останавливать пайплайн для выдирания данных на CPU не хочется.
С таким способом можно сделать зональную адаптацию яркости, например.
(я никогда так не делал и не слышал чтоб делали, но попробовать было бы интересно)

#7
16:03, 11 июня 2016

k119_55524
> Посмотри пример про нахождение суммы массива на CS. То что надо.
Где такой можно посмотреть? Не нагугливается как-то.

#8
18:05, 11 июня 2016

Тут пишут что автогенерация мип-мапов работает быстрее чем parallel reduction.
https://mynameismjp.wordpress.com/2011/08/10/average-luminance-compute-shader/

Хотя может на GCN всё уже поменялось.

#9
19:09, 11 июня 2016

ArchiDevil
> Где такой можно посмотреть? Не нагугливается как-то.
в книге по куда алгоритм. Перевод на кш простой.
Но думаю генерацией ммапов будет быстрее, так как аппаратно(по крайней мере так кажется).

#10
19:12, 11 июня 2016

>так как аппаратно(по крайней мере так кажется)
Думаю там тот-же parallel reduction, только сидит глубже в драйвере и ближе к железу.

#11
20:39, 11 июня 2016

ArchiDevil
> Останавливать пайплайн для выдирания данных на CPU не хочется.
ну динамическая адаптация дело не мгновенное все равно, так что можно и не останавливать, а выдергивать через кадр

> На D3D12? :)
нет же

/A\
> С таким способом можно сделать зональную адаптацию яркости, например.
можно, но это уже слишком хитрожопо, надо будет как-то все это складывать потом чтобы не было резких переходов

#12
21:15, 11 июня 2016

d.m.k
> ну динамическая адаптация дело не мгновенное все равно, так что можно и не
> останавливать, а выдергивать через кадр
Текущий-то фрейм нужен мгновенно.

d.m.k
> можно, но это уже слишком хитрожопо, надо будет как-то все это складывать потом
> чтобы не было резких переходов
Только вот вопрос зачем это надо. Можно же интерполировать полученные данные потом. Но только вот зачем?)

#13
21:20, 11 июня 2016

Ребят, вы издеваетесь? Алгоритм вроде ж как классика жанра. Одно или 2-х проходный (выбор зависит от кол-ва мультипроцессоров и накладных расходов на два прохода).

Вариант 1. 64 потока в варпе обрабатывают каждый свою группу линий (распределение исходя из высоты изображения). Далее пишем 64 зачений в шаред память, синхронизация и один из потоков считает среднее из 64-х значений (ну или делаем усреднение по 2 в 6 шагов (только боюсь тут на синхронизации больше потеряем)).

Вариант 2. Вначале по варпу на линию с запись в промежуточную текстуру. Потом усреднение её значений.

Основная разница это работы только одного МП против необходимости записи во временную область + синхронизация операции. Время нужно померять. Это всяко быстрее любой генерации мипмапов.

#14
23:37, 11 июня 2016

Bishop
> Вариант 1. 64 потока в варпе обрабатывают каждый свою группу линий
> (распределение исходя из высоты изображения). Далее пишем 64 зачений в шаред
> память, синхронизация и один из потоков считает среднее из 64-х значений (ну
> или делаем усреднение по 2 в 6 шагов (только боюсь тут на синхронизации больше
> потеряем)).
В конце-то всё равно еще пасс пускать, либо на CPU дергать это дело придется. Когда надо будет собрать аутпут с групп. Или я недопонял чего-то?

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

Тема в архиве.