关于D3D12Bundles示例中索引实例化的性能与API等效性问题

问题一 #

你的推测有误，StartInstanceLocation的作用是指定实例ID的起始值，而非按InstanceIndex*StartInstanceLocation计算偏移。实例化绘制时，GPU会为每个实例分配一个递增的实例ID，范围是[StartInstanceLocation, StartInstanceLocation + InstanceCount - 1]。基于这个逻辑，两组调用并不等效：

DrawIndexedInstanced 对比 #

• 单调用：DrawIndexedInstanced(100, 2, 0, 0, 100) 会绘制2个实例，实例ID分别为100、101，每个实例使用100个索引，起始索引偏移0，基础顶点偏移0。
• 双调用：分别绘制实例ID为0和100的两个实例，实例ID范围完全不同，绘制结果不一致。

DrawInstanced 对比 #

逻辑与上述一致：

• 单调用：DrawInstanced(100, 2, 0, 100) 绘制实例ID为100、101的两个实例，每个实例使用100个顶点，起始顶点偏移0。
• 双调用：绘制实例ID为0和100的两个实例，实例范围不匹配，结果也不一致。

问题二 #

这个示例的性能提升核心来自D3D12 Bundle（命令捆绑包）的特性，而非传统的实例化批处理：

• 预验证与预编译：Bundle会提前验证内部命令的合法性，并将命令转换为GPU更易执行的紧凑格式。即便每次循环切换PSO和CBV，GPU执行Bundle时无需重复解析验证命令，减少运行时开销。
• CPU提交优化：将循环内的SetPipelineState、SetGraphicsRootDescriptorTable、Draw序列打包成Bundle后，CPU可以批量提交多个Bundle，而非逐条提交单条Draw命令，大幅降低CPU到GPU的命令提交延迟。
• GPU调度效率：Bundle的结构化命令让GPU调度器能更高效地处理命令流，减少命令解析的额外开销——哪怕存在频繁PSO切换，整体执行效率也比逐条提交命令更高。

注：示例的循环写法是为了演示Bundle的适配场景，实际项目中若能减少PSO切换，性能会进一步提升，但Bundle本身已对这类重复命令序列做了针对性优化。

内容的提问来源于stack exchange，提问作者Tom Huntington