传统3D API存在的问题
DirectX因其丰富的功能和使用方便得到了广泛流行和长足发展，但这种API一直存在着一个重要问题--过高的CPU开销。在图形编程API出现之 前，3D应用程序需要直接操作图形硬件，虽然这种方式运行效率极高，但不同规格的硬件设备使通用化编码十分困难。随着3D图形市场的迅速发展，这种原始的运作方式被迅速淘汰。
DirectX和OpenGL这样的图形API扮演着应用程序和图形硬件的中间层角色。应用这种模型，应用程序使用通用的代码编写，API负责把程序代码 翻译成图形硬件能够理解的指令操作。这种模型大大降低了3D应用程序，诸如3D游戏等编写的难度。但这种模型也存在问题，就是DirectX这种API受到的每一个应用程序指令，都需要经过CPU的处理，判断是否是针对图形硬件的操作。这意味着所有的3D应用指令都会对CPU造成开销，这种开销给3D图形应用带来不利影响：它限制了一个场景内被渲染的对象数目和不同特效的种类。在第一种情况，因为每个绘图指令都造成一次API判断开销，只有一定数量的指令能够在下一个CPU运行周期前被执行，这直接限制了可以被绘 制的对象数目。为了改善这种状况，开发者们使用批量处理技术，把多个对象编成群组进行绘制，但是当被渲染的对象有材质区别时，批量处理技术也无能为力。
过高的API开销不止限制了图形渲染性能，它也限制了应用程序能达到的视觉复杂程度。除了绘图指令，状态改变指令也会造成明显的API运行 开销。这包括改变纹理、着色器、顶点格式以及混合模型。这些状态的改变是描述真实世界景象的重要一环，而没有这些，所有的对象表面看 起来都是一样的，毫无生气。状态改变指令需要通过API，也一样会带来CPU开销，糟糕的是状态改变操作要比对象绘制操作频繁的多，因为一 个绘制好的对象通常要根据环境变换出多种效果。正因为状态改变开销过高，开发者们都尽量避免多种纹理和特殊材质，结果就是3D游戏看起来并不真实。
DirectX 10全新架构，克服过高API运行开销
DirectX 10的主要设计目表之一就是显著的降低渲染时的CPU开销，它通过三种途径来解决问题。第一，完全重新设计的重新API核心关键性能 部分；第二，引进降低CPU依赖性的特性；第三，增加一个命令执行更多操作的功能。
新的运行层（Runtime）-- DirectX 10引入全新的运行层显著降低绘图指令和状态变化带来的开销。新的运行层经过重新设计来映射大多数相似的图形硬件，执行效率远远高于以前的版本。保持对老版本DirectX兼容的特性被移除，这减少了状态改变路径，使运行层更加简洁高效。为了支持这个新版的运行层，G80架构完全针对这种新的运行层设计，包括符合Windows Vista要求的新版驱动也对DirectX 10做了优化。
运行层提升性能的一项重要改变在对验证（validation）的处理。validation发生在绘图指令执行前，它的功能是确认应用程序发出的指令和 数据格式对于图形硬件的正确性，validation也维护数据的完整性，不个这个过程带来了显著的开销。在DirectX 10中，validation发生在对象创建后使用前。对象被创建一次，validation也只发生一次；而早先的DirectX 9中，对象的每次使用 都伴随着validation过程，显然DirectX 10节约了大量执行资源。
更少的CPU参与
DirectX进入了多项新特性大大降低CPU的参与程度，这些特性包括texture arrays、predicated draw和stream out。
通常来说多重纹理的切换会带来较高的状态改变开销，因此程序员总是把一些小尺寸纹理拼成一个较大纹理图集来避免简单使用一个多重纹理 。然而不管怎样，DirectX 9限制的最大纹理尺寸也只有4048*4048分辨率而已。DirectX 10提供了一重叫做texture arrays（纹理队列集）的功能，它能在每个队列够存储512个纹理。新的指令可以让着色程序动态的索引纹理队列，这些指令由GPU控制，因此CPU在多重纹理操作方面的重负被部分释放。
Predicated draw是另一种不需要CPU参与的特性。在典型的3D场景中，许多对象经常被其他对象完全遮盖，在这种情况下这些被遮盖对象的渲 染就是浪费了资源。高级GPU使用不同的硬件筛选方式来检查哪些像素在逻辑上是不可视的而不需渲染，但这种操作不是100%保证的，仍有很多 无效像素被渲染。为了进一部避免这种情况，Predicated draw技术被引入，它的方式是事先只对复杂的对象作初步简单处理，如果在最终输出 图像上这个对象被遮挡，那么简单处理过的对象将不会被完整渲染，这种技术也叫做occlusion query（遮蔽检查），之前的DirectX版本中都是由CPU和GPU共同处理，而在DirectX 10中则完全由GPU处理。
最后DirectX 10还引入了stream out技术来允许顶点或几何着色直接向图形内存中输出结果，这种方式明显比早先版本Direct X那种必须走过完整的像素着色管线的方式有效率，同时也降低了CPU在着色过程中的参与程度。
让每个指令更富效率
在DirectX 9中状态管理总是一件高开销的事务。这项任务重复的进行着纹理装载、常量和混合模型，这伴随着明显的CPU开销。但是DirectX 9不能批量进行这些操作，因此它带来很大程度的限制了渲染性能。DirectX 10新增了两种结构：State Objects（状态对象集）和Constant
Buffers（常量缓冲集），能够实现批量的普通操作一降低状态管理的开销。
在DirectX 10之前，状态管理使用较为粗放的方式，状态定义在管线的各个不同部分都存在着。比如在顶点着色器中，顶点缓冲结构定义者输 出的顶点格式；在输出合并中，混合状态决定着新的桢应用哪种混合方式。通常情况，状态定义着不同顶点和纹理的格式和在管线中的混合方 式。DirectX 9的状态管理模式中，程序在较低级别上管理，许多状态改变操作都需要重新配置管线，而DirectX 10使用了新的高级状态管理方 式State Objects来改善效率。DirectX 9中大量的不同状态在DirectX 10中被整合成5个状态对象集，它们是InputLayout (vertex buffer layout)、Sampler、Rasterizer、 DepthStencil和Blend。这些状态对象集描述着管线不同位置的基本属性。以此作为杠杆，以往需要大量命令实现的状态改变现在仅需一条指令即可完成，极大地降低了状态改变开销。
另一个被引入的特性是常量缓冲集。常量是所有着色程序中预先定义的参数，比如一个场景中的光源数目及亮度、色彩和位置都是被定义为常量。在游戏中常量经常需要受虚拟世界的改变而更新，因为需要改变的频率较高并且常量数目巨大，因此这种改变带来了较重的API开销。常量缓冲集则可最多容纳4096个常量存储在一个区内，这个区域可以被一个指令完成更新，批量的常量更新较以往的更新模式显著降低开销。
全新打造的DirectX 10通过更加贴近硬件特性的运行层设计、灵活的验证创建时间提供了更高的3D API性能；它还使用texture arrays、predicated draw和stream out明显减低CPU在图形处理中的参与频率；State Objects和Constant Buffers更帮助提升管线处理的效率。所有这些都帮助应用程序降低了DirectX API以往过高的开销。
