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

[Carl Worth]

Eric Anholt <eric at anholt.net> writes:
> 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.

Fair enough. Long ago, when "trim" was just an idea with no code yet,
Zack and José talked about ideas for more fine-grained trimming.

I think we're now at the point where we have enough code that we can
start working on what we actually want as an interface.

How about a --trim-spec option that accepts a comma-separated list of
things to trim. With today's code that would be "textures,programs,
shaders" (and one more word to describe the calls-without-side-effects
that are also currently dropped---what's a good name for that?).

That option would be useful to me immediately when trying to debug why a
trim failed, (and would also obviously be useful for someone needing to
get work done in the face of still-buggy trim code).

That's easy to implement, and will also give some needed structure to
the code to make it easier to understand.

So I'll do this right away.

If you've got a better idea for the naming of the interface, I'll be
happy to take it.

Thanks for the feedback.

-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/20120904/136a0f58/attachment.pgp>