docs(ck-tile): describe gfx1250 as CDNA5 rather than RDNA4

[ozturkosu]

JIRA ID : AICK-2249

Summary

gfx1250 is labelled RDNA4 in several comments and one CI config string. The product generation is CDNA5. This corrects the label.

Comments and one JSON _comment only — no code, no behaviour change.

Raised in review of #12173, where the same value was corrected in arch_specs.json. Split out because renaming terminology across the tree does not belong in an LDS-capacity change.

Why the RDNA4 label was there

It was not arbitrary. gfx1250 has no MFMA units and multiplies through WMMA, which is an RDNA-family instruction, and the gfx12xx numbering points the same way. The observation about the instruction path was right; using it as a generation label was not.

arch.hpp already draws exactly this distinction:

GFX1250 is its own standalone family. Although it shares the RDNA architecture with the GFX12 family, its MMA builtins and data-type ABI differ, so it must not be treated as a GFX12-family device.

Sharing an ISA lineage is not the same as belonging to that generation. So there are two separate claims in play, and only the second one holds.

Changes

Where a generation label is meant, it now says CDNA5. Where only the instruction path matters, the generation is dropped rather than replaced — a WMMA path is a WMMA path regardless of which generation the part belongs to.

file	before	after
dispatcher/tests/test_gemm_utils.py	gfx1250 (MI400 / RDNA4-WMMA) enablement	gfx1250 (MI400 / CDNA5, WMMA) enablement
dispatcher/tests/test_batched_bridge.py	same	same
dispatcher/tests/test_batched_contraction_bridge.py	same	same
dispatcher/tests/test_multi_d_bridge.py	it runs the RDNA4 WMMA path	it runs the WMMA path
dispatcher/codegen/grouped_conv/grouped_config_rules_full.py	such as rdna4/gfx1250	such as gfx1250
tile_engine/.../bridge_default_ci_config_gfx1250.json	(MI400, RDNA4/WMMA)	(MI400, CDNA5/WMMA)

Deliberately not changed

• include/ck_tile/core/arch/arch.hpp and .../mma/scale/wmma/selector.hpp describe the ISA lineage and the selector strategy as RDNA. Both are accurate — the first is the quote above, the second documents an RDNA-style selector. Renaming these would replace a correct statement with a wrong one.
• dispatcher/codegen/arch_specs_generated.py still reads rdna4. It is generated, and its source is the gfx1250 entry in arch_specs.json that feat(ck-tile): make dispatcher LDS capacity budget architecture-aware #12173 adds; the value is corrected there. Hand-editing a generated file is the exact trap this codebase keeps hitting, so it is not done here.

That last point means the tree is briefly inconsistent until #12173 lands. The affected field is metadata: nothing branches on its value, and its only consumer is a None check that rejects unknown architectures in strict mode.

Test plan

• test_gemm_utils, test_batched_bridge, test_batched_contraction_bridge, test_multi_d_bridge, test_grouped_conv_codegen all pass
• The edited CI config still parses as JSON
• No gfx1250/MI400 reference to RDNA4 remains outside the two files listed above as intentionally kept

Note for the reviewer

The label originated in #10921, the gfx1250 bridge enablement PR, and spread from there; AICK-2082 uses the same wording. So this is a retroactive terminology correction rather than a one-off typo. If CDNA5 is not the right generation either, say so before this merges — I have taken it from review feedback on #12173 and have not independently confirmed it.

[therock-pr-bot]

✅ All Checks Passed — Ready for Review

Check	Status	Details
📝 PR Description	✅ Pass	—
⛔ Forbidden Files	✅ Pass	—
🧪 Unit Test	✅ Pass	—
🔎 pre-commit	✅ Pass	—
🚫 Draft PR	🔜 To Be Enabled	—
🚩 Feature Flag	🔜 To Be Enabled	—
📊 Code Coverage	🔜 To Be Enabled	—
🤖 therock-pr-bot	✅ Pass	—

🎉 All checks passed! This PR is ready for review.

📖 Need help? See the Policy FAQ for details on every check and how to fix failures.

🙋 Wish to Override Policy?

[therock-pr-bot]

🎉 All checks passed! This PR is ready for review.

[andriy-ca]

LGTM!