本文將作為我《從零開始做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上程式設計可不是容易的事，你只能使用GPU彙編來寫GPU程式，GPU彙編？聽起來就是很高階的玩意兒，所以那時使用GPU繪製很多特殊效果的技能只掌握在少數圖形工程師身上，這種方式叫可程式設計管線。

    很快這種桎桍被打破，GPU上的高階程式語言誕生，在當時更先進的一些顯示卡上（記憶中應該是3代顯示卡開始吧），像C一樣的高階語言可以使程式設計師更加容易的往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上跑程式碼變得更容易。

  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過度依賴於特定硬體，產業應用前景並不好，只能做做工程試驗，你總不能讓使用者裝個遊戲的同時，讓他順便換個高配的N卡吧。所以一度也對這個領域不太感興趣，最近看到OpenCL的出現，發現可能這個架構還是有很好的應用前景的，也是眾多廠商目前合力力推的一個東西。想想一下一個迭代10000次的for迴圈一遍過，還是很激動的一件事。

  在遊戲領域，OpenCL已經有了很多成功的實踐，好像EA的F1就已經應用了OpenCL，還有一些做海洋的lib應用OpenCL（海面水波的FFT運算在過去是非常慢的），另外還有的庫乾脆利用OpenCL去直接修改現有的C程式碼，加速for迴圈等，甚至還有OpenCl版本的C++ STL，叫thrust，所以我覺得OpenCL可能會真正的給我們帶來些什麼~

以下是一些關於OpenCL比較重要的資源：