GPU-Driven Indirect Rendering: Building Draw Workloads on the Device

Move draw decisions close to scene data

GPU-driven indirect rendering lets compute work determine which draws or instances the graphics pipeline consumes. The CPU still prepares resources, selects compatible pipeline state and submits work. The useful change is that visibility decisions and draw parameters can remain on the device, avoiding a CPU readback before drawing. Khronos and Microsoft provide original examples of this arrangement. [1][2]

Two command-generation patterns

One approach reserves fixed command slots and sets an invisible draw's instance count to zero. Another compacts visible instance identifiers or draw commands into an output buffer and generates a count. Compaction adds bookkeeping but avoids processing empty entries. Group commands by the state that the chosen indirect mechanism can share; an arbitrary material or pipeline change is not automatically encoded by an ordinary draw command. [1][2]

Worked example: capacity follows the candidate set

Suppose an illustrative scene has 10000 candidate instances. A visible-identifier buffer using 4 bytes per identifier needs 40000 bytes, about 39.1 KiB, if every candidate may become visible. This excludes commands, counters and alignment.

If this frame exposes 3500 instances, compute writes those identifiers and the appropriate draw counts. Allocating for only 3500 because that was yesterday's maximum is unsafe. Preventing an out-of-bounds write by dropping later entries still loses geometry. Reserve the required capacity, process bounded chunks or provide a complete fallback. These are capacity calculations, not performance measurements.

Build and validate the pipeline

Start with CPU visibility results as a reference. Compare visible identifiers and final images before adding occlusion or multiple material groups. Check command layout, index offsets, base vertices, instance lookup and counter resets. Exercise empty visibility, full visibility and the capacity boundary.

Make compute writes available to indirect-command reads and to every shader stage consuming generated instance data. A dependency covering indirect arguments alone does not cover unrelated shader reads. Separate queues also require appropriate inter-queue synchronization and any required ownership transfer. Khronos documents the relevant producer and consumer access patterns. [3]

Keep resources alive and avoid overwriting a buffer still used by an earlier frame. Inspect a GPU capture for the produced counts and the commands actually executed.

Evaluate total frame cost

Measure CPU submission time alongside GPU culling, compaction and rendering. Extra compute and memory traffic can outweigh reduced submission overhead, particularly in small scenes. Indirect drawing does not remove expensive shading, solve transparency ordering or guarantee efficient material grouping. Check device features and command-count limits, and retain a supported fallback. Adopt the design when measured frame behavior justifies its complexity.

Sources

• [1] GPU Rendering and Multi-Draw Indirect — Khronos Group, Vulkan Samples.
• [2] Indirect drawing and GPU culling — Microsoft, Direct3D documentation and sample.
• [3] Synchronization Examples — Khronos Group, Vulkan documentation.