作者hardman1110 (笨小孩)
看板C_and_CPP
标题[问题] opencl似乎没有平行处理
时间Tue Sep 5 16:43:49 2017
开发平台(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的部分已在其他地方做完
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 114.34.230.27
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/C_and_CPP/M.1504601033.A.FDE.html
※ 编辑: hardman1110 (114.34.230.27), 09/05/2017 16:44:18
※ 编辑: hardman1110 (114.34.230.27), 09/05/2017 16:48:13
1F:→ johnjohnlin: 1080 thread 塞不太满 GPU 吧 09/05 19:34
2F:→ hardman1110: 每列有相依 所以只好这样 09/05 20:10
3F:→ hardman1110: 预期是GPU再慢 也会因爲1080列同 09/05 20:10
4F:→ hardman1110: 时算而大幅优化 09/05 20:11
5F:→ laladeer: 要不要考虑使用openMP先试试看 09/06 00:22
6F:→ hardman1110: 已试过多执行绪等方式 想用GPU突破 09/06 07:08
7F:推 LPH66: 你这里可能需要 barrier, 这是个「平行并发时等大家都做完 09/06 08:33
8F:→ LPH66: 再继续做其他事」的概念; 你可以把 kernel 数量并发到 09/06 08:34
9F:→ LPH66: 一个 pixel 一个 kernel, 但是在计算最小值时需要 barrier 09/06 08:34
10F:→ LPH66: 挡住, 先等大家的值都算完再来做最小值 09/06 08:35
11F:→ LPH66: 而这个最小值的计算也是有平行化的方法 09/06 08:35
12F:→ LPH66: 这称做 parallel reduction, 可以去查一些资料 09/06 08:36
13F:→ LPH66: 基本概念就是尽量把化简运算当中能平行进行的一起进行 09/06 08:38
14F:→ LPH66: 这种利用 barrier 把相依性给拆开的做法在平行程式里很常用 09/06 08:39