Consecutive frames in AFR, stripes in SFR, rectangles in checkerboard. In action, consecutive frames will not differ by much in content. In fact, they will have almost the exact same datasets.
The difference between reading the resources needed to render the frame from local VRAM vs. involving the output processors (which are already heavily loaded), PCI-e interface, memory controller, and system memory is enough to render the latter impractical.
Unified memory architectures such as we are getting on AMD APUs and sort of getting on Maxwell may change this picture. But the older generation cards have to render frames from resources already in VRAM.
Sorry for insisting but I am really curious. From a parallel computing perspective I don't see why SLI works this way, but I honestly don't know much (i.e. anything) about game graphics.
Assuming I had CUDA devices 1 and 2, and one large data set (e.g. a large matrix) A on which I have to perform SIMD parallel code f, instead of copying A on both 1 and 2 (two calls of mem copy) and parameterizing f with respect to each device (as a function of device number, thread id and positional information) on A it would be possible to copy one half of A on each CUDA device (still two calls of mem copy) and parameterize f differently (minus device number). In the end, this would allow me to use matrices twice as large with the same amount of memory operations. One device doesn't have to read the other device's memory. The two matrices could be partitioned in halves determined by rows (stripes), submatrices (rectangles), or whole matrices if my data set consists of more than one (frames).
Once things are copied on the device's memory, everything would be read from the local VRAM, the rest of the memory hierarchy (such as the buses and main memory) would be involved in the same way as if both CUDA devices had copies of the entire data set. This type of approach is applied succesfully in distributed memory computing clusters all over the world, using message-passing through high-performance dedicated networks (usually based on Infiniband or derivatives) to split data across different nodes where fine-grained multithreaded code can run on multiple cores or multilpe GPU's. With the right design [complexity function of f, obtain parallel overhead and determine the appropriate ratio of input size / processors with respect to a communications model (of a network or internal buses)] this should increase efficiency and therefore also speedup. Algebraic methods such as those involved in graphics (for which GPU's were designed) scale particularly well.
I suppose game graphics don't behave like this though, and they are probably peculiar in that small scale response time is such a sensitive requirement that they're willing to sacrifice efficiency for raw speed? I'm assuming there's also some kind of workflow I am ignoring completely (for instance involving textures and shading or whatever), preventing a "good" utilization of the device.
Edit:
Ultimately I wonder how much of this is the API's responsibility and how much is the game programmers'. It seems to me at the moment they are using the easy way out, not the most efficient one.
Edit 2:
I wonder if this is due to having only one card in charge of the output, with the extra card(s) feeding ready-to-output data to the main card's memory, creating the restriction of using just as much memory as the output card has. This theory might explain this bit a little (for game graphics) and why this makes no sense in the world of HPC.
