在过去的10年中，OpenGL与Direct3D的渲染管道模型都已经取得了重大的进展，自2002年的DirectX 9.0到DirectX 9.0c便是管道模型从固定管道到可编程管道的过渡。这之间每一步的变化都反映出设计者通用性、性能和成本上所做出的妥协。

　　Intel的G965图形芯片便是这种妥协的最好诠释之一，其先进的内部硬件设计中有许多可编程的渲染元件，但在那之外还不得不保留了许多专用的处理单元。

　　GPU与CPU在计算范畴的最大区别在于有绪计算以及无绪计算，在有绪计算中GPU得以与强大的浮点计算能力超越CPU，依靠OpenGL与Direct3D这些中间件图形应用程序的编写可以拜托直接对图形硬件寄存器的访问，把这个过程通过API交由OpenGL与Direct3D这些中间件来完成，不过解析运行这些中间件却是由CPU来完成，换句话说不过GPU运行的指令诠释是由CPU来完成的，而随着GPU处理能力的飞速发展，CPU的指令诠释速度越来越跟不上GPU发展的步伐。这些问题在GeForce 7系列、Radeon X1K系列等最新的图形GPU中表现的尤为明显。因此，把CPU从GPU指令解析中解脱出来，把更多的工作交由GPU独立完成便是近年图形显示领域最关注的话题。

　　与之前的Direct3D版本一样，Direct3D 10同样是由应用程序开发者、硬件设计师以及API/架构师三方合作下设计的，旨在解决目前图形编程所遭遇的一些限制，创造出缓和这些问题的解决方案：

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

[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] 下一页