How the texture test works

The workload, step by step

When you start a run, the tool requests a WebGL2 context, creates a shader program and uploads a fixed set of generated textures. Each texture uses four 8-bit channels: red, green, blue and alpha. The color data varies by position and texture slot, so the preview is produced from the selected textures rather than a prerecorded video.

For each animation callback, the fragment shader samples every selected texture at moving coordinates, combines the colors with different weights, and draws two triangles covering a 640 × 360 canvas. Linear filtering interpolates texels; nearest filtering selects the closest texel. Texture count and texture size are independent settings.

Textures are uploaded once at the start. The per-frame counter records texture bindings, not new uploads or physical memory transfers. The tool does not use readPixels to read the texture data back and does not compare an expected byte pattern with a returned pattern. Consequently, there is no memory-error counter.

Calculate the texture data size

The estimate is texture count × width × height × 4 bytes ÷ 1,048,576. Four 1024 × 1024 RGBA8 textures contain 16 MiB of base-level pixel data. Sixteen 2048 × 2048 textures contain 256 MiB. Doubling both dimensions multiplies the data size by four; doubling texture count doubles it.

The estimate excludes browser copies, shader resources, framebuffers, driver overhead and alignment. No mipmaps are generated in this workload. The driver decides how resources are placed. A successful upload does not prove that this amount is dedicated physical VRAM or that more memory is unavailable.

What the timing measures

Frames are counted in requestAnimationFrame callbacks and grouped into approximately one-second samples. Frame time is the interval between callbacks. This includes browser scheduling and JavaScript work; it is not an isolated GPU execution time or a memory-bandwidth measurement.

Average FPS in the report averages the one-second samples. Minimum, maximum and low-percentile values are also calculated from those samples, not from the slowest individual frames. Frame-time statistics use the most recent 600 intervals. Read short runs cautiously: stopping before the first sample can leave FPS statistics at zero.

Frame consistency is a descriptive index calculated as 100 ÷ (1 + standard deviation of the retained frame intervals ÷ their mean). Constant intervals produce 100%; more variation lowers it. The optional performance score averages this index with average FPS normalized to a 60 FPS target and capped at 100. It is a site-specific heuristic, not a hardware-health score or an industry benchmark.

Make a comparison you can repeat

Use the same device, browser, display, canvas workload, texture count, dimensions, filtering and duration. Record whether the device is plugged in and whether another graphics application is open. Keep the tab visible throughout the run. Change only one setting when investigating an effect.

For example, compare four 1024-pixel textures with four 2048-pixel textures while leaving filtering and duration unchanged. If FPS drops, you have observed a change under that workload. You have not identified a defective memory chip or measured maximum memory capacity. Repeat both settings to see whether the difference survives normal run-to-run variation.

What to use for memory integrity

A memory-integrity test must verify data, which is a different task from rendering textured triangles. Native tools such as memtest_vulkan describe the patterns and verification they perform. Follow the tool’s own documentation and record the tested amount, duration and errors.

A native test can still be affected by drivers, shared memory, system instability and inaccessible reserved memory. Use it together with the symptoms you are investigating, rather than treating any single clean run as a guarantee.