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

[Kenneth Graunke]

On Friday, January 1, 2016 12:29:06 PM PST Marek Olšák wrote:
> 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

Yeah, that seems like the best approach to me.

--Ken
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20160101/660231ec/attachment.sig>