Katkat

Optimize the Memory Accesses of a GPU Matrix Transpose

AMDSoftware Engineer · Onsite

Last updated

Analyze row-major GPU transpose accesses and use tiled shared staging for coalesced reads and writes, with barrier safety, edge handling, and device-specific bank checks.

Analyze and improve a GPU matrix-transpose kernel. For a row-major matrix, a naive mapping often makes either reads or writes contiguous across neighboring lanes, while the other side becomes strided.

Constraints & Assumptions

The original ROCm kernel listing is not supplied. Use this self-contained practice model: input A has R rows and C columns in row-major order, and output B has C rows and R columns with B[col,row] = A[row,col]. Explain a tiled implementation using explicitly shared scratchpad memory. Tile dimensions must fit the target device's thread and memory limits.

Clarifying Questions

Which index varies across adjacent lanes? What transaction/coalescing rules and scratchpad bank organization apply? Are dimensions multiples of the tile size? Are input and output distinct allocations?

Follow-up questions

  • Why can changing thread order simply move the striding problem to the other side? Why must all participating threads reach the barrier? Is padding by one element always optimal on every GPU?