On Tue, May 24, 2011 at 11:53 AM, Thomas Hellstrom <thellst...@vmware.com> wrote: > Hi, > > I'm not sure when this use of drawable <-> context bindings started, but the > below commit uses an invalid assumption to fix a problem the root cause of > which is also an invalid assumption. > > It's incorrect to associate a drawable with a context. > A drawable may have multiple contexts bound to it, and attempts to associate > a drawable with a single context will fail miserably in a multithreading > environment. > > This means that the fix below should be reverted, and > drawable->driContextPriv should never have been used in the first place. It > should nave no users whatsoever except old dri1 code using it as a possible > swapbuffer context, but even that usage is undesired. > > Furthermore, the st interface that uses a specific context to notify about > drawable invalidation is also incorrect. There should be no context > associated with that.
You are right, we need a list of contexts, and notify all of the contexts. Cheers Jakob. > > /Thomas > > > > Author: Jakob Bornecrantz <wallbra...@gmail.com> 2010-12-01 05:04:25 > Committer: Marek Olšák <mar...@gmail.com> 2011-02-20 16:31:48 > Parent: 9e872a5865c66ed0a518dd1c6c54e72f3afa71f1 (i965: Fix VB packet reuse > when offset for the new buffer isn't stride aligned.) > Child: 3377faffcdc7227bd27381894c87c7600547744f (i965: Zero the offset into > the vbo when uploading non-interleaved) > Branches: master, remotes/origin/arb_robustness, > remotes/origin/arb_sampler_objects, remotes/origin/master, > remotes/origin/nvc0, remotes/origin/pipe-video, > remotes/origin/remove-driver-date > Follows: snb-magic > Precedes: > > st/dri: Track drawable context bindings > > Needs to track this ourself since because we get into a race condition > with > the dri_util.c code on make current when rendering to the front buffer. > > This is what happens: > Old context is rendering to the front buffer. > > App calls MakeCurrent with a new context. dri_util.c sets > drawable->driContextPriv to the new context and then calls the driver > make > current. st/dri make current flushes the old context, which calls back > into > st/dri via the flush frontbuffer hook. st/dri calls dri loader flush > frontbuffer, which calls invalidate buffer on the drawable into st/dri. > > This is where things gets wrong. st/dri grabs the context from the dri > drawable (which now points to the new context) and calls invalidate > framebuffer to the new context which has not yet set the new drawable as > its > framebuffers since we have not called make current yet, it asserts. > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
