How does xfire&sli really work?

[Timopomer]

i wonder why you cant connect lets say 3 monitors to 3 cards in SLI and have each monitor render its own part of the game resulting in perfect scaling?

 

what is actually happening behind the scenes?

[nanowatt]

Did some google "research"

There is two ways that SLI works.

One is called split frame rendering - this is where the frame it split horizontally in half, which splits the workload 50/50 for each card. It intelligently splits the workload based on the geometry of the frame, for example if there is little to render on the top half (e.g. sky) and a lot on the bottom (smoke, debris, ground textures) the dividing line will move to balance the workload between each card. Split frame rendering is pretty poor at scaling the work when compared against alternate frame rendering (below).

The second is called alternate frame rendering. Each card renders full frames, but in sequential order, for example the master card might process even frames (2,4,6) while the slave card processes odd frames (3,5,7). When the slave card finishes work on a frame the results are sent to the master card, usually via the SLI bride (as described above). Theoretically this should result in the rendering time being cut in half, which should technically linearly scale the performance by double. This is not often the case in practice though, depending on drivers, games, etc.

[Sauron]

i wonder why you cant connect lets say 3 monitors to 3 cards in SLI and have each monitor render its own part of the game resulting in perfect scaling?

 

what is actually happening behind the scenes?

 

Data is being shared across the cards and an algorythm is running to determine which card is rendering what. Suppose one of the monitors shows a particularly hard to render object: what happens if each card is rendering each screen indipendently and one of the cards drops a few frames? It would be unusable. So an algorythm makes sure the workload is evenly distributed at the cost of some raw performance. The more this algorythm has to work and the more the workload needs to be split, the less will be the performance gain.

[Enderman]

 

[Briggsy]

Data is being shared across the cards and an algorythm is running to determine which card is rendering what. Suppose one of the monitors shows a particularly hard to render object: what happens if each card is rendering each screen indipendently and one of the cards drops a few frames? It would be unusable. So an algorythm makes sure the workload is evenly distributed at the cost of some raw performance. The more this algorythm has to work and the more the workload needs to be split, the less will be the performance gain.

 

I wonder if variable refresh rate monitors could potentially remove this limitation...

 

3 cards, each with its own monitor could theoretically work for Eyefinity/Nvidia surround if the fps did not have to be equal. Of course, a whole new mess of problems would present itself, I'm sure.

[Sauron]

I wonder if variable refresh rate monitors could potentially remove this limitation...

 

3 cards, each with its own monitor could theoretically work for Eyefinity/Nvidia surround if the fps did not have to be equal. Of course, a whole new mess of problems would present itself, I'm sure.

 

it would still be incredibly uncomfortable to look at. Imagine looking at a scene that's being rendered separately and off-sync in 3 sections.