[PATCH] Retrace: Add per frame timing
Zack Rusin
zack at kde.org
Fri Oct 21 17:49:25 PDT 2011
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
More information about the apitrace
mailing list