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

[Alon Levy]

On Wed, Sep 07, 2011 at 06:50:57PM -0400, Zack Rusin wrote:
> 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.
> 

I totally missed that libcommon is already there. I just need to make it into a
shared library (as well? do you prefer to link tracedump, qapitrace, glretrace
statically to it?). I think that json would be pretty bad if I want to pass binary
blobs over it, I can use boost::python or external python 2 c++ solution (swig
maybe), or add a common_c_api.c file, I'll do the later for now (hoping you will
accept it).

Regarding a pass/hinting mechanism, sounds like exactly what I need, qt already
has a plugin api that you can use afaik, and the same plugins can be "hand"
loaded into tracedump as well later. I guess I don't have any special input so
I'll wait for you guys to tackle it.

Alon

> z
> _______________________________________________
> apitrace mailing list
> apitrace at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/apitrace