WIP: Dependency-based trim

[Carl Worth]

Hi folks,

After longer than I ever expected, I've finally dusted off my old work
to rewrite the trim code. I've got what I think is a reasonable
framework for doing dependency analysis. The code runs over the trace in
a first pass computing dependency trees and copying sub-trees over to a
final set whenever a head call is in the user's trim list. Then a second
pass simply emits the calls contained in the final set.

Using this framework, I've written code to capture the dependencies and
trim the following classes of operations:

  * Unused rendering operations

  * Unused textures

  * Unused shaders

I've also got a series of tests for the apitrace-tests repository
ensuring things work.

So far, my tests pass, but things don't yet quite work when trimming
non-trivial traces generated from real-world programs. I think the bugs
there are not major and I'll be working on those soon.

So I'm not proposing this for inclusion in upstream yet, but in case
anyone wants to take a look at what I have so far, I thought I'd share
it. If anyone has high-level comments on the approach I've taken so far,
I'd love to hear them[*].

There are about 17 patches to apitrace here:

	git://git.cworth.org/git/apitrace

and another 20 patches to apitrace-tests here:

	git://git.cworth.org/git/apitrace-tests

-Carl

[*] There's growing amount of open-coded blocks that are highly
structured. These might easily be condensed into some tables to drive
the dependency generation. For example, the table would have rows
giving:

	* Specification for matching calls

	* Arguments to extract from those calls

	* Dependency links to be generated

Another idea would be to generate this code from the specs much like the
existing retrace code is generated. This would fit in the style of much
of the existing apitrace codebase so I can see that it would make
sense. Personally, I'm not a big fan of code generation, so I likely
wouldn't put much work in in this direction, but I also wouldn't likely
object if someone wanted to rewrite things that way.

-- 
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/20120814/8bd39583/attachment.pgp>