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

[Timothy Arceri]

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.

> 
> Thanks
> Emil
>