Frame Range in qapitrace GUI

[José Fonseca]

On Thu, Oct 25, 2012 at 3:48 PM, Kain Osterholt
<kain.osterholt at gmail.com> wrote:
> I think the problem had to do with a mismatch in apitrace version.  I'm
> viewing the trace on a different machine because our development boxes do
> not come with the proper packages to build qapitrace.  I was debugging
> another issue at the time with the _trace_user_arrays segfault and I think I
> was going back and forth between versions to see if the issue existed in the
> 3.0 tag.  I must have then traced with 3.0 and tried to view the profiling
> info with the tip.  This resulted in retrace running into segfaults which is
> why all the profiling data wasn't there.
>
> Perhaps a file version verification would have helped in this case but I
> don't really think it's necessary.  I should have just been more careful all
> along.  The full profile now shows up correctly when both machines are using
> the tip of apitrace.

Trace files have version verification. It must have been something else.

One issue with moving traces between different machines is that it
usually requires swizzling the textures/objects names, as they differ.
glretrace tries to do that, but it has several flaws, in particular
because some objects are per context, while other namespaces are
shared, etc.

> A couple of other things I've noticed:
>
> 1. The pixel count seems to always be 1 for each draw call which is
> definitely not accurate.

Weird indeed.

> 2. Getting the state info for a frame does get through the entire retrace
> but then crashes on the last frame where it dumps an error "json_parser -
> syntax error found, forcing abort"

Maybe glretrace is segfaulting half way dumping state. If you run
glretrace manually, ie.,

   glretrace -D XXXX foo.trace

where XXX is the call no of interest, is the generated JSON valid?

> I have the tip of apitrace as of monday.
> OpenGL driver on the dev box is catalyst 12.1

I haven't tried the profiling on AMD catalyst drivers yet.

Jose