Vulkan Command Buffers: Recording GPU Commands

Topic Overview

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.

Your Task

Model the Vulkan command buffer lifecycle and a slice of the validation layer. A command buffer is:

• allocated (INITIAL);
• recorded between vkBeginCommandBuffer and vkEndCommandBuffer (RECORDING → EXECUTABLE);
• submitted (PENDING until the GPU signals its fence);
• either reusable or, for one-time-submit buffers, INVALID after execution.

Destroying a resource it recorded also makes it INVALID. Commands have rules too: draws need a render pass, a pipeline and a vertex buffer, and transfers and plain barriers are forbidden inside a render pass.

Input

# starts a comment.

cCopy
Loading…

Rules

• Transitions print CB: OLD -> NEW. States: INITIAL, RECORDING, EXECUTABLE, PENDING, INVALID.
• begin: fails if RECORDING (CB is already recording) or PENDING (CB is pending execution and cannot be begun). From EXECUTABLE or INVALID it first prints CB: implicit reset. Beginning clears the recorded state.
• end: needs RECORDING and no open render pass (CB ends inside a render pass).
• reset: from any state except PENDING (CB is pending execution and cannot be reset). It goes to INITIAL.
• cmd (needs RECORDING: CB is not recording (STATE)); commands that pass their checks are counted:
  • beginRenderPass inside one: render pass already active in CB;
  • endRenderPass outside one: no active render pass in CB;
  • draw: draw outside a render pass, draw without a bound pipeline, draw without a bound vertex buffer (checked in that order);
  • copyBuffer inside a render pass: copyBuffer is not allowed inside a render pass;
  • pipelineBarrier inside a render pass: pipelineBarrier inside a render pass needs a subpass self-dependency;
  • using a destroyed buffer: buffer B has been destroyed;
  • buffers passed to bindVertexBuffer/copyBuffer are remembered as used by the CB.
• submit: needs EXECUTABLE, or PENDING with simultaneous use. Otherwise: CB is already pending (not simultaneous-use) or CB is STATE, not executable. At most 8 submissions can be in flight.
  • Print submitted CB: N command(s), D draw(s), fence F, then move to PENDING (if not already).
• wait F: every PENDING CB drops its submissions with fence F. When none remain, it becomes EXECUTABLE, or INVALID if it was begun with one-time. If nothing matched: wait F: no pending work on this fence.
• destroy B: refused while a PENDING CB uses it (buffer B is in use by a pending command buffer). Otherwise print buffer B destroyed, and every RECORDING or EXECUTABLE CB that used it becomes INVALID.
• state prints CB: STATE, N command(s) recorded[, one-time submit].

Output

Validation failures print validation error: MESSAGE and change nothing.

cCopy
Loading…

Other errors:

• alloc: CB [simultaneous], alloc X: name in use or pool full (8 max)
• begin: CB [one-time], submit: CB FENCE, wait: FENCE, destroy: BUFFER
• cmd: CB COMMAND [ARG], cmd: bindPipeline NAME, cmd: bindVertexBuffer BUFFER (or copyBuffer), cmd: unknown command X
• OP: unknown command buffer X, unknown operation X

Example

Input:

cCopy
Loading…

Output:

cCopy
Loading…

Requirements

1. Keep an explicit state per command buffer, and check it on every operation. Most Vulkan misuse is a state violation.
2. Track which resources each command buffer references, so destroying one can invalidate exactly the right command buffers.

Hidden tests cover draw-state errors in order, render-pass nesting, transfers and barriers inside a render pass, a simultaneous-use buffer submitted twice, a one-time buffer becoming invalid, destruction blocked while pending, invalidation by destruction, an implicit reset, and unknown names.