多謝大家關注 轉載本文請注明：http://blog.csdn.net/leonwei/article/details/8880012
本文將作為我《從零開始做OpenCL開發》系列文章的第一篇。
1 異構計算、GPGPU與OpenCL
OpenCL是當前一個通用的由非常多公司和組織共同發起的多CPU\GPU\其它芯片 異構計算（heterogeneous）的標准，它是跨平台的。旨在充分利用GPU強大的並行計算能力以及與CPU的協同工作，更高效的利用硬件高效的完畢大規模的（尤其是並行度高的）計算。在過去利用GPU對圖像渲染進行加速的技術非常成熟，可是我們知道GPU的芯片結構擅長大規模的並行計算（PC級的GPU可能就是CPU的上萬倍），CPU則擅長邏輯控制，因此不僅僅局限與圖像渲染，人們希望將這樣的計算能力擴展到很多其它領域，所以這也被稱為GPGPU（即通用處計算處理的GPU）。
簡單的說，我們的CPU並不適合計算，它是多指令單數據流（MISD）的體系結構，更加擅長的是做邏輯控制，而數據處理基本是單流水線的，所以我們的代碼for(i=0;...;i++)這種在CPU上要反復迭代的跑非常多遍，可是你的顯卡GPU則不是這樣，GPU是典型的單指令多數據（SIMD）的體系結構，它不擅長邏輯控制，可是確實天生的向量計算機器，對於for(i=0;...;i++)這種代碼有時僅僅須要跑一遍，所以圖形世界中那么多的頂點、片段才干高速的並行在顯卡中渲染處理
GPU的晶體管能夠到幾十億個，而CPU通常僅僅有幾個億，
如上圖是NVidia Femi100的結構，它有着大量的並行計算單元。
所以人們就想怎樣將很多其它的計算代碼搬到GPU上，讓他不知做rendering，而CPU僅僅負責邏輯控制，這樣的一個CPU（控制單元）+幾個GPU（有時可能再加幾個CPU）（計算單元）的架構就是所謂的異構編程（heterogeneous），在這里面的GPU就是GPGPU。異構編程的前景和效率是非常振奮人心的，在非常多領域，尤其是高並行度的計算中，效率提升的數量級不是幾倍，而是百倍千倍。
事實上NVIDIA在非常早就退出了利用其顯卡的GPGPU計算 CUDA架構，當時的影響是非常大的，將非常多計算工作（科學計算、圖像渲染、游戲）的問題提高了幾個數量級的效率，記得那時NVIDIA來浙大介紹CUDA，演示了實時的ray tracing、大量剛體的互相碰撞等樣例，還是激動了一下的，CUDA如今好像已經發展到了5.0，並且是NVDIA主力推的通用計算架構，可是CUDA最大的局限就是它僅僅能使用N家自己的顯卡，對於廣大的A卡用戶鞭長莫及。OpenCL則在之后應運而生，它由極大主流芯片商、操作系統、軟件開發人員、學術機構、中間件提供者等公司聯合發起，它最初由Apple提出發起標准，隨后Khronos Group成立工作組，協調這些公司共同維護這套通用的計算語言。Khronos Group聽起來比較熟悉吧，圖像繪制領域著名的軟硬件接口API規范著名的OpenGL也是這個組織維護的，事實上他們還維護了非常多多媒體領域的規范，可能也是類似於Open***起名的（所以剛聽到OpenCL的時候就在想它與OpenGl有啥關系），OpenCl沒有一個特定的SDK，Khronos Group僅僅是指定標准（你能夠理解為他們定義頭文件），而詳細的implementation則是由不同參與公司來做，這樣你會發現NVDIA將OpenCL做了實現后即成到它的CUDA SDK中，而AMD則將事實上現后放在所謂是AMD APP （Accelerated Paral Processing）SDK中,而Intel也做了實現，所以眼下的主流CPU和GPU都支持OpenCL架構，盡管不同公司做了不同的SDK，可是他們都遵照相同的OpenCL規范，也就是說原則上假設你用標准OpenCl頭中定義的那些接口的話,使用NVIDIA的SDK編的程序能夠跑在A家的顯卡上的。可是不同的SDK會有針對他們芯片的特定擴展，這點類似於標磚OpenGL庫和GL庫擴展的關系。
OpenGL的出現使得AMD在GPGPU領域最終迎頭趕上的NVIDIA，可是NVIDIA雖為OpenCL的一員，可是他們似乎更加看重自己的獨門武器CUDA，所以N家對OpenCL實現的擴展也要比AMD少，AMD因為同一時候做CPU和GPU，還有他們的APU，似乎對OpenCL更來勁一些。
2.關於在GPU上寫代碼的那些事兒
OpenCL也是通過在GPU上寫代碼來加速，僅僅只是他把CPU、GPU、其它什么芯片給統一封裝了起來，更高了一層，對開發人員也更友好。講到這里突然非常想贅述一些在GPU上寫代碼的那些歷史。。
事實上最開始顯卡是不存在的，最早的圖形處理是放在CPU上，后來發現能夠再主板上放一個單獨的芯片來加速圖形繪制，那時還叫圖像處理單元，直到NVIDIA把這東西做強做大，而且第一給它改了個NB的稱呼，叫做GPU，也叫圖像處理器，后來GPU就以比CPU高幾倍的速度增長性能。
開始的時候GPU不能編程，也叫固定管線的，就是把數據依照固定的通路走完
和CPU相同作為計算處理器，順理成章就出來了可編程的GPU，可是那時候想在GPU上編程可不是easy的事，你僅僅能使用GPU匯編來寫GPU程序，GPU匯編？聽起來就是非常高級的玩意兒，所以那時使用GPU繪制非常多特殊效果的技能僅僅掌握在少數圖形project師身上，這樣的方式叫可編程管線。
非常快這樣的桎桍被打破，GPU上的高級編程語言誕生，在當時更先進的一些顯卡上（記憶中應該是3代顯卡開始吧），像C一樣的高級語言能夠使程序猿更加easy的往GPU寫代碼，這些語言代表有nvidia和微軟一起創作的CG，微軟的HLSL，openGl的GLSL等等，如今它們也通常被稱為高級着色語言（Shading Language），這些shader眼下已經被廣泛應用於我們的各種游戲中。
在使用shading language的過程中，一些科研人員發現非常多非圖形計算的問題（如數學、物理領域的並行計算）能夠偽裝成圖形問題利用Shading Language實如今GPU上計算，而這結果是在CPU上跑速度的N倍，人們又有了新的想法，想着利用GPU這樣的性能去解決全部大量並行計算的問題（不僅僅圖形領域），這也叫做通用處理的GPU（GPGPU），非常多人嘗試這樣做了，一段時間非常多論文在寫如何如何利用GPU算了哪個東東。。。可是這樣的工作都是偽裝成圖形處理的形式做的，還沒有一種天然的語言來讓我們在GPU上做通用計算。這時又是NVIDIA帶來了革新，09年前后推出的GUDA架構，能夠讓開發人員在他們的顯卡上用高級語言編寫通用計算程序，一時CUDA熱了起來，直到如今N卡都印着大大的CUDA logo，只是它的局限就是硬件的限制。
OpenCL則突破了硬件的壁壘，試圖在全部支持的硬件上搭建起通用計算的協同平台，無論你是cpu還是gpu通通一視同仁，都能進行計算，能夠說OpenCL的意義在於模糊了主板上那兩種重要處理器的界限，並使在GPU上跑代碼變得更easy。
3 OpenCL架構
3.1 硬件層：
上面說的都是關於通用計算以及OpenCL是什么，以下就提綱挈領的把OpenCL的架構總結一下：
下面是OpenCL硬件層的抽象
它是一個Host（控制處理單元，通常由一個CPU擔任）和一堆Computer Device（計算處理單元，通常由一些GPU、CPU其它支持的芯片擔任），當中Compute Device切分成非常多Processing Element（這是獨立參與單數據計算的最小單元，這個不同硬件實現都不一樣，如GPU可能就是當中一個Processor，而CPU可能是一個Core，我猜的。。由於這個實現對開發人員是隱藏的），當中非常多個Processing Element能夠組成組為一個Computer Unit，一個Unit內的element之間能夠方便的共享memory，也僅僅有一個Unit內的element能夠實現同步等操作。
3.2 內存架構
當中Host有自己的內存，而在compute Device上則比較復雜，首先有個常量內存，是全部人能用的，通常也是訪問最快的可是最稀少的，然后每一個element有自己的memory，這是private的，一個組內的element有他們共用的一個local memery。細致分析，這是一個高效優雅的內存組織方式。數據能夠沿着Host-》gloabal-》local-》private的通道流動（這當中可能跨越了非常多個硬件）。
3.3軟件層面的組成
這些在SDK中都有相應的數據類型
setup相關：
Device：相應一個硬件（標准中特別說明多core的CPU是一個整個Device）
Context：環境上下文，一個Context包括幾個device（單個Cpu或GPU），一個Context就是這些device的一個聯系紐帶，僅僅有在一個Context上的那些Device才干彼此交流工作，你的機器上能夠同一時候存在非常多Context。你能夠用一個CPu創建context，也能夠用一個CPU和一個GPU創建一個。
Command queue：這是個給每一個Device提交的指令序列
內存相關：
Buffers：這個好理解，一塊內存
Images：畢竟並行計算大多數的應用前景在圖形圖像上，所以原生帶有幾個類型，表示各種維度的圖像。
gpu代碼運行相關：
Program：這是全部代碼的集合，可能包括Kernel是和其它庫，OpenCl是一個動態編譯的語言，代碼編譯后生成一個中間文件（可實現為虛擬機代碼或者匯編代碼，看不同實現），在使用時連接進入程序讀入處理器。
Kernel：這是在element跑的核函數及其參數組和，假設把計算設備看做好多人同一時候為你做一個事情，那么Kernel就是他們每一個人做的那個事情，這個事情每一個人都是相同的做，可是參數可能是不同的，這就是所謂的單指令多數據體系。
WorkI tem：這就是代表硬件上的一個Processing Element，最主要的計算單元。
同步相關：
Events：在這樣一個分布式計算的環境中，不同單元之間的同步是一個大問題，event是用來同步的
他們的關系例如以下圖
上面就是OpenCL的入門介紹，事實上說實話在10年左右就跟蹤過GPGPU相關的東西，那時非常多相關技術還存在於實驗室，后來的CUDA出現后，也激動過，學習過一陣，只是CUDA過度依賴於特定硬件，產業應用前景並不好，僅僅能做做project試驗，你總不能讓用戶裝個游戲的同一時候，讓他順便換個高配的N卡吧。所以一度也對這個領域不太感興趣，近期看到OpenCL的出現，發現可能這個架構還是有非常好的應用前景的，也是眾多廠商眼下合力力推的一個東西。想想一下一個迭代10000次的for循環一遍過，還是非常激動的一件事。
在游戲領域，OpenCL已經有了非常多成功的實踐，好像EA的F1就已經應用了OpenCL，另一些做海洋的lib應用OpenCL（海面水波的FFT運算在過去是非常慢的），另外還有的庫干脆利用OpenCL去直接改動現有的C代碼，加速for循環等，甚至還有OpenCl版本號的C++ STL，叫thrust，所以我認為OpenCL可能會真正的給我們帶來些什么~
下面是一些關於OpenCL比較重要的資源：
http://www.khronos.org/opencl/ 組織的主頁
https://developer.nvidia.com/opencl N家的主頁
http://developer.amd.com/resources/heterogeneous-computing/opencl-zone/ A家的主頁
http://www.khronos.org/registry/cl/sdk/1.2/docs/man/xhtml/ 標准的reference
http://developer.amd.com/wordpress/media/2012/10/opencl-1.2.pdf 必看 最新的1.2版本號標准
http://www.khronos.org/assets/uploads/developers/library/overview/opencl-overview.pdf 必看，入門的review