昨天在交大校慶一口氣敗入了兩台電腦，外觀照!

CPU當然是選擇最夯的i7...咦?

硬碟大手筆選擇了金士頓512GB SSD做為系統碟!! 咦????

DDR3...懶得吐槽了(這個真的很不像，ping腳太少了XD)

酷大師1200W電源XD

主機板和顯示卡都ASUS的!

裝機測試

我們一口氣填兩張問卷買了兩台，獲贈金士頓雕像一座XD

校園徵才的戰利品...

跟學校社團買的小草，還有最近很夯的拍立得

手拉坏XD

照片全部都是用手機拍的，1D回屏東老家了。題外話是廠商竟然有徵攝影師的，說不定有機會去當攝影師XD

假設我們都知道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

我遇到的問題是必須要做驚人次數的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

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時光，重拾回可以"看見"的資料

首先，我們要來看一小段讓人苦惱的C++程式碼，我們宣告了一個動態的整數陣列，維度是128，並且隨機的為他們分配的預設值

int dimension = 128;
int *d = new int [dimension];
for (int i=0; i < dimension; i++)
    d[i] = rand()%200000;

但是要怎麼一眼望盡呢?我們把滑鼠移到d這個指標上，得到一個記憶體位置，然後再按一下旁邊的+號，不出所料的，只得到第一個值。這並非我們一眼望盡的美夢

聰明的你一定馬上想到printf

for (int i=0; i < dimension; i++)
    printf("%d ", d[i]);

這麼做馬上會遇到一個問題，就是CMD視窗的行數限制會造成你閱讀困難，再來就是如果我需要debug多個變數，就必須要複製這段程式碼到各個角落，屆時你的程式碼中就會充滿細碎的test program，既骯髒又影響效能。偉大的M$怎麼可能沒有發現這個讓所有程式設計師苦惱許久的問題?尤其是在貴死人的visual studio上?

我們在中斷點上偵錯時，按下CTRL+ALT+I，開啟即時運算視窗，輸入"d,128"，你就會看到一整串的訊息，然後問，跟我printf有什麼不一樣= =? 最起碼你從2行變2個字了嘛~而且沒有弄髒你的程式碼不是嗎?

現在教你另一招，同樣在中斷點上偵錯時，按下ALT+6，開啟記憶體視窗，在位置欄位輸入你的指標位置，如上是"0x004d9158"，或是在按下右邊的"自動重新評估"後，在位置輸入"d"

這根本比前面更糟了不是嗎!!整個變成16進位的亂碼! 且慢，這時我們需要一點常識，int是32 bit的資料結構，也就是佔有4 byte的大小，並且我們宣告的int是帶符號的，所以我們按下右鍵，選擇"4個位元組整數"、"帶正負號顯示"

這時的結果已經相當接近matlab的顯示模式了，但是在column欄位上我們需要把一行定義成128個欄位，比較符合我們陣列的概念，把資料行由自動改為128就可以了。
當然你可以類推，若是double形態就選擇以64位元浮點數，是unsigned就選不帶正負號即可

平行化就硬體層面來說可分為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)

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

，