[Mesa-dev] [PATCH] st-api: Rework how drawables are invalidated v2
thellstrom at vmware.com
Wed Jun 29 01:46:04 PDT 2011
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  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
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.
> 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.
>  http://msdn.microsoft.com/en-us/library/dd374387(v=vs.85).aspx
More information about the mesa-dev