On 24/04/17 20:27, Emil Velikov wrote:
Hi Tim, On 24 April 2017 at 06:28, Timothy Arceri <[email protected]> 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
_______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
