谷歌云游戏延迟分析：Stadia引入的额外延迟约70ms【开运体育官方网站】

　本文摘要：slowmotion的iphone！关闭slowmotion，手动控制鼠标左右移动镜头，同时拍摄手和显示屏，录制鼠标和屏幕移动之间的不实时性。最后的结果比我想象的要好得多，不仅是镜头和鼠标之间的延迟帧数，人生第一次看到显示器的创作，知道是指上下一行(实际看到n行一起改版)的创作数镜头和鼠标之间的延迟帧数n，未知摄影的slowmotion的FPS，1000*n/FPS是延迟的毫秒数。

slowmotion的iphone！关闭slowmotion，手动控制鼠标左右移动镜头，同时拍摄手和显示屏，录制鼠标和屏幕移动之间的不实时性。最后的结果比我想象的要好得多，不仅是镜头和鼠标之间的延迟帧数，人生第一次看到显示器的创作，知道是指上下一行(实际看到n行一起改版)的创作数镜头和鼠标之间的延迟帧数n，未知摄影的slowmotion的FPS，1000*n/FPS是延迟的毫秒数。找到分析延迟的方法后，用各种hack杀死driver的三重缓冲器(当时是DX9时代)，建造了几个jitter的错误后，立即解决了问题。

当时的录像已经下落不明，今天用一定程度的方法测试谷歌Stadia的延迟正好在会场遇到了浙江大学CAD的图形学大牛王锐教授，厚厚的脸皮让他记录了1分钟的240框架。FPSslowmotion，回到酒店后，关闭了PotPlayer，然后开始了框架数量~(授权评估)。

其中一次移动的数据如下:手柄从最左到右手柄的第一帧:#150手柄摇到最右下落的第一帧:#179画面开始向右移动的第一帧:#219手柄和鼠标有相当大的区别。手柄从最左到向右手柄的第一帧:#150手柄的第一帧:#150手柄的手柄的第一帧:#80手柄的第一帧:最右下落的第一帧:#17999屏幕的第一帧:2199390:20手柄的第一框架的第一框架的第一框架的第一框架的第一框架的第一框架的确认:29999393920:1939393920:20中的确认这个值非常低，射击游戏同意是勇敢的o(555)o，很沮丧~改版测试方案，再次感谢战神大牛郎@gougou槐宏文，建议改变更准确的方法进行测试，增加误差:谢谢这篇文章，但是我有一个小疑问，需要其他方面的测试来测量。因为输出到照相机的旋转，所以gameplaytcodedamping的damping很可能经常出现，也就是说输出检测出来了，但是故意移动照相机并不敏感。

因为避免照相机过于敏感，所以很多游戏者在反击的基本上，如果没有什么会出现左手机的话，就不会出现反击。根据上述想法进行了新的测试。视频:感谢雷火技术中心总监小军路经上司的我的视频每次都扩大牛来记录，提高强制性格(ω`)=视频中slowmotio部分按键动作的帧数记录如下:#629-679级=授权50frames#1202-开始-#1252=50级frames#1748-#17486=48frames#2286-#23232=46frames#48-28-2828-2828-2828-2468-546)(496)平均值)延长。240fpsslowmotion下为206.7ms，误差区间在208.3±16.7ms以内。

该结果与以前粗略估计的值误差不大，原结论仍有效:更准确地测量谷歌Stadia的Controller，谷歌Latency在200ms左右，实验误差在208.3±16.7ms以内。Controllerto。Display。

Latency为什么第一段被称为ABlackBox？因为今天有一个有趣的讲座:他对延迟的分析非常细致，问了很多以前我知道的模糊概念。我用的这种失败的方法，在他的演说中，被称为BlackBox。

黑盒BlackBox的方法几乎与内部细节无关，需要测量，可以用来分析延迟。但是，估计不会太粗。如果估计太粗，Throttle将无法准确预测，从而减少图形Workload和VSync的延迟。

在这个Talk中，我个人认为有趣的一些要点:土豪工作室自己制作了闭环检测输出延迟的硬件:VSync说明的非常正确的显示器的瞄准和重新打开VSync，画面断裂的超时实时点错误=帧率下降的实时点，为了减少帧率预测而自适应画面的分辨率=miss的VSync将延迟的所有步骤都说得非常细致，可操作性强的延迟的定义明确提出了人为放入Throttle反而大减少延迟的概念#TODO这个Talk光看PPT很难解读，基本上没有文字的PPT应该是这样(··················································································································································································································································································································································································································································································································································································假装生病的同学可以看到我现场的速记草稿，基本上记录了所有页面的PPT，删除:kilia/gdc2019中的ControllerTodisplayLatency现场的速记笔记。pdf当地游戏的比较分析，由于当时在GDC会场，所以没有条件测试单独/主机的延迟。

评论中大家说的话很中肯，当地游戏的延迟也需要测试。张鹤翔:不同游戏的内部延迟不容忽视(也就是说，从文章中提到的游戏收到操作信号到输入画面的时间)，如果条件允许的话，必须用不同类型、不同制造商的游戏展开测试来获得全面的结果。对于像奥德赛这样的动作游戏，本身不会拒绝特别低的延迟，用xbox测试可能会延迟100ms以上。birdcai:比较当地的连接，单体连接时的延迟，忘记说别的话。

使用iPhone，SlowMotion也是我们使用的方法。我自己测量的结果是，在局域网上的结果是，网络和串行编码解码的延迟不超过10ms。霞先生:美国DF公司最近的谷歌云游戏测试说他们使用了高速照相机。

结论是谷歌云延迟为166ms，微软公司x1x延迟为145ms，感觉差距不大。今天，继续使用同事的Steam账户测试PC版《刺客信条-奥德赛》的延迟情况，感谢最帅的楠哥获得测试账户。

测试环境CPUi9-7900XGPUGTX108032GDDR4瞄准60fps/VSynchON《刺客信条-奥德赛》Steam版《奥德赛》输出延迟测试31帧、129.17ms31帧、129.17ms33帧、137.50ms32帧、133.33ms35帧、145.83ms35帧、145.83ms35帧、145.833ms34帧、141.67ms334帧、1337.5ms平均值33.235帧、24ms35帧、14帧、14.8ms35帧。实验测量的数据区间为33±2帧，即137.5±8.3ms。前文正确测量谷歌±Stadia的Controllerto，DisplayLatency在200ms左右，实验误差在208.316.7ms以内。

奥德赛本身的Controller，DisplayLatency很高。与谷歌Stadia引进的额外延迟在70ms左右，非常简单。因为感觉奥德赛的延迟很高，所以最近玩游戏的FPS游戏和UBI制作的FarCry5进行了比较测试。

《Fary5》Steam版17帧，70.83ms16帧，66.67ms16帧，66.67ms15帧，62.50ms17帧，70.83ms果然是FPS游戏，延后优化要好很多。实验测量平均值为16.2帧，240fps下为67.5ms。

实验测量的数据区间为16±1帧，即66.7±4.2ms。版权文章允许禁止发布。下一篇文章发表了注意事项。

本文关键词：谷歌,云,游戏,延迟,分析,Stadia,引入,的,开运体育平台app,额外

本文来源：开运体育官方网站-www.sqxtgxg.com