FPS: delivery rate
How many frames the browser delivers per second. Display refresh, the browser, and CPU work can all limit this number.
GPU WORKLOAD LIBRARY
Find the right workload. See how your browser handles it.
Explore 15 graphics and compute workloads, each with its own live scene, adjustable settings, and readable results. Start small, then choose the path you want to investigate.
Workload illustration
An easy first look: watch a ray-marched scene while the tool records frame delivery. Begin with the 15-second quick check; increase the load only when you are comfortable.
Try the volume shader01 / WORKLOAD SELECTOR
Choose by what you want to explore. Every card opens a dedicated tool—not a test running in the background.
Explore the work behind pixels, light, and multi-pass effects.
Trace rays through a mathematical volume; control detail and sampling steps.
Repeat pixel shader calculations to vary arithmetic cost.
Trace a small procedural scene in a shader; no hardware ray-tracing claim.
Apply image effects through repeated render passes.
Increase shader lighting and shadow sampling work.
Explore triangles, repeated objects, and busy particle scenes.
Submit triangles and observe browser rendering throughput.
Draw repeated objects with shared geometry and per-instance transforms.
Render many moving points; vary particle count and pixel load.
Explore sampling, uploads, and a bounded readback check.
Sample generated textures within the selected allocation budget.
Write known texture patterns and compare sampled readback values. This does not test all physical VRAM.
Transfer generated pixel data into textures during the run.
Separate GPU compute from a mixed CPU/GPU simulation.
Simulate gravity and collisions on the CPU, then draw particles on the GPU. This measures a mixed workload.
Run a WebGPU compute kernel and inspect its returned values and timing.
Use your own local video or explore an editable shader.
Observe frame delivery from a video selected on this device. The file is not uploaded; this does not prove hardware decoding.
Edit a local shader experiment. Results are separate from standard benchmarks.
02 / Before you begin
Choose a workload that matches your question. Use the quick check and a low preset for your first run.
Adjust resolution or load—not everything at once. Keep this tab visible and pause other demanding tasks.
Look at frame timing across the run, then repeat with matching settings. One number is not a hardware diagnosis.
03 / READ THE SIGNALS
How many frames the browser delivers per second. Display refresh, the browser, and CPU work can all limit this number.
The interval between frames. Spikes reveal uneven delivery that an average FPS can hide; they are not GPU-only timings.
Compares earlier and later parts of one run. A drop calls for a repeat—not an automatic diagnosis of overheating.
Use the standard GPU benchmark. Locked settings make matching runs easier to compare than an adjustable stress test.
04 / GPU Tests
A stress test lets you vary the load and observe behavior over time. A standard benchmark fixes settings for repeatable comparisons. Compare only the same workload, version, API, settings, and timing method.
No. Browser APIs do not expose GPU temperature, power, or total physical VRAM here. The texture check compares sampled readback values within its allocation budget; it is not a complete memory or hardware-health test.
No. A heavy workload, refresh limits, CPU work, power settings, background tasks, or browser scheduling can lower FPS. Repeat a matching run and check hardware acceleration before drawing conclusions.
No. Runs and reports stay in this browser by default, and selected video files are not uploaded. Public result sharing is optional and requires explicit consent; read the privacy policy before publishing.