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

[Owain Ainsworth]

On Wed, Apr 14, 2010 at 12:23:37PM +0200, Daniel Vetter wrote:
> On Wed, Apr 14, 2010 at 10:29:24AM +0100, Chris Wilson wrote:
> > 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?)
> 
> At least currently, set_tiling always stalls when actually changing
> something (if the alignment doesn't match or if there's a wrong fence reg
> attached to the buffer). btw I think the libdrm bo caching has a bug wrt
> to this: It resets tiling parameters before inserting a bo into the cache,
> while the bo might still be busy. My first try at a patch a few weeks ago
> blew up tough, so I left it as-is. Comments?

Another alternative would be to make it completely lazy. kill gtt
mappings in when we switch tiling, then at next pin for execbuf or for
next gtt map, as well as checking if we need a fence reg, check if we
*don't* then since in the latter case we're stalling anyway, and the
former we may be done or at least we have saved some time.

In OpenBSD we already check fence alignment, etc on pin, so adding this
check would be almost trivial.

-0-
-- 
Laetrile is the pits.