On Mon, 2009-02-02 at 18:15 -0800, Jesse Barnes wrote: > On Monday, February 2, 2009 2:49 pm Michel Dänzer wrote: > > As for the higher level question, I hope we both agree that we should fix > this > up,
I'm fine with it, as long as it's clear that it's just a workaround for bad counter behaviour. > 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. > > > The jumping counter exposed that problem and should probably be fixed > > > too (just to keep the counter values more friendly) but the core > > > problem should be fixed first, imo. > > > > I still disagree there: If the counter doesn't jump, even the current > > code works just fine as long as userspace calls the ioctl at least once > > a day. We can try to contain the damage caused by a jumping counter, but > > we can't completely eliminate it in all cases. Even if we can usually > > handle it sanely in the kernel, userspace libraries / apps may not be so > > robust. From my POV the core problem is clearly the jumping counter, > > everything else discussed in this thread is just workarounds to paper > > over it. > > 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? -- 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
