谷歌云游戲延遲分析：Stadia引入的額外延遲約70ms

本文作者：劉芳平

2019-04-02 18:25

導(dǎo)語(yǔ)：粗略估算Google Stadia的Controller to Display Latency大概在200ms左右。

雷鋒網(wǎng)按：本文由雷鋒網(wǎng)轉(zhuǎn)載自知乎專欄（1）（2），已獲作者授權(quán)。

先上結(jié)論：粗略估算Google Stadia的Controller to Display Latency大概在200ms左右。對(duì)比本地游戲，Google Stadia引入的額外延遲在70ms左右。

2019-3-22更新：更精確的測(cè)算Google Stadia的Controller to Display Latency在200ms左右，實(shí)驗(yàn)誤差在208.3±16.7ms內(nèi)。

A Black Box Method

14年在做《天諭》引擎的時(shí)候，我們遇到了FPS不錯(cuò)，但是“手感”很差的問(wèn)題。主觀測(cè)試后，感覺(jué)很有可能是輸入到畫(huà)面的延遲（Controller to Display Latency）太高了。但是，怎么來(lái)更加客觀的分析這個(gè)延遲呢？

記得那是一個(gè)周末，在公司絞盡腦汁，總不能去買(mǎi)一個(gè)高速攝像機(jī)來(lái)分析吧？當(dāng)時(shí)確實(shí)還taobao搜索了一下，印象中都沒(méi)數(shù)清楚后面的0……回想起來(lái)可能要幾十萬(wàn)吧〒▽〒，鳥(niǎo)叔肯定不會(huì)批的 ╮(╯﹏╰）╭

正絕望中，突然靈機(jī)一動(dòng)，蘋(píng)果不是剛發(fā)布了slow motion功能嗎？立馬在周末人煙稀少的辦公區(qū)里一個(gè)一個(gè)的找手機(jī)看，居然真的被我找到了一臺(tái)支持slow motion的iphone！

打開(kāi)slow motion，錄制了一個(gè)最簡(jiǎn)單的測(cè)試：手動(dòng)控制鼠標(biāo)左右往復(fù)移動(dòng)鏡頭，同時(shí)拍攝手和顯示器屏幕，希望能錄下來(lái)鼠標(biāo)和屏幕移動(dòng)之間的不同步。最終結(jié)果比我想象的好的多，不僅清楚的數(shù)出了鏡頭和鼠標(biāo)之間的延遲幀數(shù)，還人生第一次看到了顯示器的刷新，真的是從上往下一行一行（實(shí)際看到的是n行一起更新）的刷新的！

數(shù)出了鏡頭和鼠標(biāo)之間的延遲幀數(shù)n，又已知拍攝的slow motion的FPS，1000*n/FPS就是延遲的毫秒數(shù)。找到了量化延遲的方法后，通過(guò)各種hack把driver的三重緩沖干掉（當(dāng)時(shí)還是DX9時(shí)代），又修了幾個(gè)jitter的bug后，迅速就解決了問(wèn)題。

當(dāng)時(shí)的視頻早已不知所蹤了，今天，我來(lái)用同樣的方法測(cè)試一下Google Stadia的延遲到底有多少！

剛好在會(huì)場(chǎng)遇到了浙大CAD的圖形學(xué)大牛王銳教授，厚著臉皮讓他給我錄了一段1分鐘的240 FPS slow motionヾ(?°?°?)??

回到酒店后，打開(kāi)PotPlayer，繼續(xù)開(kāi)始一幀一幀數(shù)數(shù)~(????)? ，其中一次移動(dòng)的數(shù)據(jù)如下：

手柄從最左開(kāi)始向右搖桿的第一幀：#150
手柄搖到最右停住的第一幀：#179
畫(huà)面開(kāi)始向右移動(dòng)的第一幀：#219

手柄和鼠標(biāo)有一個(gè)很大的區(qū)別，搖桿的行程讓我沒(méi)法精確的確定左右搖的精確中點(diǎn)，那就估計(jì)一下中點(diǎn)為#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左右。這個(gè)值還是相當(dāng)高的，射擊游戲肯定是不行的o(╥﹏╥)o，很是失望~

更新測(cè)試方案，重測(cè)一遍

感謝戰(zhàn)神大牛 @gougou槐宏文建議換一種更加精確的方法來(lái)測(cè)試，減小誤差：

謝謝這個(gè)文章，但是我有一個(gè)小疑問(wèn)，還需要其他方面的測(cè)試來(lái)測(cè)量，因?yàn)檩斎氲綌z像機(jī)的轉(zhuǎn)動(dòng)，很有可能出現(xiàn)gameplay code的damping，也就是說(shuō)輸入檢測(cè)到了但是一開(kāi)始故意移動(dòng)攝像機(jī)不這么靈敏，這種就是防止攝像機(jī)太靈敏，更值得測(cè)試的是play control，因?yàn)檫@是玩家操作的，基本不想出現(xiàn)延遲，比如推左搖桿玩家什么時(shí)候動(dòng)，按x鍵玩家什么時(shí)候攻擊，如果這些延遲還是200ms，那基本沒(méi)辦法玩

相機(jī)平滑+搖桿deadzone等確實(shí)有太多的不確定因素了，需要排除掉。按照上述思路重新測(cè)試了一下。

視頻：

感謝雷火技術(shù)中心總監(jiān)小軍路過(guò)幫我錄像——每次都拉大牛來(lái)錄，提升逼格 (=′ω｀=)

視頻中slow motion部分所有的按鍵->動(dòng)作的幀數(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)。

這個(gè)結(jié)果與之前粗略估算的值誤差不大，原有的結(jié)論仍有有效：

更精確的測(cè)算Google Stadia的Controller to Display Latency在200ms左右，實(shí)驗(yàn)誤差在208.3±16.7ms內(nèi)。

《Controller to Display Latency》

為啥第一段起名叫做A Black Box Method？因?yàn)椋裉煊幸粋€(gè)很棒的講座：

谷歌云游戲延遲分析：Stadia引入的額外延遲約70ms

他里面對(duì)延遲的分析非常非常的細(xì)致，回答了很多之前我一知半解的模糊概念。我上面用的這種傻大粗的方法，在他的演講中，就叫做：Black Box Method。

谷歌云游戲延遲分析：Stadia引入的額外延遲約70ms

黑盒

Black Box方法完全不管內(nèi)部細(xì)節(jié)，直接測(cè)量，可以用來(lái)分析延遲。但是會(huì)導(dǎo)致估計(jì)不夠細(xì)。估計(jì)不夠細(xì)就無(wú)法精確預(yù)測(cè)Throttle從而降低渲染W(wǎng)orkload和VSync上的延遲。

這個(gè)Talk里面我個(gè)人覺(jué)得很有意思的幾個(gè)點(diǎn)：