[PATCH] Implement support for GPU timings of calls when proofiling with glretrace.

[José Fonseca]

On Thu, Aug 2, 2012 at 1:46 AM, Eric Anholt <eric at anholt.net> wrote:
> José Fonseca <jose.r.fonseca at gmail.com> writes:
>
>> Hi Carl,
>>
>> Your patch indeed addresses most of the issues I had with the original
>> timer query patches.
>>
>> Alas I recently asked James Benton, an intern at VMware, to start
>> looking at this:
>>
>>   https://github.com/exjam/apitrace
>>
>> It's unfortunate this effort duplication.  At a glance, I think his
>> effort is a bit ahead:
>> - it keeps.a ceiling on maximum number on queries open
>
> Seems like you should be able to be totally asynchronous, and not need
> to worry about any limits on queries.  You're going to get throttled at
> some frame boundaries at least, so periodically a ton of old queries get
> finished and you can reap them.
>
>> - keeps track of bound shader (and there's a script that can aggregate
>> gpu times per shader, whic means one can see the shader that takes
>> most gpu total)
>
> Thanks!  I've been needing this feature for *ages*.
>
> The issue I have right now with trying to do performance debug through
> apitrace is I can't easily assign blame between the VS and FS of the
> shader program that's taking all the GPU time.
>
> Hopefully at some point we get performance counters hooked up to more
> easily answer that question, but for now to figure that out, I've been
> trying to go into the trace and whack the FS source to just be
> gl_FragData[0] = vec4(0, 1, 0, 0) (and updating the length argument in
> the API call -- would be nice for that to be automatic).  An edited
> trace appears in /tmp, which fails under apitrace dump or qapitrace
> with:
>
> error: (glShaderSourceARB) unknown call detail 3
>
> so I can't quite answer my question yet.

It looks like shader (or trace) editing is generating invalid traces somehow

> As an aside, this edit makes qapitrace suck up 10g of memory and writes
> a new 1.2gb trace to disk over the course of a few minutes.  It would be
> nice if trace edits could be expressed in some small files as diffs to
> an original file.

My plan is to not write anything to disk at all -- just pipe the test
shader to glretrace's stdin and skip both disk and gzip -- which
should be even faster. But never got around to do it.

Jose