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.
/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
