deculture wrote:
HASWELL的進步真的只有這樣嗎?
這篇的圖解釋得很清楚,intel靠製程優勢,AMD從軟體下手。
你連結這篇也是錯誤百出
跟前面的一樣
就是L3 Cache和Memory Access是兩種完全不同的東西
Shared L3 cache只不過是增加cache hit
根本不能讓Intel GPU access Intel CPU使用的記憶體
Intel這方面落後是事實
AMD用GPU來打FPU,Intel的優勢就很快只剩下製程了
dongsoon wrote:
這顆7850K 4C/8T???...(恕刪)
ayler wrote:
寫程式的應該會有經驗, 大量記憶體資料搬來搬去的負擔是非常重的, 對效能影響不輸給演算法之間的差異...(恕刪)
Windwaker wrote:
今天有一批浮點+整點的資料
Intel的做法就是
先把這批資料從硬碟讀到CPU主記憶體
再把浮點的資料丟給GPU的主記憶體
GPU算完再丟回CPU的主記憶體
L3共享只不過是增加GPU的Cache Hit Rate
讓GPU讀取GPU記憶體的時候可以變快一點
但是並不能省略紅色的步驟
而AMD的做法就是省略到紅色的步驟
省下這個步驟除了讓成是比較好寫之外
也增加了效能因為不需要把浮點資料在CPU/GPU記憶體之前拷貝來拷貝去


Wow_Senior wrote:
連同 Imagination Technologies、MediaTek 以及 Texas Instruments 一起推廣 HSA 基金會(異構系統架構基金會)。
雖然 HSA 所推廣的概念在計算機界算不上新,但基金會的成員還是希望能讓它被更廣泛地應用。
(中略)
技術方面是陳腔濫調,反正就是 heterogeneous computing 的原理,技術拿來唬一唬,貼一貼。
願景方面就是新聞稿那樣了。希望這是一個更簡單,開放,同時可以涵蓋所有裝置的標準。
所以才基於『heterogeneous computing』,創了一個『heterogeneous systems architecture』。
只是目前還看不出來這新詞彙的技術,原理有什麼不同於老詞彙
Wow_Senior wrote:
他不是什麼新技術,也不是什麼新架構。而是一套 API(Application Programming Interface)。
用在做什麼?做你說的 『APU因為HSA的關係,GPU不用等CPU分配工作跟資源』這件事情。
(其實還是要...只是簡化了一點,然後還要搭配API來重新撰寫程式才辦得到。)
Wow_Senior wrote:
和市面上一些產品追求更复杂晶体管設計的做法不同,HSA 希望通過平行運算來提升處理器的表現。
比如圖像處理器將不僅僅用於圖像、遊戲等方面,普通的任務和 App 也可以用到它。
雖然用 OpenCL 已經能達到這種效果,但 AMD 認為這樣的做法太複雜,
而且主流的開發者也不容易接受。
NVIDIA 那邊也有自己的 CUDA 運算架構,不過可惜那是私有的。
HSA 基金會的目標是一種更簡單、開放,同時還可以涵蓋 PC 與行動設備(不光是跨 OS)的標準。
如果一切順利的話,到 2014 年我們應該就能在日常生活中享用到他們的成果了。

引文自 運算領域:異質運算功能 wrote:
目前業界中的工程師,均設法降低特定運算節點的複雜度。
針對 GPU,正開發 Open Computing Language (OpenCL) 。
OpenCL 為程式設計介面,不僅可支援多款 GPU 產品,亦可額外支援如多核心 CPU 的平行處理器。
另外也希望能簡化 FPGA 的設定作業。「高階合成 (High-level synthesis,HLS)」則是目前由某些製造商所採用的程序,即於 FPGA 程式設計中使用演算法架構的高階語言。如 NI LabVIEW FPGA Module 的工具,將提供圖形化的程式區塊,並將之直接轉換為數位邏輯電路,以簡化 FPGA 的複雜度。
出處:http://www.ni.com/white-paper/12570/zht/
)

引文自 運算領域:異質運算功能 wrote:
運算節點的程式設計,並非異質運算系統的唯一難題。若無法迅速傳輸資料並進行後續作業,則有再多的運算資源也是枉然。由於 PCI Express 的低潛時、高傳輸量,與點對點的特性,目前已竄起為測試系統中的主要匯流排。PXI Systems Alliance 身為 PXI 系統的骨幹,才於最近發佈了新的 PXI MultiComputing 規格,確保 PCI Express 點對點的異質運算功能。
開發測試系統期間,異質運算將提供多項新功能。在利用程式設計與資料傳輸的最新功能時,工程師可確實享受多重運算節點的優勢。
出處:http://www.ni.com/white-paper/12570/zht/
)


Whistle Blow wrote:
資料得在CPU跟GPU各自的記憶體間複製來複製去,是AMD Llano/Trinity/Richland這些APU的限制,hUMA只是解決AMD自家的問題,對手的產品早就沒有這個限制,樓主自行擴大解讀罷了。
------------------------------------------
Also resource sharing and synchronization should follow the OpenCL specification requirements. Objects allocated at the context level are shared between devices in the context. This allows, for example, using the same kernel object for both the CPU and GPU. More importantly, both buffers and images created with regular clCreateBuffer/clCreateImage API calls are shared by default. The 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.
------------------------------------------
Windwaker wrote:
你要不要看看實作
CL_MEM_USE_HOST_PTR不過是Intel SDK幫你做非同步拷貝Cache buffer
並非是Intel沒有這個限制
http://stackoverflow.com/questions/12283537/opencl-device-host-memory-coherence-for-variables-passed-to-kernel-with-cl-me
OpenCL implementations are allowed to cache the buffer contents pointed to by host_ptr in device memory. This cached copy can be used when kernels are executed on a device.
...(恕刪)
Whistle Blow wrote:
至於Intel的官方文件,明確提到不需要複製,"zero-copy"。
=======================================================
The 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.
=======================================================