[Bug 42035] no way to turn off vsync

[Michal Suchanek]

2011/11/3 Michel Dänzer <michel at daenzer.net>:
> On Mit, 2011-11-02 at 18:55 +0100, Michal Suchanek wrote:
>> 2011/11/2 Michel Dänzer <michel at daenzer.net>:
>> > On Die, 2011-11-01 at 08:50 +0100, Michal Suchanek wrote:
>> >>
>> >> 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.
>
> That's with sync to vblank enabled in the compiz configuration; it's not
> that simple because there's only a single Composite Overlay Window
> covering the whole X screen, so without vline waits, compiz's rendering
> can only really avoid tearing on one monitor.

That's stupid of Compiz to create only one window.

Anyway, X  does that too, at least with freshly started X server.

That's probably fallout of the clone mode linked sync.

X starts in clone mode.

I then run a script that turns off the second screen, straightens the
main screen from the clone mode and makes it primary, and then turns
on the other screen again.

Running glxgears then makes them sync to the primary even when on the
secondary screen. Bad.

Switching to another X server stops glxgears completely. Bad.

Switching back makes the glxgears sync properly.

Switching screens on and off with dpms also makes the glxgears sync to
the right screen, and does not even stop them.

>
>
>> > 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.
>
> That didn't really make sense, but you finally offered a little more
> information on IRC:
>
>        <hramrach> well, maybe whole X stalls. I can't tell because with
>        vline waits I only saw this with screens off
>
> That sounds like maybe the vline waits stall indefinitely because the
> CRTC is disabled, in which case the patch below (only compile tested)
> might help. (Though in that case I'd expect the GPU lockup detection to
> kick in and reset the GPU?)

I can easily make application stall even with the patch applied.

However, it happens on VT switch, not when switching off the screens with dpms.
As the dpms issue with vline waits happens about every other week it's
hard to tell if the patch fixes that.

Thanks

Michal