Chrome’s latest WebGPU update gives Linux developers a reason to revisit half-precision shaders. The Chrome 155–156 announcement, updated October 7, 2026, reports support for the optional shader-f16 feature on Linux with recent NVIDIA drivers. Before switching a browser AI workload or graphics pipeline to it, check what your application’s device actually enables.
The practical trap is checking adapter.features, seeing the feature, and then creating a device without requesting it. Build the release check around three separate questions: what the adapter offers, what the device enables, and whether the chosen shader and workload work correctly. This guide provides a repeatable worksheet for that check. It reports no hardware benchmark results.
Start with the device your application really uses
A GPU’s product name and a browser version are useful troubleshooting details, but they do not establish the capability of an existing application device. Inspect the object your renderer or inference runtime uses, especially when a library owns device creation.
The WebGPU specification’s optional-capabilities rules distinguish supported adapter capabilities from enabled device capabilities. For shader-f16, check adapter.features.has("shader-f16"), include that feature in requiredFeatures when calling requestDevice(), and check device.features.has("shader-f16") on the returned device. Validation follows the device’s enabled features. A supported feature does not automatically become enabled.
Request the optional capabilities your chosen path needs. Copying every advertised feature into the request makes it harder to explain the app’s actual dependencies. If a framework already created the device, use its documented configuration point rather than creating an unrelated device and assuming the framework will use it.
Keep GPU features and WGSL language features separate
The same Chrome update includes fragment_depth, a WGSL language extension. Chrome’s example checks navigator.gpu.wgslLanguageFeatures.has("fragment_depth") and uses requires fragment_depth;. Do not copy that detection pattern for half precision.
The WGSL enable-extension rules pair the shader’s f16 extension with WebGPU’s shader-f16 feature. An f16 shader needs enable f16; before its declarations, alongside the enabled device feature. By contrast, a language extension is available when the implementation supports it; its requires directive documents a dependency and rejects unsupported implementations rather than enabling a device capability.
Give these checks separate fields in your diagnostic output. A single “WebGPU supported” badge hides the distinction that matters when a shader fails.
Run the initialization check in order
- Check API availability. Test for
navigator.gpuin the application’s actual page context. If absent, record that result and take the app’s documented alternative path. - Request an adapter and handle absence. A request can return
null. Stop before reading its properties. “No adapter” deserves its own diagnostic, separate from “adapter lacks f16.” - Choose the workload path. If f16 is optional and supported, request it explicitly. Otherwise choose your already implemented baseline. An f16-only model or shader needs a clear unsupported-path message if no alternative exists.
- Handle device-request failure. Catch rejection and preserve the error name and message. Unsupported requested features cause failure under the device-request rules. A failed request is not evidence that an f32 workload succeeded.
- Verify the returned device and shader. Record enabled features, inspect shader compilation diagnostics, create the real pipeline, and run a small known input before loading the full workload.
Watch device.lost as well as request rejection. A device request can resolve with an already-lost device, so obtaining an object alone is not proof that initialization succeeded. Record device loss as a separate failure state and exercise that recovery path.
On reinitialization, obtain a fresh adapter. The adapter lifecycle allows one successful device creation per adapter object, and adapters can expire. Recovery code should rebuild the required resources rather than keep using the old device’s buffers and pipelines.
Use this six-case compatibility worksheet
Run each case through your application’s initialization boundary. Where hardware cannot naturally produce a case, inject the condition into a test double and label it as simulated. Keep real-device observations separate. The expected outcomes below are test targets, not measurements.
| Case | Condition to exercise | Expected application behavior |
|---|---|---|
| No API | navigator.gpu absent | Explain unavailability; use an implemented alternative. |
| No adapter | Adapter request returns null | Exit cleanly without accessing adapter properties. |
| Baseline only | Adapter lacks shader-f16 | Select validated f32 assets or explain the requirement. |
| Feature omitted | Adapter offers f16; device request omits it | Device check prevents selecting the f16 shader. |
| Feature enabled | Request succeeds with f16 enabled | Compile and execute the intended f16 path; compare output. |
| Initialization fails | Device request rejects | Preserve the error, release partial state, and offer recovery. |
For each run, record the browser version and channel, operating system, driver version when available, application build, relevant adapter features, requested features, enabled device features, selected shader variant, and the first failing stage. Add the fixture identifier, expected result, observed result, and pass/fail decision. Save the record with the change being reviewed so another developer can reproduce the same path.
Make the fallback an actual workload
A fallback needs its own shader and compatible data handling. Removing enable f16; from source that still contains f16 types does not create an f32 implementation. Blind text replacement also leaves questions about buffer layout, packing, conversions, and numerical behavior. Test those boundaries explicitly.
For a browser AI application, keep a small representative input and a reference output. Decide acceptable numerical differences before comparing variants. For graphics, use a deterministic scene that exposes the calculation being changed. Include boundary inputs meaningful to the application, then check output before timing either path.
If the fallback changes where data is processed, make that visible to users. Moving a local browser task to a server introduces a separate data-handling decision; it should not be a silent consequence of a missing GPU feature.
Decide when to enable f16 by default
Keep the baseline selectable during rollout. Require a clean initialization record, a passing output comparison, and an exercised failure path before promoting the optional implementation. Measure startup and steady-state work separately on representative machines if performance motivates the change. Feature availability alone supplies no application-specific speedup estimate.
Release decision: enable the f16 path only for devices where its feature is enabled and your workload checks pass. Retain a tested alternative or a clear explanation of the requirement. Re-run the worksheet after browser, driver, runtime, or shader changes. That turns the October update into a controlled compatibility improvement instead of an assumption embedded in device initialization.