Transpose kernels: coalesce the boundary and inspect bank mapping

For A with shape M by N, an out-of-place transpose stores B with shape N by M such that B[j,i]=A[i,j]. A metadata view can express that relationship by exchanging strides, but a dense row-major B requires actual data movement. A direct kernel can make one side contiguous across neighboring lanes and the other side strided. A tiled approach can read contiguous source regions, synchronize in shared storage, and have lanes write transposed regions with another favorable access pattern. The exact grouping determines coalescing on the target architecture.

Out-of-place conversion assumes input and output storage do not overlap in a way that changes unread values. An in-place transpose needs a different cycle or tile-exchange protocol; launching the same independent output kernel on aliased storage can create races. Partial tiles need masks on both load and store, while required cooperative participants still follow the synchronization plan. Include the conversion's allocation and lifetime in a pipeline analysis. Paying to convert once can be worthwhile across repeated consumers, but converting back after every operation can erase the expected gain.

Consider the 32-bank, four-byte-word shared-memory mapping described in the archived CUDA 12.8 guide, with one NVIDIA warp issuing distinct scalar word accesses. Successive words map to successive banks. For a row-major tile with pitch P words, a column access by lane r addresses word rP+c relative to an appropriately specified base. Pitch 32 sends all thirty-two distinct column words to one bank; pitch 33 spreads them across banks. This reasoning concerns that scalar access pattern, not every vector instruction, element width, or accelerator.

Multiple lanes reading the same shared word can use a broadcast path rather than behaving like thirty-two distinct conflicting addresses. Distinguish that case from a column with equal bank indices but different words. Adding a padding column changes pitch and storage use while leaving the logical tile dimensions unchanged. Swizzling is another layout technique with its own mapping. An access model can predict a conflict mechanism, but measured speed also depends on global traffic, barriers, occupancy, instruction behavior, and compiler choices. Avoid promising a thirty-twofold kernel speedup from a bank-count calculation.

Compare a strided consuming kernel with a conversion-plus-contiguous-consumer path using identical values, precision, and output semantics. Report standalone conversion bandwidth and end-to-end latency separately. A copy-like logical byte count can produce an effective bandwidth even when measured device-memory traffic differs through caching or extra transactions. Use profiling evidence to test the proposed bank or coalescing bottleneck. Recheck tails and aliasing after changing tile layout, because padding can fix one access pattern while breaking a hard-coded stride elsewhere.

The modular lab shows only the arithmetic pattern in a smaller domain. Reset, set m=16 and additive step a=0, predict period one with every residue zero, then Play or Step. Separately Reset, set m=16 and a=1, predict period sixteen, then Play or Step. These are reachable controls; the instrument cannot set thirty-two banks or pitch thirty-three. It illustrates all-equal versus spread residues, not a bank-conflict simulator or timing model. Derive the actual thirty-two-bank example separately and keep its architecture assumptions visible.