WebGPU Device Lost Event – Interoperability with Browser Upgrade

Answer to the specific questions

1. Does the device.lost event fire before or after any command buffers queued in the current frame?

According to the WebGPU specification, the timing of device.lost is implementation‑specific: it may be delivered synchronously (immediately when the loss is detected) or asynchronously (queued as a task). Therefore the spec does **not** guarantee whether the event occurs before or after command buffers submitted in the same frame.

2. If it fires asynchronously, at what point in the rendering pipeline is it guaranteed to be observed?

Observed behavior in current Chrome (≥124) and Firefox (≥128) is that the lost event is fired as a microtask **after** the current render frame has finished. At that point any queue.submit calls made earlier in that frame have been recorded (and may have begun execution), but work that was still in‑flight on the GPU may not yet be complete. No earlier guarantee exists across browsers.

3. Are there any version‑specific guarantees that browsers will provide a consistent loss timing in future releases?

No. The timing is explicitly left to the implementation and may change in future releases. Developers must treat device.lost as potentially arriving before or after any given frame’s command buffers.

Safe recovery steps for a browser‑upgrade scenario

1. Listen for the device.lost event on the GPUDevice.
2. When the event fires, await device.lost.promise to ensure the loss notification has been fully processed.
3. Optionally, await device.queue.onSubmittedWorkDone() to flush any previously submitted work that might still be executing on the GPU.
4. Release the old device (call device.destroy() if needed) and request a new adapter and device via navigator.gpu.requestAdapter() and adapter.requestDevice().
5. Recreate any GPU resources (buffers, textures, bind groups, pipelines) that were tied to the lost device.
6. Resubmit the command buffers that were pending before the loss, using the new device’s queue.

Why this works

By waiting for the lost promise (and optionally the queue’s completion promise) you guarantee that no in‑flight work is silently discarded, regardless of whether the loss notification arrived before or after the current frame’s submissions. The subsequent recreation of the device with a fresh queue provides a clean state for resubmission.

Missing diagnostic detail

If you need to distinguish whether the loss happened before or after a particular frame’s work (e.g., to decide whether to resubmit or skip a frame), you would need a timestamp or frame‑counter that is recorded both before submitting work and when handling the lost event. Without that detail, the safe‑recovery approach above remains the recommended course.