* claim: #6528
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Lost GPU: the per-frame probe opens a command list, as the upload would (#6528)
On a reset D3D12 device the empty submission before a frame's uploads
went through (it only signals a fence), and the first queue write then
panicked inside wgpu-core (PendingWrites::activate unwrapping Lost).
The probe now submits a command buffer with a debug marker: finishing it
makes the same begin_encoding call, through a path where wgpu loses the
device and runs its lost callback instead of panicking. The picture
capturer's probe does the same.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* claim: #8876
* Add optional viewport-only Kawase blur and native UI composition
* Fix vendored panel hook imports and deprecated float constant import
* Drain texture updates in the full GPU blur fixture
* Hold the blur evidence fixture camera fixed across radii
* Address blur compositor lint checks
* Share animated Render preview background with blur source
* Use resolved Design background for blur source
* Exercise blur rendering independently of software adapter policy in CI
* Use stock egui hosts instead of vendoring the full crate
* Preserve feature-window open handling with stock egui hosts
* Target the native Window in close-handling regression fixture
* claim: #9118
* Agent chat window: an off-screen chat window no longer stalls the main window (#9118)
The chat popped out into its own window is an immediate viewport: eframe draws
and presents it inside the main window's frame. Both surfaces waited for vsync,
and a Wayland compositor sends no frame callbacks to a window it isn't showing,
so the main window stalled behind the chat window's present.
A surface other than the main window's is now configured with Mailbox, else
Immediate, when the configured mode waits for vsync and the surface offers one
(viewport_present_mode in the vendored egui-wgpu). The main window keeps vsync
and still paces both.
* claim: #7148
* Lost GPU: a dropped frame no longer crashes the window's close (#7148)
On a lost device wgpu's present and discard return early and leave the
acquired frame's image in the surface, holding a swapchain acquire
semaphore. Dropping the surface later (the window closing for the
restart after the loss) then panicked in wgpu-hal. The painter now holds
the frame as AcquiredFrame, which destroys a second handle to the
frame's texture after the frame is presented or dropped; wgpu-core's
destroy of a surface texture takes the image back without checking the
device, and does nothing once a present or discard took it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* claim: #7007
* A surface left without a configuration is configured again, not a crash (#7007)
wgpu reports device-loss errors to no error scope. On D3D12 a driver reset
found by Surface::configure drops the old configuration and reports nothing,
so the surface was taken as configured and the next acquire panicked with
"Surface is not configured for presentation". A configure that meets a lost
device or an unsupported surface is now a refused configure, the acquire runs
under an error scope, and its Validation status reconfigures the surface.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* claim: #4172
* GPU: a lost device stops drawing instead of crashing (#4172)
After the driver resets the GPU (Windows TDR), the first queue write to meet the
lost device panicked inside wgpu-core (PendingWrites::activate unwrapping
DeviceError::Lost). Nothing watched the device for its loss.
- egui-wgpu: RenderState::device_lost (DeviceLost) is set by the device's lost
callback. The painter draws nothing on a lost device, and before a frame's
uploads it submits nothing (DeviceLost::probe), so a loss the driver reports
is found by that submission instead of the first write.
- Pictures (thumbnails of saves, ui.render) watch the same flag: on a lost
device the capturer refuses with GpuError::DeviceLost without touching it,
and the picture comes from the CPU rasterizer. Headless capturers watch
their own devices.
- The app, seeing the loss, closes keeping unsaved changes for recovery (as a
forced quit does) and starts again; the new start says what happened. A
second loss within ten minutes starts on the software renderer. The loss is
noted in the crash journal.
A crash inside a graphics driver left only "an unclean exit between
commands": no backtrace, no module, no hint that it was at startup.
- The crash journal now keeps the startup step the app is in (window,
graphics instance, surface, adapter request, adapter chosen, device
creation, renderer and viewport shader compiles, surface configure,
first frame and its present, running) and the renderer as soon as the
adapter is picked. egui-wgpu tells the app about its steps through a
small hook. An unclean exit before the first frame names the step.
- Windows: an unhandled-exception filter (src/native_crash.rs, the one
Windows-only module allowed unsafe) writes the exception code, the
faulting module and offset, and a minidump next to the journal; the
next start puts them into the report.
- The Windows CI job runs a child that faults on purpose and checks the
report.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Moving a window between monitors of different scale can briefly ask for a
surface larger than the device's largest texture (11512 x 6808 against 8192 in
the report), and Surface::configure failed validation, which wgpu turns into a
panic. The surface is now clamped to the device limit with its aspect ratio
kept, and egui draws the whole window at the matching smaller scale, so the
frame is only softer until the size settles. The device also asks for the
adapter's own texture limit (16384 on most desktop GPUs) instead of 8192, and
the resize path and an unsupported surface log instead of unwrapping.
Fixes#869
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Choosing 8x anti-aliasing in Preferences › Graphics on a device that
only allows 1x and 4x for the window's format made every later start
panic in wgpu's pipeline validation (`Sample count 8 is not supported
by format Bgra8Unorm on this device`), so the app could not be opened
again without editing graphics.json by hand.
- egui-wgpu (vendored): request TEXTURE_ADAPTER_SPECIFIC_FORMAT_FEATURES
when the adapter has it (WebGPU only guarantees 1x and 4x), and clamp
the sample count to the largest one the device supports for both the
colour target and the depth/stencil format. The supported counts are
exposed as `RenderState::msaa_supported`.
- At start, a saved count the device can't do goes back to the default
(4x, or the largest supported count below it), is written back, and a
"Settings were changed" notice says what changed.
- The Anti-aliasing list greys out unsupported counts, `ui.prefs`
rejects them, and an invalid saved `msaa` loads as the default.
- New messages translated in en, de, ja and ko.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Nathan Dane