IDirect3D10系统.docxVIP

摘要本文描述了第四代PC平台上图形图像单元（GPU）的系统构架。与上一代图形管道相比，新的管道有了重大改变，引入了一个新的可编程阶段（stage）用于生产额外的图元，并把图元流保存到内存中；扩展了所有可编程阶段的功能，涉及到顶点、图片内存资源，以及新的储存格式。此外，我们还描述了API、运行时以及实现新管道的着色语言的结构性改变。解决当前系统中的缺陷，是我们设计的基本思想。文章不但描述了重要设计抉择背后的原理，同时也描述了那些最终被否决的方案。1．前言过去10年，OpenGL和Direct3D所依赖的渲染管道构架已经取得了重大发展。最近5年中，随着从固定管道到可编程管道的过渡，发生了许多戏剧性的变化。虽然变化的进程很快，但每一步都反映出了设计者在通用性、性能以及成本上所做出的妥协。我们一直在努力了解以及构建一个系统，来解决许多程序中对图形加速器的需求（呈现图形、CAD、多媒体处理，等等）。但是，我们更想把注意力集中在交互式娱乐应用中。这些程序需要管理数十亿字节的艺术品，包括几何体、纹理、动画数据以及着色程序，占用大量系统资源（CPU、内存、带宽），以可交互的速率渲染丰富的、充满细节的图片。在处理海量数据的同时，保证渲染的灵活性，是对设计者的重大挑战之一。在系统设计的方方面面，都可以反映出我们对这个问题的解决方案。与上个版本的Direct3D一样，Direct3D 10同样是在应用程序开发者、硬件设计师以及API/运行时构架师三方的合作下设计的。在三年多的设计过程中，合作者之间详细的交流是无价的，让我们更深入了软硬件部署的代价，以及在大量不同硬件进行权衡。在开发Direct3D 10的过程中，调查显示应用程序开发者通常受以下限制的困扰，以及用来缓解这些问题的策略：1. 状态（state）改变的代价过高。 改变任何类型的状态（顶点格式、纹理、shader、shader参数、混合模式，等等）都会付出很大代价。优化方法通常是通过查询对象状态来排序，减少API状态改变次数；减少外观的改变；或者使用基于shader的技术，使用shader来决定状态。对于后者，例子之一就是把多张纹理打包为一张纹理地图（texture map）（也称为纹理地图集），通过纹理坐标变换，来索引相应的子纹理。2. 硬件加速器性能变化太多。 应用程序不得不编写一系列分支语句，以保证在不同硬件上都能正常运行。这些问题会影响到程序的特性设置，资源管理，算法精度，以及储存格式。3. CPU和GPU之间频繁的同步。传统的图形管道允许有限制的重新使用管道当前产生的数据，作为下一个处理步骤的输入数据。Render-to-texture就是这种机制的最好例子之一，所渲染的图片接下来能被当作纹理使用，最小化CPU的干涉。但是，产生新顶点数据，或者创建立方贴图就需要CPU与GPU进行更多的协调和通信，降低了效率。4. 指令以及数据类型的限制。通常都以精度和所支持的流程控制指令来衡量vertex shader，同样的方法也用来衡量pixel shader，但是，无论是pixel还是vertex shader都不支持整数指令。此外，出于对pixel shader精确性的要求，还指定了浮点算法。应用程序要么不使用这些额外的功能，要么模仿他们的使用。基于表格功能的计算就是例子之一。5. 资源限制。 纹理读取的次数、纹理范围、程序指令，等等，都受到限制。应用程序不得不压缩算法，或者把它们分为多个shader pass。因此，还出现了对自动划分shader程序的研究。2．背景我们的系统建立于PC，工作站以及游戏机平台上的应用程序可编程渲染管道。当前的图形管道分为两个编程阶段，一个用于处理顶点数据（vertex shader），一个用来处理像素或片断（fragment or pixel shader）。在Lindholm2001里描述了设计早期vertex shader的思想和折中。除了细小的差别以外，pixel shader也是按这样的轨迹来设计的。可以把顶点以及像素着色器的发展分为4代（包括Direct3D 10），如表一所示：通过挖掘顶点和像素片断之间的独立性，硬件管道实现了很高的处理吞吐量。大多数顶点和像素着色器都是以并行的状态来处理相互独立的顶点和像素片断。典型的硬件实现中pixel shader的数量要比vertex shader多很多，反映出典型的渲染过程中，像素处理的工作量要比顶点多很多。与vertex shader相比，这种特性将影响pixel shader的性能，因为pixel shader被过多的复制了。可编程管道直接使用了较低的抽象层，比如OpenGL或Direct3D。这些抽象层隐藏了不同硬件管道实现之间的差别，提供了一个方便的接口。对特定的平台来说，比如游戏机，它的硬件