On Tue, 22 Feb 2011 15:07:45 -0500, Kristian Høgsberg <k...@bitplanet.net> wrote: > On Tue, Feb 22, 2011 at 2:07 PM, Ian Romanick <i...@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()).
pgpr86u0EmAOR.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
