The GPU & the Graphics Pipeline

01Why a GPU is shaped this way

A 1080p frame has about two million pixels, and each one runs a small shader program, usually the same one as its neighbors. A CPU is built for the opposite job. It spends transistors fighting latency: deep caches, branch prediction, out-of-order execution (running later instructions while an earlier one waits on memory), all to finish one thread's next instruction as soon as possible. A GPU spends them on throughput: thousands of ALUs, the lanes that do the arithmetic, running the same program over huge batches of data. It hides memory latency by keeping many groups of work in flight and switching to another group whenever one is waiting^[1]. The pipeline is an assembly line: stages run in sequence on any one triangle, but all stages are busy on different work at once.

The parallelism has a specific shape: SIMT (single instruction, multiple threads). NVIDIA runs threads in groups of 32 called warps, which step through one shared instruction stream together; "a warp executes one common instruction at a time," and when threads in a warp take different branches the warp "executes each branch path taken, disabling threads that are not on that path"^[2]. AMD's equivalent, a wavefront, is 32 or 64 threads depending on the architecture (RDNA runs both wave32 and wave64; GCN and CDNA use 64)^[3].

02The logical pipeline

When Vulkan asks you for a vertex shader, a rasterization state, a depth state and a blend state, it's asking you to fill in the stages of one assembly line. A triangle flows through a fixed sequence of stages. Some are programmable (you write a shader), some are fixed-function: built into the hardware, so you pick options but can't replace the logic. In order^[4]:

The vertex shader runs once per vertex and outputs a clip-space position. After clipping, the GPU does the perspective divide (xyz / w, which makes far things smaller) to get NDC, normalized device coordinates where the visible screen runs from −1 to 1. Then the viewport transform maps NDC to framebuffer pixels. Both are fixed-function, and the 3D Math tutorial derives them, so this page only uses them. Vulkan's clip volume is 0 ≤ z_c ≤ w_c (depth range [0,1]), and a negative viewport height performs the Y-flip^[5].

03Rasterization

Three vertices land on the screen at fractional pixel positions, and the GPU has to decide, for millions of pixels a frame, which ones the triangle covers. Rasterization is that decision. The trick, from Pineda's 1988 paper, is the edge function: each edge defines a linear function E(x,y) that is zero on the edge's line, positive on one side and negative on the other^[6]. A sample point is inside the triangle when all three edge functions agree in sign^[7].

The edge function from a to b, evaluated at point p, is a 2D cross product:

In words: the value is twice the signed area of the triangle formed by a, b and p. It's zero when p sits on the line through a and b, and its sign tells you which side p is on. Run it for all three edges; if all three have the same sign as the whole triangle's area, p is inside. Hover any term to see what it stands for.

Normalize the three edge values by their sum (the doubled triangle area) and you get the barycentric coordinates: three weights that add up to 1 and say how close the point is to each vertex. They interpolate any per-vertex attribute, such as a color or a texture coordinate. Each edge function changes by a constant when you step one pixel in x or y, so a hardware rasterizer can update them with adds, which is exactly why they map to cheap hardware^[6].

The widget rasterizes a textured quad as two triangles over a coarse grid, where each 6-pixel cell stands in for one framebuffer pixel:

04The 2×2 quad

A field of grass blades a pixel or two wide can cost several times more to shade than the same number of pixels on a wall. Part of the reason is that hardware doesn't shade pixels one at a time; it shades them in 2×2 quads. The quads exist for texture filtering. Choosing a mip level, one of the texture's precomputed half-size copies, needs the screen-space derivatives of the texture coordinates (ddx/ddy): how much they change from one pixel to the next. The cheapest way to estimate those is to subtract a pixel's value from its neighbor's within the quad^[8].

Because all four lanes are needed for that finite difference, even pixels outside the triangle in an edge quad get shaded; their output is discarded. These are helper pixels, and Giesen puts the cost at "between 25-75% of the shading work for quads generated for triangle edges"^[8]. A triangle that covers a single pixel still shades a whole quad: 4 lanes for 1 pixel, 75% wasted. A vertical sliver one pixel wide and 10 pixels tall, lined up inside one column of quads, touches 5 quads, so it shades 20 lanes for 10 pixels. Quad overshading is one of the main reasons small and thin triangles shade inefficiently (fixed per-triangle setup cost is another), and one reason engines use LODs, simpler versions of a mesh swapped in as it shrinks on screen, to keep triangles from shrinking to a few pixels.

05Perspective-correct interpolation

You draw a floor as a textured quad, two triangles, and the texture bends along the diagonal where they meet. The cause is interpolating in the wrong space. Perspective projection keeps straight lines straight but doesn't preserve distances: the far half of the floor covers fewer pixels than the near half. So a value that's linear across a surface in 3D is not linear across its projected image on screen, and interpolating an attribute with screen-space barycentrics directly is wrong for anything that isn't already screen-linear^[9].

The fix: interpolate attribute / w and 1 / w linearly (those are screen-linear), then divide at each pixel to recover the attribute:

In words: blend each vertex's attribute divided by its w with the ordinary screen-space weights, blend the 1 ÷ w values the same way, and divide the first result by the second. Vertices farther away (bigger w) count for less, which undoes the squashing perspective did to the far side. Hover any term to see what it stands for.

The software rasterizer below is built around that divide:

struct Vertex {            // already in screen space (post viewport transform)
    float screenX, screenY;   // pixel coordinates
    float oneOverW;           // 1 / clip-space w, precomputed per vertex
    float uOverW, vOverW;     // the attribute (u,v) already divided by w
};

// Edge function: signed doubled area of (a, b, p). Pineda's half-plane test.
static float edge(const Vertex& a, const Vertex& b, float px, float py) {
    return (px - a.screenX) * (b.screenY - a.screenY)
         - (py - a.screenY) * (b.screenX - a.screenX);
}

void rasterize(Vertex v0, Vertex v1, Vertex v2, uint32_t* framebuffer, int width, int height) {
    float area = edge(v0, v1, v2.screenX, v2.screenY);   // doubled signed area; sign = winding
    if (area <= 0) return;   // 0: degenerate. < 0: the other winding, culled like a back face
    float invArea = 1.0f / area;

    for (int y = 0; y < height; ++y)
    for (int x = 0; x < width; ++x) {
        float sx = x + 0.5f, sy = y + 0.5f;     // sample the pixel center
        float w0 = edge(v1, v2, sx, sy);             // the three edge functions
        float w1 = edge(v2, v0, sx, sy);
        float w2 = edge(v0, v1, sx, sy);
        if (w0 < 0 || w1 < 0 || w2 < 0) continue;  // inside iff all three share area's (positive) sign

        float l0 = w0 * invArea, l1 = w1 * invArea, l2 = w2 * invArea;  // barycentrics

        // Interpolate 1/w and attr/w linearly (these ARE screen-linear)...
        float invW = l0*v0.oneOverW + l1*v1.oneOverW + l2*v2.oneOverW;
        float uW   = l0*v0.uOverW   + l1*v1.uOverW   + l2*v2.uOverW;
        float vW   = l0*v0.vOverW   + l1*v1.vOverW   + l2*v2.vOverW;
        // ...then divide at the pixel to recover the true attribute.
        float u = uW / invW, v = vW / invW;
        framebuffer[y * width + x] = shade(u, v);
    }
}

#[derive(Clone, Copy)]
struct Vertex {            // already in screen space (post viewport transform)
    screen_x: f32, screen_y: f32,   // pixel coordinates
    one_over_w: f32,               // 1 / clip-space w, precomputed per vertex
    u_over_w: f32, v_over_w: f32,   // attribute (u,v) already divided by w
}

// Edge function: signed doubled area of (a, b, p). Pineda's half-plane test.
fn edge(a: &Vertex, b: &Vertex, px: f32, py: f32) -> f32 {
    (px - a.screen_x) * (b.screen_y - a.screen_y)
        - (py - a.screen_y) * (b.screen_x - a.screen_x)
}

fn rasterize(v0: &Vertex, v1: &Vertex, v2: &Vertex, framebuffer: &mut [u32], width: usize, height: usize) {
    let area = edge(v0, v1, v2.screen_x, v2.screen_y);   // doubled signed area; sign = winding
    if area <= 0.0 { return; }   // 0: degenerate. < 0: the other winding, culled like a back face
    let inv_area = 1.0 / area;

    for y in 0..height {
        for x in 0..width {
            let (sx, sy) = (x as f32 + 0.5, y as f32 + 0.5);   // pixel center
            let w0 = edge(v1, v2, sx, sy);
            let w1 = edge(v2, v0, sx, sy);
            let w2 = edge(v0, v1, sx, sy);
            if w0 < 0.0 || w1 < 0.0 || w2 < 0.0 { continue; }   // inside iff all three share area's sign

            let (l0, l1, l2) = (w0 * inv_area, w1 * inv_area, w2 * inv_area);   // barycentrics
            // Interpolate 1/w and attr/w linearly, then divide at the pixel.
            let inv_w = l0*v0.one_over_w + l1*v1.one_over_w + l2*v2.one_over_w;
            let u_w   = l0*v0.u_over_w   + l1*v1.u_over_w   + l2*v2.u_over_w;
            let v_w   = l0*v0.v_over_w   + l1*v1.v_over_w   + l2*v2.v_over_w;
            let (u, v) = (u_w / inv_w, v_w / inv_w);
            framebuffer[y * width + x] = shade(u, v);
        }
    }
}

One subtlety: depth (z in NDC, which is already divided by w) is the special case that is screen-linear after projection, so the depth buffer interpolates it linearly with no divide. It's the other attributes that need the perspective-correct divide.

06The depth buffer

A character walks behind a wall, but the character was drawn second, so without help it paints right over the wall. A per-pixel depth buffer fixes that. It stores the closest depth seen so far at each pixel; each fragment compares its depth to the stored value and is kept or discarded. This resolves visibility independent of draw order, which is why you don't have to sort opaque geometry back-to-front.

The stored depth isn't distance. With Vulkan's [0,1] range, a point at distance z between the near plane n and far plane f stores:

In words: depth climbs from 0 at the near plane toward 1 at the far plane, but it follows 1 ÷ z, so it climbs steeply close to the camera and barely moves far away. Most of the buffer's values go to the space just past the near plane. Hover any term to see what it stands for.

The widget draws two overlapping triangles, always blue first, then red, with blue the nearer one:

07Early-Z

A room's walls, furniture and characters overlap, so many pixels get covered several times a frame. The API says depth testing happens after the fragment shader, but shading a pixel only to discard it for being behind a wall is wasteful. So hardware runs the depth test early, before the shader, whenever it can prove that gives the same result^[10].

08Immediate-mode vs tile-based

A post-process pass that runs fine on a desktop card can be far slower on a phone. A common reason is memory bandwidth, which mobile GPUs are built to avoid spending. There are two broad GPU architectures, and the split decides how you structure a frame on mobile.

• Immediate-mode (IMR), desktop NVIDIA and AMD: primitives are shaded in submission order against a framebuffer in main memory (the card's VRAM), with caches and compression absorbing much of the color and depth traffic. Desktop parts borrow some tiling: since Maxwell, NVIDIA's rasterizer walks screen tiles and buffers their pixel output on-chip^[14], but it doesn't hold back a whole render pass the way a mobile tiler does.
• Tile-based (TBR/TBDR), mobile Arm Mali, Imagination PowerVR, Apple, Adreno: the GPU bins the whole pass's geometry first (sorts each triangle into the screen tiles it touches), then shades one screen tile at a time in fast on-chip memory and writes only what you asked it to store. Arm's description of Mali: "a distinct two-pass rendering algorithm for each render target," with 16×16 tiles whose whole working set (color, depth, and stencil) stays on-chip^[12]. TBDR adds hardware hidden-surface removal, deferring shading until visibility is resolved per tile, so hidden fragments are never shaded^[13].

09The baked pipeline

A game hitches the first time a new material appears on screen. A common cause is the driver compiling GPU code for that material mid-frame, and the thing it compiles is a baked pipeline. Everything above (which shaders run, the rasterizer state, the depth compare op, the blend equation, the viewport) is configuration. The explicit APIs freeze it into one object. Vulkan: "each pipeline is controlled by a monolithic object created from a description of all of the shader stages and any relevant fixed-function stages"^[4], which it can then optimize as a whole and bind in one call.

That's the mental model for the next tutorial: you don't set pipeline state one stage at a time, you describe the whole pipeline once, compile it, and bind it. (Modern Vulkan adds dynamic state and shader objects that relax the bake-everything rule, and OpenGL's global state machine is the counterexample, so this is the explicit-API model, not a universal law.)

The widget walks one vertex through the stages so the data at each step is concrete:

Wrong answers, and why: the seam warp is an interpolation error (not z-fighting or winding); and SIMT vs SIMD is about software-visible width and divergence handling, not a fixed lane count or an inability to branch.

10Pitfalls

11What's next

With the model in hand, the next tutorial writes it for real: Your First Triangle in Vulkan, where this baked pipeline becomes a VkPipeline, the rasterizer and depth test become pipeline state, and the surface from the Platform & Window tutorial gets a swapchain, the rotating set of images the display shows. Then textures, then a real 2D renderer. The full path is on the series hub.

1. Tomas Akenine-Möller, Eric Haines, Naty Hoffman, et al. Real-Time Rendering, 4th ed., ch. 2–3. realtimerendering.com. The conceptual four-stage pipeline and the throughput-oriented GPU.
2. NVIDIA. CUDA Programming Guide, §3.2.2.1 "SIMT Execution Model." docs.nvidia.com. Warp = 32 threads, branch divergence serializes paths, and the SIMT-vs-SIMD distinction (software-visible width).
3. AMD. ROCm/HIP hardware docs and the RDNA Architecture whitepaper. gpuopen.com. Wavefront size is 32 or 64 depending on architecture (RDNA vs GCN/CDNA).
4. The Khronos Group. Vulkan Specification, "Pipelines." docs.vulkan.org. The stage order and the "monolithic" pipeline object baking shader and fixed-function state.
5. The Khronos Group. Vulkan Specification, vertex post-processing and VkViewport. docs.vulkan.org. The clip volume 0 ≤ z ≤ w, the perspective divide, and the negative-height Y-flip.
6. Juan Pineda. "A Parallel Algorithm for Polygon Rasterization." SIGGRAPH 1988. dl.acm.org. The linear edge function / half-plane test, computed incrementally.
7. Fabian Giesen. "A trip through the Graphics Pipeline 2011, part 6." fgiesen.wordpress.com. Edge-test coverage, the watertight top-left rule, and 2×2 quads.
8. Fabian Giesen. "A trip through the Graphics Pipeline 2011, part 7." fgiesen.wordpress.com. Early-Z as an as-if-consistent optimization and the features that disable it.
9. Fabian Giesen. "A trip through the Graphics Pipeline 2011, part 8." fgiesen.wordpress.com. Helper pixels, derivatives via finite differencing, and 25–75% edge-quad waste.
10. Scratchapixel. "Perspective-Correct Interpolation and Vertex Attributes." scratchapixel.com. Why screen-linear interpolation is wrong and the interpolate-attr/w-then-divide fix.
11. Nathan Reed. "Depth Precision Visualized." reedbeta.com. The 1/z precision problem and reversed-Z with a float depth buffer.
12. Peter Harris (Arm). "The Mali GPU: An Abstract Machine, Part 2 - Tile-based Rendering." 2014. developer.arm.com. The two-pass tile-based architecture, 16×16 tiles, and the on-chip color/depth/stencil working set.
13. Imagination Technologies. PowerVR Architecture guide, "Tile-Based Deferred Rendering (TBDR)." docs.imgtec.com. TBDR defers texturing and shading until visibility is resolved; hidden-surface removal.
14. David Kanter. "Tile-based Rasterization in Nvidia GPUs." Real World Tech, 2016. realworldtech.com. Maxwell and Pascal use tile-based immediate-mode rasterizers that buffer pixel output on-chip.