On 05/31/2017 04:43 PM, Chad Versace wrote: > This function never occurs in the callchain of a GL function. It occurs > only in the callchain of eglCreate*Surface and the analogous paths for > GLX. Therefore, even if a thread does have a bound GL context, > emitting a GL error here is wrong. A misplaced GL error, when no GL > call is made, can confuse clients.
This seems right. What seems wrong, however, is that the callers ignore the potentially NULL return. intelCreateBuffer (intel_screen.c) could easily return false when it gets NULL, but it merrily plugs along. This patch clearly makes things better, but I'd love to see a follow up that fixes the other pre-existing problems. Reviewed-by: Ian Romanick <[email protected]> > > Cc: [email protected] > --- > src/mesa/drivers/dri/i965/intel_fbo.c | 6 +----- > 1 file changed, 1 insertion(+), 5 deletions(-) > > diff --git a/src/mesa/drivers/dri/i965/intel_fbo.c > b/src/mesa/drivers/dri/i965/intel_fbo.c > index d69b921..a24ddd0 100644 > --- a/src/mesa/drivers/dri/i965/intel_fbo.c > +++ b/src/mesa/drivers/dri/i965/intel_fbo.c > @@ -440,13 +440,9 @@ intel_nop_alloc_storage(struct gl_context * ctx, struct > gl_renderbuffer *rb, > struct intel_renderbuffer * > intel_create_winsys_renderbuffer(mesa_format format, unsigned num_samples) > { > - GET_CURRENT_CONTEXT(ctx); > - > struct intel_renderbuffer *irb = CALLOC_STRUCT(intel_renderbuffer); > - if (!irb) { > - _mesa_error(ctx, GL_OUT_OF_MEMORY, "creating renderbuffer"); > + if (!irb) > return NULL; > - } > > struct gl_renderbuffer *rb = &irb->Base.Base; > irb->layer_count = 1; > _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
