[Intel-gfx] [PATCH 02/22] drm/i915/gem: Pull phys pread/pwrite implementations to the backend
Matthew Auld
matthew.william.auld at gmail.com
Thu Nov 5 16:02:38 UTC 2020
On Thu, 5 Nov 2020 at 15:45, Chris Wilson <chris at chris-wilson.co.uk> wrote:
>
> Quoting Matthew Auld (2020-11-05 15:40:20)
> > On Thu, 5 Nov 2020 at 15:39, Matthew Auld
> > <matthew.william.auld at gmail.com> wrote:
> > >
> > > On Thu, 5 Nov 2020 at 10:11, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> > > >
> > > > More the specialised interation with the physical GEM object from the
> > >
> > > Move interaction
> > >
> > > > pread/pwrite ioctl handler into the phys backend.
> > > >
> > > > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > > Reviewed-by: Matthew Auld <matthew.auld at intel.com>
> >
> > Does this need Fixes btw?
>
> I was thinking so long as we land before dg1 it would be fine. If we did
> a fake lmem with no aperture, we would have problems already. But there's
> no user exposure, so no pressing need for cc:stable.
I was thinking we could maybe be evil and achieve the same thing with
existing userspace, just requires the use of gtt_mmap to steal all of
the mappable aperture at the opportune time, such that
insert_mappable_node() still returns -ENOSPC? Or maybe I am
misunderstanding something.
> -Chris
More information about the Intel-gfx
mailing list