| name | rocm-kda-pilot |
| description | Orchestrator for ANY FlyDSL GPU kernel optimization loop on AMD ROCm -- FlashAttention, GEMM, MoE (incl. MXFP4/fp8), and other FlyDSL kernels, on gfx942 / gfx950 / gfx1250. Use whenever the task is tuning or optimizing a FlyDSL kernel (raise MFU/TFLOPS, cut latency, fix a profiled bottleneck), not just FlashAttention. Combines ROCmKernelWiki, flyprof (flydsl-rocprof-cli), rocm-report-skill, benchmark discipline, and Humanize RLCR. For FlyDSL kernels profiling MUST go through flyprof + rocm-report-skill -- never hand-roll a rocprofv3 collection script. |
| allowed-tools | Read Bash Grep Glob |
ROCm KDA Pilot
Use this skill for any FlyDSL GPU kernel optimization loop on AMD ROCm, not
only FlashAttention. It is the orchestrator that combines ROCmKernelWiki (prior
art), flyprof (capture/analyze/triage), rocm-report-skill (evidence -> one
hypothesis), benchmark discipline, and the Humanize RLCR loop. Trigger it
whenever the task is to tune/optimize a FlyDSL kernel -- GEMM, MoE
(including MXFP4 per-1x32 fp4 and fp8 mixed), attention, or any other -- across
gfx942 / gfx950 / gfx1250.
Scope note: the mandatory flyprof chain below is specific to FlyDSL
kernels (flyprof drives the FlyDSL test harnesses). For a non-FlyDSL ROCm/HIP
kernel, the loop discipline and the no-hand-rolled-rocprofv3 rule still apply,
but use rocm-report-skill + ROCmKernelWiki over standard rocprofv3/ATT
artifacts instead of flyprof run.
Kernel families (all in scope)
This orchestrator is kernel-family-agnostic. Pick the harness + contract for the
family, then run the same loop discipline:
- FlashAttention (bf16/fp16/fp8): harness
tests/kernels/test_flash_attn_fwd.py;
contracts templates/flydsl_flashattn_gfx950{,_deep}_contract.md,
templates/flydsl_flashattn_fp8_gfx950_contract.md. Family specifics in the
FlashAttention section below.
- MoE 2-stage GEMM (MXFP4 / fp8 mixed): harness
tests/kernels/test_moe_gemm.py
- aiter
op_tests/test_moe_2stage.py; contract
templates/flydsl_mxfp4_moe_gfx950_contract.md (ROCm/FlyDSL#708). Provision with
scripts/new_flydsl_task.sh --template mxfp4.
- GEMM / other: use the closest harness in
tests/kernels/ and the tile /
rasterization priors in ROCmKernelWiki
(wiki/kernels/flydsl-preshuffle-gemm.md,
sources/blogs/blog-gemm-optimization.md); the same mandatory-tooling + loop
discipline apply. (If the FlyDSL checkout ships a project-local
gemm-optimization skill, prefer its M-regime tile table as priors.)
The FlashAttention-specific guidance (PR683 baseline, fp8 parity targets) is one
family's specialization; the mandatory tooling and loop discipline
sections apply to every family.
MANDATORY tooling -- do not hand-roll profiling
ROCm/FlyDSL kernel profiling goes through the verified user-level skill chain,
never a hand-written rocprofv3 collection script:
flyprof-usage -- first, if unsure of the CLI surface.flyprof-capture -- record the kernel's ATT trace (recon -> size -> capture).flyprof-analyze / flyprof-triage -- bucket the stall taxonomy and
name the top bubble class.rocm-report-skill -- convert rocprofv3 / ATT evidence into ONE concrete
optimization hypothesis.ROCmKernelWiki -- prior art, only when it changes the next decision.
Rules (binding):
- Never write a bespoke
rocprofv3 -i ... --output-format csv collection script
or a hand-rolled counter summarize.py. If you start to, stop and use
flyprof-capture + rocm-report-skill -- they are verified and produce
auditable, replayable bundles.
- A bottleneck claim or a deeper-lever decision ("stage2 is LDS-wait bound", "do a
pipeline/LDS rewrite") MUST cite a flyprof / rocm-report artifact. An unprofiled
bottleneck assertion is not evidence and a review should reject it.
- "Profile only to answer a named question" means use this chain to answer it --
it is NOT a license to skip profiling. A round drawing a profiling conclusion
without a fresh-enough flyprof artifact should be sent back.
If these skills are missing, run scripts/bootstrap.sh (it symlinks them into
~/.claude/skills and installs flyprof); scripts/preflight.sh verifies they are
available before the loop starts.
For the prep phase (issue -> worktree -> draft -> plan), use the companion
flydsl-task-setup skill, which provisions a fresh /sgl-workspace/FlyDSL-<slug>
worktree on rlcr/<slug> via scripts/new_flydsl_task.sh and stops at the human
plan-review gate. This skill covers the loop-execution side.
Two steps always stay human-gated and must not be auto-advanced:
- Plan review/refine of
.humanize/kernel-agent/refined-plan.md before the
loop starts.
- Loop start (
/humanize:start-rlcr-loop) with the exact locked
--base-branch.
FlashAttention family specifics (gfx950, bf16/fp16)
- Use PR683 as the working baseline unless the user gives a newer ref.
- Treat
tests/kernels/test_flash_attn_fwd.py as the canonical correctness and
benchmark harness.
- Generate the Humanize plan from
.humanize/kernel-agent/draft.md.
- Start RLCR from
.humanize/kernel-agent/refined-plan.md.
- Profile via the mandatory tooling chain above (
flyprof-capture ->
flyprof-analyze/triage -> rocm-report-skill; ROCmKernelWiki for prior
art) to answer each named question -- do not hand-roll rocprofv3.
- Preserve bf16/fp16, causal/non-causal, MHA/GQA, varlen, arbitrary seq_len,
split-K, and gfx942 fallback coverage.
- Never weaken correctness thresholds to make a candidate pass.
For FlyDSL fp8 FlashAttention (ROCm/FlyDSL#698):
- Provision with
scripts/new_flydsl_task.sh --template fp8.
- fp8 on gfx950 is
e4m3fn (not fnuz). Keep softmax max/sum accumulation in f32.
- Headline target is parity with the aiter asm fp8 pipeline (~2000+T) vs the
current bf16 baseline (~1300+T).
- fp8 is additive: the existing bf16/fp16 paths must not regress.
- fp8 correctness gate is looser than bf16 (
max_err < 5e-2, min_cos > 0.98)
but fixed in the plan -- never relax it mid-loop to force a pass.
- Before starting, read the first-fp8-loop lessons in
templates/flydsl_flashattn_fp8_gfx950_contract.md ("Lessons from the first fp8
loop") and results/loop-04-flashattn-fp8-gfx950.md: split the parity gate from
the correctness gate, capture a round-0 ATT trace (the kernel is stall-bound, not
compute-bound), falsify any precision NO-GO with a host fp8xfp8 numerics probe
first, and treat the packed-fp8 PV blocker as a transpose-load layout problem.
The loop should produce correctness evidence, benchmark evidence, candidate
lineage, failed-attempt notes, and exact reproduction commands.
