Graphics Memory Sizes Compared: How Much Is Enough?

EconolineCrush writes "Trying to decide between whether or not to get a 64MB graphics card, or spring for that 128MB version? Hit up this article, which explores the performance of ATI and NVIDIA-based cards with 64 and 128MB of memory, before swiping your credit card. Not so long ago 32MB was the top end for graphics memory on consumer video cards, but now even budget cards are available with 128MB. 128MB might seem excessive now, but a year from now 64MB cards might just be obsolete."

Comments

removable RAM?

[littlerubberfeet]

this might be offtopic, but why can't the RAM on graphics cards be modular, like the stuff we stick in computers? Is it a card manufacture conspiracy? a different type of RAM? I would be willing to buy a high end Graphics card if I could eventually stick 256, or 384 MB on the card.

Re:removable RAM?

[Anonymous Coward]

Ram used to be Module based, see cards such as the Matrox Millenium and some Trident cards, however memory was hard to find and match, since each company uses there own type and speed.

Re:removable RAM?

[Milican]

By soldering the RAM directly to the board there is a better connection which allows them to run the chips faster. If you add a connector then you add a capacitive load and thus you have to slow down the memory. Thats not to say modular RAM could not be incorporated down the line, but for the latest and greatest its better and cheaper to solder the stuff right on the PCB (printed circuit board).

JOhn

Re:removable RAM?

[hike2]

In the case of NVIDIA the "value-added resellers" add their own high-speed memory as in the case of Leadtek. If they were to make the memory modular they could not charge and extra 50-100 bucks over the comptetition just so that you can gloat at your extra .5% gain over you buddies exact chipset.

Um, What About Virtual Texturing?

[Anonymous Coward]

("Virtualized Texture Memory" is prolly a more instinctive nomer.)

3DLabs/Creative's new P10 uses this. It makes the on-card video memory just a cache for streaming textures: so you get unlimited texture sizes, even with just 64MB (the proposed minimum) of video memory... Or limited by your system RAM, actually. I'm not sure if you can apply the same to geometry and colorbuffer data -- could be.

This is totally unlike "AGP texturing", mind you!

Re:What are you doing with it?

[andycat]

At work the two machines I use regularly for interactive walkthroughs of large environments (10-100 million triangles) have 64MB and 128MB of texture memory, respectively. I am constantly running up against the 64MB limit and I'm fast approaching the 128MB one. Here's how it breaks down:

Frame, depth, and stencil buffer: 1024x1024x(32 bits + 32 bits + 8 bits) = 9 megabytes

9 megabytes so far. No problem. Double that when I push the resolution up to 1600x1200 for demos, but we'll ignore that for the moment. Now, the model I'm using has 19MB of surface texture, so we're up to 28MB. The system I'm running on this poor hypothetical card uses 512x512 textures to replace distant geometry. Each one takes up 768K of memory and I've generally got a working set of between 40 and 60 textures. There's another 30-45MB, so total usage is somewhere between 58 and 73MB. Add in shadow maps and we lose another 20 or 30MB. The 64MB card is now swapping to AGP memory. The 128MB card is filling fast. It's adequate for the current generation of the system I'm running, but before I can write the next couple versions I'm going to have to implement some serious resident-texture-set cache management.

Now, you can certainly argue that this is an atypical application. You would be quite correct. However, I do need that much video memory and I do use it. Yes, it's massive overkill if you want to play Quake, Unreal, whatever, but once you start looking into more exotic applications it's easy to get into situations where you can use arbitrary amounts of texture RAM. Real-time shading can get you there in a hurry, too, once you start using textures as lookup tables for expensive-to-compute functions (e.g. light fields or factorized BRDFs) or caching the framebuffer for later re-use.

So yes, 90% of the programs 90% of users will run will currently fit neatly in 64MB of video memory, but there definitely exist systems that require more than that.

Tim Sweeney endorses texture caching.

[Vegan Pagan]

Here's what Tim Sweeney says about texture caching:

"This is something Carmack and I have been pushing 3D card makers to implement for a very long time. Basically it enables us to use far more textures than we currently can. You won't see immediate improvements with current games, because games always avoid using more textures than fit in video memory, otherwise you get into texture swapping and performance becomes totally unacceptable. Virtual texturing makes swapping performance acceptable, because only the blocks texels that are actually rendered are transferred to video memory, on demand.

Then video memory starts to look like a cache, and you can get away with less of it - typically you only need enough to hold the frame buffer, back buffer, and the blocks of texels that are rendered in the current scene, as opposed to all the textures in memory. So this should let IHV's include less video RAM without losing performance, and therefore faster RAM at less cost.

This does for rendering what virtual memory did for operating systems: it eliminates the hardcoded limitation on RAM (from the application's point of view.)"