0
| 本文作者： 劉芳平 | 2019-04-02 18:25 |
雷鋒網(wǎng)按：本文由雷鋒網(wǎng)轉(zhuǎn)載自知乎專欄（1）（2），已獲作者授權(quán)。
先上結(jié)論：粗略估算Google Stadia的Controller to Display Latency大概在200ms左右。對比本地游戲，Google Stadia引入的額外延遲在70ms左右。
2019-3-22更新：更精確的測算Google Stadia的Controller to Display Latency在200ms左右，實驗誤差在208.3±16.7ms內(nèi)。
14年在做《天諭》引擎的時候，我們遇到了FPS不錯，但是“手感”很差的問題。主觀測試后，感覺很有可能是輸入到畫面的延遲（Controller to Display Latency）太高了。但是，怎么來更加客觀的分析這個延遲呢？
記得那是一個周末，在公司絞盡腦汁，總不能去買一個高速攝像機(jī)來分析吧？當(dāng)時確實還taobao搜索了一下，印象中都沒數(shù)清楚后面的0……回想起來可能要幾十萬吧 〒▽〒，鳥叔肯定不會批的 ╮(╯﹏╰）╭
正絕望中，突然靈機(jī)一動，蘋果不是剛發(fā)布了slow motion功能嗎？立馬在周末人煙稀少的辦公區(qū)里一個一個的找手機(jī)看，居然真的被我找到了一臺支持slow motion的iphone！
打開slow motion，錄制了一個最簡單的測試：手動控制鼠標(biāo)左右往復(fù)移動鏡頭，同時拍攝手和顯示器屏幕，希望能錄下來鼠標(biāo)和屏幕移動之間的不同步。最終結(jié)果比我想象的好的多，不僅清楚的數(shù)出了鏡頭和鼠標(biāo)之間的延遲幀數(shù)，還人生第一次看到了顯示器的刷新，真的是從上往下一行一行（實際看到的是n行一起更新）的刷新的！
數(shù)出了鏡頭和鼠標(biāo)之間的延遲幀數(shù)n，又已知拍攝的slow motion的FPS，1000*n/FPS就是延遲的毫秒數(shù)。找到了量化延遲的方法后，通過各種hack把driver的三重緩沖干掉（當(dāng)時還是DX9時代），又修了幾個jitter的bug后，迅速就解決了問題。
當(dāng)時的視頻早已不知所蹤了，今天，我來用同樣的方法測試一下Google Stadia的延遲到底有多少！
剛好在會場遇到了浙大CAD的圖形學(xué)大牛王銳教授，厚著臉皮讓他給我錄了一段1分鐘的240 FPS slow motionヾ(?°?°?)??
回到酒店后，打開PotPlayer，繼續(xù)開始一幀一幀數(shù)數(shù)~(????)? ，其中一次移動的數(shù)據(jù)如下：
手柄從最左開始向右搖桿的第一幀：#150
手柄搖到最右停住的第一幀：#179
畫面開始向右移動的第一幀：#219
手柄和鼠標(biāo)有一個很大的區(qū)別，搖桿的行程讓我沒法精確的確定左右搖的精確中點，那就估計一下中點為#165幀，把min/median/max都算一下吧
min：219 - 179 = 40 frames = 167ms
median：219 - 165 = 54 frames = 225ms
max：219 - 150 = 69 frames = 288ms
所以，可以粗略估算Google Stadia的Controller to Display Latency大概在200ms左右。這個值還是相當(dāng)高的，射擊游戲肯定是不行的o(╥﹏╥)o，很是失望~
感謝戰(zhàn)神大牛 @gougou槐宏文建議換一種更加精確的方法來測試，減小誤差：
謝謝這個文章，但是我有一個小疑問，還需要其他方面的測試來測量，因為輸入到攝像機(jī)的轉(zhuǎn)動，很有可能出現(xiàn)gameplay code的damping，也就是說輸入檢測到了但是一開始故意移動攝像機(jī)不這么靈敏，這種就是防止攝像機(jī)太靈敏，更值得測試的是play control，因為這是玩家操作的，基本不想出現(xiàn)延遲，比如推左搖桿玩家什么時候動，按x鍵玩家什么時候攻擊，如果這些延遲還是200ms，那基本沒辦法玩
相機(jī)平滑+搖桿deadzone等確實有太多的不確定因素了，需要排除掉。按照上述思路重新測試了一下。
視頻：
感謝雷火技術(shù)中心總監(jiān)小軍路過幫我錄像——每次都拉大牛來錄，提升逼格 (=′ω｀=)
視頻中slow motion部分所有的按鍵->動作的幀數(shù)記錄如下：
#629 -> #679 = 50 frames
#1202 -> #1252 = 50 frames
#1748 -> #1796 = 48 frames
#2286 -> #2332 = 46 frames
#2838 -> #2892 = 54 frames
幀數(shù)區(qū)間是（50±4）幀，平均延遲是49.6幀。在240fps的slow motion下就是206.7ms，誤差區(qū)間在208.3±16.7ms之內(nèi)。
這個結(jié)果與之前粗略估算的值誤差不大，原有的結(jié)論仍有有效：
更精確的測算Google Stadia的Controller to Display Latency在200ms左右，實驗誤差在208.3±16.7ms內(nèi)。
為啥第一段起名叫做A Black Box Method？因為，今天有一個很棒的講座：
他里面對延遲的分析非常非常的細(xì)致，回答了很多之前我一知半解的模糊概念。我上面用的這種傻大粗的方法，在他的演講中，就叫做：Black Box Method。
黑盒
Black Box方法完全不管內(nèi)部細(xì)節(jié)，直接測量，可以用來分析延遲。但是會導(dǎo)致估計不夠細(xì)。估計不夠細(xì)就無法精確預(yù)測Throttle從而降低渲染W(wǎng)orkload和VSync上的延遲。
這個Talk里面我個人覺得很有意思的幾個點：
土豪工作室自己搞了一套閉環(huán)檢測輸入延遲的硬件：
把VSync解釋的非常非常清楚
顯示器的掃描和刷新
關(guān)閉VSync導(dǎo)致畫面撕裂
超時+同步點不對=幀率減半
好的同步點只會稍微降低幀率
預(yù)測+自適應(yīng)屏幕分辨率=不會miss任何一個VSync
把延遲的每一步都講的非常細(xì)致，可操作性很強(qiáng)
延遲的定義
提出了人為插入Throttle反而能大幅降低延遲的概念，反直覺
人為插入Throttle反而能大幅降低延遲
提出了具體的估算Throttle的預(yù)測算法和Best Practice
Throttle預(yù)估算法
反饋機(jī)制
此Talk講的非常細(xì)致，等GDC Vault更新視頻后，在這里補(bǔ)充鏈接。#TODO
這個Talk光看PPT很難理解，基本沒有文字——好的PPT就應(yīng)該這樣(〃'▽'〃)，需要結(jié)合視頻食用為佳。心急的同學(xué)可以湊活看我的現(xiàn)場速記草稿，基本記錄了每一頁PPT，侵刪：
kilia/gdc2019 中的 ControllerToDisplayLatency現(xiàn)場速記筆記.pdf
由于當(dāng)時在GDC會場，沒有條件測試單機(jī)/主機(jī)情況下的延遲。評論中大家說的都很中肯，本地游戲的延遲也必須測試才算完整。
張鶴翔：不同游戲的內(nèi)部延遲不可忽視（即文中所說的游戲收到操控信號到輸出一幀畫面的時間），條件允許的話需要用不同類型、不同廠商的游戲進(jìn)行測試才能拿到全面的結(jié)果。
對于奧德賽這類動作游戲，本身不要求特別低的延遲，用xbox來測試可能延遲也在100ms以上。
bird cai：你要比較本地連接，單機(jī)連接時的延時，再來談其他。用iPhone Slow Motion也是我們用的方法。我自己測量的結(jié)果，在LAN上的結(jié)果，網(wǎng)絡(luò)和串流編碼解碼的延時可以做到10ms以下。
霞先生：美國DF社好像最新的谷歌云游戲測試，說他們用了高速攝像機(jī)，結(jié)論是谷歌云延遲是166ms，微軟x1x延遲是145ms，感覺差距不大啊
今天，抽空用同事的Steam賬號測試了PC版《刺客信條—奧德賽》的延遲情況，感謝最帥氣的楠哥提供測試賬號。
CPU i9-7900X
GPU GTX 1080
32G DDR4
鎖定60fps / VSync ON
《奧德賽》的輸入延遲測試
31幀，129.17ms
31幀，129.17ms
33幀，137.50ms
32幀，133.33ms
35幀，145.83ms
35幀，145.83ms
35幀，145.83ms
34幀，141.67ms
33幀，137.50ms
平均33.2幀，在240fps下就是138.4ms。實驗測得的數(shù)據(jù)區(qū)間是33±2幀，即137.5±8.3ms。
前文精確的測算Google Stadia的Controller to Display Latency在200ms左右，實驗誤差在208.3±16.7ms內(nèi)。
可見，《奧德賽》本身的Controller to Display Latency就是很高的。簡單兩者對比下Google Stadia引入的額外延遲在70ms左右。
由于感覺《奧德賽》的延遲較高，又拿了最近在玩的FPS游戲，同為UBI出品的《Far Cry 5》進(jìn)行了對比測試。
17幀，70.83ms
16幀，66.67ms
16幀，66.67ms
15幀，62.50ms
17幀，70.83ms
果然FPS游戲，延遲的優(yōu)化就要好得多。實驗測得平均16.2幀，在240fps下就是67.5ms。實驗測得的數(shù)據(jù)區(qū)間是16±1幀，即66.7±4.2ms。
雷峰網(wǎng)版權(quán)文章，未經(jīng)授權(quán)禁止轉(zhuǎn)載。詳情見轉(zhuǎn)載須知。
