16.4 Rendering Engine & RHI

Chapter 7.7 opened the hood on graphics APIs directly: you called OpenGL functions yourself, and you saw the explicit, low-level shape of Vulkan and DirectX 12 underneath. A real game engine does not let gameplay code do that. Between the code a gameplay or rendering programmer writes and the raw Vulkan/DX12/Metal calls from that earlier chapter sits another layer, built once and used by everything above it: the RHI (Render Hardware Interface). This chapter is about that layer, and about everything the engine does around it every single frame — deciding what is even worth drawing, deciding what order to draw it in, wiring rendering steps together automatically instead of by hand, and juggling the fact that the CPU and GPU are never actually working on the same frame at the same time.

1. Where the RHI Sits: One Engine, Three Graphics APIs

A studio shipping on PC, PlayStation, Xbox, and mobile cannot ship three or four separate renderers written from scratch. Every platform speaks a different graphics API underneath (Vulkan on Linux/Android/some Windows, DirectX 12 on Windows/Xbox, Metal on macOS/iOS), but the engine's rendering logic — what to draw, in what order, with what data — is exactly the same regardless of platform. The RHI is the thin C++ layer that makes that possible: one small, stable interface that the entire engine codes against, with a separate implementation of that same interface per graphics API underneath.

Every backend file (RHIDevice_Vulkan.cpp, RHIDevice_D3D12.cpp, RHIDevice_Metal.cpp) implements the exact same set of functions, just by calling a different underlying API. When the engine calls device->CreateBuffer(...), the Vulkan backend turns that into vkCreateBuffer plus a memory allocation, the DirectX 12 backend turns it into CreateCommittedResource, and the Metal backend turns it into newBufferWithLength. The engine code that called CreateBuffer never changes between platforms — only which .cpp file gets compiled into the final executable changes.

This is the same idea you already know from other languages: an RHI is an abstract interface (a set of function signatures with no implementation) with multiple concrete implementations (one per backend) that satisfy that interface. If earlier chapters showed you a C++ base class with pure virtual functions and several derived classes overriding them, that pattern is exactly what a real RHI is built from — Section 3 writes it out.

2. Why Gameplay Code Never Calls Vulkan Directly

Nothing stops a gameplay programmer from #include <vulkan/vulkan.h> in a player-controller file and calling vkCmdDrawIndexed directly. Every serious engine actively prevents this anyway, by making the RHI the only rendering surface that code outside the renderer is allowed to see.

Four concrete reasons back this line up:

• Portability. A studio's next project might target a platform that does not exist yet. If gameplay code never touched Vulkan directly, porting to a new platform means writing one new backend file, not auditing every gameplay system that ever issued a draw call.
• Thread-safety rules that gameplay code should never have to know. Vulkan and DirectX 12 objects have strict, specific rules about which threads may call which functions when — for example, a single VkCommandBuffer being recorded on one thread must never be touched from another thread at the same time. The RHI's command list can enforce or hide these rules in one place; a gameplay programmer calling raw Vulkan from a gameplay-script callback (which could run on any thread) is exactly how these bugs happen in practice.
• Frame-level optimization needs a choke point. Sections 5 through 9 of this chapter gather every visible object, sort the whole list, and only then submit draw calls in that chosen order. That is only possible because nothing draws anything until the renderer decides to. If gameplay code fired off draw calls immediately whenever it felt like it, there would be no single list left to sort or batch.
• A narrow interface is a safety net. IRHIDevice might have 30-something functions. The Vulkan API it wraps has well over a thousand. A mistake inside a 30-function surface is easy to review, test, and validate; a mistake made through direct access to a thousand-function API, from code written by someone who is not a graphics specialist, is exactly the kind of bug that produces GPU crashes and corrupted frames that are painful to track down.

3. Designing an RHI: Handles, Descriptors, and a Command List

An RHI is built from three kinds of pieces: handles (small, opaque values that stand in for a GPU resource, instead of a raw pointer into driver memory), descriptors (plain structs describing what to create), and an abstract device and command list interface. Here is a small but complete sketch:

// A handle is just an ID and a generation counter -- NOT a pointer.
// Gameplay code never sees a VkBuffer or an ID3D12Resource, only this.
struct RHIBufferHandle   { uint32_t id = 0; uint32_t generation = 0; };
struct RHITextureHandle  { uint32_t id = 0; uint32_t generation = 0; };
struct RHIPipelineHandle { uint32_t id = 0; uint32_t generation = 0; };

struct RHIBufferDesc
{
    size_t sizeBytes;
    bool   isVertexBuffer;
    bool   isIndexBuffer;
    bool   cpuWritable;   // true for buffers the CPU updates every frame
};

struct RHITextureDesc
{
    uint32_t width, height;
    uint32_t format;       // e.g. RHI_FORMAT_RGBA8, RHI_FORMAT_D32_FLOAT
    bool     isRenderTarget;
};

struct RHIPipelineDesc
{
    const char* vertexShaderPath;
    const char* fragmentShaderPath;
    bool        depthTestEnabled;
    bool        blendEnabled;      // Chapter 7.7 Section 10's "PSO", baked once
};

These descriptors are plain data — no Vulkan or DirectX types appear anywhere in them. Now the interface that creates and destroys resources from those descriptors:

// ONE header, shared by every platform. A .cpp file per backend
// (RHIDevice_Vulkan.cpp, RHIDevice_D3D12.cpp, RHIDevice_Metal.cpp)
// implements every pure virtual function below.
class IRHIDevice
{
public:
    virtual ~IRHIDevice() = default;

    virtual RHIBufferHandle   CreateBuffer(const RHIBufferDesc& desc, const void* initialData) = 0;
    virtual RHITextureHandle  CreateTexture(const RHITextureDesc& desc) = 0;
    virtual RHIPipelineHandle CreatePipeline(const RHIPipelineDesc& desc) = 0;

    virtual void UpdateBuffer(RHIBufferHandle handle, const void* data, size_t sizeBytes) = 0;

    virtual void DestroyBuffer(RHIBufferHandle handle) = 0;
    virtual void DestroyTexture(RHITextureHandle handle) = 0;

    virtual class IRHICommandList* CreateCommandList() = 0;
    virtual void SubmitCommandLists(IRHICommandList** lists, int count) = 0;
};

And the interface for recording GPU work — the counterpart to Chapter 7.7's vkCmd* calls and ID3D12GraphicsCommandList methods, unified into one shape:

class IRHICommandList
{
public:
    virtual ~IRHICommandList() = default;

    virtual void BeginRecording() = 0;
    virtual void EndRecording() = 0;

    virtual void SetPipeline(RHIPipelineHandle pipeline) = 0;
    virtual void BindVertexBuffer(RHIBufferHandle buffer, uint32_t slot) = 0;
    virtual void BindIndexBuffer(RHIBufferHandle buffer) = 0;
    virtual void SetConstants(const void* data, size_t sizeBytes, uint32_t bindSlot) = 0;
    virtual void DrawIndexed(uint32_t indexCount, uint32_t firstIndex, uint32_t vertexOffset) = 0;
};

Compare cmd->DrawIndexed(indexCount, 0, 0) to Chapter 7.7's raw calls: it is the same idea as vkCmdDrawIndexed and ID3D12GraphicsCommandList::DrawIndexedInstanced, with the vendor-specific parameters and vendor-specific state trimmed down to what every backend actually needs. Each backend's DrawIndexed override does the real work:

// Inside RHICommandList_Vulkan.cpp (sketch)
void RHICommandList_Vulkan::DrawIndexed(uint32_t indexCount, uint32_t firstIndex, uint32_t vertexOffset)
{
    vkCmdDrawIndexed(m_vkCommandBuffer, indexCount, 1, firstIndex, vertexOffset, 0);
}

// Inside RHICommandList_D3D12.cpp (sketch)
void RHICommandList_D3D12::DrawIndexed(uint32_t indexCount, uint32_t firstIndex, uint32_t vertexOffset)
{
    m_d3dCommandList->DrawIndexedInstanced(indexCount, 1, firstIndex, vertexOffset, 0);
}

Nothing above these two files ever needs to know that DrawIndexed becomes vkCmdDrawIndexed on one platform and DrawIndexedInstanced on another. The handle design matters just as much as the virtual functions: because RHIBufferHandle is a plain ID, not a pointer, the device's internal table can safely move, recreate, or invalidate the actual GPU object behind it (say, after a device is lost and recreated) without every piece of code holding that handle needing to change. The generation field lets the device detect and reject a stale handle — one whose underlying resource was already destroyed and whose ID slot was reused for something else — instead of silently reading garbage.

4. The Render Pipeline, End to End

With an RHI in hand, the renderer's job every frame is to turn "the current scene" into a sequence of RHI calls. That happens in four stages, in this fixed order:

Every one of the next five sections builds one box of this diagram in code. By the end of Section 8 you will have a complete, working (if simplified) render loop; Section 9 then shows how a real engine wraps stage 4 in something more flexible than one hand-written function.

5. Gather, Cull, and Build the Draw List

Culling means deciding, before spending any GPU time, which objects are not even worth trying to draw. Frustum culling (the cheapest and most common kind) tests each object's bounding box against the six planes of the camera's view frustum — the pyramid-shaped volume the camera can actually see — and throws away anything fully outside it.

struct AABB   { Vec3 min, max; };               // axis-aligned bounding box
struct Plane  { Vec3 normal; float distance; };  // normal . point + distance >= 0 means "in front"
struct Frustum{ Plane planes[6]; };              // left, right, top, bottom, near, far

bool IsAABBOutsidePlane(const AABB& box, const Plane& plane)
{
    // the box corner furthest along the plane's normal -- if even THAT
    // corner is behind the plane, the whole box must be behind it too
    Vec3 positive;
    positive.x = (plane.normal.x >= 0.0f) ? box.max.x : box.min.x;
    positive.y = (plane.normal.y >= 0.0f) ? box.max.y : box.min.y;
    positive.z = (plane.normal.z >= 0.0f) ? box.max.z : box.min.z;

    return Dot(plane.normal, positive) + plane.distance < 0.0f;
}

bool IsVisible(const AABB& box, const Frustum& frustum)
{
    for (int i = 0; i < 6; ++i)
    {
        if (IsAABBOutsidePlane(box, frustum.planes[i]))
            return false;   // fully outside at least one plane -- cull it
    }
    return true;   // not fully outside any plane -- keep it
}

Worked trace: take a simplified frustum with just a near plane at z = 1 and a far plane at z = 100 (ignore the four side planes for this trace), and three objects sitting at z = 0.5, z = 10, and z = 150. The object at z = 0.5 fails IsAABBOutsidePlane against the near plane (it is closer than the camera can see) and gets culled. The object at z = 150 fails against the far plane and gets culled. Only the object at z = 10 passes every plane test and survives.

Frustum culling is a cheap first filter, not the only one. A wall directly in front of the camera can still fully hide a room behind it even though that room is inside the frustum; a further, more expensive technique called occlusion culling (testing objects against what has already been drawn, using hardware occlusion queries or a software depth pyramid) removes those. This chapter's code sticks to frustum culling to keep the example tractable — the shape of the pipeline is identical either way, just with an extra filter step.

Once the visible list exists, each surviving object becomes one or more draw items — the actual unit the rest of the pipeline sorts and submits:

struct Renderable
{
    AABB           worldBounds;
    MeshHandle     mesh;       // vertex buffer + index buffer + index count
    MaterialHandle material;   // shader + parameters + a compiled RHIPipelineHandle
    Mat4           worldTransform;
};

struct DrawItem
{
    RHIPipelineHandle pipeline;        // from material->pipeline (Section 13 explains why)
    RHIBufferHandle   vertexBuffer;
    RHIBufferHandle   indexBuffer;
    uint32_t          indexCount;
    Mat4              worldTransform;
    float             viewDepth;       // distance from camera, filled in here
    uint32_t          meshIndex;       // a stable id, used as a sort tiebreaker
    uint64_t          sortKey = 0;     // filled in by Section 7
};

std::vector<DrawItem> BuildDrawItems(const std::vector<Renderable*>& visible, const Vec3& cameraPos)
{
    std::vector<DrawItem> items;
    items.reserve(visible.size());

    for (Renderable* r : visible)
    {
        DrawItem item;
        item.pipeline       = r->material->pipeline;
        item.vertexBuffer   = r->mesh->vertexBuffer;
        item.indexBuffer    = r->mesh->indexBuffer;
        item.indexCount     = r->mesh->indexCount;
        item.worldTransform = r->worldTransform;
        item.viewDepth      = Length(r->worldTransform.GetPosition() - cameraPos);
        item.meshIndex      = r->mesh.id;
        items.push_back(item);
    }
    return items;
}

Notice what a DrawItem deliberately does not contain: it has no idea whether it is opaque or transparent, and no idea what order it will end up drawn in. That is exactly what the next two sections add — the whole point of separating "gather what exists" from "decide the order" is that sorting can look at the entire list at once, instead of each object deciding its own fate in isolation.

6. Sort: Front-to-Back for Opaque, Back-to-Front for Transparent

Opaque and transparent objects need opposite draw orders, for two completely different reasons.

For opaque objects, the reason is early-z (early depth test — the GPU checking a fragment's depth against the depth buffer before running the fragment shader, and throwing the fragment away immediately if something already drawn is closer). Early-z only pays off if something closer was already drawn into the depth buffer by the time a farther object arrives — which is exactly what front-to-back order guarantees. Draw the near object first, and every pixel of the far object that it actually blocks gets rejected before its (possibly expensive, texture-sampling, lighting-computing) fragment shader ever runs. This avoided work is called saved overdraw (shading a pixel that ends up invisible, overwritten by something else). Draw back-to-front instead, and early-z can never help — every far pixel gets fully shaded first, then gets overwritten by the near object anyway, wasting exactly the GPU time front-to-back order would have avoided.

For transparent objects, depth testing cannot make the ordering problem go away, because alpha blending (combining a new fragment's color with what is already in the framebuffer, weighted by opacity, instead of fully replacing it) is not commutative — blending A over B gives a different result than blending B over A. A small worked example makes this concrete. Take a black background, a far red object with 50% opacity, and a near blue object with 50% opacity, using the standard blend formula result = src * srcAlpha + dst * (1 - srcAlpha):

Correct order -- back-to-front (draw red first, then blue over it):
  after red:   result = (1,0,0)*0.5 + (0,0,0)*0.5 = (0.50, 0.00, 0.00)
  after blue:  result = (0,0,1)*0.5 + (0.50,0,0)*0.5 = (0.25, 0.00, 0.50)
  final color: (0.25, 0.00, 0.50)  -- a purple leaning blue, blue is on top (correct)

Wrong order -- front-to-back (draw blue first, then red over it):
  after blue:  result = (0,0,1)*0.5 + (0,0,0)*0.5 = (0.00, 0.00, 0.50)
  after red:   result = (1,0,0)*0.5 + (0.00,0,0.50)*0.5 = (0.50, 0.00, 0.25)
  final color: (0.50, 0.00, 0.25)  -- a purple leaning red, even though
                                       blue was supposed to be in front

Same two objects, same opacity, same everything except draw order — and the two final colors are different, and only one of them is correct. This is why transparent objects must be drawn back-to-front: it is not a performance optimization the way opaque front-to-back sorting is, it is the only order that produces the visually correct result at all.

7. Sort Keys: Packing Priorities Into One Integer

A sort key is a single number computed for each draw item, such that a plain ascending sort by that number alone produces the exact draw order the renderer wants. Packing several priorities (opaque-before-transparent, then depth order, then minimizing state changes) into one 64-bit integer, most important priority in the highest bits, lets the whole sort run as one fast, ordinary numeric sort — no custom comparator logic needed at draw time.

constexpr uint64_t kTranslucentBit = 1ull << 63;

uint32_t QuantizeDepth(float viewDepth, float nearZ, float farZ)
{
    float t = std::clamp((viewDepth - nearZ) / (farZ - nearZ), 0.0f, 1.0f);
    return static_cast<uint32_t>(t * 0xFFFFFFFFu);   // pack depth into 32 bits
}

uint64_t MakeSortKey(const DrawItem& item, bool isTransparent, float nearZ, float farZ)
{
    uint32_t depthBits = QuantizeDepth(item.viewDepth, nearZ, farZ);

    if (isTransparent)
    {
        // back-to-front: the FARTHEST object must sort FIRST, so invert
        // the quantized depth -- a large raw depth becomes a SMALL key.
        depthBits = 0xFFFFFFFFu - depthBits;
    }
    // else: opaque, front-to-back -- a small raw depth already sorts
    // first with no inversion needed.

    uint64_t key = 0;
    key |= isTransparent ? kTranslucentBit : 0;          // bit 63: opaque bucket always first
    key |= (uint64_t)depthBits << 24;                    // bits 55-24: depth priority
    key |= (uint64_t)(item.pipeline.id & 0xFFFF) << 8;    // bits 23-8: groups shared pipelines
    key |= (uint64_t)(item.meshIndex & 0xFF);             // bits 7-0: stable final tiebreaker
    return key;
}

Reading the bit layout from most to least significant, in priority order: bit 63 puts every opaque item before every transparent item, no matter what else is true about them — this is what guarantees transparent objects always blend against a fully-drawn opaque background. Bits 55-24 carry the depth ordering from Section 6, already flipped for transparency so a single ascending sort handles both cases correctly. Bits 23-8 group items that share the same pipeline next to each other — Section 8 shows why that matters at submit time. The bottom 8 bits exist purely so that two items with an identical key so far (rare, but possible) still sort in a fixed, repeatable order instead of an unspecified one.

Worked trace: using a simplified 0-1000 depth scale for readability instead of the full 32-bit range, four items — A (opaque, depth 3), B (opaque, depth 7), C (transparent, depth 4), D (transparent, depth 9) — produce these keys (pipeline and mesh bits left at 0 to keep the numbers readable):

A: opaque,      depth 3  ->  bucket 0, depthBits =    3  ->  key ~ 0x000000003_00_00
B: opaque,      depth 7  ->  bucket 0, depthBits =    7  ->  key ~ 0x000000007_00_00
C: transparent, depth 4  ->  bucket 1, depthBits = 1000-4 = 996  ->  key ~ 0x8...3E4_00_00
D: transparent, depth 9  ->  bucket 1, depthBits = 1000-9 = 991  ->  key ~ 0x8...3DF_00_00

Ascending sort by key gives:  A, B, D, C
  -- opaque group first, near-to-far (A depth 3, then B depth 7): correct
  -- transparent group second, far-to-near (D depth 9, then C depth 4): correct

8. Submit: Draw Items Become RHI Calls

Submit is the final stage: walk the sorted list in order, and for each item, tell the RHI to bind whatever changed since the previous item and draw it. Because Section 7's sort key already groups same-pipeline items together, most consecutive items in the sorted list do not actually need a pipeline change — a small state cache skips the redundant calls:

void SubmitDrawList(IRHICommandList* cmd, const std::vector<DrawItem>& sortedItems)
{
    RHIPipelineHandle currentPipeline{};
    RHIBufferHandle   currentVB{};
    RHIBufferHandle   currentIB{};

    for (const DrawItem& item : sortedItems)
    {
        if (item.pipeline.id != currentPipeline.id)
        {
            cmd->SetPipeline(item.pipeline);
            currentPipeline = item.pipeline;
        }
        if (item.vertexBuffer.id != currentVB.id)
        {
            cmd->BindVertexBuffer(item.vertexBuffer, 0);
            currentVB = item.vertexBuffer;
        }
        if (item.indexBuffer.id != currentIB.id)
        {
            cmd->BindIndexBuffer(item.indexBuffer);
            currentIB = item.indexBuffer;
        }

        cmd->SetConstants(&item.worldTransform, sizeof(item.worldTransform), 0);
        cmd->DrawIndexed(item.indexCount, 0, 0);
    }
}

Put together, Sections 5 through 8 are a complete pipeline: GatherVisible filters the scene down with frustum culling, BuildDrawItems turns survivors into a flat list, MakeSortKey plus std::sort puts that list into the one order that is both correct (opaque before transparent, transparent back-to-front) and fast (opaque front-to-back, pipelines grouped), and SubmitDrawList walks the result once, emitting exactly the RHI calls needed and nothing more:

std::vector<Renderable*> visible = GatherVisible(allObjects, cameraFrustum);
std::vector<DrawItem>    items   = BuildDrawItems(visible, cameraPos);

for (DrawItem& item : items)
    item.sortKey = MakeSortKey(item, IsTransparent(item), nearZ, farZ);

std::sort(items.begin(), items.end(),
          [](const DrawItem& a, const DrawItem& b) { return a.sortKey < b.sortKey; });

SubmitDrawList(cmd, items);

9. Render Graph / Frame Graph: Passes Declare Their Dependencies

Section 8's SubmitDrawList draws into whatever framebuffer is currently bound — fine for one pass, but a real frame is many passes: a depth prepass, an opaque geometry pass, a lighting pass, a bloom pass, a tonemap pass, each reading textures the previous ones wrote. Chapter 7.7 Section 12 had you write the barrier between two such passes by hand. A render graph (also called a frame graph) removes that by hand part: each pass declares, up front, which resources it reads and which it writes, and a build step figures out the correct order and inserts every barrier automatically.

class FrameGraph
{
public:
    RGTextureHandle CreateTexture(const char* name, const RHITextureDesc& desc);

    // setup() ONLY calls Read()/Write() on an RGBuilder -- it never touches
    // the RHI. execute() is the only place that records real RHI commands,
    // and it only runs later, after Compile() has ordered every pass.
    template <typename SetupFn, typename ExecuteFn>
    void AddPass(const char* name, SetupFn setup, ExecuteFn execute);

    void Compile();                    // order passes, allocate/alias resources, insert barriers
    void Execute(IRHICommandList* cmd); // run every pass's execute() in the computed order
};

Declaring a small four-pass frame with this API:

RGTextureHandle depthTex   = graph.CreateTexture("Depth",      depthDesc);
RGTextureHandle gbufferA   = graph.CreateTexture("GBufferA",   gbufferDesc);
RGTextureHandle sceneColor = graph.CreateTexture("SceneColor", colorDesc);
RGTextureHandle backbuffer = graph.GetBackbuffer();

graph.AddPass("DepthPrepass",
    [&](RGBuilder& b) { b.Write(depthTex); },
    [=](IRHICommandList* cmd) { SubmitDrawList(cmd, opaqueDepthOnlyItems); });

graph.AddPass("GBufferPass",
    [&](RGBuilder& b) { b.Write(gbufferA); b.Write(depthTex); },
    [=](IRHICommandList* cmd) { SubmitDrawList(cmd, opaqueItems); });

graph.AddPass("LightingPass",
    [&](RGBuilder& b) { b.Read(gbufferA); b.Read(depthTex); b.Write(sceneColor); },
    [=](IRHICommandList* cmd) { DrawFullscreenLightingShader(cmd, gbufferA, depthTex); });

graph.AddPass("TonemapPass",
    [&](RGBuilder& b) { b.Read(sceneColor); b.Write(backbuffer); },
    [=](IRHICommandList* cmd) { DrawFullscreenTonemapShader(cmd, sceneColor); });

graph.Compile();
graph.Execute(cmd);

Two things happen inside Compile() that hand-written rendering code has to get right on its own otherwise. First, ordering: because LightingPass declared Read(gbufferA) and GBufferPass declared Write(gbufferA), the graph knows GBufferPass must run first — the same reasoning as a topological sort over a dependency graph, which earlier data structure chapters already covered in a different context. Second, resource lifetime and aliasing: the graph knows exactly which frame-range each transient texture is alive for (a texture used only inside one pass, and never read afterward, needs no barrier at all and can even share physical GPU memory with a completely unrelated texture used later in the same frame, once the graph confirms their live ranges never overlap) — this is called resource aliasing, and it can meaningfully cut a frame's GPU memory footprint without any of the pass-writing code needing to think about memory at all.

10. Command Buffers and Recording on Multiple Threads

Chapter 7.7 Section 11 showed Vulkan splitting recording across four threads, each building its own command buffer, submitted together. A renderer applies the exact same idea to the sorted draw list from Section 8: since the list is already in its final, correct order before any recording starts, it can simply be cut into contiguous chunks, one chunk recorded per thread, with the resulting command lists submitted back in the original order.

void RecordChunk(const std::vector<DrawItem>& items, size_t begin, size_t end, IRHICommandList* out)
{
    out->BeginRecording();
    std::vector<DrawItem> chunk(items.begin() + begin, items.begin() + end);
    SubmitDrawList(out, chunk);
    out->EndRecording();
}

void RecordFrameParallel(IRHIDevice* device, const std::vector<DrawItem>& sortedItems, int threadCount)
{
    std::vector<IRHICommandList*> lists(threadCount);
    std::vector<std::thread>      workers;

    size_t chunkSize = (sortedItems.size() + threadCount - 1) / threadCount;
    for (int t = 0; t < threadCount; ++t)
    {
        lists[t] = device->CreateCommandList();
        size_t begin = (size_t)t * chunkSize;
        size_t end   = std::min(begin + chunkSize, sortedItems.size());
        workers.emplace_back(RecordChunk, std::cref(sortedItems), begin, end, lists[t]);
    }
    for (auto& w : workers) w.join();

    device->SubmitCommandLists(lists.data(), (int)lists.size());   // executed in this array order
}

The state cache inside SubmitDrawList from Section 8 now resets at the start of each chunk (each thread's currentPipeline starts empty again), so a handful of redundant state-setting calls appear at chunk boundaries that a single-threaded pass would have skipped. That small, bounded cost is normally far smaller than what four CPU cores recording in parallel save compared to one core recording everything serially — real engines use a job system (built on the same kind of thread pool covered in earlier chapters) rather than raw std::thread per chunk, but the shape — split, record independently, submit together in order — is identical.

11. The CPU/GPU Frame Pipeline: Double and Triple Buffering

Once a frame is submitted, the GPU needs real time to actually execute it — often more time than the CPU needs to record the next one. If the CPU waited for the GPU to completely finish frame N before it was allowed to start recording frame N+1, CPU and GPU would take turns being idle, and total frame time would be CPU time plus GPU time, back to back. Instead, engines let the CPU start recording frame N+1 immediately, while the GPU is still executing frame N.

Doing this safely requires that the CPU never overwrites a resource the GPU might still be reading from a previous frame. The fix is to keep more than one physical copy of every per-frame resource — double buffering keeps 2 copies, triple buffering keeps 3 — and have the CPU cycle through them, always writing into whichever copy the GPU is not currently using:

constexpr int kFramesInFlight = 2;   // double buffering; use 3 for triple buffering

RHIBufferHandle  perFrameConstants[kFramesInFlight];
IRHICommandList* perFrameCmdLists[kFramesInFlight];
RHIFenceHandle   perFrameFence[kFramesInFlight];

void RenderFrame(IRHIDevice* device, uint64_t frameNumber)
{
    int slot = (int)(frameNumber % kFramesInFlight);

    // Wait until the GPU finished whatever THIS slot held kFramesInFlight
    // frames ago -- only then is it safe to overwrite it for this frame.
    device->WaitForFence(perFrameFence[slot]);

    device->UpdateBuffer(perFrameConstants[slot], /* this frame's camera/light data */ nullptr, 0);

    IRHICommandList* cmd = perFrameCmdLists[slot];
    // ... record this frame's draw list into cmd, as in Sections 8-10 ...

    device->SubmitCommandLists(&cmd, 1);   // signals perFrameFence[slot] on completion
}

With kFramesInFlight = 2, the CPU can get up to one full frame ahead of the GPU before WaitForFence actually blocks it; with 3, up to two frames ahead. More frames in flight means more slack when a single frame briefly takes the GPU longer than usual (fewer visible stutters), at the cost of more duplicated per-frame memory and slightly more input latency, since the frame currently on screen was recorded further in the past. This is exactly the mechanism behind the "double buffering" / "triple buffering" toggle many PC games expose in their graphics settings — the player-facing setting and the fence-indexed array above are the same idea.

12. Shader and Material Systems: Permutations

A material is a shader plus a specific set of parameter values (which textures, which colors, which numeric knobs). Many materials share the same shader source but need slightly different compiled code — one object is skinned (animated by a skeleton) and another is not, one needs shadow sampling and another does not. Rather than hand-write a separate shader file for every combination, engines write one shader source with compile-time feature toggles, and let the build system generate every needed combination — each combination is called a permutation (also called a shader variant).

// One shader SOURCE file, several features toggled by #define at compile time.
#if defined(FEATURE_SKINNED)
    layout(location = 4) in ivec4 aBoneIndices;
    layout(location = 5) in vec4  aBoneWeights;
#endif

#if defined(FEATURE_SHADOWS)
    uniform sampler2D uShadowMap;
#endif

void main()
{
    vec3 worldPos = ComputeWorldPosition();

#if defined(FEATURE_SKINNED)
    worldPos = ApplySkinning(worldPos, aBoneIndices, aBoneWeights);
#endif

    float shadow = 1.0;
#if defined(FEATURE_SHADOWS)
    shadow = SampleShadow(uShadowMap, worldPos);
#endif

    // ... use worldPos and shadow to compute the final color ...
}

Each material picks a combination of feature flags, and that combination becomes a permutation key — a small integer that uniquely identifies one compiled variant:

uint32_t ComputePermutationKey(bool skinned, bool shadows, bool instanced, bool fog)
{
    uint32_t key = 0;
    key |= skinned   ? (1u << 0) : 0;
    key |= shadows   ? (1u << 1) : 0;
    key |= instanced ? (1u << 2) : 0;
    key |= fog       ? (1u << 3) : 0;
    return key;   // 4 independent toggles -> up to 2^4 = 16 distinct compiled variants
}

RHIPipelineHandle GetOrCreatePipeline(Material* material, uint32_t permutationKey)
{
    auto it = material->pipelineCache.find(permutationKey);
    if (it != material->pipelineCache.end())
        return it->second;

    RHIPipelineHandle pipeline = CompilePipelineForPermutation(material, permutationKey);
    material->pipelineCache[permutationKey] = pipeline;
    return pipeline;
}

Four independent boolean toggles already produce up to 16 permutations; real shaders often have a dozen or more toggles, so the theoretical permutation count can explode into the thousands even though any single scene only ever actually uses a small fraction of them. Chapter 7.7 Section 10 already noted that creating one pipeline can take milliseconds because the driver validates it fully at creation time — multiply that cost by "however many distinct permutations this scene happens to need," and the well-known PC "shader compilation stutter" is exactly this cost showing up mid-gameplay, the first time a permutation nobody pre-compiled during loading gets requested.

13. Reading an Engine's Renderer Source Without Drowning

A shipped engine's renderer can be tens of thousands of lines across dozens of files. Opening it top-to-bottom is not how anyone actually learns it — the sections above give you a map to navigate by instead of reading in file order.

A concrete strategy, in order:

• Find the single high-level entry point first. Search for a function literally named something like Render, RenderFrame, or SceneRenderer::Render. It almost never does the real work itself — it calls out to gather/cull, sort, and a frame graph, in roughly that order — and reading just its top-level calls hands you a table of contents for everything else.
• Find the RHI boundary next. Look for a folder or namespace literally called RHI, Graphics/RHI, or similar, containing an abstract interface header. Everything that calls into it is portable engine logic — what this chapter covered. Everything inside a specific backend folder underneath it is vendor-specific and safe to skip entirely while you are still learning how the pipeline is shaped.
• Grep using this chapter's vocabulary. Real engines name these concepts close enough to DrawItem/RenderItem, SortKey, FrameGraph/RenderGraph, CommandList, and Pipeline/PSO that searching for these terms gets you to the relevant code fast, instead of reading unrelated files hoping to stumble onto the right one.
• Read a pass's dependency declaration before its execute code. A frame graph's setup callbacks (Section 9) are usually short and tell you what a pass needs and produces without any of the actual per-pass rendering detail — read all of those first to understand the frame's overall shape, then dig into one pass's execute body only once you know where it sits in the whole sequence.
• Pick one backend and ignore the others. Whichever backend actually runs on your development machine is the only one worth reading closely at first. The other two implement the exact same interface for a different API — you can learn that translation later, on its own, once the pipeline shape from Sections 4-11 is already solid.
• Use a GPU frame-capture tool (RenderDoc on Windows/Linux, PIX on Xbox/Windows, Xcode's GPU frame capture on Apple platforms) to see the actual sequence of passes and draw calls one real frame produced, click any single draw call to inspect its exact state, and work backward into source code only for the specific parts that confuse you. This is frequently faster than reading source top-to-bottom, because it starts from ground truth instead of from a guess about what the code does.

14. Glossary

• RHI (Render Hardware Interface) — a stable C++ interface the whole engine renders through, implemented once per graphics API by a separate backend.
• Backend — the concrete implementation of the RHI interface for one specific graphics API (Vulkan, DirectX 12, Metal).
• Handle — a small opaque ID (plus a generation counter) that stands in for a GPU resource, instead of a raw pointer into driver memory.
• Gather — collecting the set of objects that might need to be drawn this frame.
• Culling — deciding which gathered objects are not worth drawing, and discarding them before any GPU work is spent on them.
• Frustum culling — culling objects whose bounding box lies fully outside the camera's view frustum.
• Frustum — the pyramid-shaped volume of space a camera can actually see.
• Occlusion culling — culling objects that are fully hidden behind other already-drawn geometry, even if inside the view frustum.
• AABB (axis-aligned bounding box) — the smallest box, aligned to the world's x/y/z axes, that fully contains an object.
• Draw item — one unit of work in the render pipeline: a mesh, a material/pipeline, a transform, and a computed sort key.
• Early-z (early depth test) — the GPU testing a fragment's depth against the depth buffer before running its fragment shader, skipping the shader entirely if the fragment is already hidden.
• Overdraw — GPU work spent shading a pixel that ends up invisible, later overwritten by something else.
• Alpha blending — combining a new fragment's color with the framebuffer's existing color, weighted by opacity, instead of fully replacing it; not commutative, which is why transparent draw order matters.
• Sort key — a single number computed per draw item such that a plain ascending sort by that number produces the desired draw order.
• Submit — walking a sorted draw list and issuing the RHI calls needed to actually draw each item.
• State cache (at submit time) — tracking the currently bound pipeline/buffers during submission so identical consecutive bindings are not redundantly re-issued.
• Render graph / frame graph — a system where each rendering pass declares its resource reads and writes up front, letting the engine compute pass order, allocate resources, and insert barriers automatically.
• Pass — one named unit of work inside a render graph, with a setup step (declares dependencies) and an execute step (records real RHI commands).
• Transient resource — a render-graph resource that only needs to exist for part of a frame, making it a candidate for aliasing.
• Resource aliasing — letting two transient resources with non-overlapping lifetimes share the same underlying GPU memory.
• Barrier — a synchronization point that ensures one piece of GPU work's effects (and any needed layout change) are complete and visible before another piece of work depending on it begins.
• Frames in flight — the number of frames the CPU is allowed to be recording ahead of what the GPU has finished executing.
• Double buffering / triple buffering — keeping 2 or 3 physical copies of per-frame resources so the CPU can safely write into one while the GPU still reads another.
• Permutation (shader variant) — one specific compiled version of a shader, produced by one specific combination of compile-time feature toggles.
• Material — a shader reference plus a specific set of parameter values (textures, colors, numeric settings) applied to it.
• Pipeline / PSO — a baked object bundling compiled shaders with blend, depth, and rasterizer state, validated once at creation (introduced in Chapter 7.7).

15. Exercises

uint64_t MakeSortKey(const DrawItem& item, bool isTransparent, float nearZ, float farZ)
{
    uint32_t depthBits = QuantizeDepth(item.viewDepth, nearZ, farZ);

    uint64_t key = 0;
    key |= isTransparent ? kTranslucentBit : 0;
    key |= (uint64_t)depthBits << 24;
    key |= (uint64_t)(item.pipeline.id & 0xFFFF) << 8;
    key |= (uint64_t)(item.meshIndex & 0xFF);
    return key;
}

uint64_t MakeSortKey(const DrawItem& item, bool isTransparent, float nearZ, float farZ)
{
    uint32_t depthBits = QuantizeDepth(item.viewDepth, nearZ, farZ);

    if (isTransparent)
    {
        depthBits = 0xFFFFFFFFu - depthBits;   // added: invert for back-to-front
    }

    uint64_t key = 0;
    key |= isTransparent ? kTranslucentBit : 0;
    key |= (uint64_t)depthBits << 24;
    key |= (uint64_t)(item.pipeline.id & 0xFFFF) << 8;
    key |= (uint64_t)(item.meshIndex & 0xFF);
    return key;
}

RGTextureHandle sceneColor   = graph.CreateTexture("SceneColor",   colorDesc);
RGTextureHandle bloomTexture = graph.CreateTexture("BloomTexture", colorDesc);
RGTextureHandle backbuffer   = graph.GetBackbuffer();

graph.AddPass("LightingPass",
    [&](RGBuilder& b) { b.Read(gbufferA); b.Read(depthTex); b.Write(sceneColor); },
    [=](IRHICommandList* cmd) { DrawFullscreenLightingShader(cmd, gbufferA, depthTex); });

graph.AddPass("BloomPass",
    [&](RGBuilder& b) { b.Read(sceneColor); b.Write(bloomTexture); },
    [=](IRHICommandList* cmd) { DrawFullscreenBloomShader(cmd, sceneColor); });

graph.AddPass("TonemapPass",
    [&](RGBuilder& b) { b.Read(bloomTexture); b.Write(backbuffer); },
    [=](IRHICommandList* cmd) { DrawFullscreenTonemapShader(cmd, bloomTexture); });