...is great.
solo campaign is not much different from halo 1，but 30 seconds of fun is still great fun
Thursday, September 16, 2010
Tuesday, September 14, 2010
Some OpenCL test. pt2.
繼續紀錄OpenCL的瑣事。
我覺得OpenCL很不錯的地方之一，在於它的一些專有名詞命名都還滿符合直覺，不會像有些想要耍帥的技術取了一堆像是warp啦，thread block啦之類很難一下子就理解的怪東西。
OpenCL的一個device就是一個cpu或一個gpu，一個device就有一個相對應的job queue可以把工作丟進去讓device執行，至於一個device有幾個核心或是一個job如何scheduling，我們不用理會，OpenCL會幫我們處理。
一整個要被執行的job大小叫做global work size，global work會被切分成一些被放在一起執行的單位叫做work group，work group的大小叫做local work size，work group裡面包含了很多的單一工作叫做work item，我們要寫的kernel，就是一個單一work item要作的工作。
個人是覺得相當直覺，看一眼就知道在幹嘛，如果有寫過shader，幾乎是一樣的流程，只是OpenCL在memory的存取上，少了一些shader的限制
1.每個work item中可以有自己的private memory，這相當於shader中的一些local register
2. 同樣work group中的work items，可以存取一小塊分享的local memory，據nVidia的文件local memory速度相當快，這有點像shader的uniform變數或constant buffer，不過shader的uniform變數是不能寫的，kernel則無此限制。
3. 所有work item都可以存取global memory，可是速度就比較慢，這可以想成是GPU的texture memory，不過在shader中是不能寫到任意貼圖記憶體位置的，kernel同樣無此限制。
4. 存取global 或local memory，都可以用一些atomic的運算，如atomic_add，來確保運算結果是正確的。
我覺得OpenCL很不錯的地方之一，在於它的一些專有名詞命名都還滿符合直覺，不會像有些想要耍帥的技術取了一堆像是warp啦，thread block啦之類很難一下子就理解的怪東西。
OpenCL的一個device就是一個cpu或一個gpu，一個device就有一個相對應的job queue可以把工作丟進去讓device執行，至於一個device有幾個核心或是一個job如何scheduling，我們不用理會，OpenCL會幫我們處理。
一整個要被執行的job大小叫做global work size，global work會被切分成一些被放在一起執行的單位叫做work group，work group的大小叫做local work size，work group裡面包含了很多的單一工作叫做work item，我們要寫的kernel，就是一個單一work item要作的工作。
個人是覺得相當直覺，看一眼就知道在幹嘛，如果有寫過shader，幾乎是一樣的流程，只是OpenCL在memory的存取上，少了一些shader的限制
1.每個work item中可以有自己的private memory，這相當於shader中的一些local register
2. 同樣work group中的work items，可以存取一小塊分享的local memory，據nVidia的文件local memory速度相當快，這有點像shader的uniform變數或constant buffer，不過shader的uniform變數是不能寫的，kernel則無此限制。
3. 所有work item都可以存取global memory，可是速度就比較慢，這可以想成是GPU的texture memory，不過在shader中是不能寫到任意貼圖記憶體位置的，kernel同樣無此限制。
4. 存取global 或local memory，都可以用一些atomic的運算，如atomic_add，來確保運算結果是正確的。
Some OpenCL test. pt1
有很長一段時間沒有在網路上寫任何東西了，主要原因是因為覺得自己寫的東西都非常不成熟，總是夾帶太多個人的不成熟看法，通常過了兩三個月看自己的文章都覺得很羞愧，也不像某些前輩高人的blog有一些真的技術內容可以學習，so，不想浪費時間的人可以直接跳去看我的blog list，那些連結裡面可以學習到真正的智慧。
如果要浪費時間...之前我是有寫了一些OpenCL的code啦...
一些連結：
它的spec寫的真的還不錯，看一看就會寫了
http://www.khronos.org/registry/cl/
AMD的OpenCL convolution tutorial，我測試用的kernel是抄他的code，他測試平台是在CPU上跑的，global work size非常大，8192還多少的，在我的nVidia 8600M上完全是沒辦法跑的，要降到512*512才可以http://developer.amd.com/gpu/ATIStreamSDK/ImageConvolutionOpenCL/Pages/ImageConvolutionUsingOpenCL.aspx
一些簡單的心得
1. stream programming model，寫kernel很簡單，看起來跟c語言幾乎是一樣的，但是目前仍然有些限制，例如pointer dereference不能使用->而一定要用array的形式，然後不能用recursion，這些限制在Cuda是不存在的，但是實用上要寫高效能的kernel可能也不會需要用到這些。
2.使用OpenCL已經可以做出許多超出傳統shader的運算，如scatter operation，atomic/synchronization primitive
3. OpenCL適用於異質多核心，只要硬體廠商有提供OpenCL的driver，同樣的code可以編譯成CPU，GPU，SPU，xxPU的版本，AMD的fusion大業似乎是想要建立在OpenCL上。
4.硬體架構對kernel的效能影響應該非常大，AMD的convolution kernel最佳化在GPU上完全沒有作用，想要寫高效能的kernel，底層的硬體是無法被抽象化的。
4. rant......要在nvidia上的卡運行OpenCL要先去下載Cuda Toolkit，我個人是覺得nVidia想要降低OpenCL的使用率吧，所以把OpenCL也包在Cuda裡面，聽說他們的OpenCL也是架構在Cuda上，所以OpenCL的效能要比直接用Cuda要慢20~30%。他們的OpenCL driver也不是太穩定。我的想法是我們應該不要使用只支援nVidia GPU的Cuda，OpenCL才是正確的道路。
5.測試AMD的convolution kernel，8600M GT大約比single thread Core 2 Duo 2.2 G快3倍左右，不過兩個平台都沒有做任何有意義的最佳化就是了。
6.如果是box filter(也就是average)，OpenCL可以做到一些shader做不到的最佳化，之後有時間再寫吧，詳情可以看這個連結http://pixelstoomany.wordpress.com/2007/09/13/why-gpus-are-not-so-good-at-post-processing-images/。其實我原本以為它可以適用於一般的convolution的，不過有個聰明的傢伙一下子就看穿了是不行的，有沒有天分從這裡就看得出來了....
如果要浪費時間...之前我是有寫了一些OpenCL的code啦...
一些連結：
它的spec寫的真的還不錯，看一看就會寫了
http://www.khronos.org/registry/cl/
AMD的OpenCL convolution tutorial，我測試用的kernel是抄他的code，他測試平台是在CPU上跑的，global work size非常大，8192還多少的，在我的nVidia 8600M上完全是沒辦法跑的，要降到512*512才可以http://developer.amd.com/gpu/ATIStreamSDK/ImageConvolutionOpenCL/Pages/ImageConvolutionUsingOpenCL.aspx
一些簡單的心得
1. stream programming model，寫kernel很簡單，看起來跟c語言幾乎是一樣的，但是目前仍然有些限制，例如pointer dereference不能使用->而一定要用array的形式，然後不能用recursion，這些限制在Cuda是不存在的，但是實用上要寫高效能的kernel可能也不會需要用到這些。
2.使用OpenCL已經可以做出許多超出傳統shader的運算，如scatter operation，atomic/synchronization primitive
3. OpenCL適用於異質多核心，只要硬體廠商有提供OpenCL的driver，同樣的code可以編譯成CPU，GPU，SPU，xxPU的版本，AMD的fusion大業似乎是想要建立在OpenCL上。
4.硬體架構對kernel的效能影響應該非常大，AMD的convolution kernel最佳化在GPU上完全沒有作用，想要寫高效能的kernel，底層的硬體是無法被抽象化的。
4. rant......要在nvidia上的卡運行OpenCL要先去下載Cuda Toolkit，我個人是覺得nVidia想要降低OpenCL的使用率吧，所以把OpenCL也包在Cuda裡面，聽說他們的OpenCL也是架構在Cuda上，所以OpenCL的效能要比直接用Cuda要慢20~30%。他們的OpenCL driver也不是太穩定。我的想法是我們應該不要使用只支援nVidia GPU的Cuda，OpenCL才是正確的道路。
5.測試AMD的convolution kernel，8600M GT大約比single thread Core 2 Duo 2.2 G快3倍左右，不過兩個平台都沒有做任何有意義的最佳化就是了。
6.如果是box filter(也就是average)，OpenCL可以做到一些shader做不到的最佳化，之後有時間再寫吧，詳情可以看這個連結http://pixelstoomany.wordpress.com/2007/09/13/why-gpus-are-not-so-good-at-post-processing-images/。其實我原本以為它可以適用於一般的convolution的，不過有個聰明的傢伙一下子就看穿了是不行的，有沒有天分從這裡就看得出來了....
Subscribe to:
Posts (Atom)