Re: [請益] 請問Haswell集顯效能提升的問題

看板PC_Shopping (個人電腦購買)作者 (BL2400PT真不錯)時間14年前 (2012/05/12 10:28), 編輯推噓12(1202)
留言14則, 14人參與, 最新討論串2/2 (看更多)
後來看到Lucid MVP的原始廣告, "他會智慧型的決定哪些render命令可以省略" 好的 要說Lucid MVP是取巧還是作弊都通.結案了 底下繼續回到SLI/Crossfire的micro-sturring ※ 引述《Khadgar (Khadgar)》之銘言: : 感謝Jk大的詳細解說 : 由於AFR可以大幅提高平均FPS, 但是犧牲的是兩個frame之間的 : frame interval的穩定性 : 這是否表示說, 假設單GPU render第k個frame的 interval是 Tk : 那 Single GPU的情況下就是 : n n : 測試 FPS = --------------, 但是實際上的 FPS = --------------- : Σ(1,n/2)T 2k Σ(1,n/2)T 2k-1 其實micro-stuttering的發生主因在GPU2會比較慢算完而且還要再把 frame buffer傳回gpu1, GPU2 ------2----------4-----------6------------8---------理論 ----------2----------4-----------6------------8-----實際 GPU1 1-----------3-----------5------------7------------9 合成後 1-----2-----3----4------5----6-------7----8-------9 理論 1---------2-3--------4--5--------6---7--------8---9 實際 第一個傳給gpu2比較慢的原因...這我要老實說我不知道, 因為我沒有作過有crossfire/sli的gpu. 第二個回傳的framebuffer大概要花多少時間可以用估計的, 因為SLI/crossfire的cable大概都只有1GB/S.不靠cable的時候 可分享到的頻寬也沒有比這個高很多... 1920x1080,RGBA frame buffer就要1920x1080x4 byte.>8MB, 用1GB/S的cable傳遞至少要8ms.>60FPS以上的時候這就吃掉一半的時間了 如果還要傳遞Z+stencil,就是1920x1080x2~4 byte...但好像不會這麼作 事實上AFR中因為這個因素造成的micro-stuttering,其他實作法中 雖然不會產生micro-stuttering,但是會以降低總FPS表現 假定GPU2開始繪製的時候的延遲是2ms,而他複製frame buffer回來到gpu的時間 是6ms.GPU1/GPU2單張正常繪圖的時間是33ms(=30FPS). 那麼.... AFR下. GPU2 -------2--2-------4--4------6----6------------8---- 2+33ms 6ms GPU1 1-----------3-----------5------------7------------9 33ms 33ms 33ms 合成後 1---------2-3--------4--5--------6---7--------8---9 1-2之間,原本預期是33/2=16ms,但實際上會是33/2+2+6=24ms, 2-3之間就是33/2-2-6=8ms,所以這個系統中,frame會以24-8-24-8 的間隔產生micro-stuttering,帳面FPS是60,但體感fps在40左右或者更差 如果用非AFR呢?GPU1繪製一半的圖的時間是16ms,但GPU2繪製一半的圖的時間則是 2+16+6/2(因為Framebuffer剩下一半)=21ms,帳面FPS和體感FPS都是48左右. GPU廠商預設愛用AFR是因為數字真的都比較漂亮. : 問題1就來了, 如果說GPU1 比 GPU2快 (例如Hybrid CF) : 那會變成 : (情況1) : |1|---T1--- |3|---T3---(pending GPU2) |5|---T5--- : **|2|-T2- **|4|-T4- : 的哪種情況呢...找了好久好像都沒有這方面的東西 : 如果是 1, 就會變古老的 5870/5850 CF = 5850 CF, 因為5870 要等 5850 大多數都是1.然後限制只能使用同級晶片SLI/Crossfire ATI/AMD的限制比較寬一點點但還是同一顆晶片的不同版本. 雖然應該沒有廠商使用2.的方法,不過他不會造成micro-stutering更嚴重. 畢竟假如由GPU2連續計算兩個frame的話 那他兩個FRAME都會延遲,間隔還是一樣長. : 可是實際上感受到的FPS根本更差, 因為如果|x|就單純複製|1|,那根本就等於把 : 一個Frame拆成兩個 frame來算 FPS....當然數字會變大 : 還有一個問題是, MVP真那麼聰明知道下一個frame一定和上一個frame一模一樣? : 他如果判斷錯誤, 那不是只會拉低時實際上感受到的 FPS? : (因為他把本來應該有2個 frame一小段畫面變成1 frame...等於實際上吃掉一個frame) 如同前面所述,Lucid MVP會省掉部分繪製,但實際上畫面沒有更新的話, 除了製造假的高FPS....還有一個不同就是傳統遊戲製作很多都是偵測鍵盤輸入/網路等 週邊事件,是和一個frame更新完之後一起作,那麼這一些遊戲在Lucid MVP下就不會 因為FPS瞬降而導致輸入不及.也許這是少有的好處?但不是競賽選手說起來也沒差. -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 140.114.78.54

05/12 10:30, , 1F
有神快拜!!
05/12 10:30, 1F

05/12 10:33, , 2F
快推不然人家以為我們看不懂 其實還是看不懂
05/12 10:33, 2F

05/12 10:34, , 3F
恩恩原PO把我想的都打出來了~~~
05/12 10:34, 3F

05/12 10:38, , 4F
有神快拜!
05/12 10:38, 4F

05/12 10:40, , 5F
娘子 有神快出來拜~~
05/12 10:40, 5F

05/12 10:53, , 6F
有神快推
05/12 10:53, 6F

05/12 10:55, , 7F
淡定嗎?
05/12 10:55, 7F

05/12 11:04, , 8F
能不能用一句話解釋 "有用但是不顯著?" 這樣嗎?
05/12 11:04, 8F

05/12 11:17, , 9F
LUCID MVP的話 就是取巧啊...製造帳面數字
05/12 11:17, 9F

05/12 11:31, , 10F
jk推!
05/12 11:31, 10F

05/12 11:37, , 11F
推~
05/12 11:37, 11F

05/12 14:03, , 12F
推:)
05/12 14:03, 12F

05/12 17:13, , 13F
05/12 17:13, 13F

05/12 21:04, , 14F
05/12 21:04, 14F
文章代碼(AID): #1FhSgxjp (PC_Shopping)
文章代碼(AID): #1FhSgxjp (PC_Shopping)