[Intel-gfx] [RFC PATCH 42/42] HAX drm/i915/lmem: default userspace allocations to LMEM

Chris Wilson chris at chris-wilson.co.uk
Mon Feb 18 12:44:51 UTC 2019


Quoting Chris Wilson (2019-02-14 16:13:18)
> Quoting Matthew Auld (2019-02-14 14:57:40)
> > Hack patch to default all userspace allocations to LMEM. Useful for
> > testing purposes.
> > 
> > Signed-off-by: Matthew Auld <matthew.auld at intel.com>
> > Cc: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>
> > Cc: Abdiel Janulgue <abdiel.janulgue at linux.intel.com>
> > ---
> >  drivers/gpu/drm/i915/i915_gem.c | 45 +++++++++++++++++++++++++++++++--
> >  1 file changed, 43 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> > index 3c86909d55b9..bd857f477ef9 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -641,7 +641,8 @@ i915_gem_create(struct drm_file *file,
> >                 u32 *handle_p)
> >  {
> >         struct drm_i915_gem_object *obj;
> > -       int ret;
> > +       intel_wakeref_t wakeref;
> > +       int ret = 0;
> >         u32 handle;
> >  
> >         size = roundup(size, PAGE_SIZE);
> > @@ -649,10 +650,50 @@ i915_gem_create(struct drm_file *file,
> >                 return -EINVAL;
> >  
> >         /* Allocate the new object */
> > -       obj = i915_gem_object_create(dev_priv, size);
> > +       if (HAS_LMEM(dev_priv))
> > +               obj = i915_gem_object_create_lmem(dev_priv, size, 0);
> > +       else
> > +               obj = i915_gem_object_create(dev_priv, size);
> >         if (IS_ERR(obj))
> >                 return PTR_ERR(obj);
> >  
> > +       if (i915_gem_object_is_lmem(obj)) {
> > +               struct i915_gem_context *ctx;
> > +
> > +               /* XXX: we should prob use the blitter context for this? */
> 
> Or the kernel_context which is setup for emitting without taking
> struct_mutex...

Actually doing this async (i.e. not blocking object creation due to
clear) requires us to be sure that the cpu access via mmap has a sync
point. pread, mmap_ggtt does, but mmap_(wb|wc) does not currently, and
we would be reliant on userspace doing a set-domain first in order for
them not to see stale buffer content.

Also I have this penciled in to enable buffer pools (e.g. !llc would
dearly love to keep WC pages around before giving them back to the
system).

Hmm,
-Chris


More information about the Intel-gfx mailing list