On Thu, 2007-10-25 at 10:25 -0700, Jesse Barnes wrote: > On Thursday, October 25, 2007 2:02 am Michel Dänzer wrote: > > > It still has some bugs. When moving windows between screens, Mesa > > > seems to lose track of the right vblank count to sync against > > > sometimes, so my test app's calls to glXWaitVideoSyncSGI return > > > immediately. Moving the window back and forth between the screens > > > a few times fixes this problem though, maybe there's a race in the > > > update of base_msc and which pipe to sync against? > > > > There can't really be a race with a single context... If this is > > still an issue with your updated patch, it might be related to some > > of the issues below. > > I was thinking the internal state may be updated by the intelWindowMoved > function after the client calls glXWaitVideoSyncSGI but before it > returned... So not really a race between two threads, but possible > confusion anyway. Or is that not possible?
Shouldn't be - the driver only calls WindowMoved after taking the DRM lock (generally during rendering operations) or when the window is bound to a context. There could probably be races between several threads though, some kind of mutex might be necessary to protect against those. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
