and a random apitrace/gallium question..

[Rob Clark]

On Fri, May 31, 2013 at 10:18 AM, José Fonseca <jose.r.fonseca at gmail.com> wrote:
> I'd support such change. Be it through GL_GREMEDY_string_marker, or
> ARB_debug_output's glDebugMessageInsertARB(DEBUG_SOURCE_THIRD_PARTY_ARB,
> ...), or KHR_debug's glPushDebugGroup(). A Gallium interface change would be
> necessary to pass these annotations to the drivers. This discussion would be
> more appropriate in Mesa-dev mailing list though.

I could probably handle the gallium bits to let the driver intercept
the messages.

> For quicker results, you could modify your gallium driver to force flushing
> on every draw, and dump the commands to stderr, and run glretrace with -v
> option. I do this all the time: enabling logging at all levels (state
> tracker, trace driver, etc), and see how they correlate.

well, with the way tiling works on adreno, that isn't so
straightforward to do, at least not without changing the results.
That is why I started wondering about a way to get apitrace-retrace to
insert some debug markers into cmdstream ;-)

BR,
-R

> Jose
>
>
> On Fri, May 31, 2013 at 3:03 PM, Rob Clark <robdclark at gmail.com> wrote:
>>
>> Is there a way to get apitrace retrace to emit gl call #'s for draw
>> calls in some way that the gallium driver could intercept (ie.
>> GL_GREMEDY_string_marker)?  This way when I'm capturing cmdstream from
>> a retrace, I could do something like emit a CP_NOP w/ payload that has
>> the marker to more easily find the spots in the cmdstream which match
>> up to draw calls in the trace..
>>
>> BR,
>> -R
>> _______________________________________________
>> apitrace mailing list
>> apitrace at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/apitrace
>
>