[Chalnoth]

Anandtech has a first pass at looking at this:
http://anandtech.com/show/6862/fcat-...rking-part-1/2

It sounds interesting to me, but it's unfortunate that it just won't work for most gamers (because it requires a capture card). But I would very much like to see tools at this level used for video card reviews.

[lanek]

Is it just me, or no one of thoses tests take the monitors or TV hardware in consideration.. because what is ouputted by a DVI, HDMI port is not what you see on your display ... as the monitor or display hardware ( till pixels show the frame ) have a delay, and so constructors have put hardware considering the latency of their hardware display for "smooth the render of frames ( or image frequency ) who take in account this.. you will never show the same results by your eyes. If your monitor have a 16ms latency ( largely considered as good in Input lag ( bad word as it is not input lag, but latencies of the display hardware ) ..
Its the problem with metering the output, as the monitor is too metering the display ( hence the increase of delay and input lag and who cant be predictable on the gpu side output as it conflict with the display " delay " )

The best monitor in term of hardware display latency ( including processing and pixel response time ) is the Asus 27" 144hz TN ( averaging in the 7.8ms ) and is nearly 4 to 5x faster to display an image of a 27" PLS or IPS ( depending the panel .. 16 to 32ms )

[pcchen]

Since this test is aimed at measuring the variations of frame time, latency is not the biggest concern here, especially considering the fact that most monitors only add a constant latency instead of a random latency (that would be pretty bad for a monitor in any case). Therefore, using a frame capture card can be considered as using a "perfect" monitor.

[silent_guy]

Originally Posted by lanek

... and so constructors have put hardware considering the latency of their hardware display for "smooth the render of frames ( or image frequency ) who take in account this..

Do you stuff like motion interpolation of TVs? Monitors don't do that kind of stuff.

..., as the monitor is too metering the display ( hence the increase of delay and input lag and who cant be predictable on the gpu side output as it conflict with the display " delay " )

The monitor sees a constant rate 60Hz input image. It has no idea whatsoever about the content. As far as it is concerned, the images are 100% stutter free. There is nothing to meter or to fix.

[lanek]

Originally Posted by silent_guy

Do you stuff like motion interpolation of TVs? Monitors don't do that kind of stuff.


The monitor sees a constant rate 60Hz input image. It has no idea whatsoever about the content. As far as it is concerned, the images are 100% stutter free. There is nothing to meter or to fix.

Nooo lol... it is on the way to display the input .. all monitors have a latency between the moment of they recieve the input and display it ( without enter details because what i see is really an image about it ) .. So the panel need to "smooth" the display taking this in account... it dont look the image, it cant... but they need display it at a certain rate ( 60hz ) otherwise you will have an image completey distorted,.. its like a strobe who commit at a certain rate. you will not get 2 " flashs " faster of the other on a monitor.. if it was follow only the input it will, but the panel smooth this by use the same interval between each.
The latency of an excellent monitor is around 8ms .. most "good" monitor around 16ms ... so i ask me what happend if your frame rate variation is around 12ms.. what happend ? Can we really see it ? because the monitor will ofc delay the input of short frame and "smooth " the output .. a perfect monitor dont exist outside a capture card. ( and yet again, we admit a 5 to 10ms delay with them ( due to CPU+SSD+and streaming of the data etc ).



Sorry my english is really bad today ( its hollidays ).. so im not sure i can explain it clearly.

[silent_guy]

I'm afraid your Easter English is a bit too much.
But let me restate: the time between a pixel leaving the GPU and the pixel getting displayed should be identical for all pixels on the screen. And it should be identical over time.

The monitor may buffer it up for some reason (RTC etc) which can introduce a certain fixed amount of latency, but that's about it. There is no need for metering etc.

[Chalnoth]

Originally Posted by lanek

The latency of an excellent monitor is around 8ms .. most "good" monitor around 16ms ... so i ask me what happend if your frame rate variation is around 12ms.. what happend ? Can we really see it ? because the monitor will ofc delay the input of short frame and "smooth " the output .. a perfect monitor dont exist outside a capture card. ( and yet again, we admit a 5 to 10ms delay with them ( due to CPU+SSD+and streaming of the data etc ).

The monitor doesn't do any smoothing. It just adds a constant delay.

[madyasiwi]

Originally Posted by Chalnoth

It sounds interesting to me, but it's unfortunate that it just won't work for most gamers (because it requires a capture card). But I would very much like to see tools at this level used for video card reviews.

I believe once the algorithm/formula is standarized/established, tools like Fraps should be able to do it without any capture card. Since Fraps is capable of capturing DX frame outputs, it could measure the color band on the fly and quickly discard the frame. I don't see anything in this FCAT toolchain that cannot be done with commodity softwares. (Besides, I hate Perl, Python FTW! )

I thought I read somewhere that Alex Unwinder plan/interested to incorporate it in his tools?

[madyasiwi]

After a second thought, grabbing front buffer might be too slow and might not be invoked at the same timing as display refresh. So yeah, a hardware capture card is required.

But I imagine the capture card's output might be forwarded to a custom directshow filter to measure the color bands on the fly so you won't need to have an array of fast SSDs for recording.

[pcchen]

Originally Posted by madyasiwi

But I imagine the capture card's output might be forwarded to a custom directshow filter to measure the color bands on the fly so you won't need to have an array of fast SSDs for recording.

Recording the frames is still valuable because you can actually see the frames to determine whether it's smooth or not.

[Chalnoth]

Originally Posted by pcchen

Recording the frames is still valuable because you can actually see the frames to determine whether it's smooth or not.

Well, I'd say that's mostly just useful for debugging the frame capture hardware and software used to measure the frame times.

[pcchen]

Originally Posted by Chalnoth

Well, I'd say that's mostly just useful for debugging the frame capture hardware and software used to measure the frame times.

It's still important to see whether a game produces smooth frames even when the measured time looks smooth.

[Chalnoth]

Originally Posted by pcchen

It's still important to see whether a game produces smooth frames even when the measured time looks smooth.

What additional information could you glean from the screen captures that isn't in the frame times? What do you mean by "smooth" in this case?

[pcchen]

Originally Posted by Chalnoth

What additional information could you glean from the screen captures that isn't in the frame times? What do you mean by "smooth" in this case?

For example, if you are moving at a steady pace, with a smooth frame time, the objects in the frame should move at a roughly steady speed. However, if a game engine does not measure frame time properly, it could produce jittery moving objects, despite the frame times measured are all smooth.

[silent_guy]

Originally Posted by pcchen

For example, if you are moving at a steady pace, with a smooth frame time, the objects in the frame should move at a roughly steady speed. However, if a game engine does not measure frame time properly, it could produce jittery moving objects, despite the frame times measured are all smooth.

That'd be fine if you were reviewing a game, but I don't think it has a lot of the value when benchmarking a GPU.

[Chalnoth]

Originally Posted by pcchen

For example, if you are moving at a steady pace, with a smooth frame time, the objects in the frame should move at a roughly steady speed. However, if a game engine does not measure frame time properly, it could produce jittery moving objects, despite the frame times measured are all smooth.

Interesting. That effect should be capturable by comparing the frame times as measured by FRAPS vs. those measured by the capture card.

[Ethatron]

You can also just calculate a motion vector-field to make a "motion-amplitude graph" to overlay with the other graphs, it's in video encoders and game engines since a while, just dump the info from a realtime MPEG4 encoder.

[Chalnoth]

Originally Posted by Ethatron

You can also just calculate a motion vector-field to make a "motion-amplitude graph" to overlay with the other graphs, it's in video encoders and game engines since a while, just dump the info from a realtime MPEG4 encoder.

That's not nearly as easy to do well. Game environments are quite complex, and it would be very difficult distinguishing between what sorts of motion are and aren't smooth.