[Bug 42035] no way to turn off vsync

[Michal Suchanek]

2011/10/28 Michel Dänzer <michel at daenzer.net>:
> On Don, 2011-10-27 at 23:47 +0200, Michal Suchanek wrote:
>> 2011/10/27 Michal Suchanek <hramrach at centrum.cz>:
>> > 2011/10/27 Michel Dänzer <michel at daenzer.net>:
>> >> On Mit, 2011-10-26 at 21:36 +0200, Michal Suchanek wrote:
>> >>>
>> >>> 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.
>> >>
>> >> Please provide details about a specific scenario where this happens with
>> >> vblank_mode=0.
>> >
>> > Remove all configuration pertaining to vsync/vline wait.
>> >
>> > Run recent radeon driver on 3.0.0-10 Ubuntu kernel.
>> >
>> > Run glxgears. They won't render even a single frame unless the screen
>> > is rotated.
>>
>> Hmm, it does not depend on kernel version.
>>
>> When two X servers are running the second one gets the stuck applications.
>
> Ah! Assuming the first server is running GL clients, that's probably the
> problem described in
> http://lists.freedesktop.org/archives/dri-devel/2011-October/015677.html , starting with 'Also note that running drm_wait_ioctl as DRM_LOCKED is a severe problem that we have to address quickly'.
>

Normally only one at a time but there is aiglx and whatnot.

Also while the second X server gets applications stuck on start the
first gets them stuck on screen blank.

So behaviour varies per X server instance, too.

Your patch comes handy because with vline waits disabled I can start
glxgears even if they would get stuck otherwise by configuring .drirc.

>
>> >>> In the more recent snapshot the tearing prevention is not working
>> >>> which is probably a bug in itself.
>> >>
>> >> Define 'not working'.
>> >
>> > fullscreen glxgears fps are not capped to the screen refresh rate.
>>
>> With the current kernel and driver it seems to work more consistently.
>>
>> Always synced on non-rotated screen and never synced on rotated, mapped or not.
>>
>> At least fresh after booting. There seems to be some period about two
>> weeks long in which the behaviour may vary :-S
>
> Variance over time sounds like counter wraparound issues, but those
> shouldn't affect vline waits...

I only saw vline waits ever affected.

That does not mean vblanks waits aren't. I did not run X server with
vline waits off for an extended period of time yet.

However, both vline waits and vblank waits get stuck in the same X client call.

Thanks

Michal