[Bug 42035] no way to turn off vsync

[Michal Suchanek]

2011/11/2 Michel Dänzer <michel at daenzer.net>:
> On Die, 2011-11-01 at 08:50 +0100, Michal Suchanek wrote:
>> 2011/10/24 Michel Dänzer <michel at daenzer.net>:
>> > On Mon, 2011-10-24 at 14:00 +0200, Michal Suchanek wrote:
>> >> 2011/10/24 Michel Dänzer <michel at daenzer.net>:
>> >> > On Don, 2011-10-20 at 12:16 +0200, Michal Suchanek wrote:
>> >> >> On 20 October 2011 11:38,  <bugzilla-daemon at freedesktop.org> wrote:
>> >> >> > https://bugs.freedesktop.org/show_bug.cgi?id=42035
>> >> >> >
>> >> >> > --- Comment #1 from Michel Dänzer <michel at daenzer.net> 2011-10-20 02:38:29 PDT ---
>> >> >> >> This should be runtime configurable, preferably per-application like dri.
>> >> >> >
>> >> >> > That would require some xserver dri2 changes first, to allow the driver to tell
>> >> >> > the different cases apart. There's been some discussion about this on the
>> >> >> > xorg-devel list, started by Chris Wilson.
>> >> >>
>> >> >> Anyone can point at the discussion or say what the problem is with this?
>> >> >
>> >> > Actually, the radeon driver patch below might be good enough, at least
>> >> > for now. It disables Option "SwapBuffersWait" by default when the real
>> >> > sync-to-vblank functionality is working. There should be no need for the
>> >> > vline waits for DRI2 in that case.
>
> [...]
>
>> I am using a X server with this patch applied now.
>>
>> It merely picks a sensible default but it's quite helpful.
>>
>> I could configure my X server to disable the vline sync but since it
>> is not really helpful in its current state and per-application
>> configurable replacement exists I guess this would be nice to have in
>> the driver.
>
> Actually, I'm not sure anymore it's a good idea, as it results e.g. in
> horrible tearing with fullscreen video playback in compiz with multiple
> monitors enabled.

Then perhaps compiz or the video player ignore the vblank sync?

Applications can control it themselves so can set the option poorly, too.

>
> Also, I still can't see how having this option enabled can result in 3D
> clients (only, as opposed to the whole X display) hanging. You'd need to
> gather more information about that.

Only the 3D clients are waiting for the vblank that is not signalled.

Or what am I missing?

Of course, it should come or the waiting clients should be released if
there is no vblank to wait for but that's an issue with the vline
waits too, only happens non-deterministically and applications can't
control the behaviour.

Thanks

Michal