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