菜单
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
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.
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.
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.
基于 SOC 职业分类
| name | flyprof-report |
| description | 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. |
| allowed-tools | Bash(flyprof:*), Read, Edit, Write |
flyprof report is the synthesis step: it runs the knob rules engine over the
bundle's bubbles/counters/tile/capture artifacts and emits REPORT.md +
report.json + headlines.json. This is prep — it tells you what to change and
why; applying the change and re-measuring is a separate, deliberate act.
capture.json + an ATT dispatch (run
flyprof-capture). counters.json is optional but improves the bound call.flyprof report --bundle DIR -f json. Read:
- data.bound_type (memory/compute/latency) and data.headline,
- data.optimal — if true, the kernel is near the roofline; do not invent
an optimization, report that it's well-tuned,
- data.recommendations[] — ranked; each has evidence (the firing signal +
the source:line it maps to), knob, api, code_change, confidence.evidence.source line and confirm
the evidence.waits_on op is really the dependency you'd break. The full
bubble→knob catalog is references/bubble-knob-table.md.code_change to the kernel .py.flyprof run <kernel> --gpu 0 into a NEW bundle.report.json: did the rank-1 bubble's stall % drop? did bound_type
move toward the roof? Compare totals.stall_pct before/after.When you have a known-good profile, write a fixture (expected top bubble class,
non-zero mapped_pct, dispatch present). On a later run, compare against it.
Never relax the fixture to make a run pass — a "regression" that's really a
measurement artifact (wrong shape, parser grabbing the wrong line, empty dispatch)
must be diagnosed, not silenced. Empty/odd results are findings; investigate the
capture before trusting a perf delta.