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 <imir...@alum.mit.edu> wrote: > > On Thu, Dec 31, 2015 at 12:36 PM, Matt Turner <matts...@gmail.com> wrote: > >> On Thu, Dec 31, 2015 at 12:25 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > >>> On Thu, Dec 31, 2015 at 12:17 PM, Matt Turner <matts...@gmail.com> wrote: > >>>> On Thu, Dec 31, 2015 at 9:45 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > >>>>> On Dec 31, 2015 9:32 AM, "Matt Turner" <matts...@gmail.com> wrote: > >>>>>> > >>>>>> On Wed, Dec 30, 2015 at 9:32 PM, Nicolai Hähnle <nhaeh...@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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev