[Mesa-dev] [RFC PATCH shader-db 2/2] run: request a debug context

[Marek Olšák]

On Wed, Dec 2, 2015 at 6:45 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> On Mon, Nov 9, 2015 at 2:02 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>> On Mon, Nov 9, 2015 at 1:56 PM, Matt Turner <mattst88 at gmail.com> wrote:
>>> On Mon, Nov 9, 2015 at 10:46 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>>>> On Mon, Nov 9, 2015 at 1:35 PM, Matt Turner <mattst88 at gmail.com> wrote:
>>>>> On Sun, Nov 8, 2015 at 8:53 PM, Ilia Mirkin <imirkin at 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.

Marek