根据 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 受益更大。
