本帖最后由 仙賢戀軒 于 2014-11-24 23:33 编辑
在很久很久以前，我写了一个帖子讨论FPS数值和游戏流畅程度的关系（传送门在此），简单来说用FPS来判断是否流畅是不科学的，相比之下看每帧的生成时间长短更科学。在帖子发布的那个时候，Frametime这个概念还属于新概念，并没有被广泛大众普遍认识和应用到，而现在在大多数的测试中就显得很常见了。当然，随着随见的推移，理论和方法也是在不断的发展的，所以今天想在这个话题上继续聊聊，关于延迟、关于卡顿、关于撕裂、也关于同步。
在早些时候，NV发布了G-sync硬件方案，宣称通过这样的方案可以杜绝卡顿，杜绝撕裂，最大程度减少延迟；而在几乎相同的时候，AMD也发布了FreeSync方案，宣称仅通过DisplayPort接口不需其他任何额外硬件就可以达到类似效果。毫无意外地，双方又一次就同一话题展开了一番口水仗，甚至上升到了企业愿景和意识形态的高度。说实话，硬件圈里恐怕没有哪些竞争可以比得上AMD和Nvidia之间的战斗，除了两家企业本身的毫不退让以外，在粉丝阵营中更不乏摇旗呐喊者、推波助澜者、上窜下跳者、浑水摸鱼者……自然这也给我们这些关注硬件圈的玩家带来了诸多的话题。
画面同步技术，一个既新又旧的技术。说旧是因为自从有视频信号传输开始，如何保证画面同步就成为了一个课题；说新是因为随着处理技术的发展和需求的提高，如何更高效解决现有问题却是一个时变时新的问题。那么，同步技术到底能给我们带来多少体验上的区别？这次AN两家提出的方案究竟是切实提升还是市场噱头？在这之前，我们必须先重新搞清楚什么是卡顿，什么是延迟，什么是撕裂。
Frametime
现在我们都知道Frametime是指电脑在生成一帧的过程中所消耗的时间，那么很自然地，这个时间越短的话电脑就可以生成越多的画面，也就可以缩短每个画面之间的间隔时间，从而我们的感官上会觉得更流畅。
那么，Frametime的数据应该怎么样得到呢？Fraps，毫无疑问。然而问题是，Fraps测的数据是对的么？
在回答这个问题之前，我们首先要先搞清楚Fraps的工作原理是什么。
这里需要特别指出的是，Fraps是针对DirectX API而编写的软件，因此对使用其他API进行运算的程序无法保证正常运行，这也是为什么Fraps无法采集Mantle数据的原因。
这是一张DirectX工作的流程图，可以看到其主要包含程序、系统、驱动和显卡四个部分组成，且驱动和系统之间存在两次交互。不过这不是今天的主题，我们也没有必要纠结太细枝末节的东西，有兴趣的朋友可以参考微软的PPT，里面针对各个pipeline有比较清楚的说明。
Fraps的工作原理如图所示，简单来说就是在指令从程序端进入系统D3D的过程中注入DLL对Call进行覆盖，由于几乎每个发出的Call到最后都会形成一幅画面，因此这个方法似乎对绝大多数程序都屡试不爽。
如果你需要测试一段时间内的平均FPS，那么这个方法是十分简便好用的，用总的Call数除以经历过的秒数就会得到平均每秒的帧数。但当你需要测试Frametime的时候，这个方法就显得不那么好用了。
由于在指令刚刚进入D3D的时候Fraps就注入了自己的DLL，所以实际上Fraps收集到一个Call的时间是从指令进入D3D到显卡运算的结果，所以实际上Fraps不知道指令在pipeline中实际所花费时间，更不用说万一系统内部碰到什么其他的问题，比如指令在驱动层或者在context queue中被延滞，这些时间都会被Fraps算进总时间内。
实际上，从整体上来看电脑在处理过程中是有重叠的，所以这里必须要提出的是，“延迟”和“卡顿”是两个完全不同的概念。
延迟、卡顿和撕裂
这张图就可以比较直观的说明问题了。
作为一个玩家来说，从自己进行输入操作开始一直到最后显示器上输出图像被眼睛接受，这个过程中消耗的时间是延迟。这个延迟的概念实际上和通常网络游戏中遇到的网络延迟的感受是差不多的，虽然画面可能十分连续，但总是有好像反应慢一拍的感觉，这就是延迟被大脑感受到了结果。
卡顿则是在两个画面的间隔时间过长被大脑感知到的过程。帧与帧之间的间隔过长会导致形成动作不连贯的影响。需要注意的是FPS过低必然会造成卡顿，但是卡顿却未必是由于FPS过低造成的，不合理的帧生成间隔和显示间隔也会同样导致这个结果。
这是一张画面撕裂的图片，很明显我们可以看到画面中的物体显示有问题，而且显示边缘几乎都在同一水平线上。要明白为什么会产生画面撕裂，我们得回到显卡和显示器的衔接过程中。
同步和缓冲
显卡会把运算完成的信息放在一个缓存中，这个缓存被称为Front Buffer，存在于显存中，当显示器需要刷新的时候就会从Front Buffer中读取画面信息并显示于面板上。那么很不巧的是，如果显示器本身在刷新的过程中如果显卡正好往Front Buffer中注入了新的画面，那么就有可能造成扫描线扫描到的一部分画面是之前的画面，但是另一部分画面是新注入的信息，这样也就造成了画面撕裂。
开启垂直同步可以有效避免画面撕裂的问题，其原理是让显卡的工作保持与显示器的扫描线保持同步，画面处理完成后等待扫描线更新后再进行新的工作处理。
但是这样做也有一个很明显的问题，那就是处理完的画面并不会很快就输出到面板上，而画面将会是等待显示器的扫描，在整体帧数并不足够高的情况下，虽然有效避免了画面撕裂，但是通常新一帧输出需要跳过好几次扫描线更新，更容易产生延迟。
为了解决这种情况，后来在垂直同步中引进了多重缓冲的技术，在Front Buffer的前端再增添Back Buffer进行进一步缓冲来避免这种情况的发生。多重缓冲按照Back Buffer的数量可以分为双重缓冲和三重缓冲。
双重缓冲的原理是在Front Buffer之前添加一个Back Buffer，这样当显卡完成了新的画面之后将新的信息存到Back Buffer之中，然后通过一个Swap命令交换Back Buffer和Front Buffer中的数据，将新的数据换到Front Buffer中以供扫描线进行更新；将旧的数据换到Back Buffer之中以供显卡覆盖新的数据。
三重缓冲的原理类似双重缓冲，相比其添加两个Back Buffer，这样显示器需要扫描的时候可以从两个Back Buffer中选择数据相对较新的Back Buffer进行Swap，而显卡则会不断将数据交替注入两个Back Buffer中。
如果以上的原理不太好理解，那么这里举个相对形象的例子：
仓库里有一些箱子需要通过卡车运走，如果只有你一个人来处理这个工作，那么你需要到仓库里把一个箱子挪到卡车旁边，再把这个箱子抬到卡车上，然后回去继续挪箱子；
如果有两个人工作，那么一个人可以专门负责把箱子挪出来，另一个人专门负责把箱子抬上车；
如果有三个人工作，那么两个人可以交替把箱子挪出来，另一个人专门负责把箱子抬上车。
G-Sync
G-sync则从另一个角度出发来解决问题：不是让显卡等着扫描线，而是让扫描线等着显卡。G-sync为显卡提供一层缓冲，且自身芯片通过vblank控制显示器的扫描线，使得显示器本身处于一个不断变化的刷新率中，这样可以保证显卡一旦有新的画面输出就马上可以被扫面线更新到面板上。
在这样的方案之下，画面撕裂的问题自然就不复存在了，由同步引起的延迟问题被解决了，也尽可能得减少了卡顿，确实是一个非常优秀的方案。
这个方案有缺点么？答案是肯定的。
首先，显示器通过芯片控制被强制同步了，但是音频却没有被同步，这个问题基于程序本身的逻辑可大可小；
其次，G-sync只是一个锦上添花的方案，而不是一个颠覆性的方案。G-sync保证了显卡输出之后和面板同步的问题，但是并不会对显卡本身的性能有任何的增长。说白了，如果你显卡本身的性能无法满足游戏要求的话，上什么sync方案都是白搭。
最后，这个方案的成本是巨大的。为了满足这个方案，你首先需要一张性能不低于650ti Boost的Nvidia显卡，一块售价199美金的G-sync卡，一块支持vblank的高刷新率显示器。120Hz甚至144Hz的显示器通常售价不菲，且拆开显示器添加G-sync卡会导致显示器本身失去保修。相比于这样的代价，把199美金拿去上更加强力显卡似乎反而是更经济实在的方法。
FreeSync
相比之下，似乎AMD的方案看起来更加“简单粗暴”一点。如果显卡还没有准备好新的图像怎么办？那就继续原先的图像呗。如果显卡有了新的图像怎么办？马上显示出来呗。
FreeSync的原理可以简单概括为，当显卡输出图像的时候，将会同时送出一个开始信号，告诉显示器一直保持这个图像；当又有新的图像输出时，显卡将会发出一个结束信号，让显示器在这个时刻结束先前图像并更新画面。
这个方案看似尽善尽美，不需要额外的硬件模块、几乎不增加显卡负载、没有延迟和撕裂。那么，有缺点么？答案自然也是肯定的。
首先，显卡本身需要支持这一技术。虽然这是一个开放方案，理论上即便是Nvidia或者Intel的GPU也可以使用，然而现在毕竟还处在技术早期，即便是AMD本身所支持的GPU也相当有限。
其次，显示器自身需要支持。该技术基于DisplayPort 1.2a，也就是说不支持DP接口的显示器基本可以洗洗睡了。
然后同样的，这也只是一个锦上添花的方案。任何的同步方案都是一样，巧妇难为无米之炊。
最后一点来源于自己猜测，过快地更新图像可能引起拖影问题。如果显卡的性能相对富裕，那么显示器就会尽其所能的一直处在刷新操作中。然而面板的相应时间却总是有限的，过于频繁地变化像素点颜色可能导致显示器面板本身应接不暇，反而起到反作用。
实际效果
实际上，这种直接和用户感官接触的东西往往是最难评论的，因为你可能会有一些范围，在这个范围内的指标都是“合适的”，而很难找到一个统一的标准对于所有人都是“舒服的”。因此像Sync的同步效果究竟如何这样的问题，我不会给出任何答案或者结论，仅提供两个对比视频共各位评说。
http://v.youku.com/v_show/id_XNjI2NDEwNTc2.html
http://player.youku.com/player.php/sid/XNzIxMTcwMDQ0/v.swf |
本帖子中包含更多资源
您需要 登录 才可以下载或查看，没有帐号？注册
x
评分
-
查看全部评分
|
收藏
转播
