[Mesa-dev] [PATCH] mesa glthread: allow asynchronous pixel transfer operation when a buffer is bound

[Nicolai Hähnle]

On 17.03.2017 18:59, gregory hainaut wrote:
> On Fri, 17 Mar 2017 13:11:31 +0100
> Markus Wick <markus at 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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>