[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