メニュー
Analyze a captured FlyDSL kernel bundle with flyprof: read the roofline/occupancy (counters), tile advice, stall/bubble taxonomy (bubbles), and the ISA<->Python mapping (map). Use after `flyprof capture`, when you need to understand where a kernel spends its stall cycles and how the ISA lines up with the .py source.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Capture a rocprofv3 ATT (Advanced Thread Trace) for a FlyDSL kernel with flyprof, including kernel discovery, tile sizing, and handling empty/out-of-range dispatches. Use when you need to record a kernel's per-instruction trace before analysis, or when `flyprof capture` returned EMPTY_ATT / DISPATCH_OUT_OF_RANGE / NO_KERNEL_DISCOVERED.
Produce and act on a FlyDSL kernel optimization report with flyprof: synthesize the ranked bubble->FlyDSL-knob recommendations, read the ISA<->Python evidence, optionally apply one knob, and verify the change re-profiles better. Use when asked what to change to make a kernel faster, or to turn a captured bundle into an optimization plan.
Diagnose a failing flyprof command by its error code. Use when any flyprof command returns ok:false / a non-zero exit, to decide whether to stop, fix config, retry, or treat the result as a finding. Maps each error.code to a hard action so you don't loop.
Start here to profile a FlyDSL kernel on AMD CDNA (gfx950/MI350X). Router for the flyprof CLI: how to run the fixed capture->analyze->report workflow, read its JSON envelopes, and pick the right sub-skill. Use whenever asked to profile/analyze a kernel, find why a kernel is slow, build an optimization report, or capture an ATT trace for a FlyDSL kernel.
| name | flyprof-analyze |
| description | Analyze a captured FlyDSL kernel bundle with flyprof: read the roofline/occupancy (counters), tile advice, stall/bubble taxonomy (bubbles), and the ISA<->Python mapping (map). Use after `flyprof capture`, when you need to understand where a kernel spends its stall cycles and how the ISA lines up with the .py source. |
| allowed-tools | Bash(flyprof:*), Read |
All of these are pure data transforms over the bundle (no GPU). Run them against
the --bundle DIR produced by flyprof capture.
flyprof counters --bundle DIR -f json (if a PMC pass was captured) →
data.roofline.bound (memory/compute/latency), data.memory.l2_hit_rate,
data.compute.mfma_inst_frac, data.lds.bank_conflict_pct.flyprof tile <k> --shape … --dtype … -f json → occupancy/LDS/regime if you
want the pre-capture estimate (and min_bk_to_cross_ridge).flyprof bubbles --bundle DIR --tag big -f json → data.stall_taxonomy.by_class
(ranked), data.hotspots (top stalls + waitcnt_sources), data.inst_mix.flyprof map --bundle DIR -f json → data.mappings (ISA → .py:line + snippet),
data.src_mapped_pct, data.source_flamegraph.counters.memory.calibrated == false: the absolute HBM GB/s is an EA0-channel
lower bound. Trust the ratios (L2 hit, 32B-partial fraction, MFMA fraction)
and the bubble taxonomy for the bound decision — not the absolute bandwidth.vmcnt % is a memory
wait; a high lgkmcnt % is an LDS/SMEM wait; is_bubble:true marks the classes
that mean the wave is idle-waiting, not doing work.waitcnt_sources on a hotspot is the bubble attribution: the s_waitcnt is
waiting on those source lines' memory ops. That edge is what a fix must break.bubbles summary is cheap — call once. For one hotspot's full
per-instruction record use flyprof bubbles --detail <code_line>; for one source
line use flyprof map --code-line N / --source-line FILE:LINE. Never dump raw ATT.Each mapping carries confidence (exact when the snapshot source matched,
heuristic when only a suffix matched). Before publishing a perf claim about a
specific .py line, cross-check the hotspot's waitcnt_sources actually point at
the op you think is the cause.