Repository navigation
AGC: agc_driver_sample_order_grid_reference loses the device on AMD's Windows driver with graphics pipeline libraries, passes with APS5_NO_GPL=1 #9507
Description
On AMD's proprietary Windows driver, agc_driver_sample_order_grid_reference ends with vkQueueSubmit recorder: Vulkan result -4. That happens on main and with #9056 + #9057 (which fix the other two sample-order tests). It has been reported on a Radeon 680M (32.0.21030.2001, #9056), a gfx1036 (32.0.21036.18, #9056) and here.
Setup: AMD Radeon RDNA 2 iGPU (1002:13c0, gfx1036), AMD driver 32.0.21042.62, Windows 11, WinLibs GCC 15.2.0, Release. ANYPS5_GPU=AMD ANYPS5_REQUIRE_VULKAN=1 ANYPS5_NO_SHADER_CACHE=1. main a6dcea927 + #9056 d930f7c08 + #9057 78254bef6. The device reports 2x2 sample location grids at every count and pipelineLibrary=1, and it gets background pipeline LTO (PipelineLinkTimeOptimizationUsable excludes only NVIDIA).
| Run (renamed executable each time) | Result |
|---|---|
| default | device lost, 3 of 3 |
APS5_NO_GPL=1 |
passes 3 of 3; the exact path matches the device's 2x2 grid bit for bit |
APS5_NO_PIPELINE_LTO=1 (fast-linked pipelines only) |
access violation in amdvlk64.dll twice, vkCreateGraphicsPipelines link: Vulkan result -3 once |
With APS5_NO_PIPELINE_LTO=1, plain agc_driver_sample_order also crashes in amdvlk64.dll+0x21c4bc2 before it prints anything. It passes 3 of 3 with the default settings. agc_driver_provoking_vertex, agc_driver_rect_list_corner, agc_driver_multisample_readback and agc_driver_tessellation pass with APS5_NO_PIPELINE_LTO=1. So the fast-link problem comes with the sample-order tests' pipelines, not with every library pipeline.
Where it goes wrong (local instrumentation, not proposed):
- It happens on the exact path, the draws whose samples are reordered (
emulatedcontext, 1x1 grid,ReordersSamples). The composite reference, which uses the device's grid without reordering, renders. The loss comes on the exact path's second draw. - The draw that loses the device is a full-screen pass of
SampleOrders::Depth(SampleOrderDepthfragment shader, monolithic pipeline) that runs after a draw's render pass (RecordSampleOrder(..., toHost = false)from the pass'safterPass). ThetoHostcall of that pass, before a draw, never loses the device. The firsttoGuestcall succeeds and the second loses the device: skip the first one and the loss moves to the next draw. - These changes do not help: no custom sample locations in that pass or its barriers; skipping its depth copy; a new copy image each time; sample shading off in that pass; the same map in both directions; a flat or repeated draw instead of the slopes; skipping
RecordDepthSampleLocations; no sample locations or sample shading in the library pipelines. - These do help: skipping that pass's draw, skipping every
toGuestreorder, orAPS5_NO_GPL=1.
So the failing work is the monolithic depth-reorder draw. Whether it fails depends on the draws around it being built from graphics pipeline libraries on this driver. Fast linking alone crashes the driver on these pipelines. I haven't found which state of the library pipelines does it. #2866 is a related report: background LTO loses the device with a depth attachment on NVIDIA, which is why NVIDIA now skips LTO.
Not run: the Khronos validation layer (not installed on this machine), VK_EXT_device_fault.
AI-assisted: yes (Claude Code); results above were run on this machine.
Activity
MarcZX10 commentedon Oct 22, 2026
This report narrows the failure to the monolithic depth-reorder draw when the surrounding pipelines use GPL. Open PR #9503 moves the
SampleOrders::Depthdescriptor-set bind to immediately after each pipeline bind; its author reports the sample-order tests pass on an RX 6700 XT when combined with #9056. That is close to this failure path, but it has not been reported against this Radeon 680M/gfx1036 setup. If convenient, testing #9503 + #9056 on the failing setup would tell us whether the driver fault is addressed across this device/driver combination. If it still fails, a device-fault/RGD capture for this exact reproduction would help separate the descriptor-binding issue from another GPL interaction.wachi35676 commentedon Oct 22, 2026
@MarcZX10 Tested #9503 (
319289374) with #9056 (d930f7c08) and #9057 (78254bef6) on the failing setup, with graphics pipeline libraries on (noAPS5_NO_GPL). It fixes the device loss here.Setup: AMD Radeon RDNA 2 iGPU (
1002:13c0, gfx1036), AMD driver 32.0.21042.62, Windows 11, WinLibs GCC 15.2.0, Release.maina6dcea927with #8884, #9056, #9057 and #9503 merged, all cleanly,ANYPS5_GPU=AMD ANYPS5_REQUIRE_VULKAN=1 ANYPS5_NO_SHADER_CACHE=1.agc_driver_sample_order_grid_reference:vkQueueSubmit ... -4), 3/3.the exact path renders Village's 2x checkerboard like the device's 2x2 sample location grid, bit for bit.agc_driver_sample_order*tests pass 3 of 3 under ctest on the iGPU._grid_referenceskips, 3 of 3, as before.So on this device and driver, the loss came from the descriptor-set bind order that #9503 fixes, not from another GPL interaction.
AI-assisted: yes (Claude Code); results above were run on this machine.
MarcZX10 commentedon Oct 22, 2026
Thanks; this reproduces the original failure and confirms that #9503 fixes it on the same gfx1036/Windows setup, including the full sample-order test set. I have incorporated this cross-check into my PR review. No further issue-side reproduction is needed from you for this device-loss report.
MarcZX10 commentedon Oct 22, 2026
Update: the reporter confirmed that #9503 with #9056/#9057 passes the original gfx1036 Windows device, and #9503 now includes the required same-GPU Khronos validation comparison (with layer load confirmed and VUIDs compared). #9503 remains open and my review is approved; #9056 and #9057 also remain open, so the issue has a reproduced, validated fix path but the changes have not merged yet.