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

[zebrax2]

http://www.anandtech.com/show/6857/amd-stuttering-issues-driver-roadmap-fraps

A very informative read. Kudos to Ryan Smith and Anandtech.

The issue did not only help improve the user experience but in the end turned out to be a blessing in disguise for AMD.

I'm looking forward to the next article discussing the tools Anandtech would be using

 

[Erenhardt]

I dunno... but if you had a device that captures signal between GPU and display, then you could measure exactly frametime on the display. (I don't know shit about display signal )

 

[tonyfreak215]

You mean something like this?

http://www.leobodnar.com/shop/index.php?main_page=product_info&cPath=89&products_id=212

nvm...different type...

 

[Jaydip]

Except for horrible editing the article has a big caveat.If fraps is wrong it shouldn't favor neither NV nor AMD but according to tests it is not true.I already said that PerfHUD or Nsight does this for NV gpus but it doesn't work for AMD gpus unfortunately.We need a stable 3rd party tool which will be acknowledged by both vendors.

 

[zebrax2]

According to the article Fraps isn't wrong but it doesn't show the whole picture due to the way it monitor things

 

[24601]

http://www.anandtech.com/comments/6857/amd-stuttering-issues-driver-roadmap-fraps/296013

http://www.anandtech.com/comments/6857/amd-stuttering-issues-driver-roadmap-fraps/296017

 

[Jaydip]

So you are suggesting to set the number of pre rendered frames to zero? it may cause heavy slowdowns during loads.

 

[24601]

So you are suggesting to set the number of pre rendered frames to zero? it may cause heavy slowdowns during loads.

It also measures latency perfectly.

context queues of higher than 0 do nothing other than having a smoother picture just to have a smoother picture, it doesn't actually transmit useful data to the user at a smoother or more useful rate.

You may as well just show the same picture twice (or thrice) in a row (as AMD does in crossfire) as filler just to make the picture look smooth, the extra calculations you are doing are absolutely pointless in a real sense.

 

[raghu78]

excellent article. AMD and Nvidia agreeing on better tools required for measuring frame latency is welcome. There is a need for increased R&D on better frame latency measurement tools at Microsoft, Nvidia, AMD and the tech press. The most important benefit is now both companies will do frame latency analysis on latest drivers and latest games.

 

[Jaydip]

It also measures latency perfectly.

context queues of higher than 0 do nothing other than having a smoother picture just to have a smoother picture, it doesn't actually transmit useful data to the user at a smoother or more useful rate.

You may as well just show the same picture twice (or thrice) in a row (as AMD does in crossfire) as filler just to make the picture look smooth, the extra calculations you are doing are absolutely pointless in a real sense.

No it will be a huge waste of resource.Think about it,the application can't send data unless the frame is actually shown.Before the frame is actually shown it can send another frame.

 

[3DVagabond]

excellent article. AMD and Nvidia agreeing on better tools required for measuring frame latency is welcome. There is a need for increased R&D on better frame latency measurement tools at Microsoft, Nvidia, AMD and the tech press. The most important benefit is now both companies will do frame latency analysis on latest drivers and latest games.

Frame latency? Not to pick on you, but it's not latency that's being measured or discussed, it's "frame interval". The article was very specific on this and explained why it's important.

It's important that we use the correct terminology. It stops confusion with different phenomenon being described as the same thing. This happens with the term "micro-stutter" all of the time being used for single GPU stuttering when it's a multi-GPU specific issue. You then end up with data from different testing being interjected into the discussion either to reinforce or reject a position. It confuses things, rather than clarify them.

 

[24601]

No it will be a huge waste of resource.Think about it,the application can't send data unless the frame is actually shown.Before the frame is actually shown it can send another frame.

Basically you're telling me micro-stutter is a benefit, not a detriment.

Most people here say BS to that sentiment.

Queuing up frames and then flooding them in a row is a stupid way to do things in all cases. It literally does not give the user additional useful data, just doing the same as showing the same picture multiple times in a row and calling that "higher frame rates."

Frame interval is useless, frame latency is what matters.

AMD/ATi's mouthpiece slides made sure to try to change the subject as must as possible to frame interval because they like showing the same frame multiple times to make the display "smoother" as seen by their laughable crossfire implementation and how they tried to cheat in their battlefield 3 drivers related to single gpu recently that they were caught red handed doing.

 

[Jaydip]

Basically you're telling me micro-stutter is a benefit, not a detriment.

Most people here say BS to that sentiment.

Queuing up frames and then flooding them in a row is a stupid way to do things in all cases. It literally does not give the user additional useful data, just doing the same as showing the same picture multiple times in a row and calling that "higher frame rates."

Frame interval is useless, frame latency is what matters.

AMD/ATi's mouthpiece slides made sure to try to change the subject as must as possible to frame interval because they like showing the same frame multiple times to make the display "smoother" as seen by their laughable crossfire implementation and how they tried to cheat in their battlefield 3 drivers related to single gpu recently that they were caught red handed doing.

I am not saying that at all.Who told you they queue the same frame?
If there is a two seconds interval between each frame we would surely not be playing games.Let me understand this correctly, are you saying to set the pre rendered frame to zero just for testing purpose or for actual gameplay?

 

[24601]

I am not saying that at all.Who told you they queue the same frame?
If there is a two seconds interval between each frame we would surely not be playing games.Let me understand this correctly, are you saying to set the pre rendered frame to zero just for testing purpose or for actual gameplay?

For both unless you are watching the screen for anything other than feedback to your controls.

If you are watching your screen like a movie, then sure, queuing is absolutely ok.

I like to believe that games are an interactive medium though.

If you haven't even read the articles the Anandtech article is referencing, don't bother having a debate on this subject.

Arguing from ignorance is a waste of both mine and your time.

 

[Rikard]

Very good article Ryan. It helps clear a lot of confusion from this forum. Like I said from the beginning, Fraps is a blunt instrument, and does not accurately represent the user experience. It would be interesting to not only have a tool that can monitor the effective frame interval but also the latency. That would truly revolutionize the way reviews are done!

 

[BrightCandle]

There is a particular statement that I still take great exception to, because its simply not true. That is that games are responsible for the stuttering on their end.

The way DirectX works is that the users thread calls onto all the draw calls and then it calls present once the frame is done. Present as a method call has a few options but everyone uses the blocking mode. What that means is that if the context queue is full (and it usually is as the GPU is normally the bottleneck) then the thread will have to wait on that present call until there is a space in the context queue.

You might think this doesn't matter but it does, a lot. Because the game simulation is also held up by this delay in the present call. The rendering is stopped waiting on present and the game simulation is also stopped waiting on the rendering. Now in a well behaved scenario the amount of wait will be the same in every frame and thus the game simulation is run at a nice even spacing. However if some present calls are not held up or allowed to go faster (the heartbeat) that will impact the games rendering period and its game simulation times. This causes a stutter in the game engine itself as it tries to match the GPUs frames consumed.

If the GPU causes a longer hold at the present call than normal then it is the GPUs fault that there is a knock on effect on the game itself. The frames might come out evenly to the DVI port but the contents of the frames will now not match the frame moment due to the knock on effect from fraps.

I think this is a really important point to understand because if one manuifacturer has a problem here and the other doesn't then one will produce smoother playing games. If Windows were the issue or fraps then we would see very similar traces from both manufacturers. The fact we see the differences we do and down to a very fine resolution tells us that actually fraps is a much more precise tool for what it is measuring (problems on the input to the GPU pipeline) than AMD is accepting.

Did Anandtech just publish a puff piece? Sure feels like it.

 

[Silverforce11]

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.

 

[Olikan]

The fact we see the differences we do and down to a very fine resolution tells us that actually fraps is a much more precise tool for what it is measuring (problems on the input to the GPU pipeline) than AMD is accepting.

errr... that's exacly what AMD said, there shouldn't be differences, even at this "bad" tool, and that's why they will fix it

 

[Imouto]

FRAPS busted -> Check
FRAPS dismissed by both AMD and Nvidia -> Check
Games blamed for terrible performance (Far Cry 3 for example) -> Check
AMD admitting their defeat about the matter -> Check
Hardware sites trying to measure stuff in the wrong way -> Check

This article is really good in several ways. Explaining things instead of bandwagoning like everyone else is a really good start. Exposing a problem is totally different from measuring it with the wrong tools.

Next time on the infrawebs: Why DVI capturing is only good if you want to shed manly tears and why faster graphics lead to more manly tears.

 

[lavaheadache]

After reading that article I have a question regarding this

"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."

Does anybody think that AMD will implement some of these fixes in legacy drivers? Namely for HD 4XXX and up? I suppose even including them for the HD 2XXX and 3XXX would be feasible since they are all a using unified shaders and can still play most games reasonably well at lowered resolution and details.

 

[Grooveriding]

That was an awesome read. For the first time there is a summation that is not winging it or guess work like seen from other reviewers. Actual information on what is and what is not happening.

So much for the frame time messiahs and people pooh poohing at AT's reviews. They wind up being the ones to give a concise and accurate explanation of what is happening and delineating it between latency and intervals.

 

[Ibra]

So now blaming FRAPS for AMD problems?

 

[Lonyo]

So now blaming FRAPS for AMD problems?

Someone already summarised some key points, but I'll do it again for your benefit, if you bother to read.

AMD AND ALSO NV say FRAPS doesn't show what people think it does, and misrepresents the situation.

AMD ALSO ADMIT that they DO have a problem, and are working to fix it.

So no, AMD aren't blaming FRAPS at all, they are saying they have a problem, and need to fix it, but that FRAPS isn't truly reflective of the situation.

 

[PingviN]

So now blaming FRAPS for AMD problems?

Why not read the article first and jump to conclusions later?

 

[Olikan]

Someone already summarised some key points, but I'll do it again for your benefit, if you bother to read.

AMD AND ALSO NV say FRAPS doesn't show what people think it does, and misrepresents the situation.

AMD ALSO ADMIT that they DO have a problem, and are working to fix it.

So no, AMD aren't blaming FRAPS at all, they are saying they have a problem, and need to fix it, but that FRAPS isn't truly reflective of the situation.

really.... or people in this forum didn't read the awesome article, or they fail at read pretty bad