umts wrote:
GPGPU依舊只能處理重複單調的工作.處理流程依然需要CPU介入.
CPU仍然要很強勁,不然GPGPU反而會幫倒忙.
AMD這幾年大輸Intel的都是浮點運算
而GPGPU的浮點運算至少快普通CPU三倍以上
這也就是為什麼Haswell的GPU越做越大 (37%)
但是Kaveri的GPU佔了50% Die的空間
這一代kaveri已經是i5整點+7730
下一代要衝i7+260X要靠DDR4才能解決記憶體頻寬的問題
個人積分：47分
文章編號：47276735
個人積分：46分
文章編號：47277336
個人積分：47分
文章編號：47277406
個人積分：29分
文章編號：47279210
個人積分：1394分
文章編號：47279256
即使先撇開殺手應用，純論技術，FPU跟SIMD指令集如SSE/AVX是內功，而利用內顯進行異質計算是外功，兩者適用的計算型態並不相同，業界趨勢是內功跟外功兼修是好事，樓主卻解讀成光把外功練到最強，就可以不用練內功了，這不就變成少林的火工頭陀了.....
關於更有效率的CPU+內顯協同機制，AMD端是剛要推出hUMA共享主記憶體，Intel端則是早早就已經實作了。
Intel的作法是從快要三年前的Sandy Bridge開始，就已經讓內顯跟CPU核心都掛到內部超高速Ring Bus上，內顯可以跟CPU核心處於同等地位、從比外部記憶體頻寬高很多、延遲時間低很多的L3快取直接存取/交換由CPU跟內顯間共享的資料，盡量不透過位於處理器外部的記憶體。
先把架構的地基打好後，接下來就是持續在IVB、Haswell、Broadwell、Skylake....繼續堆電晶體加強內顯本身遊戲跟異質計算的能力，並持續改進高速Ring Bus的頻寬跟運作。不走AMD閹割L3快取的路子，也不犧牲完整核心數（以i5/i7為例）。
下圖是Sandy Bridge的架構示意圖，Ivy Bridge/Haswell基本上也都是基於類似的Ring Bus架構讓CPU跟GPU可共享L3快取，加上效能跟效率的持續改善：
想要讓內顯跟CPU核心更有效率的交換/存取資料，卻不從需要紮實基本功的處理器內部改造下手，而得透過位於處理器外部的記憶體上進行（必須透過Memory Controller跑到處理器外部去.....），不覺得怪怪的？然後再把hUMA說成是創舉、好像別人都想不到更好方式似的.....
高雄到台北間不直接搭高鐵，卻從高雄飛到日本沖繩、然後再飛台北？要把東西拿給就住在隔壁房的老弟，不直接拿到隔壁，卻用快遞寄給老弟、讓東西去外面繞一圈再回到家中隔壁房，就算飛機飛得再快、或找到地球上最快的快遞公司，當初又何必.....
內部的L3快取怎麼說都比外部的記憶體快，但是AMD從Llano/Trinity/Richland到最新的Kaveri APU，一概都把L3快取閹掉了，如果要把L3快取加回來，一則製程能力不允許，二則必須大工程把CPU/內顯的資料共享/交換架構敲掉重弄，基礎工程浩大。
HSA基金會進行的一項主要課題，是CC-SVM（Cache Coherent Shared Virtual Memory），是探討在「具有」供所有異質核心共享的快取架構下的記憶體共享，其實這在學界也進行好一陣子了，AMD的hUMA，只能說是限於AMD自身技術能力、無法把L3快取加回去的情況下的打折扣產品，硬推廣給HSA其他重量級成員，反而會被笑話......
是要像Intel一樣先下苦功砍掉重練、讓L3快取可供CPU/內顯共用，再加入CC-SVM能力？還是像AMD一樣避免去碰把L3快取加回去的苦功，先搞個七折八扣的hUMA用用？
------------------------------------------------------------------------
節錄自Vincent323網友提供的連結：
-----------------------------------------
The approach, outlined in a paper by NC State Associate Professor of Electrical and Computer Engineering Dr. Huiyang Zhou, Ph.D. candidates Yi Yang and Ping Xiang, and AMD GPU Architect Mike Mantor, is designed for fused architecture chipsets with a shared L3 cache and shared off-chip memory for CPUs and GPUs. The approach developed by the team leverages the computing power of the GPU, while taking advantage of the CPU's more flexible data retrieval and better handling of complex tasks.
-----------------------------------------
AMD的GPU架構師參與發表的論文，是讓APU設計中有L3快取的存在、也知道讓內顯跟處理器核心共享L3快取，再搭配hUMA，才是正確的架構，只是從論文到實際產品，執行力有落差，這就像建築師設計某棟大樓的設計理念對了，但是承包的營建公司卻不給力、 造不出來.....L3快取的頻寬比外部記憶體高、延遲也低很多，既然L3快取加不回來，原本Kaveri想借助GDDR5當成主記憶體補足頻寬，但價格太貴，又不能擴充容量，功能也被拿掉了。
個人積分：47分
文章編號：47279343
個人積分：1394分
文章編號：47279414
Windwaker wrote:
GPU可以存取CPU使用中的主記憶體才能讓GPU和CPU協同運算
這是Kaveri的功能，也是Intel根本沒有的...(恕刪)
樓主試跑個Luxmark，不就知道Intel的內顯跟CPU能不能協同運算了(早已經可以了)，有興趣還可加上獨顯三者一起跑也行.....OpenCL是開放標準，早就允許這種CPU+獨顯+內顯的運算型態。
CPU使用的記憶體所存放的資料，當然也可以同時存在於L3快取內，供內顯取用，反過來也是。這也正是快取存在的用意。快取的設計精髓，不在於把東西通通搬進快取，而在於根據locality原則，把即將用到的資料先搬進來，把用不到/較少用的資料踢出去，重點是命中率，並不是越大就一定越好。
既然從Sandy Bridge之後就已經做到CPU/內顯能在內部的L3快取上共享資料了，那能不能在外部的記憶體階層上共享資料、避免資料複製？答案也是可以的，因此樓主別亂誤導了。
這篇裡面就有介紹如何達成Intel CPU/內顯之間用Zero Copy方式達成資料共享的OpenCL程式寫法，還包括範例程式碼：
Getting the Most from OpenCL™ 1.2: How to Increase Performance by Minimizing Buffer Copies on Intel® Processor Graphics
這篇講得也很清楚，Intel的OpenCL實作可以達成CPU跟內顯間零拷貝型態的資料共享：
http://software.intel.com/en-us/articles/opencl-the-advantages-of-heterogeneous-approach
==================================================
The (OpenCL) runtime shipped with the Intel® SDK for OpenCL™ Applications offers zero-copy goodness when the CL_MEM_USE_HOST_PTR flag is used during creation of memory objects
==================================================
在Intel的論壇中，對發問的程式設計師提到在OpenCL程式中讓CPU跟內顯透過實體記憶體共享資料：
http://software.intel.com/en-us/forums/topic/277703
==================================================
Intel CPU and GPU use the same physical memory so memory objects are effectively shared by default and no implicit memory transfer happens between devices or on map/unmap calls.
==================================================
According to Intel Optimization Guide because Intel uses true memory sharing across host and all devices you can allocate buffer by OpenCL runtime and then map/unmap it without extra copy (it is simplest way).
==================================================
既然I家都已經早早挑戰且做到在L3快取階層讓內顯/CPU共享資料了，還需要回頭大張旗鼓宣傳可讓內顯/CPU在外部較慢的記憶體階層上共享資料嗎？.....
hUMA只是解決AMD自家APU在Llano/Trinity/Richland等世代上，資料必須在CPU記憶體跟供內顯使用的記憶體間複製來複製去的大缺點，但相較對手的架構，並不是優勢，而且hUMA還必需要搭配重新改寫的HSAIL應用程式，也是一大障礙。
-----------------------------------------------------------------------
樓下說「稱不上協同運算」，話不是你說了算，重點是放在CPU+內顯共同異質運算後有沒有跑出綜效（時間縮短），不是在投影片上畫漂亮架構，加上一堆行銷術語，然後就號稱才是少林正宗，樓主鑽到象牙塔牛角尖裡去了......
.....異質性架構不管是在學界或是業界，都有十幾廿年的發展光景，不需要等AMD或樓主說了才算。另外AMD的HSA是著重在CPU+GPU，但是ARM的HSA是著重在big.LITTLE大小核心架構（A7搭A15，A53搭A57），兩家公司的重點跟方向差很多。
至於樓下還認為Intel必須依賴OpenCL云云，難道AMD便完全不靠OpenCL？AMD在最近這次Developer Summit開發者大會，針對APU所推出的SDK 2.9版以及Open Source Libraries，正是針對更方便開發OpenCL程式而來，因此Kaveri本來就也需要OpenCL，只是AMD又想另推一個HSAIL，但力分則散。沒有HSAIL程式，也發揮不出hUMA的優點。
至於已經支援OpenCL的程式，可比還不知道在哪裡的HSAIL程式多多了....
個人積分：47分
文章編號：47279438
個人積分：39分
文章編號：47280684
個人積分：218分
文章編號：47281083
Windwaker wrote:
簡單來說今天我算一個...(恕刪)
你真的知道X86 I/O位址映射的原理嗎? CPU丟給GPU,那請問GPU該去哪裡接?
既然APU都能統一虛擬定址空間,那APU沒事劃分個512MB當顯示記憶體是來亂的嗎? IOMMU工作原理很重要.
AMD的HSA架構一樣需要API讓CPU和GPGPU都溝通,怎麼Intel用OpenCL就成弱點?
還有Optimizing Your Applications Using OpenCL* on Intel® Iris™ Graphics
這份文件說 Global Memory Accesses go through the L3 Cache.
所以Intel GPGPU是可以用L3 cache直接存取Global Memory,不需要統一虛擬定址空間這個東東(IOMMU轉譯).
