Add flydsl2flydsl examples with L1/L2/L3 compute-pattern grouping

[johayang-amd]

Summary

Adds new flydsl2flydsl benchmark tasks ported from ROCm/FlyDSL kernels/, each with kernel.py, config.yaml, and an execution harness:

• topk_gating_softmax, moe_sorting, silu_and_mul_fq, blockscale_preshuffle_gemm, fp8_gemm_4wave, fp8_gemm_8wave, preshuffle_gemm_v2, pa_decode_swa

It also:

• Adds the vendored FlyDSL helper modules these examples import under tasks/flydsl2flydsl/kernels/ (e.g. kernels_common.py, tensor_shim.py, mfma_*, fp8_gemm_utils, preshuffle_gemm, dpp_utils), so each task is self-contained.
• Updates tasks/flydsl2flydsl/README.md to group all flydsl2flydsl tasks by compute pattern rather than an arbitrary difficulty scale:
  • L1 — elementwise / per-row reduction
  • L2 — LDS or fused multi-step cooperation
  • L3 — MFMA GEMM / attention

Validation

All runnable tasks were validated with the Task Validator (run via Cursor on MI300X / gfx942). Per-task validation_report.yaml files and an aggregated summary are included in the PR.

• 12 active (gfx942) — all PASS, 10/10 checks each (config schema, source/symbol presence, compile, correctness, performance, correctness review, self-containment, gpu-hang, result-template compatibility):
  blockscale_preshuffle_gemm, flash_attn_func, fused_rope_cache, hgemm_splitk, layernorm, moe_sorting, pa_decode_swa, preshuffle_gemm_v2, rmsnorm, silu_and_mul_fq, softmax, topk_gating_softmax.
• 10 skip — not runnable on MI300X by design:
  • Other-arch catalog entries: gfx950 ×2 (fp8_gemm_4wave, fp8_gemm_8wave — CDNA4-only 16B buffer_load_lds), gfx1250 ×4, rdna/rdna3 ×3.
  • pa_decode_fp8 — depends on the external aiter runtime; it compiles and passes correctness/performance in an aiter-enabled image, but self-containment intentionally fails, so it is excluded from the default gate.

Correctness for every active task compares against a genuine independent reference (PyTorch/CPU), not a kernel-vs-kernel self-reference.

[irvineoy]

Thank you so much for your contribution. It's very helpful.

Here are some comments from my side:

Comment 1 — required validation process for new tasks

For this project, every newly added task should be validated by the Task Validator Agent before merge. Please run the Task Validator Agent across all new FlyDSL tasks added in this PR, using the latest available Codex or Claude Code models, and please include the validation results in the PR.

This is especially important here because the PR adds many new benchmark tasks and several catalog-only entries; we need confirmation that each runnable task has valid config, prompt construction, compile command, correctness command, performance command, and expected platform support behavior.

Comment 2 — blocker: pa_decode_fp8_kernel config still points to removed API

tasks/flydsl2flydsl/pa_decode_fp8_kernel/config.yaml still references the old API:

build_pa_decode_module

build_ps_reduce_kernel

build_v2_reduce_kernel

But the updated kernel.py in this PR appears to use the FlyDSL v0.2.0 persistent-scheduling API instead, with entries such as compile_pa_decode_ps, pa_decode_ps_launch, get_pa_metadata, and get_sw_ps_max_context_partition_num. The old build_* symbols are no longer defined.

That means the current compile command:

python3 -c "from kernel import build_pa_decode_module; build_pa_decode_module(1, 1, 1); print('compile ok')"

will fail at import time, so this active task cannot reach correctness or performance validation.

Please update compile_command and target_kernel_functions to match the real v0.2.0 API, or add explicit compatibility aliases if that is intentional. Ideally this should match the actual harness entrypoints.

[johayang-amd]

Thank you so much for your contribution. It's very helpful.

Here are some comments from my side:

Comment 1 — required validation process for new tasks

For this project, every newly added task should be validated by the Task Validator Agent before merge. Please run the Task Validator Agent across all new FlyDSL tasks added in this PR, using the latest available Codex or Claude Code models, and please include the validation results in the PR.

This is especially important here because the PR adds many new benchmark tasks and several catalog-only entries; we need confirmation that each runnable task has valid config, prompt construction, compile command, correctness command, performance command, and expected platform support behavior.

Comment 2 — blocker: pa_decode_fp8_kernel config still points to removed API

tasks/flydsl2flydsl/pa_decode_fp8_kernel/config.yaml still references the old API:

build_pa_decode_module

build_ps_reduce_kernel

build_v2_reduce_kernel

But the updated kernel.py in this PR appears to use the FlyDSL v0.2.0 persistent-scheduling API instead, with entries such as compile_pa_decode_ps, pa_decode_ps_launch, get_pa_metadata, and get_sw_ps_max_context_partition_num. The old build_* symbols are no longer defined.

That means the current compile command:

python3 -c "from kernel import build_pa_decode_module; build_pa_decode_module(1, 1, 1); print('compile ok')"

will fail at import time, so this active task cannot reach correctness or performance validation.

Please update compile_command and target_kernel_functions to match the real v0.2.0 API, or add explicit compatibility aliases if that is intentional. Ideally this should match the actual harness entrypoints.

Hi @irvineoy , thank you so much for the thorough review and the helpful comments. I've updated the PR according to your comments.

Comment 1 — We ran the Task Validator (via Cursor, on MI300X / gfx942) across all runnable FlyDSL tasks in this PR, and the per-task validation_report.yaml files plus an aggregated summary are now updated in the PR (latest commit a4d36e7).

12 active (gfx942) — all PASS, 10/10 checks each.
10 skip — not runnable on MI300X by design: 9 other-arch catalog entries (gfx950 ×2, gfx1250 ×4, rdna ×3) + pa_decode_fp8 (depends on the external aiter runtime, so it's excluded from the default gate).
If you'd rather we not commit the reports, we're happy to remove them — just let us know.

Comment 2 — Good catch, and thank you for flagging it. This is already addressed in the current head: pa_decode_fp8_kernel/config.yaml no longer references the removed build_* symbols and now matches the v0.2.0 API (compile_pa_decode_ps, get_pa_metadata, get_sw_ps_max_context_partition_num, pa_decode_ps_launch). Would you mind re-checking at a4d36e7? The older build_* references were likely from an earlier commit.

Thanks again for taking the time to look through this!

[irvineoy]

Hi, quick heads-up: we are currently working on a larger refactor #48 that moves the benchmark/runtime flow to a Docker-first environment. This touches a lot of shared infrastructure, so reviews and merges may be slower than usual for a bit.

Once that refactor lands, I’ll help rebase open PRs onto that one. Sorry for the delay, and thanks for your patience.

[irvineoy]

Hi, thanks again for the PR!

I rebased this branch onto latest main. One important update: all benchmarks/validation now need to run inside Docker, so please use the Docker workflow for future validation runs.

While validating the new FlyDSL tasks, I fixed a few issues reported by the task validator, including some task-level correctness / compatibility issues. I also added framework support for the new platform_support.required_arch and platform_support.status fields, so tasks can now be skipped early if they are marked status: skip or if their required architecture does not match the current target GPU.

One question about tasks/flydsl2flydsl/kernels/: I am leaning toward removing this shared top-level kernel folder and making each task fully self-contained by placing all required dependencies inside the individual task folder. This seems cleaner for Arena task packaging and validation. Does that sound okay to you?

There are still several skip/catalog tasks with schema and packaging issues that are not trivial to fix. Do you want to include them in this PR, or should we move them to a follow-up PR?

The affected tasks are:

• flydsl2flydsl/gemm_fp8fp4_gfx1250_kernel
• flydsl2flydsl/wmma_gemm_gfx1250_kernel
• flydsl2flydsl/moe_gemm_2stage_mxscale_gfx1250_kernel
• flydsl2flydsl/moe_gemm_2stage_wmma_gfx1250_kernel
• flydsl2flydsl/rdna3_f16_gemm_kernel
• flydsl2flydsl/rdna_f16_gemm_kernel
• flydsl2flydsl/rdna_fp8_preshuffle_gemm_kernel

[irvineoy]

Request changes

[johayang-amd]

@irvineoy Thanks for the comments! I've addressed both of your questions:

1. Shared top-level kernels/ → self-contained tasks: Agreed, and done. Since you'd already made the 12 active tasks self-contained, the top-level tasks/flydsl2flydsl/kernels/ was only referenced by the skip tasks. I removed it; all remaining tasks now vendor their own helpers and there's no shared top-level folder.

2. The 7 skip/catalog tasks: I removed them from this PR. The main reason is that they target gfx1250 / RDNA / RDNA3, and we don't have access to that GPU compute to actually validate them. They're preserved unchanged (along with the shared kernels/ helpers they depend on) on the flydsl2flydsl-skip-tasks-parked branch for future reference. The 2 gfx950 FP8 GEMMs (fp8_gemm_4wave / fp8_gemm_8wave) stay in the suite and keep using your status.

I also updated README.md and ARCH_SUPPORT.md to match (dropped the removed rows / candidate table, documented per-task vendoring, and pointed the parked kernels at the branch). So this PR now scopes to the 12 gfx942-runnable tasks (12 PASS / 0 WARN) plus the gfx950 skip entries.

Heads-up: the branch currently conflicts with main after #54 (multi-GPU parallel Docker runner). Those are all in the Docker/runner area (your changes), none overlap with my flydsl task edits.