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. > >> 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. > > How so? Was just worried that the calculated timer frequency might be a little off from the actual refresh rate, leading to cases where the MSC increased a little before the corresponding frame was displayed, or a so much after that it caused problems for audio/video sync. But if that's not a concern, we can add a simple DRI2 callback for getting the current frequency for the counters and leave it at that, no kernel involvement needed. -- 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
