首先釐清幾個關鍵OpenCL是什麼？NV的CUDA還是AMD的APP又是？為何要用GPU加速？
在評估速度之前必須先瞭解以上這些東西是什麼。
OpenCL是一種讓不同運算架構的處理器之間能夠協同運算或是溝通的平台。
CUDA與APP則是NV與AMD各自的圖形處理核心運算架構，自家設計好硬體，然後釋出能夠呼叫這些硬體資源的函式庫，讓工程師開發程式時知道用哪個函式可以調用記憶體、或指定多少顆CUDA或Stream核心來做什麼事情。
GPU加速的起源：
電腦的運算指令大概可分為兩類，一種是浮點運算、另一種是普通整數運算，通常普通軟體僅需要整數運算就能解決大部分的問題，但關於影像、多媒體、三維虛擬實境這類的處理卻必須有非常高的浮點運算能力才行，所以將浮點運算交給另個IC來處理的2D、3D加速卡概念就出來了，之後演變成如今這種局面，利用浮點運算能力非常強大的GPU核心來處理影像、圖形資訊，而CPU則專心負責通用運算處理，專才專用、可喜可賀。
正因為上述原因CPU與GPU的結構差異非常大，CPU因為要能夠快速處理所有電腦內的資訊所以單一核心的硬體元件數非常多，所以在製程上不太可能有太多個核心在同一個封裝上，因為元件數量太高所以會使發熱量提昇，在散熱能力有限的情況下，能容納的核心數非常有限。而GPU則相反，由於圖形處理有自己的規範（OpenGL與Direct X）GPU僅需要處理限定的指令，可以說硬體是專門為了支援這些規範而做了最佳化，所以單一核心的元件數量並不像CPU這樣肥大，導致GPU單一個封裝能容納的核心數量就遠高於CPU了，用我的電腦作為實際案例好了，CPU是X3 435如其型號有三個核心，顯示卡為AMD的R 5770有800個核心，三比上八百，GPU內的核心數量比CPU多了兩百多倍。
於是有人在比對這個數量差異之後突發奇想：如果讓這麼大量的核心一起幫我做運算，那效率豈不是等於有一個八百核的處理器？那Xeon或i7的12核算什麼？所以在得知這個構思後，NV覺得有搞頭，在2007年2月15日最早搶了頭香做出了GPU加速的雛型「CUDA」，想取得以自家顯卡加速的先機，而蘋果公司也對GPU加速起了興趣，在做了初步研究之後發現自己一家公司做可能沒搞頭，必須要結合各家廠商建立一個通用架構，所以在2008年6月16日時與 AMD, IBM, Intel, Nvidia共同向 Khronos Group這個開放運算架構組織提出了「OpenCL」的架構，起初僅支援類似CPU與GPU這種本來就在PC很普及的零件上，後來隨著ARM公司(手機處理器架構的創始者)的加入，如今OpenCL也壯大到能夠支援手機的ARM架構處理器了，如果你有能力開發系統，理論上甚至能把一堆手機核心並列起來組成超級運算雲，這是題外話...。
轉檔有兩個階段，一、將影片檔案「解碼」變成「影像」，二、將影像轉存成檔案則稱為「編碼」。而轉檔最慢的部份在於「編碼」上。目前GPU的運算從07年到現在才發展沒多久，在這短短幾年內很難開發出一個能夠「有效」利用GPU的核心數的「編碼器」。雖然利用到所有GPU核心幫你工作理論上是可行的，但實際上這種程式的撰寫非常之不易，因為工程師要將原本在CPU處理時是一整長串影片數據的大量指令，分解成許多個指令給不同核心各自去處理，最後再將所有處理完的資料同步組合起來，這些都很傷腦力，且需要影像方面的應用數學家來配合才能達成。另外，硬體上也是處處碰壁，主要難處在於資源分配的部份，尤其是分配記憶體的部份，工程師很難決定要如何分配資料要存放在主記憶體或顯示記憶體上，因為PCI-E介面卡要經過晶片組作為溝通橋樑DDR(主記憶)體與GDDR(顯卡記憶體)面間溝通非常緩慢），另外指令能夠分解的數量有限，並非所有指令都能夠分解成許多小單位給大量的顯示核心並行運算，總之目前由於硬體的限制，導致軟體的開發處處都是困難，但為了達到以往都沒想過的速度...這些是開發必經的過程。
結論：
簡單來說，是目前正處在軟體、硬體都還正在發展的「磨合期」，目前軟硬體兩方面都在急劇進步當中，像是AMD公司就非常具有前瞻性地收購下ATI然後將CPU與GPU融合產生了APU這種東西，且一直在修改架構準備將GPU部份能夠有效為通用運算進行加速，而AMD在下一代APU當中也提出了HSA架構的概念，讓GPU與CPU共享主記憶體，如此一來便沒有像是與PCI-E介面卡間還要經過晶片組的頻寬瓶頸了，可謂GPU加速的一大進步，相信Intel與Nvidia也會馬上跟進，這樣良性競爭下最終將會使軟體與硬體都將同步提昇轉檔效率，所以我們消費者與廠商都是雙贏的，但需要時間等待就是了，目前還享受不到「真正解放」的GPU加速轉檔或者加速運算...。
就算你買了有很多核心的顯卡，目前也沒有軟體能夠「有效」發揮它的效能，所以核心數目絕不會是你考慮買卡來轉檔的主因，但如果說你有其他運算需求（如3D算圖、Adobe CS6全），或者你是程式開發者，那你可以買張2~3千元的卡，不論AMD或NVIDIA都可，反正都支援OpenCL來加速運算。
如果你注重畫質，x264軟體編碼器將是最佳選擇，它擁有CPU上的最高速度，以及對H.264各層級的架構支援度非常高，還能搭配Avisynth的各種濾鏡來處理影片，另外如果你要利用FFT(沒聽過就略過吧...)來去除雜訊，Avisynth也提供了使用GPU加速的濾鏡DLL我自己測試時GPU Loading幾乎都在100％。目前這套x264軟體編碼器亦有人正將它搬往OpenCL上不過目前還不穩定，各位可以關注x264之後的動態。
如果你注重速度，但又不想失去太多畫質，那你可以考慮支援OpenCL的編碼器，像是MainConcept H.264 Encoder、Xilisoft Video Converter Ultimate 6、Handbrake(Beta測試版)等軟體來進行轉檔編碼。
我個人是建議使用MainConcept H.264 Encoder，雖然加速幅度不大，不過它所提供的的畫質與軟體編碼相差彷彿，使用上比較困難，需要一定專業知識。
如果MainConcept操作介面上的單字看不懂...請直接使用Xilisoft Video Converter Ultimate 6，它沒有很多複雜艱深的詞彙、有中文版本，但產出的檔案較大（壓縮率較低）。
關於上面提到更有效率的CPU+GPU協同機制，AMD端將會推出hUMA共享主記憶體，Intel端則是早早就已經實作了。
Intel的作法是從Sandy Bridge開始，就已經讓內顯跟CPU核心都掛到內部超高速Ring Bus上，內顯可以跟CPU核心處於同等地位、從比記憶體快得多的L3快取直接存取CPU/內顯之間共享的資料，盡量不透過比快取慢很多的記憶體。先把穩固地基打好後，接下來就是持續在IVB、Haswell、Broadwell、Skylake....繼續堆電晶體加強內顯本身遊戲跟異質計算的能力，並持續改進高速Ring Bus的頻寬跟運作。
下圖是Sandy Bridge的示意圖，Ivy Bridge/Haswell基本上也都是基於類似的Ring Bus架構讓CPU跟GPU可共享L3快取，但有持續改善效能跟效率：
AMD Kaveri APU會採用hUMA，Llano/Trinity/Richland APU是透過更傳統的Snooping跟記憶體複製的方式，但不管是Kaveri/Trinity/Richland/Llano APU，都還只是在較慢的記憶體階層下功夫，還不敢大刀闊斧把GPU直接連到內部快取上。畢竟AMD礙於製程問題，在APU上連L3快取都取消了，也無從透過L3讓CPU跟GPU共享資料；而擁有L3快取的FX系列，則是無法再有空間納入內顯。
下圖是hUMA的概念：
hUMA是用來解決AMD自家CPU/內顯溝通效率未最佳化的問題，而Intel除了在Sandy Bridge時已經把CPU跟GPU之間的溝通方式打掉重練過、可以共享L3快取之外，在Intel處理器上執行OpenCL的程式，CPU跟GPU也是已經可以用類似於uHMA的方式共享/存取相同的實體記憶體區塊的，可參考Intel的OpenCL白皮書跟OpenCL程式設計指南：
http://software.intel.com/en-us/articles/opencl-the-advantages-of-heterogeneous-approach
http://software.intel.com/en-us/forums/topic/277703
換個角度看，Intel要繼續改進記憶體共享的機制，不會比當初在Sandy Bridge上加入Ring Bus架構/並把GPU也掛上L3快取來得更有挑戰，畢竟最難的架構打掉重建工作已經熬過去了。但是AMD要大幅度敲掉架構、把內顯也掛到L3快取上面去，首先得要有能把L3快取加回APU、或是能在FX上加入內顯的製程餘裕，因此不管從架構設計面、生產製程面來看，都將會是工程浩大。
原來Intel早已有了先見之明，將記憶體設計成「直通共享」，Intel支脈已經貫通了，正在鍛鍊內息；AMD則是相反、內息很充盈，但因為支脈尚未貫通，沒法發出大招。
既然GPU都有能力即時處理一堆影像資訊了，沒道理不能操滿所有核心來共同演算，只缺在分散式軟體演算架構尚未成熟。
