2011/10/26 Michel Dänzer <[email protected]>: > On Mit, 2011-10-26 at 14:16 +0200, Michal Suchanek wrote: >> 2011/10/26 Michel Dänzer <[email protected]>: >> > On Mit, 2011-10-26 at 12:05 +0200, Michal Suchanek wrote: >> >> 2011/10/26 Michel Dänzer <[email protected]>: >> >> > On Die, 2011-10-25 at 20:41 +0200, Michal Suchanek wrote: >> >> >> 2011/10/25 Michel Dänzer <[email protected]>: >> >> >> > 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 _______________________________________________ xorg-driver-ati mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-driver-ati
