OpenCL большого глобального размера или для циклов на рабочий элемент?

Question

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

Реализация предназначена для Mali T-6xx GPU.

Я прочитал книгу "Программирование OpenCL на примере" и документ "Оптимизация ядер OpenCL на графических процессорах Mali-T600".

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

В документе ядра написаны без циклов, так как в ядре выполняется одно выполнение для каждого рабочего элемента.

Поскольку максимальный глобальный размер рабочих элементов, которые можно порождать на графических процессорах Mali T-600, составляет 256 (и это для простых ядер), и в большинстве изображений явно больше пикселей для обработки, в моем понимании будет появляться ядро ​​без циклов как можно больше потоков рабочих элементов, пока глобальный размер рабочих элементов не завершит выполнение ядра, а глобальный размер может быть просто количеством пикселей в изображении. Это правильно? Такой, что это своего рода нить, порождающая петлю сама по себе?

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

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

Answer 1

Это правильно? Такой, что это своего рода нить, порождающая петлю сама по себе?

Да.

Поэтому я хочу знать, какой путь является правильным способом написания ядер обработки изображений или любых ядер OpenCL в этом отношении и в каких ситуациях

Я подозреваю, что в общем случае нет "правильного" ответа - есть несколько поставщиков оборудования и несколько драйверов - поэтому я подозреваю, что "лучший" подход будет отличаться от поставщика к поставщику.

В частности, для Mali порождение потоков выполняется аппаратно, поэтому в общем случае будет быстрее, чем явные циклы в коде шейдера, которые будут обрабатывать инструкции.

Обычно есть некоторое преимущество, по крайней мере, для некоторой векторизации - например, обработка векторов vec4 или vec8 пикселей для рабочего элемента, а не только 1 - поскольку ядра графического процессора Mali-T600/700/800 используют векторную арифметическую архитектуру.