On Wed, Dec 2, 2015 at 1:30 PM, Marek Olšák <mar...@gmail.com> wrote:
> On Wed, Dec 2, 2015 at 7:25 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote:
>> On Wed, Dec 2, 2015 at 1:15 PM, Marek Olšák <mar...@gmail.com> wrote:
>>> On Wed, Dec 2, 2015 at 6:45 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote:
>>>> On Mon, Nov 9, 2015 at 2:02 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote:
>>>>> On Mon, Nov 9, 2015 at 1:56 PM, Matt Turner <matts...@gmail.com> wrote:
>>>>>> On Mon, Nov 9, 2015 at 10:46 AM, Ilia Mirkin <imir...@alum.mit.edu>
>>>>>> wrote:
>>>>>>> On Mon, Nov 9, 2015 at 1:35 PM, Matt Turner <matts...@gmail.com> wrote:
>>>>>>>> On Sun, Nov 8, 2015 at 8:53 PM, Ilia Mirkin <imir...@alum.mit.edu>
>>>>>>>> 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.
>>
>> Not sure how that maps onto the two options I outlined... I guess the
>> latter? (i.e. I keep this patch local)
>
> Yes. Note that PIPE_CONTEXT_DEBUG is meant of hang debugging, not for
> OpenGL debug contexts.
Ah... that's confusing. I guess I'm the only person actually using
this, so not a big deal.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
