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

Zack Rusin zack at kde.org
Wed Aug 24 10:00:44 PDT 2011


On Wednesday, August 24, 2011 12:34:56 PM Chris Fester wrote:
> Hi Yuanhan,
> 
> Some questions:
> 
> What is the resolution of __glBeginQuery(GL_TIME_ELAPSED,...)? 

It's nanoseconds. It's part of the ARB/EXT_timer_query extensions. 

> For Linux, I've seen the gettimeofday call (what OS::GetTime() does) take a
> few tens of microseconds to complete (granted, I'm on an Intel Core2
> system, 3 or so years old).  I believe this is mostly due to the overhead
> of a system call.

Long term is would probably make sense to just use:

http://www.fftw.org/cycle.h

but my main concern for CPU timings is that compression and disk io will skew 
them a bit. So I think we need to figure out the use case for this stuff. For 
example what I'd love to know:

- what exactly it is that we're trying to measure,

- should we do the measurments while tracing or retracing,

- what's the performance of tracing while fetching both cpu and gpu time for 
every call,

- do we need both cpu and gpu time or do we care only about the gpu time

- how should the data be stored so that the tools can do the most out of them, 
for example as the TODO.markdown mentioned we'd really love to have a 
"Timeline view" 
( http://msdn.microsoft.com/en-us/library/ee417180(v=vs.85).aspx )
I haven't yet looked at how the data would need to be stored for this to 
happen.

> My admittedly lofty goal was to trace an application, capturing the TSC
> data.  Then run the retrace, also capturing TSC data.  One could then diff
> frames/calls between the trace and retrace to see CPU utliization
> differences.

That sounds like a great idea. The issue is that between the app actually 
generating the data and tracing compressing the data (compression is slower 
than decompression), the tracing timings will always be slower than the 
retracing. Also the disk io read/write speed will heavily influence both. 

So I think there's a lot of open questions. Most likely initially we need to 
push some implementation of this stuff to a branch and start experimenting with 
it.

z


More information about the apitrace mailing list