PTT數位生活區 / PC_Shopping (個人電腦購買)

Re: [閒聊] A卡在CPU瓶頸的狀況下能較N卡快

看板PC_Shopping (個人電腦購買)作者 (3d)時間5年前 (2021/03/11 22:39), 5年前編輯推噓10(10推 0噓 27→)
留言37則, 9人參與, 5年前最新討論串2/2 (看更多)
怒刪，XD，瞎子領路，亂扯一通。 問題是在State Changes，講了快20年了，外行人還是亂講一通。 2014年Nv還特別再講一次， https://developer.nvidia.com/content/how-modern-opengl-can-radically-reduce-driver-overhead-0 https://reurl.cc/0DKWr6 http://media.steampowered.com/apps/steamdevdays/slides/beyondporting.pdf 最重要的一張圖 https://i.imgur.com/AnKac7V.jpg
Nv的驅動程式，在state changes時作很嚴謹的validation跟compilation，所以吃cpu，Amd驅動程式，嗯你知道的。 這幾個遊戲，從benchmark來看，就知道繪圖引擎寫的xx的，一定是State Changes亂換，batch沒做好，花的時間都在validation跟compilation。3090vs5600xt在1080p差不到2x？有點經驗的都知道，被State Changes打敗了。 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 101.10.31.27 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/PC_Shopping/M.1615473589.A.3DE.html
推
03/11 22:42, 5年前 , 1F
State Changes不夠嚴謹(O) State Changes處理慢(X)
03/11 22:42, 1F
→
03/11 22:42, 5年前 , 2F
嗯嗯 我好像突然都理解了
03/11 22:42, 2F
→
03/11 22:44, 5年前 , 3F
沒寫過程式？optimizing compiling一定慢
03/11 22:44, 3F
推
03/11 22:47, 5年前 , 4F
你最重要的一張圖 看不到
03/11 22:47, 4F
→
03/11 22:48, 5年前 , 5F
縮一下網址好嗎？
03/11 22:48, 5F
推
03/11 22:48, 5年前 , 6F
長知識
03/11 22:48, 6F
※ 編輯: oopFoo (101.10.31.27 臺灣), 03/11/2021 22:51:31
推
03/11 22:52, 5年前 , 7F
咦？可是我去年寫 Vulkan 的時候 NV 的 validation
03/11 22:52, 7F
→
03/11 22:53, 5年前 , 8F
好像還蠻鬆的說。intel 上面會炸的 code 在 NV 上
03/11 22:53, 8F
→
03/11 22:53, 5年前 , 9F
會過 XD
03/11 22:53, 9F
跟Nv driver team聯絡，如果真有bugs他們會修正。他們反應很快。
推
03/12 00:18, 5年前 , 10F
所以怎麼證明NV比較嚴謹？NV自己說是就是？
03/12 00:18, 10F
Amd遊戲一大堆崩潰，這還不夠證明
→
03/12 02:24, 5年前 , 11F
這是for oepngl好嗎? 現代API DX12/vulkan/metal
03/12 02:24, 11F
→
03/12 02:25, 5年前 , 12F
的validation幾乎都要application自己負責了
03/12 02:25, 12F
validation是driver永遠跑不掉的責任。Vulkan只是低階，State Changes的問題沒變 ※ 編輯: oopFoo (101.10.31.27 臺灣), 03/12/2021 06:57:22
推
03/12 07:53, 5年前 , 13F
那A卡驅動現在不會了 是不是也沒比較嚴謹
03/12 07:53, 13F
→
03/12 08:02, 5年前 , 14F
AMD的driver是有在改進，但人手不足資源不夠，不然
03/12 08:02, 14F
推
03/12 08:03, 5年前 , 15F
你這個是說在任何程式執行時都會套用這些驗證 而這
03/12 08:03, 15F
→
03/12 08:03, 5年前 , 16F
些驗證會吃 CPU的運算效能 聽你的意思是一種糾錯機
03/12 08:03, 16F
→
03/12 08:03, 5年前 , 17F
制？ 所以 CPU異常的時候 N卡也會跟著異常？
03/12 08:03, 17F
→
03/12 08:03, 5年前 , 18F
AMD的gpu其實沒那麼差。
03/12 08:03, 18F
推
03/12 08:08, 5年前 , 19F
就是說失去程式崩潰的預防機制？
03/12 08:08, 19F
→
03/12 08:21, 5年前 , 20F
簡單來講，你貼圖handle有存在?檢查，buffer size對
03/12 08:21, 20F
→
03/12 08:22, 5年前 , 21F
嗎？檢查。一堆東西要檢查，不然gpu傻傻執行就崩潰
03/12 08:22, 21F
→
03/12 08:23, 5年前 , 22F
然後這些都是cpu來檢查。還有state changes的時候
03/12 08:23, 22F
→
03/12 08:24, 5年前 , 23F
gpu的code要recompile，這都要靠cpu來作。
03/12 08:24, 23F
推
03/12 09:23, 5年前 , 24F
原來如此 所以一個遊戲越容易出錯 就越容易讓N卡驅
03/12 09:23, 24F
→
03/12 09:23, 5年前 , 25F
動更依賴 CPU摟
03/12 09:23, 25F
→
03/12 09:43, 5年前 , 26F
應該是這麼說，遊戲其實常常傳錯誤參數，但驅動程式
03/12 09:43, 26F
→
03/12 09:43, 5年前 , 27F
不能讓這些錯誤造成遊戲崩潰，所以你傳的參數要檢查
03/12 09:43, 27F
→
03/12 09:45, 5年前 , 28F
然後修正。但不管遊戲有沒有錯誤，驅動程式都會仔細
03/12 09:45, 28F
→
03/12 09:45, 5年前 , 29F
檢查參數，這會花一些時間。
03/12 09:45, 29F
→
03/12 09:48, 5年前 , 30F
但，花時間最多的應該是compile gpu code
03/12 09:48, 30F
→
03/12 09:49, 5年前 , 31F
Nv的gpu code確實效率佳
03/12 09:49, 31F
推
03/12 12:34, 5年前 , 32F
N卡在Kepler架構後 其實Scheduling的過程一部份會
03/12 12:34, 32F
→
03/12 12:34, 5年前 , 33F
會交給CPU來處理 所以對CPU的依賴有稍微提高
03/12 12:34, 33F
→
03/12 23:46, 5年前 , 34F
那也可能是客戶需求問題衍生結果
03/12 23:46, 34F
→
03/12 23:46, 5年前 , 35F
AMD顧慮家機客戶，常常CPU很鳥
03/12 23:46, 35F
→
03/12 23:47, 5年前 , 36F
驅動必須盡可能吃最少cpu資源
03/12 23:47, 36F
→
03/12 23:48, 5年前 , 37F
而PC GPU是家機架構同系列的產物
03/12 23:48, 37F
‣ 更多 oopFoo 的文章
文章代碼(AID): #1WIYkrFU (PC_Shopping)
PC_Shopping 近期熱門文章
更多 近期熱門文章 >>
PTT數位生活區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 oopFoo 的文章
文章代碼(AID): #1WIYkrFU (PC_Shopping)