[PATCH] Retrace: Add per frame timing
Anuj Phogat
anuj.phogat at gmail.com
Fri Oct 21 23:00:57 PDT 2011
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>
More information about the apitrace
mailing list