Volume Shader Stress Test: Spotting GPU Thermal Throttling
Observe sustained WebGL performance with a repeatable run log. Learn why falling FPS alone cannot diagnose thermal throttling and what browser metrics actually measure.
Running the same shader for longer can reveal whether browser rendering performance changes during sustained load. It can help you decide what to investigate next, but an FPS decline alone cannot diagnose GPU thermal throttling.
What this tool actually offers
The current Volume Shader BM Test has one default WebGL workload at a fixed 1024 × 1024 drawing-buffer size. There is no separate Stress preset, automatic duration selector, temperature sensor, clock-speed monitor, or FPS history chart. You can start the default workload, observe it for a chosen active duration, and pause it manually.
The numeric panel reports FPS, frame time, active running time, and rendered frames. CSV and JSON downloads save a result snapshot. They do not contain a temperature trace or a frame-by-frame history.
A repeatable sustained-run procedure
- Put the device on a hard surface with clear airflow and use its normal, stable settings.
- Close competing workloads and record the browser version and power state.
- Restore the default shader and leave its camera unchanged.
- Start the test and keep its tab visible. Choose a duration you can repeat consistently.
- Note the live current FPS at fixed intervals using your own run log.
- Pause, then save the final result and environment information.
- Let the device return to comparable starting conditions before repeating.
Do not change the shader between readings. Different camera positions and custom shader code can change the work each frame performs. A comparison made after changing them cannot isolate sustained-load behavior.
How to read a change over time
| Observation | Possible explanations | Useful next step |
|---|---|---|
| Rate stays near the browser refresh ceiling | Animation scheduling limit or enough rendering capacity | Compare browser timing with the refresh-rate tool |
| Current FPS falls after the start | Temperature, power limits, or competing load | Check OS-level monitoring and repeat with controlled conditions |
| Sudden changes | Background tasks, browser scheduling, driver behavior | Record a browser profile or inspect system activity |
| Visual artifacts or context loss | Driver, shader, device, or browser issue | Stop the test and restore the default shader |
The same observed pattern can have different causes. Stable FPS does not establish a safe temperature, and falling FPS does not prove a cooling fault. A browser may also suspend or reduce animation work in the background; this benchmark pauses when the tab becomes hidden.
Confirming a thermal explanation
To investigate temperature specifically, use the device manufacturer's guidance and a suitable system-monitoring tool alongside a controlled run. This website cannot read GPU temperature, fan speed, voltage, or clock speed through ordinary WebGL.
Compare measurements before and after changing one condition, such as clearing blocked airflow. Avoid assigning universal percentage-drop thresholds: devices differ in power budgets, cooling design, browser behavior, and starting temperature.
Limits of stability testing
Completing one shader workload does not certify an overclock, undervolt, or GPU as stable. Other applications exercise different instructions, memory patterns, and APIs. A browser benchmark is one observation in a wider validation process, not a replacement for native diagnostics or vendor support.
Pause if the device becomes unusually hot, shows artifacts, or behaves abnormally. For a short baseline, use the run guide; for environment checks, open the WebGL capability report.