WebGL, WebGPU and Hardware Acceleration

A graphics processor is built to do the same simple operation across millions of pixels at once, which is exactly what compositing a page, decoding a video or rendering a 3D scene requires. When hardware acceleration is on, the browser routes that work to the GPU instead of grinding through it on the general-purpose CPU. The result is smoother motion and much lower power use for graphics-heavy pages.

Occasionally the browser falls back to software rendering — on a very old machine, with an unsupported driver, or when acceleration is disabled in settings. Everything still works, but animations can stutter and the battery drains faster. Naming the active renderer is the first clue to which path your browser is taking.

WebGL is the long-standing API that lets a page render 2D and 3D graphics directly on the GPU, and it is also how a tool like DeviceScope discovers your graphics adapter: it creates a small, invisible WebGL context and asks it for the vendor and renderer strings. That is why a device checker can name your GPU without any driver access — the browser surfaces it through WebGL.

The name often looks strange, wrapped in something like "ANGLE (Intel, Intel(R) UHD Graphics, OpenGL 4.1)". On Windows, Chromium-based browsers translate WebGL calls through a layer called ANGLE for stability, so the string describes that translation layer with your real GPU nested inside it. Some browsers deliberately mask the renderer entirely for privacy, in which case you will see a generic value — again, honest rather than invented.

When the hardware path is unavailable, Chromium-based browsers switch to SwiftShader, a rasteriser that runs entirely on the CPU, and the renderer string says so outright: you will see "Google SwiftShader", or SwiftShader named inside the usual ANGLE wrapper in newer builds. On Linux with Mesa the equivalent is llvmpipe, and its name appears in the string the same way. The fuller picture comes from the browser's own diagnostic pages — chrome://gpu in Chromium and about:support in Firefox list which features are running on hardware, which have dropped to software, and which are disabled outright.

A fallback matters because everything still draws: you get no error, only symptoms. Scrolling stutters on a heavy page, CPU use climbs during video playback, and a laptop fan that should be idle never quietens down. The usual causes are an old or blocklisted graphics driver, a virtual machine or remote-desktop session with no GPU passed through, and the browser's own "use hardware acceleration when available" setting having been turned off at some point. Updating the driver or restoring that setting normally puts the hardware path back.

WebGPU is the modern replacement for WebGL, designed around the way today's graphics hardware really works. It gives pages lower-level, more efficient access to the GPU and, crucially, adds general-purpose compute — the ability to run large parallel calculations, which is what makes in-browser machine learning and heavy simulations practical. For everyday sites the visible difference is subtle, but for demanding applications it is a big step up.

Support is now broad across up-to-date Chromium browsers and is arriving in Safari and Firefox, though it can still depend on your GPU and drivers. The Feature Support panel tests for both WebGL and WebGPU directly, so you can see at a glance which your setup can actually run today.

The vendor and renderer strings are not part of core WebGL. They come from a separate extension, WEBGL_debug_renderer_info, which exists apart precisely because the information is a fingerprinting risk. Browsers gate it differently: Chromium exposes it by default, Firefox restricts it and withholds it entirely in resist-fingerprinting mode, and Safari on Apple hardware returns a generic, non-identifying string rather than the exact chip. Where the extension is absent, querying the usual parameters yields only broad values of the "WebGL 1.0" kind, and there is simply nothing specific left to name the adapter with.

WebGPU approaches the same problem from a different angle. An adapter carries an info object with vendor, architecture, device and description fields, but the specification deliberately permits a browser to leave them empty or return coarse values, and in practice several of them arrive trimmed. The conclusion is the same as for WebGL: a blank GPU name is a privacy policy taking effect, not a malfunction, and an honest tool reports it as unavailable instead of substituting a plausible-sounding model.