[PATCH] Retrace: Add per frame timing

[Anuj Phogat]

Hi Zack,

> 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.

I accept. I made a wrong assumption that glXSwapBuffers() blocks until all
previous gl calls
 finish execution. But actually It just flushes all the commands to gpu
command buffer and returns immediately.

> 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.

Yes, we have to use gpu timer queries to get more meaningful rendering
timings.

Thanks
Anuj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/apitrace/attachments/20111021/e4f3ab6a/attachment.htm>