[Mesa-dev] [PATCH 1/4] mesa: only lock framebuffer in compat profile

[Emil Velikov]

On 24 April 2017 at 11:49, Timothy Arceri <tarceri at itsqueeze.com> wrote:
> On 24/04/17 20:27, Emil Velikov wrote:
>>
>> Hi Tim,
>>
>> On 24 April 2017 at 06:28, Timothy Arceri <tarceri at itsqueeze.com> wrote:
>>
>>> So in theory we could have a flag that is set by the bind
>>> functions to decide if to lock or not. However we only
>>> expose GL_EXT_framebuffer_object in compat profile so this
>>> change just uses that to decide if we should lock or not.
>>> ---
>>>   src/mesa/main/fbobject.c    | 45 ++++++++++++++++++++++++++--------
>>>   src/mesa/main/framebuffer.c | 60
>>> +++++++++++++++++++++++++++++++--------------
>>>   2 files changed, 76 insertions(+), 29 deletions(-)
>>>
>>> diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
>>> index d486d01..0f2298d 100644
>>> --- a/src/mesa/main/fbobject.c
>>> +++ b/src/mesa/main/fbobject.c
>>> @@ -145,22 +145,28 @@ _mesa_lookup_renderbuffer_err(struct gl_context
>>> *ctx, GLuint id,
>>>    * Helper routine for getting a gl_framebuffer.
>>>    */
>>>   struct gl_framebuffer *
>>>   _mesa_lookup_framebuffer(struct gl_context *ctx, GLuint id)
>>>   {
>>>      struct gl_framebuffer *fb;
>>>
>>>      if (id == 0)
>>>         return NULL;
>>>
>>> -   fb = (struct gl_framebuffer *)
>>> -      _mesa_HashLookup(ctx->Shared->FrameBuffers, id);
>>> +   if (ctx->API != API_OPENGL_COMPAT) {
>>
>> If the locking depends on GL_EXT_framebuffer_object shouldn't we check
>> for it instead of ctx->API?
>
>
> It's always and only enabled for compat so that was good enough IMO.
> Although Nicolai has pointed out we could have shared context that are
> different profiles so I don't think this is going to work.
>
Transitive dependencies are bad. If A depends on B express that either
in code or comment.
X days down the line you won't recall why the COMPAT check is here.

-Emil