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

[Ilia Mirkin]

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

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.

  -ilia