Repository navigation
fix(agc): key shader modules by the pipeline library mode - #6436
Conversation
|
Other open pull requests touch the same code. Merging one will break the other, or both implement the same thing. If this one builds on them, list them in Depends on.
Some comparisons could not be completed because a pull request conflicts with the base branch. Review these shared files manually before concluding that there is no overlap.
|
|
An RDNA2 run, the architecture #4768 was first seen on: with this change both GPL modes work on a discrete RX 6700 XT. Setup: AMD Radeon RX 6700 XT (gfx1031, The four fixtures of #4768 (
The base's GPL-off runs report Full suite,
Not tested: a run from an empty AI-assisted: yes (Claude Code). |
github-actions
Bot
added
agc
f7b8ea1 to
719f8df
Compare
|
Rebased onto Retested on the rebased head
|
|
RDNA 4 data point: with this change both GPL modes work on an RX 9070 XT. AMD Radeon RX 9070 XT (
The base failures are those of #4768:
AI-assisted: yes (Claude Code) |
|
Another data point, on current Radeon 860M (RDNA 3.5), driver 32.0.13058.8001, Windows 11 26300, WinLibs GCC 15.2.0 r7, Release. Same
This matches @thuanquang's RX 6700 XT measurement in #7376: the layered-volume failures are the GPL cache-order effect, and with this PR they're gone. Together with #7623, that is what #7376 needs before #7351's AMD AI-assisted |
|
A non-AMD check that the flipped generator word is harmless: NVIDIA GeForce RTX 4090, driver 617.42, Windows 11 Pro 26200, WinLibs GCC 15.2.0 r7, Release,
#6262 makes the same change; this result should hold for it too. AI-assisted: yes (Claude Code) |
|
Another test this fixes on AMD's Windows driver, with a harder symptom than wrong pixels:
So without this change the second GPL mode loses the device here, not only renders wrong. The other PRs in both trees touch neither pipelines nor shader modules: #7769 is a storage-flush wait, #7074 the f16 fma NaN translation, #7725 one stencil refusal. |
|
Thanks for carrying this. |
AMD's Windows driver compiles pipelines differently when VK_EXT_graphics_pipeline_library is enabled on the device, but its on-disk cache (%LOCALAPPDATA%\AMD\VkCache) does not key on it. A process in one mode is then served pipelines compiled in the other, and their writes never land (boykopovar#4768, boykopovar#5271). With the library feature off, every module now flips bit 15 of the SPIR-V generator word, which no driver interprets, so the two modes hash to separate cache entries. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…brary mode The replay rebuilds a captured compute pipeline to time it. With the library feature off, production now flips the SPIR-V generator word before vkCreateShaderModule. The replay creates the same module, so it hits the same AMD driver cache entries as the run it reproduces. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…he key Six vkCreateShaderModule calls added to main since this branch's base still passed their SPIR-V unchanged, so on AMD's Windows driver they shared on-disk cache entries across the two pipeline library modes: splitComputePipeline's recompiled compute programs, the multisample readback modules, the dispatch-arguments module, the texture repack module and the two performance overlay modules. Graphics::CreateShaderModule now keys the generator word and creates the module in one place. Every module the driver creates goes through it, including the recompiled graphics and compute programs that copied the key inline, so new call sites can't skip it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
719f8df to
28ce7bc
Compare
|
Done. The branch is rebased onto
Tested on a Radeon 860M (
One caveat. Before I cleared the driver cache, this machine's existing AMD cache for AI-assisted: yes (Claude Code) |
What
Carries @PYTHONRETARDE's workaround for #4768 (and #5271), with his authorship. He offered it in #4768 while he can't open another PR.
AMD's Windows driver compiles pipelines differently when
VK_EXT_graphics_pipeline_libraryis enabled on the device. Its on-disk cache (%LOCALAPPDATA%\AMD\VkCache) doesn't key on that, a finding by @simonbronk. A process in one mode is then served pipelines compiled in the other, and their writes never land. That's why identical test executables pass or fail depending on which GPL mode filled the cache first, and whyagc_driver_layered_volume_vertex_no_gplfails in every full run on AMD Windows.6d25bbe34(PYTHONRETARDE): with the library feature off, every shader module flips bit 15 of the SPIR-V generator word (header word 2) beforevkCreateShaderModule. No driver interprets that word, but it changes the module bytes, so the two modes get separate cache entries. It covers the recompiled compute and graphics programs and the embedded shaders (colour transfer, detile, CMASK clear, sample counter and dumps, mesh arguments, presentation), throughGraphics::CacheKeyedSpirvinContext.hpp.28ce7bc0b(mine, after review):Graphics::CreateShaderModuleinContext.hppnow keys the word and creates the module in one place. Every module the driver creates goes through it: the sites above, the six added tomainsince (splitComputePipeline, multisample readback, dispatch arguments, texture repack, the performance overlay), and the inline copies inPipeline.cppandcreateComputePipeline.agc_driver_graphicschecks the key through a mockvkCreateShaderModule.f7b8ea1cb(mine): the compute pipeline replay (ComputePipelineReplay) creates its module the same way, so a replay with the feature off hits the same cache entries as the run it reproduces. That module creation was added tomainafter the original commit.The cost is one copy of the SPIR-V per module creation with the feature off. Nothing changes with it on.
Tested
RX 7800 XT (RDNA 3,
1002:747e, driver 32.0.31041.1004, Windows 11 Pro 26200), by @PYTHONRETARDE on839d2424. Each sequence starts from an emptyVkCacheand runs the four fixtures of #4768 in every step:mainHe also ran a full CTest from an empty
VkCache: 1245 of 1247, both failures unrelated.Radeon 860M (RDNA 3.5,
1002:1114, driver 32.0.13058.8001, Windows 11 26300), WinLibs GCC 15.2.0, Release:d92a8dad3(#4768):mainfails the mode that differs from the one that filled the cache, 4/4. The commit passes 4/4 in every step of both sequences.mainff23657f3+ both commits): the same two sequences pass 4/4 in every step, 24 of 24 runs.ctest -R '^agc_' -j 1from an emptyVkCacheandtests/shader_cache: 593 of 596 pass.agc_driver_layered_volume_vertex_no_gplpasses; it fails in every full run onmainon this machine. The three failures are unrelated:agc_driver_quad_pixel_mask: AMD, fixed by fix(shader): kill demoted quad-mask pixels when the pixel program returns #6255;agc_driver_store_over_untracked(the first result was not stored): Windows: StoreOverUntracked fails at "the first result was not stored" #6347;agc_driver_pm4_replay_tool: a staleagc_pm4_replaybinary from an earlier build. It passes once the tool is rebuilt.tools/check_conventions.py --base origin/mainpasses;git diff --checkis clean.Not tested: NVIDIA, Intel, any title. @thuanquang ran the four #4768 fixtures and the full suite on an RX 6700 XT (RDNA 2): every GPL sequence passes,
agc_driver_layered_volume_vertex_no_gplfails on the base and passes here. @savvaniss ran both sequences on an RX 9070 XT (RDNA 4, driver 32.0.31041.1004): the base fails the mode that differs from the one that filled the cache, this head passes 4/4 in every step.Fork CI (run): linux (including
agc_compute_pipeline_replay), windows and the three relinker jobs pass everything exceptconventions_ci_gateandbuild_eligibility, which fail only on the fork's older workflow.Checklist
main; no other open PR implements the same functionsNotImplemented_nid_no_patch); silent stubs are listed under Silent stubs in their library's technical debt file.mdfiles or images added to the repository (attach them to this PR)