Re: [情報] AMD顯示卡救星來了!SK HYNIX HBM2記憶

看板PC_Shopping作者 (此方不可長)時間7年前 (2016/07/16 23:50), 7年前編輯推噓36(360136)
留言172則, 33人參與, 最新討論串2/3 (看更多)
藉這個話題一問: HBM2這鬼玩意頻寬隨便也256GB/s, 反觀DDR4 3200 也才 25.6GB/s, 那為什麼 intel / AMD 不把這玩意用在CPU上? 我知道, 因為 RAM 有 dimm socket, 這鬼東西會讓速度很難快得起來, 但還是有兩種方案啊: 1. 主機板先內建個4G 8G的不行嗎? 反正中低階板不要放, 中高階板也不會有人不買RAM或只買少少的RAM吧。 2. 放個一顆 4G 當 L4 Cache 也不錯啊, 用在高階板上 ------- 為什麼我會提這個, 是因為最近寫的軟體, 只要資料量一大, 整個性能就直直落, 可能掉到 1/10 之譜。 這時候就算拆成多緒來跑, 能增加的效益也很有限了, 因為共用的L3早就塞得滿滿的。 偏偏某些資料又很難拆成小份來跑。 所以我覺得有搞頭, 整體性能加個10%~20%都有可能, 特殊狀況下快個三五倍都不是問題。 ※ 引述《hn9480412 (ilinker)》之銘言: : https://news.xfastest.com/sk-hynix/23436/amd-vga-sk-hynix-hbm2/ : AMD顯示卡救星來了!SK HYNIX HBM2記憶體本季出貨 : 2016-07-16 : AMD R9 Fury X顯示卡去年第一個用上了HBM高頻寬顯示記憶體,實現了驚人的4096-bit位 : 元、512GB/s頻寬。大大節省了PCB面積,讓顯示卡整體做的更加小巧。不過遺憾的是容量 : 偏小,單顆只有1GB,Fury X用了四顆才提供4GB。 : 現在,SK Hynix宣布,第二代HBM2顯示記憶體已經開始量產,將在第三季內出貨,容量直 : 接提升至單顆4GB(4 Die堆疊),四顆就能組成16GB,輕鬆滿足任何顯示卡的需求。 : SK Hynix的HBM2有兩種頻率規格,其一為2Gbps,單顆頻寬256GB/s,四顆就能組成1TB/s : ,其二為1.6Gbps,單顆頻寬204GB/s,四顆就是816GB/s。AMD Vega核心高階卡就會採用 : SK Hynix的這種HBM2記憶體,不過要到明年初才會正式發表。 : 三星已經在今年初就宣布量產自己的HBM2,單顆容量同樣是4GB,頻寬也是256GB/s,今年 : 還計劃推出8GB型號。NVIDIA GP100核心的高效能繪圖卡-Tesla P100,據悉使用的就是三 : 星這種4GB HMB2,四顆組成16GB,不過總頻寬只有720GB/s,意味著頻率只有1.4Gbps。 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 1.171.53.13 ※ 文章網址: https://www.ptt.cc/bbs/PC_Shopping/M.1468684233.A.83D.html

07/16 23:52, , 1F
你在說啥....................
07/16 23:52, 1F

07/16 23:53, , 2F
額...哪邊有問題嗎
07/16 23:53, 2F

07/16 23:53, , 3F
你可以改寫成CUDA看看
07/16 23:53, 3F

07/16 23:55, , 4F
記得好像是會卡在LGA上? i
07/16 23:55, 4F

07/16 23:55, , 5F
因為用你這個例子可以推論到有N種方案可以讓效能更
07/16 23:55, 5F

07/16 23:56, , 6F
intel不敢說,當APU具有中階獨顯的架構+高頻寬
07/16 23:56, 6F

07/16 23:56, , 7F
為什麼不選有很多大人的理由
07/16 23:56, 7F

07/16 23:56, , 8F
請問你中低階的顯示卡要怎麼賣?
07/16 23:56, 8F

07/16 23:57, , 9F
再來,快取這個東西也不是一直增加量就可以增加效益
07/16 23:57, 9F

07/16 23:57, , 10F
這鬼玩意兒會不會撞一下就掉下來 XDDDD
07/16 23:57, 10F

07/16 23:57, , 11F
其實有現成的玩意啊 PS4和XB ONE
07/16 23:57, 11F

07/16 23:57, , 12F
其實跟命中率比較有關
07/16 23:57, 12F

07/16 23:58, , 13F
HBM的頻寬對大部分CPU軟體沒有幫助
07/16 23:58, 13F

07/16 23:59, , 14F
原PO是用自己寫的軟體阿
07/16 23:59, 14F

07/16 23:59, , 15F
我記得為了內顯效能好像有提過這個idea
07/16 23:59, 15F

07/16 23:59, , 16F
他運算量很大,不知道怎麼加速
07/16 23:59, 16F
我不確定cuda是否ok 因為資料前後關聯性滿高的 要去切、整合、判定什麼的 可能overhead會更多(而且很多時候是小資料 那就肯定不划算)

07/16 23:59, , 17F
但是瓶頸會在CPU Socket上 要弄成BGA才行
07/16 23:59, 17F

07/16 23:59, , 18F
CPU連DDR4數十GB頻寬都用不完,
07/16 23:59, 18F

07/16 23:59, , 19F
還能跟內顯分享....CPU更在意cache
07/16 23:59, 19F
也是啦 大家習慣了這種模式 所以軟體自然也都開發成適應這種模式的了..... ※ 編輯: wahaha99 (1.171.53.13), 07/17/2016 00:03:05

07/17 00:00, , 20F
弄成CACHE是要變成卡匣嗎@@
07/17 00:00, 20F

07/17 00:01, , 21F
原Po應該研究提升效率,因為HBM也救不了
07/17 00:01, 21F

07/17 00:01, , 22F
他的latency比cache長太多了。
07/17 00:01, 22F

07/17 00:02, , 23F
成本成本成本
07/17 00:02, 23F

07/17 00:03, , 24F
嗯 我記得當初沒弄出來也是因為成本 為了強化內顯
07/17 00:03, 24F

07/17 00:03, , 25F
搞這樣反而定價太高不如直接用顯獨
07/17 00:03, 25F

07/17 00:04, , 26F
APU就看看跟CPU共享L3和高頻DDR4之後有沒有救吧
07/17 00:04, 26F

07/17 00:05, , 27F
沒有救大概就注定那樣了 加eRam增加成本
07/17 00:05, 27F

07/17 00:05, , 28F
你可以像GOOGLE一樣,自己開發運算平台 XD
07/17 00:05, 28F

07/17 00:05, , 29F
撰寫專用電路
07/17 00:05, 29F

07/17 00:05, , 30F
就跟當初設計APU的初衷背道而馳了
07/17 00:05, 30F

07/17 00:06, , 31F
很好笑的是這設計在console上都不是問題XD
07/17 00:06, 31F

07/17 00:06, , 32F
你這種需求現在只能組多通道吧
07/17 00:06, 32F

07/17 00:06, , 33F
原PO買PS4跑程式阿
07/17 00:06, 33F

07/17 00:09, , 34F
vega有掛嗎?
07/17 00:09, 34F

07/17 00:14, , 35F
能疊在CPU裡是3dic的終極目標啊。就還做不到
07/17 00:14, 35F

07/17 00:15, , 36F
買PS4能跑自製程式嗎?沒這麼容易吧
07/17 00:15, 36F

07/17 00:15, , 37F
當然要破解阿 不然哩
07/17 00:15, 37F
還有 95 則推文
還有 5 段內文
07/17 10:56, , 133F
可以試試將要處理的資料的資料結構以你用的電腦CPU
07/17 10:56, 133F

07/17 10:56, , 134F
的Catch架構的特性來規劃,再加上使用針對Catch的
07/17 10:56, 134F

07/17 10:56, , 135F
低階指令,
07/17 10:56, 135F

07/17 10:56, , 136F
應該會有幫助...。
07/17 10:56, 136F

07/17 10:57, , 137F
原PO自己測試看看就知道了吧
07/17 10:57, 137F

07/17 10:57, , 138F
借支記憶體上去跑雙通 不就知道HBM大頻寬
07/17 10:57, 138F

07/17 10:57, , 139F
對你有沒有幫助嗎?!不過我覺得改善有限就是了啦
07/17 10:57, 139F

07/17 10:57, , 140F
畢竟就跟版友說的 現在頻寬都吃不完了
07/17 10:57, 140F

07/17 10:57, , 141F
資料運算來不及成瓶頸 又不是內顯 單通雙通差異不大
07/17 10:57, 141F

07/17 11:15, , 142F
去看5775c 128MB的edram有多大顆,就不能想像為什
07/17 11:15, 142F

07/17 11:15, , 143F
麼intel不放了
07/17 11:15, 143F

07/17 11:35, , 144F
3D繪圖通常tex cache的hit rate是無敵高
07/17 11:35, 144F

07/17 11:35, , 145F
因為texcord座標通常已知,會提早Fetch,
07/17 11:35, 145F

07/17 11:35, , 146F
而且一起抓回來cache的texels幾乎100%
07/17 11:35, 146F

07/17 11:35, , 147F
是周圍大量pixel未來要用的,很難miss.
07/17 11:35, 147F

07/17 11:35, , 148F
所以latency對GPU不重要,提早抓資料就行。
07/17 11:35, 148F

07/17 11:35, , 149F
但頻寬來不來的及把上百TMU數十Rop
07/17 11:35, 149F

07/17 11:35, , 150F
的資料抓取或寫入,就是另一回事。
07/17 11:35, 150F

07/17 11:35, , 151F
所以HBM高頻寬對高性能GPU幫助超大。
07/17 11:35, 151F

07/17 11:35, , 152F
CPU則相反,更在乎HBM的Latency進步多少
07/17 11:35, 152F

07/17 11:37, , 153F
給它一個頻寬50GB但Latency超低的會更快
07/17 11:37, 153F

07/17 11:43, , 154F
HBM的記憶體控制器跟512BIT的GDDR5控制器大小有得拚
07/17 11:43, 154F

07/17 11:44, , 155F
要內建雙控制器感覺就是很累贅
07/17 11:44, 155F

07/17 13:32, , 156F
放了如果賺不到錢 那就不用放了
07/17 13:32, 156F

07/17 15:18, , 157F
說真的啦,RAM bound要差到10倍效能我是覺得不太可
07/17 15:18, 157F

07/17 15:20, , 158F
能,軟體端也能做很大程度的最佳化。
07/17 15:20, 158F

07/17 16:48, , 159F
我跟你想得剛好相反 SOC搭內顯才是最合適HBM的
07/17 16:48, 159F

07/17 16:48, , 160F
而且這個市場最大(內顯)
07/17 16:48, 160F

07/17 16:49, , 161F
因為 內顯跟CPU分享HBM 這樣每塊錢效益更高
07/17 16:49, 161F

07/17 16:50, , 162F
除了內顯外 第二個HBM市場是SERVER超級電腦
07/17 16:50, 162F

07/17 16:51, , 163F
就像你說的 作為L4
07/17 16:51, 163F

07/17 16:51, , 164F
這部份利潤蠻高的 玩得起HBM
07/17 16:51, 164F

07/17 17:18, , 165F
但是HBM好像延遲較慢
07/17 17:18, 165F

07/17 17:20, , 166F
就看apple能不能加速3dic的整合啊 據說A10會用
07/17 17:20, 166F

07/17 18:29, , 167F
AMD據說打算在APU內顯做HBM
07/17 18:29, 167F

07/17 18:30, , 168F
可能不用很大,因為貼圖可擺system ram
07/17 18:30, 168F

07/17 18:31, , 169F
就像i的edram也只是cover render target
07/17 18:31, 169F

07/17 18:31, , 170F
的重度頻寬存取,貼圖較輕鬆就擺主記憶體
07/17 18:31, 170F

07/17 18:32, , 171F
若不跑繪圖時,則把HBM當L4? 一魚兩吃
07/17 18:32, 171F

07/17 21:15, , 172F
你應該不知道當年Rambus怎麼死的....
07/17 21:15, 172F
文章代碼(AID): #1NYbV9Wz (PC_Shopping)
文章代碼(AID): #1NYbV9Wz (PC_Shopping)