Look at a die photo of a modern GPU and squint. Underneath the marketing renders is something almost agricultural: the same rectangle, stamped out in neat rows, over a hundred times. That rectangle is the Streaming Multiprocessor — the SM — and it is the GPU's entire personality in one repeatable tile. In the last module you measured the machine from the outside: FLOP/s, bandwidth, the roofline. This module opens the lid. Everything a GPU does — every warp scheduled, every register read, every divergent branch and coalesced load — happens inside an SM, and the whole chip is just that story times a hundred, plus a big L2 cache and some memory controllers to feed it.

Learn one SM thoroughly and you have learned the GPU. That is this lesson's tour.

The tour: four partitions and a shared ground floor

A representative SM is organised as four processing partitions — think of them as four quarter-SMs living in one building. Each partition owns, privately:

• a warp scheduler — picks which warp issues an instruction this cycle (it gets the whole next lesson);
• a slice of the register file — the SRAM where its resident warps' registers live permanently (lesson after that);
• 32 ALU lanes for FP32 and INT32 arithmetic — one lane per thread of a warp, so a warp's instruction occupies the partition for a cycle or two;
• a tensor core — a matrix-multiply engine we name now and open in module 11;
• load/store units — the ports through which memory requests leave;
• SFUs (special function units) — a few lanes of hardware for the transcendentals: \sin, \cos, 1/x, \sqrt{x}, 2^x, computed fast and slightly approximately.

Downstairs, shared by all four partitions, sit the L1 data cache / shared memory block (one pool of SRAM, split between the two roles) and the instruction cache. Step through the floor plan:

The numbers, in one table

Vendors vary the exact figures generation to generation, but a representative modern SM looks like this — worth absorbing, because every performance argument in this module is arithmetic over these quantities:

Read the warp-slot row twice. An SM doesn't just run warps — it houses them: up to 48 or 64 warps' complete state (program counters, registers, predicate masks) is held on-chip simultaneously, all the time. That is 1,536–2,048 thread contexts resident in one tile. The "multitude of threads" you met when you first saw SIMT is not a software abstraction — it is physically installed in the register file, which is exactly what makes switching between warps free. The next two lessons are entirely about that fact.

From tile to chip: why the GPU is a repeated rectangle

Zoom back out. A full GPU is dozens to hundreds of identical SMs, wired to a large L2 cache (megabytes, shared by everyone) and a ring of memory controllers talking to GDDR or HBM DRAM. That's the whole chip: tile × N, plus plumbing. The tiling is not laziness — it is the business model:

• Scaling. Design and verify one SM, then choose the product by the stamp count: 20 SMs for a laptop part, 80 for a gaming flagship, 140 for a datacentre card. Same engineering, whole product line.
• Yield and binning. A huge die will have manufacturing defects — you learned in the back-end module that yield falls fast with area. On a CPU, a defect in the core's scheduler kills the chip. On a GPU, a defect usually lands inside one SM out of 84 — so the vendor fuses that SM off and sells the die as the 80-SM model one shelf down. Almost every "cut-down" graphics card you can buy is a flagship die with its scars disabled. The repeated tile turns fatal defects into a discount SKU.

This is why GPU generations can double their SM count and just… work. Nothing inside the SM needed to change; the tile was the unit of both design and repair.