[Mesa-dev] [PATCH] svga: use the debug callback to report issues to the state tracker

[Jose Fonseca]

On 04/12/15 23:08, Ilia Mirkin wrote:
> On Fri, Dec 4, 2015 at 6:00 PM, Jose Fonseca <jfonseca at vmware.com> wrote:
>> On 04/12/15 22:45, Ilia Mirkin wrote:
>>>
>>> On Fri, Dec 4, 2015 at 5:40 PM, Jose Fonseca <jfonseca at vmware.com> wrote:
>>>>
>>>> On 04/12/15 20:04, Ilia Mirkin wrote:
>>>>>
>>>>>
>>>>> On Fri, Dec 4, 2015 at 3:01 PM, Brian Paul <brianp at vmware.com> wrote:
>>>>>>
>>>>>>
>>>>>> On 12/04/2015 12:46 PM, Ilia Mirkin wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Dec 4, 2015 at 2:42 PM, Brian Paul <brianp at vmware.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> +   if (templ->poly_smooth && svga->debug.callback.debug_message) {
>>>>>>>> +      /* note: we always need a % something in the message string */
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Why? Did I mess something up?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> If I write it without the dummy %s I get:
>>>>>>
>>>>>> In file included from
>>>>>> ../../../../src/gallium/auxiliary/util/u_inlines.h:36:0,
>>>>>>                     from svga_pipe_rasterizer.c:29:
>>>>>> svga_pipe_rasterizer.c: In function 'svga_create_rasterizer_state':
>>>>>> ../../../../src/gallium/auxiliary/util/u_debug.h:273:40: error:
>>>>>> expected
>>>>>> expression before ')' token
>>>>>>                            fmt, __VA_ARGS__); \
>>>>>>                                            ^
>>>>>> svga_pipe_rasterizer.c:357:7: note: in expansion of macro
>>>>>> 'pipe_debug_message'
>>>>>>           pipe_debug_message(&svga->debug.callback, CONFORMANCE,
>>>>>>           ^
>>>>>>
>>>>>
>>>>> Hmmmm... so that'd be a "yes" to me messing it up :) I'll have a look
>>>>> to see if there's something simple I can do here. Off-hand it feels
>>>>> like it should be #__VA_ARGS__? Been a while since I looked at the
>>>>> specifics of all this.
>>>>>
>>>>>>
>>>>>>>
>>>>>>> BTW, right now this callback is only set for debug contexts. Perhaps
>>>>>>> that was not an ideal decision... just an FYI though.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> apitrace creates a debug context so that's the main thing for me right
>>>>>> now.
>>>>>> But it might be nice if setting MESA_DEBUG would cause the debug/info
>>>>>> messages to be printed to stderr for those apps that don't use
>>>>>> GL_ARB_debug_output.
>>>>>
>>>>>
>>>>>
>>>>> Yeah, we should probably also throw in Enable/Disable hooks into
>>>>> st/mesa that flip it on/off when flipping GL_DEBUG_OUTPUT (or whatever
>>>>> the enum is).
>>>>>
>>>>> BTW, note that apitrace cuts messages off after 100 of them which is
>>>>> pretty annoying -- I opened an issue at
>>>>> https://github.com/apitrace/apitrace/issues/395 a while back.
>>>>
>>>>
>>>>
>>>> Not just "100", but 100 *per ID*.
>>>>
>>>> Which is very different.
>>>>
>>>> Why is it so annoying?  A patch for an option is welcome anyway BTW.
>>>
>>>
>>> Right, but but an ID is a message. So let's say the message is
>>> "falling back to XYZ", why would you only want to know the first 100
>>> times? Or let's say the message is "shader compiles to XYZ
>>> instructions" -- again, why the first 100 times? In fact, *given* that
>>> you enable these messages, I don't see why it would ever be desirable
>>> to limit them.
>>
>>
>> Isn't it obvious?
>>
>>
>> OpenGL applications are repetitive by nature.  You're bound to have the same
>> error over and over again.
>>
>> Futhermore, some IHVs have messages so frequent that completely overwel
>> everything else.
>>
>> So, when you take a trace of an arbitrary app, and replay e.g., on NVIDIA,
>> you'll get lots and performance hints.  Nevertheless, you'll want to be able
>> to spot rare and more important issues among all that. limiting to a fix
>> number, e.g., 100, means that after a while, they all silence, so that any
>> new issue will stand out.
>>
>> Soemthing that happens all the time is invariably interesting.
>
> I doubt we're going to change each others' mind on this.

I'm not trying to change your mind. You said you couldn't see any reason 
to ever limit, and I gave you an example otherwise.

 > I've
> contemplated throwing prints into mesa, but haven't been sufficiently
> motivated to worry about it.
>
> Like you say, GL applications tend to be repetitive, but they tend to
> have a "startup" phase, and a "do repetitive thing" phase. If the
> message gets triggered > 100x during the startup phase, I don't get to
> see it when I'm actually interested in the results.

Yes, I agree there might be situations where you might want to see all. 
That's why I already agreed to have the apitrace option to cofigure an 
arbitraryly/infinite limit.

> But it's OK, with Matt's run from shader-db, it all works, which was
> the primary motivation for piping this thing through to gallium.

Super.

Jose