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

雷鋒網按：本文由雷鋒網轉載自知乎專欄（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部分所有的按鍵->動作的幀數記錄如下：

1. #629 -> #679 = 50 frames

2. #1202 -> #1252 = 50 frames

3. #1748 -> #1796 = 48 frames

4. #2286 -> #2332 = 46 frames

5. #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

《刺客信條—奧德賽》Steam版

《奧德賽》的輸入延遲測試

• 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。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！