隨著GPU的可編程性不斷增強，GPU的應用能力已經遠遠超出了圖形渲染任務，利用GPU完成通用計算的研究逐漸活躍起來，將GPU用于圖形渲染以外領域的計算成為GPGPU（General Purpose computing on graphics processing units，基于GPU的通用計算）。而與此同時CPU則遇到了一些障礙，CPU為了追求通用性，將其中大部分晶體管主要用于構建控制電路（比如分支預測等）和Cache，只有少部分的晶體管來完成實際的運算工作。

CPU + GPU 是一個強大的組合，因為 CPU 包含幾個專為串行處理而優化的核心，而 GPU 則由數以千計更小、更節能的核心組成，這些核心專為提供強勁的并行性能而設計。程序的串行部分在 CPU 上運行，而并行部分則在 GPU上運行。GPU 已經發展到成熟階段，可輕松執行現實生活中的各種應用程序，而且程序運行速度已遠遠超過使用多核系統時的情形。未來計算架構將是并行核心 GPU 與多核 CPU 共同運行的混合型系統。

一、CPU多核轉到GPU并行化（適合算術密集型）

雖然GPU并不適用于所有問題的求解，但是我們發現那些對運算力量耗費巨大的科學命題都具備天然的“”特色。這類程序在運行時擁有極高的運算密度、并發線程數量和頻繁地存儲器訪問，無論是在音頻處理、視覺仿真還是到分子動力學模擬和金融風險評估領域都有大量涉及。這種問題如果能夠順利遷移到GPU為主的運算環境中，將為我們帶來更高效的解決方案。

傳統意義上的GPU不善于運行分支代碼，但是ATI和NVIDIA經過長期改進其內部架構已經使得GPU可以較為高效地運行分支、循環等復雜代碼。同時因為GPU屬于并行機范疇，相同的運算可以應用到每個數據元素的時候，它們可以達到最好的性能。在CPU編程環境中，寫出每個輸入數據元素有不同數量的輸入的程序很容易，但在GPU這種并行機上還是有不少麻煩。

通用的數據結構正是GPU編程的最大困難之一。CPU程序員經常使用的數據結構如列表和樹在GPU身上并不容易實現。GPU目前還不允許任意存儲器訪問，而且GPU運算單元的設計為主要操作是在表現位置和顏色的四維向量上。

不過這些并不能阻擋GPU編程的加速發展，因為GPU不是真的為通用計算而設計的，需要一些努力才能讓GPU高速地服務通用計算程序。這些努力前些年是程序員而單獨實現的，而隨著ATI和NVIDIA開始看到高性能計算市場的硬件需求，我們看到無論是Fermi架構添加全能二級緩存和統一定址還是RV870架構不斷優化LDS并放大并發線程數，這些都是GPU自身硬件體系為了適應未來的運算環境而做出的變革。

二、并行化編程優點

在GPU并行編程過程中，OpenCL是一個不錯的選擇。OpenCL是Open Computing Language（開放式計算語言）的簡稱，它是第一個為異構系統的通用并行編程而產生的統一的、免費的標準。OpenCL支持由多核的CPU、GPU、Cell類型架構以及信號處理器（DSP）等其他的并行設備組成的異構系統。OpenCL的出現，使得軟件開發人員編寫高性能服務器、桌面計算系統以及手持設備的代碼變得更加快捷。OpenCL由用于編寫內核程序的語言和定義并控制平臺的API組成，提供了基于任務和基于數據的兩種并行計算機制，使得GPU的計算不在僅僅局限于圖形領域，而能夠進行更多的并行計算。但是，如果通過傳統的方法開發一個能夠運行在異構平臺（在CPU和GPU的平臺）的程序是很難的。不同的廠商，不同的產品型號的GPU一般有著不一樣的架構，這樣要想開發出一款能夠高效的能夠運用不同平臺的所有計算資源的軟件是很難的。OpenCL的出現有效地解決了異構平臺的問題。

OpenCL規范是由Khronos Group推出的，OpenCL程序不僅僅可以運行在多核的CPU上，也可以在GPU上進行執行，這充分體現了OpenCL的跨平臺性和可移植性，也讓編程人員可以充分利用GPU的強大的并行計算能力，相對于CPU來說，GPU存在很多特點。

l GPU擁有的核心的數量要比高端CPU的核心數量多很多。雖然GPU的每個運算核心沒有CPU的每個運算核心工作頻率高，但是GPU的總體性能-芯片面積比以及性能-功耗比比CPU高很多，所以在處理越多線程的并行計算的任務性能高很多。

l GPU能夠通過大量并行線程之間的交織運行隱藏全局的延遲，除此之外GPU還擁有大量的寄存器、局部存儲器和cache等用來提升外部存儲的訪問性能。

l 在傳統的CPU運算中，線程之間的切換是需要很大的開銷的，所以在開啟了大量線程的算法的效率是很低的。但是，在GPU中，線程之間的切換是很廉價的。

l GPU的計算能力比CPU強很多。

三、OpenCL環境下并行化編程

OpenCL是一個開放的工業標準，它可以為CPU和GPU等不同的設備組成的異構平臺進行編程。OpenCL是一種語言，也是一個為并行編程而提供的框架，編程人員可以利用OpenCL編寫出一個能夠在GPU上執行的通用程序。

OpenCL的技術核心包好了下面的四種模型：

l 平臺模型（Platform Model）：OpenCL平臺模型定義了主機和設備的角色，為程序員寫在設備上執行的OpenCL C函數（內核）提供了一個抽象的硬件模型。平臺模型確定了主機上的處理器能夠協調執行，而且存在一個或者多個處理器能夠執行OpenCL C代碼（設備）。

l 執行模型（Execution Model）：定義如何在主機上配置OpenCL環境以及內核（kernel）是如何在設備上執行的。這其中包括在主機上設置OpenCL上下文，提供主機和設備交互的機制，定義了內核在設備上執行的兵法模式。

l 內存模型（Memory Model）：定義了內核使用的抽象的內存層次。

l 編程模型（Programming Model）：定義了并發模型如何讓映射到物理硬件。

OpenCL框架被分成平臺層API和運行時API，平臺層API允許應用查詢平臺和設備，而且可以通過上下文來管理它們。運行時的API利用上下文去管理設備上的內核的執行。

四、OpenCL并行化調試工具

在利用OpenCL進行編程之后，我們可以使用gDEBugger進行調試，gDEBugger是一個高級的OpenCL和OpenGL調試器，分析器和內存分析器。它可以完成其他工具無法完成的工作：追蹤在OpenCL和OpenGL之上的應用程序的活動，并發現系統實現的內部發生了什么。

程序員可以在以下的情況下使用gDEBugger

l 優化OpenCL和OpenGL應用程序性能。

l 快速找到與OpenCL和OpenGL相關的bug。

l 改善程序性能和魯棒性

五、CPU和GPU共享記憶體空間

在過去的時間，雖然GPU和CPU已整合到同一個晶片上（GPGPU技術），但是晶片在運算時要定位記憶體的位置仍然得經過繁雜的步驟，這是因為CPU和GPU的記憶體池仍然是獨立運作。之前為了解決兩者記憶體池獨立的運算問題，當CPU程式需要在GPU上進行部分運算時，CPU都必須從CPU的記憶體上復制所有的資料到GPU的記憶體上，而當GPU上的運算完成時，這些資料還得再復制回到CPU記憶體上。這些步驟都會不斷耗費時間以及程式處理的效能。2012年，AMD就攜手ARM、高通、三星、聯發科等廠商成立HSA（Heterogeneous Systems Architecture）基金會，希望拓展CPU和GPU協同運算的新架構，并輔助此架構發展的異質運算新軟體開發環境。

日前，AMD進一步公開說明此運算架構的新技術：hUMA（heterogeneous Uniform Memory Access）。透過hUMA，CPU和GPU能共享同一個記憶體空間，并且CPU能夠直接存取GPU的記憶體位址，不必像過去得花工夫再將GPU的運算資料復寫到CPU上。近日，在HotChips會議上，AMD連續公布了桌面FX處理器使用的Steamroller架構、面向低功耗平臺的Jaguar架構等，但是這都不是AMD的終極目標，他們聲稱處理器速度的競爭已經結束，未來屬于HSA。

六、未來發展趨勢

在計算機發展歷程中，為了解決各種特定的問題，不斷有互不兼容的計算模塊被加入系統，卻很少從全局優化的角度加以考察。計算機整體效率不高的現狀正是這種設計模式的直接后果。常見情況是軟件的計算負載被調度在一個并不適合當前任務的計算設備上低效執行。HSA則展現了一種全新的體系架構，可以適應各種特性的計算任務。

HSA版本可以在CPU和GPU之間無縫地共享數據，而無需內存拷貝和緩存刷新，因為任務以極低的開銷被調度到合適的處理器上。最終的結果是HSA版本的性能高出2.3倍，而功耗降低2.4倍*。相較而言，無論是多核CPU、GPU、甚至非HSA方式的混合CPU和GPU都無法達到這樣的性能水平。同樣重要的是，無需轉換到迥異的編程模型，僅僅通過C++的簡單擴展就可以實現程序。