Volume Shader BM Test — Methodology
How the benchmark works under the hood — modes, metrics, accuracy limits, and what this test is not.
Volume Shader BM Test is a small, transparent benchmark. This page describes exactly what it measures, the four test modes, the metrics in the result panel, and the cases where the number you see is not a fair comparison.
1. The rendering stack
The test runs entirely in WebGL 2.0 through a single fragment shader. There are no native plugins, no helper extensions, and no off-screen workers. A vertex shader draws a single full-screen triangle; the fragment shader does all the work for every pixel on screen.
2. What the shader does — raymarching with SDFs
Instead of rasterizing polygons, the fragment shader uses raymarching with Signed Distance Fields (SDFs). For every pixel, the GPU casts a virtual ray from the camera and marches it forward in discrete steps until it either hits a surface defined by the SDF or exits the scene. Each step evaluates the full distance field — a large block of math that exercises the shader cores hard.
This is the same technique we go into deeply in our WebGL 2.0 raymarching deep dive.
3. Test modes
Four modes are available. They are not just resolution scales — each runs a different shader workload, which is why their scores cannot be compared directly:
- Light — fewer steps, lower resolution. Designed so even modest mobile GPUs can run it at usable FPS for a baseline.
- Medium — moderate iteration count, native canvas resolution. Roughly mirrors a "normal" demanding shader workload.
- Heavy — 1,000+ shader iterations per pixel. Where most desktop GPUs land in the 30–60 FPS range.
- Extreme — pushed to the point where high-end discrete GPUs start to drop frames. Useful for ranking the top tier; not for casual comparison.
4. Metrics
- Average FPS — frames per second across the full run, ignoring the very first second (see §6).
- Min / Max FPS — the worst and best 1-second window during the run.
- Frame time — milliseconds per frame. 60 FPS ≈ 16.7 ms; 30 FPS ≈ 33.3 ms.
- Stability — how consistent the frame time is during the run. A high stability number means your GPU sustained performance; a low one means it throttled, was preempted, or competed for resources.
The FPS result guide explains how to read these tiers in everyday terms.
5. Test modes can't be compared directly
Each mode has a different inner loop budget. A 45 FPS Light score and a 45 FPS Heavy score do not describe the same GPU work. When comparing two devices, always run the same mode on both, ideally with the same browser.
6. The first run is noisy on purpose
The first time the page loads, the browser compiles GLSL into a driver-specific binary. On some drivers this takes hundreds of milliseconds and shows up as a stutter at the start of the run. Discard the first result and use the second. For comparing devices, run twice on each.
7. Mobile results are affected by more than the GPU
Phone benchmarks are dominated by thermal headroom and OS power policy as much as raw GPU silicon. Battery saver / low-power mode, screen brightness, case material and even how the device is held will all change the score. For fair phone comparisons, plug in, disable battery saver, and prefer stability over peak FPS. See the phone GPU test guide for details.
8. What this test is not
Volume Shader BM Test measures shader ALU throughput on a synthetic workload. It is excellent for catching whether a browser, driver or device has lost a chunk of GPU compute. It is not:
- A substitute for a native benchmark like 3DMark, Geekbench GPU or GFXBench.
- A predictor of game FPS — games are dominated by draw calls and texture bandwidth, not shader ALU.
- A measure of memory bandwidth, ray tracing performance or video decode.
9. Privacy
All rendering, FPS counting and result aggregation happen locally in your browser. We don't collect hardware fingerprints, GPU IDs or results. We use standard analytics and ad services that may set cookies, but no benchmark data leaves your device.
