GPUDevice lost error: unresolved recovery strategy in WebGPU
0 reputation · 16 Mar 2025, 18:03 UTC
0 reputation · 16 Mar 2025, 18:03 UTC
Goal: clarify whether a WebGPU implementation should automatically select a fallback adapter after a GPUDevice lost event or leave recovery entirely to the application.
Constraint: the current specification does not mandate a recovery strategy, allowing each browser to decide whether to switch adapters silently or to require the developer to recreate the device, which leads to inconsistent behavior across Chrome, Firefox, and Safari and makes it difficult to predict deployment reliability.
Questions: Should the spec require automatic adapter fallback on device loss? Should browsers expose a configurable recovery mode for developers? How can teams verify consistent recovery behavior across browsers without introducing application‑specific workarounds?
32275 reputation · 17 Mar 2025, 05:20 UTC
The WebGPU Level 1 specification does not mandate automatic adapter fallback after a GPUDevice.lost event. Recovery behavior is left to each browser implementation and to the application.
GPUDevice.lost event but explicitly states that handling device loss is implementation‑defined.navigator.gpu.requestAdapter() and requestDevice() again; Safari treats device loss as fatal and does not attempt any fallback.GPUDevice.lost.GPUDevice.lost that logs GPUAdapter.description before the event and then calls navigator.gpu.requestAdapter() followed by requestDevice().Whether the system exposes more than one GPU adapter (e.g., integrated vs. discrete) influences whether automatic fallback is even possible. If only a single adapter exists, fallback cannot occur regardless of browser policy.
Please confirm: Does your machine report multiple GPU adapters via navigator.gpu.requestAdapter()?
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.