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

[Thomas Hellstrom]

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.


/Thomas



> Unfortunately, I can't find such mesa demo: xdemos/corender and xdemos/multictx are close but not quite. A "multictx_mt" version would be necessary.
>    
> Jose
>
> [1] http://msdn.microsoft.com/en-us/library/dd374387(v=vs.85).aspx
>