針對CUDA的GPU架構知識與性能對比

     5年前將《GPU Gems 2》中的“Octree Textures on the GPU”用到了論文的實時紋理創(chuàng)作一節(jié)，那時候CUDA才剛出生，OpenCL應該還在規(guī)范階段，所以將GPU用于加速和通用計算的成熟方法還是compution by texturing。至于同樣的計算量在CPU和GPU上跑，性能到底提升多少，也沒有做過對比實驗。周末翻了下《CUDA by Example: An Introduction to General-Purpose GPU Programming》，基本掌握了用CUDA編寫GPU思想和語法，比起將數(shù)據(jù)做為紋理、Shader寫算法來，進步了不少：1）開發(fā)人員不需要熟悉渲染管線及圖形API；2）不用花時間去搭建DX或者OpenGL的框架；3）Host與Device代碼混編；4）不必采用Hacking思想處理包裝成紋理的數(shù)據(jù)；5）可指定參與計算的線程數(shù)。有了如此方便的編程環(huán)境，就隨手來做一下對比吧，這個例子來自《CUDA by Example》的4.2.2生成Julia集。

     測試代碼需要做一些調(diào)整，才能更好地體現(xiàn)出GPU的平行計算優(yōu)勢，這其中牽涉到支持CUDA的GPU架構知識，在這里做一下梳理。

     在Nvidia推出Fermi架構之前，支持CUDA的Nvidia顯示芯片都是由多個Streaming Multiprocessor（簡稱SM）組成，每個SM包含了八個Stream Processor（簡稱SP），每四個SP組成一個組，也就是說SM實際上可以看成包含兩組4D的SIMD處理器。此外，每個SM還包含Register、share memory、texture cache以及constant cache。在執(zhí)行 CUDA 程序的時候，每個SM對應一個 block，而每個SP就是對應一個 thread。雖然一個SM只有八個SP，但是由于SP進行各種運算都有延遲，更不用提內(nèi)存存取的延遲了，因此 CUDA 在執(zhí)行程序的時候，實際是以 warp 為單位。目前的支持CUDA顯卡，一個 warp 里面有32個 threads，分成兩組16 threads的half-warp。由于SP的運算至少有4個時鐘周期的延遲，因此對一個4D的SP來說，一次至少執(zhí)行16個 threads(即 half-warp)才能有效覆蓋掉各種運算的延遲[1]。

圖 1

     在GeForce GTX 400系列上，Nvidia采用了全新的Fermi架構[2]，之后的顯卡的Compute Capability也從1.3躍升至2.0。SP改名為CUDA Core，提升到了32個/SM[3]。圖2為Fermi核心演變，從GF104和由其發(fā)展起來的GF114、GF106、GF108的CUDA Core都上升到了48個/SM，支持2.1的Compute Capability，而GF100和GF110依舊是32個。最新基于Kepler架構的GeForce GTX 680支持3.0的Compute Capability，CUDA Core數(shù)量達到了192個/SM。

圖 2

     由于測試平臺采用的是GTX 560 Ti，所以需要分析一下它的架構。GTX 560 Ti由8個SM組成，下圖中，左邊是從程序獲取的設備屬性，右邊為單個SM內(nèi)部結構示例圖。可以看到，GTX 560 Ti的每個SM配備了兩個Warp調(diào)度器，因此每個周期對兩個包含32個線程的Warp進行分發(fā)。另外，對于一個二維圖像，為kernel指定2D的grid和block可使代碼更加直觀。為此，block采用（16,16），總共分配256個（64*4）threads在一個SM上執(zhí)行，如果需要產(chǎn)生1024*1024的Julia分形圖，則需要grid為（64,64）。

圖 3

     測試平臺為：

     測試代碼說明：

     1）代碼分為CPU實現(xiàn)和CUDA實現(xiàn)；

     2）均采用CPU計時方法；

     3）只針對計算部分測試，不包括內(nèi)存分配、傳輸以及文件寫入；

     下面列出main函數(shù)代碼，左邊為CPU實現(xiàn)，右邊為CUDA實現(xiàn)，均編譯為release版本。

     測試結論：CPU版本耗時244ms，CUDA版本耗時2.1087ms。這可是100倍的效率提升啊。不過CPU版本沒有經(jīng)過多核優(yōu)化，所以這樣這樣對比實在不公平，但這卻凸顯出CUDA C將并行思想融入語言規(guī)則的優(yōu)勢。

     在驚訝GPU用作通用計算的執(zhí)行效率時，別忘了它還是有諸多應用上的問題：

     1)初始化耗時，需要在顯存分配空間，然后將數(shù)據(jù)從內(nèi)存copy到顯存；
     2)數(shù)據(jù)量受GPU顯存限制；
     3)對本身就需要GPU參與運算的程序，如：3D游戲，通用計算會爭奪GPU資源，如果做平衡？
     4)計算數(shù)據(jù)之間的不相關性限制了GPU通用計算的應用范圍；

     5)CPU算法到適合GPU架構算法的移植；

     最后，GPU硬件設計本身就已經(jīng)決定了它的強項是密集數(shù)據(jù)處理（如：科學計算、醫(yī)療圖像處理），在邏輯處理方面還是CPU的天下，所以它們是互補的，只會有整合而非替代的趨勢。

[1] http://www2.kimicat.com/gpu%E7%9A%84%E7%A1%AC%E9%AB%94%E6%9E%B6%E6%A7%8B

[2] http://www.chip.cn/index.php?option=com_content&view=article&id=2857:geforce-gtx-400-gpu&catid=7:test-technology&Itemid=15

[3] http://www.geeks3d.com/20100606/gpu-computing-nvidia-cuda-compute-capability-comparative-table

[4] http://www.expreview.com/13590-2.html

[5] http://en.wikipedia.org/wiki/CUDA

posted on 2012-11-27 23:13 Heath 閱讀(3869) 評論(4)  編輯 收藏 引用 所屬分類: Graphics Programming