facebook rss twitter

Review: NVIDIA's SLI - An Introduction

by Ryszard Sommefeldt on 22 November 2004, 00:00

Tags: NVIDIA (NASDAQ:NVDA)

Quick Link: HEXUS.net/qa4u

Add to My Vault: x

What mode to choose?

It's a good question. A quick pass at the thought process for the choice of rendering mode for certain applications, since that's how the current SLI drivers do it; per application, leads me to believe that NVIDIA decide upon it by considering the following. Understand that this is pure speculation on my part.

Firstly, the available core logic for SLI is nForce4 SLI or Tumwater. That means a reasonably fast processor as a given (3.0GHz Nocona Xeon or Athlon 64 3500+), so the CPU limitation argument, that'd cause you to not use AFR as a default, has some boundaries.

The analysis is then done for an application using that slowest CPU, to get a frame rate and resource usage profile of that application across a fair chunk of its usage. Both SFR and AFR modes will be used. Analysing not just frame rate lets you weed out cases where maybe performance is high with SFR, but off-screen resource usage is still high and the SLI overhead is larger than it need be. So AFR will be chosen if minimum framerate is above some acceptable measure. That'd be done for each SLI card combination. So in theory you might see AFR used for an application using 6800 Ultras, but SFR or SLI disabled on 6600 GTs.

And currently all the behaviour that decides what mode to use is hard coded in the driver, inside the profile system.

I talked about there being two SLI modes - AFR and SFR - but around four separate SLI situations where it can be active. It appears that in the AFR case, it can be deactivated when the application isn't run full-screen. It can also be tweaked to adjust pixel offsets into the final output. It appears that some applications, especially those that are highly efficient in their use of the GPUs in AFR mode, can bounce the image around by a single pixel, so that the final image appears to shimmer and jiggle around by a single pixel up or down.

So you get the SFR case, AFR windowed, AFR full-screen and AFR with corrective offsetting either windowed or full-screen (if I'm indeed analysing it correctly) as possible modes in the driver. Those modes are marked with a hex code that tell the driver how to setup the rendering, maximal and minimal splits in the load balancing if applicable (so that rendering can monopolise 99% of a single GPU in SFR mode, or you can prevent that actually happening if needed, for example) and the various AFR modes with possible correction values.

Currently, those modes aren't changeable without some effort. For example, I'll show you Half Life 2 performance in due course, using AFR (the default choice) and also in load-balanced SFR mode. That's only possible by analysis of the modes and editing the driver by hand.

Also the driver, depending on the SLI setup you're creating, might not activate SLI at all by default, even if you choose the Multi-GPU rendering mode. Indeed, for applications outside those identified in the driver's profile system, the default is to turn SLI off completely. And even if you enable it with a custom profile, the SLI choice is then always AFR.

The driver interface for SLI is therefore suboptimal. Unless NVIDIA have tested SLI with a certain application, it's not on the list and SLI won't work for it. Then even if you turn it on, you get AFR without fail. There needs to be easy user configuration of the available modes, even if that's just a choice between AFR and SFR. It also opens up all sorts of problems with the corrective AFR modes, if you can't specify those parameters and the default AFR mode produces incorrect rendering. Even moreso if that incorrect rendering gave amazing framerates!

Currently, the driver in an SLI system is the weakest link. During testing in recent weeks, the driver has switched around operating modes for applications between revisions, turned off SLI completely where it was once enabled and generally sought to frustrate. Pinning down a good driver for all applications has been futile. For example, 66.93 breaks SLI completely on my Tumwater SLI system but the drivers that do work well don't give good SLI performance in all applications. Fun and games.

Let's have a look at how the driver appears.