Re: [RFC PATCH 098/162] drm/i915/gtt: map the PD up front

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jan 12, 2021 at 10:47:57AM +0000, Matthew Auld wrote:
> On Fri, 27 Nov 2020 at 13:32, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote:
> >
> > Quoting Matthew Auld (2020-11-27 12:06:14)
> > > We need to general our accessor for the page directories and tables from
> > > using the simple kmap_atomic to support local memory, and this setup
> > > must be done on acquisition of the backing storage prior to entering
> > > fence execution contexts. Here we replace the kmap with the object
> > > maping code that for simple single page shmemfs object will return a
> > > plain kmap, that is then kept for the lifetime of the page directory.
> > >
> > > Signed-off-by: Matthew Auld <matthew.auld@xxxxxxxxx>
> > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> >
> > We are going to really struggle with this on 32b :(
> 
> Just go back to mapping everything on demand like we did previously,
> and unmap as soon as we are done with the current directory across
> alloc/insert/clear?

tbh if you run i915.ko on 32b kernels, on a modern platform, you deserve
all the pain you get. There's quite a bit of work going on to essentially
make kmap functions worse on 32b (we're not yet at the stage where people
propose to nuke them, but getting there slowly), so designing code today
with them in mind as primary justification is backwards.

What we can't do is keep kmap around forever, it'd need to be something
like vmap that has a long-term mapping intention behind it. And at that
point it's probably equally amounts of work to just go back to ad-hoc
kmap. Also the rules have changed somewhat with kmap_local anyway, a kmap
is a lot less painful in the code than it was with kmap_atomic.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx



[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux