On Thu, 2010-02-18 at 05:16 -0800, Francisco Jerez wrote: > Keith Whitwell <kei...@vmware.com> writes: > > > On Thu, 2010-02-18 at 00:15 -0800, Keith Whitwell wrote: > >> On Wed, Feb 17, 2010 at 10:39 PM, Francisco Jerez > >> <curroje...@kemper.freedesktop.org> wrote: > >> > Module: Mesa > >> > Branch: master > >> > Commit: f455ca6490fcb65781b21f81c7117bd923e250d1 > >> > URL: > >> > http://cgit.freedesktop.org/mesa/mesa/commit/?id=f455ca6490fcb65781b21f81c7117bd923e250d1 > >> > > >> > Author: Francisco Jerez <curroje...@riseup.net> > >> > Date: Tue Feb 16 17:21:10 2010 +0100 > >> > > >> > st/mesa: Make the frontbuffer visible on st_flush(PIPE_FLUSH_FRAME). > >> > > >> > So far the frontbuffer was only being flushed on st_glFlush and > >> > st_glFinish, however, a co-state tracker may need to make sure that > >> > any frontbuffer changes are already on its way to the actual front. > >> > > >> > The dri2 state tracker will need this for event-driven GL applications > >> > to resize properly (It could also be done calling > >> > "dri_flush_frontbuffer", > >> > but that way we would flush unnecessarily in the double-buffered case). > >> > > >> > Additionally this patch avoids flushing the mesa rendering cache if > >> > PIPE_FLUSH_RENDER_CACHE wasn't specified. > >> > > >> > --- > >> > > >> > src/mesa/state_tracker/st_cb_flush.c | 15 ++++++--------- > >> > 1 files changed, 6 insertions(+), 9 deletions(-) > >> > > >> > diff --git a/src/mesa/state_tracker/st_cb_flush.c > >> > b/src/mesa/state_tracker/st_cb_flush.c > >> > index 1329f80..0ddfce4 100644 > >> > --- a/src/mesa/state_tracker/st_cb_flush.c > >> > +++ b/src/mesa/state_tracker/st_cb_flush.c > >> > @@ -91,7 +91,8 @@ display_front_buffer(struct st_context *st) > >> > void st_flush( struct st_context *st, uint pipeFlushFlags, > >> > struct pipe_fence_handle **fence ) > >> > { > >> > - FLUSH_CURRENT(st->ctx, 0); > >> > + if (pipeFlushFlags & PIPE_FLUSH_RENDER_CACHE) > >> > + FLUSH_CURRENT(st->ctx, 0); > >> > >> This is incorrect. Without this call, st->pipe->flush() will be > >> called with the VBO buffers still mapped, which is illegal. This > >> needs to be undone. > > > > OK, I've backed this hunk out. Sorry for not spotting this earlier - > > the interactions between the VBO module and driver buffer managers is > > definitely a fragile area. > > > Okay, thanks for pointing this out, and *sorry* for my impatience and > for not giving a clear statement of the motivations behind that hunk: We > really don't want to flush the VBO rendering caches in that case, > there's no need to, and it can lead to a recursive call into the VBO > module because we were already called by it, and right now it isn't > fully reentrant. > > With your and José's arguments in mind, I don't think my st_flush > changes made any sense, it's a bad design even with a new > "PIPE_FLUSH_FRONT" flag (that isn't the pipe driver business, is it?). > > IMHO a new "st_notify_invalidate" interface would be a somewhat better > idea: It would mean that the windowing system is about to throw its > current buffers away and allocate new ones, so it would let the state > tracker flush whatever it needs to. > > I've reverted both patches until we consider this issue discussed. Any > better ideas?
What would help me a lot is to create or modify one of the mesa demos to illustrate the problem you're trying to fix. I think I'm getting an understanding now, but there is still possible ambiguity and having a concrete example may help get us all onto the same page about what the goal of the changes is. I think I understand it now, but I'm still not sure how much there is we can do. It sounds like: App renders half a frame to a front buffer DRI2 receives somehow a notification of window size change DRI2 wants to destroy and recreate the window buffers --> Your change would try and flush the pipe driver here DRI2 ?? creates new front buffer ?? DRI2 ?? blits contents of old front to new front ?? DRI2 ?? destroys old front buffer ?? App keeps on rendering somehow the second half of the front buffer. I'm unsure how this would all work in practice, and a concrete example of an app doing something sensible in these circumstances would help me better understand what problem you're fixing. Keith ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
