[Mesa-dev] [PATCH 3/4] dri2: Don't call the dri2 flush hook for swapbuffers unless we have a context.

[Eric Anholt]

On Tue, 22 Feb 2011 15:07:45 -0500, Kristian Høgsberg <krh at bitplanet.net> wrote:
> On Tue, Feb 22, 2011 at 2:07 PM, Ian Romanick <idr at freedesktop.org> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On 02/21/2011 02:41 PM, Eric Anholt wrote:
> >> The driver only has one reasonable place to look for its context to
> >> flush anything, which is the current context.  Don't bother it with
> >> having to check.
> >
> > There are some odd interactions here, but I don't completely recall the
> > details.  Kristian implemented this function in this way for a specific
> > reason.  It was either to deal with glXSwapBuffers when no context was
> > current or to deal with glXSwapBuffers on a drawable that isn't bound to
> > a context.  Otherwise the flush method would have been associated with
> > the context (instead of with the screen).
> 
> The background is that tiling/deferred rendering architectures would
> like to ignore glFlush() and only really flush when the user hits
> *SwapBuffer.  Since the driver doesn't actually see the swapbuffer
> call (it goes to the X server, Wayland or the pageflip ioctl), there
> has to be a way for the loader to tell the driver "ok, really flush
> now".  That's what this entry point is for.

The glFlush() skipping hack never seemed appropriate to me.  Sure,
glFlush() is expensive (it's massively expensive for us too, just not
quite as bad apparently), but the spec is awfully clear to my reading:
"all commands that have previously been sent to the GL must complete in
finite time."  So, for example, if I glFlush() then wait just shy of
infinite time and remap a BO that was in use for that rendering, I'd
better not block waiting for the rendering to complete.

Could the glFlush() skipping affect real applications?  I'm not sure if
ARB_sync or OQ users do glFlush()es after OQs they know they're going to
use soon, but it's something I wouldn't be surprised by.  Right now in
our driver we're flushing immediately after a sync or OQ end to get
results sooner, but I sometimes wonder if that's the right thing to be
doing.

> It looks like there could be a problem if the drawable isn't current
> for any context, and Erics patch looks like it just skips it if
> there's no current context which probably fixes some crashes.  It
> seems like it could still crash if there's a current context, but the
> drawable passed to swapbuffers isn't current for any context.  The
> spec says that the flush is only implied if the drawable is current
> for the current context in the current thread, maybe we just need to
> add that check before calling the dri flush entrypoint.

All I cared about here was fixing our driver that didn't implement the
hack -- we have a glFlush() that works, so we're already covered for
required flushing at swapbuffers time (implementing the hook is just
necessary for copysubbuffer and frontbuffer handling, which we do by the
equivalent of calling the driver flush part of glFlush()).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20110222/73f2e5f8/attachment.pgp>