作者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/m.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