PCDVD數位科技討論區
PCDVD數位科技討論區   註冊 常見問題 標記討論區為已讀

回到   PCDVD數位科技討論區 > 電腦硬體討論群組 > 顯示卡討論區
帳戶
密碼
 

  回應
 
主題工具
lzarconlony1
*停權中*
 
lzarconlony1的大頭照
 

加入日期: Jun 2015
您的住址: 金一十大女支三
文章: 1,282
關於GPU內數量問題參照wiki
NV GPU Unit
AMD GPU Unit
     
      
舊 2015-09-08, 10:40 AM #81
回應時引用此文章
lzarconlony1離線中  
deanhu
Major Member
 

加入日期: Nov 2001
文章: 200
nVIDIA已經大到可以想要隻手遮天;AMD已經瀕危到只能不斷膨風?
 
舊 2015-09-08, 02:20 PM #82
回應時引用此文章
deanhu離線中  
rockports
Power Member
 
rockports的大頭照
 

加入日期: Feb 2015
文章: 618
雞排攤:準備中。
舊 2015-09-08, 02:33 PM #83
回應時引用此文章
rockports離線中  
freaky
Advance Member
 

加入日期: Jan 2002
文章: 449
把原本render可以做的事拿去用compute來做,不是因為某家GPU render unit常在idle的關係?對遊戲廠商來說這叫針對硬體特性最佳化,什麼出招不出招的。
舊 2015-09-08, 02:43 PM #84
回應時引用此文章
freaky離線中  
orakim
Master Member
 

加入日期: Sep 2003
文章: 1,810
> DX11時螞蟻無法團結 工作分配不到極限 打不贏蝗蟲
> DX12把工作切細 螞蟻能發揮效率 蝗蟲習慣單打獨鬥 要面對平行運算效率下降
用鐵路、馬路來比喻會比較適合

在穩定的運輸量下 時刻表固定,鐵路是非常有效率的交通工具(傳統的GPU rendering是這種)
但問題點是鐵路就一條,遇到其他列車搶道 那就要停下來讓他過;搶道的情形越頻繁鐵路的速度越慢
NV,intel的架構在 DX11就像是鐵路,在傳統圖形運算上是非常有效率的方式
GCN的架構在DX11 就是只有稀稀疏疏車輛的馬路,效率上沒辦法比的上NV,intel

DX12開放多執行緒,讓運算不再單純 NV,intel那種架構就很容易出現搶佔的情形
要讓火車停下來再出發耗費(延遲)的時間會讓它沒有效率;(這部份是context switch)
必須要降低搶佔的情形 (換句話說就是限制遊戲的功能),就出現NV要Oxide 關閉特定功能的狀況

GCN架構DX12與DX11不同點就在於
DX11原本稀稀疏疏的馬路,在DX12可以塞其他車輛進去再利用
讓他原本在DX11沒效率的運輸方式,在DX12可以塞的滿滿滿 效率可以提昇很多
當然塞到爆 有搶佔的情形時,GCN其實也是需要 context switch;
不過目前看來沒有context switch的GCN1.1 在DX12內也適應良好

之前提到的那個說法,講明了其實是
人家在DX11就是(粒度大)有效率的架構 又何必逼他使用DX12(粒度大本來就不適合)
GCN在DX11沒力的情形才需要積極的促進遊戲轉成DX12,讓定位與NV接近的顯卡 效能可以跟的上或者超越
反正DX12的遊戲還很久,NV、intel 還有軟、硬體改良的時間

此文章於 2015-09-08 03:18 PM 被 orakim 編輯.
舊 2015-09-08, 03:15 PM #85
回應時引用此文章
orakim離線中  
lzarconlony1
*停權中*
 
lzarconlony1的大頭照
 

加入日期: Jun 2015
您的住址: 金一十大女支三
文章: 1,282
引用:
作者orakim
> DX11時螞蟻無法團結 工作分配不到極限 打不贏蝗蟲
> DX12把工作切細 螞蟻能發揮效率 蝗蟲習慣單打獨鬥 要面對平行運算效率下降
用鐵路、馬路來比喻會比較適合

在穩定的運輸量下 時刻表固定,鐵路是非常有效率的交通工具(傳統的GPU rendering是這種)
但問題點是鐵路就一條,遇到其他列車搶道 那就要停下來讓他過;搶道的情形越頻繁鐵路的速度越慢
NV,intel的架構在 DX11就像是鐵路,在傳統圖形運算上是非常有效率的方式
GCN的架構在DX11 就是只有稀稀疏疏車輛的馬路,效率上沒辦法比的上NV,intel

DX12開放多執行緒,讓運算不再單純 NV,intel那種架構就很容易出現搶佔的情形
要讓火車停下來再出發耗費(延遲)的時間會讓它沒有效率;(這部份是context switch)
必須要降低搶佔的情形 (換句話說就是限制遊戲的功能),就出現NV要Oxide 關閉特定功能的狀況

GCN架構DX12與DX11不同點就在於
...


最近登革熱 對消毒水有莫名反感
你越消毒我越想飛 甚至飛不夠還會考慮跨海飛
工程問題回歸原點 不要動不動就對手行銷攻擊
噴太多消毒水小心蚊子沒殺死先把人毒死

------
我大概看懂"粒度大" 不過如果要對應英文該怎麼說?

NV的threads是用Warp AMD則是Wavefront
其實前面的比喻很籠統 可能我敘述能力不夠好
加上這東西其實真的蠻複雜 很難表達
還有一些比較深入的也不方便現在表達 所以..

Warp目前是32 threads, Wavefront則是64 threads.
很有趣的一個數字 跟想像中不同

還有記憶體架構也應該納入考量
GPU走到現在已經是影像專用Processor 有不同思維

這些東西沒想像中那麼新 其實都是前一段時間產物
所以不曉得到底有甚麼好藏料 需要姿態這麼高高在上
舊 2015-09-08, 03:36 PM #86
回應時引用此文章
lzarconlony1離線中  
orakim
Master Member
 

加入日期: Sep 2003
文章: 1,810
> 我大概看懂"粒度大" 不過如果要對應英文該怎麼說?
你可以查字典,這串intel 也有提到(如果你有看原文的話)
> 工程問題回歸原點 不要動不動就對手行銷攻擊
其實我不知道你在說什麼,包含你下面回的東西

順便提一下 粒度大小是硬體架構決定的,個人不認為軟體上有什麼辦法可以改善
軟體能做大概就context switch 能不能降低延遲
這部份據AMD說法 NV maxwell 有這個架構 還沒有實裝功能
(當然AMD是去年提到的,NV後來有沒有實做就不清楚了)

此文章於 2015-09-08 03:51 PM 被 orakim 編輯.
舊 2015-09-08, 03:44 PM #87
回應時引用此文章
orakim離線中  
lzarconlony1
*停權中*
 
lzarconlony1的大頭照
 

加入日期: Jun 2015
您的住址: 金一十大女支三
文章: 1,282
引用:
作者freaky
不好意思nVidia產品線和市場比較多元,GPU不是針對DX12特化的。我這樣說你就滿意了嗎?如果不久的將來有別的benchmark出現,nVidia的DX12 async compute效能很好你要怎麼說?這不是假設問題喔。


請問一張以遊戲市場為訴求的遊戲顯示卡 不對DX12特化 是怎樣的多元?
遊戲卡可以跑繪圖嗎 那繪圖卡是跑甚麼東西用? 跑遊戲嗎?

再次要求其他benchmark把async compute關掉?

引用:
作者freaky
我也來離題一下。
其實我對現在的社會蠻感嘆的,講真話沒人要聽,大家寧願相信路邊小道消息,只因為標題聳動內容生動活潑,很多根本就是置入性行銷!
想理性討論都被說是出來消毒的。

================
我到前陣子才知道無聊轉到的韓劇(搞不好根本就不是同一部)劇名不是羅琳亞的塑身衣~_~


請問哪邊置入行銷? NV反行銷自己要求對方關閉async compute嗎?
還有連電視劇的標題跟子標題都弄不懂 觀察力會不會太好

引用:
作者freaky
其實也不是婊到誰的問題,雙方想做的都是最佳化。現在Windows開發都是以小改版的方式進行,所以更新的速度會比之前快。可能有些人不知道,AMD/Intel/nVidia在Microsoft都有駐點人員和DirectX團隊共同開發,所以設計問題彼此都有一定程度的了解。只是某公司的行銷手法愈趨極端,經常以似是而非的說法混淆視聽,實非我所樂見。


所以千錯萬錯都是對方的錯
要求遊戲商關閉async compute --> 對
GPU沒DX12"硬體"特化 --> 對
對手宣傳自己GCN特點 --> 錯 錯的太離譜 你們不准說我們可以做 是這樣的意思嗎

引用:
作者freaky
Microsoft一直想做到的是mid-buffer preemption,目前nVidia的GPU在這方面確實有所限制,也在和DX team討論其他的可行方式,因其最終目的是在降低latency。不過最近這個benchmark的議題主因可能倒不是在此,而是遊戲針對AMD GPU的特性使用async compute的方式,導致speedup的因素來自於compute-compute concurrency而非compute-render concurrency。


準備要施壓MS?因Maxwell已經開賣而Pascal流片?

引用:
作者freaky
把原本render可以做的事拿去用compute來做,不是因為某家GPU render unit常在idle的關係?對遊戲廠商來說這叫針對硬體特性最佳化,什麼出招不出招的。


那odixe為什麼不准用async compute?

你失憶嗎 幫你回憶


這種說法 該不會當初要求關閉async compute功能就是同組的
舊 2015-09-08, 03:59 PM #88
回應時引用此文章
lzarconlony1離線中  
lzarconlony1
*停權中*
 
lzarconlony1的大頭照
 

加入日期: Jun 2015
您的住址: 金一十大女支三
文章: 1,282
引用:
作者orakim
> 我大概看懂"粒度大" 不過如果要對應英文該怎麼說?
你可以查字典,這串intel 也有提到(如果你有看原文的話)
> 工程問題回歸原點 不要動不動就對手行銷攻擊
其實我不知道你在說什麼,包含你下面回的東西

順便提一下 粒度大小是硬體架構決定的,個人不認為軟體上有什麼辦法可以改善
軟體能做大概就context switch 能不能降低延遲
這部份據AMD說法 NV maxwell 有這個架構 還沒有實裝功能
(當然AMD是去年提到的,NV後來有沒有實做就不清楚了)


intel那串沒提到喔 粒度大我看不懂
不過如果是Coarse-grained or Fine-grained
這兩個中文叫做粗粒度 細粒度
大概像這樣

grain的形容還不夠精細 除了threads還有flow strategy等issue
寫驅動的還不趕快去想
舊 2015-09-08, 04:43 PM #89
回應時引用此文章
lzarconlony1離線中  
freaky
Advance Member
 

加入日期: Jan 2002
文章: 449
粒度是對岸翻譯,我們是用精細度,英文是granularity。
舊 2015-09-08, 04:57 PM #90
回應時引用此文章
freaky離線中  


    回應


POPIN
主題工具

發表文章規則
不可以發起新主題
不可以回應主題
不可以上傳附加檔案
不可以編輯您的文章

vB 代碼打開
[IMG]代碼打開
HTML代碼關閉



所有的時間均為GMT +8。 現在的時間是06:08 AM.


vBulletin Version 3.0.1
powered_by_vbulletin 2025。