Originally posted by: nullpointerus
Originally posted by: taltamir
Originally posted by: tanishalfelven
Originally posted by: taltamir
From what I read quad SLI is not practical before DX10 due to limitations on how many frames ahead you can render. With DX10 you can render more frames ahead, thus allowing each card to work on a different frame without having to wait for other cards to finish.
isn't that kind of a waste. i mean what if the user turns or fires. all those extra frame are wasted unless the game can predict what the gamer will do.
Consider, if you will, that a normal playable framerate is 30 frames per SECOND. And that the ideal (and max on most monitors) is either 60 or 75.
So if you are 3 frames ahead and fire a weapon then frames aren't wasted, you just experience a 1/10 of a second delay before the animation kicks in.
You and tanishalfelven appear to have two different definitions for the phrase "rendering frames ahead": 1) the extra frames are what the game guesses will happen at some point in the future, so they are discarded (i.e. never shown on the screen) whenever the game guesses wrong; and 2) the extra frames are synchronized with the game engine, so they will be rendered whenever the monitor gets around to it (if v-sync is on), but input is desynchronized so that the keyboard/mouse commands to fire the weapon will not actually be considered until the latent frames have been rendered.
Either case would appear to have diminishing returns. If you had 20 cards, each rendering ahead, then, when a weapon is fired that would either be [case 1]: 19/20 (95%) of your graphics processing power wasted, or [case 2]: input lag of 19 frames (1/3 of a second). But both these cases are for AFR.
SFR would appear to have diminishing returns, too. With 20 cards, each of which is told to render 1/20th of the screen, some of the cards would be rendering the top portion of the screen, where there is typically little or no work to do, while other cards would be rendering the center of the screen, where most of the work occurs.
The real question is, of course, the benefit of 2 vs. 4 cards (not 20, a number which was picked for illustrative purposes only). However, since there are diminishing returns in all cases, quad SLi would never approach 400% efficiency in a real game: each additional card will make less and less of an improvement. The information required to render a frame is still tied to input, a fact which will
never change. Expecting 4x 8600GTS to equal 2x 8800GT would probably be a pipe dream, even if the theoretical maximum rendering rates were comparable.
IOW, one could easily create a contrived example in which quad SLi will hit 400% efficiency over a single card of the same type, but the contrived example would never apply to games where input
must be tied to frame rendering. Conversely, I can see how quad or octal-SLi would be extremely effective in an render farm because the frames are being rendered as fast as possible from predefined scripts, not dynamic human input.
The biggest problem is compatibility. nVidia and ATI have enough trouble getting (and keeping!) two-GPU solutions working with the most popular games. Quad-SLi would be worse off (in terms of driver problems) even if it became as officially-supported as two-card SLi.
Changing the DX/OGL specifications (or the hardware implementation) to make games more compatible with multi-GPU rendering would be a great first step, IMO. That's why I am interested in the
new multi-GPU approaches, which could allow for greatly increased compatibility (since frame element distribution and composition would be directed at the hardware level rather than at the software level).
EDIT: Changed wording to make this post readable.
Facebook
Twitter