新手套 & 花園夜市

沒甚麼關聯的標題，幸好最近的標題都走混搭風(??)，所以還不錯...(???)

今天是暑假第一天，去了康康推薦的kazuma買新手套，一開始去找本店，還滿難找的，在永康的一個小巷子裡，兵仔市場旁邊，最後找到的時候他沒開orz，還被我哥罵笨蛋，所以又跑去新開的成大分店，還好有開。

店裡手套很多，不過不知道該選哪個好，我問店員有沒有推薦的，他就說有常在玩就買硬一點的比較不會變形，沒有就買軟一點的比較不用整形。

之前不見的手套是SSK的，今天有看到一個長得很像，試戴過感覺不錯，跟不見的那個也很像，只是SSK的手套很硬。

我估計了一下以後有可能真的玩傳接球的機率，就乖乖的買了一個比較軟的，Mizuno牌。

手套買拉，可是真的有機會玩嗎，心裡有點存疑阿...真的很懷疑阿...

晚上跟我哥去吃了一家據說也是老字號的日本料理，東京益田，因為餐廳裡面都客滿了，所以就坐在外面的位子，天氣有點涼，所以就一邊吹涼風，一面聽候選人的競選口號一邊吃，感覺很不錯。

他們的握壽司，薑汁燒肉和烤雞腿都不錯吃，不過我點了一個有點奇怪的東西，生鮪魚拌山藥，我覺得應該是拿來做成蓋飯上面的料拉，不過沒有點白飯，只好加了一堆醬油把它唏哩呼嚕的吞下去...味道的話就沒有太詳細去品嘗了，不過魚應該有新鮮...

我因為家裡離花園夜市徒步距離十分鐘可是卻從來沒有去過而遭到同事恥笑，所以吃完晚餐就決定來雪恥，逛花園夜市，最後在夜市吃了有點普通的烤雞串(還要等二三十分鐘)和哈密瓜牛奶，然後突然想起來，這不就跟去花蓮自強夜市吃的東西差不多嗎(過程也差不多)。

我哥還跟我說如果想吃燒烤可以帶我去好一點的店，我只好跟他說其實我並不是想吃燒烤...好難解釋...。所以我內心os的結論是，夜市果然都是拿來騙觀光客的東西拉!!!

不過為了迎合大家愛逛夜市的奇特習性，我會對外宣稱花園夜市真的很棒。

最後，跟我哥去了一家夜市旁邊的咖啡店，他們的敗筆是居然沒開冷氣，雖然今天天氣有點涼了，不過店裡面還是很熱，點了英式奶茶，沒特別好喝，不過上面的圖案...花紋...(這有個專有名詞的嗎)很漂亮。

感覺跟這個部落格的主題完全不搭，不過暑假很棒，回家也很棒，只是太少回家感覺在家裡的空間越來越少了。

OpenCL FFT & Ocean Wave pt. 2

稍微正確的結果，之前的錯誤並不是高頻波，而是虛數的部分，因為Apple 的OpenCL FFT沒有complex to real這種轉換，所以inverse FFT出來的結果其實是複數，忽略掉虛數部分是上圖結果。

CUFFT有提供complex to real FFT這種轉換，只要在frequency domain符合一些對稱的條件，可以保證output會是實數，input size可以從N減為(N/2) + 1，在Cuda的ocean wave demo中，他們用這個方法來進一步加速，可惜的是Apple的FFT沒有這個功能。

不過照Tessendorf paper上的公式，我看不出一定會符合對稱的條件(?)，那這時候轉換出來虛數的部分代表甚麼呢?感覺上已經到達我數學能力的極限了，數學只要不用，實在是退化的非常快阿...還好工作上都用現成的library，幾乎所有東西都是黑盒子啦，難的東西都交給別人寫就好...

一些相關reference

• ocean wave的經典論文是Tessendorf的"Simulating Ocean Water".
• real input DFT http://en.wikipedia.org/wiki/Discrete_Fourier_transform#The_real-input_DFT
• Insomniac Game在Resistance 2中用了32*32的FFT來模擬水面http://www.insomniacgames.com/research_dev/articles/2009/1500769，只是他們的技術更複雜，水面有LOD，除了風力還可以模擬其他外力造成的水波。他們非常大方的釋出了所有source code，只是很大部分都是用spu assembly寫的，嗯...
• kiss FFT http://sourceforge.net/projects/kissfft/一個CPU FFT library，我用來驗證GPU結果正確性。非常方便，整合大概花了五分鐘，其中有三分鐘是在下載檔案。好的library就應該是這個樣子，可以直接把程式碼貼進專案然後就可以work，沒有其他雜七雜八的external dependency。

OpenCL & FFT ocean wave

應該是錯的，出現一堆極高頻波，Fourier Transform我從來就沒學好過。

FFT kernel是Apple的library，2D FFT 256 x 256在8600M GT上花費約0.082 ms，已經相當快了，不過聽說CUFFT(Cuda的FFT)速度比OpenCL更快。

Z prepass & alpha test

我想我終於真正領悟了Z prepass renderer的奧義，我們的場景裡如果有很多alpha test的物件例如樹的話，效能常常會下降很多，這是因為alpha test的物件沒辦法有early Z，所以所有的pixels都會執行pixel shader，但如果在Z prepass架構下：

第一個pass用最簡單的shader，開啟alpha test，把樹的Z值寫到Z buffer。
第二個pass執行真正的複雜的shader，Z function用equal，然後把alpha test關掉，因為Z test已經可以把樹刻出來拉，如此複雜的shader就有了early Z的效果。

今天測試了一下，有些樹的效能可以從0.7ms提升到0.2ms以下。當然，樹如果用了alpha to coverage，這個方法就沒辦法用了，幸好我們的場景沒有這種樹。

Halo Reach

...is great.

solo campaign is not much different from halo 1，but 30 seconds of fun is still great fun

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，來確保運算結果是正確的。

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的，不過有個聰明的傢伙一下子就看穿了是不行的，有沒有天分從這裡就看得出來了....