Multi-GPU microstutter: Workaround solution

[boxleitnerb]

As far as I know Nvidia has implemented something like this. A NV-guy was talking about it in an interview (in German unfortunately):
http://www.youtube.com/watch?v=isWb4Ktb94A

Basically he acknowledges microstutters, saying that they have a buffer in their driver that helps to release the fps evenly. However, the data management of some engines gets messed up in very taxing settings, there is too much data that cannot get coordinated properly, thus rendering the buffer ineffective.

 

[ViviTheMage]

I don't see any microstutter with my 2x6950's ... and I am not sure how I would feel enabling vsync, it always makes the game feel sluggish.

 

[SirPauly]

Thanks for sharing -- nice info.

 

[AdamK47]

The Skyrim SLI profile has it's own problems. In performance SLI mode, the reflections on the water in some areas can sometimes start flashing and water displacement mapping doesn't work. I can fix the water flashing problem by using the Fallout 3 / New Vegas SLI compatability flag, but water displacement maps still do not render correctly. HDR does not work correctly at all no matter what SLI capatability flag has been set. Another huge problem with performance SLI mode is that the framerate will drop for no apparent reason. I'm not talking about 2 or 3 frames either. More like 15 to 20 with vsync enabled. This causes massive stuttering with horrible mouse lag. This seems to happen even in areas that don't have a lot going on in it. Single card mode does not have this problem. I gave up on performance SLI mode for this game and have switched to using SLI AA mode. You get single card performance, but with far better image quality. Maybe Nvidia can fix their SLI profile in future drivers to get everything working correctly. For now, SLI AA mode works great and looks great.

 

[AdamK47]

AFAIK SFR died and AFR won...with microstutter as a fallout.

SFR didn't scale geometry, so it had it's own drawbacks too.

SFR can still be used, but not directly through the Nvidia control panel. It can be selected using Nvidia Inspector. One game I use it with is Company of Heroes. The default AFR profile causes shadows to flicker like crazy. SFR doesn't have this problem. SFR doesn't provide nearly the increase in framerate AFR does for this game, but it does provide me between 10% and 20% increase over single card performance with a 3-way GTX 580 setup. The game is probably old enough to where I don't need SLI anyway. SFR also fixes the stuttering in older OpenGL games. ID Tech 2 and 3 games use it well, but then again no SLI performs just the same with vsync enabled.

 

[BFG10K]

Does SFR even work with modern engines?

Yes in theory. It should still be in the driver even if the stock control panel can’t access it. Performance isn’t as high as AFR, but it also has none of the drawbacks. You also don’t need application specific code to handle inter-GPU dependencies.

Nvidias multi-GPU AA has a bad image quality and is only based on MSAA/CSAA. AMD has a 16xSGSSAA CF-AA mode that is horribly slow. At least for me this is not a practical solution.

Yes, that’s a real shame. If the vendors did multi-GPU right they could pull off SSAA for free (from a performance standpoint) with none of drawbacks of multi-GPU.

If I want to invest heavily in image quality and my fps are low anyway, I only lose a little performance but get rid of microstutters completely.

Fair enough, but personally this is not how I play my games.

 

[BFG10K]

It can only use the historical measure. No game can predict how long the GPU will really take on the next frame, but at the same time the delay of 1 or 2 frames when actually all of a sudden the load has increased dramatically isn't going to make much difference and if you are only looking back for less than 100ms then it shouldn't really ever register to the human something bad just happened, we are talking about 8ms at 60 fps and 16ms at 30.

AFR already causes detectible input lag because it’s rendering frames ahead of displaying them. Any additional buffering scheme to smooth out the framerate would add even more detectable lag.

 

[boxleitnerb]

Yes in theory. It should still be in the driver even if the stock control panel can’t access it. Performance isn’t as high as AFR, but it also has none of the drawbacks. You also don’t need application specific code to handle inter-GPU dependencies.

Yes, that’s a real shame. If the vendors did multi-GPU right they could pull off SSAA for free (from a performance standpoint) with none of drawbacks of multi-GPU.

Fair enough, but personally this is not how I play my games.

I might give it a go, but the performance increase would be to little for my taste. There could be scenes where SFR doesn't scale at all.

This would be so perfect. I heard that 4x or 8x SGSSAA cannot be split efficiently across multiple GPUs. I'm not sure why, I don't have the knowledge.

For some games I need 60+fps, too. To each his own

 

[BrightCandle]

AFR already causes detectible input lag because it’s rendering frames ahead of displaying them. Any additional buffering scheme to smooth out the framerate would add even more detectable lag.

It would only cause delay for a single frame. What we are asking the game to do is to do two things. 1) It needs to know roughly how long the GPU is taking to render - ie its frame rate. 2) It needs to predict the CPU frame time. Then it delays the start of CPU computation to sync them. On the second frame when it adjusts for a change in frame time however it also puts the alternative frame off by an additional +50% of GPU render time to make sure frames are as far apart as they should be to produce a smooth world.

It would be nice to have the option to make it delay the CPU rendering to sync the two up such that we don't get either old data displayed or two frames that are very close to each other rendered alternatively.

 

[BrightCandle]

A pair of 7970's running heaven benchmark for me is running at about 110 FPS on top settings at 1920x1200. However at those settings there was considerable microstutter in the first scene. Which goes to show that you can have a lot of fps being pushed with cards more than capable of playing a game and still suffer from microstutter. Its not just a problem near 30fps.

 

[ArchAngel777]

A pair of 7970's running heaven benchmark for me is running at about 110 FPS on top settings at 1920x1200. However at those settings there was considerable microstutter in the first scene. Which goes to show that you can have a lot of fps being pushed with cards more than capable of playing a game and still suffer from microstutter. Its not just a problem near 30fps.

+1 - However, in my experience Vsync resovles the issue. I was actually able to confirm this on a number of titles using FRAPS frame tracking and someone on extreme systems made a program to parse the information. SLI ended up within 1-2% percentage points of perceived smoothness once Vsync was enabled.

And, additonally, even when testing my 460 in non-sli mode without Vsyc there was microstutter as well. It makes sense as perceived smoothness is based on consistency.

 

[soccerballtux]

sounds like the ideal situation for this fix is when a single card can run the game at 45fps or so. Then During heavy situations it slows down to 30fps, in normal situations it's framerate capped to 60fps instead of 90.

 

[boxleitnerb]

+1 - However, in my experience Vsync resovles the issue. I was actually able to confirm this on a number of titles using FRAPS frame tracking and someone on extreme systems made a program to parse the information. SLI ended up within 1-2% percentage points of perceived smoothness once Vsync was enabled.

And, additonally, even when testing my 460 in non-sli mode without Vsyc there was microstutter as well. It makes sense as perceived smoothness is based on consistency.

What fps did you have when vsyncing? Always 60 or below?

 

[itsmydamnation]

i don't know how you did your measurements but i will just leave this here for consideration

http://forum.beyond3d.com/showpost.php?p=1610062&postcount=2291

( the context of this post is a little different to this thread, but worth considering)

For now though, I thought I'd make a quick remark on the TechReport review:
You have to understand that what TechReport records is not necessarily what you see. They are using FRAPS to log individual frame times, and this works by a D3D software hook that monitoring the times that IDirect3DDevice9:resent() is called. It doesn't monitor changes on the screen like Digital Foundry does in their Eurogamer faceoffs. Games usually take the past few frame steps to predict the next one, so stuttered Present() calls would still have objects move in steps that match unstuttered calls.

If a driver is to minimize input latency, it wants to get information from the game for the next frame as fast as possible (within reason, as it only queues a frame or two). This could result in stuttered calls from the view of FRAPS, but the driver can put the frames on the screen smoothly with delays at its discretion. If, OTOH, the driver wanted to ace TechReport's test, it would have a heuristic to insert variable artificial delays somewhere so that calls to Present() were more even, and then more delays at the end of the pipeline to make sure the frames went to the display smoothly.

You should read their Battlefield 3 Performance article. They get differing results in the same game. With their Fear no Evil test, AMD shows lots of microstutter in FRAPS, but "the Radeons just don't feel much choppier than the GeForces overall." In the Rock and a hard place test, it was the other way around, and "with a GeForce, the latency spikes were very palpable, causing animations seemingly to speed up and slow down wantonly".

Even if the frame times reported by the driver matched those of the display, there's no easy way to summarize it all. Consider the Skyrim 99th percentile numbers you referenced where the 7970 was "worse". Now, look at the actual plot Kaotik posted above. The 99% percentile is virtually the same for all DX11 cards because the slowest 1% were all within the first 600 frames, where it looks like it is CPU/PCI-E bound. After that, however, it is the GTX 580 which shows vastly more stuttering according to FRAPS, despite you claiming the opposite due to the 99th percentile time.

Looking closely, it appears that up to 2500 frames are CPU limited. If you cut those out of the test, the 7970 is then 20% faster than the 580 instead of 10%.

 

[d3fu5i0n]

False:
http://techreport.com/articles.x/21516
You might not percieve it, but that don't mean others won't...

I highly agree.
I remember using two 5770s once. Even getting around 120-180FPS in Portal 2, I'd still regonise microstutter and a moderate amount of input-lag, even Crysis Warhead when getting high framerates [the level in the mine].
I found that V-Sync lowered the perception of the stuttering, although it would highly increase the amount of input-lag.

Well... that's what I found.

 

[ArchAngel777]

What fps did you have when vsyncing? Always 60 or below?

Depends on the game. With BF3 I am 60 quite a bit of the time, but there are many times I will dip into the mid 40's. I don't notice any issues when it does, I have to use FRAPS to even notice it.

 

[ArchAngel777]

I found that V-Sync lowered the perception of the stuttering, although it would highly increase the amount of input-lag. Well... that's what I found.

I do not notice any input lag with SLI versus single card. I have pre-rendered frames set to 0 globally. Not sure if that has anything to do with it. If the input lag is merely 16ms or so, I highly doubt someone could/would notice it. However, we are all different. Some people claim they don't see tearing, others claim they can't see aliasing and yet others (myself) claim they can't really detect the input lag that Vsync supposedly induces.

However, there are SOME games where Vsync has induced noticable input lag, but that is pretty rare in my experience. I think the only two games I found did that was Metro 2033 and Dead Space 1

 

[Attic]

As far as I know Nvidia has implemented something like this. A NV-guy was talking about it in an interview (in German unfortunately):
http://www.youtube.com/watch?v=isWb4Ktb94A

Basically he acknowledges microstutters, saying that they have a buffer in their driver that helps to release the fps evenly. However, the data management of some engines gets messed up in very taxing settings, there is too much data that cannot get coordinated properly, thus rendering the buffer ineffective.

This follows what I have seen. I always enable vysnc, but still note microsotutter in these situations.

I'm noticing microstutter much more when i'm at ultra settings and using 4xTrSSAA while at <60fps. Stuck at 60fps everything is good, but i'm still getting what I think of as severe MS when going crazy with details and at anything less than 60fps. I'll have to continue to test if this is due to TrSSAA.

 

[Mize]

Good thread.
Can anyone comment on the impact of core parking on microstuttering? I know BF3 players were disabling core parking to remedy stuttering, but don't know if anyone has analyzed the impact on microstutters.

 

[blackened23]

I haven't seen microstutter in a long time but for those that do, the MSI afterburner fps limiter combined with vsync eliminates it for everyone that has tried it.