[Mesa-dev] [shader-db PATCH 1/5] run: create debug contexts

[Marek Olšák]

On Thu, Dec 31, 2015 at 6:49 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> On Thu, Dec 31, 2015 at 12:36 PM, Matt Turner <mattst88 at gmail.com> wrote:
>> On Thu, Dec 31, 2015 at 12:25 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>>> On Thu, Dec 31, 2015 at 12:17 PM, Matt Turner <mattst88 at gmail.com> wrote:
>>>> On Thu, Dec 31, 2015 at 9:45 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>>>>> On Dec 31, 2015 9:32 AM, "Matt Turner" <mattst88 at gmail.com> wrote:
>>>>>>
>>>>>> On Wed, Dec 30, 2015 at 9:32 PM, Nicolai Hähnle <nhaehnle at gmail.com>
>>>>>> wrote:
>>>>>> > For Gallium-based drivers, this is required for receiving shader
>>>>>> > information
>>>>>> > via debug messages.
>>>>>> > ---
>>>>>>
>>>>>> But that's a Gallium bug, right?
>>>>>>
>>>>>> Ilia sent a similar patch, and in the discussion I think we decided
>>>>>> that what run.c is doing is perfectly fine.
>>>>>
>>>>> It's not a bug at all. Behavioural difference from i965 though. I was happy
>>>>> to let the matter drop as I was the sole user of it. Sounds like there are
>>>>> going to be more now, so this has to be addressed one way or the other.
>>>>
>>>> Could you summarize what that difference is?
>>>
>>> Sure. i965 always generates messages to be sent to KHR_debug
>>> (potentially restricted by some env vars as well). st/mesa only passes
>>> the callback info through for GL debug contexts. The drivers, in turn,
>>> can use the presence/absence of the callback as an indicator as to
>>> whether to perform extra work. Mildly relatedly, currently GL context
>>> flags are not made available in pipe contexts.
>>
>> Okay, I checked the spec again:
>>
>>     Debug output functionality is controlled with the DEBUG_OUTPUT enable
>>     state. If the context is created with the CONTEXT_FLAG_DEBUG_BIT set then
>>     the initial state of DEBUG_OUTPUT is TRUE, otherwise the initial state of
>>     DEBUG_OUTPUT is FALSE. In a debug context, if DEBUG_OUTPUT is disabled the
>>     GL will not generate any debug output logs or callbacks. Enabling
>>     DEBUG_OUTPUT again will enable full debug output functionality. If the
>>     context was created without the CONTEXT_FLAG_DEBUG_BIT and the
>>     DEBUG_OUTPUT is later enabled, the level of debug output logging is
>>     defined by the GL implementation, which may have zero debug output. To
>>     guarantee the full debug output support of the GL implementation the
>>     context should be created with CONTEXT_FLAG_DEBUG_BIT context flag bit
>>     set.
>>
>> I was somewhat surprised to see that it is implementation-defined
>> whether *any* debugging information gets out if a debug context is not
>> created.
>>
>> I'd rather that the "implementation" be "Mesa" and not "i965" or "Gallium".
>>
>> Ian, Timothy, others: Are other people okay with changing core-Mesa to
>> not emit any debug messages if not in a debug context?
>>
>> This would mean that, even if the program has called
>> glEnable(GL_DEBUG_OUTPUT), if not in a debug context there are no
>> debug messages. This is apparently the route Gallium is taking.
>
> FTR, I'd be just as happy with someone adding an driver->Enable
> callback to st/mesa which would call pipe->set_debug_callback with
> null or the "right" thing depending on the enable state. There's no
> existing impl for that callback though and I figured any such impl
> would die in a bikeshed apocalypse. Can't win, don't try :)

I disagree with your pessimism. The callback is a very good idea.

Marek