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

[Eric Anholt]

On Thu, 25 Aug 2011 16:43:13 +0800, Yuanhan Liu <yuanhan.liu at intel.com> wrote:
> 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.

Why couldn't one thread be decompressing and the other thread be
consuming the decompressed data and handing it to the GL?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/apitrace/attachments/20110825/e44ec135/attachment.pgp>