On Wed, 8 Jun 2011 12:03:04 -0700, Jesse Barnes <jbar...@virtuousgeek.org> wrote: > On Wed, 8 Jun 2011 19:06:11 +0100 > Chris Wilson <ch...@chris-wilson.co.uk> wrote: > > > Currently, the midlayer dri2 code intercepts vblank_mode=0 SwapBuffers > > and converts it to a CopyRegion request. This prevents the backend from > > doing anything meaningful in this case and typically ends up being > > vsync'ed since the drivers cannot distinguish it from a regular > > CopyRegion request. > > > > Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> > > Cc: Jesse Barnes <jbar...@virtuousgeek.org> > > Cc: Kristian Høgsberg <k...@bitplanet.net> > > --- > > > > Sigh... I broke the patch with a last minute name change. Please pretend > > you never saw the previous patch. > > In hindsight, it would have been better if DRI2 never had a CopyRegion > hook and just let the driver decide what to do given all the params > (i.e. a very generic Swap hook). > > But we don't have that and this looks like a nice addition. It would > be good to add a blurb to the header file about the hook though, since > it could be easily confused with a hook that's supposed to schedule > something and return immediately or something, rather than a "swap now, > tearing be damned" hook.
\o/ making vblank handling more predictable. So, I'm wondering if we want to just drop the no-tearing support in CopyRegion (aka MESA_copy_sub_buffer) that we snuck in back when we didn't really have other no-tearing support. It sounds like the clutter compositors are using another swap control to sync to vblank before dispatching their subbuffer blits. Do we know about compiz? (The latency between vblank signal from OML_sync_control to client wakeup to server wakeup to render engine wakeup might make us miss the vblank. If we do, it means dropping from 60fps to 30fps, though, which is perhaps even nastier than a tear?)
pgpABylNu23wI.pgp
Description: PGP signature
_______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel