Optimize the Memory Accesses of a GPU Matrix Transpose
AMDSoftware Engineer · OnsiteLast 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?
Solution walkthrough is for members
Get the full walkthrough with reference code and complexity analysis, plus Kitty Coach at 300 messages a day. Hints, the code runner and community answers stay free.