本帖最后由 sapphirex 于 2011-8-6 16:37 编辑
http://vga.zol.com.cn/241/2410554_all.html#p2410554
来,战个痛快
前言:GPU大百科全书系列的连载已经进行了4期了,在这4期的连载中,我们领略了GPU流水线在处理图形过程中的前三步重要步骤,包括几何处理,光栅化和像素处理。尽管笔者竭尽所能将故事说的尽可能通俗易懂,但是在水平有限,因此笔者在这里再次诚挚的感谢能够坚持阅读的读者们。在本期的GPU大百科全书中,我们将会以一个全新的视角,来面对一系列长达10年之久并还在继续的关于设计之争的大论战。
也许你会觉得,技术的进步和产品的分歧只是一场很热闹的游戏,除了昭示某方看似一念之差所犯下的错误以及给各种争论带来弹药之外,好像并没有别的意义,我们这么反复咀嚼吵架剩下的东西一点意思都没有。
其实不然,10年来NVIDIA与ATI/AMD在shader领域相关的IC设计之争以及此消彼长,其本质上并不是,或者应该说不仅仅是各公司自身设计实力所导致的。到底是什么导致了这场长达10年的纷争中的每一次胜负?这些胜负又意味着些什么?这种导致胜负的因素会不会对今后的继续影响GPU的发展?我们在今天的GPU大百科全书所要解析和面对的,就是这存在于喧哗吵闹背后的真实。
● 来,战个痛快 NVIDIA与ATI,以及后来收购ATI的AMD,这对冤家的恩怨纠葛几乎伴随了整整一代人的成长。自从3Dfx,S3,Trident,Matrox以及SIS这些曾经叱咤风云的图形大鳄们退出历史舞台之后,NVIDIA和ATI/AMD就完全霸占了IC舞台中最抢眼的一部分。
已经消逝的3Dfx
在先前的文章中,我们仅仅使用了最程式化的流水线介绍法来展现相关单元的运作方式以及技术特点,并未涉及任何实际的产品。对于几何部分以及光栅化这两个相对封闭而且更新节奏较慢的单元来说,这么做不仅能够避免把话题过早的引向争论,而且可以消弭差异化所带来的理解方面的问题。但当我们的来到像素处理部分时,这对冤家在设计上的差异已经非常表象化,而且到了完全无法忽略的地步。伴随着像素处理单元发展的,是一场又一场惊心动魄的战争。
这是一场关于像素的战争
既然不能忽略,那就让我们直面这份差异。来,战个痛快!
第一次争论
● 第一次争论 shader的第一次出现,对任何人来说都是欢欣鼓舞的事情,可以实现各种过去想都不曾想过的特效不仅让程序员们兴奋不已,更令硬件供应商摩拳擦掌——这下好了,又有敦促消费者升级以及更换硬件的完美借口啦。
当然,光有借口是不够的,厂商必须设计出实际的产品,才能最终让消费者打开荷包任其舔舐。而设计产品就要有计划和设计目的,产品必须符合一定的要求和规范才能成为产品。对于图形供应商来说,规范和要求似乎没啥可选择的余地,满足DirectX和Open GL似乎是唯一的要求。无论怎么看,这本来都应该是挺简单的一件事。
Pixel Shader1.4实现的水面效果
但是活雷锋大商人微软是顽皮的,他似乎并不喜欢让一切都如剧本般一帆风顺的进行下去,于是便为这个本来应该是挺简单的事情添加了一份变数——在发布包含Pixel Shader1.0/1.1的DirectX8.0之后1年,微软又发布了升级后包含Pixel Shader1.4的DirectX8.1。
相对于Pixel Shader1.0/1.1,Pixel Shader1.4的改进其实并不明显,除最大指令支持度上进行了升级之外,Pixel Shader1.4并未带来更多实质性的进步。但即便仅存在些许的进步,毕竟他是微软发布的一个新版本API,游戏规则的改变势必会影响到厂商对硬件设计层面的决策和部署,如果某个硬件对于新的API支持不足,厂商就要对市场作出解释,以当时的情况来看,第一个需要作出解释的厂商,是NVIDIA。
NV25“狼来啦”
NVIDIA于2002年4月发布的NV25并不支持的Pixel Shader1.4,这款新构架虽然效能卓越,但其API支持度甚至还不如半年前竞争对手ATI发布的R200,这种奇特的现象不仅让市场无法理解,而且也让竞争对手抓住了小辫子。NVIDIA给出的对NV25不支持Pixel Shader1.4的解释是Pixel Shader1.4改进极少且响应欠佳,在没有获得多少支持度的前提下推出对应的硬件没有意义。说白了,就是Pixel Shader1.4现在还没用,我们的新构架满足有用的API的需求就可以了。
以现在的眼光来看,NVIDIA在当时所作出的宣传其实并没有错,Pixel Shader1.4本身的更新确实不大,而且也并未带来本质性的特效提升。经营了1年半之久的Pixel Shader1.0/1.3在当时已经获得了非常好的支持度,推出适应的硬件其实也没有错。从结局来看,NV25也确实因为其强劲的性能、灵活有效的市场划分和对手各种糟糕的表现而获得了几乎完胜的销售成绩。可以说第一次针对硬件的争论,是以NVIDIA的胜利而告终的。
NV25芯片结构
尽管这场并不算很大争论最终的胜利属于NVIDIA,但同时也给NVIDIA传达了一个相当错误的信号:NVIDIA误以为自身的影响力,已经可以凌驾在舆论以及微软之上了——既然我说Pixel Shader1.4暂时没用,市场就能接受这种言论并且很自觉的买我的帐,那这块市场岂不是我说了算了?这个错误的信号,为今后故事的发展埋下了一个巨大的伏笔,它直接导致了NVIDIA在未来第一场真正的战斗中犯下的其发展史上最大的一次战略错误。
有关精度的唇枪舌剑
● 有关精度的唇枪舌剑
如果说Pixel Shader1.4之争仅仅是支持度的问题的话,接下来所发生的这场争执就不再那么简单了。它不仅将NVIDIA与微软的分歧摆上了台面,更影响了NVIDIA整整一代产品的表现,它就是初代DirectX9.0的浮点精度。
Pixel Shader2.0实现的效果
2002年12月,微软发布了全新一代图形API——DirectX 9,如果说DirectX 8.1的Pixel Shader1.4改动来的太小,支持度和意义都不是很大的话,DirectX 9的Pixel Shader2.0就可谓是脱胎换骨了。全新的Pixel Shader2.0所引入的更大的指令数也让Pixel Shader2.0获得了更好的效率,同时FP24浮点格式的RGB数据处理让程序员第一次有了能够完整正确的表达颜色的可能。有了DirectX 9,人们终于有可能在计算机上创造“虚拟的现实”了。
Pixel Shader2.0的浮点数据精度存在问题
但就是这么一个重要的API,却在发布的同时就引发了一场巨大的争吵和骚动。人们纷纷对微软使用的浮点精度表示了困惑,而NVIDIA则第一时间对这种精度提出了质疑,认为这个浮点精度是不会被市场采纳和接受的,得不到认可的,更将矛头直指微软针对自己,恶意推出一款违背常规及现实需要的图形API,我们甚至可以从当时NVIDIA的态度中感受到明显的激动。
也难怪NVIDIA如此激动,因为美国电气和电子工程师协会在IEEE 754中规定的二进制浮点算法规则里,压根就不存在FP24这么个格式……
IEEE754关于浮点数据精度定义的文件 根据硬件的预研周期,一款图形构架是不可能等到图形API出现之后才开始研发工作的。因此对于厂商来说,如果想定义一款构架所需要遵循的基本规则,要么厂商要自己对即将到来的API内容进行预判,要么通过与规则制定者的紧密合作来获取规则的第一手资料。虽然没有人只用一条腿走路,但在第一代DirectX 9硬件的研发过程中,NVIDIA很明显更倚重于前者,而ATI则明智的选择了后者。因此后续出现的NV30所支持的浮点精度均为IEEE754规定的FP16/32,而R300则紧贴微软的要求,刚好支持FP24这个并不存在于国际通行标准中的格式。
相信DirectX 9发布时的NVIDIA,心中一定是充满了疑惑、愤怒和不安的,因为他十分清楚接下来将要发生的事情。而像素处理单元战争故事中第一个高潮,也即将到来了。
小小寄存器+狂妄引发的大败
● 小小寄存器+狂妄引发的大败
业界很少有一款产品,能够像NV30这样在与对手的战争中输得如此的彻底。性能不佳,良率低下,价格昂贵,功耗巨大,甚至还得了个电吹风的头衔……对NV30的失败,很多事情都要出来负责,比如说低速的DDRII显存,过激的工艺,甚至还有微软“特异”的浮点精度。但这些都不是导致NV30失败的本质,如果你想明白NV30为何会如此惨败,以及这失败背后的真正含义,就要从NV30的Pixel Shader单元设计寻找答案。
享有电吹风“美誉”的Geforce FX 5800Ultra
NV30的Pixel Shader单元设计存在很多独特的特点,它并不具备Pixel Shader2.0中很常规的处理3D+1D以及co-issue的能力,如果遇到坐标变换等需要非绑定4D运算的场合,NV30将一筹莫展。与此同时,NV30的Pixel Shader单元还不具备mini ALU,shader core后面吊着的,是两个完全符合DirectX8.1要求的FX12 combine,由于Pixel Shader2.0并不支持混合精度以及非浮点精度指令,所以这两个FX12 combine单元在DirectX 9的场合中完全就是废物。尽管后续的NV35添加了2个可以吞吐FP16/32的mini ALU,但这两个mini ALU并非全功能,在大多数场合下都进能运行在simplified模式下,说白了,加了等于白加。
问题还没完,NV30不光运算单元设计成这样,寄存器方面也存在极大的问题,甚至可以说寄存器的设计失败才是最为致命的。整个NV3X构架的Temp Register被限定为13个,仅比Pixel Shader2.0所要求的12个的最低要求多1个。Register被分为2个bank,这2个bank加在一起每周期内只能向shader core输送一个FP32或者两个FP16数据,由此造成的延迟是异常巨大的。在此基础上,本来就不够多的Register还要被拿去做Output Buffer,或者说Register与Output Buffer使用了同一片存储区域,如果某个shader Program的数据需要调用2个FP32 Register或者4个FP16 Register,NV3X的整体渲染效率就会开始大幅下降,这种下降还会随着调用寄存器的增多而不断加剧,当FP32 Register调用达到5个时,整个流水线的像素填充率只能达到理论值的1/4。
NV30构架
NV30被设计成这样,那他的对手R300呢?完整的3D+1D shader core和3D+1D mini ALU,尽管这些ALU的精度仅支持FP24但却完全符合微软的要求。32个Temp Register也让它完全可以大声地嘲笑寄存器资源极度不足的NV30。我们在R300身上看到的是充满了流畅和简洁的数学美感,而在NV30身上,我们只能看到非常全面的缺点和失败……
究竟是什么原因导致了NV30采用如此不堪的设计呢?其实答案很简单——如果你把NV30看成一款具有优秀DirectX 8.1性能,同时兼顾DirectX 9.0性能的GPU,一切就都了然了。
仅采用FX12单元的NV30
前面我们提到了,Pixel Shader1.4那场争论向NVIDIA传达了一个错误的信号,让他误以为自己已经强大到可以左右市场并正确预判未来的一切。这虽然并没有直接导致NVIDIA与微软的交恶,但也让NVIDIA在与微软的后续合作中表现的远不如ATI积极。按照NVIDIA的设想,由于初代shader的成功,市场能够接受和消化的更新速度以及节奏,只能允许下一代API在尽可能保持传统版本特色的基础上做出些许改进。同时,微软既然在DirectX Next Preview中宣布了新的Shader Modle会引入浮点型数据,那么符合IEEE 754规定的FP16/32格式将很自然的成为微软的选择。于是,一款“保持传统版本特色”同时做出“些许改进”以便支持新版本特性的图形构架,就这样来到了我们面前。
充满了简洁美感的R300
反观ATI,收购了ArtX让ATI的图形设计迅速的成熟了起来,与微软的紧密合作也让他能够第一时间获得新版本DirectX的所有信息,这种合作的紧密最终甚至发展到了足以影响微软决策的地步——我们实在无法解释为何微软会冒巨大的风险,来选择使用一个并未被IEEE组织承认且本身有没有任何特别的好处的浮点数据精度,更无法解释这种精度在接下来的一次小升级中即被替换的结局。如果你无法接受这一切均来自ATI的影响的话,那就只有虚构一个更加强大的“外部势力”来进行干预了。
总之,像素处理单元的第一场真正的大战,也就是精度战,至此已经分出胜负了。在这场战斗中,NVIDIA所犯下的一系列错误并非来自研发实力的差异,他只是为自己那几年的狂妄或者说自我认知不足,以及对时局的把握不当付出了代价。
|