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

[Gregory Hainaut]

Hello,

Sorry I was in vacation. I will update my patch with a hash map to
trace buffer creation/destruction.

Cheers,
Gregory

On 3/20/17, Nicolai Hähnle <nhaehnle at gmail.com> wrote:
> On 20.03.2017 14:33, Markus Wick wrote:
>> Am 2017-03-20 14:21, schrieb Nicolai Hähnle:
>>> On 17.03.2017 18:59, gregory hainaut wrote:
>>>> 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.
>>
>> The dispatcher thread needs a map of all valid buffer objects. So we
>> need to update such a map on all glGenBuffers/glDeleteBuffers calls. So
>> the overhead will be the map lookup on all affected glBindBuffer calls.
>
> You're right. Ridiculous details of the OpenGL spec make this
> interesting, actually, because Section 6.1 (Creating and Binding Buffer
> Objects) of the OpenGL 4.5 (Compability Profile) spec says:
>
> "A buffer object is created by binding an unused name to a buffer
> target. The binding is effected by calling
>
>      void BindBuffer( enum target, uint buffer );
>
> target must be one of the targets listed in table 6.1. If the buffer
> object named buffer has not been previously bound, or has been deleted
> since the last binding, the GL creates a new state vector, initialized
> with a zero-sized memory buffer and comprising all the state and with
> the same initial values listed in table 6.2."
>
> But this language is different from that for core profiles, where a call
> to glGenBuffers is required. So in this case, the compatibility profile
> spec is actually better for performance :/
>
> Cheers,
> Nicolai
>