個人積分：716分
文章編號：44465122
個人積分：75分
文章編號：44485825
個人積分：22分
文章編號：44486989
你買下去?
個人積分：40分
文章編號：44487188
個人積分：27分
文章編號：44488689
Nuclearus Multi-Core、Cinebench 11.5......這些Benchmark當然還是可用，只是別忘了，Haswell還有不小的計算潛力，是這些Benchmark根本用不上、也測不到的。
OpenCL是CPU跟GPU異質協同運算的標準，也是趨勢，但似乎大部分認為Haswell跟IVB沒差的，還是停留在只有CPU能計算、GPU只能玩遊戲那種老舊觀念，如果是這樣，根本不需要關注新Haswell架構。
下面這些幾乎都是真實應用程式測試，用上了CPU+GPU協同計算，涵蓋的應用面也蠻廣的，包括影音編輯/轉檔、Photo編輯/製作、資料壓縮、財務計算、3D rendering算圖等等。
中央處理器版上常見硬體進步，軟體卻不跟上的抱怨；但是已經有軟體跟上了，這下似乎卻換成不少人腦袋裡的舊觀念跟不上了.....
影音應用：
Photo應用：
資料壓縮應用：
財務分析計算應用：
3D Rendering算圖應用：
個人積分：7分
文章編號：44490827
個人積分：27分
文章編號：44491004
hanzo0313 wrote:
Intel支援OpenCL是對的，接下來就看他們能不能想出更有效率的CPU+GPU協同機制...(恕刪)
關於更有效率的CPU+GPU協同機制，AMD在搞還沒推出的hUMA，Intel則是早早就做了，Intel的作法是從Sandy Bridge開始，就已經讓內顯CPU跟CPU核心都掛到內部超高速Ring Bus上，內顯GPU可以跟CPU核心處於同等地位、從L3快取直接存取CPU/GPU之間共享的資料，不透過比快取慢很多的記憶體。先把基礎建設做好，接下來就是持續在IVB、Haswell、Broadwell、Skylake....一代代繼續加強GPU跟異質計算的能力，並持續改進高速Ring Bus的頻寬跟運作。
兩家的設計各有千秋，Kaveri APU將會是hUMA，Llano/Trinity/Richland APU是透過更傳統的Snooping的方式，但Kaveri/Trinity/Richland/Llano都還只是在較慢的記憶體階層下功夫，還不敢大刀闊斧把GPU直接連到內部快取上。畢竟AMD礙於製程問題，在APU上連L3快取都取消了；有L3快取的FX系列，則是根本無法再納入內顯。架構設計跟製程，彼此間有雞生蛋、蛋生雞問題。
下圖是Sandy Bridge的示意圖。
下圖是hUMA的概念：
hUMA只是用來解決AMD自家CPU/內顯GPU溝通效率未最佳化的問題，因為Intel早在Sandy Bridge時就已經把CPU/內顯GPU之間的溝通方式打掉重練過了，接下來就是持續增進GPU以及Ring Bus的效能。以在Intel處理器上執行OpenCL程式來說，CPU跟GPU就已經可以共享/存取相同的記憶體，不需要複製來、複製去，也就是尚未推出的AMD hUMA想達成的目標。
http://software.intel.com/en-us/forums/topic/277703
http://software.intel.com/en-us/articles/opencl-the-advantages-of-heterogeneous-approach
換個角度看，Intel若要進一步改進記憶體共享的機制，不會比當初加入Ring Bus架構、並且把GPU也掛上L3快取更難。但是AMD要大幅度敲掉架構、把內顯也掛到L3快取上面去，不管從架構設計面、生產製程面，那就工程浩大了。
http://www.realworldtech.com/sandy-bridge/8/
個人積分：933分
文章編號：44495111
...
個人積分：7分
文章編號：44495394
個人積分：7分
文章編號：44495433
