Repository navigation
AMD Windows: GPL-mode cache failures (alpha/wave32 pass after local driver update) #4768
Description
Updated-driver confirmation of the three outstanding fixtures — 26 October 2026
27 October independent cache-order evidence: LeandroLP23 reports 48 controlled executions on a Radeon 860M / AMD32.0.13058.8001: the mode run first with an empty AMD cache passes all three fixtures, while switching GPL mode against that populated cache fails; reversing the priming order reverses the winner. The original cache was restored. This is stronger evidence for cross-mode driver-cache reuse than our as-found-cache comparison below, which does not isolate a cause. It is a contributor report on a different GPU/driver, not a new local reproduction or proof that either mode is faulty alone. Keep open; our original source-pinned results remain below. AI-assisted maintenance: yes (Codex).
Keep open: the separate sampled-storage/direct-ordering/cube failures reproduce locally. Literal main d3b397b750bf55fed924036a344917c1e6fa920f, Windows11 Enterprise26200, WinLibs GCC15.2r7/UCRT Release. AMD Radeon Graphics 1002:13c0, Windows driver32.0.21045.16010 / Vulkan26.10.1; NVIDIA RTX5080 10de:2c02, driver621.01 /32.0.16.2101.
Each cell totals two repetitions in each of two rounds, using the same executable/native runtime throughout:
| Fixture | AMD default / forced GPL-off | NVIDIA default / forced GPL-off |
|---|---|---|
agc_sampled_storage_base_level_usage |
4/4 pass / 0/4 pass | 4/4 / 4/4 pass |
agc_copied_direct_ordering |
4/4 pass / 0/4 pass | 4/4 / 4/4 pass |
agc_recorder_cube |
4/4 pass / 0/4 pass | 4/4 / 4/4 pass |
The AMD forced-off failures match CrimsonMac's report: sampled sRGB base level reads0 instead of0.215860; direct ordering reports vkQueueSubmit recorder: Vulkan result -4; cube sampling reads0 instead of0.062745. 48 processes: 36 pass /12 fail, no skips/timeouts or Vulkan validation warnings/errors/VUIDs; max0.610s. Required Vulkan, loaded Khronos1.4.363 and actual physical GPU identity verified per process; app shader cache/journal disabled. Full native libraries/relinker/real recorder fixture build; pre/post executable and runtime hashes match.
Sequence per GPU: default → forced-off → forced-off → default. Default means APS5_NO_GPL unset; forced-off means APS5_NO_GPL=1. This recorder does not print its final resolved GPL feature flag. Driver cache and implicit layers were retained; no full-suite cache priming or clean-cache controls were performed. This confirms the mode-dependent failures on this setup, not that switching modes caused them or that the driver/cache is proved to be their cause. Source, driver and cache identities differ from historical reports, so this is not a driver-only comparison.
The original alpha/wave32 cases separately passed36/36 on main 5b5d24cb223ede690fe5eab1fe2f7a1736b801a5 after the driver update, including original/copied alpha paths and both modes. Their retained logs and72 known alpha output warnings remain in the same evidence Gist. Those passes do not close these three failures.
Exact source/artifact pins, all48 outcomes and complete verbose logs. AI-assisted: yes (Codex).
Previous evidence and source-pinned history
Latest confirmation: main338f, 2026-10-21 UTC
Keep open. The residual original-path AMD GPL-on alpha failure still reproduces on unmodified main 338f22e493c113d71df6cd4b032fe3740283d0fd, including merged #6436. This matrix no longer shows the older full mode inversion: the copied location and GPL-off agree; original-path GPL-on remains the exception.
| Physical GPU; alpha passes / fresh processes | Original GPL on | Original GPL off | Copied GPL on | Copied GPL off |
|---|---|---|---|---|
AMD Radeon Graphics 1002:13c0 /32.0.21036.18 |
0/3 | 3/3 | 3/3 | 3/3 |
NVIDIA RTX5080 10de:2c02 /610.62 |
3/3 | 3/3 | 3/3 | 3/3 |
Other hardware (contributor result): @thuanquang reports 10/10 passes for original-path GPL-on alpha on main a07e985c8, RX 6700 XT/gfx1031, Windows driver 32.0.21045.5002, with the driver cache retained. This is a different GPU, driver and executable/cache identity; it narrows affected configurations but does not explain or close our gfx1036/32.0.21036.18 failure. It is not our own run.
All three failures retain the same assertion:
alpha 0x00000000 with alpha-to-coverage on: channel 0 of pixel (0, 0) inside the scissor holds half 0x0000, expected 0.5
24 processes: 21 passes /3 assertion failures, maximum1.142s. Alpha only; the earlier wave32 results remain historical. The real AlphaToCoverage.cpp and required target libraries build on literal main, with two GCC vector-comparison warnings retained. Source, executable and all360 runtime/sidecar files are unchanged through the matrix. Original and copied executables are byte-identical (be5f922151f39437894d00c8e2020408ec45c6a2b3a0546157d024db192e5962); same original output path, cwd and DLL search path, fresh external copy directory. Both GPL modes run three planned serial processes per location, on before off. No source workaround in this run.
Windows11 Enterprise26200, WinLibs GCC15.2.0r7/UCRT Release, SPIRV-Tools ON. Required Vulkan, application shader cache/journal disabled, verbose CTest with30s bounds; actual adapter and loaded Khronos1.4.363 confirmed per log. Zero VUIDs, validation errors, skips or timeouts. Each successful alpha process reports the same three unused-fragment-output warnings:27 Undefined-Value-ShaderOutputNotConsumed-DynamicRendering and36 Undefined-Value-ShaderOutputNotConsumed total. These are assertion passes with disclosed warnings.
Driver cache remains as found, apart from normal driver writes; no reset, rename, ACL or driver change. The previous one-line generator control f12fa1d972 remains pinned to main5b59: it made the same original-path failure pass3/3, and restoring the baseline library restored failure3/3. That establishes metadata-key/driver sensitivity, not whether stale cache reuse or generator-sensitive compilation causes it. The control is not repeated or promoted as a production fix here.
Supported-control capability check: both adapters advertise VK_KHR_pipeline_binary and pipelineBinaries=true. AMD reports pipelineBinaryInternalCache=true but pipelineBinaryInternalCacheControl=false (AMD proprietary25.10.36); NVIDIA reports the control true. Khronos requires that property to be true before setting disableInternalCache=true (VUID-...-09602). We did not attempt the unsupported AMD setting. NVIDIA's capability does not settle the AMD cause. The next distinguishing measurement still needs a supported cache-reset/disable control on AMD; no cold-cache result is claimed.
No full-default build, full suite, title, performance, Linux or console result. AlphaToCoverage.cpp, Context.hpp, Pipeline.cpp and the test device helper are unchanged from main5b59; device target settings evolved, so this is not an isolated source bisect. Newer checked main ec7eacc62d adds unrelated library exports/debt only and is not separately runtime-tested here. AI-assisted: yes (Codex); author responsible.
Historical observations and controls at their original source pins
Previous generator control: main5b59, 2026-10-21 UTC
Keep open. Unmodified main 5b59fbc553 (with #6436) still fails alpha at the original executable path on our AMD iGPU. A one-line change to shader generator metadata makes that path pass; restoring the byte-identical baseline library restores the failure.
| AMD alpha; passes / fresh processes | Original GPL on | Original GPL off | Copied GPL on | Copied GPL off |
|---|---|---|---|---|
| Unmodified main | 0/3 | 3/3 | 3/3 | 3/3 |
| One-line generator control | 3/3 | 3/3 | 1/1 | 1/1 |
| Restored baseline library | 0/3 | 1/1 | 1/1 | Not run |
NVIDIA RTX 5080 passes once per mode at both locations on baseline main, and once per mode at the original location for both the control and restoration. An additional AMD original/GPL-on confirmation fails 3/3 immediately before the unsuccessful cache-isolation attempt. 36 processes total: 27 passes and nine retained baseline assertion failures, maximum measured duration 1.149 s. This follow-up is alpha only; the earlier wave32 matrix remains historical below.
The diagnostic fork commit f12fa1d972 adds keyed[2] ^= 0x4000u to the common CreateShaderModule helper for both modes, retaining #6436's existing GPL-off 0x8000u marker. It builds on the original PYTHONRETARDE/LeandroLP23 work. SPIR-V section 2.3, word 2 gives generator metadata no module-semantic effect; the pinned tool registry leaves its low 16 bits for supplier use. This establishes metadata-key/driver sensitivity. It does not distinguish stale disk-cache reuse from generator-sensitive compilation or qualify a production fix.
Identity/setup: the same original/copied executable bytes and paths throughout, SHA-256 bfa144ba719561e6764711f726c11a760630213b2a7c40fa02e0218bcc0dc97b; same cwd and DLL search path. Only libSceAgcDriver.prx changes in the control; all 360 runtime files, executable hashes and main source are verified restored afterwards. WinLibs GCC15.2r7/UCRT Release, Windows11 Enterprise26200; physical Radeon Graphics 1002:13c0 /32.0.21036.18 and RTX5080 10de:2c02 /610.62 verified in logs. Real alpha fixture and required library builds pass; conventions pass. No full-suite, full-default-build, title or performance qualification.
Required Vulkan, disabled AnyPS5 shader cache/pipeline journal, verbose serial CTest and loaded Khronos1.4.363 throughout. Zero VUIDs/validation errors/skips/timeouts. Every successful alpha process logs the same three unused-fragment-output warnings as main (GPL-on Undefined-Value-ShaderOutputNotConsumed-DynamicRendering, GPL-off Undefined-Value-ShaderOutputNotConsumed): 81 warnings total, retained rather than hidden.
Driver cache: retained, apart from normal driver writes. Renaming %LOCALAPPDATA%\AMD\VkCache was denied before any move, so no empty-cache/restored-cache-file control completed. No ACL/driver change was made. Older untagged entries surviving #6436 are one possible explanation from its source, unconfirmed. The fork commit is a reproducible diagnostic, not a new PR or title unblock. Results retain their main5b59 pin; newer checked main e10b4d6190 was not runtime-tested here. AI-assisted: yes (Codex).
Current-main confirmation, 2026-10-20 UTC
A residual location-sensitive failure remains on our AMD device after #6436. In response to LeandroLP23's request, rebuilt the two genuine fixtures from unmodified main 73b6a4cc7144d80ba5c720306ec1516728dfb59b, including merged #6436 (2ea00aae4). Production, fixtures and registrations are unchanged. The earlier complete GPL inversion is not reproduced by this matrix: wave32 and GPL-off cells now agree, while original-location GPL-on alpha still fails.
Five fresh serial processes per fixture/mode/location on Windows 11 Enterprise 26200, WinLibs GCC 15.2.0 r7/UCRT Release, bundled dependencies/SPIRV-Tools ON:
| Actual GPU | Executable location | GPL on: alpha / wave32 | GPL off: alpha / wave32 |
|---|---|---|---|
AMD Radeon(TM) Graphics 1002:13c0, driver 32.0.21036.18 |
original gpl4152-main/tests |
0/5 / 5/5 | 5/5 / 5/5 |
| same AMD | new empty folder, only byte-identical executables copied | 5/5 / 5/5 | 5/5 / 5/5 |
NVIDIA GeForce RTX 5080 10de:2c02, driver 610.62/32.0.16.1062 |
original | 5/5 / 5/5 | 5/5 / 5/5 |
| same NVIDIA | same copied executables | 5/5 / 5/5 | 5/5 / 5/5 |
All five AMD failures stop at the original assertion:
alpha 0x00000000 with alpha-to-coverage on: channel 0 of pixel (0, 0) inside the scissor holds half 0x0000, expected 0.5
Controls and limits:
- Required Vulkan; actual requested physical adapter confirmed in every log; loaded Khronos 1.4.363; application shader cache and pipeline journal disabled. GPL on leaves
APS5_NO_GPLabsent; off sets it to1. The sequence was on then off, original/copy per fixture; this is not an off-first or cache-cold campaign. - Same current directory, PATH and original runtime libraries for both locations. Original test directory is first on the common PATH so copied programs also use its standard-runtime DLLs. Executable and all 358 original runtime/sidecar files hash-identical before/after; copied folder holds only the two executables. Alpha SHA-256
68618c3e3d81e92f66814e9dc7b84e647d4b27084e67d816c22d22a85d4ba32f; wave32946003ffa1a74f0d7c3613769123b815f9c7b4a07ecab546d405e9450a945dfe. - AMD's driver cache was left intact: no clearing, moving, renaming or isolation. Existing cache content versus a new executable identity remains a confounder. This result does not establish the failure's cause or causally disprove the new mode separation. The current helper marks GPL-off modules; whether an older GPL-on cache entry remains involved needs a separate distinguishing control.
- 75 passes / 5 assertion failures, zero skips/timeouts or VUID/validation errors. Each of the 35 successful alpha runs logs three shader-output-not-consumed warnings during its later depth-only coverage checks: 45
Undefined-Value-ShaderOutputNotConsumed-DynamicRenderingwarnings with GPL on and 60Undefined-Value-ShaderOutputNotConsumedwarnings with GPL off (105 total). Wave32 runs have zero warnings. Failing alpha runs stop before those later checks. These are functional passes with disclosed warnings, not validation-clean alpha results.
Logs, build receipt, exact environment and SHA-256 manifests retained locally. No source workaround, title/FPS, Linux, driver-cache-cold or whole-suite claim. This issue stays open because the requested original/copied cells still disagree. AI-assisted: yes (Codex); author responsible.
Latest main4f-based candidate (2026-10-14 UTC)
#4451 head246d16a03, base main4f618, is fully rebuilt with SPIRV-Tools ON. Full build/libs/checkers and three compatibility/state controls ×20 pass. All13 NVIDIA groups ×5 in both GPL modes pass without skips (maximum5.44858s). AMD-selected groups retain the pattern below: standard/dithered coverage fail GPL-on; BDA span, wave32 exec-lane and subgroup fail GPL-off; the other groups pass ×5. No selected skips. Targetless32_AR behavior from merged #5521 is retained.
This is a fresh candidate run; the matched unchanged-main controls below remain pinned to main872. Their agreement does not establish exclusion against unchanged main4f. No new cause, workaround, title or full-suite claim. Hardware/OS and mode definitions remain the same as below.
Earlier same-build main872 comparison (2026-10-14 UTC)
Unmodified main 872f52320382aff45faa4b70f9c03d28228b6991 and restored #4451 head365850f33 run in the same S checkout/build directory, Windows11 Enterprise26200, AMD1002:13c0/32.0.21036.18, WinLibs15.2.0r7 Release/SPIRV-Tools ON. Stock builds full runtime libraries and five existing fixtures; the candidate is then restored and fully rebuilt. Vulkan required, AnyPS5 cache disabled, serial30s limits, five repetitions for passes; failures stop on the first run.
| Existing control, both main and restored candidate | GPL on | GPL off |
|---|---|---|
| Standard alpha-to-coverage | Fail first | Pass ×5 |
| BDA span reads | Pass ×5 | Fail first |
| Wave32 exec-lane bits | Pass ×5 | Fail first |
| Wave32 subgroup | Pass ×5 | Fail first |
| BDA device helper | Pass ×5 | Pass ×5 |
GPU-selection logs confirm AMD for the native failures. Diagnostics match on both:
- alpha zero: pixel(0,0) holds half0x0000, expected0.5;
- span: wave32 byte32768 stays0xcdcdcdcd, expected0x523f7ebd;
- exec-lane: lane0 stays0xdeadbeef, expected64;
- subgroup: thread0 stays0xdeadbeef, expected0.
NVIDIA RTX5080/610.62 passes all five existing controls ×5 in both modes on stock main and restored candidate. Candidate three compatibility/state controls pass20 times; all13 selected controls pass ×5 in both NVIDIA modes (maximum5.42903s). In the AMD-selected candidate runs, other controls pass ×5; CPU/helper controls are not separate AMD hardware coverage. No selected skips.
The new dithered fixture fails GPL-on at alpha zero (resolved0, expected0.249023438 for mask00) and passes GPL-off ×5. Main has no such fixture, so the existing-control comparison does not exclude a dither-specific regression. Layered-volume, byte-identical placement, LTO, cause-bisect and driver-cache-coldness campaigns are not repeated here. The earlier source/location evidence keeps its own pins.
Source fact: VulkanDevice::Target at this main derives both fixedPushSlots and registrationModules from graphicsPipelineLibrary. Thus the GPL switch also changes compiler-target settings consumed by compute; this does not prove either setting causes these failures.
#4451 is updated to the tested head; no production workaround added. AI-assisted: Codex.
Earlier original-location retest (2026-10-13)
Staged alpha heada5a282 on pinned main b0d, reconstructed from actual updated #5097/#5137 commits: the original-location AMD standard/dithered-on and wave32/layered-off failures persist; other selected cases pass5. Exact affected groups, forced-off/helper device scope and the passing NVIDIA suite are in the maintained #4451 report. This retest does not repeat the placement or unmodified-main controls and establishes no root cause or absence of a regression. The earlier exact e152 placement evidence below retains its own head/base and one-run counts.
Compute follow-up: On the same staged a5/mainb0d stack, existing buffer-load/store passes GPL-on and fails GPL-off at both original and copied executable locations, once per cell, with unchanged executable/runtime hashes. The exact 0xdeadbeef diagnostic and device-setup source observation are in the distinct validation reply. Alpha retains its different mode/location pattern; no uniform all-stage failure or root cause is established.
Earlier e152 alpha placement comparison (2026-10-13)
Staged #4451 head46dea, pinned main e152ba8; same Windows/AMD1002:13c0 setup below. The PR's published head remains unchanged pending dependency merges. Fresh original-location standard and dithered tests each fail their first GPL-on run and pass GPL-off five times; wave32 passes on/fails off. Layered failures and full validation scope are in the updated PR report.
Copy this exact registered alpha executable into an otherwise empty external directory; retain cwd and PATH to the original runtime libraries. SHA-256 of both executables and every unpatched runtime .prx remains identical before/after. Each copied mode runs once:
| Copied executable | AMD GPL on | AMD GPL off |
|---|---|---|
| Standard alpha | Pass | Alpha-zero mismatch |
--dithered8 |
Pass | Resolved-color mismatch |
This reproduces the original/copy mode inversion on this exact head. The initial harness expected the wrong dither success marker and aborted after its third actual execution; its record is preserved, the real success marker verified, and only the fourth case run separately. GPU/mode identities are verified; no skips. No driver cache was cleared, and root cause remains unknown. This is not an unchanged-e152 main control or proof of no production regression.
Earlier scoped main5aaa evidence: untouched main GPL-off standard-alpha and original layered white-band vertex each fail5/5; restoration fails each once. Its optional GPL-on alpha passes once before a truncated-JUnit harness assertion. Separately compiled original/extended fixtures against the same alpha libraries at one external path each pass on/fail off once; those images are not byte-identical and do not isolate a cause. No new title result. AI-assisted: Codex.
What
On Windows AMD RDNA2, native AGC tests change their GPL-on/off pass/fail pattern after copying byte-identical executables to another directory. The same runtime libraries are used. This is not isolated to the alpha change in #4451: a stock production-source/fixture control of main 2f4cc8983be9b9eacb878a4c705bdf5fcdc2d84f, built in the same directory, reproduces it.
Device/setup: Windows 11 Enterprise 26200, Ryzen 9950X3D iGPU, AMD Radeon(TM) Graphics 1002:13c0, driver 32.0.21036.18; WinLibs GCC 15.2.0 r7 / Release, testing ON, bundled dependencies, SPIRV-Tools OFF, ASAN OFF. RTX 5080 10de:2c02 is the passing control.
Results
Each cell below covers five fresh process executions of each existing fixture: agc_driver_alpha_to_coverage_tests.exe and agc_driver_wave32_subgroup_tests.exe.
| Stock main production/fixtures | AMD GPL on | AMD GPL off | AMD GPL on, pipeline LTO off |
|---|---|---|---|
| Original build executable location | 0/5 pass each | 5/5 pass each | 0/5 pass each |
| NVIDIA, original location | 5/5 pass each | 5/5 pass each | 5/5 pass each |
Both stock main and restored #4451 give the same pattern in the original build location. The main control temporarily replaced all changed core files except CMakeLists with exact base sources; git diff <base> --name-only -- core then listed only the CMake test additions. Production, headers and the two fixtures therefore match the stated main commit. Candidate sources were restored byte-for-byte and rebuilt afterwards. This is a matched production/fixture control, not a claim of an untouched whole-checkout build.
A further #4451 placement control checks SHA-256 equality of the original and two copied executables, and equality of every copied runtime .prx. For all three groups (the two above plus dithered alpha coverage):
| Executable location; same current directory | AMD GPL on | AMD GPL off |
|---|---|---|
Original <build>/tests |
0/5 pass each | 5/5 pass each |
| Empty temporary directory containing only copied executables; original build libraries via PATH | 5/5 pass each | 0/5 pass each |
| Copied executables and copied libraries together | 5/5 pass each | 0/5 pass each |
The copied stock-main executables also show the inverse pattern in single-execution controls, whether the current directory is the repo or their temporary folder. The five-run placement matrix is on #4451 3040cd741.
Failure signatures
alpha 0x00000000 with alpha-to-coverage on: channel 0 of pixel (0, 0) inside the scissor holds half 0x0000, expected 0.5
AGC graphics: wave32 subgroup: thread 0 v_mbcnt_lo_u32_b32 is 3735928559, expected 0
The new dithered group similarly loses its preserved background at alpha zero (resolved 0, expected 0.249023438). These are mismatches, not a crash in amdvlk64.dll. The same fixture groups on the candidate's NVIDIA build pass in both GPL modes; its full suite passes 990/0/7 of 997.
Reproduction
Build the stated main commit and the two named native targets in Release. Set ANYPS5_GPU=AMD Radeon, ANYPS5_REQUIRE_VULKAN=1, ANYPS5_NO_SHADER_CACHE=1, and prepend <build>/core/libs/libs/unpatched and the toolchain bin to PATH. Leave APS5_NO_GPL absent for on; set it to 1 for off. Setting 0 also disables GPL, because the code checks presence.
- Run each executable from
<build>/testsfive times, serially (30-second bound per process). - Copy only the two executables to a new empty temporary directory. Verify their SHA-256 hashes match. Use the same PATH and current directory, then run each copy five times in both modes.
- For the existing LTO control, leave GPL on and set
APS5_NO_PIPELINE_LTO=1.
GDB module probes confirm the intended runtime locations. They also show different ASLR addresses for the executable's Output array after relocation; this does not prove ASLR is the cause. Driver shader caches were not cleared. The relocation control changes executable identity/path as seen by the OS/driver. No production workaround, environment switch or tolerance was added.
Scope and related reports
Root cause is unknown. This does not establish an alpha regression, request-serialization defect, or recurrence of #4435's resolved shader-module-lifetime crash. #3882 reports another AMD device with unwritten draws, but not this RDNA2 executable-location/GPL inversion; #2009 concerns faulted pixel-interlock stores. Searches for AMD/GPL, AMD/unwritten and executable/relocation found no existing report of this control pattern.
The earlier different-runtime observations and corrections remain in #4435 and #4451. A fresh later-main control is recorded below; it does not reproduce the relocation inversion in that build. No new title launch or PS5 hardware measurement. Private game assets are not attached.
AI-assisted: yes (Codex); author responsible.
Later-main control (2026-10-13)
A newly configured native build of unchanged main 5f01c808219237ba9bdcbf02f6e1db5075fd61a9 uses the same WinLibs release/Release/testing/bundled-dependency options (its C++ compiler command is c++.exe). The two existing groups above and agc_driver_packed_mip_tail_target each pass 5/5 with AMD GPL on and fail 5/5 with GPL off, both at the original location and after copying only the executables. All three groups pass 5/5 on NVIDIA in both modes and both locations. This later build retains an AMD mode-sensitive mismatch but does not reproduce the relocation inversion. It is not an isolated cause bisect: source revision, build directory and executable images changed. The older byte-identical relocation controls above remain scoped to their own artifacts. No driver cache was cleared and no all-main-suite pass is claimed from this selected native run.
Current alpha main075 comparison (2026-10-13)
#4451 head 0bcf45842, pinned main 075169f7b3faeae1216efc35df41c44fac9f3190, same gpl4152-main location/toolchain/driver/cache conventions as above. Fifteen groups x5 are attempted in each mode:
| Group | AMD GPL on | AMD GPL off |
|---|---|---|
| Existing undithered coverage | Fails first run | Passes x5 |
| New dithered coverage | Fails first run | Passes x5 |
| Wave32 | Passes x5 | Fails first run |
| Other twelve groups | Pass x5 | Pass x5 |
NVIDIA passes all 15 groups x5 in both modes. Replacing all 15 changed core production/header/fixture files with exact main 075 (CMake registrations retained), then byte-exact restoration/full rebuild, gives the same original-fixture undithered-on/wave32-off failures in both controls. Main lacks the new dithered fixture; no baseline dithered result is claimed. No placement inversion, LTO or driver-cache-clearing campaign was repeated here. Older placement observations remain scoped to their own artifacts; no root cause or alpha-specific regression is established.
Full NVIDIA: 1054 passed / 0 failed / 8 skipped of 1062, maximum 24.0818 s; BDA device/span/interlock each pass five serial repetitions with matched main and restored candidate, and restored sparse CPU/native controls pass x5. Historical main-77 at head9ea was 1046/0/8 of 1054, max23.0308 s, before the canonical-21 collision; that is not current compatibility proof. Historical main-4bb loader error 127 is covered by merged #5025. No new title/Linux/console claim or production workaround. AI-assisted: Codex.
Previous alpha main2cc comparison (2026-10-13)
Exact #4451 head3d3ad6a92, base main 2cc97e1057aaffd5b37b38af5def142899375ea5, original build location gpl4152-main, g++.exe/empty launcher. Full build/libraries pass. The eleven-group campaign changes the earlier head4a pattern:
| Group, current head | AMD GPL on | AMD GPL off |
|---|---|---|
| Existing undithered coverage | Fails first run | Passes five repeats |
| New dithered coverage | Fails first run | Passes five repeats |
| Wave32 | Passes five repeats | Fails first run |
| Other eight selected groups | Pass five repeats | Pass five repeats |
NVIDIA passes all11 groups five times in both modes. The first AMD alpha failure still loses the preserved background at alpha0; wave32 leaves0xdeadbeef. Stronger current comparison: replace all15 changed core production/header/fixture files with exact2cc main (retaining CMake test registrations), rebuild the selected native targets and libraries, and run the original undithered/wave32 fixtures:
| Production and original fixtures | Undithered on/off | Wave32 on/off |
|---|---|---|
| Exact2cc main | Fail / pass x5 | Pass x5 / fail |
| Byte-exact source restoration and full rebuild | Fail / pass x5 | Pass x5 / fail |
Failing fixtures stop on their first execution. Main lacks the new dithered fixture, so it is not part of that main control. This is a matched production/fixture comparison, not a whole untouched checkout. No location/LTO/driver-cache-clearing control was repeated here. The older inversion observations above retain their own artifact scope; no root cause or alpha-specific regression is established.
Full NVIDIA 1029/2/8 of1039, max24.406s. BDA span/interlock failures also reproduce with matched2cc main and restored head; #3291 records them. Decoder compatibility controls and conflict-adjacent sparse CPU/native groups pass. Environment/GPU/cache conventions remain as above. Previous review head4a on510a had three GPL-on failures and passed GPL-off; it was a different revision/build, not a cause bisect. No production workaround or new title/Linux/console claim. AI-assisted: Codex.
Activity
simonbbby commentedon Oct 13, 2026
Linux/RADV control on the same PCI device (
1002:13c0): both existing fixtures pass 5/5 with GPL on and 5/5 with GPL off, at both the original build location and after copying only the executables to an empty directory. That is 40/40 passing processes; no location inversion or GPL-mode mismatch in this control.Tested
agc_driver_alpha_to_coverage_testsandagc_driver_wave32_subgroup_testsfrom the existing clean regression build atmain2a5eca11cd1bf583db39ce67034e8453842ac244. Copies have identical SHA-256 digests. Every run uses the same current directory (build) and the original.prxfiles viaLD_LIBRARY_PATH;lddconfirms the same library paths. All 40 logs select RADVRAPHAEL_MENDOCINO, vendor0x1002, device0x13c0, subgroup 64.Ubuntu 24.04 / Linux 7.0, Ryzen 9 9950X iGPU (gfx1036), Mesa 25.2.8, GCC 13.3, Release, SPIRV-Tools ON.
VK_DRIVER_FILES=radeon_icd.json,ANYPS5_GPU=RADV,ANYPS5_REQUIRE_VULKAN=1,ANYPS5_NO_SHADER_CACHE=1,MESA_SHADER_CACHE_DISABLE=true; GPL on leavesAPS5_NO_GPLabsent, off sets it to 1. Five serial runs per cell, 30 s bound, no skips.This uses an older main than the Windows controls in the issue, a different OS/driver, and SPIRV-Tools ON. It is a scoped Linux datapoint, not a matched-current-main comparison or proof that the Windows driver alone causes the failure. The dithered fixture and #4451 head were not tested in this run.
LeandroLP23 commentedon Oct 13, 2026
A second AMD Windows data point, on a different RDNA generation and driver: Windows 11 (26300), Radeon 860M (RDNA 3.5,
1002:1114), driver 32.0.13058.8001, WinLibs GCC 15.2.0, Release, testing ON, SPIRV-Tools OFF,main8bcd97cd5. Each cell is five fresh processes, run from the same current directory (the checkout root) withANYPS5_NO_SHADER_CACHE=1. The copies are SHA-256 identical to the build outputs.APS5_NO_GPL=1agc_driver_alpha_to_coverage_testsagc_driver_alpha_to_coverage_testsagc_driver_wave32_subgroup_testsagc_driver_wave32_subgroup_testsSo on this machine, where the executable sits makes no difference. The GPL mode does, and it fails the other way round from your RDNA2 result. With GPL off, both fixtures fail on every run:
alpha 0x00000000 with alpha-to-coverage on: channel 0 of pixel (0, 0) inside the scissor holds half 0x0000, expected 0.5wave32 subgroup: thread 0 v_mbcnt_lo_u32_b32 is 3735928559, expected 0. The0xdeadbeeffill was never overwritten.With GPL on, the full
ctest -R '^agc_' -j 1passes on this machine (464/464). This suggests that, on AMD's Windows driver, the result depends on which pipeline compile path is used (library vs monolithic), and which path breaks depends on the driver version. The path to the executable shouldn't matter by itself.LeandroLP23 commentedon Oct 13, 2026
On this machine (Radeon 860M, driver 32.0.13058.8001,
main5d50886ee), GPL-off is broken for more than those two fixtures: withAPS5_NO_GPL=1,ctest -R '^agc_' -j 1passes 196/470. Compute-only fixtures fail too, for exampleagc_driver_buffer_load_store:lane 0 load_ubyte is 0xdeadbeef, expected 0x00000000. So nothing a pipeline writes lands, whatever the stage. Without the variable the suite passes except for one test:agc_driver_layered_volume_vertex_no_gpl, new with fix(agc): render all attachment layers with dynamic rendering #3763, fails on every run:slice 1 texel (0, 0) channel 0 is 64, expected 255 (the band of layer 0). With a temporary per-slice dump, no layer receives its band with GPL off, whileagc_driver_layered_volume_vertex(the same draw with GPL) fills every band. That test setsAPS5_NO_GPL=1itself, so on this driver it fails in a default run of the suite. It's this issue, not fix(agc): render all attachment layers with dynamic rendering #3763's change.Your RDNA2 (driver 32.0.21036), NVIDIA and RADV runs pass GPL-off. That points at the older AMD Windows driver's non-library device configuration, and not at the relocation.
Amoenus commentedon Oct 13, 2026
@LeandroLP23 Confirmed a compute-only failure on our RDNA2 Windows device as well: AMD Radeon(TM) Graphics
1002:13c0/ gfx1036, driver32.0.21036.18, Windows11 Enterprise26200.a5a282cdon pinned main b0d, adapted #5097/#5137 + #4451 stack. Existingagc_driver_buffer_load_storeruns once per cell:Both failures report:
Executable SHA-256 matches between locations; every original unpatched runtime
.prxhash stays unchanged before/after. Same cwd/PATH, verified device and mode, no skips, all processes under0.72s, AnyPS5 shader cache disabled; driver cache untouched. This is one execution per cell, not five or an all-compute-suite result.Our original-location alpha still has the opposite mode pattern (on fails/off passes), while the earlier e152 alpha copy control in the body reverses it. These observations do not establish uniform failure across all stages or one shared cause.
Source observation:
VulkanDevice.cppenables six extensions and the GPL/extended-dynamic-state/dynamic-rendering feature chain when GPL is available and enabled. The switch therefore changes logical-device setup too. That file is byte-identical to pinned main b0d in this stack; the run remains an adapted-stack test, with no unchanged-main or root-cause claim. No production workaround added. AI-assisted: Codex.simonbronk commentedon Oct 14, 2026
The mode inversions here come from the AMD Windows driver's own on-disk pipeline cache (
%LOCALAPPDATA%\AMD\VkCache). Whichever GPL mode compiles a pipeline first stores it there. A process in the other mode then gets that cached binary, and its writes never land. With the cache emptied before each run, both modes pass every time.Same device as @Amoenus: AMD Radeon(TM) Graphics
1002:13c0/ gfx1036, driver 32.0.21036.18, Windows 11 Pro 26200, WinLibs GCC 15.2.0 r7, Release,main5a6ad0e,ANYPS5_NO_SHADER_CACHE=1(so AnyPS5's ownvk-pipelines-*.binis not used). Fixtures:agc_driver_alpha_to_coverage,agc_driver_buffer_load_store,agc_driver_wave32_exec_lane_bits,agc_driver_layered_volume_vertex. To empty the cache I renamedVkCacheaway between runs.0xdeadbeef/0x40untouched)Fresh-cache runs take about 0.7 s and cached ones about 0.3 s, so the second process really is served from the cache. Changing
VkApplicationInfo::pApplicationNameper mode doesn't separate the entries: the same four.parcfiles are written and the inversion stays.Before I found the cache, I bisected the GPL switch with temporary overrides.
fixedPushSlotsandregistrationModulesforced to the GPL-on values don't fix GPL-off. With GPL off, enabling onlyVK_KHR_pipeline_library+VK_EXT_graphics_pipeline_library(with the feature) on the device makes compute writes land. That run used the GPL-filled cache, so it fits the picture above: the driver compiles differently when that feature is enabled on the device, and its cache key doesn't include it.This explains:
agc_driver_layered_volume_vertex_no_gplfails in a normal suite run on AMD Windows (agc_* tests: 3 of 483 fail on AMD Radeon RX 6400, pass on NVIDIA RTX 4080 SUPER #5271): the GPL-on tests before it filled the cache.agc_driver_lds_mixed_width_atomicsis not this; it fails on this device with an empty cache too.A user who never switches mode shouldn't hit it. Still, anything that changes enabled device features between AnyPS5 builds could hit the same reuse, if it changes how this driver compiles. I haven't tested that.
AI-assisted (Claude Code).
PYTHONRETARDE commentedon Oct 15, 2026
A workaround on the AnyPS5 side, following @simonbronk's finding that the driver cache doesn't key on the enabled GPL feature: with the library feature off, flip bit 15 of the SPIR-V generator word (header word 2) of every module before
vkCreateShaderModule. No driver interprets that word, but it changes the module bytes, so the two modes get separate cache entries.Commit on my fork, on
main839d2424:bf140983. It covers all 11 module sites: the recompiled compute (VulkanDevice.cpp) and graphics (Pipeline.cpp) programs, and the embedded colour transfer, detile, CMASK clear, sample counter/dumps, mesh arguments and presentation shaders, through oneCacheKeyedSpirvhelper inContext.hpp. Tagging only the two recompiled paths fixed the compute fixtures but notalpha_to_coverageandlayered_volume_vertex; the embedded shaders have to be keyed too.RX 7800 XT (RDNA 3,
1002:747e), driver 32.0.31041.1004, Windows 11 Pro 26200, WinLibs GCC 15.2.0 r7, Release,ANYPS5_NO_SHADER_CACHE=1.VkCacheemptied, then the four fixtures from the table above (alpha_to_coverage,buffer_load_store,wave32_exec_lane_bits,layered_volume_vertex) run per mode in sequence:main839d2424bf140983Full CTest with
bf140983from an emptyVkCache: 1245 of 1247 pass, includingagc_driver_layered_volume_vertex_no_gpl(fails in every full run onmainhere, as in #5271). The two failures are unrelated:guest_kqueue(user name equals computer name, fix in #6173) andguest_memory(passes 5/5 alone).Not tested: other AMD GPUs or drivers, NVIDIA, Intel, Linux, any title. The cost is one copy of the SPIR-V per module creation. I can't open it as a PR until #6173 is merged or closed (one open PR at a time); if someone wants to take it sooner, it's yours.
AI-assisted: yes (Claude Code).
LeandroLP23 commentedon Oct 15, 2026
@PYTHONRETARDE your
bf140983also fixes the inversion on a second AMD generation and driver.Windows 11 (26300), Radeon 860M (RDNA 3.5,
1002:1114), driver 32.0.13058.8001, WinLibs GCC 15.2.0, Release. The commit was cherry-picked cleanly ontomaind92a8dad3.ANYPS5_NO_SHADER_CACHE=1, the libraries frombuild/core/libs/libs/unpatchedfirst onPATH, and%LOCALAPPDATA%\AMD\VkCacheemptied before each sequence. Each step runs the same four fixtures:alpha_to_coverage,buffer_load_store,wave32_exec_lane_bitsandlayered_volume_draw --vertex-only.maind92a8dad3bf140983onstep of the second sequence passes onmain. Only the mode that differs from the one that filled the cache fails.ctest -R '^agc_' -j 1with the commit, from an emptyVkCacheandtests/shader_cache: 569 of 570 pass, includingagc_driver_layered_volume_vertex_no_gpl, which fails in every full run onmainon this machine.agc_driver_quad_pixel_mask(implicit-LOD sample with quad pixel mask 2: pixel (0, 0) channel 2 is 2, expected 0). It fails 3 of 3 onmaind92a8dad3without the commit as well, with GPL on and off.Not tested: titles, NVIDIA, Intel, Linux.
AI-assisted: yes (Claude Code).
fix(agc): key shader modules by the pipeline library mode
fix(agc): key shader modules by the pipeline library mode
LeandroLP23 commentedon Oct 15, 2026
@PYTHONRETARDE I took you up on the offer: #6436 carries
bf140983with your authorship, rebased onto currentmain. It adds one commit of mine for a module site that landed after your base (the compute pipeline replay). Your RX 7800 XT results are credited there next to the 860M runs. If you'd rather open it yourself once #6173 is through, say so and I'll close mine.fix(agc): key shader modules by the pipeline library mode
fix(agc): key shader modules by the pipeline library mode
fix(agc): key shader modules by the pipeline library mode
LeandroLP23 commentedon Oct 20, 2026
#6436 is now on
main(2ea00aa). It routes everyvkCreateShaderModulethrough one helper, which marks the module's SPIR-V generator word when GPL is off. So AMD's per-executable driver cache can no longer serve a module built in one GPL mode to the other. That is the cross-mode cache sharing this issue's location-dependent pattern points at. I can't confirm the fix from my hardware, though, because the pattern doesn't reproduce here even without #6436:Radeon 860M (RDNA 3.5,
1002:1114, driver 32.0.13058.8001), Windows 11 26300, WinLibs GCC 15.2.0, Release. The recipe above was followed:ANYPS5_GPU=AMD Radeon,ANYPS5_REQUIRE_VULKAN=1,ANYPS5_NO_SHADER_CACHE=1,APS5_NO_GPL=1for off, and the driver cache not cleared.mainaa1b1bf (with #6436)build/testsbuild/testsEach cell is
agc_driver_alpha_to_coverage_teststhenagc_driver_wave32_subgroup_tests. On the parent build I also tried first-use order: a fresh copy under a new name (so a new driver cache identity), run once in one mode and then five times in the other, both ways round. Every run passed. The same held three times foragc_driver_layered_volume_draw_tests --vertex-only, the case that failed here on #6436's branch with an old, populated driver cache.So on this device it stays clean either way. @Amoenus, could you rerun the two fixtures on current
mainwith your1002:13c0setup? Can @PYTHONRETARDE do the same on the RX 7800 XT? If the original-location and copied-location cells now agree, this can be closed.AI-assisted: yes (Claude Code)
Amoenus commentedon Oct 20, 2026
@LeandroLP23 retested the real alpha fixture on unmodified main
338f22e493, including #6436. Original-path AMD GPL-on still fails 3/3 with the same alpha-zero mismatch; copied GPL-on and both GPL-off locations pass3/3. RTX5080 passes all four mode/location cells3/3.24 processes:21 passes /3 retained assertion failures. Required Vulkan and loaded Khronos1.4.363, no skips/timeouts/VUIDs/validation errors. The63 existing unused-output warnings are disclosed in the updated issue summary, alongside exact artifact identities and scope. All360 runtime files and both executable hashes remain unchanged during the matrix; driver cache remains as found.
A supported-control probe adds one limit: this AMD driver advertises
VK_KHR_pipeline_binarybut reportspipelineBinaryInternalCacheControl=false, so Vulkan does not permit disabling its internal cache through that API. NVIDIA reports true; we did not apply the unsupported setting on AMD. Stale-cache reuse versus generator-sensitive compilation remains unresolved. The earlier generator marker remains a diagnostic at its original main5b59 pin, not a qualified production fix.AI-assisted: yes (Codex); author responsible.
[-]AMD Windows: identical AGC executables invert GPL pass/fail results after relocation[/-][+]AMD Windows: alpha-to-coverage still fails at the original executable path after #6436[/+]thuanquang commentedon Oct 21, 2026
One more AMD data point for the matrix: a discrete RDNA 2 card, RX 6700 XT (gfx1031), AMD Windows driver 32.0.21045.5002, Windows 11 26200, MinGW GCC 15.2.0, Release.
On
maina07e985c8, which includes #6436,agc_driver_alpha_to_coveragepasses 10 of 10. It ran from its original build path through CTest (--repeat until-fail:10), with GPL on andANYPS5_REQUIRE_VULKAN=1, and the driver's cache for that executable left as it was. That is the cell your iGPU fails.So this original-path failure doesn't reproduce on this GPU and driver. That fits a cause tied to what your 32.0.21036.18 cache holds for that path, but it can't rule it out, since this cache was filled by recent builds only.
CrimsonMac commentedon Oct 23, 2026
After #6436, AMD's driver cache still crosses GPL modes for three tests here. In each of them, every SPIR-V module already differs between the two modes.
Ryzen 5 7600 iGPU (
1002:164e, gfx1036), AMD Windows driver 32.0.21042.62, Windows 11 26100, WinLibs GCC 15.2.0 r7, Release,main11e8ad293. In each sequence,%LOCALAPPDATA%\AMD\VkCachewas emptied, then the whole^agc_group ran with-j8:APS5_NO_GPL=1agc_driver_sample_order*, #9313)APS5_NO_GPL=1→ GPL onagc_driver_sample_order*)agc_sampled_storage_base_level_usage:sampled sRGB base level: read 0.000000, expected 0.215860agc_copied_direct_ordering:vkQueueSubmit recorder: Vulkan result -4(device lost)agc_recorder_cube:single cube snapshot sampled the wrong face: read 0.000000, expected 0.062745Whichever mode fills the cache first passes. The other mode then fails all three, every time, until
VkCacheis emptied. That also holds withANYPS5_NO_SHADER_CACHE=1 APS5_NO_PIPELINE_JOURNAL=1, so AnyPS5's own caches aren't involved.What I ruled out, with temporary local changes (none of them proposed):
Graphics::CreateShaderModulecreates inagc_driver_recorder_tests --cube-only, from an empty cache in each mode. It creates three modules in each mode, and none of the six is byte-identical across modes.MultisampleUpload.cpp,SampleOrder.cppandTextureDetiler.cpp(the depth sample copy) landed around the same time as fix(agc): key shader modules by the pipeline library mode #6436, so their modules aren't keyed yet. Routing them throughCreateShaderModulechanges nothing. The whole-suite matrix above is identical with and without that change.VkApplicationInfo::applicationVersionorpApplicationNameper mode changes nothing either. The driver keeps writing one.parcfile under the same name.All three tests copy or sample textures through the recorder (an sRGB base level, a cube face, copied direct writes). So my guess is that the stale entries are pipelines the driver builds itself for copies, blits or clears, which no change to our SPIR-V can key. I haven't confirmed that. If anyone knows a way to give those internal pipelines separate cache entries per device configuration, this would be the place to try it. Otherwise, clearing
VkCachebetween GPL modes stays the workaround for AMD Windows test runs.AI-assisted: yes (Claude Code).
PYTHONRETARDE commentedon Oct 24, 2026
@LeandroLP23 sorry for the delay, here is the RX 7800 XT rerun. RDNA 3 (
1002:747e), driver 32.0.31041.1004, Windows 11 Pro 26200, WinLibs GCC 15.2.0 r7, Release,main6cd36e6 (with #6436). Same setup as CTest: the repo root as the current directory,build/core/libs/libs/unpatchedfirst onPATH,ANYPS5_REQUIRE_VULKAN=1,ANYPS5_NO_SHADER_CACHE=1,APS5_NO_PIPELINE_JOURNAL=1,APS5_NO_GPL=1for off.VkCachewas left as found (32 files from earlier runs). Both copies are SHA-256 identical to the build outputs.build/testsEach cell is
agc_driver_alpha_to_coverage_teststhenagc_driver_wave32_subgroup_tests. The first run of each cell took 1.0–1.4 s and the other four about 0.25 s, so each mode built its own pipelines instead of reusing the other mode's. Onmain839d242 (before #6436) these fixtures failed in whichever mode didn't fill the cache, so the location and mode cells now agree here.@CrimsonMac your three tests also cross modes on this card and driver, on the same
main.VkCachewas emptied before each sequence, and each step ran the three tests through CTest:The failures are the same as yours:
sampled sRGB base level: read 0.000000, expected 0.215860AGC graphics: vkQueueSubmit recorder: Vulkan result -4single cube snapshot sampled the wrong face: read 0.000000, expected 0.062745So it isn't specific to gfx1036 or driver 32.0.21042.62. I didn't repeat the changes you ruled out.
AI-assisted: yes (Claude Code).
[-]AMD Windows: alpha-to-coverage still fails at the original executable path after #6436[/-][+]AMD Windows: GPL-mode cache failures (alpha/wave32 pass after local driver update)[/+]Amoenus commentedon Oct 26, 2026
@CrimsonMac your three reported fixtures also reproduce on our updated AMD iGPU driver32.0.21045.16010 (Vulkan26.10.1), on literal main
d3b397b750bf55fed924036a344917c1e6fa920f. For each fixture: default4/4 pass, forced GPL-off0/4 pass; the matching RTX5080/621.01 controls pass4/4 in both modes. The assertion values/device-loss error match your report.All48 source-pinned results and verbose logs; the issue body now has the concise table. Actual GPU and loaded Khronos layer verified; no VUIDs or timeouts. Caches/implicit layers were left as found, without full-suite priming or clean-cache controls, so this does not prove cache poisoning or a driver-only cause. The original alpha/wave32 passes after our driver update do not resolve these distinct cases. Keeping the issue open. AI-assisted: yes (Codex).
LeandroLP23 commentedon Oct 27, 2026
A run with clean-cache controls, since the last two comments left caches as found. On this GPU, whichever GPL mode runs first against the AMD driver cache passes, and the other mode then fails.
Setup. Radeon 860M (Ryzen AI 7 350, gfx1150 / RDNA 3.5), AMD Windows driver 32.0.13058.8001, Windows 11 Home 26300, WinLibs GCC 15.2.0 r7, Release,
maincb45ae2ddf. Every run hadANYPS5_REQUIRE_VULKAN=1 ANYPS5_NO_SHADER_CACHE=1 APS5_NO_PIPELINE_JOURNAL=1 VK_INSTANCE_LAYERS=VK_LAYER_KHRONOS_validation, run throughctest -Vfrombuild. "off" addsAPS5_NO_GPL=1. The validation layer from Vulkan SDK 1.4.363.0 was confirmed loaded withVK_LOADER_DEBUG=layer. The AMD cache is%LOCALAPPDATA%\AMD\VkCache.The three fixtures are
agc_sampled_storage_base_level_usage,agc_copied_direct_orderingandagc_recorder_cube. Each step ran all three twice, in this order:Phase B is the deciding run: with an empty cache, forced GPL-off passes all three fixtures, and the default mode then fails all three. Phase C reverses the order, and so does the result. A failing mode did not change the outcome for the mode that filled the cache (A4 still passes after A2 and A3).
The failures match CrimsonMac's and Amoenus' reports:
sampled sRGB base level: read 0.000000, expected 0.215860fresh direct consumer ran before copied write-backsingle cube snapshot sampled the wrong face: read 0.000000, expected 0.062745No
VUID-lines and no missing layer in any of the 48 runs. The original cache was restored afterwards.So on RDNA 3.5 with this driver, too, the result follows which mode filled the cache first. This supports the cache-crossing explanation over a fault in either GPL mode on its own.
AI-assisted: yes (Claude Code)