[問題] opencl似乎沒有平行處理

[hardman1110 (笨小孩)]

開發平台(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://www.ptt.cc/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
→ johnjohnlin: 1080 thread 塞不太滿 GPU 吧
→ hardman1110: 每列有相依 所以只好這樣
→ hardman1110: 預期是GPU再慢 也會因爲1080列同
→ hardman1110: 時算而大幅優化
→ laladeer: 要不要考慮使用openMP先試試看
→ hardman1110: 已試過多執行緒等方式 想用GPU突破
推 LPH66: 你這裡可能需要 barrier, 這是個「平行並發時等大家都做完
→ LPH66: 再繼續做其他事」的概念; 你可以把 kernel 數量並發到
→ LPH66: 一個 pixel 一個 kernel, 但是在計算最小值時需要 barrier
→ LPH66: 擋住, 先等大家的值都算完再來做最小值
→ LPH66: 而這個最小值的計算也是有平行化的方法
→ LPH66: 這稱做 parallel reduction, 可以去查一些資料
→ LPH66: 基本概念就是盡量把化簡運算當中能平行進行的一起進行
→ LPH66: 這種利用 barrier 把相依性給拆開的做法在平行程式裡很常用