----- 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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
