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