Slashdot Mirror
Shared Video Memory and Memory Bandiwidth Issues?
klystron2 asks: "Does shared video memory consume a huge amount of memory bandwidth? We all seem to know that a notebook computer with shared video/main memory will have performance drawbacks.... But what exactly are they? It's easy to see that the amount of main memory decreases a little bit, but that shouldn't make a big difference if you have 1GB of RAM. Does the video card trace through memory every time the screen is refreshed? Therefore consuming a ton of memory bandwidth? If this is the case then the higher the resolution and the higher the refresh rate, the lower the performance of the system, right? I have searched the Internet for an explanation on shared memory and have come up empty. Can anyone explain this?"
Does the video card trace through memory every time the screen is refreshed? Therefore consuming a ton of memory bandwidth? If this is the case then the higher the resolution and the higher the refresh rate, the lower the performance of the system, right?
Yes. The pixels on the screen are read out every single frame time (i.e., 60 to 75 times each second). The DAC (Digital to Analog Convertor) must be fed the pixel data every time -- with video in main RAM, there is no other place to store this image data because the main memory is this buffer. The product of the frame rate, resolution, and color depth tells you how much bandwidth is consumed.
The exact performance impact is not easy to predict though. Where it gets tricky is with CPUs that have large L1, L2, and L3 caches. It is possible for the CPU to be running at 100% while the video is being read if the CPU is finding all the data and instructions in the cache. But if the CPU must access main RAM, then there will be competition.
Two wrongs don't make a right, but three lefts do.
But seriously, you may want to take a look at this Tom's Hardware article detailing the weaknesses of an integrated chip.
For those looking for the quick answer, I'll do my best to summarize. First off, since integrated graphics tend to be low cost solutions, transistor counts are nowhere near current add-in boards. From the article, Nvidia's FX5200 has 47 million transistors (FX5600=80 million and FX5900=130 million), while their onboard solution (equivalent to GeForce4 MX440) has only 27 million.
Then, there's the question of memory bandwidth. Dual channel DDR 400 has a peak of 6.4GB/s, which is shared, while an equivalent GeForce4 MX440 would have a dedicated 8GB/s.
Now, to your question. Does this consume a ton of bandwidth and affect performance? Well, that would all depend on what you're doing with it.
If you're running 3D games and the like, then both performance and bandwidth will be an issue and limit your framerates. Comparing the previous review and this review of add in boards, shows about a 25% reduction in framerate (at 1024x768) between an add in GeForce4 MX440 and an NForce2 integrated chipset in UT2003, and an almost 40% reduction in 3DMark 2001. Since the machines were not identical, don't take the numbers as gospel, but they were similar enough to make a meaningful comparison IMHO.
That being said, for normal 2D work, bandwidth utilization is negligible and shouldn't seriously impact performance as shown by this SysMark 2002 test. AFAIK, this doesn't take into account extremely intensive RAM->CPU loads, but I wouldn't expect results to vary significantly, since memory requirements for 2D work are relatively low.
Be warned though, that Tom's Hardware did note image quality issues with most of the integrated chips-which they theorized was the result oflow cost manafacturing, not a limit of the technology itself. This theory is bolstered by the fact that their low cost add in card (Radeon 9200) suffered the same problems.
...which had the Z80 CPU generating the video directly, leaving only interframe gaps for computing.
Since the greeblie had no interrupts and they were too lazy to quantise the BASIC interpreter so that they could run it in the interframe and still generate reasonably consistent sync pulses, the screen went away completely while programs ran. A modern monitor would go postal, faced with a constantly appearing/vanishing sync pulse train but TVs are kind of used to dealing with cruddy signals.
I think the Sinclair was branded a Timex in the UK.
Got time? Spend some of it coding or testing
In general, yes, shared memory sucks bandwidth. As others pointed out, the calculations are pretty straightforward (X * Y * #bytes/pixel * refresh rate = Bandwidth).
However, in today's systems it's FAR more complicated that this.
First, some older implementations, particularly the Intel 810, used a 4MB display cache. The net of this is that the display refresh was generally served from a secondary memory and didn't interfere with main memory bandwidth. As well, Intel used some technology Chips & Tech developed that basically did run-length encoded compression on the display refresh data (look right at your screen now, there's a LOT of white space, and RLL will shrink that substantially.)
Today most chip sets incorporate a small buffer for the graphics data and compression techniques to minimize the impact of display refresh on bandwidth.
But wait -- it gets even MORE complicated. With integrated graphics on the north bridge of the chip set, the memory controller in the chip set knows both what the CPU and what the graphics core want to access. So the chip set actually does creative scheduling of the memory accesses so that the CPU doesn't get blocked unless absolutely necessary. So most of the time the CPU is either getting its memory needs services by its own cache, or it's getting (apparently) un-blocked access to memory. So the impact of graphics is much less than the simple equation above would suggest.
Finally... we now have dual-channel memory systems. Even more tricks to keep the graphics and CPU memory accesses separate come into play here.
So, the short answer is yes, there's an impact, but it used to be much worse. Innovative design techniques have greatly reduced the impact so that in non-degenerate cases it doesn't affect the system too much. In a degenerate case of your app never getting cached and doing nothing but pound on the memory system with accesses, however, then you'll see the impact in line with the bandwidth equation above.