[PATCH] tracedump: add --help and --function-histogram

[Zack Rusin]

On Wednesday, September 07, 2011 04:59:50 PM Alon Levy wrote:
> What I'm actually after atm (maybe you are working on this) is trying to
> figure out optimizations possible from the calls. I have for instance a
> trace that shows about 3.3 MB per frame, most of it spent in setting up
> arrays, glVertexArrayPointer. I wanted to answer the question wether there
> were reused buffers here. So basically just caching the blobs per function
> per index, but it gets a little more complicated for places where you need
> to track the current item being set via previous function calls, for
> glVertexArrayPointer luckily you only need the first index parameter. Is
> anyone looking at this?

Yea, that'd be definitely very nice to have. First I really wanted to have a 
common interface for analysis/hinting passes. Then we could just invoke all 
the passes via the same interface and the results would be passed back via 
some common reporting class. The particular problem of tracking vertex array 
setups from previous calls would of course be still plugin/pass dependent but 
at least the frame splitting, trace iteration, state lookups and so on would 
be shared.

This is code that would be used by the gui as well so it would be ideal if it 
was in libcommon and if not it has to be easy to get the results somehow.

gDEBugger does some simple analysis like: whether you are issuing a lot of 
small draw calls that could be optimized by bundling data, or whether you keep 
issuing state managment function without actually changing the state. We could 
do a lot more than that but we need to do some work on our model first.

Jose and I have been talking about unifying the model used by the gui with the 
trace_model.hpp code. They're a little different now, in particular because the 
gui model does the Frame->Calls split whereas the trace_model.hpp is just a 
list of calls. I think this is something that Jose wanted to tackle. Of course 
until then you could always create a branch and come up with an interface that 
operates just on Trace::Call's and see how far you can get with that.

z