[AnandTech] AMD Comments on GPU Stuttering, Offers Driver Roadmap

[tbone8ty]

Malta

http://wccftech.com/amd-unveils-rade...-gpu-gdc-2013/

[Hell Hound]

I can tell the diff and + ID TECH lets you adjust frame time.

[cobra_kai]

http://www.anandtech.com/show/6862/f...marking-part-1

Looks like nVidia is taking the lead on new benchmarking tools, probably because right now they have the lead when it comes to stuttering

[BababooeyHTJ]

Hopefully they get it sorted by the time the 8 series comes out, i just seem to have a nose for skipping the problems and jumping in at the right time, a big tech change, avoid the first round.

As far as single gpus go AMD's 7xxx series seem to be far more consistent with frame latency than past cards. Older techreport reviews seem make that case anyways.

Microstutter has always been an issue. I'm super glad that AMD is finally attempting to do something about it.

[STEvil]

http://www.anandtech.com/show/6862/f...marking-part-1

Looks like nVidia is taking the lead on new benchmarking tools, probably because right now they have the lead when it comes to stuttering

What lead? Its a poorly written tool that doesnt take the full render path (let alone the rest of the system) into account.

[cobra_kai]

What lead? Its a poorly written tool that doesnt take the full render path (let alone the rest of the system) into account.

I'm not sure I follow. From what I understand it is directly recording the output from the video card in order to look at the amount of time between frames. It seems to me that the point is to ignore everything that comes in front and focus only on the frame times that the end user sees. I can't speak to the analysis tools but from a characterization of stutter that a user experiences what would be a better approach?

[Final8ty]

As far as single gpus go AMD's 7xxx series seem to be far more consistent with frame latency than past cards. Older techreport reviews seem make that case anyways.

Microstutter has always been an issue. I'm super glad that AMD is finally attempting to do something about it.

How can you be confused when my comment was clearly in regards to my use which is multi GPU.

[Glow9]

Cliffs:
We realize there is a problem, it will eventually go away like our mouse bug.
DX9 has been around for 10 years but we still can't produce drivers that will get our hardware to work properly
Many DX10 titles are on the way! Stay tuned for more crappy driver releases.
Give us your money cause we reassured you stupid consumers.

[BababooeyHTJ]

How can you be confused when my comment was clearly in regards to my use which is multi GPU.

Its not like AMD's older series are performing any better in terms of microstutter.

[Hell Hound]

Start @ 3.MIN

[Rollo]

What does the carmack interview have to do with the topic?

NVIDIA parts/drivers have worked out ways around the problems Carmack mentions with drivers and DX and AMD is starting to do the same.

[Hell Hound]

read thread,

Desktop computing is not mission critical and never will be aka the average users isn't interested in the possibility that one task is done under certain latency limitations, to make the one task run as low latency as possible, but many task are done in a fashion that work without noticeable perceived latency.

He talked about latency issue,and having over spec hardware struggling compared to consoles.It is really noticed on console based games like sega rally revo,that thing skips w/o crossfire.

From you

Got to disagree there. How many years has it been going on and now they come clean when they have the problem largely fixed for single cards and a fix 4 months out for CFx

Video is couple of yrs old,they know but haven't fixed it yet and just now making a push.

The main thing he said is drivers are his concern,I think it relates to thread.

[Final8ty]

Its not like AMD's older series are performing any better in terms of microstutter.

The 6 series had worse stuttering than the 5 series and when it comes to quadfire which i use the 7 series has a lot more issues, even tri fire 7 series has more issues, i have never had to disable ULPS.

[STEvil]

I'm not sure I follow. From what I understand it is directly recording the output from the video card in order to look at the amount of time between frames. It seems to me that the point is to ignore everything that comes in front and focus only on the frame times that the end user sees. I can't speak to the analysis tools but from a characterization of stutter that a user experiences what would be a better approach?

Exactly, it ignores the entirety of the rest of the issue. You can fix your drivers all you want but if the problem lies outside of the render calls (HT, core parking) there's not much you can do and relying only on this method may produce flawed results.

An example of a possible flawed result is the runt frames. Given the numbers that have been shown they dont all seem to line up as being what we've been told they are (all of the time).

[zir_blazer]

Exactly, it ignores the entirety of the rest of the issue. You can fix your drivers all you want but if the problem lies outside of the render calls (HT, core parking) there's not much you can do and relying only on this method may produce flawed results.

Issues like that would probabily affect both SLI and Crossfire in the same way. Yet Crossfire has some serious issues that SLI doesn't have, so its the Crossfire implementation the one that is to blame considering that SLI scales quite good.

There is always, everywhere, people complaining about certain graphic glitchs, slowdowns, shuttering, whatever. What you see is what matters, end users usually doesn't really care about the inner workings of it for as long as it works properly. This technique to focus on the graphic output is what will help the most to properly see and identify all those issues, as with it you don't depend on a person perception to detect them (Not everyone notices), and get into a more scientific, exact method. Once you know that there is an issue somewhere, then you could use even more tools to properly identify what happens at the moment that the glitch/shutter occurs, to know what is the actual cause (Hardware, OS, Drivers, whatever), and try to fix it.
I'm very optimistic that with ths method, it will be posible to do before-and-after comparisions so you can see if an specific option (Like VSync), a new Drivers version, Software patch, or anything else, has a positive or negative impact. So it will be trackeable if there are actual improvements.

[STEvil]

Issues like that would probabily affect both SLI and Crossfire in the same way. Yet Crossfire has some serious issues that SLI doesn't have, so its the Crossfire implementation the one that is to blame considering that SLI scales quite good.

They can as seen in some HT vs non-HT results, however "can" is not "always".

There is always, everywhere, people complaining about certain graphic glitchs, slowdowns, shuttering, whatever. What you see is what matters, end users usually doesn't really care about the inner workings of it for as long as it works properly. This technique to focus on the graphic output is what will help the most to properly see and identify all those issues, as with it you don't depend on a person perception to detect them (Not everyone notices), and get into a more scientific, exact method.

Why is this method the most correct? Why cant another method which is not using visual perception work as well or better, given that it may actually also include this method as well as others? Why is one method which performs only one test better than multiple methods which test multiple issues?

You've basically jumped off an assumption cliff with your line of reasoning..

Once you know that there is an issue somewhere, then you could use even more tools to properly identify what happens at the moment that the glitch/shutter occurs, to know what is the actual cause (Hardware, OS, Drivers, whatever), and try to fix it.
I'm very optimistic that with ths method, it will be posible to do before-and-after comparisions so you can see if an specific option (Like VSync), a new Drivers version, Software patch, or anything else, has a positive or negative impact. So it will be trackeable if there are actual improvements.

So you cant use other methods in your previous statement but then you suddenly can in the next? Hmm.. seems you've cliff jumped before if you're going to bring a parachute

[CrimInalA]

good article , very interesting .
Thumbs up AMD for admintting this issue (finally) .

[zir_blazer]

Why is this method the most correct? Why cant another method which is not using visual perception work as well or better, given that it may actually also include this method as well as others? Why is one method which performs only one test better than multiple methods which test multiple issues?

I don't know if "visual perception" is actually the correct name for it, but I'm referring to the same thing responsible that not everyone notices motion the same, or is sensible at the same degree. Some people is more sensitive and notice shuttering or tearing where you wouldn't notice anything, in the same way that some people couldn't notice the difference during the CRT era of playing a game @ 75 Hz or @ 100 Hz assuming that you had enough Hardware to draw all the frames flawlessly - the frames are there, but not everyone notices them. Its basically what AMD said in the first Anandtech article:

In our discussion with AMD, AMD brought up a very simple but very important point: while we can objectively measure instances of stuttering with the right tools, we cannot objectively measure the impact of stuttering on the user. We can make suggestions for what’s acceptable and set common-sense guidelines for how much of a variance is too much – similar to how 60fps is the commonly accepted threshold for smooth gameplay – but nothing short of a double-blind trial will tell us whether any given instance of stuttering is noticeable to any given individual.

As you're recording the output of the GPU, that is what would be displayed in the Monitor, you could analyse frame by frame to check for inconsistency. You don't rely anymore on someone's visual perception/sensivity for motion, as you have proper tools to check for it. Maybe a guy doesn't notice the effect of tearing due a runt frame like this one (From here), but that frame WAS on screen for a few miliseconds.

If you have any doubts, you can as well re-read all the, Tech Report, PCPer and Anandtech articles about this matter and why they're using this new method.

You've basically jumped off an assumption cliff with your line of reasoning..

So you cant use other methods in your previous statement but then you suddenly can in the next? Hmm.. seems you've cliff jumped before if you're going to bring a parachute

You have both AMD and nVidia reasons about why the other current method to detect frame delay, FRAPS, isn't accurate enough, and why reviewers have gone thorough this and this to set up for this new method of analyzing the direct output.

If you don't like it, I'm sure there are many people besides myself that would die to know what method you have in mind that is better or more correct.
Should I give you my parachute?

[cobra_kai]

Why is this method the most correct? Why cant another method which is not using visual perception work as well or better, given that it may actually also include this method as well as others? Why is one method which performs only one test better than multiple methods which test multiple issues?

I very much agree with this statement. I sure there can be, and probably will be, other tools in the future that give even deeper insight into the rendering pipeline and what effects each part of the system is having. However, for the near term I think this is a very large step forward from solely using FRAPS as a benchmarking tool and helps explain a lot of what people were complaining about but unable to show from FRAPS results.

[Rollo]

read thread,
He talked about latency issue,and having over spec hardware struggling compared to consoles.It is really noticed on console based games like sega rally revo,that thing skips w/o crossfire.

From you

Video is couple of yrs old,they know but haven't fixed it yet and just now making a push.

The main thing he said is drivers are his concern,I think it relates to thread.

My bad, I missed your point. It's a good explanation of why stuttering exists in pc gaming and why companies need to work around it. I thought you were trying to illustrate the latency and stutter "have" to exist in pc gaming, when NVIDIA has apparently figured out a way around it and AMD is well into the process.

I see this issue as a good thing for pc gaming in general. PCs have always had the advantage for resolution and image enhancement, if all graphics solutions deliver smooth animation it can only be good for the industry.

[Stukov]

If anyone is interested, over at Guru3D, Hilbert has been working on a splitter and frame capture device/system (right before it goes to the screen) he bought some serious hardware for it but is running into the issue of a storage system that can record the high write speeds without dropping frames.

[STEvil]

I don't know if "visual perception" is actually the correct name for it, but I'm referring to the same thing responsible that not everyone notices motion the same, or is sensible at the same degree. Some people is more sensitive and notice shuttering or tearing where you wouldn't notice anything, in the same way that some people couldn't notice the difference during the CRT era of playing a game @ 75 Hz or @ 100 Hz assuming that you had enough Hardware to draw all the frames flawlessly - the frames are there, but not everyone notices them. Its basically what AMD said in the first Anandtech article:



As you're recording the output of the GPU, that is what would be displayed in the Monitor, you could analyse frame by frame to check for inconsistency. You don't rely anymore on someone's visual perception/sensivity for motion, as you have proper tools to check for it. Maybe a guy doesn't notice the effect of tearing due a runt frame like this one (From here), but that frame WAS on screen for a few miliseconds.

If you have any doubts, you can as well re-read all the, Tech Report, PCPer and Anandtech articles about this matter and why they're using this new method.



You have both AMD and nVidia reasons about why the other current method to detect frame delay, FRAPS, isn't accurate enough, and why reviewers have gone thorough this and this to set up for this new method of analyzing the direct output.

If you don't like it, I'm sure there are many people besides myself that would die to know what method you have in mind that is better or more correct.
Should I give you my parachute?

No, I think your post demonstrates you still need it as you seem to think everything i've said was only about utilizing only visual perception (when in fact I said to use pretty much any method other than) to diagnose the issue.