命令处理器 (CP)
命令处理器 (CP)
命令处理器 (CP)
根据 ATI 的说法，R600 系列的命令处理器 (CP) 是颗完整的处理器。倒不是说它可与 X86 处理器相提并论，而是它是个完整的微码处理器。它可以完整存取内存、可以执行数学运算并拥有自己的思考能力。理论上而言，这代表它可以下载微码来执行真正的指令类型，以分担驱动程序的工作。
CP 会解析驱动程序送来的命令汇流，并执行与命令汇流相关的思考。然后它会同步化芯片内的某些组件，甚至是验证部命令汇流。部分管线的设计即可执行部分验证工作，例如弄清楚目前处于什么转译模式中。
Demers 表示：「整个芯片的设计在于从驱动程序身上减轻这项工作负担」。「在过去，驱动程序 (即使是 500 系列) 通常是先检查，然后说：程序要求设定这些任务，但某些任务却互相冲突。
如果资源与状态有冲突，驱动程序可以关闭并思考下一步怎么做。你必须记住的是驱动程序是在 CPU 上执行。驱动程序思考方式的先天问题在于它是窃取原可以执行其它更有价值的任务的 CPU 周期。ATI 宣称已移转几乎所有相关工作－或更重要的所有验证工作－交给硬件处理。
命令处理器负责不少这项工作，而这款芯片相当具「自知力」，设计架构允许它可以到处窥探，以检查硬件的其它部分在干什么。举例来说，Z 缓冲会检查像素着色器正在做什么。它想要看看是否可以及早杀掉像素。如果资源可以知道目前发生的事，就可以切换到可以完成任务的最兼容模式。
利用这种行为类型的改良技术也可解释游戏机在特定应用上比 PC 来得快的原因。 PC 总是在检查应用程序的状态，但这个动作牵涉到许多资源负担 (overhead)。如果应用程序要求一个绘制 (draw) 指令以相关状态传送，微软的执行期程序 (runtime) 会检查它的一部分，驱动程序也会，然后它就必须全部验证，最后传送到硬件。ATI 觉得这个资源负担太大，因此尽可能将之移转到硬件中。
这是个通常称为小批次 (small batch) 的问题。 微软的 David Blythe 评论过，应用程序要求的错误沟通、不同的处理风格及 API 与硬件之间的不符合，是开发人员最大的怨言所在。 他的结论指出，他的分析「未能显示保留剩余状态时细部改变的任何重大优势，所以我们收集细部状态到称为状态对象 (state object) 到较大、相关、不变的汇总 (aggregate)中。它的优势在于可建立状态应该与不应该独立的明确模型，并降低大幅重新组态管线所需的 API 呼叫数。这个模型较符合我们观察应用程序使用 API 的方式。」降低绘制呼叫数、设定常数与其它命令，使 DX10 又重拾了这些资源负担。
硬件进展的进一步降低，也有助 CPU 的驱动程序资源负担之降低。ATI 指出，资源负担可能「高达 30%。」 这倒不是说应用程序的执行会快上 30%，而是说 CPU 的驱动程序常见的资源负担将可降低。视应用程序而定，CPU 使用率可能低到 1% 或高达 10-15%，平均上这个数字应该在 5-7% 之间，但 30% 的降低可解读为 CPU 降低数 % 的负载变化。虽然这并非较高画面率的终极目标，但却是正确方向上的一步。这对现有 DX9 应用程序也有好处，而 DX10 是从小批次友善的角度设计，所以就 CPU 负载降低的观点而言，DX10 比 DX9 受益更大。
