[Intel-gfx] [PATCH v3 2/5] drm/i915: Use batch pools with the command parser

[Volkin, Bradley D]

On Thu, Nov 06, 2014 at 05:56:36AM -0800, Daniel Vetter wrote:
> On Thu, Nov 06, 2014 at 07:36:55AM +0000, Chris Wilson wrote:
> > On Wed, Nov 05, 2014 at 02:42:00PM -0800, Volkin, Bradley D wrote:
> > > For this part, I've got an implementation that works ok but one difference is
> > > that if we stop submitting batches, and therefore stop calling batch_pool_get,
> > > we stop moving buffers to the batch pool's inactive list. This means some buffers
> > > don't get marked purgeable even when they are. The solution that I see is to
> > > add a function to do the batch pool active -> inactive work and then call that
> > > from the appropriate place(s), but that seems to defeat the purpose of the
> > > proposed change. Suggestions?
> > 
> > Just mark them always as purgeable.
> 
> Yeah the trick with purgeable is that the shrinker will wait for the
> buffers to retire if they're still active. So you can mark the purgeable
> right after the move_to_active call. Then the only part that doesn't
> happen automatically is the batch-pool internal accounting. But we also
> don't really care about that until we want a new shadow batch.

Ok. I was concerned about leaving objects purgeable because there are various
places where the driver checks that an object is not purgeable. Looking at it
again, the only one I'm nervous about is i915_gem_object_get_pages(), but I'll
put something together and see if it's a problem. I imagine we can avoid the
issue by carefully setting madv during/after the parser flow.

Brad

> 
> libdrm works the same way btw: Userspace grabs a new batch (from the cache
> hopefully, setting willneed again), builds the cmd stream and submits it.
> Then it frees the buffer right away, libdrm puts it into the bo cache and
> also marks it as purgeable right away.
> -Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch