【eNet硅谷动力专稿 未经授权，禁止转载 作者 Ben esT】
回想起微软大张旗鼓地宣扬DX10将为游戏体验带来种种革命性飞跃，似乎还是不久前的事情～～的确，虽然NVIDIA/AMD已经推出了数代支持DX10的产品，但DX10的诞辰至今仍不满两年。一方面NVIDIA祭起CUDA大旗，试图用Physx将AMD一举击杀；另一方面AMD则以DX10.1回击，极力抨击DX10的残废；就在AMD、NVIDIA还在Vista/DX10平台上栾战之时，不远处另一片新战场——Win7/DirectX 11已经呼之欲出！！
作为游戏玩家，我们总是期盼着3D画面能够模糊与现实之间的界限，而这个界限正在硬件性能与先进的技术等动力的推动下不断向前迈进，虚拟与现实间的差异正变得越来越模糊……而在超越硬件与天才创作人之外，还有另一股动力，那就是图形API！不同于CPU，GPU没有通用的指令集供软件工具直接调用，所以我们需要通过一个通用的接口来调用GPU的运算资源。通常GPU工程师们需要负责将应用程序编程接口（API）生成的代码转译为GPU能够辨别的代码，而作为游戏设计师与显卡的唯一沟通途径，API的重要性可见一斑，可以说API直接决定了游戏设计师能有多大的自由来运用硬件和创造3D世界中的一切。
API负责的主要工作包括对3D世界中的物体进行描述，然后将这些物体发送到GPU并指挥硬件对数据进行处理，这个逐步进行的过程就是所谓的渲染流水线。图形API管线分为若干个阶段，不同阶段负责的渲染工作也各异，下面就是对整个3D图形管线架构的概括：
首先是对定点数据进行处理（模型的位置、形状、大小等信息），然后模型将根据需要被进一步操作或重组，接着3D模型将被打散投射到荧幕上的2D像素上，这个过程就是所谓的光棚化；紧跟着这些2D像素还需要进行查找贴图信息或采用各种打光等技巧进行处理；最后但对像素的操作完成后再把它们输出到显示荧屏上。整个3D渲染流水线到此结束。DX10渲染管线
在过去的二十年里（感觉似乎不止20年对吧？），硬件设计师们一直在推动着两款主要API的发展，这两款API就是OpenGL跟DirectX。不过本文的重点将集中在DirectX身上，而原因就在于对于3D游戏领域而言，DirectX的普遍性已经远超OGL，个中的主要原因就是DirectX自身的升级发展速度远远超越OGL，它不断地为自身、为硬件带来更新的特性以及更加灵活的规范。而正是由于这一特性，每次DX的更新换代总是吸引着业界的目光，随着诞生的新特性也自然成为媒体、专家、玩友们津津乐道的话题。虽然目前我们还身处DX9、DX10交接过渡的时代，但是DX11已经开始浮出水面。
按照惯例，微软将根据相对应的硬件上市时间来调整DX11的发布时间，而且跟上代DX一样，DX11将与新一代的windows一起发布。在VISTA受到市场的广泛排斥后，微软对Win7寄予厚望，所以WIN7的发布势必卯足了劲要把所有新特性摆上台！有趣的是，从DX9到DX10的升级之路足足走了四年有多，而DX11在DX10诞生不过两年、DX9游戏依然主导的今天就匆忙出关，这在DX历史上实属罕见……
DX11:新pipeline，新特性
上面这张DX10的流水线结构图相信很多人都看过吧，当时可能谁也没有预料到DX10会失败到如厮地步～～DX10的失败原因一部分归咎于Vista独占、差劲的驱动支持、生不逢时；另一部分则是由于开发人员在运用新特性和配套开发工具等过程遇到诸多障碍。
邂逅DX11
邂逅DX11的第一眼，就已经让人感觉到她比胞兄DX10更酷更性感，除了一系列的增强改进让原本DX10那些很少有人问津的特性变得更加平易近人
外，流水线还新增了两项具有革命性意义的新“工序”：Tessellation（镶嵌单元，由hull shader、domain shader以tessellator组成）与Compute Shader。有这两项性特性，开发人员可以更加自由地发挥创造力，将进模糊虚拟与现实之间的界限。
除了两项新的流水线特性外，DX11更多地是对DX10的修整调节，所以严格来讲DX11是DX10.1的一个超集，有相当一部分DX10/10.1功能被完整地移植到了DX11身上，这也就意味着以后所有支持DX11的硬件必将完全符合DX10.1规范（目前只有AMD的GPU能够满足这一要求）。除此之外，DX11还将引入下列扩展：
虽然这些扩展不像pipeline的变化那样具有飞跃性，但却能够改善性能或简化各种复杂特效的开发难度。更高、更强、更多线！
虽然超线程概念已经存在了数十年，但大多数程序员还是直到近几年多核心CPU流行之后才开始关心程序的平行化，在此之前大部分通用代码都是简单的单线程，在这些代码里寻找并挖掘多线程化带来的性能提升是件费力不讨好的苦差。通常超线程能够带来多少性能提升完全取决于代码中有多少需要按序执行的步骤，这是再天才的程序员也无法改变的事实。而不幸的是，目前图形渲染中存在太多需要按序执行的任务，DX10在设计之初并没有为GPU的多线程化做考虑，虽然现在我们依然可以将渲染任务多线程化，但需要通过一些低效率的同步技巧或管理线程来保证整个渲染流水线能够有条不紊地工作，这些多余的开销不仅降低了多线程带来的性能提升，而且也增加了程序员的负担，所以程序员往往更倾向于把精力花在其他能够较为有效提升性能的地方。
尽管备受API的缺陷折磨，AMD/NVIDA的驱动小组依然不遗余力地提升驱动的平行化能力，只是一些受到CPU瓶颈限制的情况依然无法避免。好在微软终于在DX11中引入完整的多线程技术来解决这些麻烦，而更令人可喜的是，作为DX11子集的DX10/10.1同样可以享受多线程技术的待遇，AMD/NVIDA的驱动小组只需要将DX11的多线程技术引入他们的驱动中，就可以为DX10/10.1打开免费的多线程升级，当然由于缺失一部分DX11独有的特性，性能提升可能没有DX11硬件明显。
在DX11中，微软通过将目前单一执行的Direct 3D设备被分为三个独立的接口：设备（Device）、立即执行范畴（immediate Context）和延迟执行范畴（Deferred Context），这三者都被分发到各自独立的线程，而且设备和Deferred context还可以分配多个线程，负责将等待执行的任务发送给immediate Context或渲染线程。这样的设计可以将图形生成所需的资源做预先的存取。同时，CPU还可以利用显卡的多线程处理加快DirectX的处理，减少CPU的响应时间而使游戏不再受到CPU的瓶颈限制。
谈到Tessellation（镶嵌），这项技术在娱乐级领域的第一次上镜可以追溯到G400的发布会上，但相信很多人对它还比较陌生，因为曝光率较高的是Displacement mapping技术——Tessellation的杰作之一。但此后Tessellation虽然在不少新生GPU的特性列表上露过脸，但实际上真正硬件支持该技术的只有AMD的R6XX/R7XX GPU，因为这两款产品具备硬件Tessellator（硬件镶嵌单元）。多年来除了硬件支持的不足外，API没有将其纳入要求规范也是Tessellation一直得不到发展的主要因素，好在DX11终于将其收编入伍，并为渲染流水线新增一道可编程镶嵌处理的工序，这一次Tessellation的春天终于要到来了！
运用Tessellation（镶嵌拆分）的好处在于它首先对原始图象的各子块区域和图象库中的每一幅图象进行多尺度小波分解;然后逐层计算各图象小波分解系数的标准方差和它们之间的相似距离，并据此从图象库中选取与原始图象中的各子块区域最佳匹配的贴图，再将其镶嵌到原始图象中的对应区域。同时，根据人眼观察某个区域时往往通过取整或将细节取平均来得到一个总体强度效果这一视觉特性，使最终的镶嵌图象具有在近处看到的是各个贴图的内容，而在远处观看则是原始图象的总体轮廓的视觉效果。
一个原本高达12万多个三角型构建的模型，经过Tessellation的拆分后可缩减至只有840个，若经Tessellation技术后将可回复至 十万个三角型左右，但所占的VRAM Buffer Size却由先前的45MB下降至只有不到100K ，同时运算速度亦提升了2倍。再配合传统的LOD技术，即根据物体和玩家视角的距离运用Tessellation来动态调整物体的模型细节，那么效率可以进一步飞升。可想而知，一旦游戏开始运用Tessellation技术，画面的多边形细节将可以得到成倍增长！
引入Tessellation之所具有革命性飞跃，是因为镶嵌拆分功能赋予游戏设计师更自由的创作空间，让美工们可以“肆无忌惮”地绘制真实复杂的3D模型，而无需像过去那样因为内存消耗等性能问题而“畏首畏尾”。DirectX 11流水线中的Tessellation详解
DX11的管线为Tessellation这道新工序准备了三个部件：Tessellator、Hull shader以及Domain shader，比起AMD自己的解决方案，DX11的Tessellation要更加完善跟系统化，这也导致了R6XX/7XX的Tessellation功能跟DX11存在不兼容的问题。下面我们就来详细分析下三个部件是如何工作的：
首先Tessellator可以把一些粗模分解成小块，tessellator还可以将这些小块重新组合到一起，创建更加复杂、更加逼真的几何体；比如tessellator可以将一个立方体分解成小块然后再组合成一个球体，而个中的微妙之处还在于无需反复访问内存，节约资源的同时还能有效提升性能，由此全面提升画质、性能与开发效率。
接着Hull Shader将接收到的面片控制点（patches control point），经转换然后输出配置tessellator的数据。面片（patches）是诸如顶点/像素之类的新图原，用于定义面上需要被镶嵌的片段；而Control points则用来定义想需要绘制的图形形状（比如说是曲面还是平面）的变量参数。如果你熟悉Photoshop的话，不妨把Control points理解为PS的钢笔工具：用平面代替线的贝塞尔曲线功能。Hull Shader采用control points来控制tessellator对模型进行操作，并将转化好的片面控制点传送给Domain Shader。
tessellator只负责镶嵌拆分处理：它将Hull Shader传送过来的patch根据之前Hull Shader设置好的参量进行镶嵌拆分，然后再将计算得出的一系列点传送给Domain Shader，由后者组合成新模型。虽然程序员可以根据自己的需要来编写Hull Shader程序，但是镶嵌拆分部分完全由固定功能的tessellator来自动完成，所以tessellator就是一个根据参量来计算的固定功能模块。
最后Tessellator将生成的点传送给Domain Shader（下面简称DS），DS将根据控制点（control points）或置换贴图（displacement mapping，如果有的话）将这些点组合成程序员需要的几何模型。DS通过运行程序员编写的DS程序来执行这些操作，这些DS程序将根据control points或置换贴图的参数来控制这些新产生的点如何转移或坐标位移。每处理完一个点后，Domain Shader就会输出一个顶点，而这个顶点可以根据需要再进一步交由GS（几何shader）来处理，或通过流数据输出功能回到VS（顶点shader）进行处理。但通常情况下，大量的Domain Shader输出结果将直接进入光栅化阶段，几何模型将被拆散成屏幕上的像素进行PS（像素shader）处理。
很多游戏开发者都对DX11引入Compute Shader（下文简称为CS）特性刚到兴奋不已。CS的加盟让DX从原本图形为主的API开始走向通用化，DX11面世后我们就能够用它来进行一些通用计算了，CS还进一步扩充了DX API的操作类型跟操作数据种类。
其它渲染管线阶段，我们会看到原本一些加速图形渲染的设计会妨碍通用计算代码，尽管我们可以将通用计算算法硬塞进像素着色程序里，但是我们却不能随意利用诸如树形结构之类的数据结构，在像素和线程间共享数据不仅困难且开销很高，而且还必须想办法将绘制三角形和贴图映射等技巧套用到通用计算之中。
在DirectX11以及CS的帮助下，游戏开发人员便可以将这些烦人的数据结构扔给CS，可以用它来直接运行各种通用算法。与其他完整的可编程的DX10和DX11管线阶段一样，CS将其他类型的shader共享一套SP。
相应的硬件必须要比当代硬件更加灵活些，因为在运行CS代码的时候，硬件必须支持随机读写、不规则列阵（而不是简单的流体或者固定大小的2D列阵）、多重输出、可根据程序员的需要直接调用个别或多个线程、32k大小的共享寄存空间和线程组管理系统、粒数据指令集、同步建构以及可执行无序IO运算的能力。
与此同时，CS也将丢失一些特性，因为单个线程已经不再被看成是一个像素，所以线程将会丧失与几何图形的关联。这就意味着，尽管CS程序依然可以利用纹理取样功能，但是自动三线LOD计算将会丧失自动功能（LOD必须被指定）。此外，一些并不重要的普通数据的深度值剔除（depth culling）、抗锯齿（anti-aliasing）、alpha 混合以及其他运算不能在一个CS程序中被执行。
由CS带来的新型应用实际上是无限的，是取之不竭的，但首先对此感兴趣的是游戏开发商们们，他们正研究如何利用这一新增特性来为游戏引擎添加PS无法实现的高级特效～～其中，这些新型应用就包括A-Buffer (A缓存) 取样技术，该技术可以很大程度上增加抗锯齿以及无规则透明度的性能，可以带来更先进的Deferred Shading（延迟着色）技术、更先进后期处理效果（post processing effect）和卷积运算、以及更先进的专为频域运算的快速傅利叶转换(Fast Fourier Transform，FFT)以及区域求和表算法。
除了图形渲染外，游戏开发者可能同时也希望做一些诸如IK(inverse kinematics，逆运动学)、物理、人工智能以及其他在GPU上执行的传统的CPU任务之类的运算。用CS算法在GPU上执行这些数据意味着这些数据将可以更快供渲染计算使用，而且一些算法可能在GPU上的执行速度更快。此外诸如AI、物理等可以同时在CPU/GPU上进行运算的算法，可以通过CS交由GPU来处理以节省带宽资源。
随着shader特效越来越复杂，游戏开发者开始对shader的灵活性与弹性不足而头痛。举例来说吧，比如面对一个需要多种复杂shader混合来渲染的场景，程序员往往需要把多段shader写进一段长代码里，形成一个“超级shader”。这种处理方式虽然方便了开发过程，但弊端非常明显：一是shader过于复杂导致硬件性能下降，即所谓的优化差，低端硬件无法运行；一是不方便代码的除错检验；
为了解决这一问题，微软在DX11中带来解决之道。DX11提出shader子程序的概念，即允许程序员将各种小段、简单或为个别需要而特制的shader程序链接起来，再根据实际需要动态调用，这样既能够提高硬件兼容性，同时减少“巨型shader”对寄存器空间的占用，有效提升性能。
增强纹理压缩技术
微软已经很长很长一段时间没有更新DX的纹理压缩算法了，在业界人士的大力呼吁下，DX11终于在这方面有了新进展。DirectX 11加入了两种新的压缩算法——BC6和BC7。其中，BC6是专门针对HDR图像设计的压缩算法，压缩比为6：1；而BC7是专门为LDR（低动态范围）图像设计的压缩算法，压缩比为3：1。
上图展示的是图像通过BC6压缩模式进行压缩的前后效果对比图。其中左边的图像为原始图像，中间的是在压缩过程中损失的一些细节，而右边的就是压缩后的图像。可以看出，从画质上来看几乎没有损失（肉眼看不出），但是却可以大幅度降低显存的占用。
上图则是BC7针对LDR纹理的压缩与传统的BC3纹理压缩对比。可以看出传统的BC3纹理压缩损失了大量的纹理细节，压缩之后的效果也很不好。而采用BC7算法压缩后的纹理，丢失的细节很少，效果也非常好，这就是改进纹理压缩的魅力。
此外微软还要求DX11硬件的纹理解压必须完全按照DX11的API规范，此举意在敦促硬件厂商在DX11到来之前完善目前DX10的纹理压缩规范，以提高纹理质量。
虽然距离DX11正式版登场还有大约半年的时间，但作为DX10的超集以及WIN7的助阵，预计DX11的普及速度将远远超过DX10！目前有关NVIDIA、AMD下一代DX11硬件的“内幕”也不断曝光，由此可见双方在新一轮的军备竞赛是丝毫不敢怠慢，而作为一名玩家，就让我们拭目以待，做个精明的渔翁吧！
