Of scalingand failing
Multi-GPU schemes like SLI are always prone to fragility, and sometimes their performance simply doesn't scale up well from one GPU to two, or from two to three or four. We've written about this many times before, most extensively in this section of our CrossFire X review, so I won't cover that same ground once again. You'll see this dynamic in effect in our performance results shortly.
We noticed some particular quirks of three- and four-way SLI in preparing this article, though, that bear mentioning here. One of those issues involves video memory. Very high performance graphics subsystems require lots of memory in order to work effectively at the extreme resolutions and quality levels they can achieve. That presents a problem for G92-based SLI because current GeForce 9800 GTX and GX2 cards come with 512MB of memory per GPU, and SLI itself eats up some video memory. In some cases, we found that the GeForce 8800 Ultra, with 768MB of RAM, performed better due to apparent video memory size limitations with G92-based SLI.
In addition, we used the 32-bit version of Windows Vista on our GPU test platforms, largely because Nvidia's 64-bit drivers have sometimes lagged behind their 32-bit counterparts on features, optimizations, or QA validation. Since we're often testing pre-release hardware with early drivers, that was a real problem. However, choosing a 32-bit OS in this day and age has its own perils. As you may know, 32-bit versions of Windows have a total memory address space of 4GB. We installed 4GB worth of DIMMs in our test systems, but some of the OS's total address space is reserved by hardware devices, including video cards. For example, we see a total of 3.58GB of physical memory available in Task Manager when we have a single GPU installed on our Gigabyte X38-DQ6-based system.
This limitation hasn't been much of a problem for us in the past, but the problem grew more acute on our nForce 780i SLI-based test system. With a single GPU installed, that system showed only 2.8GB of physical RAM installed. With dual GPUs, the total dropped to 2.5GB, and then to 2.3GB with three GPUs. Our quad SLI system saw that number dip to 1.79GB, which is, well, uncomfortable. I doubt it had much impact on our performance testing overall, but it's not a lot of headroom and one heck of a waste of RAM. The lesson: use a 64-bit OS with these exotic three- and four-way SLI setups. We'll be moving our test platforms to Vista x64 soon.
We ran into a couple of other little problems, as well. For one, screenshots captured on the Windows desktop with Aero enabled had big, black horizontal bands running across them when SLI was enabled with Nvidia's latest 174.53 drivers. This is just a bug and not typical of the SLI setups we've seen in the past. Another likely bug was related to the "Do not scale" setting in Nvidia's drivers that disables GPU scaling of lower resolutions up to the monitor's native res. When we had that option enabled with three- and four-way SLI, 3D applications would start up with a black screen and the system would become unresponsive. We'd have to reboot the system to recover. Nvidia's graphics drivers usually avoid such quirkiness, but right now, those two issues are very real.
|AMD issues statement on R9 290X speed variability, press samples||10|
|MSI's new gaming notebook has a 2880x1620 screen||8|
|Next-gen Intel SSDs could have 2TB capacities, integrated heatsinks||17|
|Data suggests consumer drives are as reliable as enterprise models||48|
|Valve joins the Linux Foundation||55|
|USB group designing slim, orientation-independent connector||66|
|Are retail Radeon R9 290X cards slower than press samples?||224|
|Cherry intros MX RGB key switch; first keyboard due from Corsair||56|
|MSI's latest Z87 motherboard, GeForce GTX 760 graphics card have Mini-ITX dimensions||35|