游戲跑分新視角：細(xì)看一秒內(nèi)幀數(shù)變化
事實(shí)上，文章一開始并沒有打算深入探討多卡并聯(lián)系統(tǒng)的Micro-stuttering（幀延時波動，實(shí)在找不到一個合適的詞翻譯…）。新測試方法幫助我們發(fā)現(xiàn)許多有意思的問題，也說明我們的方向沒有錯。但是，這個Micro-stuttering卻使得我們的任務(wù)復(fù)雜了不少。
這張圖可以比較直觀的反映Micro-stuttering（X軸以ns為單位，Y軸以幀數(shù)為單位），多卡系統(tǒng)單位時間內(nèi)幀延時會上下波動。
很自然，我們已經(jīng)聯(lián)系了主要的顯卡芯片廠商，看看他們對這個問題的解釋。但是令我們意外的是，不管是AMD還是NVIDIA都直接而且坦率地承認(rèn)多卡系統(tǒng)的Micro-stuttering確實(shí)存在，而且是一個亟待解決的問題，他們也已研究多時。但有趣是，對于以上的多核心產(chǎn)品（比如HD 6990、GTX 590）或者多卡解決方案（SLI、CrossFire），AMD和NVIDIA都沒有明確告知消費(fèi)者這個問題的存在。相當(dāng)諷刺，不是嗎？
AMD的David Nalasco在評估多顯卡派遣幀任務(wù)的時候就發(fā)現(xiàn)了Micro-stuttering，他注意到幀數(shù)延時的波動隨著游戲的反復(fù)進(jìn)行，因?yàn)閹c幀之間的相對時間是可變的。而且他聲稱這個問題并沒有普遍性。
根據(jù)有限但還算公平的測試，我們對于這個說法基本認(rèn)同。首先，盡管幀延時波動隨著時間一直存在，但它更傾向于既定的而且反復(fù)進(jìn)行的測試場景。其次，波動似乎在有相對性能有限的平臺里程度更深。例如，我們在相同設(shè)置下測試相同的游戲，中端的HD 6870 CF所體現(xiàn)出來的幀間波動就要比更高端的HD 6970 CF更加明顯。同理，GTX 560 SLI和GTX 580 SLI的情況也是如此。如果這一狀況是多卡系統(tǒng)的一大特性，那顯然是負(fù)面的。第三，在我們的測試數(shù)據(jù)中，CrossFire在抑制幀延時波動方面明顯沒有SLI好。雖然我們還不能說以上三點(diǎn)具有普適性，但知道從我們的測試中得到的結(jié)果就是如此。
Nalasco告訴我們一定程度上抑制幀延時波動有許多方法。你或許已經(jīng)猜到了，那就是“垂直同步”。“垂直同步”啟用之后，可以阻止當(dāng)前幀渲染完畢后GPU跳轉(zhuǎn)到不同的資源緩沖區(qū)（已完成新的幀渲染），而幀緩沖區(qū)跳轉(zhuǎn)被推遲到下一次屏幕刷新。不過Nalasco也指出開啟“垂直同步”也只能在“某些時候”有效果，換句話說也就是不一定完全有效。所以，我們認(rèn)為關(guān)于“垂直同步”對于Micro-stuttering的精確影響還很難預(yù)測。
Ps.如果選擇“等待垂直同步信號”（也就是“打開垂直同步”），顯卡繪制圖形前會等待信號；性能強(qiáng)勁的顯卡則會提前完成繪制，并在下個信號到達(dá)之前等待。此時，游戲的fps值會受顯示器刷新率的制約。對于高端顯卡而言，這限制了其性能的發(fā)揮。而如果選擇“不等待垂直同步信號”（也就是“關(guān)閉垂直同步”），那么顯卡繪制完一屏畫面，不等待垂直同步信號，就開始下一屏畫面的繪制，自然可以完全發(fā)揮顯卡的實(shí)力。但是，不要忘記，正是因?yàn)榇怪蓖降拇嬖冢拍苁沟糜螒蜻M(jìn)程和顯示器刷新率同步，使得畫面平滑，使得畫面穩(wěn)定。取消了垂直同步信號，固然可以換來更快的速度，但是在圖像的連續(xù)性上，性能勢必打折扣。這也正是很多朋友抱怨關(guān)閉垂直后發(fā)現(xiàn)畫面不連續(xù)的理論原因。
有意思的是Nalasco提到的另一中可能：一種“更加聰明”的“垂直同步”，可以通過人的視覺感知來控制幀的跳轉(zhuǎn)。聽起來很不錯，這種方法也有潛在的可行性。但Nalasco只是說了一些未來的構(gòu)想，對于現(xiàn)實(shí)技術(shù)只字未提，他也承認(rèn)AMD到現(xiàn)在也沒有一個十全十美的解決方案。
另外，他還透露，未來AMD會在這方面投入更多精力，因?yàn)閷矶嗫ㄏ到y(tǒng)肯定和LInao APU有很大關(guān)聯(lián)，而且是不對稱的結(jié)構(gòu)，相比目前的多卡系統(tǒng)產(chǎn)生Micro-stuttering的幾率更大。
而NVIDIA的Tom Petersen也進(jìn)行了如下的圖文闡述，幫助我們更好的理解。
上面的示意圖表明了幀產(chǎn)生的流程，從游戲引擎到顯示輸出，非常有助于上下文的討論。
其中，游戲引擎包含了一系列的內(nèi)部變量，物理模擬、圖形處理以及用戶交互等等。當(dāng)一個幀開始渲染，圖形引擎首先將其交給DirectX API。據(jù)Petersen的說法，F(xiàn)raps就是在這個時候開始時間信息記錄。接下來，DirectX將調(diào)用高級API和Shader程序?qū)⑵滢D(zhuǎn)換成更基地的指令，然后交由顯卡驅(qū)動處理。進(jìn)而，顯卡驅(qū)動將這些DirectX低級指令轉(zhuǎn)化成機(jī)器語言交付給GPU進(jìn)行渲染，最終輸出到顯示設(shè)備。
為了更好的闡述關(guān)鍵問題，Petersen定義了許多變量。比如，”Stutter”就表示游戲時間（T_game）和輸出顯示時間（T_display）之間差的絕對值、”Lag”表示”T_game”和”T_dispaly”之間的耗時、”Slide show”表示每幀渲染時間的總共耗時。按照Petersen的觀點(diǎn)，在這三個變量中，玩家在游戲中感知最為明顯的就是”Stutter”。
在Petersen透露的諸多細(xì)節(jié)中，最讓人印象深刻的莫過于“NVIDIA在旗下的GPU中安置了許多硬件單元用來固定多卡系統(tǒng)的幀延時波動”。主要原理是基于一種名為“Frame metering（幀測量）”的技術(shù)，可以在幀間進(jìn)行動態(tài)追蹤。一些“表現(xiàn)較快”的幀會被適當(dāng)延遲，換句話說，就是GPU不會直接跳轉(zhuǎn)到新的緩沖區(qū)，從而保證渲染后的畫面能夠均勻地進(jìn)行顯示輸出。而這些延遲會根據(jù)幀率的快慢在特性的時間進(jìn)行調(diào)整。據(jù)稱，這種“Frame metering（幀測量）”技術(shù)至少在NVIDIA G80時代就已經(jīng)開始運(yùn)用了。
現(xiàn)在，注意一下其中的含義。因?yàn)檫@種延遲測量是大概是在T_render和T_display之間進(jìn)行的，所以Fraps根本不會進(jìn)行記錄。這也就意味著我們之前的SLI測試數(shù)據(jù)沒有將這一過程展現(xiàn)給讀者。呈現(xiàn)在他們面前的是表面看起來波動不大，而非一高一低交替進(jìn)行的幀數(shù)流。
雖然“Frame metering（幀測量）”看起來相當(dāng)不錯，但也包含了一些折中。為了平衡波動，NVIDIA大大提升了介于幀渲染完成到顯示輸出的延遲時間（lag）。雖然這回造成一部分的性能損失嗎，不過在大部分情況下，當(dāng)我們以毫秒為單位進(jìn)行討論的時候，這些延遲并不容易察覺。所以，在沒有一個相對完美的解決方案的前提下，這種方法還是能夠起到減輕波動的效果的。
當(dāng)然，這種技術(shù)同樣存在不少問題，而關(guān)鍵在于它非常依賴于游戲引擎。如果游戲引擎處理每幀的時間都完全一樣，“Frame metering（幀測量）”就能起到非常不錯的效果；反之，就只能斷斷續(xù)續(xù)地解決暫時問題，甚至可能會起到反作用。舉個例子來說，比如我們的攝像機(jī)以奇數(shù)順序12-34-56-78進(jìn)行幀數(shù)抓取，而投影儀卻已1-2-3-4-5-6-7-8的方式進(jìn)行播放，那看起來會是什么效果？
這些問題我們也咨詢了Petersen，他也非常坦白的表明了” Frame metering”在面對不同游戲引擎的時候?qū)⒚媾R挑戰(zhàn)。但當(dāng)問及具體哪些游戲引擎能夠和” Frame metering”完美搭配，他也未能給出詳細(xì)的例子。在承認(rèn)還有很多工作要做的同時，Petersent還說道：”如果我們能將所有幀都能統(tǒng)一（不再有波動），那絕大多數(shù)游戲就非常完美了”。言外之意，就像Nalasco說的那樣，這在業(yè)界依然是一個值得研究的課題。
關(guān)注我們
