Repository navigation
fix(vk): the Navi 21 task + mesh fallback also covers the RX 6900 XT XTXH and RX 6950 XT (#996) - #2215
Conversation
hckrman101
left a comment
There was a problem hiding this comment.
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's ids == set(DEVICES) keeps the list honest in both directions. The default stays inside #ifdef _WIN32, so Linux/RADV is untouched, and RX_VK_TASK_MESH_FALLBACK is 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.
80a5bd2 to
8eba736
Compare
|
@hckrman101 Thanks for the review. I rebased the branch on current 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. |
Joey-Magnus
left a comment
There was a problem hiding this comment.
Two device IDs behind vendorID == 0x1002 inside #ifdef _WIN32, DEVICES updated, 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.
…XTXH and RX 6950 XT (NotRexed#996) after an RX 6800 XT lost the device within minutes on the native path. Navi 21 also ships as 0x73af (RX 6900 XT, XTXH boards) and 0x73a5 (RX 6950 XT): the same chip on the same driver, so they get the same default. They were not tested on their own; RX_VK_TASK_MESH_FALLBACK=0 still turns it off. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
8eba736 to
eea15bd
Compare
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.