初时，将AMD诱入到重重迷雾中的，其实是强盛所带来的自负。

　　从Shader结构上来看，DirectX 9.0C为止的Shader Modle 3.0代码基本上都维持了规整的4D形态，即便很多像素的改动和操作并不需要触及全部的RGBA，尽管存在挣脱这种编程格式束缚的需求，但当时的程序员们确实习惯了根据微软设置的限制或者说“保护”，来对所有的Shader代码进行最彻底的几何关联。4D指令虽然灵活度欠佳，但却可以方便当时的硬件进行吞吐，而且因为结构本身以及Shader Modle 3.0编程特色，吞吐量在当时几乎可以等效为当时硬件的Shader性能。在这种环境下，被AMD收购之前的ATI推出的R580很自然的以其强劲的吞吐能力而获得了渴望获得性能的用户和业者的一片好评和赞誉。

强调浮点吞吐，拥有“3:1构架”的R580

　　AMD在CPU界可谓久经沙场，但在当时还只能算是个图形界新丁。接收了ATI的AMD看到了R580与DirectX 9.0C需求的高契合度，同时也注意到了DirectX 9.0C的广受欢迎以及顽强生命力，再加上长期以来由Athlon64所积累的自负，这些要素都让AMD产生了一个极其危险的错觉——尽管还不知道全新的DirectX 10以及微软未来对图形操作方式的发展方向，但以AMD的影响力，是完全可以影响程序员的编程习惯和需求导向的，所以只需要按照自己的预测或者说期待去制作硬件，只要做的出来就应该不用愁卖不动。

　　于是，以ILP需求为基础的R600，用一块叫VLIW的糖果，非常轻松的便将AMD诱入了一片深重的迷雾当中……

漫长迷茫的开始——R600构架

　　R600最大的特点，在于依旧以DirectX 9.0C的Shader Programs或者说浮点指令吞吐量为设计基准，我们甚至可以认为它是一颗仅仅对DirectX 10进行了寄存器及特性需求支持的DirectX 9.0C显卡。VLIW（Very long instruction word，超长字节指令）结构的ALU团簇以及编程需求是R600的灵魂，如果指令之间能够完全无关并且以超长字节的形式进行打包，那么R600将会发挥出令人生畏浮点吞吐能力。而如果程序端真正做到了AMD期待的强烈的ILP倾向，那图形构架根本就不需要太多的线程仲裁机制以及缓冲资源，只需要不停地规律的吞吐即可。所以R600也不具备优势性的线程管理机制以及Shared等缓冲资源。

　　这世界上的万事万物都是平衡的，当你能够从某个事物中获得好处时，你必定会为此支付相应的代价。我们在先前的多篇文章中都曾经介绍过，VLIW能够带来极高的吞吐能力提升，但代价便是指令的无关性以及单元复用率的负担。事实上现实中的指令，无论是图形还是通用计算方面的，在绝大多数情况下都不可能做到VLIW要求的无关性。进入到以1D及分支逐渐增多的DirectX 10以及通用计算环境之后，R600及其之后的衍生物构架所面临的常见的场景，往往是一个VLIW中包含着两个甚至更多存在条件关联的指令，以前条指令结果作为初始条件的后条指令需要付出更多的周期来等待前条指令的执行完毕，而更多的周期，则被浪费在了这种等待以及相关的打包/解包过程之中。

VLIW吞吐模式

　　没错，在等待这样一个非运算活动的时间里，以微观的眼光来看，相当多的运算单元实际上是处在闲置状态的。