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

[gregory hainaut]

On Mon, 27 Mar 2017 16:10:32 +0200
Gregory Hainaut <gregory.hainaut at gmail.com> wrote:

> 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
> >

Hello,

Actually I found another issue on this patch. A deleted buffer is unbound from the context.
So validity must be updated accordingly.

However I have a tricky question, I think that it is possible to share buffers
between multiple contexts. Do we want to support it with glthread ? If yes, it will
require either
* to duplicate the reference counting logic
* Or to use a synchronous delete and peep into the context to check if the buffer is still alive
* Or any better idea ^^

Cheers,
Gregory