Memory & budgets
What consumes GPU and system memory, what the pressure badges mean, and what gets freed when memory runs low.
Real-time playback keeps a large amount of data resident on the graphics card and in system RAM.
What uses memory
Textures and raster images dominate most projects. Every loaded image, every rasterised layer, every impostor and every render output lives on the GPU, and resolution multiplies fast.
After those:
A Volume is a 3D grid, so doubling its resolution multiplies its memory by eight. Volumes and Distance Fields are among the heaviest things you can make.
Millions of points, dense geometry and Gaussian splats all take real space.
A running simulation holds its working state on the GPU for as long as it plays.
Video and audio from imported media are decoded into memory as they play.
Allocations are counted against a budget by category. On the GPU those are Textures, Shape Buffers, SDF Fields, Volumes, Meshes, Output Pool, Simulation, G-Buffer, Splats and Compute Buffers; in system memory they are Video Frames, Image Assets, Audio Buffers, Geometry Buffers, Scratch and External.
There is a third tier on the desktop. Your drive holds the durable cook-output cache, which is where a baked result and a decoded image level are kept between sessions, and the compiled-shader cache. The two are budgeted and reported together as one Disk figure.
Resolution is the biggest single lever. Before optimising anything cleverer, drop a Volume's grid resolution or a render's output size. The saving is often invisible in the final look.
Budgets and the pressure badges
Neither budget is set by hand, and neither is read from the hardware.
The GPU budget is an estimate. It comes from the largest buffer the graphics driver says it can allocate, adjusted by a table of known GPU families: on Apple Silicon it is half of system RAM, on Intel integrated graphics a quarter, and on a discrete card a fraction of the reported buffer ceiling or a figure looked up from the card's name. A card the table does not recognise falls back to 2 GB. The system memory budget is a quarter of installed RAM, measured from the machine rather than assumed, and never less than 256 MB. The disk budget is fixed: 8 GB for the cook-output cache plus 256 MB for the shader cache.
The Performance panel shows live usage with a pressure badge for how full things are overall:
Normal: headroom available.
Warning, past 80% full: data that can be rebuilt, such as cached results, is cleared to make room.
Critical, past 95% full: eviction becomes aggressive.
A badge ticking into Warning during normal work is expected. A badge sitting at Critical is the cue to lighten the graph.
What happens under pressure
Space is freed in this order:
Caches that own their data are asked to shed first: decoded images, splats, 3D models, video frames, audio and machine-learning results. This is the step that hands real RAM back, because each cache drops its own copy rather than just forgetting a number.
In system memory, the least-recently-used items in the category under pressure go next, then other categories if that was not enough.
On the GPU there is no category order. The globally coldest entry goes first, and anything still referenced by a live result is skipped. Warning frees around a quarter of the budget, Critical around three quarters.
On the desktop, the disk caches prune last. A cook-output blob or a compiled shader is only ever a recompute, so losing one costs time and nothing else.
Operating-system low-memory signals drive all four steps. When the machine warns, caches are shed to three quarters of their budgets; when it reports critical, to half.
An export that cannot get the memory it asks for sheds every tier to half and retries once. If the second attempt also fails it reports an out-of-memory error rather than failing mid-render. A GPU allocation over budget with nothing cold to evict is allowed through with a warning in the log, so the GPU budget is a target rather than a hard ceiling.
Everything evicted can be rebuilt: cached cooks, recycled render targets, parsed files. Project data is never discarded. The visible cost is a re-cook the next time you touch an evicted result.
The Web Player runs in a browser tab and cannot see operating-system low-memory signals, so it does not shed caches ahead of time the way the desktop app does. It has no disk tier at all: nothing is cached between page loads, so every shader compiles again on every visit. Its budgets are fixed rather than measured: 1 GB of system memory, and a GPU budget taken from what the browser says the device will allocate, floored at 256 MB and capped under 2 GB whatever the machine has. Keep web exports to modest resolutions and collection sizes.
Reducing the footprint
If a badge is pinned at Critical or you are hitting out-of-memory errors:
Lower Volume and Distance Field resolutions first.
Reduce render output size, or the resolution of rasterised and impostor layers.
Thin out heavy collections with fewer points or decimated geometry.
Bypass branches you are not actively looking at, so their results stop being refreshed and can age out of the cache.