After having reintroduced the possibility of using two graphic cards in parallel in order to increase performances with SLI, and Quad SLI’s big failure which tried to use two double graphic cards, Nvidia decided at the end of 2007 to add 3-way SLI to its multi-GPU offers. This gives us the occasion to take full inventory on the performances of SLI and CrossFire configurations.
The multi-GPU system
The nature of 3D rendering means that it’s very parallelizable, in other words, the same operation is executed on a significant number of distinct elements and on several levels. Geometry processing and that of its numerous vertices/triangles can be done in parallel as well as the calculation of pixels, and finally of course, the processing of images.
It’s therefore obvious that here lies an opportunity to divide up the required tasks of 3D rendering so that several graphic processors can be used. The issue then becomes one of finding the most efficient combination out of all of these possibilities and implementing it in a robust and performance consciousness way to drivers.
Sharing the work in terms of geometry between two processors inside the same image is feasible but rather complex to put into place. Gains may not be too interesting, all the more so that geometry processing represents a very simple task in many games.
Then there is separating geometry processing from the calculation of pixels with one graphic processor exclusively dedicated to one of these tasks and a second one to the other. Unified architectures actually enable GPUs to devote all of their calculation capacities to a very specific task; however, this goes against the very principle of these unified architectures which is the sharing of their processing capacities.
Dividing up the calculation of pixels between several GPUs is a better adapted solution at least with classic GPUs which have processing units dedicated to the calculation of vertices and pixels. In this case, each GPU will entirely process all vertices (in some ways a waste of resources, but either way this would mean dedicated units with nothing to do if this wasn’t the case) and only some pixels, for example, those on half of the screen, one out of two lines, or small zones on the image. Here, we are speaking of SFR (split frame rendering).
The division of work on pixels can be static (fixed once and for all) or dynamic (depending on the complexity of calculation of each zone of the screen and the power of each GPU). If the division is dynamic, this solution has the advantage of being able to efficiently divide the work between two GPUs of differing power; however, significant performances gains can be difficult to achieve in certain situations. While its basic functioning is "simple", it can become extremely complex with the engines in more advanced games.
Currently, the most efficient solution is to share the calculation of images between GPUs. With AFR (alternate frame rendering), each GPU handles the complete rendering of an image not having to worry about the other GPUs. The only challenge is that there be no dependence between images. While it is rather simple to avoid this, in a number of cases, the responsibility falls on the game developer and not the GPU manufacturer who is more or less powerless on this level. It was for this reason that the previous method was initially favored before it was progressively replaced in the majority of cases by higher performance AFR.
Dynamically sharing threads, or diverse operations that are to be executed on various elements, is the next step. More specifically, this will involve sharing the required calculations between different chips in a similar way to what happens between different units on the same chip. There are still a number of obstacles to be overcome, notably in terms of communication between GPUs and their memory, but it seems evident this will be the path to follow in the future.
