Dual Graphics Showdown - SLI vs Crossfire

The Renaissance

Since the introduction of PCI Express, the dream of multi-board graphics has once again been realised. As motherboards carry multiple PCI Express slots, the physical obstacle is now removed. PCI-E also provides an unprecedented amount of bandwidth not only to the GPU, but from the GPU as well. While AGP 8x provides 2.1GB/s of total bandwidth, the sixteen lane PCI-E slots used for graphics boast 4GB/s of upstream and 4GB/s downstream bandwidth. If more than one GPU had to share this bandwidth, you can be sure it won’t be choking anytime soon.

And thus, in 2004, SLI was reborn. Leveraging PCI Express and their nForce4 chipset, NVIDIA launched the GeForce 6 series of GPUs with SLI support. This time SLI had a different meaning – Scalable Link Interface as it was known was a digital connector that provided a direct link between two graphics boards. But the principle of dividing and conquering the workload remained the same.

Although ATI enjoyed a slight lead against a single GeForce 6800, the X850, irrespective of how many suffixes added to its name, could not fend off two 6800 Ultras working side by side.

And thus CrossFire, ATI’s multi-GPU solution, was announced in May of this year. By the time you read this, it should almost be available. Before we dive into the technology of SLI and CrossFire, it’s important to first understand the problems they face. Although graphics is inherently parallel, getting two GPUs to accelerate a single game with total transparency is still no easy feat. There’s the traditional problem of sharing memory and synchronisation. On top of that, load balancing and scene partitioning becomes critical factors to performance. Image quality and FSAA also become more interesting with dual-GPU solutions. So fi rst we’ll first look at the science behind multi-GPU graphics, and then the implementations offered by ATI and NVIDIA.

Splitting frames between cards-the CPU splits the frames between each card for rendering, afterwhich they're processed by the SLI mode in use.

Multi-GPU mojo

In an ideal world, when you plug in the second graphics card, games run twice as fast. For this to happen, a few conditions must be met. First, there should always be work for both GPUs to do. Second, the work should be easily split into independent parts. Third, both GPUs should be doing the same amount of work, such that one is never waiting for the other.

The problem of feeding both GPUs constantly is mainly in the hands of AMD and Intel. Unfortunately, it is also the biggest problem facing dual-GPU systems today; no Athlon or Pentium can adequately feed even a single Geforce 7800. Simply put, the CPU takes longer to execute the game code than the GPU to render the graphics. But by no means is this a new phenomenon – it’s been around since the Voodoo era. We can only hope that multi-core CPUs and multi-threaded game engines will alleviate this imbalance somewhat.

The problems of splitting up (partitioning) and balancing the workload is the real science of multi-GPU graphics. There are two ways of partitioning the work: split the workload into different frames, known as alternate frame rendering (AFR) or split the individual frame into different parts, which NVIDIA calls split frame rendering (SFR).

Alternate Frame Rendering

Alternate frame rendering is the most straightforward method of partitioning. Using this method, two frames are calculated concurrently. The CPU begins by feeding the first GPU with an entire frame. While it works on this frame, the CPU hands over the next frame to the other GPU. In this way, both GPUs are working on alternating frames and partitioning is done without fuss. Since each GPU works on independent frames, both vertex and pixel processing power is doubled.

Alternate frame rendering is elegant in that it does both partitioning and balancing. Successive frames are roughly the same and it can be expected that both GPUs will take the same time to render their frame, hence balancing is done automatically.

Alternate frame rendering does have a few drawbacks however. First, its performance is greatly affected by inter-frame effects. Shaders which use the results of previous frames to render the current frame will require the GPUs to pass rendered results to each other. Motion blur, which accumulates results from multiple frames is one such example. Second, AFR introduces an extra frame of latency into the pipeline. Since the CPU is always buffering two frames, what you see on the screen will always be behind your input by the time it normally takes plus the time to draw an additional frame. At 60 frames per second, this adds an additional 16 milliseconds of latency. And lastly, there are some pathological cases where the game code doesn’t work with AFR.

For such cases, split frame rendering must be called into service.