[Kolkka]

On the Steam Deck the game freezes about 30 seconds into Kokiri Forest, every run: the kernel logs a ring gfx timeout and resets the GPU. Fixes #1000.

What changed: mesh programs on AMD are built without the driver's optimizer, a workaround for hangs on AMD's own drivers (RX 6600, #461, #484). On Mesa's RADV that is the case that hangs: the foliage culling mesh program 89ca750f9852b7ca, built without the optimizer, wedged the Deck's GPU (Van Gogh, RDNA2). The workaround now checks VkPhysicalDeviceDriverProperties::driverID and skips RADV, so RADV builds every mesh program with the optimizer, as on other vendors. AMD's proprietary drivers are unchanged. RX_VK_MESH_OPT=1 still forces the optimizer on.

Tested: Steam Deck LCD, SteamOS, Mesa RADV, handheld at 50% resolution. Before: ring gfx timeout and reset 25–40 s after the save loaded in Kokiri, in every run. After: no ring timeout or reset in any run since, each 1,200–6,000 frames past the first 3D frame. tests/run_all.py: no new failures against main.

🤖 Generated with Claude Code

[NotRexed]

Thanks, and for the Steam Deck measurement. #1965 makes the same change (the optimizer kept on for RADV, AMD's own driver unchanged), opened earlier, so the review continues there; your Van Gogh result is noted on it. Closing as a duplicate.

[Joey-Magnus]

The vk_draw.cpp lambda is identical to #1965's (still open) apart from the comment. The change is correct: the hangs that added the workaround (#461, #484) were on Windows/Adrenalin, so exempting RADV leaves it where it's needed. It doesn't cure every RADV hang, though; the RX 6900 XT Deku Tree and Lon Lon reports hang with the optimizer on. One of the two should merge with both sets of Deck results, and the other close. If this fixes #2245, #2362 may be unnecessary.