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

[Yuanhan Liu]

On Fri, 2011-08-26 at 01:07 +0800, Zack Rusin wrote:
> On Thursday, August 25, 2011 04:43:13 AM Yuanhan Liu wrote:
> > On Thu, 2011-08-25 at 06:06 +0800, Jose Fonseca wrote:
> > > 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.
> 
> What branch are those timings based on? I don't think I've seen that code. 

Based on a patch I wrote before.

> I 
> remember an email with gzwrite commented out and that was only 174fps back 
> then, so it's surprising that not compressing/not writing to disk is slower 
> than doing it in a separate thread.
Oh, my fault, sorry for that. Well, my point is that it can reduce lots
of overhead.

> 
> > 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.
> 
> Yea, we can. In fact it'd be probably a lot easier, since we control the 
> entire app. We create a ringbuffer of calls and decompress in a separate 
> thread. The rendering thread just pops the calls from the buffer and executes 
> them. We were just never optimizing the retracer because it wasn't a priority. 
> It's really fast as it is so there has never been a need for it. Plus with 
> snappy it's even faster.

Got it. Thanks!