[問題] 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