2017-02-08 9 views
0

Я пытаюсь оптимизировать алгоритм сопоставления блоков для оценки движения в OpenCL. В основном размер изображения составляет 384x288, и, если предположить, что изображение разделено на несколько неперекрывающихся макрокоманд размером 16x16, можно реализовать в общей сложности 24x18 макроблоки.OpenCL - Обработка блоков в изображениях, глобальных и локальных работах

В каждом местоположении макрокоманды необходимо оценить движение в двух последовательных кадрах (включает в себя поиск близлежащей области для суммы абсолютных различий в интенсивности пикселей - серый с использованием блоков 16x16). Правильно ли я устанавливаю глобальные размеры до 24 и 18 соответственно при запуске ядра?

Я понимаю, что при запуске ядра opencl местоположение макроблока на исходном изображении может быть выработано как {get_local_size (0) x 16 -1, get_local_size (1) x 16 - 1}. Это верно? Также было бы оптимальным значением для местного размера рабочей группы для этого варианта использования?

Спасибо

ответ

0

я правильно в определении глобальных размеров 24 и 18 соответственно при запуске ядра

Если каждый поток вычисляет весь макроблок, да вы правы насчет глобального размер, но локальный размер должен быть 1 или что-то вроде 3x2. Но если один поток вычисляет одиночный пиксель, нет, глобальный параметр - это общие потоки. Это должно быть 384x288, если вы подсчитаете один пиксель на поток.

Число групп/макроблоков изменяется с локальным размером и глобальным размером.

Если в группе имеется 16 потоков, и если имеется всего 32 нитей, было бы всего 2 группы потоков. То же самое происходит для исполнения 2D и 3D-ядер.


Расположение местоположения макроблока на исходное изображение может быть разработан, как

x=get_group_id(0) * get_local_size(0) 
y=get_group_id(1) * get_local_size(1) 

идентификатор начинается с нуля. Где местоположение (x, y) указывает на верхний левый угол патча. Затем нижний правый угол будет

xLast=get_group_id(0) * get_local_size(0)+get_local_size(0) 
yLast=get_group_id(1) * get_local_size(1)+get_local_size(1) 

Ofcourse предполагается начало быть 0,0 в самый самый верхний левый.


Кроме того, что бы оптимальное значение для размера локального рабочей группы для этого варианта использования?

Если вы оставите параметр локального размера пустым (null), реализация opencl сама выберет (с подходящим размером, но может быть не лучшим), поэтому количество групп неизвестно.


Глобального размер и локальный размер будет отличаться, если у вас есть нить на пиксель или нити на группу или даже больше, чем один поток на пиксель. Например, если 2 новых кадра должны быть рассчитаны из более старых 5 кадров, можно использовать 2 потока на пиксель. Или вы можете выполнять всю работу в одном потоке пикселя, или вы можете выполнять все задания 16x16 пикселей в одном потоке, или вы можете делать все в одном потоке. Выбор за вами, вы должны проверить/farsee, если ваш алгоритм неловко параллелен или последователен.

Я предполагаю, что оценка - это что-то вроде 5 (или 11) -точечного трафарета (2d-дифференциация времени?), Поэтому он будет добавлять вещи, умножать вещи по отдельности, затем применять к пикселю, затем делать то же самое для другого фрейма пиксель, затем сделать то же самое для всех 16x16 пикселей макроблока, затем сделать то же самое для всех макроблоков, он должен использовать 1 поток на пиксель (повторное использование уже вычисленного трафарета для вычисления 2 кадров) (только с одним цветом?).


Вы могли бы начать с рабочим кодом (или переписывают себя), то распараллеливание его на своих вложенных циклов, например, вы можете сканировать строки (1D ядра), пиксели сканирования (2D ядра), пикс сканирования и их субпиксели (3D?), так что i становится get_global_id (0), а j становится get_global_id (1).