On Fri, 2009-02-13 at 10:27 -0800, Jesse Barnes wrote: > On Friday, February 13, 2009 2:33 am Michel Dänzer wrote: > > On Thu, 2009-02-12 at 09:15 -0800, Jesse Barnes wrote: > > > It does, but take a look at that code again. If interrupts are disabled > > > by the timer, we'll capture the frame count. If, sometime later, they're > > > re-enabled, we'll end up in drm_update_vblank_count. And if, between > > > those two points, we've had a DPMS event, the frame counter will have > > > been reset and will now be a lower value, so our drm_update_vblank_count > > > will detect a wraparound. I think any hardware that resets its frame > > > count will be susceptible to this problem unless we make wraparounds > > > harmless. > > > > The modeset ioctl makes wraparounds harmless if used correctly. > > I don't think it does. And you may not be seeing this problem on radeon > because your max_vblank_count is only 0x1fffff, which wouldn't trigger this > behavior.
Which btw looks like it's incorrect for newer Radeons with AVIVO display engine, which seem to have 24 bits in the frame counter registers - Dave/Alex? > 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? > > > 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. > 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. -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
