AMD Comments on GPU Stuttering, Offers Driver Roadmap & Perspective on Benchmarking

[VulgarDisplay]

Its already been pointed out at least a dozen times, using v-sync causes other issues, and is a bandage, not a fix!

Honestly, nvidia's frame metering sounds like it's a bandaid too. From the bits and pieces about it in the article it sounds like it creates input lag also. Maybe not as much as vsync? Either way, AMD said that they plan on having that functionality in their upcoming drivers. You can choose to smooth out distribution and increase input lag, or not.

 

[Mistwalker]

How did AMD's stuttering mess get to be about FRAPS?

Nice red herring...

Did you even read the article?

FRAPS is mentioned some 75 times. It's entirely relevant.

The truth is that Nvidia and AMD simply think FRAPS is not always accurate and not always the correct tool to use. I commend Nvidia for developing the new method that give us more tools to measure even more performance metrics. I also commend the fact that AMD have finally (after over a year) admitted that Crossfire causes serious stutter/FPS problems out of the box.

Totally agree with this.

 

[ICDP]

How did AMD's stuttering mess get to be about FRAPS?

Nice red herring...

Please explain it for me?

FRAPS showed AMD has some serious issues.
More advanced tools confirms this.

Now why the foucs on FRAPS...and not AMD's stuttering issues?

The truth is that Nvidia and AMD simply think FRAPS is not always accurate and not always the correct tool to use. I commend Nvidia for developing the new method that give us more tools to measure even more performance metrics. I also commend the fact that AMD have finally (after over a year) admitted that Crossfire causes serious stutter/FPS problems out of the box.

This was my final paragraph in the post above this one from you. Can you see where I mention that AMD finally got around to admitting that CF is a stuttering mess? Can you see where I mentioned FRAPS without claiming in is totally useless? Not always accurate, but that is not the same as worthless.

The original article is about FRAPS, Stuttering and why AMD don't think FRAPS is always accurate. Now ask again why we are mentioning FRAPS and stuttering in a thread devoted to an article that is devoted to FRAPS and stuttering... oh right

 

[Lonbjerg]

This was my final paragraph in the post above this one from you. Can you see where I mention that AMD finally got around to admitting that CF is a stuttering mess? Can you see where I mentioned FRAPS without claiming in is totally useless? Not always accurate, but that is not the same as worthless.

The original article is about FRAPS, Stuttering and why AMD don't think FRAPS is always accurate. Now ask again why we are mentioning FRAPS and stuttering in a thread devoted to an article that is devoted to FRAPS and stuttering... oh right

You think my posts were soley directed at you...funny...but not true.
Nice red herring though.

 

[ICDP]

You think my posts were soley directed at you...funny...but not true.
Nice red herring though.

You made a general comment on this thread claiming that somehow the entire thread became focused on FRAPS, I responded to it. Nothing more to it than that.

Now what is it you keep saying... oh yeah, nice red herring though.

 

[Arzachel]

Please explain it for me?

FRAPS showed AMD has some serious issues.
More advanced tools confirms this.

Now why the foucs on FRAPS...and not AMD's stuttering issues?

That stupid claim you've made for all these months has been busted already by PCPer findings. GTX 680 and HD 7970Ghz deliver the very same frame times and variances. In fact if you check the review you'll see the HD 7970Ghz ahead in quite a few benches while the GTX 680 can only pull ahead in Far Cry 3 where none of the cards did well.

Also, the article is about the merits of frame time variance benchmarking, what FRAPS is measuring exactly and how representative it is. Feel free to make another thread with FCAT benchmarks, if that is what you wish to discuss. Otherwise, back under the bridge with you.

 

[Imouto]

Now what is it you keep saying... oh yeah, nice red herring though.

That's a nice fallacy.

 

[Rikard]

Vsync is worth at least 16ms latency and jumps from 60 to 30 fps whereas triple buffering in addition adds another 16ms of latency. The human eye can detect 20ms, thus 32ms minimum for triple buffering and sync is unfortunately very noticeable, especially when its tagged onto 16ms of game sim followed by 16ms of render time, 16ms of scan out time and 10ms to get onto the pixels. Dropping 32ms makes a big difference.

Careful here, you are mixing latency with frame intervals. It is true that a human can detect frame intervals of 20 ms, down to 16 ms in ideal conditions. But the detectable latency is about 80 ms. So a situation with ~16 ms frame intervals and ~70 ms latency will feel very smooth and responsive, but in cases which this cannot be obtained you would need to trade one for the other, for example by v-sync. However, even 1 ms latency can be the difference between win and lose for a competitive player, so there are good reasons to reduce latency to values much smaller than what is possible for a human to detect.

 

[BrightCandle]

Careful here, you are mixing latency with frame intervals. It is true that a human can detect frame intervals of 20 ms, down to 16 ms in ideal conditions. But the detectable latency is about 80 ms. So a situation with ~16 ms frame intervals and ~70 ms latency will feel very smooth and responsive, but in cases which this cannot be obtained you would need to trade one for the other, for example by v-sync. However, even 1 ms latency can be the difference between win and lose for a competitive player, so there are good reasons to reduce latency to values much smaller than what is possible for a human to detect.

No actually I am not. I am referring to a figure that John Carmack used as part of his keynote speech talking about VR headsets where he says that latency from input to output greater than 20ms is what causes people to be sick with Virtual Reality. Specifically when you attach the head movements to the game people notice the latency above that obviously. You can of course attack John Carmack's figure if you like, its a bit too round and untested for my liking but I vow to his superior knowledge on the subject seeing as how he did all the testing on latency and explained what is wrong with the pipeline as it stands.

 

[Rikard]

No actually I am not. I am referring to a figure that John Carmack used as part of his keynote speech talking about VR headsets where he says that latency from input to output greater than 20ms is what causes people to be sick with Virtual Reality. Specifically when you attach the head movements to the game people notice the latency above that obviously. You can of course attack John Carmack's figure if you like, its a bit too round and untested for my liking but I vow to his superior knowledge on the subject seeing as how he did all the testing on latency and explained what is wrong with the pipeline as it stands.

I am of course talking about hand-eye coordination, which is what matters to the large majority of computer users. John Carmack is considering another, faster, input method.

 

[BrightCandle]

I am of course talking about hand-eye coordination, which is what matters to the large majority of computer users. John Carmack is considering another, faster, input method.

Excellent I didn't know someone had specifically done a study into this. Link please.

 

[UaVaj]

I hope ppl can stop abusing the usage of FRAPS in future, its a meaningless tool to measure latency or even interval, and has been stated as such since the start (even in TR's original article! "conclusions").. but no, review sites are jumping on the stupid bandwagon.

Point is, if review sites wish to measure "smoothness" (stutters, micro-stutters, input lag, latency etc), dont waste our time unless there's a super speed camera filming the monitor, the final output thats the ONLY relevant factor for users.

you are indeed 100% correct.

do keep in mind garbage in garbage out. if the original frametime (per frap) is already garbage to begin with, can only imagine the processed output, more garbage delivered.

althought frap do not show the whole picture. frap does a damm good job of predicting the end results.

 

[willomz]

Just because FRAPS isn't perfect doesn't mean it should never be used.

If we are saying that only people with FCAT can review graphics cards than that is going to limit the community quite severely. And that isn't even perfect.

And actually in games where there aren't big driver issues then FRAPS is actually very accurate.

Tom's hardware found that in some games (e.g. Crysis 3) FRAPS actaully agreed very closely with FCAT even when there were a lot of dropped/runt frames.

 

[Rikard]

Excellent I didn't know someone had specifically done a study into this. Link please.

The link I was going to give you was dead but you could read this one instead:
http://link.springer.com/article/10.3758/BF03205270
It is really about the time gap between the end of the eye saccade and the onset of hand movement, but it contains more information about response times divided in on set of eye movement etc.

But really, you do not need that level of detail to know that response times for VR is shorter than for mouse+screen. Nerve signals travel at about 70 m/s, and lets say the distance from brain to finger is 1 m, then you get an additional latency of 14 ms. (I wonder if that needs to travel back for feed back that you did indeed move the hand but did not yet see the effect in order to set on motion sickness.)

Why does all this matter? Well, I would like to have hardware that is fast enough that I cannot perceive any latency or frame intervals, but I do not want to pay huge amount of money for performance that I cannot possible perceive. A bit like the magic 60 FPS that most users agree on.

 

[BrightCandle]

The link I was going to give you was dead but you could read this one instead:
http://link.springer.com/article/10.3758/BF03205270
It is really about the time gap between the end of the eye saccade and the onset of hand movement, but it contains more information about response times divided in on set of eye movement etc.

Specifically the paper is about how long it takes a male subject to start to move their eyes and handsin response to a light where they must point to that light. It does not at all look into the relationship of hand eye perception of latency, it looks at eye to hand not hand to eye. This paper does not support your assertion for 80ms perceptible latency. Interesting in itself but not on topic.

We have a lot of people noticing blur differences down below 16ms, we have multiple pro gamers on double blind tests able to detect the difference between 60 and 120hz (which is just 8ms) in blind trials and we have a lot of anecdotal evidence here that tells us that 48ms of latency matters to a lot of people.

Most of us would use vsync if it had no negative impact, but it does, a quite noticeable one.

Techreport released their FCAT data today as well and they have shown that FCAT is producing smoother results than it should do. They have a 50ms spike shown in fraps, that in FCAT is barely a change but in the high speed video its very obvious at normal speeds. Turns out fraps is more accurate at spotting these problems than FCAT. What FCAT has exposed the runt frames issue, but stuttering seems to be better more accurately measured by fraps.

 

[Rikard]

Sorry for digging this up, but Easter holidays happened...

Specifically the paper is about how long it takes a male subject to start to move their eyes and handsin response to a light where they must point to that light. It does not at all look into the relationship of hand eye perception of latency, it looks at eye to hand not hand to eye. This paper does not support your assertion for 80ms perceptible latency. Interesting in itself but not on topic.

That is what I said, and why I asked you to read the article to the end. The article contains relevant information and references to many other scientific studies in this field.

The link I wanted to give you is still dead, but I found this which is anyway more light weight and more suitable to a forum discussion: http://youtu.be/BTOODPf-iuc So yes, 80 ms is the perceptible latency (but that the subjects height matters was news to me!)

We have a lot of people noticing blur differences down below 16ms,

...because the response time of the eye is ~10 ms. Remember people complaining about blur when moving from CRT to LCD? Remember those BenQ LCDs with black image insertion? That is why. It has very little to do with perceived latency that we are discussing here.

we have multiple pro gamers on double blind tests able to detect the difference between 60 and 120hz (which is just 8ms)

Yes, because there is always some variation in the frame interval:
http://forums.anandtech.com/showthread.php?t=2304959&highlight=
By using a 120 Hz screen you can reduce the effect of imperfections apparent on a 60 Hz screen. It does not mean that you can see faster than 60 fps...

we have a lot of anecdotal evidence here that tells us that 48ms of latency matters to a lot of people.

I prefer to believe half a century of scientific research, thank you.

Most of us would use vsync if it had no negative impact, but it does, a quite noticeable one.

I agree.

Techreport released their FCAT data today as well and they have shown that FCAT is producing smoother results than it should do. They have a 50ms spike shown in fraps, that in FCAT is barely a change but in the high speed video its very obvious at normal speeds. Turns out fraps is more accurate at spotting these problems than FCAT. What FCAT has exposed the runt frames issue, but stuttering seems to be better more accurately measured by fraps.

How can something that does not measure what the user is exposed to be more accurate than another method that does measure what the user is exposed to? That makes no sense. You also said earlier that Fraps does not produce false positives, but I can give you a trace later where 2 s frame intervals were recorded that I assure did not manifest on screen. I just wish I had recorded it so you could see for yourself.

 

[deathBOB]

How can something that does not measure what the user is exposed to be more accurate than another method that does measure what the user is exposed to? That makes no sense. You also said earlier that Fraps does not produce false positives, but I can give you a trace later where 2 s frame intervals were recorded that I assure did not manifest on screen. I just wish I had recorded it so you could see for yourself.

The frame was rendered on time (due to buffering by the graphics card), but the content of the frame was delayed, as identified by FRAPS. Watch the video and read the explanation: http://techreport.com/review/24553/inside-the-second-with-nvidia-frame-capture-tools/6

 

[UaVaj]

Yes, because there is always some variation in the frame interval:
http://forums.anandtech.com/showthread.php?t=2304959&highlight=
By using a 120 Hz screen you can reduce the effect of imperfections apparent on a 60 Hz screen. It does not mean that you can see faster than 60 fps...

:thumbsup::thumbsup:

now see how well the fps folks takes that into consideration with machine eyes.

 

[bystander36]

Honestly, nvidia's frame metering sounds like it's a bandaid too. From the bits and pieces about it in the article it sounds like it creates input lag also. Maybe not as much as vsync? Either way, AMD said that they plan on having that functionality in their upcoming drivers. You can choose to smooth out distribution and increase input lag, or not.

The reality is that the input lag induced is infrequent and actually makes it more consistent between inputs.

In a perfect world, where both cards rendered their frames exactly the same pace, then once you offset the cards render times, no more adjustments would be required. However, there is still going to be some variation, so there will be occasional delays needed to keep them in line, but the delays only happen if it renders faster than the other card had, so all it does is add a little latency to make it consistent.

Consistent latency may be better than inconsistent latency, and as a result of getting them evenly spaced out, you also get consistent input intervals, which also matters.