摘要

　　 本文描述了第四代PC平台上图形图像单元(GPU)的系统构架。与上一代图形管道相比，新的管道有了重大改变，引入了一个新的可编程阶段(stage)用于生产额外的图元，并把图元流保存到内存中;扩展了所有可编程阶段的功能，涉及到顶点、图片内存资源，以及新的储存格式。此外，我们还描述了API、运行时以及实现新管道的着色语言的结构性改变。解决当前系统中的缺陷，是我们设计的基本思想。文章不但描述了重要设计抉择背后的原理，同时也描述了那些最终被否决的方案。

前言

　　 过去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程序的研究。

背景

　　 我们的系统建立于PC，工作站以及游戏机平台上的应用程序可编程渲染管道。当前的图形管道分为两个编程阶段，一个用于处理顶点数据(vertex shader)，一个用来处理像素或片断(fragment or pixel shader)。在Lindholm2001里描述了设计早期vertex shader的思想和折中。除了细小的差别以外，pixel shader也是按这样的轨迹来设计的。

　　 通过挖掘顶点和像素片断之间的独立性，硬件管道实现了很高的处理吞吐量。大多数顶点和像素着色器都是以并行的状态来处理相互独立的顶点和像素片断。典型的硬件实现中pixel shader的数量要比vertex shader多很多，反映出典型的渲染过程中，像素处理的工作量要比顶点多很多。与vertex shader相比，这种特性将影响pixel shader的性能，因为pixel shader被过多的复制了。

　　 可编程管道直接使用了较低的抽象层，比如OpenGL或Direct3D。这些抽象层隐藏了不同硬件管道实现之间的差别，提供了一个方便的接口。对特定的平台来说，比如游戏机，它的硬件管道与PC平台相比是不同的，底层细节也是由这些抽象层来暴露。

　　 我们把这些抽象层称为运行时(runtime)，并且通过它所提供的API对他进行控制。运行时为设备提供了独立的资源管理(分配内存，控制生存期，初始化，虚拟技术，等等)，所有纹理贴图，顶点缓冲，状态改变以及和硬件加速器的通信都通过特定设备的驱动程序来完成。对可变成管道来说，运行时还加入了对照色程序的抽象和管理任务。

　　 由于早期可编程处理器对指令储存空间的限制，为了在有限资源内，最大化对硬件的控制，不得不使用类似于汇编的语言来编写照色程序。但是，随着硬件功能的增加，需要一种高级的编程抽象来提高程序员的生产力。一种与C类似，并且添加了对潜在渲染管道进行定制的编程语言满足了这种需求。此外，还发展出了一些其他的语言，利用浮点处理器和GPU内存带宽来完成渲染以外的一些计算，但是，我们不打算在这篇文章里对这些应用进行讨论。

　　 虽然新的编程语言有必要与CPU编程语言(特别是C)类似，但我们还是进行了一些重要的修饰。举例来说，硬件结构和编译模型更像是一台虚拟机，汇编着色语言扮演了独立于硬件的中间语言(IL)，而不是特定的机器语言。在离线环境下，Microsoft HLSL之类的高级语言被编译为IL，在程序运行时，通过驱动程序内建的翻译器，实时转换为目标硬件的指令。需要注意的是，OpenGL shading language使用了一种不同的方法来完成运行时的编译过程。

　　 另一个重要的区别是，着色程序并不是孤立的程序，通过一个运行在CPU上的程序来协调渲染管道，它们通常是共同(in concert)执行的。 此外CPU程序还以纹理或填充寄存器常量的方式，为着色程序提供参数。

　　 虽然本文没有具体描述特定硬件新图形管道的构架，但图形管道的设计很大程度上都是根据硬件实用性以及多硬件并行处理来设计的。此外，当前硬件实现的结构体系也将延续或者影响我们的设计。