fix(vk): the Navi 21 task + mesh fallback also covers the RX 6900 XT XTXH and RX 6950 XT (#996) #2215
No reviewers
Labels
No labels
accessibility
autorelease: pending
autorelease: tagged
bug
dependencies
documentation
duplicate
enhancement
github_actions
good first issue
help wanted
invalid
question
testing wanted
wontfix
No milestone
No assignees
1 participant
Due date
No due date set.
Dependencies
No dependencies set
Reference
MagicBeanDev/Hookshot!2215
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/navi21-more-ids"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Follow-up to #1992, as @hckrman101 suggested in the review.
Navi 21 also ships as 0x73af (RX 6900 XT, XTXH boards) and 0x73a5 (RX 6950 XT). It's the same chip on the same AMD Windows driver as 0x73bf, so I've added both to the default task + mesh compute fallback.
gpu/vk/vk_main.cpp: the two IDs are added to the default (AMD, Windows only). The comment says they weren't tested on their own.tests/test_task_mesh_fallback_devices.py:DEVICESlists them, so theids == set(DEVICES)check covers them.docs/development.md: theRX_VK_TASK_MESH_FALLBACKrow names the 6950 XT.Not tested on those cards: I only have an RX 6800 XT (0x73bf). The reasoning is the same chip and driver. If an owner reports a problem or a big fps cost,
RX_VK_TASK_MESH_FALLBACK=0turns it off.python -I -B tests/test_task_mesh_fallback_devices.pypasses locally.Thanks for picking this up from #1992.
The IDs check out: 0x73af is the XTXH Navi 21 (RX 6900 XT LC / XTXH boards) and 0x73a5 is the RX 6950 XT, both Navi 21 like 0x73bf. The match is exact equality behind
vendorID == 0x1002, so nothing else can hit it by accident, and the test'sids == set(DEVICES)keeps the list honest in both directions. The default stays inside#ifdef _WIN32, so Linux/RADV is untouched, andRX_VK_TASK_MESH_FALLBACKis still read after it, so an owner can switch it off. CI is green, including the Windows llvm-mingw build.Nit, optional: the workstation Navi 21 parts (Radeon Pro W6800 0x73a3, W6900X 0x73a2) run the same chip on the AMD Pro driver too. Fine to leave them out until someone reports, just mentioning it since the comment says "Navi 21 is ...".
Related open AMD mesh PRs: #2362 (RADV mesh off by default on Linux AMD) touches
create_device()too but a different hunk under#ifndef _WIN32, so no overlap with this one; #2311 (vk_draw.cpp) and #2312 (the SPIR-V emit context) don't touch these files.Not tested on the 6900 XT XTXH / 6950 XT themselves, as the description says; same chip and driver as the tested 6800 XT, and the env var is the escape hatch, so that's fine by me.
@hckrman101 Thanks for the review. I rebased the branch on current
main(a0dfd28), so it is now 8eba736. The only conflict was indocs/development.md: #1823'sRX_VK_DRIVER_FAULTSrow landed right below theRX_VK_TASK_MESH_FALLBACKrow. I kept both rows. The code and the test are the same as in the version you approved, andtests/test_task_mesh_fallback_devices.pypasses locally.On the workstation parts (W6800 0x73a3, W6900X 0x73a2): I'm leaving them out for now, as you suggested, since nobody has tested them or reported the issue on them. They're easy to add if someone does.
Two device IDs behind
vendorID == 0x1002inside#ifdef _WIN32,DEVICESupdated, and the test passes merged into main. The red Windows part 1 job is main's old ASTC test failure, fixed by #2397. Update the branch to get it green.github-sync referenced this pull request2026-11-12 06:22:54 +00:00