当前位置:首页 > 装机升级 > 显卡 > 评测
游戏跑分新视角:细看一秒内帧数变化
  • 2011-9-22 0:01:00
  • 类型:转载
  • 来源:泡泡网
  • 网站编辑:admin
【电脑报在线】    编者按:从游戏评测出现至今,FPS(FramesperSecond,每秒帧数)一直都是我们衡量硬件表现好坏的标准。毫无疑问,在绝大多数情况下,FPS的确可以作为游戏性能的标杆。但是,经历了长久的测试历程以及数以万计的帧数统计之后,部分玩家已经开始注意到,实际获得的游戏体验和表面得出的FPS数据并不完
    编者按从游戏评测出现至今,FPS(FramesperSecond,每秒帧数)一直都是我们衡量硬件表现好坏的标准。毫无疑问,在绝大多数情况下,FPS的确可以作为游戏性能的标杆。但是,经历了长久的测试历程以及数以万计的帧数统计之后,部分玩家已经开始注意到,实际获得的游戏体验和表面得出的FPS数据并不完全相符。

    是测试数据有误,还是我们的评定标准本身就存在缺陷?FPS真的能代表一切吗?近日,国外同行TechReport撰文,详细解答了我们以上的疑问,深入探究了FPS的一些弊端,并且提出了全新的游戏测试理念。当然,还有更多的问题得以爆料。(以下为全文翻译,部分内容进行了调整。注意,本的主要侧重于新游戏测试理念的阐述,而并非显卡跑分PK。)

    


    本文的初衷其实来自一个简短的谈话。去年秋天,我和曜越科技(Thermaltake)公关RamsomKoay一起共进晚餐的时候,被问及了一个看似简单但又不太好回答的问题:既然一款主流显卡就能在多数游戏中提供基本的流畅度(30FPS以上),为什么还有那么多人还要买更快的显卡?更高的FPS究竟能代表什么?谁需要它呢?

    表面上,我在这方面是专家。但打心底来说,问题到来那一刻我并没有做好准备去如何回答。虽然有些突然,我还是简单思索了一下然后给出了我自认为的最佳答案,也无非是一些关于避免卡顿以及保持一个稳定的游戏画面等等。不过说完这话之后我就意识到了不太妥当,因为在我们以往的显卡评测中,关于这些我们并没有给读者一个合理的阐释。

    实话说,这个问题一直让我很纠结。虽然接下来的评测任务量一直不小,但是我还是抽出一些时间改变了一下测试流程,将Fraps的FrameTimes功能启用,以此来记录每个独立帧渲染需要耗费的时间。在此之后的的每一个显卡评测,我都会仔细的收集这些数据。(虽然这样很耗时,但对于这篇文章却是至关重要的。)

    到上周这一工作算是告一段落。接下来我抽了一部分时间,将这些数据进行细化整理。最终的结果是这些数据相当有启发性,甚至让人有些担心(对于我来说),因为它直接颠覆了我们以往评测的一些结论。但是,我认为这些结果非常值得分享。实际上,它甚至可能会改变你对于游戏测试的固有理念。

     为什么FPS是失败的?

    毋庸置疑,几乎所有的游戏硬件测试都采用同一种评估方法,那就是大家公认的FPS(FramesperSecond,每秒帧数)。毫无疑问的是,FPS是一个出色的即时性能汇总,表达准确而且简单易懂。不只是游戏,FPS的概念还常见于我们所熟知电影及电视,比如电影/电视分别以每秒24/30张画面的速度播放,也就是一秒钟内在屏幕上连续投射出24/30张静止画面,所以播放速率就是24/30FPS,游戏画面也与之同理。(通常每秒播放24张画面以上,根据“视觉惰性”,即视觉暂留现象,人眼就认为是连续的。)

    当然,关于利用FPS进行测试的争论一直存在,尤其是我们常见的平均FPS更是受到很多质疑,因为其衡量的太广泛了。事实上我们也从这些讨论中汲取了一些有用的东西并付诸实施,比如在游戏测试的时候同时获取平均FPS和最低FPS,甚至可能的时候还提供了单位时间内的FPS变化图表。相比干巴巴的平均FPS,我相信这些信息更能够帮助读者更好的理解游戏性能表现。

    即便如此,这种方法仍旧有一些明显的缺点。因为经历多次的测试之后,我们发现有些时候这些结果和我们的直觉体验并不完全一致。最根本的问题在于,无论对于电脑时间还是人类视觉感知来说,一秒都太长了。一秒内的平均结果可能会掩盖一些系统性能突发变化,而这对于游戏体验来说非常重要。

    为了说明,我们先来看两个例子。虽然经过加工,但这些结果却是基于我们多年来的游戏测试真实数据。下面的图表纵轴以毫秒(ms)为单位表示所需要的时间,而横轴则表示一秒内两款不同显卡所提供的一系列帧数。

    

    

    显而易见,GPU1在大多数情况下跑得更快,每帧所用的时间较短(绝大多数都在25ms以下),而CPU2要慢一些,因为每帧时间一直稳定在30ms左右。

    但是,我们可以看到GPU1在运行这个游戏的时候有一个明显的问题(假定说是由于驱动里糟糕的显存管理引起的纹理载入毛病造成的,也可能是硬件方面的原因),那就是其中一帧所耗费的时间出奇的长,几乎达到了将近500ms,像是被卡在那儿了。如果你是这个游戏的玩家而碰巧遇到这个问题,一瞬间肯定会卡的要死。而如果这个问题经常出现,游戏也就基本不能玩了。

    而这方面GPU2就要好了不少,虽然平均FPS可能要比GPU1少,每帧耗费的时间都差不多,并且能够提供一个持续稳定的游戏画面输出。那两款显卡的平均FPS到底是多少呢?

    

    可以看到,在我们统计的时间内,两款GPU的平均FPS几乎相同。如果就此而言,那么两款显卡的性能表现本质上没有区别。而正是我们使用了平均FPS,才使得GPU1中的一个致命缺陷被掩盖了起来。

    以上只是一小段时间内的反映,如果说GPU1在整个测试中的其它场景也时不时遇到类似的延迟,但耗费时间可能没有这么大,那整体帧数可能会达到50FPS的样子,最低帧数也有35FPS。而根据我们传统的思维,这是一个看起来相当不错的成绩,但是实际游戏体验的糟糕程度就可想而知了。

    回归到主题,FPS对于性能评估的意义虽然重大,但短板也是明显的。而解决以上问题最简单有效的方法就是将单位时间放大细化,就像我们刚才做的那样,把每帧所耗费的时间独立呈现。事实上这么做并没有什么难度,想必那些游戏开发商们已经研习多年。

    所以,对于我们自己来说,也是时候转化一下认知理念了。下面表格里的数据可能会有一些帮助,详细列举了部分以毫秒为单位的帧时间(越低越好)所对应的FPS速率,这里的条件是假定完整的统计时间为1秒。这个表已经包含了许多阈值,比如其中16.7ms相当于稳定的60FPS。打个比方来说,目前大多数LCD的的刷新率就是每秒60次(60Hz),所以每次刷新的时间高于16.7ms的阈值就不能提供稳定的画面输出。

    
Frametimeinmilliseconds

    
FPSrate

    
8.3

    
120

    
10

    
100

    
16.7

    
60

    
20

    
50

    
25

    
40

    
33

    
30

    
42

    
24

    
50

    
20

    
60

    
17

    
70

    
14

    
经过以上几点介绍,下面我们就来看一下实际游戏测试中的一些数据,看看我们能够从中获得什么。

     FPS有弊端我们换一种新方法

    第一个实例来自我们之前的GeForceGTX560Ti评测。虽然测试发布较早,测试驱动也有些老,但并不影响验证我们下面采用的新方法。测试游戏使用的是《战地:叛逆连队2》,画质设定如下图所示。

    

    

    虽然一大推数据看起来相当繁杂,但在准确的绘制每款显卡帧数时间的时候却并不十分困难,这个时候我们之前工作的效果就体现出来了。

    

    

    正如你所见,即便各项数据纠结到一块儿,但异常值(耗时较高的帧数)还是能一眼就看出来。另外可以看到,高端卡能够在单位时间内输出更多的帧数,而且每帧耗时交少,所以数据线也要更长更低。

    

    另外,竞争对手之间的数据比拼可以在图中非常直接的体现出来。总的来说,这种方法相当直观而且简单易懂。比如上图中的GTX560Ti在2150-2250帧数范围之间明显更快,在500帧左右HD6870有一个明显的异常值等等。接下来我们将这些数据放大,进一步深入观察。

    

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

    这些放大数据和我们之前的数据基本对应,尽管HD6870那个异常值看起来并没有那么长。很明显,两款显卡的差别如果采用FPS是无论如何也无法体现出来的。

    另外,我们看到在58ms异常值之后的那两帧出现了突然的回落,延时非常低。之所以会出现这种情况,是因为显卡采用了三重缓冲技术,也就是每三帧可以同时渲染,所以后两帧并不需要等待前一帧的延时。虽然可以把这三帧看做一个整体,而且平均耗时也只有23ms,但是只要那个58ms延时存在,就会对实际游戏的流畅度造成一定影响。

    实际上,我们并不想夸大类似一个单独的突发帧延时的影响,但是借助已经在录的众多数据,可以看看还有没有类似的情况发生。

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

    我们将以上八款显卡60秒内超过50ms延时的帧数列举出来。可以看到,四款A卡中除了HD6970之外,都出现了4个以上的异常值。而与之相反的是四款N卡类似的情况则没有出现一次,即便是老迈的GTX260也是如此。

    比如对反应时间要求极高的联机游戏玩家,稳定的帧数时间就显得尤为重要。那么参考我们上文提供的数据图表,将帧数时间降低到20ms以下(对应50FPS),可以轻而易举的选择出合适的显卡。

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

    结果相当明了,只有GTX570和HD6970(稍有一些)两款显卡几乎没有20ms以上的延时帧。或许看完这些对比之后还是没有一个清晰的概念,这些数字到底有什么意义呢?

    回到文章开头我们提到的问题,之所以许多人热衷于高端显卡,就是为了获得更好的游戏体验。而更好的游戏体验,就是建立在显卡在单位时间内提供稳定的帧数输出的基础上,每帧占用更少的延时时间。而这远比单纯的一个FPS数据更有意义,也更加客观。

    下面我们就将筛选条件进一步提高,统计出每款显卡99%的帧数中的最低耗时时间(以下图二为例,GTX570的99%帧数耗时都在18ms以下),并据此对比一下各款显卡的FPS排名。

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

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

    两种测试方法下,各款显卡的排名基本一致,差别程度也比较相仿。从某种意义上来说,这些显卡在平衡FPS和每帧耗时之间做的不错。如果这样来看,传统的FPS并没有什么问题,高FPS显卡能够获得更低的帧耗时,反之亦然。那么这种新的测试方法又有什么意义呢,难道仅仅是为数据分析提供便利吗?先别急,下文便见分晓。

     单卡不明显那多卡系统呢?

    上文中我们的新方法和传统方法测试得出的结果排名基本一致,或许会有读者质疑这种方法的实用性。不过别忘了,到此为止我们仅仅测试了单块显卡,而多卡并联系统还只字未提。结果又会怎样呢?

    以下多卡测试数据来自我们之前的GeForceGTX590评测。和前面一样,测试游戏同样是《战地:叛逆连队2》,这一次我们采用了更加符合多卡系统定位的2560x1600分辨率。

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

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

    测试方法与上面的单卡测试相同,具体结果如下:

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

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

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

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

    可以明显的看到,多卡的数据走向与单卡差别非常明显,形状也不再是一条线,而且突发帧的数量大大增加,这究竟是怎么回事儿?同样,我们将这些继续将这些数据放大,更直观地观察。

     出现问题的放大

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

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

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

    同样的,三款单卡看起来还比较正常,总体来说比较问题,而且突发帧数量并不多。

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

    从GTX560TiSLI身上就已经开始显现出较大波动,总体上遵循一高一低的趋势,下面的多卡系统莫不如此。

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

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

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

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

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

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

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

    已经不止一次的听到关于多卡系统的Micro-stuttering(下文会具体解释)问题了,这次算是一个集中的反映。需要清楚的是,我们这里看到的很像是多卡系统工作方式的一个人工还原。

    不管是AMD还是NVIDIA,在CrossFire/SLI多卡系统中都将AFR(AlternateFrameRendering,交替帧渲染)作为首要渲染模式。顾名思义,比如在双卡系统中,AFR就是将偶数帧交给GPU1渲染,而奇数帧则安排给GPU2渲染;或者说把第n帧画面指派给GPU1渲染,把n+1帧指派给GPU2渲染,使帧数渲染交替进行,从而充分利用多卡系统的并行几何处能力。(三卡或四卡的原理一样,渲染交替进行。)虽然,CrossFire/SLI同样支持其它一些负载平衡渲染模式,比如SFR(SplitFrameRendering,分割帧渲染),但效率方面并不如AFR。

    虽然这些基本原理非常简单,但要在多卡系统中做到负载平衡却相当不易。首先,每一个独立的帧从渲染原理上来看就是一个需要高度平行的任务,需要高度平行的天性使得帧与帧之间的平行也相当拿捏,所以保持帧间的同步很是困难,更不用说多卡之间的负载平衡了。(比如GPU1已经完成了1帧渲染,需要进行第3帧渲染,而此时GPU2的渲染还在进行,那么GPU1就需要等待。当然,实际的平衡负载问题要复杂的多,需要平衡算法来解决。)

    另外,因为不管多卡系统中有几款显卡,只有主卡才能与显示器连接,所以其他显卡渲染的帧只能通过传输到主卡进行输出。而无论是CrossFire还是SLI接口,这种数据传输都会耗费时间。除了帧数据,其它的一些缓存数据也需要经常在显卡之间进行传输,尤其是一些高级渲染技术(比如render-to-texture,渲染到纹理)使用的情况下。而这些数据通常会使用PCI-E接口,同样会造成延迟。

    上面的图表很好的说明了多卡系统之间负载平衡还远远未达到完美,需要解决的问题还有很多。不过现在,我们可以先从一些多卡系统的天生缺陷说起。

    很明显,继续使用平均FPS去评估多卡系统的性能表现肯定是不靠谱的。因为从平均FPS很难看出高延迟帧,而这些高延迟帧却恰恰是获得连贯游戏画面的关键因素。我的感觉是,在提供连贯的游戏体验方面,帧延迟在20ms和50ms之间交替进行并不如一直稳定在50ms。

    因为,从人类的视觉系统特别善于捕捉不规则的场景,也就是说一快一慢的画面会让人感觉相当不爽。事实上吗,这种体验我已遇到多次。这也就是为何很多人抱怨Micro-stuttering的原因。

    当然,这些只是冰山一角。问题的复杂性要远比这些图表展现的高的多。关于这个问题我们接下来会进一步阐释,但现在,我还是想把这些数据继续放大,看看还有那些问题。

     数据的进一步分析

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

    这里有一个进一步分析这些数据的原因,因为我相信这里看到的问题并不完全依赖于micro-stuttring。如果你看看我们之前完整的测试图表,就会很清楚的看到这个趋势:多卡系统明显要比单卡产生更多的延迟帧。平衡多卡之间的负载需要更多的系统资源消耗,以超过50ms延迟帧的数量来看,同样型号的单卡要明显好于多卡。

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

    如果我们将阈值降低到20ms,这时多卡系统就看起来好多了,尤其是SLI。虽然我们之前也说到了Micro-stuttering可能会引起各种各样画面的不连贯,但只要高延迟帧的数量不是过多,多卡系统依然能够在多数情况下比单卡表现的好。

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

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

    上面两张图算是对我们的新测试方法最好的回报了。在前面单卡测试中,两种测试方法各款显卡排名镜像排列,而这里情况就大不一样了。比如采用FPS标准衡量,HD6970CF排名第二;而到了“99%帧时间”方法中却跌倒了第四位。另外可以看到,HD6870CF的FPS表现相当不错,GTX580也屈居之后;但是在第二种方法中却排名垫底,甚至还不如GTX570。

    现在还很难说这种新方法就是衡量显卡性能的最佳途径,但至少可以肯定的是,作为考量显卡帧耗时的一个指标,它要比传统的FPS更加出色。换句话说,这种方法对我们的玩家更加负责、更加中肯,即便表面看起来有些呆板。

    为了更好地反映这种新方法的作用,除了“99%帧时间”,我们还非别统计了50%、66%、75%、80%、90%、95%、98%几个范围内每组显卡渲染帧的耗时。虽然我并不建议将来的显卡评测都采用这种方式,但从说明问题方面来看,还是相当直观的。

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

    从上图中不难看出,想要对比两组显卡相当简单。比如在50%的帧数范围内,HD6970CF的帧延时要明显低于GTX590,在提高帧数比例之后,劣势就慢慢显现出来。再比如,GTX57050%的帧数延时大大高于HD6870CF,但提高到99%的帧数之后,就基本打个平手了。

     更多实例验证之《子弹风暴》

    当然,仅仅靠一款游戏很难说明问题,接下来看看其他游戏中多卡并联是否还是存在类似的问题。下面这款游戏是《子弹风暴》,为了区别于《战地:叛逆连队2》,我们使用了不同的测试方法:不再使用固定的场景,而是在一分钟的时间内,在同一关卡内试玩5次,选取其中一次的统计结果。这也就意味着测试结果的变数会更大。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    不管是什么样的原因,相比单卡,多卡系统出现了帧延迟波动问题多多少少都会出现。从以上测试结果来看,除了GTX580SLI和HD6970CrossFire稍微好一些,其它几组显卡的波动都不小。虽然这只是一小段测试的数据,随机性比较高,但我的感觉是即便跑完整个侧这种问题依然无法避免。

    按照惯例,我们将这些数据进行一步分析:

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

    由于GTX560Ti表现太糟糕,50ms以上的延时帧就超过了500个,所以这里就不做讨论了。坦白说,大多数多卡并联对高延时帧的抑制还算不错,唯一的例外就是HD6870CF,虽然没有GTX560Ti那么差劲,但50%以上帧数延时都接近35ms。其中的原因不太好说,但我们分析可能是显存过于吃紧造成的。

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

    有个问题不得不说,在做类似的统计的时候,一定要注意设定的阈值。比如上图中GTX580高于20ms的延迟帧要明显高于GTX570,但以50ms为阈值的话,结果恰恰相反。一般来说,50ms的阈值对于日常测试应该就足够了,而20ms就显得稍微有些苛刻了。

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

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

    在《子弹风暴》测试中,传统的平均FPS和“99%帧时间”两种方法获得的显卡排名基本上一致,但HD6870CF算是个例外,从第五名跌倒了第七。而我想说的是,在“99%帧时间”中我们看到了GTX560Ti是多么不济。虽然平均FPS也达到了25帧左右,但经常出现80ms以上的帧数,玩游戏自然不会流畅。

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

     更多实例验证之《星际争霸2》

    《星际争霸2》和其它游戏有些不同。虽然同样采用Fraps进行帧数记录,但测试过程中采用的是播放录像Demo,而并不像前两款游戏中我们亲自去试玩。这里的录像Demo为33分钟,由于时间较长,所以每款显卡也不再测试五遍。33分钟所产生的帧数相当庞大(有些显卡达到了140,000个之多),也不能全部都统计在一张表内,这里每个表我们只选取了6500个。

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

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

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

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

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

    有些意外的是,前面两款游戏中几款单卡的帧数耗时几乎没有什么波动,但这里…….

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

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

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

    可以看到,除了GTX570还好为好点,无论是GTX580还是HD6970均是以三到四帧为跨度出现较大跳跃,尤其是GTX580波动的周期相当有规律。HD6970虽然没有那么规则,但情况也比较类似。我反复猜疑其中的原因到底是什么,有可能是三重缓冲的影响,也可能是游戏引擎以周期工作,或者是这两方面的综合。这里也充分说明了一个道理,要获得一个稳定的帧数延迟,单单靠SLI或者CrossFire的优化还是远远不够的。

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

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

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

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

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

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

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

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

    多卡系统中,SLI并没有像NVIDIA单卡中波动那么明显,反而趋于缓和;而CrossFire的情况与单卡很是类似,按照3-4个帧周期交替进行。虽然这里我非常想说明以上问题到底为何,但目前还很难给出一个合理的解释。

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

    单从《星际争霸2》这款游戏来看,相同级别下,N卡在避免高延时帧方面显然做的更好。但在6500个统计帧数之内,还是有相当多的帧延时超过50ms,即便是GTX580SLI也是如此。这里可能与CPU或者其它系统配置的限制有很大关系,可以肯定的是相对较少的高延迟帧能够帮助我们获得更好的游戏体验。

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

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

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

     难免而且复杂的Micro-stuttering

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

     那……现在呢?

    好吧,我先承认下面的文字算不上全文的总结。

    经历了一大推测试数据以及和Nalasco以及Petersen的交谈之后,我们有以下几点值得阐述。最重要的一条:保证游戏中的帧率平滑将会是未来GPU性能评定的一个新途径,而不再是仅仅衡量单纯的渲染速度。就目前来看,多卡并联系统依然面临着很大挑战,而单卡也远远称不上完美。可以肯定的是,未来新技术以及新算法亟待应用,而GPU与游戏厂商同样任务不轻。只有这样,才能为用户提供更加出色的游戏体验。

    另外,摆在我们(评测人员)的是,如何测试才能够准确衡量帧率波动给显卡性能带的影响。Petersen已经告诉我们NVIDIA正在考虑做一个API,允许Fraps此类第三方程序能够从GPU内部渲染开始读取时间。当然希望他们能够这么做,我们也会尽量说服AMD在驱动程序中提供类似的功能。除此之外,或许高速摄像相机在测试屏幕变化精度方面会大有裨益。(开个玩笑,这可是出钱还要出力啊。)

    最后,不管何种显卡评估或者测试,读者的体验才是王道。比如,我们要对一些基本问题有深刻的理解:Mciro-stuttring的问题影响到底有多严重?(我想回答成画面间断不连续更为精确,而并非“高延迟帧的潜在可能性”云云。)答案很大程度上依赖读者的观点,而读者的观点往往又依赖于读者本身以及对问题的认知程度等等。

    与此同时,我们对Mciro-stuttring问题的读者反馈很感兴趣。如果你正在使用多卡系统,你曾遇到过Micro-stuttering问题吗?如果遇到过,多久才能看到一次,感觉如何呢?在下面的评论中发挥吧。

    讲了一大推,最后还是说说我们的新测试方法。尽管遇到这样或那样的问题,但我们还是比较谨慎乐观地和大家分享。客观来讲,我们的新方法提供了以往传统测试方法无法获得的显卡性能真实表现,并使之大白于天下。无论是数据分析还是显卡对比,都相当直观而且浅显易懂。甚至,用到CPU测试中也未尝不可。在未来的测试中,我们很可能付之于实施。也欢迎各位读者积极反馈。总之,我们的感觉是,一旦你走进微观世界,就很难再用宏观的眼光去看它了。■

     

我来说两句(0人参与讨论)
发表给力评论!看新闻,说两句。
匿名 ctrl+enter快捷提交
读者活动
48小时点击排行
编辑推荐
$ViewControl.热点推荐_Vs2$
论坛热帖