#GDC19 谷歌雲遊戲延遲分析—《Controller to Display Latency》
先上結論：粗略估算Google Stadia的Controller to Display Latency大概在200ms左右。
2019-3-22更新：更精確的測算Google Stadia的Controller to Display Latency在200ms左右，實驗誤差在208.3±16.7ms內。
A Black Box Method
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內。
《Controller to Display Latency》
為啥第一段起名叫做A Black Box Method？因為，今天有一個很棒的講座：
他裡面對延遲的分析非常非常的細緻，回答了很多之前我一知半解的模糊概念。我上面用的這種傻大粗的方法，在他的演講中，就叫做：Black Box Method。
Black Box方法完全不管內部細節，直接測量，可以用來分析延遲。但是會導致估計不夠細。估計不夠細就無法精確預測Throttle從而降低渲染Workload和VSync上的延遲。
這個Talk裡面我個人覺得很有意思的幾個點：
- 土豪工作室自己搞了一套閉環檢測輸入延遲的硬體：
- 把VSync解釋的非常非常清楚
- 把延遲的每一步都講的非常細緻，可操作性很強
- 提出了人為插入Throttle反而能大幅降低延遲的概念，反直覺
- 提出了具體的估算Throttle的預測演算法和Best Practice
此Talk講的非常細緻，等GDC Vault更新視頻後，在這裡補充鏈接。#TODO
這個Talk光看PPT很難理解，基本沒有文字——好的PPT就應該這樣(〃▽〃)，需要結合視頻食用為佳。心急的同學可以湊活看我的現場速記草稿，基本記錄了每一頁PPT，侵刪：
kilia/gdc2019 中的 ControllerToDisplayLatency現場速記筆記.pdf
推薦閱讀：
