-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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:
>>>>>> Can you think of a case where those frames would matter?
>>>>> E.g. the GLX_OML_sync_control spec says 'The graphics Media Stream
>>>>> Counter (or graphics MSC) is a counter that is unique to the graphics
>>>>> subsystem and increments for each vertical retrace that occurs.'
>>>>> Vertical retraces that occur while nobody's listening may not matter in
>>>>> simple cases, but that doesn't mean they're never relevant.
>>>> But that doesn't say anything about whether the frame count must stay
>>>> accurate while apps aren't running (i.e. doing anything with video/GL).
>>> The other side of this coin is that it doesn't mention this as a special
>>> case, so users of the extension can assume that the count increases
>>> regardless.
>> But apps can't assume that; frames *will* be lost when the monitor goes off,
>> for as long as the monitor is off. So if an app isn't actively using the
>> framecount for something it can't count on a given value. Right?
>
> Again, I disagree with the notion that because something may not work
> under some (in this case exceptional) circumstances, we shouldn't try to
> make it work whenever possible.
>
> 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.
I talked to Eric about a similar issue a few weeks ago. The scenario
that we discussed was an app that uses vsync for throttling. The
monitor blanks, and suddenly the app runs flat out. The app may
effectively go from nearly 0% CPU usage to 100% CPU usage just because
the screen blanked. That's not okay. In that case, I proposed to have
a separate timer that fired at a rate approximately equal to the (now
disabled) vblank.
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.
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkmbUfMACgkQX1gOwKyEAw9p1QCbBaX+DRlBk1Zl6kMwZSCMivvW
3jsAn3l0NpmbZMYDsncFdu1/LGcrmwRH
=xqZP
-----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
