So far, that kind of memory pressure hasn't really exerted itself in the consumer space. Running any modern triple-A game title at 1600 x 1200 with a high amount of samples for anti-aliasing - at least four Z samples say, which is around 30MB of AA sample data to store, per frame, if you don't mask off what you don't need to sample - with a high degree of anisotropic texture filtering is possible at very interactive frame rates with the current class of high-end hardware. You're more shader-limited than anything these days, with memory pressure at even that resolution with those settings not enough to tax a 256MB board.

The only way that's going to happen, unless people start playing games at larger resolutions with the same settings, is if the quality, size and number of in-game art assets increases fairly significantly. Even assuming large re-use of texture data from a GPU's texture cache, there's still very easy scope for a game to need more than the current amount of frame buffer space, per frame. The issue today is that games developers aren't loading up the hardware with everything they possibly can, because 128MB is the most common memory configuration in consumer graphics today. But what if they did, and is it starting to happen?

Consumer need

Programmable graphics processors like ATI's R4-series and Nvidia's GeForce 6-series have given developers and 3D graphics researchers the power and capability to come up with innovative new ways to construct a 3D scene, especially in terms of lighting and shadowing, in real-time with interactive frame rates. There are numerous papers on the web that discuss things like real-time radiosity, real-time global illumination (or decent approximations of it at least), shadow mapping, shadowing using spherical harmonics, shadowing using precomputed radiance transfer (PRT), which all require not only significants amounts of high-quality artist-generated data to look good, but all manner of intermediate data storage while you're building the frame to display.

Take perspective shadow mapping, a technique that's gaining favour in many new game engines, which may be combined simultaneously per frame in a game engine to light the world. You're creating new shadow map data for every frame displayed. It's not a usually a fixed workload per frame, so it can't easily be optimised. To understand that, think about why you'd calculate the light contribution for a frame for a light source that's fully occluded by both objects in the scene (it's blocked by a wall, say) and the viewing perspective (you can't physically see the light anyway so it's contribution to the frame's lighting is lessened). You only really want to use large resolution shadow maps for large area lights, such as the sun, with smaller maps useful for point or directional lights.