#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 <[email protected]>
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 <[email protected]>
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.
