Repository navigation
cargo, wgpu: test the CI feature set without rex-gpu, and report why a submission was refused - #700
Open
jamesbraid wants to merge 2 commits into
Open
jamesbraid wants to merge 2 commits into
jamesbraid wants to merge 2 commits into
Conversation
Windows CI has failed since the GPU-resident Newport work (bfd55f1) made rex-gpu turn on the whole wgpu feature. rex-gpu was in the one CI feature set only to run the REX3 replay corpus and the REX3 GPU matcher in the main nextest build. Since that change it also compiles every IMPACT and VPro wgpu raster suite into the ordinary test job. Linux runners have no adapter, so those tests skip there; Windows runners have WARP, the software D3D12 adapter, which cannot compile the raster kernels (FXC: error X3511), so 26 tests failed on every run. A prototype flag for one board should not decide which GPU suites the general test job runs. Test the corpus with the features it needs, gputrace and rex-jit, and leave rex-gpu out. The corpus keeps running (14 tests); the 9 REX3 GPU matcher tests need an adapter and skipped on Linux runners anyway; GPU suites belong in a job that names its adapter. rex-gpu itself still compiles through the existing cargo check of the REX3 GPU probe.
When a compute pipeline fails to build, wgpu hands the error to the
device's error handler and fails every submission that uses the
pipeline. A later Gpu::wait on such a submission gets wgpu's "Tried to
wait using a submission index (14) that has not been returned by a
successful submission" and returned that before looking at the error
the handler stored. On Windows CI the IMPACT raster tests failed with
exactly that message, while the cause, FXC failing to compile the raster
kernel ("error X3511: forced to unroll loop, but unrolling failed"), sat
unreported in the same Gpu. Read like that, it looked like a device lost
or poisoned by some other test.
Check the stored error first, so a wait on a refused submission names
what refused it. The new test builds a pipeline from WGSL that fails
validation, submits a dispatch with it and expects the wait to return
the validation error.
jamesbraid
force-pushed
the
fix/windows-wgpu-software-adapter
branch
from
November 13, 2026 07:30
4f5a304 to
7633316
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Test (windows-latest)has failed on every main run since 972325f, and on every pull request based on it: the same 26 wgpu tests, all of the IMPACT and VPro raster unit tests plus four of the shared layer's.The GPU-resident Newport work (bfd55f1, from Tzeentchnet's #569) made
rex-gputurn on iris's wholewgpufeature.rex-gpuwas in the CI feature set only to run the REX3 replay corpus and the REX3 GPU matcher in the main nextest build, so from that change the ordinary test job also compiled every IMPACT and VPro wgpu raster suite. Linux runners have no GPU adapter, so those tests skip there. Windows runners have WARP, the software D3D12 adapter, which cannot compile the raster kernels (FXC:error X3511: forced to unroll loop, but unrolling failed). At ce3a53f, the last green run, none of these tests were in the Windows build.cargo: test the CI feature set without rex-gpu: the CI feature set becomesjitv2,rex-jit,gputrace. The corpus keeps running with the features it needs (14 tests). The 9 REX3 GPU matcher tests need an adapter and already skipped on Linux runners. GPU suites belong in a job that names its adapter (the lavapipe job).rex-gpuitself still compiles through the existingcargo checkof the REX3 GPU probe.wgpu: report the error that refused a submission, not the failed wait: the misleading "Tried to wait using a submission index (14) that has not been returned by a successful submission" on Windows was wgpu refusing every submission after the pipeline failed to compile.Gpu::waitnow returns the stored error first.a_refused_submission_reports_whyfails with CI's old message without the change.Checked locally:
cargo check --workspace --all-targetswith the new CI set, the corpus tests (14 pass) and the new test. The diagnosis, including a Windows runner run of the failing suites on WARP, is from probe runs on a fork.