new AMD Catalyst driver from Alpha Micro stuttering

[VulgarDisplay]

I'm told hardcore gamers dont play with vsync cos the input lag is too much "OMG WTFBBQ" horrible and it would affect their ability to perform uber flick headshots....

This is true. Get on my level. :awe:

 

[bystander36]

I'm told hardcore gamers dont play with vsync cos the input lag is too much "OMG WTFBBQ" horrible and it would affect their ability to perform uber flick headshots....

Or they don't use v-sync because they prefer the smoothness of low latency. Low latency feels more responsive to a lot of people. It even helps reduce simulator sickness for some (myself). Just because you don't play the way others do, does not mean you have to be an asshat.

Besides, low latency does make it a tiny bit easier to track a target.

I play both ways depending on the game. There are reasons for both ways, even if you can't understand it.

 

[Leadbox]

If fraps is showing a stuttering trace then there is a still a problem, but a lot of people misunderstand what it is measuring. The key part people are missing is that fraps measures the time when the present method is called in the DirectX API, which signifies to the card its time to show the frame. What the graphics card driver does in response is part all the instructions for the frame into the context queue. However if there isn't space in the queue then the thread calling onto present is blocked, it just sits idle until there is space.

Pcper has the following:

Following that is t_present, the point at which the game engine and graphics card communicate to say that they are ready to pass information for the next frame to be rendered and displayed. What is important about this time location is that this is where FRAPS gets its time stamps and data and also where the overlay that we use for our Frame Rating method is inserted. What you should notice right away though is that there is quite a bit more work that occurs AFTER the t_present command is sent and before the user actually sees any result. This in particular is where capture method’s advantages stem from.

That is a bit different to what you wrote

 

[UaVaj]

Pcper has the following:

That is a bit different to what you wrote

just becuase it is not written exactly the same - does not mean it does not have the exact same meaning.

both bright candle and pcper said the exact same thing - just differently. frap measure right before directx api.

still lost? how about a picture.

source: An introduction to FCAT benchmarking


-----

if you or anyone else actually understand the term "garbage in garbage out" you would understand the importantance of FRAP's measurement in contrast to FCAT's.

 

[Leadbox]

just becuase it is not written exactly the same - does not mean it does not have the exact same meaning.

both bright candle and pcper said the exact same thing - just differently. frap measure right before directx api.

still lost? how about a picture.

source: An introduction to FCAT benchmarking


-----

if you or anyone else actually understand the term "garbage in garbage out" you would understand the importantance of FRAP's measurement in contrast to FCAT's.

I dont disagree with the part were fraps measures just the rest of it reads a bit off
We can go from this: fraps in

To this: fcat out

It clearly doesn't have to be smooth in for it to be smooth out

 

[BrightCandle]

There are multiple buffers between the fraps measure and the fcat measure. The execution context buffer and the vsync buffering. These buffers adsorb the momentary differences of delivery of frames and thus the output frames come out smoothly. The GPU can only work so fast and since its almost always the bottleneck a faster frame wont get processed any earlier so it comes out when the GPU has time, getting delayed in the process. But that frame has now been time shifted, it has a different latency to the frames around it and the contents represents a different time period to when it would be displayed, and that we see as a hitch in the game world. That is different to a frame being displayed too long like in a low FPS scenario but neitherless its still a noticeable effect and we seem to be able to see these things very easily (well most of us can but not all).

The ideal FCAT and fraps output matches precisely, because then we can be sure that all the frames are getting processed with the same latency, which ensures both the content and the delivery of the frames is matched. Of course then what we also want is a perfectly smooth graph for both.

You can actually get the FCAT output to look a lot more like the Fraps output by reducing the execution queue to the minimum (ideally 0 but I think the minimum is 1 on AMD and NVidia these days) while having vsync off. That will actually output quite a spiky graph if the input is also spiky and in addition it will make the fraps output even worse because sometimes the GPU might be starved for work and sit idle.

I am writing about it differently to pcper partly because I have written DX code myself and hence know how this works and partly because NVidia's/AMDs quotes are taken out of the context by them when reporting it. Fraps frametimes matter every bump and hitch is a sign of a genuine shift in animation, but its also a very sensitive measure. On the one hand its right of AMD/NVidia to say that not every little movement is a problem, but its also true that some amount of movement is actually noticeable. What I am trying to do (and have been trying to do for quite a while now) is explain how it works and its impact so people can see precisely what it measures and understand how it works. There is a lot of misinformation on this forum trying to say fraps is useless, but we need both Fraps and FCAT, and we also need a latency tracking tool as well. All of these measures are looking at different aspects of the graphs pipeline and we have a variety of different problems around how the cards currently work.

 

[Black Octagon]

Thanks a lot, BrightCandle