On Mon, 2009-02-16 at 10:42 -0800, Jesse Barnes wrote: > On Sunday, February 15, 2009 11:33 pm Michel Dänzer wrote: > > On Fri, 2009-02-13 at 10:27 -0800, Jesse Barnes wrote: > > > Recall our last discussion where I outlined the cases we'd have to deal > > > with in the modeset ioctl if we didn't use get/put to just keep > > > interrupts on around the calls: > > > > But we are intending to keep them on around the calls. So the problem is > > that you are disabling the IRQ in between? Maybe a solution could be not > > to mess with the counter when disabling/enabling the IRQ. It needs to be > > guarded by the modeset ioctl anyway, so shouldn't that work? > > The current problem isn't a disable between modeset ioctls, it's a disable > followed by a counter reset of any kind (modeset ioctls or not), since > the "last" count we track is just done in the disable function, not in the > modeset ioctl. Doing in in the modeset ioctl instead may be possible, but as > I said there are lots of cases to deal with.
Isn't the actual problem that drm_irq_uninstall() updates last_vblank? If it didn't (and the modeset ioctl is properly called around the disabling and re-enabling of the IRQ), wouldn't it just work? > > > > > Can you think of a case where those frames would matter? > > > > > > > > E.g. the GLX_OML_sync_control spec says 'The graphics Media Stream > > > > Counter (or graphics MSC) is a counter that is unique to the graphics > > > > subsystem and increments for each vertical retrace that occurs.' > > > > Vertical retraces that occur while nobody's listening may not matter in > > > > simple cases, but that doesn't mean they're never relevant. > > > > > > But that doesn't say anything about whether the frame count must stay > > > accurate while apps aren't running (i.e. doing anything with video/GL). > > > > The other side of this coin is that it doesn't mention this as a special > > case, so users of the extension can assume that the count increases > > regardless. > > But apps can't assume that; frames *will* be lost when the monitor goes off, > for as long as the monitor is off. So if an app isn't actively using the > framecount for something it can't count on a given value. Right? Again, I disagree with the notion that because something may not work under some (in this case exceptional) circumstances, we shouldn't try to make it work whenever possible. You asked for examples; well, it's pretty easy to come up with examples which work according to the spec but not with your proposal. E.g. consider an app which calls glXGetSyncValuesOML every n seconds. If n is larger than the number of seconds we wait before disabling vblank interrupts, the MSC value doesn't increase at the rate returned by glXGetMscRateOML. I'd be interested in Ian Romanick's opinion on this. -- Earthling Michel Dänzer | http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
