One API into another

Every draw call rewritten on the way through

A compatibility layer sitting between a program and the GPU is, at its core, a rewriting engine. The program speaks one graphics API — Direct3D 11, say — and the GPU driver beneath speaks another, most commonly Vulkan. Every draw call, every resource binding, every pipeline state change passes through the layer and comes out the other side translated. The process sounds mechanical. It is not.

The first complication is that Direct3D 11 and Vulkan do not carve the world at the same joints. D3D11 accepts state changes incrementally: you bind a rasteriser state here, a blend state there, a shader somewhere else, and the driver accumulates them into whatever the hardware eventually needs. Vulkan does the opposite. It demands that rasterisation state, blending, vertex layout, shader stages and render-pass format all be baked into a single pipeline state object before a draw call can be issued. The translation layer cannot emit that object when it receives the first D3D11 state call, because it does not yet know what the rest of the state will look like. It has to wait, accumulate, and then construct the Vulkan pipeline object at draw time — when the full picture is finally available.

That waiting-and-accumulating is state tracking. The layer maintains a shadow copy of everything the program has touched: currently bound render targets, active vertex and index buffers, sampler settings, rasteriser flags, stencil references, every piece of context that D3D11 keeps implicitly on the device. None of that exists as a concept in Vulkan, which has no persistent device context at all. The layer is manufacturing that context from scratch, updating it on every API call, and reading it back at draw time to know what pipeline object to create or retrieve.

The pipeline object problem

Pipeline objects are expensive to create. On most drivers, constructing one stalls the CPU for several milliseconds while the driver compiles the final shader variant — the one that knows the exact input layout it will receive, the exact blend equation it will use, the exact render-pass format it is targeting. Do that at draw time without preparation and you get the hitches that make a frame budget unpredictable. This is shader compilation stutter: not a bug in the program, but a consequence of the mismatch between an API that deferred state assembly and one that requires it up front.

The layer's answer is a pipeline cache. The first time a particular combination of state is encountered, the object is created and stored, keyed by a hash of the relevant state fields. Every subsequent draw that matches the same combination retrieves the cached object in nanoseconds rather than milliseconds. The cache warms up across a session; the next session can often load the compiled objects from disk. But the first run through unfamiliar content always carries the cost, and any change to the underlying driver or hardware can invalidate the cache entirely, restarting the process.

Beneath the pipeline object itself, the layer also has to translate resource bindings. D3D11 binds textures, samplers and constant buffers individually to numbered slots on each shader stage. Vulkan groups resources into descriptor sets, with a layout declared in advance and matching the pipeline object. The layer has to infer what descriptor set layout the program would have needed had it been written for Vulkan, allocate descriptors in pools, update them as the D3D11 program swaps resources in and out, and keep those descriptors alive for as long as any in-flight frame might still reference them. Lifetime management here is not optional: a descriptor pointing at freed memory produces GPU undefined behaviour, which is a category of failure that does not announce itself politely.

The draw call itself, once all of this is assembled, is almost anticlimactic. Vertex count, instance count, index offset — these translate directly. The weight is entirely in the preparation: the state shadow, the pipeline lookup or creation, the descriptor updates. That is where the translation overhead actually lives, and why a compatibility layer's CPU cost is not evenly distributed across a frame but instead clusters around state-heavy sequences — UI rendering, shadow map passes, anything that switches shaders or render targets frequently. The frame time is not higher everywhere. It is higher in specific, predictable places, and understanding the mechanism tells you exactly which ones.