2.3 · Renderer

A deferred Vulkan renderer built on NVRHI. Three cooperating layers — a static Renderer facade, the SceneRenderer deferred pipeline, and the Renderer2D batcher — talk to the GPU through a single global render command queue that is drained either by a real worker thread (runtime) or by the main thread at end of frame (editor).

Three layers, one queue

The renderer is split into three deliberately small layers. Each one has a clear job and the layer above never reaches past it.

The deferred pipeline

SceneRenderer drives a long but linear pass chain. Each pass reads from the previous one's outputs and writes into images that SceneRenderer::Init() allocated up front. Pipeline state objects (PSOs) are cached — they are never recreated per frame.

Pass-by-pass

Submit / queue mechanism

The whole renderer is built around Renderer::Submit. You call it with a lambda; the lambda is enqueued on the global RenderCommandQueue and executed later in a context that holds the NVRHI command list. This is how every pass in the pipeline above issues its draws.

Renderer::Submit([=]()
{
    nvrhi::CommandListHandle cmd = Renderer::GetCommandList();
    cmd->setGraphicsState(state);
    cmd->draw(args);
});

Who drains the queue depends on the threading policy:

Triple-buffered frames

The renderer triple-buffers per-frame resources (uniform buffers, transient descriptors, etc.). With three slots in rotation, frame N can be built on the main thread while frame N−1 is being recorded by the render thread and frame N−2 is in flight on the GPU.

This is only meaningful when CoreThreadingPolicy == MultiThreaded. In single-threaded mode the queue is drained at end-of-frame, so frames overlap only on the GPU side — CPU-side, frames are strictly sequential. Code that depends on "the render thread is one frame behind" works in runtime; in the editor that gap is zero.

Frame flow at a glance

Shaders & materials

Shaders live in Resources/Shaders/. They are HLSL — full stop. The renderer compiles them to SPIR-V through DXC and feeds the result to NVRHI. There is exactly one shading language allowed in the source tree.

Pipeline state objects (PSOs) are cached, not built per frame. SceneRenderer::Init() is the right place to materialise every pipeline you'll need; the per-frame path looks them up by handle.

Materials hang off the asset system — see 2.9 Asset System. Texture dependencies are tracked: when a texture reloads, dependent materials are notified via OnDependencyUpdated and pick up the new image without a manual reload.

Adding a new render pass

1. Write the shader in HLSL under Resources/Shaders/.
2. Register it with ShaderLibrary.
3. In SceneRenderer::Init, create the cached nvrhi::GraphicsPipeline / ComputePipeline and the material that binds inputs.
4. Allocate any intermediate images / framebuffers there too — never per-frame.
5. Insert the pass execution in SceneRenderer::PreRender or between two existing passes in EndScene, depending on where it fits in the swimlane diagram above.
6. Register shader dependencies via Renderer::RegisterShaderDependency so live-reload picks the new pass up.

Extending

Pitfalls

Key types