Video memory mysteries
Originally published 2002 in Atomic: Maximum Power Computing Last modified 03-Dec-2011.
Video cards with 64Mb of memory on them are common items these days. 64Mb of very speedy Double Data Rate memory, even. The (relatively) cheap GeForce4 MX 440 uses DDR memory with a doubled 200MHz default clock speed; that's the same speed as the memory on the GeForce2 Pro and the GeForce3 Ti200.
Current high end cards - your top-flight Radeons, your full GeForce4s - have 128Mb of memory.
Which raises the question - why?
Do you need that much?
Working out how much memory a given display mode needs for 2D video purposes is easy. Screen width in pixels times screen height in pixels times bits of colour data per pixel equals bits in the frame buffer - the block of memory that the graphics card feeds to its digital-to-analogue hardware to create the monitor image (or which the graphics card just massages into a digital data stream, if you're one of those yuppies with digital DVI screens).
If you're running your PC in 1600 by 1200 resolution, with 32 bit colour, then that's a total of 61,440,000 bits for the whole display. Which is 7,680,000 bytes, which is 7,500 kilobytes, which is about 7.32 megabytes. It's not 7.5 megabytes, because there are 1024 bytes in a kilobyte and 1024 kilobytes in a megabyte. This is something that marketing people conveniently forget when they're telling you how big hard drives are. But I digress.
If you're using "double buffering" (more informatively referred to as page flipping) - and, today, you almost certainly are - then that doubles this memory requirement. Double buffering renders the upcoming frame into another area of memory from the frame buffer, so the incoming data doesn't affect the currently-displayed frame.
Even at 1600 by 1200, though, 16Mb is still plenty for double buffered 2D video. Heck, it's enough for triple buffering, if you drop your resolution to 1280 by 960.
Full Scene Anti-Aliasing (FSAA) can eat a lot more memory. Basically, all flavours of FSAA render more pixels than they have to, and then average them out to give a final image with smoother diagonal edges. Jaggy diagonals look bad enough in still frames; they look even worse when there's animation going on, causing the stair-steps to "crawl" up and down the lines.
FSAA doesn't change the amount of memory needed for the final display buffer or its double- or triple-buffered cousins, but it adds yet another buffer, for the intermediate higher resolution data, that's two or four times as big as any of the others.
But, assuming 2X FSAA and double buffering, we still haven't used up all of the memory on a humble 32Mb video card.
All of the rest of the modern graphics card memory budget is taken up by 3D data.
Some of the 3D data is the Z-buffer and stencil buffer. The Z-buffer is used to determine what's in front of what in the rendered scene; the stencil buffer is another piece of unnecessary-pixel-rendering-avoidance technology. Current chipsets are able to make these buffers much smaller than the final display buffer.
Depending on your video card and the... software... (coughgamecough) you're running, you may also be using a significant amount of the card's memory for vertex data - low-level rendering information for objects in the game world - and related purposes. Modern video cards with lots of hardware rendering capability can handle all sorts of serious rendering tasks that'd otherwise fall to the CPU; it doesn't take a ton of memory to do them, but it takes some, and the card always uses some of its memory as scratch space anyway.
A quicker and dirtier strategy, which works on dumber cards, is to dump lots of pre-calculated vertex data in the card's memory so it can just display the correct pre-calculated version of an object for each frame, without having to calculate anything itself. That takes more RAM.
The real RAM hogs, though, are textures and their relatives - light maps, bump maps, and so on. All of the stuff that goes on the surfaces of objects so they don't have the construction-paper-model look of relatively-old-school 3D games (objects in truly old-school 3D games, of course, have no surfaces at all).
The amount of memory textures take up varies massively, depending on how many textures are actually needed at once, and what resolution they are, and what colour depth they are (they don't have to have the same bit depth as the final display), and whether they're compressed or not in the card's memory. You can change all of this stuff, and so there are umpteen possible texture memory loads for any given game.
If you blow your memory budget - use up more video RAM than your graphics card has - AGP graphics cards can use "AGP texturing" - allowing system memory to be used for textures and accessed quickly, over the AGP bus.
Unfortunately, AGP isn't actually fast enough to make this practical. AGP 4X is the fastest AGP flavour in common use as I write this; it has a peak bandwidth of about one gigabyte of data per second. The DDR memory on a GeForce4 MX 440 moves six gigabytes per second.
AGP 8X, which is just trickling onto the market now, doesn't make a big difference to this. AGP texturing is always going to suck compared with on-card texture memory.
It's possible to use more than 64Mb of video memory, with current software. FSAA in high resolutions, along with a decent slab of high detail textures, can push up the RAM usage enough to do it.
But since most 21 inch monitors don't have enough phosphor dots to clearly display 1600 by 1200 in the first place, and smaller screens are even worse, adding FSAA at those resolutions doesn't make much of a difference. People do it, but there's not much reason to.
Similarly, pro 3D rendering software can make use of a ton of video memory if you're previewing your troupe of hairy spiders all mapped with different high-res Old Masters and all juggling shiny teapots mapped with different high-res Belgian whoopee cushion erotica. That scene will rotate faster in your preview window if you've got more space for textures on the video card.
For most people, though, 64Mb is still plenty.
As I write this towards the end of 2002, some current games have enough texture detail to break a 64Mb budget even without FSAA, if you crank all of the quality sliders to max. Games are written for the most popular hardware, not for the most powerful hardware, though. So you still won't find anything that won't run fine on a 64Mb card; worst case scenario, you'll just have to reduce the texture detail one or two notches from the maximum setting.
If you're not doing some odd pro-3D job that involves tons of vast textures, and you don't have a display that'll let you see the difference between FSAA and non-FSAA in Extreme Resolution, then staying under 64Mb is easy, and will stay that way for a while yet.
