On Thu, 5 Nov 2020 at 15:45, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: > > Quoting Matthew Auld (2020-11-05 15:40:20) > > On Thu, 5 Nov 2020 at 15:39, Matthew Auld > > <matthew.william.auld@xxxxxxxxx> wrote: > > > > > > On Thu, 5 Nov 2020 at 10:11, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx> > > > Reviewed-by: Matthew Auld <matthew.auld@xxxxxxxxx> > > > > 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
