Associate
- Joined
- 3 Jul 2008
- Posts
- 378
There is much debate about 'microstutter' (which should really be called 'uneven frame output' but anyway) when using multi-GPU setups. Many people report that they notice this when using their multi-GPU systems. A few have produced results 'proving' its existence, whereas others swear down that they have never experienced it, and/or question the validity or applicability of the very few numerical results actually available.
Anyway, to help answer the question, I have written a very simple little program which analyses FRAPS benchmark outputs to determine the degree of microstutter present. You can download the program here:
http://www.mediafire.com/download.php?2moyugibhez (thanks lightnix...)
Of course there will be some non-uniformity of frame output, even in single GPU setups. Also it is clear that the degree of non-uniformity changes from game to game. So, what would really be interesting is to find out by how much using a multi-GPU setup increases the level of microstutter, if at all.
Instructions for use are included in the readme.txt file (pasted below).
To get started, here are a couple of results I gathered to check that the thing was working. These were both gathered stood still, looking out across a vista (there was some dynamic stuff happening in the distance in each case however):
System:
e6600 @ 3.4Ghz
GTX280 @ 650/1107
HL2 ep2:
Crysis (1920*1200 high)
Anyway, single GPU results would be interesting, but the multi-GPU results should be the real eye-openers, one way or another. It would also be nice to see if there is a difference between SLI and xfire as far as microstutter goes. If so, that would be a real selling point in my eyes.
Anyway, to help answer the question, I have written a very simple little program which analyses FRAPS benchmark outputs to determine the degree of microstutter present. You can download the program here:
http://www.mediafire.com/download.php?2moyugibhez (thanks lightnix...)
Of course there will be some non-uniformity of frame output, even in single GPU setups. Also it is clear that the degree of non-uniformity changes from game to game. So, what would really be interesting is to find out by how much using a multi-GPU setup increases the level of microstutter, if at all.
Instructions for use are included in the readme.txt file (pasted below).
To get started, here are a couple of results I gathered to check that the thing was working. These were both gathered stood still, looking out across a vista (there was some dynamic stuff happening in the distance in each case however):
System:
e6600 @ 3.4Ghz
GTX280 @ 650/1107
HL2 ep2:
Crysis (1920*1200 high)
Anyway, single GPU results would be interesting, but the multi-GPU results should be the real eye-openers, one way or another. It would also be nice to see if there is a difference between SLI and xfire as far as microstutter goes. If so, that would be a real selling point in my eyes.
readme.txt included in file said:This little program attempts to quantify the degree of "microstutter" in a particular FRAPS benchmark output. Microstutter has become the popular term for describing uneven frame output, often present in multi-GPU setups when running with an alternating frame rendering (AFR) configuration. Its effect, when present, is to make a given framerate appear 'less smooth' than an equivalent framerate with a single GPU setup.
*** How to use the program ***
1) Make a folder wherever you like, and copy across the microstutter_test.exe file
2) Download and install FRAPS (http://www.fraps.com/). In FRAPS, go to the 'FPS' tab, and select the 'Frametimes' tick-box (located at the bottom left)
3) Enter your game with FRAPS running, and at a suitable point, run a FRAPS benchmark (default key is F11, I think...). Run the benchmark for a suitable length of time (say 30 - 60 seconds) during regular gameplay (no loading screens)
4) Go to the FRAPS/benchmarks folder, and find the appropriate *.csv file for the benchmark you just ran.
5) Copy this *.csv file to the microstutter test folder and rename the *.csv file to: input.csv
6) Run the microstutter_test.exe program, and observe the microstutter index. The higher the index, the greater the effect of microstutter during the benchmark.
*** How NOT to use the program ***
1) No not use with (double buffer) vsync enabled.
The microstutter index will always appear to be zero, since double buffer vsync switches discretely between constant framerates. However, if you have triple buffer vsync working properly, and your framerate stays below your monitor refresh rate (usually 60), then it might be interesting to see by how much the microstutter is reduced.
2) Do not use in games with a maximum framerate cap (unless your framerate stays below this)
As above, a fixed maximum framerate will lead to a zero microstutter index. Microstutter is not an issue anyway if you are operating at your maximum monitor refresh rate, or at a fixed framerate.
3) Do not run a benchmark while the game is loading, particularly if a separate loading screen is shown. In-game loading and paging should be accounted for to some extent (see below) but it is best to avoid this if possible. A good microstutter index can be obtained simply staring into space and doing nothing.
*** How does the program work? What is the microstutter index, exactly? ***
In short, the degree of microstutter is calculated for every frame by comparing its variation away from the local average frametime. This value is scaled by the local average frametime to obtain a non-dimensional index. The reported 'microstutter index' is the average of these values over the benchmark, multiplied by 100.
So, the smaller the microstutter index the closer each frame is to the 'smoothed' average framerate, and the less 'noisy' the data.
You can think of the microstutter index as being the (average) percentage varation of each frame away from the stabilised local framerate.
...Step by step:
The local average frametime is obtained by taking the average of the frametime for 4 frames in either direction (for a total of 9 contributions to the average). This is not calculated for the first 5 or last 4 frames, and so these frames are not included in the microstutter statistics.
The variation away from the average frametime is calculated for each valid frame. To help avoid the final data being skewed by large 'spikes' due to paging etc and other game related events, the largest 2% of local varations are culled, and no longer appear in statistics.
The local variation in frametime is divided by the local average frametime to produce a small nondimensional number (local microstutter index).
The average, over valid and non-culled frames, is taken for the local microstutter index. This number is multiplied by 100 to produce a more 'user-friendly' range of numbers.
*** Anything else? ***
Well, don't abuse me for the noobishness of the program. I'm not a computer scientist or software engineer or anything like that.
If you find any real bugs, let me know on the ocuk forums thread (see http://forums.overclockers.co.uk/ and look for Dr_Fartypants)
If you want to create a nice visual interface for the program, or otherwise improve it, then go right ahead! You can use the executable, or I can pass you the (horrible fortran90) source if you like. Just let me know what you're doing is my only requirement.
If you want to find me then I can usually be found at OcUK forums (Dr_fartypants), or hardforums (arseface).
Last edited: