[Mesa-dev] [PATCH] st-api: Rework how drawables are invalidated v2

[Jose Fonseca]

----- Original Message -----
> On 06/29/2011 10:10 AM, Jose Fonseca wrote:
> > ----- Original Message -----
> >    
> >> Note that the state trackers themselves don't use atomic stamps on
> >> frame-buffers. Multiple context rendering to the same drawable
> >> should
> >> be protected by the application.
> >>      
> > I known that contexts must not be used by two threads
> > simultaneously, but I don't recall ever reading similar constraint
> > for drawables. Is this written anywhere? Neither glXMakeCurrent
> > man page nor wglMakeCurrent reference page [1] mentions such
> > constraint.
> >
> > Of course, rendering from two contexts to the same drawable will
> > usually be effective only when the context flushes. But AFAICS,
> > the application should not need any additional lbocking.
> >    
> 
> It would make little sense for two contexts to render simultaneously
> to
> the same drawable  without mutex protection, since they wouldn't be
> able
> to tell when the other context flushes. You may be right that it's
> not
> mentioned explicitly, but I think GL implicitly requires application
> mutex locking around shared objects.
> 
> Let's assume two contexts both render to different parts of a
> drawable.
> Context 1 flushes. Context 2 propagates the changes back and then
> overwrites any previous rendering. (Assuming context 2 has local
> drawbuffer storage).
> 
> Also, I think there are a lot of places in mesa, where global objects
> are assumed to be protected by application mutexes, a simple example
> would be _mesa_bufferobj_mapped() where the GL rules say that a
> buffer
> object may not be recursively mapped. However, without an atomic
> (check
> for map and subsequent map) a race condition could allow this to
> happen.
> Fixing up all this would probably require a huge amount of work, and
> we'd be facing a lot of CPU overhead from the atomic operations.
> 
> When I looked at this a while ago I came to the conclusion that the
> only
> sensible interpretation of multithread access to GL / GLX shared
> objects
> would be to have applications responsible for locking.  The EGL spec
> (2.4) provides some guidance into this by claiming that the APIs must
> be
> thread safe, but it is up to the client to protect access to texture
> objects and buffer objects.
> 
> In any case, this would be specific to the state tracker, so the
> state
> tracker api is using an atomic stamp.

OK. After more though, I agree that an application will want to synchronize concurrent writes to shared objects, to ensure consistent behavior. So it should be alright to not add expensive synchronization primtives internally.

I still think that cases such as concurrent reads from shared objects should always work without additional protection. And I suspect that writing with one context and reading from other(s) too.  Probably the best thing to do is to ensure we have test cases for the cases we care/know about, and ensure we handled them correctly.


Jose