Welcome, Unregistered.

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Reply
Old 17-Aug-2008, 16:41   #1
Humus
Crazy coder
 
Join Date: Feb 2002
Location: Stockholm, Sweden
Posts: 3,217
Send a message via ICQ to Humus Send a message via MSN to Humus
Default Micro-stuttering and how to solve it

Since micro-stuttering is an issue for some people I thought it would be interesting to see if there's a way to solve it. Personally I'm not bothered by it and haven't actually been able to even see it, but I can prove it's happening with Fraps on my 3870x2. So I spent a couple of hours to implement a simple waiting mechanism to feed the GPUs at a more balanced rate. For best stability you want the second GPU to start working only once the first GPU is in mid-frame (assuming 2 GPUs). This is the result:



Now, since I'm not able to see the micro-stuttering in the first place I can't really say if it's any smoother in practice, but at least the Fraps graph looks good.

What I did was first to create a GPU limited test case using my InteriorMapping demo and slowing it down a bit by adding work to the shader until it ran at about 120fps. Micro-stuttering happens when you get GPU limited since you're feeding commands to the GPU faster than it can accept them. The more GPU limited you are the worse the problem is because the GPUs will start working on their frames shortly after each other and then after crunching through the frames both finish almost at the same time too, which makes one frame appear for 1ms and the next 15ms instead of both 8ms, as shown in the graph.

So I inserted an event query at the end of each frame. I use two queries, one for each GPU. Then at the end of the frame it syncs on its event query and counts how long it has to wait until this GPU's previous frame is complete. Then I sum up all the wait that was necessary and simply distribute it equally over the next two frames, which puts the frames better interleaved on the GPU. The best thing, the framerate did not change because of this.

I think something like this should be added to the driver with a simple checkbox in CCC to enable it. It can probably also be made more accurate than my simple prototype.
__________________
[ Visit my site ]
I speak for myself and only myself.
Humus is offline   Reply With Quote
Old 17-Aug-2008, 17:03   #2
Bouncing Zabaglione Bros.
Regular
 
Join Date: Jun 2003
Posts: 6,358
Default

Have you sent the code to your old contacts on the ATI driver team? If not, why not?
Bouncing Zabaglione Bros. is offline   Reply With Quote
Old 17-Aug-2008, 18:25   #3
MfA
Regular
 
Join Date: Feb 2002
Posts: 5,543
Send a message via ICQ to MfA
Default

The problem is that with your example the rendering will settle into a steady state with the same FPS as the stuttered rendering. The more variation in the rendering times the more delays will eat into benchmarks ... which is not a bad thing necessarily from a user point of view, but from ATI's point of view the stutter costs them nearly nothing in (it's just not made a big deal off) but a reduction in benchmarks far more. At least in the short term.

Or in other words, someone will probably need to write their own driver hook, I don't see ATI doing it (there is information out there how FRAPS does it's thing).
MfA is offline   Reply With Quote
Old 17-Aug-2008, 19:03   #4
digitalwanderer
Dangerously Mirthful
 
Join Date: Feb 2002
Location: Winfield, IN USA
Posts: 15,339
Default

Well if it's a check box option in CCC you could test it both ways, and I have a feeling ATi would recommend you test it with it OFF for flat-out speed tests.

Brilliant work Humus, thanks!
digitalwanderer is offline   Reply With Quote
Old 17-Aug-2008, 19:23   #5
Davros
Naughty Boy!
 
Join Date: Jun 2004
Posts: 11,075
Default

doesnt vysnc fix micro stuttering ?
Davros is offline   Reply With Quote
Old 17-Aug-2008, 22:50   #6
tabs
Senior Member
 
Join Date: Jan 2007
Location: UK
Posts: 1,255
Default

It's been my observation that you wont 'see' microstuttering at very high FPS because its hard to differentiate the higher it is, particularly on typical LCD monitors. It's noticable (to me) at around 35-65 FPS actual, where the scene might only appear to be rendering at 20-50, depending on how bad it is.
tabs is offline   Reply With Quote
Old 18-Aug-2008, 00:49   #7
Anarchist4000
Member
 
Join Date: May 2004
Location: Somewhere, IN USA
Posts: 313
Default

Here's an idea for your test. Include a pseudo-random number generator and include a dynamic loop that counts up to the random number. It should give the same sequence every time to be repeatable for testing. It should also be the worst possible scenario for micro-stutter. Another interesting test scenario would be a render to texture every couple of frames and then use the textures in the following frames.

Implementing an improved method of v-sync should be able to combat the problem almost entirely. Yes the framerates get capped to some degree but the frames would be coming at fairly predictable intervals.
Anarchist4000 is offline   Reply With Quote
Old 18-Aug-2008, 01:27   #8
digitalwanderer
Dangerously Mirthful
 
Join Date: Feb 2002
Location: Winfield, IN USA
Posts: 15,339
Default

Quote:
Originally Posted by Davros View Post
doesnt vysnc fix micro stuttering ?
Unfortunately no.
digitalwanderer is offline   Reply With Quote
Old 18-Aug-2008, 10:56   #9
Scali
Naughty Boy!
 
Join Date: Nov 2003
Posts: 2,127
Send a message via ICQ to Scali Send a message via MSN to Scali
Default

Quote:
Originally Posted by Humus View Post
I think something like this should be added to the driver with a simple checkbox in CCC to enable it. It can probably also be made more accurate than my simple prototype.
Yes, it's a pretty obvious solution, which I've discussed with some people years ago, when talking about multithreaded software rendering.
I originally assumed that this is what drivers did anyway (the driver can just keep track of average frame rendering times and have pretty accurate estimates for when to start the next frame, more or less like what you described), until people started reporting micro-stutter issues.

I can think of only one reason why the drivers don't: Your estimate won't be 100% perfect, and will have to be adjusted continuously, so you might get a slightly lower framerate than when you bruteforce the commands through as quickly as possible.
Scali is offline   Reply With Quote
Old 18-Aug-2008, 11:24   #10
Bouncing Zabaglione Bros.
Regular
 
Join Date: Jun 2003
Posts: 6,358
Default

Quote:
Originally Posted by Scali View Post
I can think of only one reason why the drivers don't: Your estimate won't be 100% perfect, and will have to be adjusted continuously, so you might get a slightly lower framerate than when you bruteforce the commands through as quickly as possible.
Which would be a good argument for making it an optional tickbox. This way the user can choose to have slightly higher framerates and ignore microstuttering, or slightly lower, but smoother framerates.
Bouncing Zabaglione Bros. is offline   Reply With Quote
Old 18-Aug-2008, 11:35   #11
Scali
Naughty Boy!
 
Join Date: Nov 2003
Posts: 2,127
Send a message via ICQ to Scali Send a message via MSN to Scali
Default

Quote:
Originally Posted by Bouncing Zabaglione Bros. View Post
Which would be a good argument for making it an optional tickbox. This way the user can choose to have slightly higher framerates and ignore microstuttering, or slightly lower, but smoother framerates.
Ofcourse, but I suppose the driver writers are just in denial on this issue.
I don't think anyone has ever officially admitted that this problem even exists, and you can't fix problems that don't exist, right?
Scali is offline   Reply With Quote
Old 18-Aug-2008, 12:54   #12
suryad
Senior Member
 
Join Date: Aug 2004
Posts: 2,454
Default

Wow so simple and clean! Utterly brilliant Humus. I for one have noticed microstuttering in HL2 weirdly enough. But it could be because my hard drives are really badly fragmented right now. I have never ever noticed any form of microstuttering till this weekend. I am going to defrag and give the game a shot some time today but still very brilliant work!
suryad is offline   Reply With Quote
Old 18-Aug-2008, 15:20   #13
Foodman
Junior Member
 
Join Date: Feb 2002
Location: I'm Lost
Posts: 51
Send a message via ICQ to Foodman Send a message via AIM to Foodman
Default

Quote:
Originally Posted by suryad View Post
Wow so simple and clean! Utterly brilliant Humus. I for one have noticed microstuttering in HL2 weirdly enough. But it could be because my hard drives are really badly fragmented right now. I have never ever noticed any form of microstuttering till this weekend. I am going to defrag and give the game a shot some time today but still very brilliant work!
Valve has a built in defrag mechanism for Steam. Try it first.
Foodman is offline   Reply With Quote
Old 18-Aug-2008, 16:18   #14
AlexV
Heteroscedasticitate
 
Join Date: Mar 2005
Posts: 2,433
Default

Quote:
Originally Posted by Scali View Post
Ofcourse, but I suppose the driver writers are just in denial on this issue.
I don't think anyone has ever officially admitted that this problem even exists, and you can't fix problems that don't exist, right?
You're wrong. On both accounts.
__________________
Donald Knuth: Science is what we understand well enough to explain to a computer. Art is everything else we do.
AlexV is offline   Reply With Quote
Old 18-Aug-2008, 16:25   #15
Scali
Naughty Boy!
 
Join Date: Nov 2003
Posts: 2,127
Send a message via ICQ to Scali Send a message via MSN to Scali
Default

Quote:
Originally Posted by Morgoth the Dark Enemy View Post
You're wrong. On both accounts.
In that case, point me to an official admission that the problem exists, and the intention to fix it.
If you fail to do so, I must be right. Which I probaby am anyway, else you would have done so in your previous post. But thanks for playing.
Intelligent, civilized people don't just go screaming "You're wrong" without any kind of argumentation whatsoever. Instead, they point out the facts, without having to get personal or anything. Which leads to a much better discussion and altogether atmosphere.
Scali is offline   Reply With Quote
Old 18-Aug-2008, 16:52   #16
AlexV
Heteroscedasticitate
 
Join Date: Mar 2005
Posts: 2,433
Default

Learn German, it's good for you:

http://www.pcgameshardware.de/aid,63...MD_und_Nvidia/

And while you're at it, study manners too, no one screamed at you so stop acting like a butthurt nubile. I have about 0 interest in your person, I was merely addressing a statement which is false, if stated as an absolute, as it suggests inner knowledge that you lack (knowledge of what IHVs are doing).
__________________
Donald Knuth: Science is what we understand well enough to explain to a computer. Art is everything else we do.
AlexV is offline   Reply With Quote
Old 18-Aug-2008, 16:57   #17
tabs
Senior Member
 
Join Date: Jan 2007
Location: UK
Posts: 1,255
Default

Double post

Last edited by tabs; 18-Aug-2008 at 17:04.
tabs is offline   Reply With Quote
Old 18-Aug-2008, 17:03   #18
tabs
Senior Member
 
Join Date: Jan 2007
Location: UK
Posts: 1,255
Default

@suryad - Microstuttering != Visible stutters.

Microstuttering causes the viewer to perceive lower framerates than what's rendered, and cant be confused with the usual stuttering, which is the plainly visible hitching, or pausing (no matter how brief) he might get from HD activity or having his settings too high.

You cant *see* microstuttering. You only get the impression of lower FPS.
tabs is offline   Reply With Quote
Old 18-Aug-2008, 17:05   #19
Arwin
Now Officially a Top 10 Poster
 
Join Date: May 2006
Location: Maastricht, The Netherlands
Posts: 14,912
Default

Quote:
Originally Posted by Morgoth the Dark Enemy View Post
Learn German, it's good for you:

http://www.pcgameshardware.de/aid,63...MD_und_Nvidia/

And while you're at it, study manners too, no one screamed at you so stop acting like a butthurt nubile. I have about 0 interest in your person, I was merely addressing a statement which is false, if stated as an absolute, as it suggests inner knowledge that you lack (knowledge of what IHVs are doing).
Actually, your manners aren't perfect either.

Also, more people would be better off if all good articles on the web are written in English, don't you think?

Und ich sage das hier nur weil ich selbst auch Deutch lesen kann (schreiben aber ...), und schon weiss das es sehr viel gutes uber ICT zum lesen gibt auf Deutch - ich bin ja schon sehr länge ein 'Fan' von das Deutsche C't Magazin gewesen.
Arwin is offline   Reply With Quote
Old 18-Aug-2008, 17:12   #20
Scali
Naughty Boy!
 
Join Date: Nov 2003
Posts: 2,127
Send a message via ICQ to Scali Send a message via MSN to Scali
Default

Quote:
Originally Posted by Morgoth the Dark Enemy View Post
Learn German, it's good for you:

http://www.pcgameshardware.de/aid,63...MD_und_Nvidia/

And while you're at it, study manners too, no one screamed at you so stop acting like a butthurt nubile. I have about 0 interest in your person, I was merely addressing a statement which is false, if stated as an absolute, as it suggests inner knowledge that you lack (knowledge of what IHVs are doing).
Quote:
Das Einteilen dieser Frames (bzw. der command buffer) wird zumindest unter Vista vom Kernel übernommen, das heisst dieses Verhalten kann auch über den Treiber nicht beeinflusst werden.
Unless my German fails me (which it doesn't, since us Dutch people bother to learn other languages in school), they claim that the driver cannot fix the issue and put responsibility under the Vista kernel.
Sounds like denial to me.
In fact, they actually admit that they go for maximum framerate, because they believe that this is what the user wants.

nVidia says no more than that they're 'investigating the issue'.

Also, I still say it's extremely poor form to just shout "You're wrong". You could have posted the link right away, at least you'd have something to back up your disagreement, even though it doesn't quite disprove what I said.
Aside from the fact ofcourse that I was referring to official statements, which can never be 'inner knowledge' by default.
Scali is offline   Reply With Quote
Old 18-Aug-2008, 19:56   #21
Humus
Crazy coder
 
Join Date: Feb 2002
Location: Stockholm, Sweden
Posts: 3,217
Send a message via ICQ to Humus Send a message via MSN to Humus
Default

Quote:
Originally Posted by Davros View Post
doesnt vysnc fix micro stuttering ?
Quote:
Originally Posted by digitalwanderer View Post
Unfortunately no.
It should, as long as you're hitting a framerate that's consistently above the refreshrate of the monitor. If you're using double buffering there should also not be any micro-stuttering if you're going at less than the refreshrate, although you'll instead get the framerate capped very low of course. If you're using triple-buffering and the framerate is lower than the refreshrate you'll get micro-stuttering even on single GPU setups. Interestingly enough, I don't think I've ever heard anyone complain about that. Although in that case you'd see it jump between 16ms and 32ms, rather than say between 1ms and 31ms.
__________________
[ Visit my site ]
I speak for myself and only myself.
Humus is offline   Reply With Quote
Old 22-Aug-2008, 13:22   #22
gjaegy
Junior Member
 
Join Date: Mar 2007
Posts: 71
Default

Humus, this is a problem I am very concerned about. I spent hours and hours trying to reduce their effect.

The issue is even more noticeable (if we discuss the same issue) when VSync is on, as frame time keep on changing from 1/60 to 1/30, producing horrible result.

The only way I found to reduce this (with vsync on) is to ensure you write/use the same render target over frame. Some other suggest using queries or locking a rendertarget, causing CPU and GPU to sync.

Moreover, one have to set the "pre-rendered frame" to 0 (NVidia cards, NVidia control panel).

With this method, framerate automatically drops to 30Hz instead of varying between 60Hz and 30Hz, producing much smoother results.

The disadvantage is that you theoretically lost some GPU power, as it gets idle sometimes.

Another issue is that it doesn't work with multi-GPU systems.

I have been in touch with some guys at NVidia, tell them my opinion that they should implement such a feature at the driver level. However, they suggested to render the scene to an offscreen render target and, according to a measured frametime, present this one or several time. computing the frametime is an issue however, as you don't know whether you are CPU or GPU limited.

It turns out to be a real chaos, and customer keep on asking : "why do I see 49 FPS and it looks jerky ? It looks smoother at 30Hz with present interval set to 2 ?! You cheat in your FPS counter !!"
gjaegy is offline   Reply With Quote
Old 22-Aug-2008, 14:02   #23
AlexV
Heteroscedasticitate
 
Join Date: Mar 2005
Posts: 2,433
Default

Quote:
Originally Posted by gjaegy View Post
The issue is even more noticeable (if we discuss the same issue) when VSync is on, as frame time keep on changing from 1/60 to 1/30, producing horrible result.
I'd be interested in seeing this scenario where it changes on a frame by frame basis. Framerate demultiplication with V-sync on is normal fare. Also, a difference of around 16ms in inter-frame delay would be...difficult to perceive by a normal human.
__________________
Donald Knuth: Science is what we understand well enough to explain to a computer. Art is everything else we do.
AlexV is offline   Reply With Quote
Old 22-Aug-2008, 14:14   #24
gjaegy
Junior Member
 
Join Date: Mar 2007
Posts: 71
Default

Not sure I understand correctly, my English is not that great

Let's consider a frame that require 20ms to be computed by a GPU, vsync being on. This means, because of the driver/GPU being 2 or 3 frames ahead, that the frame will be displayed sometimes after 1/60s, sometimes after 2/60s.

The issue is, on the CPU this is not visible, thus the frame delta time will be 20ms, and all animations will be computed according to this time. So delta time is 20ms, but real frame is 16 or 33ms.

Believe me, effect is noticeable.

In that case, if you sync the GPU at the start of each frame and ensure it doesn't compute any frame ahead - actually buffer past frames (i.e. also losing any benefit of asynchronously processing) the framerate will be 30Hz, and the delta time computing on CPU for animation will be 1/30Hz, matching with the real frame delta time => smoothness impression

I guess this will be confusing for some of you, it is very hard to explain actually (and i am quite bad at explaining )

As someone said, it seems vendors are more concerned about FPS than about real smoothness feeling
gjaegy is offline   Reply With Quote
Old 22-Aug-2008, 14:50   #25
zsouthboy
Member
 
Join Date: Aug 2003
Location: Derry, NH
Posts: 563
Default

gjaegy: that's a great explanation of something I've been unable to explain to people who can't see it. your english is fine
zsouthboy is offline   Reply With Quote

Reply

Tags
micro-stutter, stutter

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 11:44.


Powered by vBulletin® Version 3.8.6
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.