On Tue, 2009-02-03 at 08:58 -0800, Jesse Barnes wrote: > On Tuesday, February 3, 2009 1:34 am Michel Dänzer wrote: > > On Mon, 2009-02-02 at 18:15 -0800, Jesse Barnes wrote: > > > On Monday, February 2, 2009 2:49 pm Michel Dänzer wrote: > > > > > > though I'm not sure why we need a frame count cap at all. We've already > > > got the timeout, so shouldn't we just keep the code simple? Is debugging > > > tearing easier than debugging a hang? I guess that's what we're really > > > getting at... > > > > I'm afraid you lost me here, care to elaborate on what you mean by > > 'frame count cap' and what this has to do with debugging tearing vs. > > hangs? > > > > If by 'frame count cap' you mean the limit for the number of frames that > > can be waited for, that's implicitly there (even if we only considered a > > single delta as 'has passed', one couldn't wait for more than (2 ^ 32 - > > 1) frames) and your proposal changes it in the same direction, just only > > half the way. I'm suggesting to take it further if at all, as the > > motivation is to catch pathological cases rather than being able to wait > > as long as possible. > > Yeah I mean a (small) limit to the number of frames we can wait for. Without > an explicit limit we'll be capped at 2^31 frames.
You mean with your proposed explicit limit. :) > 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... > and anything greater than the limit will return instantly. It sounds > like you're suggesting we make the code return instantly if anything > greater than a few thousand frames is passed in, which is fine (though > I don't know if there are displays with khz or mhz refresh rates out > there where that would cause problems). The most I've heard of is 240 Hz, which would be fine. I suspect anything with a significantly higher refresh would be different enough from displays as we know them that a lot more than this would need to be revisited anyway. :) > > > I looked at this more; apparently the framecount reg on at least my > > > machine is running way too fast, which triggered the behavior we talked > > > about earlier. But given that we didn't use to track frame counts across > > > VT switch (many drivers removed their IRQ handler, so the frame count > > > wouldn't increase between LeaveVT and EnterVT) and things seemed ok, > > > > Yeah, I think a counter that doesn't move is less problematic than one > > that moves erratically from the POV of users of this functionality. > > > > > it's probably fine to just return 0 from the get_vblank_counter hook, > > > and ignore frames we lost between interrupt/vblank off periods. > > > > Not sure I understand what you're proposing here, do you have a patch? > > 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. 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? -- Earthling Michel Dänzer | http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ------------------------------------------------------------------------------ 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
