[Mesa-dev] [ANNOUNCE] apitrace 3.0
jose.r.fonseca at gmail.com
Wed Mar 21 15:44:29 PDT 2012
On Sun, Mar 11, 2012 at 7:00 PM, José Fonseca <jose.r.fonseca at gmail.com> wrote:
> On Sun, Mar 11, 2012 at 6:59 PM, Dave Airlie <airlied at gmail.com> wrote:
>> (resend to include list, I only sent it to Jose by accident).
>> On Fri, Mar 9, 2012 at 8:22 PM, José Fonseca <jose.r.fonseca at gmail.com> wrote:
>>> There are several new features in apitrace that deserve an announcement:
>> I had an idea for a "feature" the other day but no idea how sane or
>> useful it would actually be.
>> I thought about trying to integrate callgrind and apitrace somehow, so
>> we could instrument the CPU usage for a single frame of an
>> I think we'd have to run the app under callgrind with instrumentation
>> disabled (still slow) then enable it for the single frame.
>> Just wondering if anyone else thinks its a good idea or know how to
>> implement it.
> IIUC, you're looking for the ability to profile the app (and not the
> GL implementation), for a particular frame, is that right?
> There is definitely interest in more profiling on apitrace:
> - there have been some patches for GPU/CPU profiling while tracing
> (see timing-trace branch) but I believe it is more useful to profile
> while retracing
> - there have been some patches for GPU profiling while retracing
> (timing-retrace branch) but needs some good cleanup
> - Ryan Gordon commited patches for CPU profiling while retracing
> (commited, glretrace -p option)
> Concerning callgrind integration, I personally don't have much trust
> in callgrind as profiling tool -- it emulates a CPU instead of
> measuring one. It does so using JIT binary translation, which is why
> is so slow. Lately i've been using linux perf with good results.
> Either way, I don't know if there's any interface to start/stop
> measuring or emit some marker from within the app being profiled.
> A full opengl wrapper like apitrace it's not necessary -- a LD_PRELOAD
> library with just glXSwapBuffers is sufficient --, all that's
> necessary is to start/stop/reset the profiler on that call.
> I think the hard thing here is really start/stop profiling programmatically.
Actually it looks like linux perf has a facility to emit custom
profiling events from whitin the app:
A capability I saw in this interesting Intel presentation, which also
used it with apitrace:
It should be possible to trim the perf events with "perf script" somehow
More information about the mesa-dev