Description
About GPU Information
Introduction
The DeviceHub GPU Information tool is a free online graphics capability probe that reads WebGL vendor and renderer strings when a context can be created, notes WebGPU API presence at a high level, and explains privacy-reduced or software-renderer outcomes such as Google SwiftShader, without claiming a full DirectX/Vulkan OEM control-panel dump or a guaranteed real GPU model name. Web developers diagnosing black screens, support teams collecting graphics environment rows, QA comparing Intel integrated versus discrete NVIDIA paths, educators teaching canvas fingerprinting ethics, and creators troubleshooting hardware acceleration all get a browser-visible answer with explicit honesty. DeviceHub states limits plainly: GPU strings via WebGL may be privacy-reduced, spoofed by enterprise policy, or replaced by software renderers; absence or generic labels are common and useful. This page does not flash firmware, does not change NVIDIA Control Panel settings, and does not replace WebGL Test or WebGPU Test for conformance-style drills. Pair with WebGL Test when extension lists and shader compiles matter. Pair with WebGPU Test when adapter requests and feature flags are the focus. Pair with Display Information and Display category tools such as HDR Test when the question is panel HDR or gamut rather than GPU GL strings. Pair with Device Information for hub context and CPU Information when worker limits sit beside GPU limits. Pair with Browser Features for a matrix row without creating a WebGL context on every visit. Remote desktop sessions frequently expose SwiftShader or llvmpipe-like strings, document session type before RMAing a laptop GPU. Headless CI browsers often lack real GPUs; expect software renderers in pipelines. Safari, Firefox, and Chrome differ in how aggressively they anonymize UNMASKED_RENDERER, capture the browser name beside every screenshot. ANGLE translation layers on Windows rewrite strings; what you see is the browser’s GL stack view, not always the marketing GPU name from Device Manager. Schools teaching privacy should highlight that DeviceHub shows reduced strings instead of fighting the browser to unmask users.
What this tool does
GPU Information attempts a lightweight WebGL context, queries DEBUG_RENDERER_INFO style vendor and renderer parameters when allowed, displays the resulting strings or a clear failure state, and summarizes whether WebGPU globals exist for further testing elsewhere. It does not download large glTF scenes, does not run FurMark-like stress, and does not force high-entropy fingerprint scripts beyond what is needed for the labeled diagnostic. Copy explains SwiftShader, blocked 3D, and reduced renderer policies in plain language. Failures distinguish context creation errors from empty extension support when possible. Permissions stay none, no mic or camera. Users are directed to WebGL Test for richer interactive probes and WebGPU Test for adapter enumeration flows that may involve different UI. Refresh after toggling hardware acceleration or updating GPU drivers. Notes remind you that identical machines can show different strings across browsers on purpose. The tool never “fills in” a GeForce model when the browser returns a generic placeholder. Discrete versus integrated GPU switching on laptops may change strings after preference toggles, retest after the OS GPU preference change and a full browser restart. Canvas fingerprint warnings in corporate policies may block the probe; unsupported or blocked states are valid outcomes to record.
When to use it
Use GPU Information after WebGL content fails to initialize, when comparing integrated versus discrete GPU browser paths, before blaming CSS for jank that is actually software GL, when remote desktop tickets show unexpected renderers, and when teaching privacy reduction of graphics strings. Prefer WebGL Test when you need extensions, shader precision, or draw smoke beyond vendor strings. Prefer WebGPU Test when the app under test is WebGPU-first. Prefer Display Information or HDR Test when the symptom is tone mapping or gamut on the panel, not GL renderer identity. Prefer Browser Features for a quick WebGL boolean without string extraction. Avoid treating SwiftShader as proof the physical GPU is dead, drivers, policy, or RDP may be forcing software GL. Avoid using a single anonymized string as a warranty GPU model. Run on the user’s machine locally during support, not on the agent desktop. Retest after clean driver installs and after disabling “Use graphics acceleration when available” experiments. Use in CI documentation to set expectations that headless Chrome reports software renderers.
How it works
WebGL exposes optionally unmasked vendor and renderer strings through the WEBGL_debug_renderer_info extension historically; modern browsers increasingly reduce, gate, or replace those strings to limit fingerprinting. Creating a canvas and getContext('webgl') or webgl2 is a privileged enough operation that some hardened profiles block it entirely. Software renderers appear when the browser cannot or will not use the GPU. WebGPU presence is detected via navigator.gpu style surfaces without necessarily requesting an adapter with high-entropy options, deeper adapter name reads belong in WebGPU Test with appropriate honesty. DeviceHub typed permissions remain none; WebGL does not use the Permissions API microphone category. Secure HTTPS is required for reliable modern graphics APIs on DeviceHub. Remote desktop, virtual machines, and GPU blacklists all alter outcomes independently of DeviceHub code quality. ANGLE, Metal, and Desktop GL backends change string formats across OSes. Privacy-sensitive deployments should treat renderer strings like other fingerprint material when pasting publicly. No DeviceHub server needs the GL string to render the page labels, values stay local unless you copy them out. Dual-GPU laptops may bind the browser to iGPU unless the OS per-app setting says otherwise, string changes after preference flips confirm that path.
Step-by-step instructions
- Open GPU Information over HTTPS on a local console session when possible, avoid assuming RDP strings match the laptop’s discrete GPU.
- Allow the page to create a WebGL context and read vendor/renderer output; wait for success or explicit failure messaging before screenshotting.
- If you see SwiftShader, llvmpipe, or generic reduced strings, note hardware acceleration settings, driver state, and remote-desktop use beside the result.
- Open WebGL Test when you need extension lists or draw confirmation beyond strings; open WebGPU Test when adapter features matter.
- Capture Browser Information or Browser Features rows for engine context that explains differing anonymization policies.
- Paste GPU strings into tickets labeled as browser-exposed WebGL view, not Device Manager marketing names, and avoid public posts if fingerprint risk matters.
Common problems
Expecting exact GeForce RTX model matches fails under privacy reduction. SwiftShader on RDP mistaken for dead hardware causes unnecessary RMAs. WebGL disabled in browser flags yields context failures blamed on DeviceHub. Comparing Safari reduced strings with Chrome unmasked strings on older builds creates false “inconsistency” bugs. Headless CI software GL is normal. Assuming WebGPU presence means WebGL strings must be discrete NVIDIA overreaches. Multiple GPUs with OS preference set to power saving keep browsers on iGPU, string looks “wrong” relative to gaming benchmarks. Corporate group policy blocking WebGL shows failures that are configuration, not site defects. Users reading ANGLE strings as non-NVIDIA incorrectly escalate vendor drivers, ANGLE is a translation layer. Canvas blockers and fingerprint extensions abort probes early, disable temporarily when isolating issues.
Privacy explanation
WebGL renderer strings are classic fingerprinting surfaces. DeviceHub shows them for diagnostics you initiate and does not upload GPU profiles for advertising when you view the page. Permissions stay none. Prefer WebGL Test only when needed so casual browsing does not always create contexts. Closing the tab drops the context. Treat screenshots of full renderer strings as sensitive in threat models that care about device fingerprinting. Privacy-reduced placeholders are desirable for users, do not seek browser exploits to unmask. Shared lab PCs should clear the screen after GPU demos if shoulder surfing of hardware details is a concern.