On Wed, Dec 2, 2015 at 6:45 PM, Ilia Mirkin <[email protected]> wrote: > On Mon, Nov 9, 2015 at 2:02 PM, Ilia Mirkin <[email protected]> wrote: >> On Mon, Nov 9, 2015 at 1:56 PM, Matt Turner <[email protected]> wrote: >>> On Mon, Nov 9, 2015 at 10:46 AM, Ilia Mirkin <[email protected]> wrote: >>>> On Mon, Nov 9, 2015 at 1:35 PM, Matt Turner <[email protected]> wrote: >>>>> On Sun, Nov 8, 2015 at 8:53 PM, Ilia Mirkin <[email protected]> wrote: >>>>>> st/mesa only prints messages in a debug context. Without always enabling >>>>>> the message generation, I don't see a way to hook into the glEnable() to >>>>>> turn it on/off. >>>>>> --- >>>>>> run.c | 1 + >>>>>> 1 file changed, 1 insertion(+) >>>>>> >>>>>> diff --git a/run.c b/run.c >>>>>> index 73e468d..1d8d3b1 100644 >>>>>> --- a/run.c >>>>>> +++ b/run.c >>>>>> @@ -417,6 +417,7 @@ main(int argc, char **argv) >>>>>> EGL_CONTEXT_OPENGL_CORE_PROFILE_BIT_KHR, >>>>>> EGL_CONTEXT_MAJOR_VERSION_KHR, 3, >>>>>> EGL_CONTEXT_MINOR_VERSION_KHR, 2, >>>>>> + EGL_CONTEXT_FLAGS_KHR, EGL_CONTEXT_OPENGL_DEBUG_BIT_KHR, >>>>>> EGL_NONE >>>>>> }; >>>>>> EGLContext core_ctx = eglCreateContext(egl_dpy, cfg, EGL_NO_CONTEXT, >>>>> >>>>> Is this a limitation of st/mesa, or am I using the KHR_debug API >>>>> incorrectly? It's my understanding that you can get KHR_debug messages >>>>> without a debug context by calling glEnable(GL_DEBUG_OUTPUT), and it >>>>> looks like this is supported by the KHR_debug spec. >>>> >>>> But I don't want to be generating the debug info in my driver for no >>>> reason. For example I have a timing-type debug message which gets the >>>> current time (to report how long a sync fence wait takes). This is a >>>> non-free operation that I want to avoid if no one's looking. >>> >>> Huh, looks like we do quite a bit of work before we throw the message >>> away. We could probably make that process a lot simpler. >>> >>>> I can see this both ways... perhaps the more expensive messages should >>>> be keyed on whether it's a debug context and the compiler message >>>> should always be reported. Or perhaps we can just create a debug >>>> context here and be done with it. >>> >>> I guess you can determine that based on >>> DEBUG_SEVERITY_{HIGH,MEDIUM,LOW,NOTIFICATION}? >> >> There's no driver notification about that (that I'm aware). Should there be? >> >> I don't really see how that can work, since I think you're supposed to >> be able to have multiple ones in a group. But I'm new to that API... >> if there's a driver hook that I missed or variable I should be looking >> at, please educate :) >> >> -ilia > > So what's the conclusion here? Request debug contexts, or I keep this > patch local for now until such a time that I can redo the gallium impl > to also pass messages through for non-debug contexts and teach nouveau > to look at context type to determine whether to do potentially > expensive debug things instead of whether there's a debug callback > set? [Aka for the foreseeable future.]
A gallium state flag that enables the compiler messages would be a cleaner solution I think. Marek _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
