FCAT: The Evolution of Frame Interval Benchmarking, Part 1
by Ryan Smith on March 27, 2013 9:00 AM ESTMore To Come
While we were unable to complete our work with FCAT ahead of NVIDIA’s embargo, we wanted to provide an article that at least gives a brief overview of FCAT, as FCAT is in many ways itself part two of a process we started yesterday with our article and analysis of stuttering on AMD cards.
FCAT, we believe, is the next evolution of frame interval benchmarking. Where FRAPS' coarse nature does not suffice, FCAT provides a clear picture of what’s happening at the end of the rendering pipeline, giving us for the first time an automated, quantitative look at frame intervals, stuttering, and more. To be clear it is by no means a perfect tool, but as we have taken the time to lay out yesterday and today, compared to the beginning of the rendering pipeline, it is the end of the rendering pipeline that is more meaningful both for quantitative analysis, and ultimately for the users.
Speaking more directly however, FCAT is quite simply the frame interval analysis tool we have long wanted. It is the tool that will enable us to analyze stuttering, micro-stuttering, and more, in a manner consistent with our benchmarking methods and core beliefs in the scientific method. It’s exceedingly rare that we say this, but we haven’t been this excited by a new benchmarking tool in a very long time.
Wrapping things up, we will be following up this article next week with part 2 in our look at FCAT. In part 2 we will go into further detail about how to analyze the results FCAT generates, and what we’re finding across a range of video cards and games, both in single-GPU and multi-GPU configurations. So until then, stay tuned.
Facebook
Twitter
RSS
88 Comments
View All Comments
Dribble - Wednesday, March 27, 2013 - link
No tech report have something very similar to what is described above with the colour bars - it's what detected the runt frames that afflict xfire. The nvidia tool looks like a more professional complete solution, but tech report did it first.Klimax - Thursday, March 28, 2013 - link
You will still need FRAPS like tools, because FCAT won't see some problems and changes in pipeline.Hrel - Wednesday, March 27, 2013 - link
making it a simple an effective tool - and*it can only do at the start of the rendering pipeline - it can only do so* at the...
Taracta - Wednesday, March 27, 2013 - link
A color bar can hold a whole lot of information. From my reasoning, it might be possible to timestamp each line in a frame, but let's not get that detailed. How about just timestamping each frame and coding the information in the overlay. Each 24-bit pixel of the overlay is 3 bytes of information. An overlay at about 10 pixels wide would give 30 bytes of information on each line. This should be enough to timestamp the frame from were FRAPS would get its information to be compared with the time of what come out at the end of the pipeline. Why wouldn't this be possible?Rythan - Wednesday, March 27, 2013 - link
Agreed. Ideally, you'd write a frame number and timestamp on each line of the overlay (as FRAPS/FCAT does), and separately transmit the frame number and timestamp to the video capture system (a simple 32-bit GPIO interface would do). This would tell you everything about latency, stutter, and dropped frames from the PRESENT call to the montior.Ryan Smith - Wednesday, March 27, 2013 - link
Unfortunately that won't work. The timestamp needs to be generated at the moment the simulation state finalized, before the draw calls are sent off. Present is too late, particularly because a pipeline stall means that Present may come well after the simulation state has been finalized.Taracta - Wednesday, March 27, 2013 - link
The whole issue is not the simulation state but what happens between Present and your Display. The accuracy of what is being stimulated is not what the beanchmark is about (it would be nice to have a benchmark for that) but to measure the frame latency introduced by the graphics pipeline.shtldr - Thursday, March 28, 2013 - link
At least the game/benchmark could encode the simulation time when it calls "present" and the capture analysis tool could then discover fluctuations in the time difference between simulation time and shown-on-the-screen time. Ideally, such a difference should be constant all the time, leading to a perfectly smooth rendering of the simulation. This is what someone has already pointed out earlier in the comments.arbiter9605 - Wednesday, April 17, 2013 - link
i might be off, Like how frap's puts in its overlay of fps, dxframe overlay, puts the color on each frame in same way so colors are on each frame that through drivers, gpu, directx etc.toyotabedzrock - Wednesday, March 27, 2013 - link
Why can't they just send back a signal when the buffer swap happens? It seems that drawing more stuff on the screen adds a delay to rendering.