[PATCH] Retrace: Add per frame timing

[Zack Rusin]

On Friday, October 21, 2011 06:49:29 PM Anuj Phogat wrote:
> Hi All,
> 
>          Here is a simple patch to add per frame timing information while
> retracing. Tested this patch with couple of simple applications. It seems
> to work fine.
> This will provide useful information to identify performance issues with a
> specific frame. Currently, this patch creates a new file (frame.time) to
> dump the per frame timings.
> But the ideal way would be to integrate this information with apitrace UI.
> I would try to understand the UI code and integrate this new feature.

Yea, that would be a great feature to have. We've discussed it previously on 
this mailing list, you might want to go check out that discussion in the 
archives because there's quite a few things we'll need to do to get it right.

For example your code isn't measuing the time needed to render a frame but to 
retrace a set of calls. The difference being that your measurments will be 
skewed by both the time needed to parse and decompress the trace file and the 
asynchronous nature of the underlaying graphics api. In other words it isn't 
reliable, in particular because snappy will decompress in chunks so the long 
frame that you might be seeing might not be related to rendering at all but be 
caused by decompression kicking in for the given set of calls. It just 
requires a bit more thought and probably a careful usage of gpu timer queries 
to separate the cpu time from the gpu time.

Also, just as a sidenote there's already a frame_complete function in 
glretrace_main.cpp so there's no need to introduce your custom frame 
termination detection.

z