[PATCH] tracedump: add --help and --function-histogram
Zack Rusin
zack at kde.org
Wed Sep 7 15:50:57 PDT 2011
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
More information about the apitrace
mailing list