??? 畫外音：不知道我的6200A排在什么地方哈哈。
??? 其實上圖有偏頗，這張圖節選自Siggraph2004，而現在ATi 1800XT的SIMD性能已經超過了6800好多，可不是游戲性能。不過可以看出，比CPU的浮點運算性能高好幾倍是不真的事實，可是如何利用呢？
??? 可編程硬件的到來為我們開了一個好頭，也許未來計算機硬件的發展趨勢就是，通用計算Generic Computing（GC，自造詞匯，可不是垃圾收集）。顯卡一直以來都是和Pixel打交道，讀取Texel，處理Primitive，寫入FrameBuffer，為SIMD的應用打下了堅實的基礎。顯卡芯片從開始就是并行設計的，這樣從紋理單元讀取Texel時才能發揮效力，當年大名鼎鼎的Riva TNT2的意思其實是TwiNs Textures雙紋理，而不是黃色炸藥。Geforce3依靠添加的幾個昂貴的register實現了Vertex Programming。NV收購3dfx，推出NV30系列芯片，伴隨著DX8為PC機引入Shader，開創PC機圖像畫質飛躍的先河，如今熱門游戲大多數已經使用可編程著色技術用來實現以往在工作站上才能實現的效果，這就是為什么如今看游戲實時演算的畫面都比當年Square動用sgi工作站集群渲染出來的FF8動畫效果好的原因。其實高級CG圖形理論在80年代就已經相當成熟，比如78年的Shadow mapping，White的Ray-tracing等等。那些技術以后我會慢慢給大家介紹，大家不妨去NVIDIA下載一個SDK研究一下，還有MS DX SDK也是必需的。
??? 先說目前可編程硬件用作通用計算的局限，而且在我看來，這個局限在Vista與DX10流行后可能依舊得不到解決，那就是API的問題。顯卡廠商提供的驅動，無一例外的都是徹底為顯示服務的，而不是用來標榜自己是GPGPU的。雖然說都有了自己的本地編譯器（主要是用于編譯GLSL string codes，HLSL可以預先編譯好，然后再由驅動載入執行），可是依舊不是為了計算非圖形數據服務。于是找到了Sh。Sh是一個很有趣的東西，使用了metaprogramming技術，模擬圖形語言的算法，編譯的時候轉化為對應的低等級ASM語句，很多Graphic Slide里面進行核心算法展示的時候都用的Sh。有興趣地可以到
這里看一下。強烈建議顯卡廠商推出可以直接進行計算的驅動，不要和FrameBuffer牽涉，可以直接通過Bus寫入內存，技術上并不難，也許是個商業問題。關鍵時刻永遠是商業左右技術的發展，而不是技術人員的一廂情愿就可以左右世界發展，如今已經不是工業革命時代了。
??? 給大家介紹來自Starford University的
Brook（聽起來好像廣告，不過在Shading Language界可是有Starford Shading Language得一席之地的）。Brook可以理解為是一個C編譯器，只不過它編譯的不是Bin，而是C++ string codes，而且是著色計算語句數組。比如有這樣一段Brook代碼，簡單的Alpha混合，不對，不像，反正就是它了：
kernel?void?saxpy(float?alpha,?float4?x<>,?float4?y<>,
out?float4?result<>)?{
result?=?(alpha?*?x)?+?y;
}
???
??? 編譯成最終的C++代碼變成，
static?const?char*?__saxpy_fp30[]?=?{
"!!FP1.0\n"
"DECLARE?alpha;\n"
"TEX?R0,?f[TEX0].xyxx,?TEX0,?RECT;\n"
"TEX?R1,?f[TEX1].xyxx,?TEX1,?RECT;\n"
"MADR?o[COLR],?alpha.x,?R0,?R1;\n"
"END?\n"
"##!!BRCC\n"
"##narg:4\n"
"##c:1:alpha\n"
"##s:4:x\n"
"##s:4:y\n"
"##o:4:result\n"
"##workspace:1024\n"
"##!!multipleOutputInfo:0:1:\n"
"",NULL};
void?saxpy?(const?float?alpha,const?::brook::stream&?x,const?::brook::stream&?y,
::brook::stream&?result)?{
??? static?const?void?*__saxpy_fp[]?=?{"fp30",?__saxpy_fp30,?"ps20",?__saxpy_ps20,
??? ??? ??? ??? ??? "cpu",?(void?*)?__saxpy_cpu,?NULL,?NULL?};
??? static?__BRTKernel?k(__saxpy_fp);
??? k->PushConstant(alpha);
??? k->PushStream(x);
??? k->PushStream(y);
??? k->PushOutput(result);
??? k->Map();
}
???
??? 這不就是純粹的Shading Language么。不過值得注意的是，Brook通過運行庫進行封裝，把GPU當作Streaming Processor，由CPU進行控制，計算數據并輸出。目前似乎只能進行圖形的計算，比如FFT，Ray-Tracing等演示，還沒有到達能夠計算pi的程度。
??? 思考了一下。精度問題需要解決，FP16剛剛開始廣泛使用，FP32還不能夠支持硬件過濾。FP32僅僅只是IEEE754 float的精度而已，更本談不上double的精度，用在需要精度較高的地方可能還不是很適合。如我設想那樣，進行pi的幾百萬位的計算，目前來說不太可能，首先，Shading Language從來就沒有提供地址的操作，也就是無法選澤Pixel的位置，也就是無法對FrameBuffer進行準確定位。如果可以解決這個問題，那么就可以進行真正意義上的通用計算，那個時候FrameBuffer只是一個暫時的緩沖容器而已。
??? SIMD的物理計算可以相當的強悍。物理特性計算都是強調同時性的，而GPU可以同時并行計算，充分發揮了自己的優勢，難怪NVIDIA要和Havok進行合作。記得以前看過博客園中一位先生寫的物理引擎，著實震驚，我建議他不妨研究研究這一塊。Stream的概念將在DX10上得到徹底的詮釋，不妨看看我以前翻譯的DX10文章，其中Geometry Shader很有意思。
??? 我期待下一代API出現，一個嶄新的軟硬件組合方案，這樣就可能為Display Adapter這個古老的東西帶來真正的革命。值得注意的是，AMD已經收購了ATi，而Intel還在為100億美元收購NV的價格評估的時候，也許下一代變革已經開始了，讓我們拭目以待。
??? 提到的東西可以在這里找到
??? Brook
http://sourceforge.net/projects/brook??? libSh
http://sourceforge.net/projects/libsh