Intel Xe · CuTe · GEMM

GEMM Shape Hierarchy Visualizer

See how the shapes required by an Intel Xe CuTe GEMM relate to each other, from the full problem down to one DPAS atom.

Problem (M,N,K) WGTile (BM,BN,BK) SGLayout (SGM,SGN,1) SGTile DPAS Atom MMA Repeats

1 · The complete hierarchy

One picture

ProblemM × N × K

→

WGTileBM × BN × BK

→

SGLayoutSGM × SGN × 1

→

SGTileBM/SGM × BN/SGN × BK

→

DPAS AtomAM × AN × AK

→

RepeatsRM × RN × RK

WGTile = SGLayout × MMARepeats × MMAAtom

BM = SG_M × Repeat_M × Atom_M
BN = SG_N × Repeat_N × Atom_N
BK =        Repeat_K × Atom_K

2 · Interactive configuration

Change the shapes

Work-group tile

Subgroup layout

SG_M

SG_N

SG_K

DPAS atom

Atom M

Atom N

Atom K

Valid configuration

3 · Derived shapes

What CuTe derives from your choices

Work-group tile

256 × 256 × 32

One work-group updates a BM × BN output tile while consuming BK values of K per mainloop step.

Subgroup tile

32 × 64 × 32

Derived as (BM/SG_M, BN/SG_N, BK) when K is not split across subgroups.

MMA repetitions per subgroup

4 × 4 × 2

How many DPAS atom positions each subgroup covers in M, N, and K.

4 · Subgroup grid

How the work-group C tile is divided

Relationship

Quantity	Formula	Value
Subgroups	SG_M × SG_N × SG_K	32
Work-items / WG	subgroups × 16	512
SG tile M	BM / SG_M	32
SG tile N	BN / SG_N	64

For the common 8×4×1 layout, 32 subgroups collectively cover the work-group's 256×256 C tile.

5 · One subgroup → DPAS atoms

Tile the subgroup tile with the hardware atom

Dimension equations

M: 32 / 8  = 4 repeats
N: 64 / 16 = 4 repeats
K: 32 / 16 = 2 repeats

Total = 4 × 4 × 2 = 32 atom applications

M×N atom positions for one K slice

There are 2 K slices, so this M×N atom grid is traversed twice.

6 · Validity rules

The shape constraints to remember

BM % SG_M == 0
BN % SG_N == 0

(BM / SG_M) % Atom_M == 0
(BN / SG_N) % Atom_N == 0

BK % Atom_K == 0

SG_K == 1     // normal non-split-K GEMM in this tutorial
subgroup_size = 16

Equivalent: BM % (SG_M × Atom_M) == 0 and BN % (SG_N × Atom_N) == 0

7 · Concrete BF16 example

Why 256 × 256 × 32 works

M dimension

256 = 8 × 4 × 8

SG_M=8, each subgroup gets 32 rows, then 32/Atom_M(8)=4 DPAS positions.

N dimension

256 = 4 × 4 × 16

SG_N=4, each subgroup gets 64 columns, then 64/Atom_N(16)=4 DPAS positions.

K dimension

32 = 2 × 16

BF16 DPAS has Atom_K=16; a work-group K tile of 32 therefore contains 2 DPAS-depth steps.

8 · Map to CuTe code

The types correspond directly to the visual model

using WGTile =
    Shape<_256, _256, _32>;
//          BM    BN    BK

using SGLayout =
    Layout<
      Shape<_8, _4, _1>,
      Stride<_4, _1, _0>
    >;
//       SG_M SG_N SG_K

using Tiled = typename TiledMMAHelper<
    MMA_Atom<XE_DPAS_TT<8, float, bfloat16_t>>,
    Layout<WGTile>,
    SGLayout
>::TiledMMA;

DPAS8×16×16

SGLayout8×4×1

WGTile256×256×32

→

TiledMMAcomplete ownership map

9 · Global GEMM

How the work-group tile covers the full problem

If the full problem is M=N=K=4096 and WGTile=256×256×32:

WG grid in M

4096 / 256

WG grid in N

4096 / 256

K-loop iterations

128

4096 / 32

The first two work-group dimensions determine where the output tile lives. The third dimension determines how much reduction work is consumed per mainloop iteration.