AMD第三代的APU- Kaveri帶來的啟示


deculture wrote:
HASWELL的進步真的只有這樣嗎?

這篇的圖解釋得很清楚,intel靠製程優勢,AMD從軟體下手。


你連結這篇也是錯誤百出
跟前面的一樣
就是L3 Cache和Memory Access是兩種完全不同的東西
Shared L3 cache只不過是增加cache hit
根本不能讓Intel GPU access Intel CPU使用的記憶體

Intel這方面落後是事實
AMD用GPU來打FPU,Intel的優勢就很快只剩下製程了
ayler wrote:
剩不到兩個月就要開賣...(恕刪)





這顆7850K 4C/8T???再加上效能等同HD7730~7750的內顯
定價不要太誇張的話,一定很多人買單....

dongsoon wrote:
這顆7850K 4C/8T???...(恕刪)

維持2模組4執行緒....別想太多。

A10-6800K是4.1GHz,A10-7850K是3.7GHz,壓路機架構帶來的效能增進,又被降低的時脈抵消了.....

ayler 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.
------------------------------------------
Zero copy: Refers to the concept of using the same copy of memory between the host, in this case the CPU, and the device, in this case the integrated GPU, with the goal of increasing performance and reducing the overall memory footprint of the application by reducing the number of copies of data.
-----------------------------------------
Getting the Most from OpenCL™ 1.2: How to Increase Performance by Minimizing Buffer Copies on Intel® Processor Graphics

雖然Haswell的內顯不能直接認得CPU眼中的虛擬位址,但是CPU的虛擬位址會透過TLB或記憶體分頁單元Memory Paging轉化為實體位址,而TLB跟Paging硬體單元是Intel設計的,內顯也是自家設計的,繪圖驅動程式是Intel自己寫的,OpenCL runtime也是Intel寫的,想要由CPU/內顯共用的object/實體記憶體,只要有指定CL_MEM_USE_HOST_PTR flag旗標,這個物件可只存在一份,然後透過OpenCL runtime/繪圖驅動程式/Intel晶片驅動程式去設定分頁硬體單元,讓這個物件所存放的實體記憶體同時對應到內顯的frame buffer以及CPU程式的虛擬定址空間位址上,也就是所謂的"zero-copy goodness"。

Windwaker wrote:


今天有一批浮點+整點的資料
Intel的做法就是
先把這批資料從硬碟讀到CPU主記憶體
再把浮點的資料丟給GPU的主記憶體
GPU算完再丟回CPU的主記憶體


L3共享只不過是增加GPU的Cache Hit Rate
讓GPU讀取GPU記憶體的時候可以變快一點
但是並不能省略紅色的步驟
而AMD的做法就是省略到紅色的步驟
省下這個步驟除了讓成是比較好寫之外
也增加了效能因為不需要把浮點資料在CPU/GPU記憶體之前拷貝來拷貝去





原來是在講這個.



起床就去上班了現在才到家...
第一件事就是把想了一晚的問題再發上.



如果只是要吵 GPU 可以直接存取 CPU 的資源.

嗯.

效能的長進是一定有的.

我也看了上面的串

有位兄台提到很重要的兩串文字.

Wow_Senior wrote:

連同 Imagination Technologies、MediaTek 以及 Texas Instruments 一起推廣 HSA 基金會(異構系統架構基金會)
雖然 HSA 所推廣的概念在計算機界算不上新,但基金會的成員還是希望能讓它被更廣泛地應用。

(中略)

技術方面是陳腔濫調,反正就是 heterogeneous computing 的原理,技術拿來唬一唬,貼一貼。
願景方面就是新聞稿那樣了。希望這是一個更簡單,開放,同時可以涵蓋所有裝置的標準。
所以才基於『heterogeneous computing』,創了一個『heterogeneous systems architecture』。
只是目前還看不出來這新詞彙的技術,原理有什麼不同於老詞彙



heterogeneous computing.
異質運算.

我用了這段字去找了下, 發現了有趣的東西

運算領域:異質運算功能
http://www.ni.com/white-paper/12570/zht/


然後把後面這篇
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 年我們應該就能在日常生活中享用到他們的成果了。



我很快就導出這串的重點.

Wow_Senior 兄臺有你真好, 每次都要看你的回文去挖梗才能快速熟識該串的討論在說些啥

的確我離題有點遠了.


---

問題就在異質運算上面.

GPU有它的長處:平行運算
CPU有他的長處:循序運算
其他東西也有其他的長處:(以下略)

如果能把它們的長處組合起來, 那該有多好?

CUDA 等架構不就是從此而生的? 所以.

參照剛剛貼的連結該文中的一段 :

引文自 運算領域:異質運算功能 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/



現在 AMD 的春秋大夢, 大概是已經認了單純 CPU 效能不可能敵過 Intel
所以拖著 GPU 來進行異質運算, 然後用這異質運算的加分效果反打 Intel 一巴掌.

不過如各位所見的, AMD 並不認為 OpenCL 是好東西 (他說這太複雜)
所以 AMD 想自己搞一套來玩.

於是就有所謂後面的一套 AMD 開發的 API , 翻成中文就是 應用程式介面.

更白話講就是一個介於使用者編寫程式語言, 與硬體及編譯器之前的人類與機器溝通用中介軟體

單純講. 就是用軟體為介去達成異質運算效果
應用軟體的開發人員就不用再去懂那些有的沒的呼叫函數, 甚至用GPU要懂一套, 用CPU要懂另一套語言
他只要對這個 AMD 開發的 API 或 OpenCL 寫個指令, 這些 API 底下就會自動編譯並分配運算資源.



But, 明眼人應該都曉得.
OpenCL 可能如 AMD 說的仍然太複雜, 但它的好處是大家的 CPU + GPU 都能用
AMD 今天也想寫一套 API , 顯然目的是要綁架自己的 APU 來運用.
(別忘了 AMD 本職是硬體開發而不是軟體開發)

Well, 這個情況下, 不是 AMD + ATi 的組合, 可能就好笑了.
如同 nVIDIA 的 CUDA 只有 nVIDIA 能用一樣.
AMD 極可能把這功能綁在 APU 內的 GPU 上.

那麼這樣玩起來還是有個問題.

若有外部 GPU , 而且運算能力更為強大?
AMD 這套 API 是否能把外部 GPU 也當成內部 GPU 一樣的使用? 還不限定是 ATi ?
(外部 GPU 再快都要通過 PCI-Express 介面進行傳輸.)



AMD 自製的 API 是否能取代 OpenCL 成為新一代的標準介面?

按照過去 AMD 的精彩歷史

窩科科科...



還是看看 AMD 的 APU 能不能有效率的在移動裝置上靠著那一點點先天優勢佔住.

不過 x86 體系的 CISC 能效比要去跟 ARM 陣營的 RISC 對尬...

難怪 AMD 也想學著做 ARM 了.



ARM 陣營 : 想學嗎? 我教你啊?




----

至於為什麼一直在吵 GPU 能對 CPU 的資料直接定址取用不用烤來烤去...

然後效能大躍進.
我想同篇文章下面這段就能明白一些端倪

引文自 運算領域:異質運算功能 wrote:

運算節點的程式設計,並非異質運算系統的唯一難題。若無法迅速傳輸資料並進行後續作業,則有再多的運算資源也是枉然。由於 PCI Express 的低潛時、高傳輸量,與點對點的特性,目前已竄起為測試系統中的主要匯流排。PXI Systems Alliance 身為 PXI 系統的骨幹,才於最近發佈了新的 PXI MultiComputing 規格,確保 PCI Express 點對點的異質運算功能。

開發測試系統期間,異質運算將提供多項新功能。在利用程式設計與資料傳輸的最新功能時,工程師可確實享受多重運算節點的優勢。

出處:http://www.ni.com/white-paper/12570/zht/



既然資料傳輸會是問題, 那麼 AMD 就讓 GPU 直接去讀 CPU 的同段資料便不再是問題.

這的確是神解, 但不見得是相容解.

相容解是什麼? 今天 GPU 角色換個不同廠的? 甚至只是單純的不住在 CPU 裡?



所以 nVIDIA 才要弄丹佛計畫. 弄個 x86.

原來啊原來.

Intel 如果學著 AMD 這樣搞,
那三家當中唯一沒有 CPU 只有 GPU 的 nVIDIA 一定要吃土的.
為了移動市場這塊大餅... nVIDIA 硬著頭皮都得幹啊. x86 !


Intel 還沒跟上的原因, 我覺得很單純的是他想要保有對 ATi / nVIDIA 的相容性
讓 Intel 平台不管使用 Intel / ATi / nVIDIA 的 GPU 都能夠進行相對穩定的異質運算.
採取相對保守的策略...
反正現階段的資料傳輸瓶頸還不是瓶頸,
換張高級點的顯卡弄出來的異質運算效能
還是比擴張傳輸速度規格的效能來得好些

傳輸效率... Intel 效能老是被卡住的一個地方.

不過啊...
就算弄上 HSA
CPU 旁邊的 GPU 再神也只是配角.
要弄到地表超強的話, 裝個中階顯示晶片進去當好鄰居就得了.

但... 各位覺得有可能嗎?

想像一下那個處理器所產生的高熱與電耗?



而且直接寫程式控制雖然對工程師們不友善,
但某個程度上來說, 平台相容性卻有了.
如果是 OpenCL, 可能只要對應的函式改改就成了可以多平台的好物.

但是學寫 AMD 的還得再去重練一趟然後可能只能跑 AMD ...



這不是什麼能看壞的東西
AMD 想搞的東西大家都早就在搞
只是他的確想展現自己是走在這路上的領導者

不過比起吹牛, 實際的產品能效才是重點中的重點

別像當初推土機出來還倒輸龍二哥那樣囧就好了...


---



最後, 才是我對這個 AMD 推出 HSA 新神話的個人見解.

如果能用在行動裝置上頭而且能效的水準能近似 ARM 的話那當然是很美好的.

實際上要是回到 PC 上頭
GPU 再怎麼能也無法取代 CPU ,
因為功能基本上就是完全不一樣的東西.

只要 CPU 還沒被取代
身為 PC 的唯一頭腦, 它的基本水平就很重要
這點便是 Intel 的強處, 目前大家都公認的吧 (價錢不討論)

所以現在只是 AMD 要搶先做
就好像 AMD 當年搶先在個人PC上去黏 HTT 通道 (Intel 還在 FSB 上頭)
搶先在個人PC上去弄 64bit (雖然被 M$ 婊到)
搶先開放更多的虛擬化架構 (Intel 的 CPU 還要挑型號跟主機板的晶片組)




But 搶先是搶先了.



最重要的那個基本效能到底有沒有提升?

不提升基本效能只是拿異質運算來掩飾自己浮點欠佳的缺點...

當對手跟你做一樣的事情時你就得再死一次了, AMD .

就好像 HTT 打 FSB 打得很高興後來被 QPI 打回去一樣




我們不看壞 heterogeneous computing (異質運算) , 那是個必定的潮流
我也不看壞 AMD 搞個 HSA

但我們會看壞的是 AMD 他繼推土機的模組式CPU之後
又拉個 GPU 當墊背來提高效能, 到底能提高到什麼樣的地步?



切記這在有限資源的行動裝置上面的構想是很好的
行動裝置沒那種空間跟電力給你大大的GPU與記憶體.

只是 AMD 的產品其能效表現, 你懂的.

不要抱太大的期待, 這樣才會深刻體會到 AMD 盡力之後的成果是多麼美好



So. 你們慢吵.







dongsoon wrote:
這顆7850K 4C...(恕刪)


我也在等這顆HSA Feature的Kaveri,明年1~2月應該就買的到了

enm wrote:
原來是在講這個.起床...(恕刪)


AMD的API叫Mantle.
打『AMD Mantle』搜尋可以找到目前公開出來的一些資料。
宣傳的內容是提到不限誰家的CPU誰家的顯示卡。
目前還沒有數據資料。只有PPT秀了一下有/無Mantle差多少指令週期的『示意圖』
最近也沒啥新聞好看,所以我有稍稍去翻了一下。
設定自己成為一個什麼都不懂的人,看看AMD的介紹能讓我理解多少。

至於吵啥...Vincent版友昨天就沒回應了
大概是昨天台灣時間凌晨2、3點,多倫多時間下午2、3點那幾段對話失望了。
後續也沒人再對HSA的話題說啥了。
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.
------------------------------------------


你要不要看看實作
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.

This means that changes to data performed by kernel might not be immediately reflected in host_ptr. In fact, there is no guarantee that host_ptr contains valid data while it is used for buffer..

In order to have valid and up-to-date data you must force synchronization. The offcial documentation is a little vague about this moment, but buffer mapping/unmapping definetly works:

如果Intel沒這限制早就支援HSA
說穿了Intel沒有這個feature
所以程式設計還是要自己做拷貝的動作
SDK不過只是做非同步的快取讀取而已
很多情況下,還是要自己從CPU記憶體拷貝
因為快取的資料並非保證的


enm wrote:
但我們會看壞的是 AMD 他繼推土機的模組式CPU之後
又拉個 GPU 當墊背來提高效能, 到底能提高到什麼樣的地步?


Intel整點本來就和AMD半斤把兩
AMD在HSA下面用GPU打浮點
GPU浮點通常是FPU五倍以上
現在就是這樣了
重點只是多少程式支援

HSA一起飛
到時候Intel的優勢不再
只能和AMD玩內顯大戰
Kaveri只是第一步而已
等到明年用20mm+DDR4
AMD內顯優勢會更加明顯

最慘的是Intel Atom
對上支援HSA的snapdragon
贏回移動市場的機會更少
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.
...(恕刪)

在Llano/Trinity/Richland等等APU上,確實必須這樣實作,複製來、複製去、複製來、複製去。

你貼的資料,根本不是Intel的實作資料。至於Intel的官方文件,明確提到不需要複製,"zero-copy",在Intel自家的OpenCL runtime中,也實作了這個功能(實體記憶體分享)。並不只是程式設計師不需要自行複製buffer,而是明確說了底層的Runtime也不會也不需要去複製Buffer。

=======================================================
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.
=======================================================
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.
=======================================================


我也再貼上一篇我寫的

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.

This means that changes to data performed by kernel might not be immediately reflected in host_ptr. In fact, there is no guarantee that host_ptr contains valid data while it is used for buffer..

這邊所謂的zero copy
是Intel CPU可以把CPU memory的資料讀進L3快取給GPU使用
但是變成有兩個問題
1. 快取裡面的資料不是保證的
2. 資料不能大過於L3 快取
光是這兩個限制
基本上這個功能就沒甚麼用了

想想看,一個資料不但不保證而且大小不能超過L3快取
基本上可以運用的機會實在不多
到最後還是要從CPU拷貝到GPU使用

HSA的做法是GPU從主記憶體直接讀取
資料要多大有多大,而且資料是保證的
所以Intel在這方面是有限制的

文章分享
評分
評分
複製連結
請輸入您要前往的頁數(1 ~ 25)

今日熱門文章 網友點擊推薦!