|
||
|
Master Member
  加入日期: Sep 2003
文章: 1,810
|
> 就想像看看一顆APU規格是FX-8370 + R9 290再加HSA,
應該不會只是這種等級 看圖 他是server用的CPU 搭配FirePro (同天有拿 FirePro S9150 跟NV的計算卡比 S9150功耗是235W) 這擺明Server等級的東西 此文章於 2015-03-31 10:55 PM 被 orakim 編輯. |
|||||||
2015-03-31, 10:52 PM
#51
|
|
|
*停權中*
加入日期: Mar 2015 您的住址: 熱火隊地盤
文章: 2,703
|
引用:
DT還有可能， NB就不必想了.  |
|||
|
2015-03-31, 10:53 PM
#52
|
|
|
Golden Member
 加入日期: Dec 2001
文章: 2,914
|
引用:
打個比方而已......  反正不管AMD要怎麼玩,前提還是HSA要能流行 現在DirectX12還能跟Mantle扯上關係, 反觀HSA,Kaveri都推出一年多了,好像也沒看到端出什麼東西來?  |
|
|
2015-03-31, 11:05 PM
#53
|
|
|
Master Member
加入日期: Sep 2003
文章: 1,810
|
> 反觀HSA,Kaveri都推出一年多了,好像也沒看到端出什麼東西來?
在PCDVD 應該說過一兩次 啊 今年一月才有系統支援 可以正式開發HSA 也就是可以開發的時間到現在也才幾個月 實際成品出來看規模 一兩年大概是免不了的 -- 另外AMD 說支援HSA 1.0的硬體 到現在也還沒販賣，要開發就只能用kaveri 暫時頂著 XD 此文章於 2015-03-31 11:11 PM 被 orakim 編輯. |
|
2015-03-31, 11:09 PM
#54
|
|
|
*停權中*
加入日期: Mar 2015 您的住址: 列山神農洞
文章: 86
|
HSA在server, mobile推會不會比較容易?
DT/NB的阻力頗大..... |
|
2015-03-31, 11:14 PM
#55
|
|
|
Golden Member
加入日期: Dec 2001
文章: 2,914
|
引用:
記得看過說要使用GPGPU的程式的寫作邏輯跟普通程式不太相同, 所以除非Compiler能自動產生GPGPU最佳化的程式碼, 不然要靠設計師自己去Call底層API的話,普及的速度應該不會快 |
|
|
2015-03-31, 11:29 PM
#56
|
|
|
Elite Member
加入日期: Nov 2004 您的住址: 北平西路3號
文章: 4,614
|
引用:
也許AMD已經點出未來之路 目前SMT清一色都是intel除了2004年IBM Squadron之外 HT on NetBurst→SMT based on OOOE HT on Itanium→CMT（SMX） HT on Atom→SMT without OOOE HT on Nehalem→SMT based on OOOE 我認為AMD可能想實驗Fine-grained multithreading（細質多執行緒）在X86系統上 能不能與intel HT抗衡 自從NVIDIA NV40與ATI R520之後的GPU都是採用Fine-grained multithreading 但是有名的CPU就Fujitsu SPARC64 VI |
|
|
2015-04-01, 01:04 AM
#57
|
|
|
Master Member
加入日期: Sep 2003
文章: 1,810
|
> 除非Compiler能自動產生GPGPU最佳化的程式碼,
不清楚，不過AMD 是有個HSAIL 中間語言 利用現有工具(opencl、C++ AMP、Python...) 生出HSAIL 再由HSAIL Finalizer 針對target進行編譯，靠這個可以支援不同的GPU (AMD GPU、ARM Mali、PowerVR...共同特色HSA基金會初始成員) > HSA在server, mobile推會不會比較容易? HSA成員內大部份是mobile，HSA實際上也支援mobile 的GPU 只要ARM CPU架構 對HSA必須的hUMA、hQ有支援，應該就能直接用HSA了 AMD預計今年推出的ARM Lanner Falcon(Server APU)就會支援HSA 2.0 不過2016就有點詭異，Server的處理器 (x86、ARM)都沒有GCN 取代的是併購SeaMicro得到的Freedom Fabric http://pc.watch.impress.co.jp/img/p...tml/16.png.html AMD 第一個ARM 處理器(seattle)沒有GPU 有Freedom Fabric，是個支援Freedom Fabric 的ARM CPU AMD 第二個ARM 處理器(Lanner Falcon)有GPU，支援HSA 2.0 是標準APU AMD 第三個ARM 處理器(K12) 結構大改(預計會是走高時脈 高效能路線) 沒有GPU 但有Freedom Fabric，同世代的x86也沒GPU 究竟 這代表的是什麼意思，讓我們繼續看下去 Lanner Falcon的開發 只是讓AMD 對ARM架構修改 讓他能支援HSA? 再把技術回饋給ARM? server 其實不需要HSA? 此文章於 2015-04-01 01:48 AM 被 orakim 編輯. |
|
2015-04-01, 01:44 AM
#58
|
|
|
*停權中*
加入日期: Apr 2015
文章: 58
|
基本上要增加單緒效能得從以下著手
increase architectural register naming or larger general purpose register(像arm64, mips and power一樣 因為x86很缺 register naming) more instruction decoder/ integer pipeline/issue port(i社採用4+1+1+1已經過時了 , 更多條管線與更多decoder也會增加ipc) 增強scheduler的亂緒resource分配(基本上instruction decode 會更有效率) branch prediction cache hit rate miss and latency(i社32kb instruction + 32kb data用了8年了 是時候要改了) more register renaming + enhance out of order(基本上如果front end餵不飽是沒用的) more ALU/AGU (同上) new instruction set (對常用的legacy code 沒幫助) increase clock speed (要拉時脈必然要加深管線 管線變深效率變低功耗變高 一種惡性循環) |
|
2015-04-02, 05:56 AM
#59
|
|
|
*停權中*
加入日期: Dec 2001
文章: 427
|
引用:
這些東西AMD也都知道， 只不過，電路設計不設計得出來， 是個大問題， 光一個cache的延遲、頻寬， AMD就輸intel好幾個level了； 記憶體控制器也是個問題， 自從intel CPU內建mc之後， 記憶體的有效頻寬， AMD在這部分好像不曾贏過。 至於pipeline的數目與深度， 太深跟太多都會增加延遲、電路設計的複雜度， 而且再牽扯到oooe， branch prediction要是做得太糟， 那就會遇到pipeline時常得清掉的窘狀， 等於做白工..... 綜合以上各點， 設計出來的東西，得要經過微調再微調， 不然根據理論上設計出來的東西， 可能會類似推土機架構那樣， 表面上的輸出量很大，實際上卻會遇到一堆問題。 |
|
|
2015-04-02, 03:40 PM
#60
|
|
