- Process ids are reused: report_for_pid now takes the sentinel's arm
time and ignores a report written before it, so an old crash of an
unrelated run with the same pid no longer costs a backend. The test
plants such a stale report.
- is_device_failure drops "buffer" and "surface": drawing code and the
modelling kernel panic with those words too. It keeps wgpu, out of
memory and device lost, and adds wgpu's "validation error".
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
#1519 stopped the sentinel blaming a backend for a run that had already
drawn for SENTINEL_PROOF_DELAY, on the reasoning that a backend which
kept the application alive that long had proved itself. That reasoning
does not hold for the failure this repository sees most on integrated
hardware.
Measured here on an Intel Iris Xe: with `--backend dx12` a large drawing
aborts the process 110 s in, long past the proof delay, so the sentinel
carried `survived=1` and the next launch went straight back to dx12 and
crashed again. The same binary on `--backend vulkan` opens the same
drawings with no out-of-memory report and no uncaptured errors at all,
so the backend really is the difference and moving off it really is the
cure. D3D12 is fine while the interface draws and only fails once the
whole scene uploads, which is why the clock is the wrong question.
The crash report from #1521 answers the right one. It records the
backend that was live and what the panic was, and it is named for the
process that wrote it, so it joins exactly to the `pid` the sentinel
already stores — no guessing from whichever report is newest, and no
new state to keep. A sentinel marked survived is now excused only when
that run left no report, or left one that has nothing to do with the
graphics device.
The test that matters is the pair, and both were run end to end:
killed from Task Manager after 40 s, no report -> dx12 kept
device crash after 110 s, report names wgpu -> dx12 skipped, Vulkan
`is_device_failure` is deliberately narrow: an indexing bug in drawing
code that happens to run on a frame must not cost the user a working
backend.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
#1521 inserted crash_log between web_diag's doc comment and its module, so the comment documented crash_log instead. #1519 wrote the survived marker with a literal line break inside the string.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The crash sentinel is armed before the event loop and disarmed after it
returns, so anything that stops the process without unwinding leaves the
file behind and the next launch skips that backend. A real GPU failure
does that — and so does the user closing the app from Task Manager, an
OOM kill, a power cut, or a panic with nothing to do with graphics.
The cost is not a one-off: the skip is permanent, and each later
abnormal end takes the next backend with it, walking a machine down
dx12 -> vulkan -> gl -> software rasterizer. The user is told their
driver is at fault the whole way.
Seen on this machine: a debug build died once while opening a large
drawing, and every launch afterwards reported "dx12 is not usable on
this GPU" on an Intel Iris Xe. Probing the backends directly showed
dx12 not merely usable but the best of the three
(max_storage_buffers_per_shader_stage 262144, against 59 for Vulkan
and 16 for GL). Clearing the stale sentinel brought dx12 straight back.
The failures this guard was built for kill the process at GPU init or
on the first drawing viewport, which is why arming it at all works. A
run that keeps drawing well past that has already shown the backend is
fine, so it now marks the sentinel `survived=1` after
SENTINEL_PROOF_DELAY, and a sentinel carrying that marker accuses
nobody. An early death still blacklists exactly as before.
Verified both ways on Windows 11 with an Intel Iris Xe: killed after
40s, the next launch still chose dx12; killed after 8s, the next launch
skipped dx12 and fell back to Vulkan.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Older GPUs without usable DirectX 12 Feature Level 12_0 or working
Vulkan support (e.g. legacy Intel iGPUs and other old parts), and old
GLES drivers whose shader compiler rejects iced's own shaders, crash
at startup or on the first drawing viewport: StagingBelt aborts in
Buffer::get_mapped_range (panic=abort, silent exit) on the DX12 path,
and shader compilation fails inside iced's gradient pipeline on the
GLES path. Selecting a working backend via WGPU_BACKEND before iced
boots avoids both classes.
- Probe each candidate backend (Windows: dx12,vulkan,gl; Linux:
vulkan,gl) in an isolated --gpu-probe child: device request,
staging-style mapped upload, render pipeline creation (its fragment
shader reads a private vec4 array, catching old-Mesa compile
failures), offscreen render and readback. First fully-passing
backend wins; explicit --backend / WGPU_BACKEND / --safe-mode
always win, and Windows keeps preferring DX12/Vulkan (#55).
- Software adapters (WARP/llvmpipe/SwiftShader) are the last resort
before a best-effort GL attempt: slow but alive.
- The crash sentinel names the attempted backend so only implicated
backends are skipped next launch.
- Winning probes report adapter limits; GPUs without shader storage
buffers get the packed compatibility renderer automatically, with
a startup command-line notice so the switch is never silent.
Karim Jerbi