Glossary#

Terms#

backend#

The integration that lets a kernel compiler recognize cuda.coop calls and generate CUDA code for them. Numba-CUDA-MLIR is the first supported backend. See registration.

blocked#

A layout in which each thread owns consecutive elements of a tile. With K items per thread, thread t owns tile positions t * K through t * K + K - 1. See blocked versus striped.

common API#

The backend-independent API exposed through from cuda import coop. It describes operations on thread groups, values, and storage. Support for particular operations and argument types depends on the backend. Qualified APIs provide backend-specific extensions. See choosing an API.

family#

A group of related primitives that share semantics and implementation. The Load/Store family includes load and store. Families organize implementation modules; a thread group describes the threads executing a primitive. See implementation families.

payload#

The values contributed or received by one thread. ThreadData(K) describes a fixed-size payload of K items. Some operations also accept scalars or backend-specific arrays. See thread data.

phi#

A compiler intermediate representation (IR) operation that selects a value according to the control-flow path taken into a block. For example, after an if statement assigns different values to a variable, a phi selects the value from the branch that ran. At a loop header, it can select the initial value or the value from the previous iteration. Comments refer to these alternatives as phi inputs.

primitive#

A cooperative operation provided by cuda.coop, such as load or store. Each primitive defines which threads participate, how it uses their data, and where its results are available. See participation and synchronization.

qualified API#

A backend’s namespace, such as cuda.coop.numba_mlir. It provides the common operations and compiler-specific extensions. See namespace choices.

striped#

A layout in which consecutive threads own consecutive tile elements at each per-thread item position. For G threads, thread t owns tile positions t, t + G, t + 2 * G, and so on. See blocked versus striped.

temporary storage#

Shared-memory scratch used internally by a primitive. The compiler allocates it automatically when needed. An explicit TempStorage descriptor can control allocation sharing and synchronization for supported operations. Keep application data in payloads or arrays. See the temporary-storage FAQ.

thread group#

The threads participating in a primitive, such as a block, a physical warp, or a logical group within a warp. A thread’s rank identifies its position within that group. See groups.

tile#

The sequence of values processed by one group in an operation. With G threads and K items per thread, a full tile has G * K values. valid_items in Load and Store selects a prefix of that sequence. It counts tile elements, not elements per thread.

Blocked versus striped#

Both layouts distribute the same tile across threads. They differ in which thread owns each position. For four illustrative threads and two items per thread, a tile of positions 0 through 7 is distributed as follows:

Thread rank

Blocked: items[0], items[1]

Striped: items[0], items[1]

0

0, 1

0, 4

1

2, 3

1, 5

2

4, 5

2, 6

3

6, 7

3, 7

For group size G, items per thread K, thread rank t, and local item slot i:

Layout

Tile position owned by items[i] in thread t

Owner of tile position p

Blocked

t * K + i

Thread p // K, slot p % K

Striped

t + i * G

Thread p % G, slot p // G

The four-thread table illustrates ownership, not a supported physical CUDA warp size. A physical warp has 32 threads.

Layout describes the values a caller sees. The memory-access algorithm may use a different intermediate layout. For example, load(..., algorithm="transpose") reads striped values, then rearranges them into blocked payloads. algorithm="striped" leaves the payloads striped.

Store expects the layout selected by its algorithm. Combining a striped Load with a direct Store without conversion changes the output order. ThreadData does not carry a layout tag that corrects this mismatch.

Follow the values in the Load and Store visualizations. The programming guide explains these layouts.