Alternate-frame Rendering
Alternate-frame rendering is a much easier way to increased performance, relatively speaking. All the complex overhead inherent to a load-balanced SFR method is negated with AFR.Full frames are prepared by the CPU and presented to the driver, which renders them on the next GPU in the round-robin sequence. That means entire batches of geometry, fragment data, off-screen resources like render target, any other buffers and everything else needed to render a single frame of output. There's no overhead in managing off-screen resources, MRTs, geometry or anything else. It's all just batched to the GPU as a whole, as it would be in a single-GPU system.
However, since frames are rendered in that way, there's significant buffering involved. As one GPU is working on rendering a frame, the next frame that'll be rendered on the other GPU can be being prepared for the GPU, by the CPU and the driver. If that data is all ready, even if the currently active GPU isn't finished drawing a frame, the other GPU can be rendering it, in preparation for a buffer swap (and copy to the primary GPU's framebuffer, if it's the secondary card). That buffering can happen many times per frame if the CPU is fast enough and there's an excess of spare computing power to make it happen.
However, if for whatever reason there's not enough buffering happening for player input to be interleaved into the rendering process, there can be a lag between player input and render output. That's extra latency and something that can't be overcome in AFR mode (without maybe switching back to SFR) if the frame-rate is low enough for it to become manifest.
That's the simple explanation for AFR being sub-optimal for SLI. If you're not rendering quick enough, there's even more latency introduced than in the low-framerate case with SFR (or a single frame being renderered by a single GPU). That can be caused by a slow CPU (so SFR is preferred to reduce the latency, despite the overhead), unoptimised driver or pathalogically bad application programming (say for example the application periodically locks lots of off-screen render targets, causing a pipeline stall more often than is necessary). AFR doesn't help you recover from that any faster than normal.
It accelerates well when the rest of the process can keep up (you can double geometry performance and double pixel performance to a certain extent), but it's a poor choice when that can't happen.
Currently, SLI can't fall back to SFR or even single GPU mode when AFR isn't helping.
And it turns out that AFR, not load-balanced SFR, is NVIDIA's recommended mode of operation for its current SLI implementations. That turns on its head current thinking about the way SLI would be done for the majority of applications. Let's examine the possible thinking behind that.
