the GPU named by the renderer string can actually render
Check id webgl-performance-caveat-vs-renderer
What an ordinary browser yields
A no-caveat context granted, or refused by a build whose renderer string names the software rasteriser doing the work. N/A when WebGL is absent or the renderer string is unreadable (severity: warn).
What a detector infers
getContext("webgl", {failIfMajorPerformanceCaveat: true}) asks Chromium for a context only if it can supply one without a major performance caveat. On a software rasteriser - SwiftShader, llvmpipe, a GPU-less VM - it returns null. That is the engine reporting on its own graphics stack, one layer below anything page script can assign, and it costs a 2x2 canvas to ask. IT IS A COHERENCE ROW, NOT A SOFTWARE-RENDERING ROW, and the distinction is the whole design. Rendering in software is ordinary and is never a finding here: a blocklisted driver, a virtual machine and a remote desktop session all do it, and an honest fallback SAYS SO - Chromium rewrites the renderer string to name SwiftShader. What cannot be true is a renderer string naming real silicon while the engine refuses to render without a caveat. Both halves come from the same browser, so no reference data is involved and there is nothing to go stale. WHY IT EARNS A PLACE BESIDE hardware.ts, which already infers software rendering: that module measures THROUGHPUT, and its own comment concedes the figure varies several-fold on one fixed GPU, which is why its discrete tiers are deliberately never written to the corpus. This is a boolean the engine answers directly - no benchmark, no timing variance, no threshold to tune. Two instruments for one question, and the cheap one has no error bars. PROVENANCE: taken from a commercial fingerprinting collector measured using failIfMajorPerformanceCaveat, a probe this suite had no equivalent of.
How to resolve it
If the renderer string is being substituted, substitute it for something the graphics stack can back. A machine rendering through SwiftShader while reporting a discrete GPU is contradicted by the engine's own refusal, and no page-level override reaches that answer because the refusal happens before a context exists. Running with real GPU access resolves it; so does reporting the software renderer honestly, since a build that admits it renders in software is not contradicting itself and this row does not flag it.
Nearby checks in Render & GPU
- SVG's screen matrix agrees with the element's client rect
svg-ctm-vs-client-rectTwo independent routes to a single fact. getScreenCTM maps an SVG element's user space into viewport coordinates, and getBoundingClientRect… - IntersectionObserver's rect agrees with getBoundingClientRect
client-rect-vs-observerA third account of where one element sits, from the most ordinary API that has one. - WebGPU's build constants are identical in every realm
webgpu-sync-surface-vs-realmWebGPU's cheapest fingerprint is not the GPU at all. navigator.gpu.getPreferredCanvasFormat() and navigator.gpu.wgslLanguageFeatures are… - the GL limits the driver reports are limits the driver will actually honour
webgl-limits-vs-driverEvery other WebGL check on this page reads what getParameter SAYS. - ANGLE's translated shader is written in the dialect the renderer string implies
shader-backend-vs-rendererThe UNMASKED_RENDERER_WEBGL string is a label — a piece of text a page can rewrite to name any GPU and any graphics backend. - every extension WebGL advertises can actually be instantiated
webgl-extensions-vs-drivergetSupportedExtensions() returns a list a page can rewrite; getExtension(name) either hands back a real extension object or null, and that… - the clear path and the shader path paint opaque red to the same bytes
webgl-draw-path-invarianceOpaque red can be produced two ways: the fixed-function clear path, and a fragment shader emitting vec4(1,0,0,1). - a mediump claim of fp32 precision is delivered by the arithmetic
shader-mediump-claim-vs-arithmeticgetShaderPrecisionFormat is a claim about float precision; a shader that computes a value only fp32 can represent is the GPU keeping or…
Clearcote is a browser built for fingerprint coherence
It is a Chromium fork, maintained by the same people who wrote this reference. It ships as a compiled browser rather than as a stealth script injected into someone else's — which is a description of how it is built, and is not an argument about how it behaves on this check.
This audit takes no position on how Clearcote scores on Render & GPU checks, on this one, or anywhere else. It has no baseline corpus of other people's fingerprints to rank you against and no vendor scoreboard — nearly every check is self-referential, asking one browser the same question through two independent APIs and reporting whether both answers can be true at once. It runs identically on any browser, including ours. Run it on yours and read the result yourself.
See the other checks in Render & GPU — the family webgl-performance-caveat-vs-renderer belongs to.