WIP: "apitrace trim" is starting to get interesting

[Carl Worth]

I just pushed a couple of new commits to my apitrace-trim branch. In
addition to trimming drawing operations outside the specified range, the
new functionality includes:

  * Identifying "dead" textures (never bound within the specified range)
    and dropping many texture updates to these textures (glTexImage* and
    friends).

  * Optionally dropping glGet*, glXGet*, and eglGet* calls (only if the
    user specifies "apitrace trim --trim-gets".

Feel free to look at the branch, and let me know what you think.

I am not proposing this branch to be merged into master at this
point. Here's an incomplete list of things that need to be addressed
before the code might be ready for that:

  * The ad-hoc GL-state-tracking code needs to be moved outside of
    cli_trim.cpp, (perhaps to common/glstatetracker.cpp or so)? This
    will allow for sharing of frame-detection and similar functionality
    between trimming and snapshot-generating code, etc. (It will also
    hide away any of the current, hideously ugly STL usage from the
    logic doing the actual trimming.)

  * The tracking of live/dead textures needs to be augmented to mark
    textures live in response to glFramebufferTexture and
    glFramebufferTextureLayer. This is a correctness fix, (trimming may
    be incorrectly aggressive without this fix).

  * The list of texture-updating functions (to be potentially trimmed)
    needs to be made more complete. This is a quality-of-implementation
    fix, (without this, the tool won't trim as much as possible, but
    should not generate a buggy trace).

  * We should decide a better interface than --trim-gets for determining
    what the user actually wants to trim.

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). For example,
he would like to be able to trim out-of-range drawing operations first,
(without touching textures), and only after verifying that trimmed trace
would he then want to trim dead textures.

To support something like that, I'm thinking we'll want something like a
--trim-spec option that might have a default value of:

	"drawing_operations,dead_textures"

and then the user could specify an alternate trim specification, (for
example, adding "gets" to the list). We might also want separate
command-line options to add or remove specific classes from the trim
specification, (since we anticipate the default trim specification to
grow going forward, and it would be annoying to have to query and enter
the whole string just to tweak one piece of it).

And of course, once all of the above is done, there are lots of new
classes of trimming that can be done. For example, it's currently fairly
disappointing to try trim a trace down to a single frame of calls, but
still find in qapitrace that every original frame is still present. (We
might just consider glXSwapBuffers a drawing operation to allow those
out-of-range frames to disappear.)

It is nice, though, that the current approach allows us to incrementally
approach the ideal trim-trace-to-a-single-frame operation.

As always, I'll be glad for any feedback. More code to come soon...

-Carl

-- 
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/20111121/e6879a01/attachment.pgp>