On 24 April 2017 at 11:49, Timothy Arceri <[email protected]> wrote: > 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. > 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 _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
