Execution Model

GPU work begins on the CPU: the application creates resources, records commands that use them, and submits those commands to a queue. Submission allows the CPU to continue while the GPU executes the work. The resources must remain available until that execution finishes.

Graphics context

A GraphicsContext connects the application to a GPU device through a particular backend and provides its graphics, compute, and transfer queues. Resources used together must belong to the same context; buffers, textures, shaders, pipelines, and their handles cannot be bound across contexts.

Capabilities reports the device name and supported features. Use RayTracingSupported and MeshShadingSupported to check support before creating the resources for those workloads. The ray tracing and mesh shading samples show these checks during initialization.

Queue selection

GraphicsQueue is the usual starting point for a frame that combines drawing, computation, and copies. Keeping dependent operations on one queue simplifies their ordering.

Separate queues allow independent workloads to be submitted separately, but they do not necessarily correspond to independent hardware engines. Use additional queues when the work can benefit from overlapping execution. When one queue uses data produced by another, connect their submissions with an explicit dependency.

Within a queue, dependent operations can also require barriers or texture transitions so that later accesses observe earlier writes. These memory dependencies are distinct from submission order; Synchronization explains how to express them.

Recording and submission

queue.CommandBuffer() returns a CommandBuffer with recording already in progress. After recording the operations and their dependencies, call Submit() once. Submission ends recording and returns a TimelineValue that identifies the completion point on that queue.

After recording a frame in commandBuffer, the triangle tutorial submits it and waits for completion:

commandBuffer.Submit().Wait();

Recording builds the command sequence; Submit() schedules that sequence for execution. Calling Wait() then blocks the CPU thread until the submission completes. This makes the tutorial's frame loop easy to follow, because each frame finishes before the next begins.

The queue reclaims completed command buffers for reuse. Obtain one with queue.CommandBuffer() for each recording, record from one thread at a time, and submit it once. After submission, leave the buffer to the queue: do not modify, resubmit, or dispose it.

Pipeline state

A graphics pipeline defines the shaders, vertex input layout, primitive assembly, attachment formats, and render state used by draw commands. Select the pipeline before binding vertex, index, or constant data. Its attachment formats and sample count must agree with those of the render pass.

A compute pipeline selects the shader entry point for a dispatch. Bind the pipeline and its constants before dispatching, outside a graphics render pass.

The triangle's render callback illustrates the graphics sequence. The compute sample adds a compute dispatch before the graphics pass that displays its output.

Ownership and lifetime

Ownership determines who releases an object; GPU completion determines when it can be released. Calling Dispose() releases native resources even if C# references to the object remain. Submitting commands does not transfer ownership of their resources to the queue.

At shutdown, stop submitting work and wait for the last resource use on every participating queue. Then release the application's resources and dispose the context. The context releases its queues and internal helpers, so this final step belongs after application work has completed.

During rendering, track the completion of work that uses data you intend to overwrite or resources you intend to replace. Wait for those uses to finish before modifying or releasing the affected storage. Resource Management describes how views and their backing resources fit into this lifetime model.