[Mesa-dev] gallium st incorrect drawable <-> context bindings.
wallbraker at gmail.com
Tue May 24 03:13:17 PDT 2011
On Tue, May 24, 2011 at 11:53 AM, Thomas Hellstrom
<thellstrom at vmware.com> wrote:
> 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
> 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.
> Author: Jakob Bornecrantz <wallbraker at gmail.com> 2010-12-01 05:04:25
> Committer: Marek Olšák <maraeo at 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,
> Follows: snb-magic
> st/dri: Track drawable context bindings
> Needs to track this ourself since because we get into a race condition
> 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
> current. st/dri make current flushes the old context, which calls back
> 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
> framebuffers since we have not called make current yet, it asserts.
More information about the mesa-dev