On Tuesday, February 3, 2009 9:26 am Michel Dänzer wrote:
> On Tue, 2009-02-03 at 08:58 -0800, Jesse Barnes wrote:
> > What I'm saying is that anything greater than a few hundred frames (up
> > to the limit) will be caught by the timeout,
>
> If it wasn't for the problems that triggered all these discussions...

No, remember the problem that triggered this was the current, broken test, 
that was returning false for sequence numbers less than a few million of the 
current sequence number.  So with a large cap (2^31) or a small cap that 
problem will be fixed.

> > No you got it; it would keep the counter from jumping at all between
> > IRQ/vblank off->on transitions.  The only downside is that apps that do
> > their own calculations for vblank sequence numbers and then try to use
> > them across such periods might be surprised, but the GL wrappers around
> > the ioctl should handle that case.  The patch below is all it takes. 
> > Remind me again why we bothered to keep an accurate count across off->on
> > periods? :)
>
> I don't think this is a good general solution; just because your driver
> can't maintain a consistent counter under all circumstances doesn't mean
> it should never even try.

It can; when interrupts are on.  And when they're off (i.e. no clients are 
waiting and/or we're VT switched away), why do we care about keeping the 
frame count accurate?  DPMS events will turn off the display too after all, 
and apps won't generally be aware of that, so stopping the counter 
arbitrarily needs to be safe anyway.

> Also, it might be possible to disable vblank interrupts immediately
> instead of only after a delay, and avoid some wakeups with apps that
> only wait for every second or third refresh or something like that?

Yeah, or you could reduce the delay.  But if your app has a swap interval set 
to indicate it wants to wake up every 2 or 3 frames, it'll still take a 
vblank ref, so we won't disable (unless it's trying to time a single frame 
wait by itself of course, dunno how common that is).

-- 
Jesse Barnes, Intel Open Source Technology Center

------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to