On Tue, 2009-02-17 at 17:34 -0800, Jesse Barnes wrote: > On Tuesday, February 17, 2009 5:26 pm Ian Romanick wrote: > > Jesse Barnes wrote: > > > On Tuesday, February 17, 2009 4:10 pm Ian Romanick wrote: > > >> Stepping back, there are two separate axes (Are vblanks happening? Is > > >> anyone listening?) that give four separate cases. I think we can derive > > >> sensible behavior in all cases. Here is my suggestion: > > >> > > >> Are vblanks | Is anyone | > > >> happening? | listening? | What to do? > > >> > > >> Yes Yes Update MSC based on vblank interrupts > > >> Yes No Disable IRQ, estimate MSC next time > > >> someone listens > > >> No Yes Update MSC based on timer at approx. > > >> previous refresh rate > > >> No No Disable IRQ, estimate MSC next time > > >> someone listens > > >> > > >> I believe that it is reasonable for apps to expect the MSC to increase. > > >> I think the easiest way to maintain that is to estimate the number of > > >> vblanks that would have occurred while the IRQ is disabled. We can do > > >> this by recording the wall-clock time the IRQ was disable and the > > >> refresh rate at that time. I thought we already had a mechanism for > > >> doing this. > > > > > > We actually try to do better: we capture the frame count at disable time > > > and then compare it to the count when we re-enable interrupts. So in > > > theory we get an accurate count across disable periods. For display off > > > situations > > > > Even better. > > > > > though, we currently return -EINVAL, indicating that userspace is waiting > > > on a disabled pipe. Mesa could handle this more gracefully I suppose, to > > > achieve the throttling you talked about... I'd rather not fake this > > > behavior in the kernel if possible. > > > > User-space would have to know the count, the wall-clock time, and the > > refresh rate of the pipe when the display was disabled to do the work. > > Do we have an interface to do that? If we don't is that an interface > > that we want to create and maintain forever? > > > > Part of my rationale for putting it in the kernel is that it keeps all > > the complexity in one place. We've tried splitting things into minimal > > kernel + the rest in user-space before, and we've generally regretted it > > later. > > In a KMS situation, the kernel will know the refresh rate, otherwise we'd > have > to go poke hw or have the 2D driver involved somehow.
Yeah, I think it should be easy to handle all this in the kernel with KMS. Not sure it's worth improving things beyond how they are now otherwise (but that doesn't mean we should regress from it either :). -- 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
