GPU memory / VRAM
The GPU's limited workspace for textures, geometry, shadows, and render targets. Large images and high resolution fill it fast.
See it
What it is
GPU memory, often called VRAM, holds the resources the graphics processor needs close at hand: texture pixels, vertex and index buffers, shadow maps, depth buffers, and post-processing render targets. A single uncompressed 4096 by 4096 RGBA8 texture is about 64MB before mipmaps, regardless of whether its downloaded PNG was only a few megabytes. Run out and the browser can drop the drawing context entirely and fire webglcontextlost, which the user reads as the tab dying.
Watch the budget when a scene uses many large textures, several shadow casting lights, high device pixel ratio, or a chain of fullscreen passes. KTX2 texture compression, smaller maps, shared geometry and materials, fewer render targets, and deliberate disposal are the main levers. Browsers do not expose a dependable cross-device byte count, so estimate from resource formats and test on low-memory hardware.
Gotcha: dropping a JavaScript reference does not immediately release the GPU allocation. In three.js, call dispose() on textures, geometries, materials, and WebGLRenderTargets when they leave the scene. renderer.info.memory reports object counts rather than exact bytes, but a count that keeps climbing after scene changes is still a useful leak signal.
Ask AI for it
Audit and reduce GPU memory in this three.js scene. Convert color maps to KTX2 with Basis Universal, cap textures at 2048px unless a measured close-up needs more, reuse geometries and materials, and remove unused WebGLRenderTargets. On teardown, call dispose() on every Texture, BufferGeometry, Material, and WebGLRenderTarget, then track renderer.info.memory.textures and geometries across ten scene swaps.