On Tuesday, February 17, 2009 9:27 am Jesse Barnes wrote:
> On Tuesday, February 17, 2009 9:04 am Michel Dänzer wrote:
> > 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?
>
> No, this happens w/o an uninstall, it's just due to wraparound being added
> between the disable timer & the next drm_vblank_get.
>
> > 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.
>
> Yes, that might fail. It might also behave strangely if the driver decides
> to reduce the refresh rate on the fly too.
Btw I don't have a problem with keeping this functionality, but we need to fix
it (the problem above is the only one I'm aware of atm). That means:
1) removing the last count stuff and providing a "disable timer" knob
2) changing the wait condition to handle spurious wraparound
3) fixing the last vblank count code in the core to handle counter resets
properly
I don't particularly care which one we choose; I think the patch I posted to
start this thread is a bugfix anyway, and (1) would be pretty trivial too.
Maybe you want to take a stab at (3)?
As to your example, I wasn't looking for theoretical issues, but real apps
that would depend on this behavior. I haven't played with many video apps,
so I'm not sure if what you outlined is common behavior, or if apps typically
care about much higher frequencies...
Thanks,
--
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
