[Intel-gfx] [PATCH] i915: support page flipping

Jesse Barnes jbarnes at virtuousgeek.org
Fri Mar 13 22:13:33 CET 2009


On Friday, March 13, 2009 2:08:50 pm Chris Wilson wrote:
> On Thu, 2009-02-26 at 14:35 -0800, Jesse Barnes wrote:
> > On Thursday, February 26, 2009 1:56:52 pm Chris Wilson wrote:
> > > On Thu, 2009-02-26 at 13:28 -0800, Jesse Barnes wrote:
> > > > Add a new page flip ioctl to the i915 driver.  The new ioctl takes
> > > > the new drm_i915_gem_page_flip arg, which contains a buffer object
> > > > target for the flip, an offset into that buffer, and other buffer
> > > > parameters to be used for the flip.
> > > >
> > > > If a flip is already pending on the object in question, the ioctl
> > > > waits for it to finish first, then queues the flip.  An optional wait
> > > > flag causes the ioctl to wait for the flip to complete before the it
> > > > returns.
> > > >
> > > > If an execbuffer containing an object with a pending flip comes in,
> > > > it will stall until the flip completes, to preserve glXSwapBuffers
> > > > semantics.
> > > >
> > > > Signed-off-by: Jesse Barnes <jbarnes at virtuousgeek.org>
>
> Hmm, I finally got around to trying this updated variant of the
> page-flipping patch having hit a situation whereby the lack of unpinning
> of the new scanout buffer was consuming all the fence registers. The
> downside of this version, which unpins after vblank, is that this leaves
> the fence register covering the scanout buffer on the i915 available for
> reuse. [This also confirms that the scanout memory is vulnerable to an
> unbind().] The bo must remain pinned until it is no longer the scanout
> target -- the flickering (as the scanout rapidly switches between tiled
> and untiled) on my i915 is unbearable :(
> -ickle

Yuck, yeah we'll have to figure out a good way of handling the pin/unpin.  The 
2D driver can't really deal with it since it won't know when it's safe to 
unpin the old (current) buffer, though it can pin the new one.  Maybe the 2D 
driver should pin the new one and the kernel should be responsible for 
unpinning the old?  And of course we should add a check to make sure the new 
one is pinned in the ioctl, and return -EINVAL if it isn't...

-- 
Jesse Barnes, Intel Open Source Technology Center



More information about the Intel-gfx mailing list