[Intel-gfx] [PATCH 1/3] drm/i915: Unbind the bo if the user requests a different alignment

[Chris Wilson]

On Tue, 13 Apr 2010 16:49:46 -0700, Eric Anholt <eric at anholt.net> wrote:
> On Mon, 12 Apr 2010 18:23:22 +0100, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> > On Mon, 12 Apr 2010 10:10:22 -0700, Eric Anholt <eric at anholt.net> wrote:
> > > On Sun,  4 Apr 2010 22:35:19 +0100, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> > > > If the buffer is currently bound and does not meet the requested
> > > > alignment, then unbind it and repin.
> > > 
> > > Do we have any users legitimately requesting an alignment?  I thought
> > > they never existed or only lied when they did.
> > 
> > Yes, I invented one. ;-) Reusing surfaces within a batch with different
> > per-surface tiling parameters on pre-i965, without informing the kernel
> > that the buffer is tiled [so we can get away with reusing the surface
> > multiple times in the batch with different parameters...], and so having 
> > to manually request the minimal legal alignment for the relocated bo.
> > Given the transient nature of clip masks, glyph masks and intermediate
> > back buffers, we can reuse a lot of buffers within a single batch and
> > avoid catastrophic aperture thrashing.
> > -ickle
> 
> And you're guaranteeing that the transient tiled data doesn't need to
> have coherent contents across batchbuffer boundaries? (since it could
> get swapped, which means needing a17 swizzling, so the kernel would need
> to know about it).  This sounds like madness.

Darn. The current incarnation was literally for glyph masks, clip masks
and all the other short-lived write-once, immediately use as source
buffers within the same batch, and then discard. But there is nothing to
ensure that they exist only within a batch, and so they could well fall
foul of a17. I wonder if we can simply lazily rebind the bo at the point
of fence allocation rather than at tiling change. I am not sure if that
even makes sense yet. The other approach would seem to be to SET_TILING
on the last use within a batch and hope that doesn't cause a stall. Maybe
also a mechanism to mark the buffer contents as uninitialized so that if
we need to unbind, we can simply discard and allocate fresh pages? (An
extension to madvise, MADV_UNINITIALIZED or MADV_CLEAN?)

For xf86-video-intel, being able to reuse in-batch surfaces wins around
10% performance across the board in cairo-perf-trace. The effect is
reduced by the need to match tiling and stride, which is proving hairy to
workaround. The bigger the batch with more intermediate buffers, the more
pronounced the effect.
-ickle
-- 
Chris Wilson, Intel Open Source Technology Centre