Skip to content

Restore retained wgpu textures after device loss - #8292

Open
luo007 wants to merge 1 commit into
emilk:mainfrom
luo007:luoc/rdp-staging-buffer-fallback
Open

Restore retained wgpu textures after device loss#8292
luo007 wants to merge 1 commit into
emilk:mainfrom
luo007:luoc/rdp-staging-buffer-fallback

Conversation

@luo007

@luo007 luo007 commented Jul 6, 2026

Copy link
Copy Markdown

fix #8265.

What this fixes

This PR fixes a wgpu recovery issue that can happen after a remote desktop/session disconnect.

When the remote session is disconnected, the underlying wgpu device can be lost. eframe then recreates the wgpu renderer/device, but textures that were already retained by egui before the device loss could become blank afterwards.

The affected case is when egui still references an existing managed TextureId, while the newly recreated wgpu renderer no longer has the corresponding GPU texture resource.

Root cause

egui keeps texture state at a higher level than the wgpu renderer. During normal rendering, texture uploads are sent through texture deltas, and unchanged retained textures are not uploaded again every frame.

After a remote disconnect triggers wgpu device loss, the old GPU-side texture resources are gone. However, egui may still consider those textures alive and continue referencing their existing TextureIds. Since those textures have not changed from egui's point of view, no fresh upload delta is produced for them.

That leaves the recreated renderer in this state:

  • egui still retains and references the texture.
  • the old wgpu device/renderer lost its GPU copy during device loss.
  • the recreated renderer does not automatically receive a replay of the retained texture data.
  • rendering can then use a TextureId that has no valid GPU-side texture in the new renderer.

The result is that images/textures that were visible before the remote disconnect can become blank after recovery.

How this is fixed

This change keeps enough CPU-side texture information for managed textures so they can be restored when the wgpu renderer/device is recreated.

The recovery path now:

  • exposes the set of textures currently retained by egui/epaint;
  • retains the texture metadata and CPU-side data needed to replay managed texture uploads;
  • passes retained textures through the native wgpu recovery path;
  • replays those retained texture uploads into the newly created wgpu renderer;
  • leaves already-freed textures alone, so only textures still retained by egui are restored.

This lets renderer recovery rebuild the GPU-side texture state after wgpu device loss, without requiring the application to modify or re-upload unchanged egui-managed textures manually.

Additional changes

A minimal wgpu_recovery_minimal example is added to make this remote-disconnect/device-loss recovery path easier to reproduce and manually inspect.

Testing

I did not run the full test suite locally.

The new wgpu_recovery_minimal example is included as a focused manual repro for checking that retained textures are restored after wgpu device loss and renderer recovery.

@luo007
luo007 requested a review from Wumpf as a code owner July 6, 2026 09:19
@github-actions

github-actions Bot commented Jul 6, 2026

Copy link
Copy Markdown

Preview is being built...

Preview will be available at https://egui-pr-preview.github.io/pr/8292-luoc/rdp-staging-buffer-fallback

View snapshot changes at kitdiff

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

egui-wgpu panics in Renderer::update_buffers when Queue::write_buffer_with returns None on Windows Server + RDP

1 participant