[RFC] [PATCH 1/2] Add a basic support of logging cpu and gpu time

Yuanhan Liu yuanhan.liu at intel.com
Thu Aug 25 01:43:13 PDT 2011


On Thu, 2011-08-25 at 06:06 +0800, Jose Fonseca wrote:
> ----- Original Message -----
> > On Wed, 24 Aug 2011 10:08:01 +0800, Yuanhan Liu
> > <yuanhan.liu at intel.com> wrote:
> > > Restructured to match the latest master branch. The implementation
> > > is
> > > quite ugly and dirty. But it didn't change the structure of the
> > > trace file.
> > > 
> > > --
> > > From ec52fd63c08eca86fca42ae27e79309130984078 Mon Sep 17 00:00:00
> > > 2001
> > > From: Liu Aleaxander <Aleaxander at gmail.com>
> > > Date: Wed, 24 Aug 2011 09:55:03 +0800
> > > Subject: [PATCH 1/2] Add a basic support of logging cpu and gpu
> > > time
> > > 
> > > Logging GPU time is a kind of trick, since you can't get the gpu
> > > time
> > > immediately after your opengl call. Thus we need to move it at the
> > > end of
> > > frame to reduce the time query overhead.
> > > 
> > > Well, that would introduce another problem, as the trace_writer
> > > doesn't
> > > know the real opengl call for the specified gpu time. Thus I
> > > introduce
> > > another log file for time. Please see comments inline for more
> > > info.
> > 
> > Trace capture time seems like the wrong time to be doing performance
> > analysis to me.  I would expect GPU performance analysis to be done
> > after the fact in qapitrace.  Then you could do multiple runs to
> > ensure
> > reliable data, and you could do even more clever things like culling
> > all
> > primitives to try to determine the balance of time used between VS
> > and
> > FS.
> 
> Yes. Although there are use cases for measuring the real application, I do feel that measuring times in retrace time is more useful, as everything becomes reproducible & easily automated. 

Yeah, right, Jose talked to me about this. While, one issue:

There are too overhead while tracing or retracing the app. Say, here I
have an app:

fps     test-plane
182     normally run
70      by glxtrace
100	by glretrace

175     by glxtrace, a separate thread to compress and write data to
disk.

In the glxtrace side, we can delay the real write and even open another
separate thread to write the trace data. So that the overhead while
tracing can be reduced lots. 

While, we can not delay the read while retracing, right? So that it's
hard to reduce the big overhead.

Of course, the overhead doesn't matter when logging the cpu time for the
OpenGL call, as we can get the right time of the specified function by
getting the time before and after that function call, just like the
patch did.  But it does matter if you want to get the timeline.

(Anyway, I didn't object to record the time while retracing.)

Thanks,
Yuanhan Liu



More information about the apitrace mailing list