【显卡知识】谁是微软忠实随从 A/N统一架构历史回顾

吸血大魔王

前言：

       生活在这个时代是幸福的。我们每天都在享受科技进步所带来的各种便利，欣喜若狂和眼花缭乱交替支配着每个人的神经。作为一名家用电脑的使用者，这种感受也许会更加明显和直接。我们面前的屏幕从一个圆乎乎的墨绿色小窗发展成了今天的20寸甚至30寸的大号LCD，上面所显示的画面也从一个个挪动的白色方块慢慢演变成了几乎可以以假乱真的连贯画面。这一切变化的背后，都是GPU及图形业界孜孜不倦的探索和努力的功劳。

       从G80开始算起，统一图形构架出现到现在已经5年时间了。从DirectX 10到DirectX 11，图形发展史上从来没有哪个5年能够像这5年一样让人欢呼雀跃的同时失望不已。这期间图形业界以及我们的生活中究竟发生了什么？又是什么让雀跃和失望这两种情绪同时影响着人们？值此统一构架问世5年之际，CBS探索与发现节目将以三期专题的形式，带您回顾这段奇异同时充满了灿烂火花的岁月，并且展示这段岁月光鲜外表下的真实。

---

      
● 完美版本的DirectX

       其实不管创造或者使用了多么玄乎的算法啊概念啊操作啊之类的东西，图形界的发展方向始终都还是很单纯的，那就是视觉虚拟现实。视觉虚拟现实是什么？视觉虚拟现实就是以数学的方式构建一个可以被硬件执行的函数集合，这个函数集合包含了组成被渲染目标一切可视信息，通过对这个集合的演算以及操作，最终将无限接近现实中形状和色彩表现的图像输出到输出装置中去。

       但是受限于运算能力和算法的限制，这个看似简单的目标长久以来一直像是一个几乎无法达到的目的地。单纯的视觉刺激也许会激发科学家或者程序员一时的研究兴致，但要向着这个目标持续并坚定的前进，光有兴趣是不行的，还必须有动力。

你能分辨视觉虚拟现实和真实的区别么？

       我们应该感到庆幸，图形业界不全是科学家和程序员，这里还有商人。

吸血大魔王

       游戏不仅仅是人类，甚至是动物生存过程中重要的组成部分，动物们透过游戏来学习各种生存技巧，而对于人类而言游戏的意义已经远远超出了学习生存技巧的范畴，这导致了PC引入图形娱乐手段之后所带来的大量有待开发的商业价值。有了价值，就有了商人；有了商人，就有了利益；有了利益，一个行业的发展也就有了动力。       现在利用这个价值来推动行业发展的商人，就是微软。

微软的通用API：DirectX

       虽然微软未必是一个被所有人所喜欢的企业，但在这层意义上，我们不得不感谢它。作为泛用性底层API，DirectX是微软在图形界当家的根本。凭借微软自身强大的影响力以及其对图形编程领域的认知，每一代的DirectX 都会为娱乐图形编程界引进诸多先进的理念、控制方法和算法。从多重材质到T&L，从Shader programe到Unified Shader，在DirectX的影响下，整个光栅化过程正在以更加高效的方式表现着越来越接近真实的实时演算图像效果，并最终坚定地向着视觉虚拟现实这个图形界最终目标不断的前进。
       今天微软在这个话题中为我们提供的素材，是从DirectX 9.0C开始的。

DirectX 9.0C显示效果

       整个DirectX发展史的关键节点有两个，一个是DirectX 7中T&L的引入，一个是DirectX 8中shader的引入。T&L的引入第一次将显卡从一个单纯的打印机变成了有主动操作功能的图形处理器，而shader的引入则将运算能力这个无限可能的大门放置在了显卡面前，透过运算能力，人们终于可以准确并且实时的操作纹理上像素的色彩，并最终透过正确的色彩表达正确的效果了。不过这两个划时代的API都无法与DirectX 9.0C进行比较，因为直到DirectX 9.0C，光栅化的一切特效才得以最终实现。

吸血大魔王

● 来之不易的“一切图形特效”

       诚然，“实现一切特效”这句话已经被喊出过很多次了，shader引进的DirectX 8时代就曾经有人断言，只要有足够的耐心，Shader Model1.0/Shader Model1.4足以实现任何特效，后来人们发现由于精度问题，数据的上下溢等根本就无法解决，所谓的“一切特效”到最后变成了“一切错误的特效”；后来DirectX 9出现之后精度问题解决了，又有人断言Shader Model2.0可以实现任何特效了，结果发现由于缺乏跳转、条件分支等操作以及对指令长度的限制，人们得到的最终结果依旧是不正确的；最后，在多次更新之后，微软终于在DirectX 9.0C上实现了“一切特效”这个理想。

直到DirectX 9.0C之后才最终正确的图形效果

       在DirectX 9.0C中，MS第一次将之前版本的DirectX 中所遗留的问题一次性彻底解决了，它将Vertex Shader和Pixel Shader的最大指令数提升至65535，引入了动态程序流控制，将分支和跳转能力彻底开放给了程序员，允许顶点单元直接进行纹理操作（Vertex Texture），同时通过多目标渲染（MRT）和延迟渲染（Deferred Shading）等创造性的技术保证了光栅化过程中整个流水线的整体效率。
       通俗的说，DirectX 9.0C已经解决了ALU利用率和效率之外的几乎一切问题了，往后版本的DirectX 在光栅化过程中的其他改进，尤其是后端过程的改进基本上都可以在DirectX 9.0C中找到影子或者前身，甚至可以说只是简单的放大和补完而已。
       对程序员来说，DirectX 9.0C比先前的所有版本DirectX 都更让他们近乎于不受约束的尽情堆砌指令来实现越来越接近于现实的色彩和特效，并且不用担心这些色彩和特效会出现致命性的错误。再加上硬件厂商的跟进，DirectX 9.0C成了DirectX 史上支持度最高的版本。它是如此的完美和成功，以至于我们无需多言它的种种事迹，单看几乎是照抄规则的OPEN GL 2.0即可窥见一斑了。

吸血大魔王

● 呼唤统一构架的到来       尽管DirectX 9.0C堪称完美，但它的完美本身从出发点上就存在局限。它对shader部分的补充虽然非常必要并且具有划时代的意义，对后端的本质性改进更是至今都未见超越，但DirectX 9.0C忽略了一个很致命的问题——shader单元的动作效率问题。
       传统的shader单元是分立的，根据不同的需要被分成了独立的Vertex shader单元和Pixel shader单元，两组单元各司其职，分别处理不同的shader programs。表面上看专门的用特定单元运行唯一对应代码的对应式设计似乎可以达到简单高效的目的，但在实际应用中反倒出现了效率低下的问题。

不同单元在负载方面的效率问题

       假定一段shader programs中仅包含10%的Vertex Shader指令，剩下的90%都是Pixel Shader指令，那么当重载的Pixel shader单元全力动作的时候Vertex shader单元实际上是处在欠载状态的。这种情况反之亦然。一段实际的shader program是不可能完全做到50:50的指令平衡设计的，再加上指令的串行吞吐特性，程序员无论如何都不可能做到指令密度的平均化。因此我们不难发现，实际应用中根据传统的API设计出来的硬件经常会出现大面积的负载不平衡的现象。虽然硬件设计者为了应对这一问题，在硬件设计之初就已经为两个单元固定了一个比例，但这实际上反倒帮了倒忙，程序员不得不尽可能的迁就固定比例硬件的效率，从而限制了他们自由发挥的空间。
       既然程序端不可能解决这个问题，如何让全部的运算单元都能够在理论上达到最高效的运作模式就成了摆在新一代API面前的最大问题。
       威武的商人为我们带来的解决方案很直接也很划时代——把他们统一起来。

吸血大魔王

● 统一构架DirectX 10       所谓统一，指的是将Vertex Shader和Pixel Shader单元合并成一个具有完整执行能力的US（Unified Shader）单元，指令可以直接面向底层的ALU而非过去的特定单元，所以在硬件层面US可以同时吞吐一切shader指令，同时并不会对指令进行任何的修改，也不会对shader program的编写模式提出任何的强迫性的改变要求。以这个简单但是直接的手段为核心，微软推出了全新的API——DirectX 10。遵循DirectX 10规范设计的硬件在理论上可以达到100%的shader效率。

高效率的shader所带来的效果

       统一构架由此开始……
       ● 第一代统一构架硬件
       DirectX 10的出现有很多积极地意义，它标志着微软正式开始将注意力转向了shader效率而非功能的增强方面。 shader效率的提升可以提高对应设计的运算单元的整体运作效率，效率的提升则可以折算成最终幁数的提升。幁数达到一定的程度比如60甚至100之后便没有了意义，因为肉眼已经无法分辨更高幁数的区别，所以提升的效率又可以被拿来进行更加复杂和灵活的操作。可以说从DirectX 10开始，微软正式进入了提倡以效率换效果的时代。
       效率换效果有很多种手段，其中之一便是指令格式的改变。

新指令格式shader实例：GS

       传统的DirectX 9硬件中的shader格式是非常固定的，Vertex Shader指令天生就是4D（X,Y,Z,A），而因为硬件单元设计通常都是3D+1D 结构的缘故，Pixel Shader指令一般情况下也会写成4D。这种情况导致了DirectX 9环境下的Pixel Shader指令无论属于何种应用，哪怕仅包含一条Z-buffer或者一条texture load，也要在指令结构上找齐成4D格式。这种格式的刻板要求极大的限制了程序员对shader尤其是Pixel Shader的发挥。

传统shader指令结构

       我们前面提到过，DirectX 10不会对shader program的编写模式提出任何的强迫性的改变要求。但是因为US直接面向ALU的特点，程序员面前的可用资源不再是一个个带有条条框框的固定功能单元，而是更加底层的运算单元。这使得DirectX 10环境下编程中的程序员可以大胆的直接使用更加灵活的1D、2D指令以及各种算数函数，而不用担心任何来自硬件方面的限制。我们甚至认为衡量一款游戏是否属于DirectX 10游戏并不是看它是否使用了US，而是看它是否大量使用了1D、2D指令以及算数函数。更加灵活的shader让程序员在无限接近实现视觉虚拟现实的道路上又向前前进了一大步。

更加灵活的shader所带来的细腻效果

       我们说过，生活在这个时代真幸福。
       微软在API层面提出了要求，硬件厂商就要跟进，于是第一代满足统一构架要求的DirectX 10硬件应运而生。

吸血大魔王

● 第一代统一构架硬件分析之G80       2006年11月，NVIDIA发布了业界第一款DirectX 10构架的GPU——G80。
       G80由一套完整的包含仲裁资源的几何处理单元，与之相连的8个SM阵列，6组TA和6组ROP单元组成，整个构架以高速crossbar总线直连。

8800GTX显卡

       作为第一代DirectX 10硬件，G80的SM阵列设计最为值得关注，他是US的直接执行场所。MIMD结构的SM阵列由16个全功能的1D ALU单元和16K的shared memory组成，每个1D ALU或者说SP单元都具备独立的发射端口资源，同时均可以访问全部的shared资源，每组shared资源都配备了充足的bank，每组SP访问任意位置的shared都可以获得等于寄存器的速度。
       这个SM结构的设计可以说完整的契合了DirectX 10的硬件要求。他为US操作提供了充足的发射端资源，保障了指令进出的效率，同时每一个运算单元都有充足的shared资源用于缓冲，构架对编译器和指令关联性依赖极小，每个SP都可以在条件允许的情况下实现理论上的0延迟衔接操作。整个运算部分强调TLP性能，同时也能对应重组的纹理资源和后端资源，在整个光栅化的过程中，除了超重载的连续4D吞吐等极为个别的场合外，该构架均可以保持充足的效率并且没有明显的短板存在。

G80构架图

       值得注意的是从G80开始，NVIDIA将传统的TMU单元拆分成了两个独立的部分——TA和TF，其中TF单元被放置在SM之内以方便直接将ALU运算之后的像素进行fillrate，而TA单元则放置在L2 Texture cache旁边方便快速查找和抓取纹理。这种设计在今后NVIDIA新构架的设计，尤其是GF100的设计中起到了关键作用。

吸血大魔王

● 第一代统一构架硬件分析之R600       2007年5月，AMD收购ATI之后推出的第一款DirectX 10 GPU—R600正式发布了。
       R600由一套几何处理单元，独立的线程仲裁器UTDP，与仲裁机构相连的SPU和TMU单元，以及完整的后端所组成。整个构架以ringbus换装总线进行连接。

R600构架图

       与G80相比，R600的结构可以说是完全不同的两种设计思路。他的运算部分采用4个非全功能1D ALU和1个全功能4D ALU以VLIW的形式打包组成一个VLIW core。5个ALU共享2套发射端口资源，全部64个VLIW core共享8K的GDS，也就是NVIDIA方面的shared memory。

上报SGI的R600正式构架

       不难发现，R600构架为每一个ALU配备的缓存和发射端资源都非常的少。与此同时，由于其特殊的US结构，R600对编译器的要求极高。R600要求编译器和程序都进行充足的并行度优化，既要找齐4个1D和1个4D指令同时打包，还要保证这些指令之间完全没有关联性，不存在分支嵌套关系，否则将无法发挥最大的效率。另外，由于发射端资源的不足，所有经过VLIW打包的指令都必须在US单元的全部寄存器中跑过一边之后才能同时离开。这种结构下一旦指令的进出不仅不便，而且一旦VLIW包中的指令间存在条件分支关系，则必须等全部指令一起从单元中出来之后在进行重新打包以及进入。对于传统的DirectX 9C领域这种近乎于纯4D吞吐的场合来说，这个条件倒是很好满足，但对于新的DirectX 10来说，这种要求几乎直接限制了shader的灵活度。
       R600的另一个显著问题在于其过高的粒度尺寸，相对于对手32Thread/warp的粒度尺寸来说明显会带来更大的延迟问题。
       R600构架的目的或者说初衷之一，就是通过ATI长久以来对图形编程业界的影响力，将自己认为更加合适的追求吞吐和ILP性能的保守的编程模式推广下去。压迫程序员并迫使其遵从由ATI制定的被认为是适宜的编程方法以及API转换路线。当时的实践证明，这一尝试是失败的。

吸血大魔王

● 第一代统一构架硬件综述       通过前面的分析，我们不难发现双方在第一代统一构架硬件开发过程中的异同。无论G80还是R600，他们都严格遵从了微软的要求配备了可以完整执行任何种类shader的US单元。但是在细节方面，双方的开发理念则明显显示出了巨大的差异。确切的说，是激进和保守的差异。
       G80的MIMD构架倾向于强调TLP性能，其所强调的方向是更加灵活的线程能力、更加高效和灵活的shader能力，在绝对吞吐能力以及纹理能力方面则作出了妥协。这种设计在保证传统的DirectX 9性能以及面向更加先进的DirectX 10环境的选择中明显更倾向于后者。而R600的SIMD构架则更加强调ILP性能，充足的后端资源、强大的单位周期吞吐和相对匮乏的ALU周边资源让他看上去更像是一个面向DirectX 9的“DirectX 10兼容”产品。

TLP与ILP在应用方面的差异

       第一代统一构架的硬件大战，毫无疑问的以AMD的全线告负而收场。上次出现这种完完全全一边倒的局面还是NV30 VS R300的时代。R600失败的原因其实并不复杂——这款硬件作为一款DirectX 10硬件仅符合了支持US和大数量线程能力这两个最基本的要求，距离API所希望的硬件环境相差太远，执行效率过于低下。

       而作为一款DirectX 9的硬件，他的后端资源被过多地投注在了公共汽车一般的ringbus总线和过于巨大的MC上，导致本来可以被用来强化传统需求的晶体管资源被白白的浪费掉了，最终无论是传统需求还是新兴需求，R600都无法提供很好的满足条件。而G80则刚好相反，NVIDIA在G80上表达了几乎是爆棚的自信和对未来极为准确的预判能力，同时在汲取了NV30惨败的经验教训之后，紧跟微软走这个大方向再也没有脱离过NVIDIA的战略目标。在G80身上我们几乎看到了当年R300的全部优点——成熟，简洁，高效，贴近需求和实际。

       既然胜负已分，日子总还是要继续过下去的，所以第一回合就这样结束了。

吸血大魔王

● 第二代统一构架硬件       图形业界有着自己的规律，每次API的重大更新版本都会对应两代产品。厂商需要通过第一代产品的表现来全面评估自己对API的理解和掌控能力，以及这些理解和掌控反映到市场上的结果。根据这些结果去调整和完善自己的构架，借以推出第二代性能更加强劲的产品。

R600的tick版本：RV670芯片

G80的tick版本：G92芯片

       无论NVIDIA还是AMD，双方都在竞争中不断的审视着自己以及对方，对产品的调整也一直都在进行着。期间出现过的G92和RV670就是这种调整的产物。但是相对而言他们都只是新工艺的应用以及对上一代构架的微调，虽然有着其独特的意义，但并不能算是真正的构架更替。双方都在酝酿，不断的检讨和修正自己的构架路线以及市场环境和需求的变化，积蓄着自己的力量。
       终于，在第一代统一构架出现一年半之后，我们看到了经过真正的调整、完善和放大增强之后的第二代统一构架硬件——GT200和RV770。

吸血大魔王

● 第二代统一构架硬件分析之GT200构架分析       GT200在结构上与G80具有一定的传承性。他们的前端构造基本一致，运算单元内部结构如SP单元和shared等也都没有发生本质的改变。整体来讲两者之间大部分的区别来自于规模的增长。

GT200构架图

       当然，大部分结构一致并不代表两者的构架就是一致的。GT200相对于G80最为巨大的改进在于添加了atomic单元以及SIMT特性。
       atomic单元的添加使得GT200具备了原子操作的能力，透过原子操作，硬粒化之后的线程操作管理将更加有序和具体，这也就意味着像素或者其他类型如通用计算应用的Thread的生成、仲裁、泵送、内存位置确定和执行过程都将变得更加精确和高效，atomic单元和原子操作的引入也为未来NVIDIA构架最终实现并行化设计起到了关键的先导作用。
       SIMT特性的引入则可以使得程序员在进行指令搭建的过程中无需考虑GPU究竟是SIMD还是MIMD，从而将性能优化的方向专注于shader的拆分，合并，灵活搭配以及Thread管理方面。

GT200与G80的异同

       相对于G80，GT200可以说保持了针对DirectX 10的全部优点。特别是在shader编写和执行领域，GT200由于原子操作和SIMT特性的引入而变得更加高效和灵活。

吸血大魔王

● 第二代统一构架硬件分析之RV770构架分析       RV770在AMD的图形构架史上是一个极其重要的存在。
       在经历了R600系列的失败之后，AMD通过RV670的tick过程修正为R600构架去除了大量的低效率的晶体管，如过于臃肿的MC部分以及缓慢的ringbus总线。这些举措都为RV770节约了大量的晶体管资源。

R700构架图

       利用这些晶体管资源，RV770成功的将运算资源提升至R600的250%。尽管RV770的VLIW core结构本身没有发生任何变化，但是core外围资源发生了相当大的变化，除了将原本的GDS扩容至16K之外，AMD还为RV770引入了16K的LDS，以及与之搭配的独特的面向驱动和程序开放的使用机制。这增加了构架的总shared资源，改善了VLIW core的可用缓存及延迟情况。尽管整体可用缓存的密度依旧处在一个比较低落的水平上，但综合来看这些努力确实在一定程度上提升了整个体系在应对复杂和灵活shader应用时的效率。
       除此之外，AMD还成功的利用这些晶体管资源完善了RV770的纹理处理能力，大幅扩展了纹理单元的规模，重新调整了纹理资源和运算资源的比例并改善了其操作模式，并在后端首次引入了RBE单元，其在后端应用尤其是采样及抗锯齿等领域的表现令人印象颇为深刻。
       最后，为了进一步改善构架的外部及存储延迟问题，AMD为RV770搭配了当时成熟度并不是很高的大带宽GDDR5内存。

吸血大魔王

●第二代统一构架硬件综述       经过了第一轮较量，双方再一次回到了相对公平的起跑线上。无论G80/G92还是R600/RV670都可以被看作是一个完美的tick-tock过程，NVIDIA通过第一代统一构架积累了丰富的面向DirectX 10的硬件设计经验，并根据其直接面向ALU的理念创造性的将流计算向前迈进了一步，直接使用ALU进行通用计算的CUDA体系成了今天NVIDIA的重要卖点和未来发展方向。AMD亦通过一次完美的tick-tock过程修正了R600上很多非常致命的错误和缺陷，成功完成了构架瘦身，为未来的新构架打下了良好的基础。机会对双方来说都是均等的了。
       在经历了漫长的等待之后，我们终于看到了第二代统一构架的硬件，相对于第一代有些一边倒式的乏味格局，第二代统一构架可以说是一场灿烂的对撞。

GT200与RV770的对决

       首先是NVIDIA的GT200，GT200最大限度的利用了DirectX 10在shader上的开放性和灵活性。他是第一个尝试以通用计算性能来阐释和对应图形性能的构架。在NVIDIA的眼中，符合DirectX 10要求的ALU可以被用来执行任何的shader指令，那么用它来实现符合shader格式要求的通用计算指令是一个很好的应用方向，更加强劲的通用计算性能势必需要更加灵活和高效的ALU单元，而更加灵活和高效的ALU单元在执行DirectX 10所要求的更加灵活和自由的shader指令时效率也绝对不会差，这也是NVIDIA自身对微软推出DirectX 10的目的理解。GT200的出现标志着NVIDIA对DirectX 10意义和应用手段，甚至是未来发展方向的理解正式走向了完美和成熟。
       而AMD这边的RV770一样让人激动不已，激增的运算能力，激增的纹理性能，激增的后端规模，激增的显存带宽，同时还有没有跟着一起激增的优秀的功耗。无论从哪一个角度来看，RV770都是一款极为成功的产品。相对于R600，RV770上反映了AMD极大的野心，希望通过最平衡的资源搭配和极端完美的后端应用在实际应用中压制对手高效构架的野心，希望将对手拖入极端消耗技术积累的工艺战的野心，希望通过对软件环境的影响力为自己争取最大利益的野心，甚至是妄图以SIMD巨大的吞吐直接压制延迟的野心。

希望将对手拖入工艺战的RV770

       尽管双方在第二代统一构架中的表现都可圈可点，但这并不代表双方的第二代统一构架就都是完美的。实际上不论是NVIDIA还是AMD，大家都有着自己不得不面对的甚至可以说是性命攸关的危险。

吸血大魔王

● GT200和RV770面对的问题       首先是GT200。作为史上第一款晶体管突破十亿的单芯片，GT200为了灵活的ALU单元付出了惨重的代价。要让自己的MIMD体系能够高效率的运作，CORE外围的周边资源，比如寄存器、发射端口、shared、MC以及线程仲裁和分配资源等等都要十分充足。在可用晶体管上限的限制下，来自周边辅助资源的沉重压力迫使NVIDIA不得不在TA（Texture Arroy）和ROP等后端领域做出了大量妥协。
       尽管NVIDIA为GT200配置了全新设计的极为高效的后端体系。但其绝对数量以及与运算资源之间的比例最终还是处在了一个相对较低的水平上。与此同时，为了在纯吞吐领域不被对手甩开太远导致传统的以吞吐为主的应用场合被对手反超，NVIDIA将其复杂的运算单元的总规模逼近了半导体工艺所能够承受的最大极限。这直接导致了GT200芯片面积和功耗的激增。

GT200与RV770尺寸对比

       RV770这边的日子也未见得好过。如果紧追对手的脚步重新设计自己的构架以达到贴近API所要求的灵活高效的目的，那么RV670上AMD所做的一切努力都将化为乌有。而如果要维持现有构架不变，要想让这个低资源密度的高延迟构架去应对日益灵活的应用需求就必须寻找出路。释放SIMD的规模，靠极高的吞吐来压迫延迟是一个很好的选择，但能够压制延迟的吞吐规模所带来的晶体管要求一样会导致AMD不断地迫近半导体工艺所能够达到的极限，太过贴近极限显然无法让AMD达成将对手拖入漫长的高消耗的工艺战中的目的。
       与此同时，降低延迟的另一个有效手段——显存带宽的大幅提升在当时前景也并不明朗，GDDR5的带宽虽然作为维持规模和延迟平衡的重要组成部分发挥了卓越的功效，但以当时的眼光来看GDDR5的产能能否跟上需求还不得而知，AMD不得不为了构架而进行一场极为危险的赌博。

RV770所使用的奇梦达GDDR5显存颗粒

       尽管双方精彩的背后都有着种种危险或者说不安定的因素存在，但好在大家都是幸运的，GDDR5没有成为限制RV770的脚踝，而NVIDIA也终于在经历了阵痛之后通过更新的工艺提供了稳定的GT200系列产品。
       第二代统一构架之战，可以说是史上最完美的一场对决，双方都是出了自己的看家本领，甚至连AMD的赌博都赌的异常漂亮而且赢满全场。最终，AMD通过近乎完美的修复以及重新平衡之后的构架收复了大量失地。而NVIDIA也通过更加符合技术方向的构架设计积累了无比宝贵的经验和财富。
       连输家都没有，完美无瑕，无懈可击，你完全不知道这种局面是怎么造成的……

吸血大魔王

● 将效率进行到底       DirectX 10所带来的统一构架既然是为了强调效率而生的，那么对其改进的方向显然也要继续集中在效率上。这就是威武的商人微软对图形业界发展方向的理解。DirectX 10通过统一shader和直接面向ALU的更加灵活的shader提升了整个shader过程的效率，那么接下来还有什么办法可以进一步提升图形处理的效率呢？答案是——并行度和shader的多样性。相对于DirectX 10目的单纯简洁的开放底层ALU，DirectX 11的改进无论是复杂度还是针对性方面都明显高于前辈。

       ● 强调“花样”的DirectX 11
       以编程的角度来说，不管一个像素的颜色和信息多么的复杂，它所对应的shader program都可以构成一个线程（Thread）。实际画面中的像素是各有不同而且相互影响的，像素彼此之间的相互关系以及程序格式又可以使得构成他们的Thread组合成一个kernel。Thread的复杂度不同，优先级不同，处理的前后顺序以及所占用的处理资源也各有不同。平衡好Thread以及kernel的效率显然有利于整个图形流水线面对任务时的整体效率。

Thread与kernel的关系

       传统的API环境下，Thread和kernel是完全串行吞吐的，kernel会被事先排成队列，依次通过线程仲裁结构被泵送到整个运算部分的外围，然后被解离成一个个的Thread供运算单元去执行。一整个kernel中所有的Thread都被执行完毕并且离开寄存器之后，下一个kernel才会进入运算部分。这种完全串行的运作方式显然不利于ALU动作效率的提升。当然，微软很早就意识到了这个问题，但在运算能力和shader单元利用率这两个极大地问题没有被解决之前，由Thread和kernel串行吞吐所导致的效率缺陷还不足以成为决定性的或者说最短的短板要素。
       既然DirectX 10已经把注意力转向了shader单元的效率问题并且成功的解决了这个短板，再加上第二代统一构架所能够提供的纯运算能力已经开始将Thread和kernel的效率问题凸现出来，微软决定透过一次API版本的升级开始进行解决问题的努力。
       这就是DirectX 11的并行kernel和多线程渲染能力。

串行与并行kernel

       微软在前期倒是也已经为Thread和kernel的处理打下了一定的基础，比如在DirectX 9中引入跳转功能，在DirectX 10中引入类似超线程的设计等。这些手段的主要目的并非实现并行化处理，而且其背后所带来的线程管理手段也比较原始，如果由他们来实现并行化，其所导致的问题会远远大于并行化所带来的效率提升。
       所以在DirectX 11中，微软引入了immediate Context（立即执行部分）和Deferred Context（延迟执行部分）这两个概念，将不同优先级的Thread和kernel分别对应到不同的执行部分，两个部分分别管理自己的Thread和kernel，并在需要的时候将不同的kernel合并成一个并行的队列，在正确的时刻将他们同时输送到不同的空闲可用ALU团簇甚至ALU中去。借以达到运算密度最大化的目的。
       有了并行kernel，接下来的Compute Shader的出现就显得更加顺理成章了。

吸血大魔王

● 打破常规的Compute Shader       自从DirectX 10对底层ALU的开放之后，怎样让shader变得更加灵活就一直是业界孜孜不倦的探索的重要方向。尽管开放式的指令环境使得其灵活度达到了一个前所未有的高度，但图形指令本身毕竟存在着诸多限制，比如无法使用树结构，所有指令都必须严格套用汇至三角形和贴图映射的格式来完成，串行线程模式使得像素线程间的数据共享也极为困难而且开销极大等等。简单地说，传统格式的shader已经无法满足业界更加灵活和高效的需求了。在微软看来，是时候改变一下这种局面了。
       解决这个问题的方法，就是Computer Shader。

Compute Shader的树状结构

       因为并行kernel的出现，线程之间的数据共享可以通过Deferred Context和重组的缓存空间来完美的解决，与此同时，如果硬件支持非可预期延迟的随机读写，比如引入cache体系，程序员可以通过Compute Shader更好的管理多个并行的Thread和甚至kernel。虽然Compute Shader打破了shader指令与几何之间的必然联系并因此丢失了一些便利的功能如自动对应LOD等，所有涉及Z值的操作比如阴面隐去（HSR）类操作和常规抗锯齿采样等功能也将受到影响，但透过引入Compute Shader所带来的实际应用中的可能性近乎是无限的。它意味着程序员真正的全方位掌握了像素及其所对应的Thread，他可以任意的为它们添加复杂的交互关系而不用担心分支和数据共享方面出现延迟过于巨大的问题。
       Compute Shader这种以Thread而不是以像素和几何为出发点的改变同时也意味着海量光源应用以及光线追踪成为可能。另外，Compute Shader可以实现很多传统的Pixel Shader根本无法实现的高级特效，比如透过A-buffer采样来增加边缘无规则透明度的性能，通俗来讲，就是景深特效DOF（Depth of field ）。
       让我们再次重复那句话吧：能生活在这个时代真的很幸福啊。

吸血大魔王

● 第三代统一构架硬件       除了并行kernel和Compute Shader之外，DirectX 11还对core内部的寄存器总量进行了提升，这也是支持Compute Shader所必须的前提条件之一。另外在几何处理阶段，DirectX 也引入了TS这个概念。因此，硬件只有在寄存器达到规定要求，支持多线程管理并且具备TS单元之后才可以被认为符合DirectX 11的要求。
       又经历了1年多之后，我们终于见到了第三代统一构架硬件——GF100和RV870。
       ● GF100构架分析
       GPU史上从来没有哪一个构架能够如此接近CPU，甚至是并行多核CPU的程度。GF100是第一个。
       纵观GF100构架，最值得注意的部分包括首次引入GPU构架的多级cache结构，分为两级的线程分配管理体系，并行式的GPC单元设计，增大的shared memory以及彻底融入运算部分的TS单元。

GF100芯片照片

       多级cache的引入不仅使得运算单元可以享受CPU才能够享有的包含一致性的高速缓冲平台，为整个体系提供了真正联通本地显存和寄存器的直接双向读写手段，其可编程的操作方式更可以令其在要求透明延迟的shared和应对寄存器溢出的cache、甚至是texture cache之间自由转化，灵活的应对不同的传统场合和新的DirectX 11中关于Compute Shader部分的需求。
       GF100构架除了在体系最外围配备了充足的线程仲裁资源意外，每个SM内部也都配备了完整的分派式多线程管理单元。多级的线程分派机制可以保证kernel在不同的GPC内被解离成Thread之后依旧能够让ALU团簇在第一时间得到任务。
       之前在G80上出现并且一直持续至今的融入SM的分离式Texture Arroy设计在GF100上产生了重大的影响。GF100体系分成四个对等并且完全并行的GPC单元，每个GPC单元都包含独立的几何引擎以及光栅化流水线，GPC模块之间透过新加入的L2 cache进行通讯、kernel和Thread的协调以及数据共享。这不仅使得GF100的三角形吞吐能力较之同规模的旧结构提升了300%，可以实现并行的分块化的渲染动作，更使得DirectX 11所要求的TS单元直接融入到了整个光栅化流水线内部。

GF100构架图

       在特性方面，除了完全符合DirectX 11关于Compute Shader和并行kernel所要求的硬件环境之外，GF100还支持分支论断和基于CTA（线程块）级别的乱序执行，这使得GF100的整体Thread效率得到了进一步的显著提升。
       当然，由于NV自GT200一来对通用计算市场的规划和态度，GF100中包含着规模庞大的DP单元，在特性上也支持了虽然同样划时代但仅对C++体系有巨大意义的统一定址体系。这部分晶体管的沉重负担不仅对图形过程毫无助益，甚至直接导致了NVIDIA不得不再次在纹理和后端作出了妥协，削减了纹理资源与运算资源的比例。这也是无法被抹杀的事实。

吸血大魔王

● 第三代统一构架硬件分析之RV870构架分析       相对于更晚问世的GF100，RV870比前一代统一构架的改进要小很多。
       在RV870中，AMD仅为其配备了合乎DirectX 11要求的寄存器资源，改进了UTDP对多线程的支持，在前端的几何单元中插入了一组TS单元，同时将运算单元中的GDS提升到了64K。除此之外，我们仅能见到进一步放大的VLIW core规模和其他配套的纹理资源及后端资源。
       各资源的整体比例较之RV770并未发生本质性的改变，VLIW core的操作管理方式及周边资源密度也未见任何实质性的变化，甚至其UTDP单元也依旧维持着抢占式多线程的管理方式。

RV870构架图

       在面对传统应用环境时，该构架可以保持RV770的运行效率，同时受益于工艺的提升，其温度和功耗表现较之背负了沉重的晶体管负担的GF100要优异许多。但在面对DirectX 11 API的场合，该构架只能说乏善可陈。

吸血大魔王

● 第三代统一构架硬件综述       微软自DirectX 10开始不断地向业界强调着效率的重要性，通过DirectX 11的改进我们更加明确的认识到只有效率才是符合微软要求以及其所规划的图形技术发展路线的重中之重。功能单元效率，shader效率，ALU效率，甚至kernel和Thread效率，这些强调都会被当做硬件设计者的指导思想予以贯彻。但是在第三代统一构架硬件中，我们看到的却并不都是这种贯彻的结果。
       作为长期战略的延续和忠实执行者，GF100的到来充分表明了NVIDIA的态度——紧跟微软的脚步，第一时间推出符合其API要求的硬件，借以达到在其API环境下最高的图形执行效率。在GF100中，我们看到了具有划时代意义的多级cache体系，完全针对执行效率而生的多级线程管理和仲裁机制，对应并行kernel和多线程渲染的并行GPC结构，基于CTA（线程块）级别的分支论断和乱序执行功能等等。这些功能对DirectX 11的灵魂——Compute Shader和并行kernel都助益匪浅。虽然GF100构架还包含了大规模的DP单元以及统一定址这类与现阶段图形API关系不大的设计，并且继续为由此导致的晶体管规模问题付出了不小的代价，但是整体来讲GF100依旧是一个极为贴近API要求的硬件构架。我们在GF100身上依旧看得到高效、高针对性、贴近需求的理念。

GF100与RV870的运算单元细部差异

       反观RV870，单纯以构架和DirectX 11针对性的角度出发，我发现只能用“堆砌”和“凑活”这两个词来形容。外挂在整个核心最外围的单一的UTDP，好像是用钉子和胶水贴在setup之后的TS单元，不论操作方式还是比例甚至是绝对大小都没有变化的shared设计，结构完全没有任何改进仅仅是单纯翻倍的运算单元，还有跟着一起放大的纹理和后端部分……在RV870的身上我没有看到任何改进或者锐意进取的痕迹，除了做出了最基本的一些补完之后，在shader的灵活度和通用计算领域终于达到了对手上代的GT200的水准，另外在功耗和发热端表现突出之外，这个几乎可以说仅能做到“支持DirectX 11”而已的构架完全没有任何值得称道的地方。这竟然是AMD放弃了一次tick过程所推出的应对重大API升级的构架，对于当前API的第一代产品来说几乎就是一场灾难。我甚至想说服自己认为这款构架根本就不是AMD的全新构架，他只是RV770的一次tick过程而已。
       以构架设计来看，RV870已经不能用失败来形容了，他甚至连失败的资格都不具备。与对手GF100相比，他的整个核心构架甚至不如对手一个SM设计的复杂精巧，这意味着两者的设计根本就没有处在一个水平上。不论NV30和R300还是R600和G80的对决都不曾出现过这种代差级别的落后。

RV870不变的运算单元设计

       但是，第三次统一构架之战的结局显然不是RV870的惨败，不仅没有惨败，甚至从某种意义上来讲，连失败都没有发生。双方所处的格局最终与GT200对RV770时代没有多少变化，依旧是在实际游戏测试中互有胜负，NVIDIA透过更好的构架设计取得了单芯方面的胜利，而AMD则通过多芯互联方案取得了单卡性能的桂冠。NVIDIA继续透过设计积累着自己对图形业界发展的认识并不断的拓展新的领域，而AMD则仍旧不时得对NVIDIA的市占率发起冲击并博得玩家的好评声浪。
       其实这个问题早在第二次统一构架之战的时候就已经显现出来了——当时GT200在实际游戏测试中并没有对RV770取得对应构架设计程度的领先。
       为什么一款贴近API需求的构架在实际的游戏测试中，甚至是最新的最贴近要求的DirectX 版本游戏中仍旧无法取得性能优势呢？
       统一构架的5年间游戏界以及我们周围的生活都发生了哪些变化呢？
       在随后两期的CBS探索与发现节目中我们将会为大家继续揭晓答案。