Vulkan Command Buffers: Recording GPU Commands

Recording Commands, Not Executing Them

In Vulkan and D3D12, the CPU records commands into command buffers and submits them for GPU execution later. This decoupling lets the CPU prepare multiple frames ahead while the GPU works on previously submitted buffers.

A typical command sequence:

1. Begin render pass (framebuffer, clears, viewport)
2. Bind pipeline (shaders + fixed-function state)
3. Bind vertex/index buffers
4. Bind descriptor sets (textures, uniforms)
5. Draw (indexed or non-indexed)
6. End render pass
7. Pipeline barriers (memory/execution dependencies)

Pools, Secondary Buffers, and Sync

Command buffers come from command pools tied to queue families (graphics, compute, transfer). Secondary command buffers record independently and execute from a primary buffer, enabling multi-threaded recording. Unreal's Vulkan RHI uses this to parallelize CPU-side rendering.

cCopy
Loading…

For example, a frame might record once and resubmit every frame if the scene is static, amortizing CPU overhead. Semaphores synchronize queue submissions (image available -> render -> present). Fences signal CPU-GPU completion. Pipeline barriers enforce memory visibility within a buffer.

For This Exercise

You will simulate a command buffer as an array of typed commands and demonstrate record-then-submit ordering. This task asks you to append commands and print the sequence. Command buffer reuse is why Vulkan renderers issue far more draw calls per frame than OpenGL could manage.