On 17.03.2017 18:59, gregory hainaut wrote:
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
?
Yes, the behavior is 100% defined: GL commands that set an error must
leave the internal state of the GL unmodified (except when the error is
GL_OUT_OF_MEMORY, then all bets are off).
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.
It would be nice if glthread could handle this properly, but I don't
currently see how.
Cheers,
Nicolai
Best regards,
Gregory
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
