How a GPU actually draws

Half of KytyPS5 is graphics, and the graphics code assumes you know how the hardware works — not how an API looks. This chapter covers the hardware model.

The pipeline

To draw a triangle, a GPU runs a fixed sequence of stages. Some are programmable (you supply a shader), some are fixed-function (configured by registers):

Separately, compute shaders bypass all of this: they run a grid of threads doing arbitrary work, used for physics, culling, post-processing and — in Kyty — for detiling textures.

How shaders actually execute: waves and lanes

This is the part that trips people up, and it is essential for Shaders: RDNA 2 → SPIR-V.

A GPU does not run one shader invocation at a time. It runs a wave — 32 or 64 invocations — in lockstep on one instruction stream. Each invocation is a lane. One instruction, executed simultaneously for all lanes on their own data.

So what happens at an if? Lanes can take different logical paths, but the wave shares an instruction stream. Instead the hardware keeps an execution mask: a 64-bit register where bit n enables lane n. Branching is implemented by masking:

          // if (x > 0) { A } else { B }
v_cmp_gt_f32  vcc, v0, 0      compare in every lane → 64-bit result in vcc
s_and_saveexec_b64  s[0:1], vcc   enable only lanes where the test passed
          … vector code for A — masked lanes do not update results …
s_andn2_b64   exec, s[0:1], exec  flip to the other lanes
          … code for B …
s_mov_b64     exec, s[0:1]        restore

In this example both vector instruction sequences are visited and disabled lanes do not update their vector results. Scalar instructions are wave-wide, and scalar branches can skip blocks; EXEC masking is not a universal rule for every instruction. This is why GPU code is fast when threads agree and slow when they diverge — and, more importantly for us, why GPU control flow is data manipulation rather than program structure. Recovering structure from it is the hardest job the shader recompiler has.

Descriptors: how a shader reaches a texture

In a PC API you call BindTexture(slot, texture). On RDNA 2 there are no slots. A texture is described by a descriptor — a packed block of bits holding its address, format, size, tiling and swizzle — and the shader simply has that block in its registers, or loads it from memory itself.

AMD calls these "sharps":

You can decode real ones here. The bit layouts are taken directly from Kyty's shaderBindings.h:

Tiling: textures are not stored in rows

A linear image stores pixel (x, y) at base + y*pitch + x*bpp. GPUs do not do this, because a shader sampling a texture reads a 2D neighbourhood, and a linear layout puts vertically adjacent pixels far apart in memory.

Instead pixels are interleaved into small blocks so that a 2D neighbourhood lands in one cache line. AMD has several schemes — 256 B, 4 KB, 64 KB, plus special layouts for render targets, depth buffers and partially-resident textures — each with its own swizzle function and alignment rules that vary with bytes-per-pixel and mip level.

Guest memory holds tiled data. Vulkan wants either linear data or its own opaque layout. Converting between them is The Vulkan backend.

Kyty targets Vulkan 1.3. You do not need to be able to write a Vulkan renderer to read this book, but you need the vocabulary and one key idea: Vulkan is explicit about everything, which is both why it suits an emulator and why it makes some things awkward.

The objects you will meet

SPIR-V, and why it is stricter than machine code

Vulkan does not accept GLSL or HLSL. It accepts SPIR-V: a binary intermediate language of 32-bit words. Every value has a declared type, every capability used must be requested, and — critically — control flow must be structured.

Structured means: every conditional branch declares in advance where its two paths reconverge (the merge block), and every loop declares both its merge block and its continue target. In SPIR-V assembly:

OpSelectionMerge %merge None      "these branches rejoin at %merge"
OpBranchConditional %cond %then %else
%then = OpLabel
  ...
  OpBranch %merge
%else = OpLabel
  ...
  OpBranch %merge
%merge = OpLabel

Compare that with the RDNA 2 snippet in this topic, which had no merge point at all — just mask manipulation and fall-through. Reconstructing the declarations SPIR-V demands, from code that never had them, is the single hardest pass in the recompiler, and it is allowed to fail: there is a documented fallback for shaders whose control flow cannot be structured.

A worked mapping

To make the shape of the translation concrete, here is one line of the same operation at four levels:

Multiply is easy. The work is in the thousand cases that are not: packed 16-bit maths, saturating conversions, cross-lane shuffles, image sampling with a dozen modifier bits, buffer loads that need bounds checking SPIR-V does not provide for free.