On Fri, 17 Mar 2017 13:11:31 +0100 Markus Wick <mar...@selfnet.de> wrote:
> Hi gregory, > > Am 2017-03-17 10:25, schrieb Gregory Hainaut: > > diff --git a/src/mesa/main/marshal.c b/src/mesa/main/marshal.c > > index f8cad30..43a70d4 100644 > > --- a/src/mesa/main/marshal.c > > +++ b/src/mesa/main/marshal.c > > @@ -214,6 +218,12 @@ track_vbo_binding(struct gl_context *ctx, GLenum > > target, GLuint buffer) > > */ > > glthread->element_array_is_vbo = (buffer != 0); > > break; > > + case GL_PIXEL_UNPACK_BUFFER: > > + glthread->pixel_unpack_buffer_bound = (buffer != 0); > > + break; > > + case GL_PIXEL_PACK_BUFFER: > > + glthread->pixel_pack_buffer_bound = (buffer != 0); > > + break; > > } > > } > > > > I wonder what shall happen if buffer is not 0, but neither a valid > buffer object. So the glBindBuffer call will fail, and there would still > be no buffer bound. > The comment above this function explains it very well. > > degasus Hello degasus, What shall happen ? => Honestly I don't know. Is the behavior 100% defined when you hit a gl error ? What will happen ? => It depends on the gl transfer operation that will follow the bind. Let's take some examples glBindBuffer(invalid_buffer); // if no buffer is bound, offset_to_pbo will be interpreted as a memory // pointer. Crash is expected (even with gl thread off) glTextureSubImage1D(....., offset_to_pbo); // Now, if the application know that buffer isn't bound (hazardous dev or // using an is/get API to check the status). The application will use // a real memory pointer. It will be fine without glthread. But it will // crash with (the current) glthread. glTextureSubImage1D(....., memory_ptr); If the application is badly/strangely coded, glthread will make it worst. The solution ought to be either fix the app or don't use glthread. Best regards, Gregory _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
