[Bug 42035] no way to turn off vsync

[Michal Suchanek]

2011/10/26 Michel Dänzer <michel at daenzer.net>:
> On Mit, 2011-10-26 at 14:16 +0200, Michal Suchanek wrote:
>> 2011/10/26 Michel Dänzer <michel at daenzer.net>:
>> > On Mit, 2011-10-26 at 12:05 +0200, Michal Suchanek wrote:
>> >> 2011/10/26 Michel Dänzer <michel at daenzer.net>:
>> >> > On Die, 2011-10-25 at 20:41 +0200, Michal Suchanek wrote:
>> >> >> 2011/10/25 Michel Dänzer <michel at daenzer.net>:
>> >> >> > On Mon, 2011-10-24 at 23:23 +0200, Michal Suchanek wrote:
>> >> >> >> With this patch it should be at least possible to turn off all this
>> >> >> >> when it does not work.
>> >> >> >
>> >> >> > Exactly. So, have you had a chance to try it?
>> >> >>
>> >> >> I installed the packages I built yesterday. The patch has no visible effect.
>> >> >
>> >> > Well, I do see an effect in the log file:
>> >> >
>> >> > [2558366.995] (==) RADEON(0): SwapBuffers wait for vblank: disabled
>> >> >
>> >> >
>> >> >> > Does it address your bug report?
>> >> >>
>> >> >> I am not quite sure.
>> >> >
>> >> > The above means the thing the bug report complains about being
>> >> > impossible to disable is disabled.
>> >>
>> >> Still it is disabled without the patch too, which it supposedly should not.
>> >
>> > I don't see how that can be the case with a driver built from unpatched
>> > upstream, without (the equivalent of) Option "SwapbuffersWait" "off".
>>
>> I don't have that in Xorg.conf and the only patch Ubuntu adds fixes up
>> the -background none option.
>>
>> So I would suspect that in this particular driver snapshot vblank is
>> broken in entirely new way which completely evades whatever the patch
>> is doing.
>
> Option "SwapbuffersWait" has nothing to do with sync to vblank (which is
> controlled via the driconf setting vblank_mode). It only controls
> whether tearing is avoided for DRI2 buffer swaps without sync to vblank.

Ideally I would like no tearing and no vblank sync but both tearing
prevention in the radeon driver and sync to vblank can lead to
applications getting stuck in the  X server.

However, the tearing prevention does in practice vblank sync, at least
for fullscreen windows. So the practical difference is minimal since
most GL rendering would occur in large windows.

Applying the patch to the 'stable' Ubuntu package
(xserver-xorg-video-radeon 1:6.14.99~git20110811.g93fc084-0ubuntu1)
gives the expected results. Without the patch rendering is always
synced, with the patch and vblank wait enabled rendering on the
primary screen on DVI-1 gets stuck in the DRI2GetBuffersWithFormat
call, even when the window is initially created on DVI-0 and moved to
DVI-1. I guess it matters what aoutput is used, not which screen is
primary.

So there are multiple issues here.

The tearing prevention in the X server may lead to applications
getting stuck sometimes. It cannot be configured at runtime.

In the more recent snapshot the tearing prevention is not working
which is probably a bug in itself.

The patch disables the tearing prevention in favour of DRI vblank sync
which can be turned on and off per application and should be
configurable at runtime through some GL extension. When enabled it
leads to applications getting stuck in the X server.

Thanks

Michal