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

[SolMiester]

From the article, it sounds like most issues that AMD had with single-GPU stuttering have been rectified and the remaining issues aren't that big.

"There is still work to do – AMD quickly fixed their DX9 issues, while DX10 fixes are in the process of being rolled out – but in many ways this is a post-mortem on the issue rather than being an explanation of what AMD will do in the future. Not every game is fixed yet, but many are. Scott Wasson’s most recent results show an incredible improvement for AMD compared to where they were even 6 months ago."

Nvidia just recently fixed some stuttering issues as well so I don't think there's much difference on the single-GPU front. Sounds like AMD multi-GPU setups still need some work though (although I haven't noticed any serious MS).

But for how long have the AMD cards had the sGPU issues...?, Lava was talking about his old 4 & 3 series
But of course we couldnt debate the AMD issues without a fanboi coming in to muddy the waters..
This is yet another issue of AMD getting it wrong, remember when Anand talked about AMD monthly drivers a the 2 sets of games they tested with...I month they fixed something, but broke it with the next months release!....7 series CF eyefinity was borkered for about 8mths before they released another driver that worked, then its sGPU stutter & runt frames, and of course CF stutter...is it any wonder AMD get a hard time about their drivers...
Ill say it again, the 7 series has turned out to be a great piece of hardware, unfortunately, the AMD software team has let them down....again!

 

[Will Robinson]

@Solmiester

But of course we couldnt debate the AMD issues without a fanboi coming in to muddy the waters..

Coming from someone who is a deeper shade of green than Kermit the Frog I find that comment amusing....:whiste:

 

[Imouto]

@SolMiester Looks like you didn't read the article at all. Both Nvidia and AMD had these issues.

You've been playing with this issue since the very beginning. Every single card before Kepler had this issue. Anyway you can check a handful of TR reviews to check that the issue was present in Fermi cards too. Get that into your skulls already.

 

[Grooveriding]

There are similar measurements of nvidia fermi 5XX & 4XX series cards where the supposed 'stuttering measurements' are worse than anything on current nvidia 6XX or AMD 7XXX. That really says it all for single cards considering how many of us used those Fermi cards and never noticed that, the same way I see nothing of the sort on my 7950.

Re-read Ryan's article and read what is partially said but not fully. The majority of the hoopla was nvidia trying to push this around because they were losing the framerate metric and wanted something else measured where they would look better.

Never mind all the insight into just how much is involved between the frame coming from the application, through Windows, the API, the GPU, buffers and then to your screen. Put to bed all the guesswork and nonsense being tossed around prior.

 

[BallaTheFeared]

Did they address pcper's CF results, which were based on capturing the output at the display rather than within the render pipeline?

I know AMD acknowledged the frame time issue awhile ago, and I saw improvements pretty quickly which is why I took the leap for the 7950, but I'm a dual+ card kind of guy... What was said about missing/runt frame output for CF?

 

[notty22]

Quote from 'final words'

Ultimately AMD’s message has been one of information, explanation, and admission of oversight. AMD has been clear with us from the start that the primary reason they even ended up in this situation is because they weren’t doing sufficient competitive analysis, and that they have revised their driver development process so that they now do this analysis to prevent future problems. The fact that NVIDIA seemed to have figured all of this out much earlier was a point of frustration for AMD. The company likely left non-negligable amounts of performance on the table over the years, which could've definitely helped in close races.
At the same time they’ve been hard at work on fixing existing stuttering problems, with many of those fixes being delivered while fixes for more DX10+ games are right around the corner.
At the same time however AMD’s message is not just one about stuttering, but also one about benchmark and analysis methods with FRAPS. FRAPS, despite its limitations, has clearly exposed problems with AMD’s drivers that resulted in stuttering that AMD needed to fix. Meanwhile measuring frame intervals with FRAPS has become an increasingly common technique in reviews, only to really become popular at the same time as when AMD has finally fixed many of these issues.
AMD’s concern – and one that NVIDIA has shared with them in the past – is that measuring the rendering pipeline at the beginning of the pipeline like FRAPS goes about it does not accurately represent what the end user is seeing, due to the various buffers in the Pipeline and how the Present mechanism works. While FRAPS was good enough to pick up on the major stuttering issues in AMD’s drivers, as these issues get resolved it’s far too coarse a tool to pick up on finer issues, and in fact what FRAPS is now seeing is decoupled from what the user is seeing due to the presence of the context queue and other buffers.

There's also credit to Nvidia for pointing out stuttering, and being pro-active to fix it.
Which is where AMD is supposedly at /heading to.

 

[SolMiester]

@Solmiester

Coming from someone who is a deeper shade of green than Kermit the Frog I find that comment amusing....:whiste:

The quote was about fanbois coming in to disrupt the discussion about AMD issues, not qualifying them to NV, which is where the bickering starts!..I have never hidden my preference to NV...Thats like saying because I prefer steak, I cant discuss chicken FFS...

 

[SolMiester]

@SolMiester Looks like you didn't read the article at all. Both Nvidia and AMD had these issues.

You've been playing with this issue since the very beginning. Every single card before Kepler had this issue. Anyway you can check a handful of TR reviews to check that the issue was present in Fermi cards too. Get that into your skulls already.

I did read the article, though I skimmed some stuff, where does it say NV has these issues?, AFAIK, NV put in place the hardware frame sync or whatever with Fermi

 

[Wall Street]

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.

The point that the article was making is that FRAPS doesn't measure frames output to the screen, which is completely different from saying FRAPS is useless. FRAPS is still useful for three reasons:

1. Stutters in frame present calls, while not representing when the actual buffers are flipped, do appear highly correlated with the final frame outputs. Look at the PCPER articles, the games that have a very long frame time followed by a very short frame time do show up as very long frames followed by very short frames in their analysis. It is like saying that goals doesn't have anything to do with wins in sports - the two may not be the same but are highly correlated.

2. Internally, the game engine uses the time between present calls to determine how far to move the animation forward each frame. As addressed in the article, staggered present calls can cause jerky animation even if the frame buffers a not flipped in a staggered manner.

3. As pointed out from the Microsoft GPUView utility, stuttered present calls can cause game pipeline stalls where no work is getting done. Even if the frames are rendered smoothly but the acceptance of the present calls is stuttered, this created performance issues as some game engines cannot move on to other tasks until the frame is handed over to the GPU.

 

[Rvenger]

Did they address pcper's CF results, which were based on capturing the output at the display rather than within the render pipeline?

I know AMD acknowledged the frame time issue awhile ago, and I saw improvements pretty quickly which is why I took the leap for the 7950, but I'm a dual+ card kind of guy... What was said about missing/runt frame output for CF?

13.2 Beta 7 on 2x 7970s @ 1080p vsync enabled were very stuttery. Hence my sig change.

 

[Elfear]

But of course we couldnt debate the AMD issues without a fanboi coming in to muddy the waters..

I sure came across as a huge fanboi didn't I.

 

[hansmoleman8]

Generally pointless and inconclusive article. Anandtech stopped using fraps and frametime, but continues to use outdated "average" frame rate as a metric.

Other sites show min, and average fps, or frametimes. Or an fps over time graph for the length of the playthrough / demo (hardocp).

This just smells like a 'business decision'.

 

[blackened23]

Generally pointless and inconclusive article. Anandtech stopped using fraps and frametime, but continues to use outdated "average" frame rate as a metric.

Other sites show min, and average fps, or frametimes. Or an fps over time graph for the length of the playthrough / demo (hardocp).

This just smells like a 'business decision'.

Oh neat, you didn't read the article.

 

[hansmoleman8]

Oh neat, you didn't read the article.

Oh sorry, anandtech is best and will never sell out. :whiste:

And an AMD company rep will always tell the whole truth...:whiste:

And using the same tools on the same system, with different GPUs is totally an invalid test....because AMD looks bad :whiste:

 

[blackened23]

Oh sorry, anandtech is best and will never sell out. :whiste:

And an AMD company rep will always tell the whole truth...:whiste:

And using the same tools on the same system, with different GPUs is totally an invalid test....because AMD looks bad :whiste:

Oh, thanks for registering today to tell us this. Nothing going on there i'm sure. Anyway, all the points you brought up were addressed in a reasonable fashion. Perhaps you should read the bits about how FRAPs is ultimately flawed for testing purposes.

 

[hansmoleman8]

Oh, thanks for registering today to tell us this. Nothing going on there i'm sure.

Oh my opinions are totally invalid because i registered today.

They are when you're a returning banned member.
admin allisolm

They have changed how they develop their drivers, how they do competitive analysis, and how they look at stuttering and frame intervals in games. And they’re not done. They’re already working on changing how they do frame pacing for multi-GPU setups, and come July we’re going to have the chance to see the results of AMD’s latest efforts there.

Oh this is totally not free PR for AMD...:whiste:

Anyway, all the points you brought up were addressed in a reasonable fashion. Perhaps you should read the bits about how FRAPs is ultimately flawed for testing purposes.Perhaps you should read the bits about how FRAPs is ultimately flawed for testing purposes.

Perhaps you should think for yourself. Same tools, same system, different GPU. Objective results. Whether or not the results are "noticeable" is not the point.
If we're talking about stuff being "noticeable", why have GPU reviews at all? Is 75 fps more "noticeable" than 60 fps (constant fps). No because 15 of those frames are discarded and never drawn....

 

[zebrax2]

Oh this is totally not free PR for AMD...:whiste:

A review sites purpose is to provide information. Sometimes information may look like free PR but that is OK; depriving the readers of useful information like in that case, when will the driver that will address some of CFs problem will be available to users, to me is a graver sin.

 

[blackened23]

Perhaps you should think for yourself. Same tools, same system, different GPU. Objective results. Whether or not the results are "noticeable" is not the point.
If we're talking about stuff being "noticeable", why have GPU reviews at all? Is 75 fps more "noticeable" than 60 fps (constant fps). No because 15 of those frames are discarded and never drawn....

You really didn't read the article. The fact that latency is an issue was not a point of contention. It exists. The interesting tidbit from the article, however, is that FRAPs does all latency measurements before anything even hits the render pipeline. FRAPs measures latency before the GPU driver actually does anything. The GPU driver doesn't touch it if latency is measured before the render pipeline. Now if you wanna keep blabbing despite that fact, have at it.

This actually goes a long way towards describing why results at different websites are so varied EG tomshardware. Because FRAPs doesn't measure it properly. Even nvidia agrees that FRAPs is flawed in this respect. Again. You didn't read the article. By all means keep doing what you're doing though.

 

[Avalon]

Fixin time!

 

[3DVagabond]

Oh this is totally not free PR for AMD...:whiste:

I'm not sure how you interpret this, but I interpret it as, "If you want dual GPU don't buy AMD right now." The only good PR for AMD is that they are saying there is an issue. Not trying to deny anything.

 

[Silverforce11]

The point that the article was making is that FRAPS doesn't measure frames output to the screen, which is completely different from saying FRAPS is useless. FRAPS is still useful for three reasons:

1. Stutters in frame present calls, while not representing when the actual buffers are flipped, do appear highly correlated with the final frame outputs. Look at the PCPER articles, the games that have a very long frame time followed by a very short frame time do show up as very long frames followed by very short frames in their analysis. It is like saying that goals doesn't have anything to do with wins in sports - the two may not be the same but are highly correlated.

2. Internally, the game engine uses the time between present calls to determine how far to move the animation forward each frame. As addressed in the article, staggered present calls can cause jerky animation even if the frame buffers a not flipped in a staggered manner.

3. As pointed out from the Microsoft GPUView utility, stuttered present calls can cause game pipeline stalls where no work is getting done. Even if the frames are rendered smoothly but the acceptance of the present calls is stuttered, this created performance issues as some game engines cannot move on to other tasks until the frame is handed over to the GPU.

These are issues with the actual game itself and how it interfaces with windows, if these problems do occur because of poor game engines it will rear its ugly head on all hardware, ie. Far Cry 3 unpatched.

The problem with all the FRAPs usage by review sites up to now, is they blame it on the hardware when they see funny charts, or they correlate it automatically to smoothness for users when in fact its wrong. TR's original article even says why its wrong, because they had a wacky frame time chart for radeons in BF2:BC compared to nvidia, but they played the level and it felt "smoother" on the radeon.. so its about lazy reviewers letting these benches run without sitting down to "play" it then misinterpreting the results.

 

[ICDP]

Not with single GPU stuttering they dont.....guess that deflates your e-peeny somewhat eh?..why else would you make this an us v them issue?

First 4 months of the GTX680 were plagued by stuttering for many people when Vsync was enabled. Review sites didn't comment because they never test with vsync on.

I had a GTX 680 from release until last month and suffered with this "bug" for a long time. The only solution was to disable vsync and live with excessive tearing.

https://forums.geforce.com/default/...osts-will-be-deleted-vsync-stutter-discussi/1

Search google for Kepler Vsync Stutter to see the extent of the problem.

 

[Imouto]

I did read the article, though I skimmed some stuff, where does it say NV has these issues?, AFAIK, NV put in place the hardware frame sync or whatever with Fermi

From the article:

The fact that NVIDIA seemed to have figured all of this out much earlier was a point of frustration for AMD.

+

Old Fermi reviews at TR.

http://techreport.com/review/22048/today-mid-range-gpus-in-skyrim
http://techreport.com/review/22151/nvidia-geforce-gtx-560-ti-448-graphics-card
http://techreport.com/review/21982/today-mid-range-gpus-in-battlefield-3

 

[BFG10K]

This actually goes a long way towards describing why results at different websites are so varied EG tomshardware. Because FRAPs doesn't measure it properly.

No, the results are different because websites generally test differently. Most of the time they run custom benchmarks, so they aren’t even testing the same parts of the game.

Even if FRAPs isn’t accurate, it would still produce the same numbers across different systems, providing the benchmarks and settings were identical. But they aren’t, and that’s why Tom’s Far Cry 3 results will never match Anand’s or TR’s (for example), no matter what tool they use for measurement.

My take on this whole issue:

FRAPS, while not perfect, is still accurate for representing gameplay. There might be outliers of course, but generally speaking it’s pretty close to games’ internal framerate counters, and it does pick up fluctuations that are noticeable in actual gameplay.

So I definitely think AMD has issues with an irregular framerate compared to nVidia.

The real problem here isn’t FRAPS. It’s input lag, which can’t be reliably tested externally. I can produce a perfectly flat framerate line using frame smoothing/buffering, but it would be absolutely horrific for gameplay. That’s the danger if these companies (and game engines) start going out of their way to make flat lines at the expense of everything else.

So to put it in simple terms: just because your graph is flatter, it doesn’t necessarily mean the gameplay is better.

 

[Silverforce11]

The real problem here isn’t FRAPS. It’s input lag, which can’t be reliably tested externally. I can produce a perfectly flat framerate line using frame smoothing/buffering, but it would be absolutely horrific for gameplay. That’s the danger if these companies (and game engines) start going out of their way to make flat lines at the expense of everything else.

So to put it in simple terms: just because your graph is flatter, it doesn’t necessarily mean the gameplay is better.

And AMD driver engineers specifically said they focus on reducing overall latency (input lag) rather than go after frame interval smoothness. But at least they will offer the option in their drivers for users to pick which they prefer, more choices, good.