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

[James Benton]

On 01/08/12 01:26, Carl Worth wrote:
> José Fonseca <jose.r.fonseca at gmail.com> writes:
>> - it keeps.a ceiling on maximum number on queries open
> This part had me scratching my head for a bit, but I think I understand
> it now.
>
> The first patch in that series does a rather simple-minded thing of
> blocking on every frame until all the results are in. And that's
> obviously not interesting.
>
> The commit with the "maximum number of queries" instead queues up this
> number of queries and then starts harvesting results, (potentially
> blocking depending on the hard-coded limit and on how much activity the
> application has outstanding).
>
> My series instead queues up results without any hard-coded limit. What
> it does is simply harvest all available results at the end of every
> frame. So it never blocks to collect results. I think this is preferred.

Originally it was implemented with no limit but the nvidia drivers (on 
linux atleast) seem to not return correct results when too many queries 
are active. I found this whilst retracing one of the 3dmark06 tests.

>> - 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)
> Like I said in my earlier mail, this is what I was about to add next.
> I was skipping past an implementation step of just recording
> program/shader ID values and planning to hash shader source to take care
> of cases such as:
>
>    * Shader/program ID values being reused for different shaders
>
>    * Multiple shaders being instantiated with identical source
>
> I see that this patch series is starting with just grabbing the numeric
> program number. It's probably better to start with that at least.
>
>> But it possible that some details on your change that don't exist on
>> his branch. If you could give his branch a spin and let me know if it
>> fits your needs it would be great.
> It doesn't currently run with the Intel driver, but that looks like
> missing support for GL_TIMESTAMP in the driver, (which we should just
> add—it should be strictly easier than the existing support for
> GL_TIME_ELAPSED).
>
> -Carl