www.Phototalks.idv.tw

最近開始在kernel function中打轉，打算解決效能瓶頸!

假設我們都知道CUDA有這些memory了
global memory
local memory
shared memory
register

這是我用存取速度來排序的，我們發現一個很尷尬的東西local memory，明明是local卻比shared memory慢?

這點有許多謬誤，這個速度取決於你佔用local memory的大小，CUDA原則上會儘量把local memory分配到register中，但若存不下才分配到global memory中，但這不代表local memory永遠比shared memory慢，因為你知道它有機會存在最快register中。

這關係到一個大問題，許多人都認為(甚至連CUDA的教科書)以大量的thread來hide memory latency可以獲得最高的效能，但這僅在你的thread occupied rate在80%以上才有明顯效果，但並非所有的問題都有辦法展開到全部的thread執行，另外一個極端是當你全部thread都用上了還想增加效能時，這時候我們可以考慮讓一個thread多做點事，利用register/local memory來hide memory latency，這可以在低thread occupied rate仍保有最高的效能輸出。

不要害怕分配小單位的local memory，因為它有很大機會是存在register

這到底有什麼好處? 一般我們為了避免直接存取global memory，都儘量使用shared memory，但本質上shared memory僅是cached global memory，還是需要經過bus存取global memory，那為什麼不要直接放在register中呢? 讓bus暢通使更多block來存取。

一個大原則使用記憶體，注意使用量必須是遞增，不是用大量的local memory
register > local memory > shared memory > global memory

最近論文慢到不用CUDA無法跑完的境界，在使用Texture Reference上遇到了許多問題，故寫下此整理後查

我遇到的問題是必須要做驚人次數的bi-linear interpolation warping，故希望能用GPU的texture mapping功能，但同時必須要在多張影像中間切換

先轉述一篇文章片段

Those of you who have used CUDA textures should be familiar with the insane programming interface that they present. Texture references can be declared only as global variables, and only in the file where you are using them. You can’t pass them around as by-value/by-reference arguments in functions, you can’t create them inside function/class scope, and you cannot make arrays of them.

我們都看到這些限制拉，既然不能做texture reference array，這也代表我們不能在kernel function中index它，故每張影像一個texture reference是不可行的，當然這並不包括你硬刻影像數量的texture reference array在code中，同時你還必須受到一個kernel function僅能access 128個texture rerference的限制，並且在未知影像數量下也做不到硬刻code。

解決辦法一：在要使用texture時bind texture reference，但這似乎牽涉到複製到texture memory的問題，當你頻繁的切換時會有巨大的overhead。

解決辦法二：爛招合併所有影像到同一個texture，自然就可以僅用一texture reference，但你會受到texture size limit，這僅對小影像的合併有用，並且CUDA似乎不希望你開一個巨大的texture block，會在runtime時死掉，這個大小是與你的GPU記憶體無關的。還有另一個問題是你在fetch影像邊界的texture時可能會染到上下一張影像的pixel顏色，因為它當作是同一張圖了!

解決辦法三：使用3D texture reference，使用第三個維度來作為2D texture的影像index，但明顯的你的影像大小最好要全部一樣，並且也會發生解法二的顏色問題

解決辦法四：放棄使用你的高階CUDA語法，有low-level的解法，使用”DEPRECATED”的CUDA Driver API，咦?

解決辦法五：放棄使用CUDA! DirectX10有提供texture array! XDD

最終解法：使用cudaArrayLayered! interpolation 僅在該layer，不會跨layer interpolation

最近要用到PCL來做visualization，但官方的tutorial都是教你用cmake開專案
要整合到現有的專案檔就很麻煩~~
所以自己整理了該include的清單備查

For PCL version 1.5.1

C:/Program Files/PCL 1.5.1/include/pcl-1.5
C:/Program Files/PCL 1.5.1/3rdParty/VTK/include/vtk-5.8
C:/Program Files/PCL 1.5.1/3rdParty/Eigen/include
C:/Program Files/PCL 1.5.1/3rdParty/Boost/include
C:/Program Files/PCL 1.5.1/3rdParty/Flann/include
C:/Program Files/PCL 1.5.1/3rdParty/Qhull/include
C:/Program Files/OpenNI/Include

C:/Program Files/PCL 1.5.1/lib
C:/Program Files/PCL 1.5.1/lib/$(Configuration)
C:/Program Files/PCL 1.5.1/3rdParty/Boost/lib/
C:/Program Files/PCL 1.5.1/3rdParty/VTK/lib/vtk-5.8/
C:/Program Files/PCL 1.5.1/3rdParty/Flann/lib/
C:/Program Files/PCL 1.5.1/3rdParty/Qhull/lib/
C:/Program Files/OpenNI/Lib/

kernel32.lib
user32.lib
gdi32.lib
winspool.lib
shell32.lib
ole32.lib
oleaut32.lib
uuid.lib
comdlg32.lib
advapi32.lib
opengl32.lib
ws2_32.lib
comctl32.lib
wsock32.lib
openNI.lib
pcl_common_debug.lib
pcl_octree_debug.lib
pcl_surface_debug.lib
pcl_registration_debug.lib
pcl_keypoints_debug.lib
pcl_tracking_debug.lib
pcl_apps_debug.lib
pcl_kdtree_debug.lib
pcl_search_debug.lib
pcl_filters_debug.lib
pcl_segmentation_debug.lib
pcl_visualization_debug.lib
pcl_features_debug.lib
pcl_io_debug.lib
pcl_sample_consensus_debug.lib
flann_cpp_s-gd.lib
qhullstatic_d.lib
libboost_system-vc100-mt-gd-1_47.lib
libboost_filesystem-vc100-mt-gd-1_47.lib
libboost_thread-vc100-mt-gd-1_47.lib
libboost_date_time-vc100-mt-gd-1_47.lib
libboost_iostreams-vc100-mt-gd-1_47.lib
vtkCommon-gd.lib
vtkRendering-gd.lib
vtkHybrid-gd.lib
vtkGraphics-gd.lib
vtkverdict-gd.lib
vtkImaging-gd.lib
vtkIO-gd.lib
vtkFiltering-gd.lib
vtkDICOMParser-gd.lib
vtkNetCDF_cxx-gd.lib
vtkmetaio-gd.lib
vtksys-gd.lib
vtksqlite-gd.lib
vtkpng-gd.lib
vtktiff-gd.lib
vtkzlib-gd.lib
vtkjpeg-gd.lib
vtkexpat-gd.lib
vtkftgl-gd.lib
vtkfreetype-gd.lib
vtkexoIIc-gd.lib
vtkNetCDF-gd.lib
vfw32.lib

又是影像處理期末考的玩意兒
網路上完全找不到詳細的例子，好險自己領悟一番有點感覺了，故寫下此筆記後查

這邊舉例CCITT 4的RLC編碼方式，我們都知道有Pass mode、Vertical mode與Horizontal mode三種模式，以及幾個重要的座標點
a0：編碼行的參考點，預設為-1(假設element從0開始)
a1：編碼行a0後第1個transition位置
a2：編碼行a0後第2個transition位置
b1：參考行(前一行)a0後第1個transition位置(值與a0相反)
b2：參考行(前一行)a0後第2個transition位置

Pseudocode

initialize a0
detect a1, b1, b2
if (b2 < a1) {
    Pass mode encoding
    a0 = b2
} else {
    if ( abs(a1-b1) <= 3 ) {
        Vertical mode encoding
        a0 = a1
    } else {
        detect a2
        Horizontal mode encoding
        a0 = a2
    }
}

課本的例子Example 1:
參考行
編碼行

■□□□■■■■■□□■■■□□□□■■■□□□
■■■■■■■□□□□□□□□□□■■■■■□■

未完…

期末考記錄用
參考自此但我覺得需要修改

LZW compression

string = NULL;
while character = next input character{
    if string+character is in table {
        string = string + character
    } else {
        output code of string
        add string+character to table
        string = character
    }
}

LZW decompression

while code = next input code {
    if code is new code {
        string = translated code
        output string
        // string(0) is the first character of string
        add prevString+string(0) to table
    } else {
        add to table for known code sequence
        string = translated code
        output string
    }
    prevString = string
}

如果你常用Matlab寫矩陣運算，一定對這個變數瀏覽工具不陌生，這真是太美好了，可以一眼望盡矩陣內所有的數值，如果你有更大的螢幕，甚至可以想像如Nash一樣在數字海中找到真理

但是這些美夢到visual studio中卻應聲破裂，散亂成16進位的記憶體亂碼，本文就是要帶領你回到美好的debug時光，重拾回可以”看見”的資料

(more…)

最近有空看了不少平行化的技術和語言，寫此篇作為紀錄

平行化就硬體層面來說可分為CPU和GPU兩種平行化，CPU的平行化我們稱之為Multi-Thread，也就是我們所熟知的執行緒；而GPU的平行化運算統稱為GPGPU(General-purpose computing on graphics processing units)，泛指在GPU上非rendering的計算。而GPU的thread與我們常見的CPU thread不太相同(可異質的thread，如GUI與背景計算)，他必須是要「相同執行步驟」的thread(如矩陣運算)，才能由GPU執行平行化，所以在撰寫的思考會比較沒有自由。

接下來則是我們常見的CPU與GPU平行化的framework

CPU:

• Pthread:本是UNIX的thread，目前有許多跨平台的版本，實做了複雜的thread介面與同步機制
• openMP:與compiler綁定的#pragma巨集語法，目前大多數的C/C++ compiler都有支援(VC2010)，使用相當簡單迅速
• windows.h: 與pthread類似，但不跨平台

對初學者來說，我相當建議使用openMP來實作平行化，如果有寫過matlab的平行化「parfor」，openMP就是差不多的東西，並且也實作非常容易使用的同步機制如「critial」，優點是其巨集式的語法，並且可以在需要的時後跳過巨集語法變回single thread的程式(方便debug)，具有撰寫快速、維護容易的特性，讓我們可以專注在平行邏輯，而不是在封裝thread function。缺點是要寫出複雜的同步邏輯如condition就比較無力。但是對於非real time導向的科學計算加速很有幫助，要處理伺服器的複雜同步機制還是得使用自定thread function的傳統thread(如pthread)。

GPU:

• Nvidia CUDA: 目前最完整的GPGPU framework，包括了許多類似STL的加速資料結構與矩陣計算函式，如果你想省時間學習開發，選CUDA
• ATI Stream: 他們跑去玩openCL了~
• Miscrsoft DirectCompute: 微軟基於DirectX的GPGPU framework，理所當然的windows ONLY
• openCL: 由許多廠商共同支援跨GPU的通用framework，理論上是可以支援所有顯卡的，不過由於跨平台的特性，所以語法更低階更難寫，並且發展緩慢，但是在未來會成為主流

所以結論就是CUDA(啥?)，你甚至可以使用類似openMP的#pragma語法來實作GPU thread，叫做HMPP，其主要規格定義在openHMPP，但這軟體是要錢的…

Intel為什麼沒有參一腳呢? 按照我在研討會上聽到的資訊，他們認為GPU以運算時間做為效能依據不夠客觀，應以工耗比(Performance/Power)來競爭才夠客觀，畢竟現在顯示卡已經可以算是一個小型主機版架構了，所以他們認為CPU是很給力的(了不起我們再買NV嘛)~~~

原本用的NIKE運動水壺也不錯，就是吸嘴部分久了感覺有點髒，但卻無法更換，所以只能整個水壺換掉。SIGG水壺的模組化相當不錯，瓶身也是一體成形，瓶口則是分為窄瓶口與寬瓶口兩種，寬瓶口比窄瓶口多了一個寬瓶上蓋，而最上面的開口則是與窄瓶口的零件相同，兼具了易清洗及飲用的特性，當然價格也比窄瓶貴一些。(新版的內部塗料已經沒有BPA)

瓶蓋方面則是有兩種可以選擇，一種是如照片的立體瓶蓋，也有類似牛奶瓶的”平”蓋可以選擇，口徑皆相同可以替換。新買的瓶子有金屬臭味，店員說是由國外工廠直接進口還未清洗，所以需要先泡水幾次去味

，

最近很紅的AKB48虛擬偶像阿~

雖然同一樓層的蔡教授早就在做了，我本來也想趕流行製作虛擬正妹的說

信手拈來就是個──魚柱小姐

我不信邪多按了幾次隨機產生，但僅是多了些魚柱小姐的兄弟姊妹…

人體鍊成果然是禁忌阿…

這是我點的煙燻雞三明治。
看這超大的三明治，根本很難用優雅的吃相解決它。美式餐點不僅食材有外國的粗獷感，就連吃法也相當野蠻呀，旁邊附的小菜是台式泡菜和薯條。

(more…)