游戏跑分新视角：细看一秒内帧数变化

    事实上，文章一开始并没有打算深入探讨多卡并联系统的Micro-stuttering（帧延时波动，实在找不到一个合适的词翻译…）。新测试方法帮助我们发现许多有意思的问题，也说明我们的方向没有错。但是，这个Micro-stuttering却使得我们的任务复杂了不少。

这张图可以比较直观的反映Micro-stuttering（X轴以ns为单位，Y轴以帧数为单位），多卡系统单位时间内帧延时会上下波动。

    很自然，我们已经联系了主要的显卡芯片厂商，看看他们对这个问题的解释。但是令我们意外的是，不管是AMD还是NVIDIA都直接而且坦率地承认多卡系统的Micro-stuttering确实存在，而且是一个亟待解决的问题，他们也已研究多时。但有趣是，对于以上的多核心产品（比如HD 6990、GTX 590）或者多卡解决方案（SLI、CrossFire），AMD和NVIDIA都没有明确告知消费者这个问题的存在。相当讽刺，不是吗？

    AMD的David Nalasco在评估多显卡派遣帧任务的时候就发现了Micro-stuttering，他注意到帧数延时的波动随着游戏的反复进行，因为帧与帧之间的相对时间是可变的。而且他声称这个问题并没有普遍性。

    根据有限但还算公平的测试，我们对于这个说法基本认同。首先，尽管帧延时波动随着时间一直存在，但它更倾向于既定的而且反复进行的测试场景。其次，波动似乎在有相对性能有限的平台里程度更深。例如，我们在相同设置下测试相同的游戏，中端的HD 6870 CF所体现出来的帧间波动就要比更高端的HD 6970 CF更加明显。同理，GTX 560 SLI和GTX 580 SLI的情况也是如此。如果这一状况是多卡系统的一大特性，那显然是负面的。第三，在我们的测试数据中，CrossFire在抑制帧延时波动方面明显没有SLI好。虽然我们还不能说以上三点具有普适性，但知道从我们的测试中得到的结果就是如此。

    Nalasco告诉我们一定程度上抑制帧延时波动有许多方法。你或许已经猜到了，那就是“垂直同步”。“垂直同步”启用之后，可以阻止当前帧渲染完毕后GPU跳转到不同的资源缓冲区（已完成新的帧渲染），而帧缓冲区跳转被推迟到下一次屏幕刷新。不过Nalasco也指出开启“垂直同步”也只能在“某些时候”有效果，换句话说也就是不一定完全有效。所以，我们认为关于“垂直同步”对于Micro-stuttering的精确影响还很难预测。

    Ps.如果选择“等待垂直同步信号”（也就是“打开垂直同步”），显卡绘制图形前会等待信号；性能强劲的显卡则会提前完成绘制，并在下个信号到达之前等待。此时，游戏的fps值会受显示器刷新率的制约。对于高端显卡而言，这限制了其性能的发挥。而如果选择“不等待垂直同步信号”（也就是“关闭垂直同步”），那么显卡绘制完一屏画面，不等待垂直同步信号，就开始下一屏画面的绘制，自然可以完全发挥显卡的实力。但是，不要忘记，正是因为垂直同步的存在，才能使得游戏进程和显示器刷新率同步，使得画面平滑，使得画面稳定。取消了垂直同步信号，固然可以换来更快的速度，但是在图像的连续性上，性能势必打折扣。这也正是很多朋友抱怨关闭垂直后发现画面不连续的理论原因。

    有意思的是Nalasco提到的另一中可能：一种“更加聪明”的“垂直同步”，可以通过人的视觉感知来控制帧的跳转。听起来很不错，这种方法也有潜在的可行性。但Nalasco只是说了一些未来的构想，对于现实技术只字未提，他也承认AMD到现在也没有一个十全十美的解决方案。

    另外，他还透露，未来AMD会在这方面投入更多精力，因为将来多卡系统肯定和LInao APU有很大关联，而且是不对称的结构，相比目前的多卡系统产生Micro-stuttering的几率更大。

    而NVIDIA的Tom Petersen也进行了如下的图文阐述，帮助我们更好的理解。

上面的示意图表明了帧产生的流程，从游戏引擎到显示输出，非常有助于上下文的讨论。

    其中，游戏引擎包含了一系列的内部变量，物理模拟、图形处理以及用户交互等等。当一个帧开始渲染，图形引擎首先将其交给DirectX API。据Petersen的说法，Fraps就是在这个时候开始时间信息记录。接下来，DirectX将调用高级API和Shader程序将其转换成更基地的指令，然后交由显卡驱动处理。进而，显卡驱动将这些DirectX低级指令转化成机器语言交付给GPU进行渲染，最终输出到显示设备。

    为了更好的阐述关键问题，Petersen定义了许多变量。比如，”Stutter”就表示游戏时间（T_game）和输出显示时间（T_display）之间差的绝对值、”Lag”表示”T_game”和”T_dispaly”之间的耗时、”Slide show”表示每帧渲染时间的总共耗时。按照Petersen的观点，在这三个变量中，玩家在游戏中感知最为明显的就是”Stutter”。

    在Petersen透露的诸多细节中，最让人印象深刻的莫过于“NVIDIA在旗下的GPU中安置了许多硬件单元用来固定多卡系统的帧延时波动”。主要原理是基于一种名为“Frame metering（帧测量）”的技术，可以在帧间进行动态追踪。一些“表现较快”的帧会被适当延迟，换句话说，就是GPU不会直接跳转到新的缓冲区，从而保证渲染后的画面能够均匀地进行显示输出。而这些延迟会根据帧率的快慢在特性的时间进行调整。据称，这种“Frame metering（帧测量）”技术至少在NVIDIA G80时代就已经开始运用了。

    现在，注意一下其中的含义。因为这种延迟测量是大概是在T_render和T_display之间进行的，所以Fraps根本不会进行记录。这也就意味着我们之前的SLI测试数据没有将这一过程展现给读者。呈现在他们面前的是表面看起来波动不大，而非一高一低交替进行的帧数流。

    虽然“Frame metering（帧测量）”看起来相当不错，但也包含了一些折中。为了平衡波动，NVIDIA大大提升了介于帧渲染完成到显示输出的延迟时间（lag）。虽然这回造成一部分的性能损失吗，不过在大部分情况下，当我们以毫秒为单位进行讨论的时候，这些延迟并不容易察觉。所以，在没有一个相对完美的解决方案的前提下，这种方法还是能够起到减轻波动的效果的。

    当然，这种技术同样存在不少问题，而关键在于它非常依赖于游戏引擎。如果游戏引擎处理每帧的时间都完全一样，“Frame metering（帧测量）”就能起到非常不错的效果；反之，就只能断断续续地解决暂时问题，甚至可能会起到反作用。举个例子来说，比如我们的摄像机以奇数顺序12-34-56-78进行帧数抓取，而投影仪却已1-2-3-4-5-6-7-8的方式进行播放，那看起来会是什么效果？

    这些问题我们也咨询了Petersen，他也非常坦白的表明了” Frame metering”在面对不同游戏引擎的时候将面临挑战。但当问及具体哪些游戏引擎能够和” Frame metering”完美搭配，他也未能给出详细的例子。在承认还有很多工作要做的同时，Petersent还说道：”如果我们能将所有帧都能统一（不再有波动），那绝大多数游戏就非常完美了”。言外之意，就像Nalasco说的那样，这在业界依然是一个值得研究的课题。