add gfx950-specific MLA fp8 decode kernel

[charlieguo1106]

Summary

• Add a gfx950-specific MLA FP8 decode kernel path using ds_read_b64_tr_b8.
• Route FP8 MLA decode on gfx950 to the new kernel while keeping the existing path for other architectures.
• Extend MLA decode benchmark/test tooling with stable repeated timing and optional aiter comparisons.

Test plan

python tests/kernels/test_mla_decode.py --bench_aiter

MI3xx

MI35x

[coderfeli]

Thanks for adding the gfx950-specific path. I think this needs one more round before merge because the new target path is not actually covered by the current test, and the metadata contract is unclear.

Main concern: tests/kernels/test_mla_decode.py now skips the whole pytest on gfx950, with the reason that AITER emits a folded nh=16 work-info layout while this FlyDSL kernel only supports the native nh=128 layout. But kernels/mla_fwd_decode.py routes fp8/fp8 MLA decode on gfx950 to the new kernel, and the public API still consumes caller-provided work_indptr / work_info_set. As written, CI can pass on gfx950 while never exercising the new gfx950 kernel through pytest, and a caller reusing the same AITER metadata path would hit the newly routed kernel with the incompatible layout.

Please either add a gfx950 test path that generates/uses the native nh=128 metadata expected by this kernel, or make the launcher/API contract explicit and fail loudly when the provided metadata is the folded gfx950 layout. Also please align the CLI behavior with pytest: running python tests/kernels/test_mla_decode.py on gfx950 still calls run_single() despite the same incompatibility that causes pytest to skip.

Smaller follow-up: the routing uses arch.startswith("gfx950"). If this is meant for the CDNA4 gfx95x family, please use the same gfx95* detection style as the rest of the repo or add a comment that this is intentionally gfx950-only.