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 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. > Queries of the MSC while the IRQ is disabled will get increasing, but > approximate, values. Anyone using this as a timing mechanism for > anything critical is already doing it wrong. This won't give accurate > results when the refresh rate changes, but the results will "[increment] > for each vertical retrace that occurs." > > The important thing is that the app visible MSC is just a value that is > magically derived from some other state. That we calculate this by > counting interrupts, peeking at hardware counters, or measuring > wall-clock time isn't terribly relevant. This is part of the reason > that the MSC is defined to be a 64-bit, unsigned value. Apps get to > ignore the man behind the curtain and listen to the real Oz. In that case we should just do it in userspace, Mesa can figure out a value totally independent of the kernel based on refresh rate... Somehow I suspect apps might expect something different though. -- 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
