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

Nicolai Hähnle nhaehnle at gmail.com
Mon Mar 20 22:22:28 UTC 2017


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


More information about the mesa-dev mailing list