[Mesa-dev] [PATCH 2/2] glx/dri2: Add support for adaptive vsync

[Lauri Kasanen]

On Wed, 12 Feb 2014 00:07:43 -0800
Eric Anholt <eric at anholt.net> wrote:

> >> On Sun, 15 Dec 2013 12:38:28 +0200
> >> Lauri Kasanen <cand at 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