[johnl-amd]

Adds ROCm/FlyDSL as a federation source and vendors flydsl-kernel-authoring from it, so the nightly import keeps the catalog copy in step with FlyDSL, which becomes its source of truth.

This supersedes #266 and #269, which were closed pending FlyDSL #1305 and #1304. Both merged on Oct 18, so the upstream skill now carries its own skill card and evals, and SKILL.md has been split into references/. The earlier PRs pointed at a feature branch and a pre-split copy of the skill, so this is a regenerated declaration rather than a reopen. Original work is Felix Li's.

Declared license is Apache-2.0, matching FlyDSL's LICENSE and the skill card.

Draft until the two FlyDSL skills are reviewed together; #274 stacks on this one for flydsl-kernel-trace-analysis.

No walkthrough yet. The one on the old branch described the previous thin-entry-point design, where the catalog copy deferred to a local FlyDSL checkout, which is no longer how the skill works. Better written by someone who can run it on Instinct hardware.

The README catalog row is deliberately not here. Every row links to blob/main/skills/<name>/SKILL.md, which 404s on the external-reference check until the skill is actually on main. Same split as #248 then #255: the row follows in a separate PR once this merges.

Testing

• federate_skills.py --only flydsl-kernel-authoring: vendors at 6245f9b.
• publish.sh then check.sh: 0 errors, 12 skills, Cursor and Codex manifests up to date.
• federation.json hand-edited rather than regenerated, to avoid an unrelated reordering of the existing sources.

[danielholanda]

@johnl-amd Thanks for creating this PR on behalf of Felix. Can you confirm you were able run and verify that this skill is useful by itself?

[johnl-amd]

Manual test on MI300X hardware

I did a manual test of this skill on real hardware. I used one MI300X GPU. The GPU
target is gfx942.

The vendored copy is correct

The vendored copy agrees with the upstream folder at commit 6245f9b. All 9 files
are identical. I calculated the content hash again with
federate_skills.content_hash(). The result agrees with the hash in the marker
file.

The skill names 79 fx. and flyc. symbols. All 79 symbols are present in the
installed package. No symbol is absent.

The skill makes correct kernels

I installed the flydsl wheel, version 0.4.0. Then I ran the 4 upstream examples.
All 4 examples give correct results on the GPU:

Example	Result
01-vectorAdd	PASS
02-tiledCopy	correct
03-tiledMma	correct
04-preshuffle_gemm	correct, after you add the repo root to PYTHONPATH

Then I wrote a new kernel. I used only the instructions in this skill. The kernel
does a predicated saxpby operation. It uses the two calls make_layout_tv and
make_tiled_copy. I used the tensor shape 333 by 777. The two axis lengths are not
multiples of the tile. Thus the kernel must mask the data that is out of bounds.

The kernel compiled and ran. The maximum error is 0.0. The documented API operates
as the skill describes.

The two review evals are correct

I tested the technical statement in each eval.

Eval 1 says that const_expr(lane == 0) is incorrect. This is true. The compiler
refuses the code. It gives this message: cannot evaluate dynamic 'Boolean' as Python bool during tracing.

Eval 2 says that an explicit init selects runtime loop state. This is also true.
In ast_rewriter.py, the function _is_range_constexpr accepts only a literal
range_constexpr name. Thus range(0, 15, 1, init=...) goes to scf_range. The
Python integer bounds do not change this behavior.

You must match the ROCm version

To run a kernel, you must do 4 steps. These steps are not easy to find:

1. Install ROCm 7.2. The 0.4.0 wheel needs libamdhip64.so.7. ROCm 6.4 stops with
   an abort.
2. Install rocm-llvm and rocm-device-libs. If you do not, the compiler gives
   the unclear message lld invocation failed.
3. Install libxml2. The program ld.lld needs it.
4. Install the torch build for ROCm 7.2.

Step 4 is important. A torch build for ROCm 6.4 compiles the kernel correctly. But
the kernel then stops at launch with hipErrorContextIsDestroyed. The result
tensor stays full of zeros. This failure is difficult to diagnose.

The skill gives the correct ROCm version in its header. But no text tells you that
the torch build must also agree.

3 items to think about

1. The skill starts with the words "Repository: this checkout". Section 12 gives
   the commands pip install -e . and a build-fly/python_packages path. Thus the
   skill speaks to a person who has a FlyDSL checkout. A catalog user has no
   checkout. The skill does not mention pip install flydsl.
2. The skill points to 3 companion skills: build-flydsl, debug-flydsl-kernel
   and flydsl-tile-programming. All 3 skills are in the product repo. But this
   PR and Federate flydsl-kernel-trace-analysis from ROCm/FlyDSL #274 federate only 2 skills. Thus these 3 links have no destination in
   the catalog.
3. The commit 6245f9b is later than the tag v0.4.0. The most recent version on
   PyPI is 0.4.0. Thus a catalog user can install code that is older than the
   documentation. I found no problem that this causes.