[问题] opencl似乎没有平行处里

楼主: hardman1110 (笨小孩)   2017-09-05 16:43:49
开发平台(Platform): (Ex: Win10, Linux, ...)
win10
编译器(Ex: GCC, clang, VC++...)+目标环境(跟开发平台不同的话需列出)
VC++
额外使用到的函数库(Library Used): (Ex: OpenGL, ...)
OpenCL
问题(Question):
希望透过opencl对图像运算做加速(1080 x 960)
opencl似乎没有达到平行化运算的优化
想请教是哪里没注意到
喂入的资料(Input):
两块参考图片、与一块输出图片的一维阵列内存加上一些定值参数
预期的正确结果(Expected Output):
由于切成1080个work item 预期要比cpu快很多
但结果却没快多少 0.4s >> 0.3s
错误结果(Wrong Output):
由于我水平方向有相依性,所以global_work_size 我是设置1080
一次算一列,但发现我的图片高度减半运算时间也减半
照理说运算时间应该差不多等于算最久的那列的时间
程式码(Code):(请善用置底文网页, 记得排版)
附上 opencl 的kernal 程式 .cl
https://github.com/ChiFang/question/blob/master/calcCostSmoothLMat_kernel.cl
补充说明(Supplement):
时间上只有LOG clEnqueueNDRangeKernel
buffer 搬到gpu的部分已在其他地方做完
作者: johnjohnlin (嗯?)   2017-09-05 19:34:00
1080 thread 塞不太满 GPU 吧
楼主: hardman1110 (笨小孩)   2017-09-05 20:10:00
每列有相依 所以只好这样预期是GPU再慢 也会因为1080列同时算而大幅优化
作者: laladeer (laladeer)   2017-09-06 00:22:00
要不要考虑使用openMP先试试看
楼主: hardman1110 (笨小孩)   2017-09-06 07:08:00
已试过多执行绪等方式 想用GPU突破
作者: LPH66 (-6.2598534e+18f)   2017-09-06 08:33:00
你这里可能需要 barrier, 这是个“平行并发时等大家都做完再继续做其他事”的概念; 你可以把 kernel 数量并发到一个 pixel 一个 kernel, 但是在计算最小值时需要 barrier挡住, 先等大家的值都算完再来做最小值而这个最小值的计算也是有平行化的方法这称做 parallel reduction, 可以去查一些资料基本概念就是尽量把化简运算当中能平行进行的一起进行这种利用 barrier 把相依性给拆开的做法在平行程式里很常用

Links booklink

Contact Us: admin [ a t ] ucptt.com