[Intel-gfx] [RFC 00/22] Gen7 batch buffer command parser

[Volkin, Bradley D]

On Wed, Dec 04, 2013 at 12:13:39AM -0800, Daniel Vetter wrote:
> On Tue, Nov 26, 2013 at 9:24 PM, Volkin, Bradley D <bradley.d.volkin at intel.com> wrote:
> 
> [snip]
> 
> > Which "state setup stuff" are you referring to? Something specific in i-g-t or something
> > more general?
> 
> The state setup 3D commands as opposed to doing actual rendering commands
> (with 3D_PRIM). Just to have a bit more realistic cs opcode lengths for
> micro-benchmarking.
> 
> [snip]
> 
> > Ok, I'll look at the hw context code for buffer mgmt. For "purgeable", just via the
> > madv field in the i915 gem object?
> 
> Yeah, though I'd extract two tiny helpers (maybe shared with the madvise
> ioctl) to set an object to purgeable and then resurrect it. The later can
> obviously fail. The helpers are just so we have a place to throw debug
> asserts into, maybe there are other needs for in-kernel caches.

Hmm. Not sure how much use the helpers would be. The ioctl has one case where it will
truncate() the object, but beyond that it just sets madv appropriately. In general,
purging and resurrecting appear to happen via a put_pages() from the shrinker and a
get_pages() the next time the object is needed.

Also, I haven't looked too closely at the shrinker code. Could there be potential races
between the shrinker purging a buffer and an execbuf call choosing it? I would expect
that synchronization is already in place. Just curious if you know off the top of your head.

Brad

> 
> > Also, there are a couple iterations of the work-in-progress patches. Do you prefer a
> > cache per ring or a single cache shared by all rings?
> 
> I've pondered a bunch of reasons for/against the two approaches and I
> think it won't really matter. Maybe slightly leaning towards per-ring
> caches since then objects retire in order. Well, until we do preemption
> ;-)
> -Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch