Question
WebGPU adapter acquisition: choosing a fallback strategy when requestAdapter() returns null
Ash River
0 reputation · 22 Apr 2022, 09:10 UTC
86.7K views1
Loading…
0 reputation · 22 Apr 2022, 09:10 UTC
I am designing the initialization path for a browser application that uses WebGPU for compute and rendering. The documented entry point is asynchronous: navigator.gpu.requestAdapter() resolves to a GPUAdapter or null, and a null adapter is a normal outcome rather than an exception. I need a deliberate policy for that null case instead of an incidental crash.
The spec leaves fallback behavior to the application, so the decision is mine: fall back to WebGL, degrade to a reduced CPU path, or show an error state. Complicating factors: browser support and enabled-by-default status vary across engines and versions, adapters can be blocklisted per GPU/driver, and the device itself can later be lost via the device.lost promise, so the policy may need to handle both startup failure and mid-session loss. Canvas configuration also depends on navigator.gpu.getPreferredCanvasFormat(), which only makes sense once an adapter exists.
30275 reputation · 22 Apr 2022, 17:58 UTC
1. There is no spec‑defined signal that distinguishes “WebGPU unsupported” from “adapter blocklisted/disabled”; a null GPUAdapter must be treated as a generic fallback trigger.
2. If a GPUDevice is lost (device.lost rejects), the same fallback path used for a startup null adapter should be retried: re‑call requestAdapter() and, if it again returns null, fall back; otherwise recreate the device.
3. Decide once at startup whether to use WebGPU or fall back to WebGL (or a CPU path) unless your application explicitly supports hot‑switching; WebGPU availability does not change during a page lifetime without a browser restart or flag change.
webgpunavigator.gpu.requestAdapter() to resolve to a GPUAdapter or null; null is a normal outcome, not an error.device.lost is a promise that rejects when the GPU device becomes unusable; recovery requires a new requestAdapter() call.navigator.gpu.getPreferredCanvasFormat() must be called only after a non‑null adapter is obtained; otherwise it throws or returns undefined.Because the user agent gives no reason for a null adapter, applications cannot reliably differentiate between a missing WebGPU implementation and a temporary blocklist. Treating every null as a fallback ensures graceful degradation. Device loss is conceptually identical to a startup null adapter: the adapter that backed the device is no longer usable, so the same recovery logic applies. WebGPU support is stable for the lifetime of a page unless the browser is upgraded or flags are toggled, making a per‑session re‑evaluation unnecessary unless the app implements a manual graphics‑quality toggle.
await navigator.gpu.requestAdapter().null, immediately execute your fallback path (WebGL, reduced CPU compute, or error UI).GPUAdapter is obtained, call await adapter.requestDevice() to get a GPUDevice.device.lost; on rejection, return to step 1 and reuse the same fallback decision if the new requestAdapter() returns null.Does your application support hot‑switching between WebGPU and WebGL at runtime? Knowing this determines whether the fallback decision should be re‑evaluated after startup or remain fixed for the page lifetime.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.