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

[José Fonseca]

On Thu, Sep 8, 2011 at 3:01 PM, Alon Levy <alevy at redhat.com> wrote:
> 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).

I think the right place for a GL usage analysis is not any library,
but glretrace itself.

Most interesting kind of analysis  (e.g., detect redundant state
changes, leaking GL objects) need to know the GL state at a given
call.  So a purely standalone (in the sense that does not rely on a
live GL implementation) analysis tool  would need to replicate the
whole GL state machine. A endeavor that, although not impossible, it
is huge, and error-prone -- one would spend most time fixing
false-positives/negatives reports due to bugs in the state tracking.

The only viable way to have a standalone tool would be to use
glretrace to dump the state per call, but that would be very
inefficient.

Whereas doing this in glretrace is straightforward: when retracing a
GL call, just before exercising a GL state change or context
destruction one could inspect the current state by calling the
respective glGetXxx() call and see if the state is already set, or see
if there are undestroyed textures/etc.

One could code generate most of this, by describing the mapping
between GL calls and GL state, e.g.:
    # state setter, state getter, getter argument
    " glBlendEquation",  "glGet", "GL_BLEND_EQUATION"

And the code generator would emit:

void retrace_glBlendEquation(...) {
   [...]
    if (is_analysis_enabled) {
        GLint old_mode = 0;
        glGetIntegerv(GL_BLEND_EQUATION, &old_mode);
        if (mode == old_mode) {
             analysis_warning_redudant("mode");
        }
    }
    glBlendEquation(mode)
}

Such table would cover a big portion of GL state, and then we'd use
different tables, or hand-coded exceptions.

Provided the GL implementation is correct (a fair assumption given
that the focus of the GL analysis is applicatio, and not the GL
driver), this would give correct results.

Admitedly, glBlendEquation would be trivial to implement in a
standalone tool tool. But when you start thinking of texture state
(which depends on the active texture unit), the glretrace appraoch
would be exactly the same, but a standalone tool would need to
tracking which is the active texture unit, and per-unit state,

Furthermore the GUI already passes warnings/errors from glretrace. So
passing GL misuse notices would be a natural extension.

> 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.

I really don't wanna add Qt as dependency to any command line tool, as
it raises the bar to build apitrace on Windows/MacOSX much higher, and
while I use the Qt GUI a lot on Linux, I rarely use anything but
glretrace on Windows/MacOSX.

I'm also not sure what benefit we would get from a plugin api that we
don't get from an ordinary shared library with a clean interface.

Jose