推 panex0845 : State Changes不夠嚴謹(O) State Changes處理慢(X) 03/11 22:42
→ panex0845 : 嗯嗯 我好像突然都理解了 03/11 22:42
→ oopFoo : 沒寫過程式？optimizing compiling一定慢 03/11 22:44
推 henry46277 : 你最重要的一張圖 看不到 03/11 22:47
→ henry46277 : 縮一下網址好嗎？ 03/11 22:48
推 LoveShibeInu: 長知識 03/11 22:48
※ 編輯: oopFoo (101.10.31.27 臺灣), 03/11/2021 22:51:31
推 Bencrie : 咦？可是我去年寫 Vulkan 的時候 NV 的 validation 03/11 22:52
→ Bencrie : 好像還蠻鬆的說。intel 上面會炸的 code 在 NV 上 03/11 22:53
→ Bencrie : 會過 XD 03/11 22:53
跟Nv driver team聯絡，如果真有bugs他們會修正。他們反應很快。
推 sporocyst : 所以怎麼證明NV比較嚴謹？NV自己說是就是？ 03/12 00:18
Amd遊戲一大堆崩潰，這還不夠證明
→ otaku690 : 這是for oepngl好嗎? 現代API DX12/vulkan/metal 03/12 02:24
→ otaku690 : 的validation幾乎都要application自己負責了 03/12 02:25
validation是driver永遠跑不掉的責任。Vulkan只是低階，State Changes的問題沒變
※ 編輯: oopFoo (101.10.31.27 臺灣), 03/12/2021 06:57:22
推 henry46277 : 那A卡驅動現在不會了 是不是也沒比較嚴謹 03/12 07:53
→ oopFoo : AMD的driver是有在改進，但人手不足資源不夠，不然 03/12 08:02
推 henry46277 : 你這個是說在任何程式執行時都會套用這些驗證 而這 03/12 08:03
→ henry46277 : 些驗證會吃 CPU的運算效能 聽你的意思是一種糾錯機 03/12 08:03
→ henry46277 : 制？ 所以 CPU異常的時候 N卡也會跟著異常？ 03/12 08:03
→ oopFoo : AMD的gpu其實沒那麼差。 03/12 08:03
推 henry46277 : 就是說失去程式崩潰的預防機制？ 03/12 08:08
→ oopFoo : 簡單來講，你貼圖handle有存在?檢查，buffer size對 03/12 08:21
→ oopFoo : 嗎？檢查。一堆東西要檢查，不然gpu傻傻執行就崩潰 03/12 08:22
→ oopFoo : 然後這些都是cpu來檢查。還有state changes的時候 03/12 08:23
→ oopFoo : gpu的code要recompile，這都要靠cpu來作。 03/12 08:24
推 henry46277 : 原來如此 所以一個遊戲越容易出錯 就越容易讓N卡驅 03/12 09:23
→ henry46277 : 動更依賴 CPU摟 03/12 09:23
→ oopFoo : 應該是這麼說，遊戲其實常常傳錯誤參數，但驅動程式 03/12 09:43
→ oopFoo : 不能讓這些錯誤造成遊戲崩潰，所以你傳的參數要檢查 03/12 09:43
→ oopFoo : 然後修正。但不管遊戲有沒有錯誤，驅動程式都會仔細 03/12 09:45
→ oopFoo : 檢查參數，這會花一些時間。 03/12 09:45
→ oopFoo : 但，花時間最多的應該是compile gpu code 03/12 09:48
→ oopFoo : Nv的gpu code確實效率佳 03/12 09:49
推 tint : N卡在Kepler架構後 其實Scheduling的過程一部份會 03/12 12:34
→ tint : 會交給CPU來處理 所以對CPU的依賴有稍微提高 03/12 12:34
→ kuma660224 : 那也可能是客戶需求問題衍生結果 03/12 23:46
→ kuma660224 : AMD顧慮家機客戶，常常CPU很鳥 03/12 23:46
→ kuma660224 : 驅動必須盡可能吃最少cpu資源 03/12 23:47
→ kuma660224 : 而PC GPU是家機架構同系列的產物 03/12 23:48