gdc2024囫囵吞枣 GPU Work Graphs: Welcome to the Future of GPU Programming

GPU Work Graphs: Welcome to the Future of GPU Programming 解析

GPU Work Graphs通过引入细粒度任务同步、优化中间数据传输及提供Debug工具支持，解决了传统DX12 ExecuteIndirect在并行度、内存分配和空执行方面的痛点，为GPU编程提供了更高效、灵活的框架。

一、Dx12 ExecuteIndirect的痛点

顺序执行与依赖关系缺失
ExecuteIndirect本质上是顺序执行模型，无法显式表达任务间的依赖关系。例如，在GPU驱动的渲染管线中，裁剪（culling）后的间接调度（indirect dispatch/draw）可能导致大量空执行（empty execution）。若同一材质的所有物体均被裁剪，则生成的draw调用index数为0，但DX11/DX12（无Mesh Shader）需在CPU端编码draw指令，无法优化此类空操作。
空执行与性能浪费
在GPU驱动的渲染中，若物体被裁剪后仍触发空draw调用，会导致GPU资源浪费。例如，未使用Mesh Shader时，draw指令由CPU生成，无法跳过空操作，影响整体效率。
内存分配的局限性
ExecuteIndirect需预先分配最坏情况（worst case）内存。例如，存储可见三角形索引（triangle index）的UAV（Unordered Access View）需按最大可能值分配空间，导致内存利用率低下，甚至在某些场景下成为性能瓶颈。

细粒度任务同步
Work Graph通过定义任务（job）间的局部同步，替代传统API的全局屏障（barrier）。例如，在GPU驱动的渲染中，不同网格部分（mesh part）的裁剪与绘制可并行执行，无需等待全局裁剪完成。这显著提升了GPU并行度，减少了空闲周期。
图：传统全局屏障（左）与Work Graph局部同步（右）对比
中间数据传输优化
内存分配：Work Graph支持分批启动任务，仅需分配较小的临时缓冲区（temporary buffer），而非按最坏情况预留内存。例如，可见三角形索引可动态分配，避免UAV写入GPU内存的开销。
数据流向控制：中间数据可能无需通过UAV传递，进一步减少内存带宽占用。
Debug工具支持
Work Graph明确定义了任务图（graph）结构，使Debug工具（如RenderDoc）更易追踪任务执行流程。然而，目前RenderDoc对Work Graph的完整支持尚未明确。

1. API层面

2. Shader层面

节点化编程：通过标记（markup）将函数定义为图中的节点（node）。示例代码可参考微软官方Sample：
DirectX-Graphics-Samples/WorkGraphsSandbox
节点启动方式：
Broadcast：全屏Pass式启动。
Coarseasing：自动批处理任务。
Thread：1x1x1尺寸的批处理，逐个启动任务。
图结构限制：
单向无环图（Acyclic）：默认不允许循环依赖，但支持节点递归调用（递归深度最多32层）。
通用程序（Generic Program）：统一定义PSO（Pipeline State Object），包括着色器（shader）、混合状态（blend state）、光栅化状态（rasterizer state）等，支持通过名称匹配变体（variant），兼容光线追踪（raytracing）、顶点着色器（VS）、像素着色器（PS）等。

3. 硬件支持与实用性

GPU Work Graphs通过重构任务调度模型，解决了传统DX12 ExecuteIndirect在并行性、内存效率和空执行方面的核心问题。其细粒度同步、动态内存分配和图式编程接口，为GPU编程提供了更灵活、高效的框架，尤其适用于GPU驱动的渲染等复杂场景。