Thirteen AI accelerators, drawn the same way
Every vendor names its parts differently — a compute unit, an Xe-core, a streaming multiprocessor, a Tensix tile — and every vendor draws its own block diagram at its own level of detail. These thirteen are drawn to one structure, so you can click from the card down to the thing that actually does the multiply and compare like with like. Ten of them carry memory of their own. The other three share the machine's: two GPU blocks living inside a CPU package and one superchip, each reading the same pool its own CPU uses — and that difference is visible on their maps.
Cross-vendor matrix
The same ten questions asked of each part. A cell reads “—” where the figure is unknown, rather than an estimate.
Three of the row labels are links: the rows whose answer is a RATE that more than one vendor publishes open a page comparing that rate across every part, as a table and as bars. The rest stay plain, because a row naming a part has nothing to chart and a row holding a count or a capacity is not a throughput.
Numeric formats
What each matrix engine accepts as an operand, smallest first, and what it accumulates into. The accumulator is the column usually left out, and without it a narrow operand reads as narrow arithmetic: almost every engine here multiplies in 4, 6 or 8 bits and adds into 32.
Keyed by architecture rather than by card, because this is an architectural property — the three Blackwell parts answer identically, and so do the four Tenstorrent cards. A cell reads vector where the format is a general ALU type but not a matrix operand, and convert where it must be widened before the engine will take it. Both are “supported”; neither runs at matrix rate.
A format name is a link where more than one part has a published rate for it. Those pages carry two charts — the vector lanes and the matrix engine, kept apart because a lane's multiply-add and a matrix array's cell are different units of work — with dense and sparse figures on separate charts and the accumulate column carried through from this table. The formats left as plain labels are the ones no vendor publishes a comparable rate for.
Private to one column
Formats from the table above for which one architecture is the only path. A convert cell counts as a path, so a format another architecture only widens is not listed. The rows are read off those cells.
How to read these diagrams
Every page carries two views of the same part, because they answer different questions.
The die map comes first: every block on the die drawn at its own place on one grid. This is the view that shows what a spec sheet cannot — which edge the memory controllers sit on, how many cores one L2 has to serve, which column of tiles a memory channel feeds. Hover a block for its detail, use the filter chips to isolate one class, and click a block to open it below.
The hierarchy follows: the card opens into its die, the die into its clusters, and down to the thing that actually does the multiply. Click any block marked open ›, use the breadcrumb to come back out, press Esc to go up one level. Every view has its own URL, so a link can point straight at a single SIMD32 inside a compute unit.
One map is real and the rest are logical, and each page says which it is. Wormhole and Blackhole have SoC descriptors giving every tile's NOC coordinate, so those maps are the actual grid, drawn in the vendor's own coordinates. The GPU parts have block diagrams but no per-unit geometry, so those maps take the vendor's arrangement and lay it out for legibility — not to scale, and not to physical position. On a harvested part the disabled units are drawn struck through so the cut is visible at a glance; the count is real and the placement is illustrative. Each page lists its sources.