fix(agc): support alternate channel order in 16-bit color targets

[TibixDev]

What

Support alternate component order for 16-bit RGBA color targets. Swap red and blue in shader exports, write masks, and constant-color blend factors together. Reject conflicting constants across simultaneous targets.

Semantics follow ac_translate_colorswap in Mesa 26.2.2. Console equivalence remains unmeasured and is recorded in TechnicalDebt.

Tested

Fedora 44, Release: graphics tests cover UNORM, SNORM, UINT, and float formats; standard/alternate/rejected reverse orders; write masks; blend constants; and compatible/conflicting target combinations. Related color-format PRs do not implement this mapping. Contribution checks pass. Windows was not tested.

Checklist

• Current main; no duplicate open PR.
• One topic.
• No new code comments.
• Unsupported paths still throw; UI stubs are documented.
• No notes, logs, or images in the repository.
• No new third-party code.
• General behavior.
• Depends on: none.
• AI-assisted: yes.

[oneandonlydean]

Which title draws to a 16_16_16_16 color target with COMP_SWAP 1 on main? With the title ID and the log line where it stops this can go in.

[TibixDev]

Rebased on e705d430. Preserved the new wide-string and Windows I/O limitations. Removed an unrelated blank-line change and grouped this texture limitation with the graphics notes. The title-evidence request remains open.

Fedora 44 Release: agc_driver_graphics_tests, agc_driver_pm4_tests build; the targeted tests and contribution checks pass. Windows CI is pending.

[adriadam10]

Thanks. This no longer applies to current main, and the conflict is not mechanical:

• State.cpp DecodeColorFormat case 12: since #1425, main already maps swap 2/3 to the reversed mappings (0x1b/0x93) and only rejects swap == 1. Please rebase and add the swap == 1 (0xc6) case on top of that, keeping 2/3 as they are.
• DecodeState: main throws when blending into a target with a reversed order (mapping == 0x1b/0x93). Say how the new blend-constant handling interacts with that, and keep the throw for the reversed orders.
• tests/Graphics.cpp and docs/dev/TechnicalDebt.md conflict as well; re-add the test and the TechnicalDebt line (not as the last line of its section) after the rebase.
• @oneandonlydean's question is still open: which title draws to a 16_16_16_16 target with COMP_SWAP 1, and where does it stop on main? Without that evidence (title ID and log line), or a Linux test reproducing it, this stays a speculative path.

Please rerun agc_driver_graphics_tests after the rebase.

[adriadam10]

Rebased onto current main and fixed the points from the previous review on your branch:

• DecodeColorFormat case 12 now only adds swap == 1 (mapping 0xc6) on top of #1425; swap 2/3 keep 0x1b/0x93.
• Blending into a reversed order (0x1b/0x93) still throws. The constant-color swizzle applies only to the 0xe4/0xc6 targets; conflicting constants across simultaneous targets throw. The old "component swap 1 fails" check is gone and the blend test now expects the reversed-order rejection.
• Graphics.cpp test re-added after the rebase and TechnicalDebt line re-added in "Functional" (not last in the section).
• agc_driver_graphics passes and fails without the State.cpp change.

Not verified: console behaviour for COMP_SWAP 1 on 16_16_16_16 (only Mesa ac_translate_colorswap, same model as the existing 8_8_8_8 alternate order); recorded in TechnicalDebt. Merging on green CI.