嘟9375 wrote:
老實說AMD壓過INTEL或INTEL壓過AMD對我而言真的沒啥差
我只想知道HSA是不是可行
這玩意才有可能改變以後我們的生活
最簡單看到的就是像是Kinetic這種影像辨識
其他像是Photo Indexing或是人臉辨識
就現在CPU FPU跑得很喘的程式
會變成大量普及
重點是大家不用追新的CPU了
因為GPU光是浮點就比現在的CPU的FPU快了近十倍
個人積分：47分
文章編號：47352644
個人積分：218分
文章編號：47354123
nvfans wrote:
恩，偷偷跟你說......(恕刪)
很婉轉的跟你說.你誤會了
文章要看原文,翻譯版本差很大.
ANANDTECH原文是 "AMD introduced support for something similar back with Llano."
驅動之家翻譯成 "AMD Llano APU里就已经有了这个东西"
something similar 應是"有些類似"的意思,而不是肯定的"已經有了".
http://www.realworldtech.com/fusion-llano/2/
原文說 The Fusion GPUs have a dedicated non-coherent interface to the memory controller (the Radeon Memory Bus or Garlic, shown with a dotted line) for commands and data.
又說 The GPU has a separate interface for sending memory requests that target the coherent system memory.
證明Llano APU功能並不完整,需要coherent request queues協助請求.
所以很抱歉Llano APU出局了.
如果要把類似的算進去.連Intel的Sandy Bridge的Coherent ring interconnect也有類似功能.
http://www.realworldtech.com/sandy-bridge-gpu/3/
原文說 GPU memory buffers can be directed to the LLC, or to main memory, but in either case, they rely on the ring for access to data.
個人覺得家大業大的Intel很強是很正常的.
個人積分：0分
文章編號：47355117
umts wrote:
很婉轉的跟你說.你誤...(恕刪)
我剛去看了你上一篇轉的AnandTech的文章，它裡面寫：The second extension, InstantAccess is simply Intel's implementation of zero copy. Although Intel's processor graphics have supported unified memory for a while (CPU + GPU share the same physical memory), the two processors don't get direct access to each others memory space. Instead, if the GPU needs to work on something the CPU has in memory, it needs to make its own copy of it first. The copy process is time consuming and wasteful. As we march towards true heterogeneous computing, we need ways of allowing both processors to work on the same data in memory.
大家英文都很行我就不翻了。這樣的話樓主沒說錯啊，Intel的確不算是真正的Heterogeneous computing......，所以Intel的確在這上面比AMD的技術要慢啊。然後AMD的Kaveri才是真的allow both processors to work on the same data in memory。
這裡貼一下那個文章：http://www.anandtech.com/show/6863/intels-pixelsync-instantaccess-two-new-directx-extensions-for-haswell
懶得看完的人請直接看最後一段。
個人積分：948分
文章編號：47355809
個人積分：388分
文章編號：47355878
而且它會是一個趨勢
現在既然已經發現 GPU 在浮點上的表現要比 CPU 本身的 FPU 要好
往後會變成 Intel 386DX + 387 這種模式也不會感到意外
問題只在於技術上的東西誰能做得比較好...
而且我也說過了, 其實最後也不是集中在誰的定址技術好壞.
類似的東西其實每一家都能做, 差別在於能做到什麼程度
而且定址方面的問題並不像電晶體材料的物理特性什麼的那樣難以突破
只在於開發團隊動動腦筋的差別.
最終問題還是會回到上面所提到的.
該裝置原本的 "效能"
(行動裝置還需要計入"耗能")
如果我需要暴力浮點的場合. 高規CPU+高規GPU效果更好
反之若不需要那種暴力浮點場合, 其實普通CPU+普通GPU就能應付
前者不消說, 後者不管 AMD 還是 INTEL 都是輕鬆樂勝
所以最後的差別還是在於市場的環境, 以及產品本身的效能是否真的勝任市場需求.
差別在於, 目前行動裝置市場漸漸壯大起來
以現有科技要在那麼小又沒有太多電源能玩的機子上面堆效能是有困難的
因此在這有限定條件的情況下
" CPU + 內建GPU "
在一定低功耗的情況下, 又能節省其整體成本
然後其能效, 能夠到什麼境界, 就變得相當重要了.
總之, HSA, AMD 起的頭要是真的有效
Intel 摸摸鼻子也是得跟上
最終不管是誰勝出, 都是消費者受益
個人是樂觀其成
個人積分：218分
文章編號：47356038
Windwaker wrote:
你要不要看看實作
CL_MEM_USE_HOST_PTR不過是Intel SDK幫你做非同步拷貝Cache buffer
並非是Intel沒有這個限制(恕刪)
根據 The OpenCL Specification Version: 1.1規範說明.
CL_MEM_USE_HOST_PTR 的解釋 This flag is valid only if host_ptr is not NULL. If specified, it indicates that the application wants the OpenCL implementation to use memory referenced by host_ptr as the storage bits for the memory object.
實際上CL_MEM_USE_HOST_PTR是個輔助host_ptr這個pointer的位元旗標.
並不是什麼"Intel SDK幫你做非同步拷貝Cache buffer".
你連結的原文下幾行.
If the buffer object is created with CL_MEM_USE_HOST_PTR set in mem_flags, the host_ptr specified in clCreateBuffer is guaranteed to contain the latest bits in the region being mapped when the clEnqueueMapBuffer command has completed; and the pointer value returned by clEnqueueMapBuffer will be derived from the host_ptr specified when the buffer object is created.
"CL_MEM_USE_HOST_PTR set in mem_flags" 也表明它就只是旗標,不是函數沒有"非同步拷貝"的功能.
而你引述的範例以clCreateBuffer建立緩衝區,並以clEnqueueMapBuffer隊列映射緩衝區到記憶體相對的空間,並傳回host_ptr指向映射的區間的過程中,Buffer沒被即時建立,以致於host_ptr指向的記憶體可能是空的或未被清除的舊資料.也是跟"Intel SDK幫你做非同步拷貝Cache buffer"無關.
這程式範例很簡短,應該不會造誤解吧.
另外沒有提到L3 cache,卻又推論出兩個問題 (雖有提到cache但不代表是L3,況且L3在Haswell有兩種)
1. 快取裡面的資料不是保證的
2. 資料不能大過於L3 快取
會不會太遷強,這等於指控Intel CPU cache有bug,有點像在玩火.
我有以理性的態度將事情原委說明清楚。應該不會被檢舉吧.
個人積分：388分
文章編號：47356215
umts wrote:
另外沒有提到L3 cache,卻又推論出兩個問題 (雖有提到cache但不代表是L3,況且L3在Haswell有兩種)
1. 快取裡面的資料不是保證的
2. 資料不能大過於L3 快取
會不會太遷強,這等於指控Intel CPU cache有bug,有點像在玩火.
這一點我也有疑問.
CPU 不都是直接把需要的資料從 Main Memory 搬進 L2 / L3 cache 裡面進行等待計算的嗎?
就算是要給 GPU 計算資料,
CPU 也是得先去 Main Memory 提取資料進入 L2 / L3 cache 裡面解譯
才能命令 GPU 去 "運算" 某個定址的資料.
換句話說, GPU 在這個場合,
要不就是 GPU 本身也有快取,
去Main Memory 搬進 GPU 的 cache 來用
要不就是 GPU 要去 CPU 的 L2 / L3 cache 裡面找 CPU 叫他算的資料
或者, GPU 接受指令,
前往在 Main Memory 上的指定位址取得資料然後開始運算.
但是, 這個在 Main Memory 裡面找來的資料, 是該放在誰的 cache 裡面進行計算?
或者, GPU 直接把 Main Memory 就當成他的 cache 直接計算?
放在誰的 cache 裡面可以提高效率是可見的
(不用說, Main Memory 對 CPU/GPU 的資料讀寫反應延遲一定比 cache 要高)
但是問題是放在誰的 cache ? 這邊應該指的是 CPU 的?
那要是直接就在 Main Memory 上進行讀, 運算, 寫
實際的效能上會嚴重受到 Main Memory 本身的帶寬及頻率, 延遲等因素
如同各位所熟知的 APU 需要搭 雙通道+ 高頻率 DDR3 才能讓內顯運算等級提升...
喔... 喔喔喔...
所以才會提到 AMD 的 Kaveri 希望使用 DDR5 等級的記憶體來增強功力???
那...
會不會又是看得到吃不到, 想要請等明年之類的
個人積分：25分
文章編號：47356390
個人積分：25分
文章編號：47356458
個人積分：25分
文章編號：47356501
