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

[Eric Anholt]

On Wed, 14 Apr 2010 12:23:37 +0200, Daniel Vetter <daniel at ffwll.ch> 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?

I'd also tried to avoid that stall by just freeing tiled buffers, with
no performance success.  Your resetting tiling at realloc time instead
might be a better plan than I had.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20100414/4f04dc70/attachment.sig>