![]() |
|
#1
|
|||
|
|||
|
GPU "Microstuttering" FAQ
So everyones been posting about how an SLI or Crossfire rig, while managing to put out higher FPS than the single GPU solutions, does so while "Microstuttering". I'd like to clarify as much as I can around the issue, and hopefully you guys can help me out too. I don't have access to a multi GPU rig right now, so I'm going to go from what I learned about SLI and crossfire setups from my last rich customers dual 8800 build.
What is microstuttering? When running two Graphics Processing units (GPUs) in tandem, via Crossfire or SLI, in Alternate Frame Rendering (AFR) mode, the two GPUs will produce frames asyncronously (for lack of a better term). Microstuttering can be expressed one way as your computer experiancing, in extreme rapid sucession, a high FPS, followed by a low FPS, followed by a high, then low, and so on. The following is a chart of Frames VS Time, with time in nanoseconds (yeah, I have no idea why they used nanoseconds, but 100,000 [the first increment] is 0.1 seconds, or 100 miliseconds) in the Y-axis, and the frame count (NOT FPS) in the X-axis. The lower the bar, the higher the FPS. ![]() Image taken from PC gamers hardware As you can see, the crossfire setup, while getting out the same amount of frames (30) in less time (ie, while maintaining a higher FPS), has a certain wobble. This wobble is the phenomina known as microstuttering. Here is another chart from anand found by Mega 666 ![]() Pulled from Anand The Multi-GPU "Variance" is much greater than that of the Single GPU solution. The greater the difference from one variance to the next, the greater the stutter. The difference between the average variance and the variance at any one frame is the phenomina of microstuttering. How does microstuttering impact me in game? Microstuttering can make playing what fraps is calling a 60fps game feel identical to playing a 30 fps game (literally, this is a potential true case mathmatically). Why does microstuttering happen? It's a product of the failure of a multi GPU solution to syncronize properly. Frame syncronization is the act of making sure that the time between frames is identical no matter where you take a measurement. In a single GPU solution one GPU builds the image, and then sends it off to the monitor. It then builds another and sends it off as well. Thus, a single GPU solution does not suffer from microstutter. In a dual GPU solution, two GPUs build seperate images. In Alternate Frame Rendering (AFR), GPU "A" must send its image to the monitor exactly half way between the previous frame from GPU "B", and the next frame (which will be from GPU "B" as well). Note: 20 milliseconds is .02 seconds, or 1/50th of a second. In my example lets go with a game running at 50 FPS. A frame is built and displayed by GPU "A". Exactly 20 miliseconds (ms) later GPU "B" must have completed building and displaying its frame. Exactly 20 ms after that GPU "A" must have finished building and displaying the next frame, and so on. Each frame must be displayed in exactly 20 ms after the previous one. I'm currently working on a flash demo to illustrate the point. When its done I'll export it to .gif and post it here... assuming [H] supports gifs lol. Do all Multi GPU rigs experiance microstuttering? It looks like it, yes. The extent to which might be different on one system than on another, they might even be different every time you start your machine or run the game engine. If I notice microstuttering, can I minimize/eliminate it? Yes. By running the game at a setting where your graphics cards are able to output more than the monitors refresh rate (that is, the maximum FPS the monitors are capible of; the pixels on your screen can only change so fast) microstuttering is eliminated completely. Most monitors have a refresh rate of 60 or 70Hz, meaning you would need 70 or 80 FPS to eliminate microstuttering. Also, running the game in Split Frame Rendering (SFR), with the top half being rendered by one card and the bottom half being rendered by the other, will eliminate microstuttering, but opens the door to tearing and a performance hit. I don't know if SFR is even still supported... If theres any other point anyone would like me to make, by all means post it and i'll include it. Last edited by MrWizard6600; 06-21-2008 at 02:40 AM..
|
|
#2
|
|||
|
|||
|
ahh good stuff. now i understand why CSS occasionally looked the way it did after i had sli'd two gts g92's.
|
|
#3
|
|||
|
|||
|
Are there any games where the style of play or motion makes this issue relatively obvious? I'm understanding the concept thanks to the helpful graph, but I'd like to get a better practical feel of what to look for.
|
|
#4
|
|||
|
|||
|
Maybe you shouldn't try to look for it.
Ignorance is bliss.
|
|
#5
|
|||
|
|||
|
Problem with micro stutter..or any stutter...is once you do see it, it will bug the living shit out you for a long time.
|
|
#6
|
|||
|
|||
|
That chart is deceptive. No video card renders at the exactly the same rate the whole time. Just look at a fraps chart. It'll be all over the place even on a single card. So microstuttering isn't just a multi-GPU issue. If a single GPU renders frame A in 20ms, Frame B in 22ms, frame C in 18ms ... would you not see the same effect?
|
|
#7
|
|||
|
|||
|
I've sent my cards in for speech therapy.............
|
|
#8
|
|||
|
|||
|
Quote:
|
|
#9
|
|||
|
|||
|
Quote:
|
|
#10
|
|||
|
|||
|
Quote:
I knew this would come up and I'm going to have to incorperate it somehow. What your suggesting is nearly impossible. the odds that the frame's content has changed so dramatically that the GPU requires a whole additional 4 ms of time to render would be extremely rare. A sharp drop or an increase in FPS, even as sudden as some of [H]s charts indicate, when scaled to fit this chart would be a long curve, not s spike. I'll work on that now actually... Last edited by MrWizard6600; 06-21-2008 at 02:00 AM..
|
|
#11
|
|||
|
|||
|
Doing some research on this. Never experienced it myself but..
An interesting and long thread at anandtech - http://forums.anandtech.com/messagev...VIEWTMP=Linear Another graph which may help. ![]()
|
|
#12
|
|||
|
|||
|
This is very interesting and I will be looking forward for more results.
Acquiring a pair of 4870 seems a valid option but this kind of weakness could maybe change my mind.
|
|
#13
|
|||
|
|||
|
I've heard AMD has redesigned their bridge and patched their drivers to help prevent microstutter.
|
|
#14
|
|||
|
|||
|
Quote:
+1 to the OP for posting this.
|
|
#15
|
|||
|
|||
|
Quote:
|
|
#16
|
|||
|
|||
|
It's the delta in latency between each rendered frame. With AFR, that delta is large enough to perceive as interrupting or inhibiting the even "flow" of frames rendered.
|
|
#17
|
|||
|
|||
|
Yeah, I got that. If I'd seen that in the OP, I would have understood the magnitude of the problem.
|
|
#18
|
|||
|
|||
|
I have seen this issue for awhile and it drives me nuts as Trepidati0n stated! I am surprised that it wasn't brought up awhile back. When I talked about stuff like this, people told me I as seeing things. lol
|
|
#19
|
|||
|
|||
|
Excellent post OP. I've seen it in the few SLI rigs I've worked with, but nice to see the data behind it
.
|
|
#20
|
|||
|
|||
|
This thread should be stickied, very nice information.
|
![]() |
| Thread Tools | Search this Thread |
|
|