On Wed, 12 Feb 2014 00:07:43 -0800 Eric Anholt <e...@anholt.net> 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. True, it won't catch a single-frame hickup currently. But the situation I thought of was different: you usually hit the refresh rate, but then a heavy level / cutscene / animation happens, which would drop you to 30 fps for several minutes, as long as the heavier workload is present. This has downsides for latency and the perception of smoothness. - Lauri _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
