小小寄存器+狂妄引发的大败

　　业界很少有一款产品，能够像NV30这样在与对手的战争中输得如此的彻底。性能不佳，良率低下，价格昂贵，功耗巨大，甚至还得了个电吹风的头衔……对NV30的失败，很多事情都要出来负责，比如说低速的DDRII显存，过激的工艺，甚至还有微软“特异”的浮点精度。但这些都不是导致NV30失败的本质，如果你想明白NV30为何会如此惨败，以及这失败背后的真正含义，就要从NV30的Pixel Shader单元设计寻找答案。

　　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被设计成这样，那他的对手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格式将很自然的成为微软的选择。于是，一款“保持传统版本特色”同时做出“些许改进”以便支持新版本特性的图形构架，就这样来到了我们面前。

　　反观ATI，收购了ArtX让ATI的图形设计迅速的成熟了起来，与微软的紧密合作也让他能够第一时间获得新版本DirectX的所有信息，这种合作的紧密最终甚至发展到了足以影响微软决策的地步——我们实在无法解释为何微软会冒巨大的风险，来选择使用一个并未被IEEE组织承认且本身有没有任何特别的好处的浮点数据精度，更无法解释这种精度在接下来的一次小升级中即被替换的结局。如果你无法接受这一切均来自ATI的影响的话，那就只有虚构一个更加强大的“外部势力”来进行干预了。

　　总之，像素处理单元的第一场真正的大战，也就是精度战，至此已经分出胜负了。在这场战斗中，NVIDIA所犯下的一系列错误并非来自研发实力的差异，他只是为自己那几年的狂妄或者说自我认知不足，以及对时局的把握不当付出了代价。