WIP: "apitrace trim" is starting to get interesting

[Carl Worth]

On Thu, 24 Nov 2011 17:34:36 +0000, José Fonseca <jose.r.fonseca at gmail.com> wrote:
> Note that you trim draw calls outside of range, but draw calls to
> fbo's to textures later used in the range, need to be preserved as
> well.

Whoops. Good point.

> And so on. That is, multiple passes over the trace are necessary to
> get all the needed calls correctly.

Right, some of this can get pretty complicated fairly quickly. My goal
here was to start out trimming only conservatively, (things known to be
safe to trim), and then incrementally get more sophisticated. Clearly I
missed this one. But it should be easy enough to safely trim only
those drawing operations targeting the window system, not an FBO, for
now at least. I'll fix that.

> Run
> 
>    grep glGet specs/glapi.py | grep -v sideeffects
> 
> to see them all. (Hmm. Actually some should not be there).

Thanks. I'm a total GL newbie, so I was unsure whether any glGet calls
had side effects. I'm glad to see you've already done some work to
classify these. At this point, I still need to be taught quite a bit
about GL.

> > Feel free to look at the branch, and let me know what you think.
> 
> I confess that I was very sceptical about any state tracking, but
> looking at what you done so far, I'm more optimistic that we can trim
> a big portion of the cases we care correctly.

I'm quite encouraged already and I'm looking forward to what we'll come
up with.

Thanks again for looking at the code I've done so far. I'll catch up
with what you've cherry-picked, clean up what's left, and then keep
working on new code to make this stuff easier.

-Carl

PS. What follows is more-or-less a brain-dump from a session I spent
with the current (and still immature) "apitrace trim" applyinh it to a
real-world case, (getting a minimal trace from a game triggering a
rendering bug).

> > On this last topic, Eric mentioned to me verbally that he would really
> > like to do some fairly fine-grained trimming, (verifying that a trace
> > maintains some buggy behavior as each new item is trimmed).
...
> What I think it would be super is to have a fuzzy trimming couple with
> brute force interactive triming:

This morning I ran through my first non-trivial case of trimming, and I
think I got a usefully minimal trace in the end, (and learned a lot
about what we want here).

Here's the process I went through:

  1. Traced a program until a bug became evident

  2. Brought it up in qapitrace to a frame showing the bug, noted the
     first and lasst call numbers from that frame.

  3. Ran my "apitrace trim --trim-gets --calls=FIRST-LAST" to do some
     initial trimming.

During this step I made two changes to "apitrace trim" as seen here
previously:

    a. Added unconditional trimming of all calls after the last call
       specified in the --calls option. This should be safe and
       uncontroversial. It was very useful for step 5 below.

    b. Disabled the trimming of out-of-range drawing operations. This
       particular case showed that this trimming is buggy, (and it's a
       different bug than the FBO issue mentioned above). I haven't
       chased down that bug yet, but it's clear that we definitely need
       to be able to easily specify that certain supposedly-safe
       trimming operations shouldn't be performed to be able to
       workaround bugs like this.

  4. Added a new --trim-all option to "apitrace trim" that
     unconditionally trims all calls outside the specified range.

  5. Manually iterated with calls of the form:

apitrace trim --trim-all --calls=RANGE bug.trace; glretrace -w bug-trim.trace

Since the trace now ends with the buggy frame it was clear from the
final frame in the retrace window whether the bug was preserved. I
iteratively refined my range specification, (sometimes blindly and
sometimes by poking around inside qapitrace to guess at likely
boundaries).

The final trim took a trace of over 500 thousand calls down to 54 calls
while still preserving the bug. It took me roughly 150 steps to find
that. Obviously, I want to automate that quite a bit more.

Here are some of the things I noticed while going through this:

  * If the glXMakeCurrent call is trimmed away, then glretrace
    segfaults. So there's obviously a bug somewhere. I didn't
    investigate where.

  * In my case, I trimmed out all state manipulations except for the
    handful that were actually necessary once I had my trace trimmed
    down to one drawing operation of interest. In many scenarios, that's
    not necessary at all, (extra state setting is unlikely to complicate
    debugging in many situations).

  * For the manual, iterative trimming I did, it would be nice to have
    the tool detect a bit more structure from the trace. The frame
    identification in qapitrace definitely helped, (and I plan to
    abstract that code to add "apitrace trim --frames" soon). Beyond
    that, it would be very convenient to automatically detect the
    structure of things such as nested glPushMatrix/glPopMatrix
    calls. Those calls were among the most problematic in the
    range-based bisecting I was attempting.

    Long-term, it might be nice to have some hierarchy inside qapitrace
    with the ability to enable/disable pieces of the hierarchy in a live
    preview. That should make it fairly easy to drill down to find a
    problematic drawing operation, (like firebug for the graphics
    stack).

    Short-term, it would be useful to have a mode for "apitrace trim"
    that's nearly as aggressive as my --trim-all, but that would
    preserve ''essential'' state updates such as the matrix
    manipulations.

-- 
carl.d.worth at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/apitrace/attachments/20111129/a2f153b1/attachment.pgp>