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

From: Eric Anholt <eric@anholt.net>
To: Daniel Vetter <daniel@ffwll.ch>, Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/3] drm/i915: Unbind the bo if the user requests a different alignment
Date: Wed, 14 Apr 2010 14:19:49 -0700	[thread overview]
Message-ID: <874ojdohoq.fsf@pollan.anholt.net> (raw)
In-Reply-To: <20100414102336.GA3440@viiv.ffwll.ch>

[-- Attachment #1.1: Type: text/plain, Size: 1586 bytes --]

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

[-- Attachment #1.2: Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx