Lauri Kasanen <c...@gmx.com> writes: > On Thu, 2 Jan 2014 11:20:13 +0200 > Lauri Kasanen <c...@gmx.com> wrote: > >> On Sun, 15 Dec 2013 12:38:28 +0200 >> Lauri Kasanen <c...@gmx.com> wrote: >> >> > There is a GLX extension for this behavior, glx_swap_control_tear, which >> > mesa doesn't >> > support ATM. But as usual, even after it becomes supported, there will be >> > thousands >> > of applications that won't add support for it, necessitating the need for >> > a user >> > override. >> >> Ping. Patch 1 is already merged. > > Ping 2.
I don't think this is what people are thinking of when they ask for GLX_swap_control_tear. The model behind swap_control_tear, as far as I've heard, is that you've got a workload that should be hitting refresh rate, but then something happens (a shader recompile, for example). So one frame misses vsync, and you want that frame to get presented as soon as possible rather than at the next vblank. Instead, this patch has that swap still presented vsynced next frame, late, but then the frame after that (that you predict should be back to hitting refresh rate) ends up tearing even when it finished on time. It seems worse than what would have happened without the patch. There's also the fact that gettimeofday() has only a very limited relationship to when frames are ready to be flipped.
pgpHNycUxQOh5.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
