-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. >> 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? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmbY8QACgkQX1gOwKyEAw/S2wCeJXI/cOf1LBcJdiFI9y8mU1yd HiEAn3Zu3DvxoWOjs2Vqy3o+qGo3IuJg =aZml -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ 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
