全文浏览
◆ Fraps记录延迟为什么不靠谱及总结
Fraps记录帧速解读
Fraps软件的名头和作用不用多费笔墨了，这个软件是评测编辑最常用的工具之一，很多没有内建benchmark工具的程序及游戏都是靠Fraps来手动测量的，其截图、录像功能也非常实用。
虽然它很实用，但是AMD还是认为这个软件有问题，它记录的帧时间并不一定准确。
还是要先了解一下Fraps的工作原理，它通过dll文件注入到应用程序中，然后开始拦截D3D
Present命令，在这里Fraps可以延迟输出指令以便插入自己的绘制指令。当用户按键激活帧数及帧时间测试时，Fraps就会计算present指令，当它每次察觉到发出一个present指令之后就会记录下来，认为生成了一帧新图像，然后再允许present指令通过。
这套流程对大部分应用都很管用，这也是Fraps如此受欢迎的原因之一。用Fraps软件测量游戏的平均帧还好，但是用它来测量游戏的帧间隔（也就是我们说的延迟、卡顿的原因）就不靠谱了。
Fraps过早地开始注入渲染过程，它比GPU优先、比驱动程序还要优先，甚至比D3D还以及context
queue还要优先，因此Fraps可以告诉你进入渲染过程之前发生了什么，但是它无法告诉你渲染完成之后发生了什么，而真正决定游戏卡顿与否的关键就在后一个阶段上。
因此用Fraps来判断游戏卡顿与否是有问题的。从前面的渲染过程介绍中我们知道，只有当context
queue准备好接受指令之后程序才会开始渲染新的一帧图像，而Fraps记录的只是渲染开始的部分，并非整个渲染过程，因此它只能告诉你它看到了什么，而不能告诉你渲染末期的帧间隔。
AMD对Fraps担忧的问题有两点，首先根据我们前面的定义，Fraps实际上是不能真正测量游戏的延迟的，context
queue会阻挡任何试图测量真正的帧延迟的努力，两个present指令之间的时间并不等于渲染完成一帧所需的时间，特别是在下一个present指令因为任何原因被延迟的情况下，二者更没有关系了。
AMD的第二个顾虑就是Fraps越来越多地被用作帧延迟的测量工具，但是因为它过早介入了渲染过程，实际上它看到的延迟并非用户感受到的，如果Fraps认为AMD显卡有更多卡顿但是用户并没有感觉到这个问题，这是AMD显卡的错吗？
需要指出的是，我们的最终目标还是尽可能将卡顿变得更小更少，而AMD也在为这个目标而努力，但是让AMD担心的是Fraps测量的结果使得他们显卡的卡顿现象看起来更多了。
AMD对fraps软件的看点与评价
原文后面还有很多内容，包括对另一个测量工具GPU
View的分析，还有单卡下的卡顿及多卡系统下的卡顿问题的探讨，不过我们的目的现在已经达到了，来看看最后的总结吧。
总结：
Anandtech这篇文章很强大，虽然读起来会比较费力，但是多多少少让我们了解了显卡的渲染过程以及什么才是真正的延迟，对Fraps原理的解析也有助于我们理解为什么AMD认为Fraps软件测量的“延迟”并不能成为真正的延迟，这也是Anandtech网站没有采用帧延迟的方式来衡量显卡性能的原因之一。
原文的总结部分也很长，长话短说就是AMD以及NVIDIA对滥用Fraps帧时间测试的评测方法也是有一定顾虑的，不过AMD的态度还不错，他们也承认了测试反应出的问题，并且在驱动中不断优化这个问题，毕竟就算Fraps测量的不准，记录出来的结果中N卡的卡顿还是要比A卡平均好一些。
Anandtech说他们也在考虑新的测试方法，未来几周就会露面。这对我们来说也是一个提醒，超能习惯用的测试成绩表格主要是基于平均帧数，平均帧或许很粗略，但是从小编使用几年的感觉来说它还是有说服力的，因为帧时间以及最低帧给我的感觉是太随机了，同一个测试重复几次得到的结果都不一样，反倒是平均值更有可重复可验证性。
当然，我们也不会就此停步不前，也会尝试用更多的方式来展现所测产品的真实性能，这一点还会继续改进。
最后，Anandtech也强调了他们这篇文章不是否定Fraps的价值，它依然是一个非常好用、实用的测量工具。