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. > > > > 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? > > That's why I asked for an example. If we assume it's important in > > some cases, we can still remove the update_vblank_counter code and > > just provide a knob to prevent interrupts from ever being disabled. > > One could also question why we're bothering to disable vblank interrupts > at all, given that they'll be enabled all the time with tear-free > compositing anyway, which will hopefully be the usual case in the long > run. Yeah, I certainly hope tear-free will be the usual case (even in the short run!), but with the hacked up compiz I've been running for testing, I don't need interrupts all the time. vblank interrupts are only enabled when needed (i.e. when a page flip is pending). That only happens when a screen update has occurred, and, on my system at least, when I'm idle no screen damage occurs, which means no page flips or interrupts. So interrupt mitigation is still a good idea. -- Jesse Barnes, Intel Open Source Technology Center ------------------------------------------------------------------------------ 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
