[PATCH 2/2] trim: Invert the meaning of the --calls argument.

[Eric Anholt]

Carl Worth <cworth at cworth.org>, coni at yoom.home.cworth.org writes:

> Eric Anholt <eric at anholt.net> writes:
>> When you're trying to actually do trimming, you're identifying some
>> class of things to remove ("all the rendering between the load screen
>> and the frame that had the bug" or "all the rendering after the frame
>> that had the bug"), and asking trim to remove them (like the command
>> name suggests).
>
> I agree that the command name does suggest this negative sense.
>
> Meanwhile, this change would also apply to the --frames option I have in
> my current trimming code. And with --frames I've found that it's very
> convenient to have the positive-sense option. That is, "I know frame 256
> has the bug of interest, so 'trim --frames=256' to include only this one
> frame.

That syntax makes sense if the dependency tracking is trusted and
enabled and working.  I'm not thrilled so far -- it didn't work for me,
Ken's had issues on other traces, and I had a hard time making sense of
how it was supposed to work in the half hour or so I spent trying to
review it.

I also don't like how monolithic it is.  You either dead-code eliminate
programs and shaders and textures (and repeated statechanges?  and FBOs?
and buffer objects?), or you don't.  Which means that if any piece is
broken, I can't use the working pieces to make progress on trimming my
shader.  Even if trim's analysis is working, if I'm working on a bug in
the driver that is dependent on a "dead" call (hey, texture upload and
buffer object changes all call driver code that actually prods the
hardware), that would block me.
-------------- 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/20120904/3968ac66/attachment.pgp>