Skip to content

Fix non-transposed Crout L1 offset - #34

Open
kerwtsai-amd wants to merge 1 commit into
ROCm:mainfrom
kerwtsai-amd:fix-pdpancrN-l1-offset
Open

Fix non-transposed Crout L1 offset#34
kerwtsai-amd wants to merge 1 commit into
ROCm:mainfrom
kerwtsai-amd:fix-pdpancrN-l1-offset

Conversation

@kerwtsai-amd

@kerwtsai-amd kerwtsai-amd commented Aug 15, 2026

Copy link
Copy Markdown

Summary

  • Fix the non-transposed Crout leaf launcher to shift L1 by its column offset instead of a transposed-layout row stride.
  • Prevent recursive leaves with a nonzero ICOFF from accessing beyond the NB * NB L1 allocation.

Root cause

HPL_pdpancrN() is the Crout leaf panel factorization for non-transposed L1. Its launcher used L1 + jj * PANEL->jb, copied from the transposed variant. Transposed layout uses row + column * NB, where ICOFF * NB is correct; non-transposed layout uses column + row * NB, so the contiguous base shift is only ICOFF (jj). The kernel body already uses N-layout indexing such as L1[t * NB + jj].

For recursive leaves with ICOFF > 0, the old base can make the decisive store reach (ICOFF + t) * NB + j, beyond the NB * NB allocation. Because dipiv follows L1, this can corrupt pivots or fault directly.

Reproduction

A full-size MI355X/gfx950 run with N=540672, NB=1024, P=2, Q=4, PFACT=Crout, RFACT=Crout, NBMIN=4, NDIV=2, and L1=no-transposed faults before producing a WR result or residual:

private_seg_size=0, group_seg_size=20480
Memory Fault Error [...] kernel: void pdpancrN<1024>(...)

PFACT=1 with L1=1 selects this leaf; RFACT controls the recursive driver but does not itself select pdpancrN.

Test plan

  • Ran all six panel-factorization variants (llN, llT, crN, crT, rlN, rlT) at NB=896 and NB=1024 on MI355X/gfx950; all 12 residual checks PASSED.
  • Ran fixed crN at N=36864, P=2/Q=4: approximately 2.117e4 GFLOP/s at NB=896 and 2.073e4 GFLOP/s at NB=1024; both PASSED.
  • Covered crN at P=1/Q=8, P=4/Q=2, and N=18432.
  • Confirmed transposed controls are unaffected; pre/post-fix crT residuals are bit-identical.

HPL_pdpancrN() offsets its L1 base pointer by ICOFF * PANEL->jb, which is the
strided shift the transposed variants need. In the non-transposed layout the
kernel indexes L1 as L1[(JJ + j) * NB + i], so the JJ argument the launcher
already passes supplies the strided shift itself; the base pointer must supply
the shift on the contiguous axis, + ICOFF.

The recursion driver HPL_pdrpancrN() hands the leaf the diagonal sub-block of
L1 at Mptr(L1, ICOFF, ICOFF, PANEL->jb), i.e. L1 + ICOFF + ICOFF * jb. The leaf
splits that between the base pointer and JJ, so applying the strided shift in
both places and never applying the contiguous one walks off the end of L1,
which holds exactly nb * nb doubles (PANEL->L1 = A0 + ml2 * JB and
PANEL->dipiv = PANEL->L1 + JB * JB). The maximum reachable offset is in bounds
only for ICOFF == 0.

The symptom is a GPU memory access fault at any NB whenever the recursion
produces a leaf with ICOFF >= 1, which is essentially always -- including
NB=896, the value the README recommends for MI355X. The fault does not abort
the MPI job, so an affected run hangs rather than exiting.

HPL_pdpanllN() and HPL_pdpanrlN() already use L1 + jj; only the Crout variant
carried the transposed form.
@kerwtsai-amd
kerwtsai-amd requested a review from pbauman as a code owner August 15, 2026 07:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant