[Mesa-dev] [PATCH 3/4] main/get: make KHR_debug enums available everywhere

Emil Velikov emil.l.velikov at gmail.com
Tue Sep 15 04:18:12 PDT 2015


On 14 September 2015 at 19:11, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> On Mon, Sep 14, 2015 at 1:56 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> On 14 September 2015 at 18:39, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>>> On Mon, Sep 14, 2015 at 1:35 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>>>> From: Matthew Waters <ystreet00 at gmail.com>
>>>>
>>>> Although GL_CONTEXT_FLAGS is not explicitly added by KHR_debug,
>>>> it contains,
>>>>
>>>>     "It is implementation defined how much debug output is generated if
>>>>     the context was created without the CONTEXT_DEBUG_BIT set. This is a new
>>>>     query bit added to the existing GL_CONTEXT_FLAGS state to specify whether
>>>>     the context was created with debug enabled."
>>>>
>>>> implying the GL_CONTEXT_FLAGS parameter is supported whenever KHR_debug
>>>> is also supported.
>>>>
>>>> v2 [Emil Velikov] Rebase.
>>>>
>>>> Signed-off-by: Matthew Waters <ystreet00 at gmail.com>
>>>> Signed-off-by: Emil Velikov <emil.l.velikov at gmail.com>
>>>> ---
>>>>  src/mesa/main/get_hash_params.py | 24 ++++++++++++------------
>>>>  1 file changed, 12 insertions(+), 12 deletions(-)
>>>>
>>>> diff --git a/src/mesa/main/get_hash_params.py b/src/mesa/main/get_hash_params.py
>>>> index c06835a..3907b2f 100644
>>>> --- a/src/mesa/main/get_hash_params.py
>>>> +++ b/src/mesa/main/get_hash_params.py
>>>> @@ -124,6 +124,18 @@ descriptor=[
>>>>
>>>>  # GL_EXT_texture_filter_anisotropic
>>>>    [ "MAX_TEXTURE_MAX_ANISOTROPY_EXT", "CONTEXT_FLOAT(Const.MaxTextureMaxAnisotropy), extra_EXT_texture_filter_anisotropic" ],
>>>> +
>>>> +# GL_KHR_debug (GL 4.3)/ GL_ARB_debug_output
>>>> +  [ "DEBUG_LOGGED_MESSAGES", "LOC_CUSTOM, TYPE_INT, 0, NO_EXTRA" ],
>>>> +  [ "DEBUG_NEXT_LOGGED_MESSAGE_LENGTH", "LOC_CUSTOM, TYPE_INT, 0, NO_EXTRA" ],
>>>> +  [ "MAX_DEBUG_LOGGED_MESSAGES", "CONST(MAX_DEBUG_LOGGED_MESSAGES), NO_EXTRA" ],
>>>> +  [ "MAX_DEBUG_MESSAGE_LENGTH", "CONST(MAX_DEBUG_MESSAGE_LENGTH), NO_EXTRA" ],
>>>> +  [ "MAX_LABEL_LENGTH", "CONST(MAX_LABEL_LENGTH), NO_EXTRA" ],
>>>> +  [ "MAX_DEBUG_GROUP_STACK_DEPTH", "CONST(MAX_DEBUG_GROUP_STACK_DEPTH), NO_EXTRA" ],
>>>> +  [ "DEBUG_GROUP_STACK_DEPTH", "LOC_CUSTOM, TYPE_INT, 0, NO_EXTRA" ],
>>>> +
>>>> +# GL 3.0
>>>> +  [ "CONTEXT_FLAGS", "CONTEXT_INT(Const.ContextFlags), extra_version_30" ],
>>>
>>> Does this need to become NO_EXTRA? or "extra_version_30_or_es" or
>>> something? Not sure exactly which contexts you're hoping it to be
>>> exposed for...
>>>
>> Afaict CONTEXT_FLAGS does not exists in GLES up-to and including 3.1 -
>> so extra_version_30_or_es does not seem correct. The extension
>> requirement is OpenGL 1.1, yet considering it's been like that
>> (version_30) despite the quoted spec, I'm wondering if we shouldn't
>> just leave it where it was ?
>
> Note that extra_version_30 just checks for ctx->Version >= 30, nothing
> to do with desktop vs es contexts. I don't know what's desired here,
> but I'm fairly sure that it's not this :)

It's a two fold 'issue':
On desktop GL, the following quote applies

    ... It is implementation defined how much debug output is generated if
    the context was created without the CONTEXT_DEBUG_BIT set. This is a new
    query bit added to the existing GL_CONTEXT_FLAGS state to specify whether
    the context was created with debug enabled.

Which afaict, can be interpreted as either "CONTEXT_FLAGS query should
be _made_ available" or "CONTEXT_FLAGS should be extended _if_
available". Slightly leaning towards the former. How does others feel
?

On the GLES front the following hunk is applicable

    In OpenGL ES versions prior to and including ES 3.1 there is no
    CONTEXT_FLAGS state and therefore the CONTEXT_FLAG_DEBUG_BIT cannot be
    queried.

I.e. one does not know about it.

So considering that the former has been (not strictly) 'broken' and
this patch targets GLES, I think we should omit that hunk. The reason
why I kept it in was just to inspire a discussion on the topic :)

Thanks
Emil


More information about the mesa-dev mailing list