Repository navigation
fix(vk): RADV's mesh shaders off by default on Linux AMD (issue 2245) - #2362
Conversation
RADV's native task/mesh path deadlocks the GPU: the gfx ring and RADV's gang compute ring end up waiting on each other, and a mesh-only draw hangs with the compute queue empty (devcoredumps on an RX 6800, no VM fault). Task + mesh draws alone on the compute fallback still crash, so only full Compute is stable there; the reports span Navi 2x (RX 6800, RX 6600 XT) and the RDNA3 APUs (Steam Deck OLED, Rog Xbox Ally X). So on Linux, where AMD's Vulkan driver is RADV, the Mesh shaders row's Automatic now picks Compute. Native stays a choice in the row, Windows is untouched, and RDNA1 and older are a no-op (no mesh shaders on RADV). The menu row's Automatic hint now says so.
|
RDNA3 desktop data in support (RX 7900 XT, RADV NAVI31, Mesa 26.2.3, Linux 7.2.7; rows in docs/tested-configurations.md from #2202):
On an older build, native hung on the load into Kokiri Forest (gfx ring timeout → MODE1 reset) in 3 of 4 tries. Since then we've played on full compute, with no hang. So on this card, full compute is also the fastest mode, and making it the AMD default costs nothing here. |
Joey-Magnus
left a comment
Joey-Magnus
left a comment
There was a problem hiding this comment.
The inline point still applies: gpu/vk/vk_main.cpp:258 checks vendorID == 0x1002 under #ifndef _WIN32. That catches AMDVLK on Linux and misses the Windows build under Proton, where the driver is RADV. driverID == VK_DRIVER_ID_MESA_RADV covers both.
#2311 (re-enable the optimizer for mesh programs on RADV) may be the real fix for #2245. If it is, this PR would move every Linux AMD card, Deck and Ally included, onto the slower compute fallback for nothing. #2382's depth hold also applies on that path, and the two haven't been tested together. Could someone with an RX 6600/6800 try #2311 first?
|
This is the run asked for in the review: RX 6800 XT, main with #1965 merged (landed 23:34Z today), Mesh shaders on Automatic. Result: on this card the optimizer change is not enough on its own for native mesh, the run still ends in a full GPU reset. 99 s into the session, at frame 1398. The kernel took a full reset: To be clear about what this says and what it does not: #1965 may well fix what it set out to fix — the reset while a save loads and nothing here contradicts that. The finding is narrower: on desktop RDNA2 with Automatic, the mesh path still takes the GPU down. It is not the import bug either: the same run logged An earlier attempt on the same build hung sooner, on the Kokiri Forest load, with Same build with the compute fallback restored: loads and runs, no resets. What I could not measure: fps Native vs Compute. The native run died before there was a stable window to read it. Hardware: RX 6800 XT (RADV NAVI21), Mesa 25.0.7, kernel 7.0.0-42, Vulkan 1.4. |
…s behind them Upstream's main fails 15 of its own source checks at c356bef (PRs merged without a rebase). These are the eleven outside the upscalers: - vk_memory.cpp: RX_VK_CAPTURE_KEEP_OLD and RX_VK_CAP_BLOCKS are on/off switches and were read as set-means-on, so =0 turned them on (NotRexed#2437). env_on, as the rest. - mouse_native.c: the mouse's kept angles are let go when the camera leaves states 3 and 4 (first-person aim, Z-targeting): they were written back on return, and the view snapped to where it was before (NotRexed#2617; test_mouse_native's yaw). - menu_i18n.h: three English texts changed in vk_menu.cpp (NotRexed#1930, NotRexed#2362, NotRexed#2435), so their 13 translations are keyed and translated again (machine-made, as the file's others). - Fixtures that cut source by its text and missed what the source gained: window_title (NotRexed#2116), dead_import_bytes (NotRexed#1906), env_on in reverb_frame, hos_xinput_pads (NotRexed#2435), wait_recorded's forward declaration (NotRexed#2458); and the Dockerfile check's parser, which took --no-update for a PPA. Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
….2.0 Kept: this fork's low-end VRAM defaults, the handheld texture limits (with upstream's small-VRAM mips rule), the Steam fixes, the native file choosers and the name. Taken from upstream: its Linux sleep timer (NotRexed#2637, this fork's handheld rule), the RADV mesh default (NotRexed#2362), the systemd scope for Play (NotRexed#2540). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01C7fdTPXbwDRohew9qanvbp
On Linux AMD, Automatic now means Compute: RADV's native task/mesh path deadlocks the GPU (the gfx ring and RADV's gang compute ring wait on each other with no waves running), and a task+mesh-draws-only fallback still hangs on a mesh-only draw, so only full Compute is stable there (issue 2245). The reports span Navi 2x (RX 6800, RX 6600 XT) and RDNA3 APUs (Steam Deck OLED, Rog Xbox Ally X), so it keys on the vendor rather than a device list. Native stays a choice in the row, and Windows keeps what it had. RDNA1 and older have no mesh shaders on RADV: for them a no-op. The Mesh shaders hint says so too. Ported from upstream 434cdd3 (NotRexed#2362). RADV/AMD Linux hardware not available here: the branch is checked, the hang is unverified.
Fixes #2245.
Until this lands, setting Mesh shaders to Compute avoids the crash.
On Linux, Automatic now means Compute on AMD cards: RADV's task/mesh path hangs the GPU, so native mesh shaders stay off unless Native is picked by hand. Windows keeps what it had. RDNA1 and older never had mesh shaders on RADV, so nothing changes there.
Why full Compute and not the fallback: on the native path the gfx ring and RADV's gang compute ring end up waiting on each other with no waves running (the RX 6800 devcoredump in #2245). With RX_VK_TASK_MESH_FALLBACK=1 the hang moves to a mesh-only draw instead: waves on gfx, compute queue empty. So pushing only task and mesh draws to the fallback, like the Windows default from #1747, is not enough on RADV. Which programs hang moves around between runs (the checkpoint culprits follow the skipped ones), so it isn't one bad shader either. The reports cover Navi 2x (RX 6800, RX 6600 XT) and the RDNA3 APUs (Steam Deck OLED, Rog Xbox Ally X), which is why this keys on the vendor instead of a device list.
Tested on an RX 6600 (RADV NAVI23, driver 0x6802006, kernel 7.3.3-cachyos), v2.1.0:
main with the same patch compiles clean.