[Intel-gfx] FBC patchset

[Keith Packard]

On Fri, 08 Jul 2011 21:19:29 +0100, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> On Fri, 08 Jul 2011 13:00:09 -0700, Keith Packard <keithp at keithp.com> wrote:
> > On Fri, 08 Jul 2011 20:43:47 +0100, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> > 
> > > Bumping to 250ms sufficiently delays the task to miss the race, but we
> > > can not foretell just how long any given crtc modeset will take. So what
> > > we need is to take the mode_config.lock in order to prevent concurrent
> > > access to the FBC registers and also to prevent the fb from disappearing
> > > beneath us:
> > 
> > Sounds like we also need to push out any FBC reconfiguration anytime
> > modesetting occurs to ensure that we've waited past a vblank interval?
> 
> During intel_crtc_mode_set() and friends we only call into
> intel_update_fbc() which just clears the FBC enabled bit and schedules a
> delayed task to do the rest, if required.

Does a further call into intel_crtc_mode_set push out the delayed task
so that it now occurs at least 50ms after the later call? That seems
useful, although it might not be necessary.

> If we are going from 2 crtcs to 1 with no swapping of the framebuffer,
> then the single crtc that we want to enable FBC on, remains running for
> the whole duration and the actual enabling is just deferred by 250ms.

Which is fine; mode setting doesn't happen often.

> If we are just moving the fb y-offset (e.g. panning the display), then the
> pipe will remain running but we disable FBC and wait 250ms before
> re-enabling.

That also seems fine; we certainly don't want to spend any time
optimizing for this case.

> So I think it just reduced into being an incorrect locking issue, but
> we're still making the assumption that it is safe to touch the FBC just
> because X ms have passed. :|

We could, of course, make sure that a certain number of vblank intervals
have passed instead of using a fixed timeout. Or we could compute the
vblank interval from the mode and then just make sure the timeout used
is sufficient. Or we could just use 100ms and assume that no-one will
ever set a mode of less than 10Hz.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20110708/b5b55beb/attachment.sig>