On Tue, 30 Jul 2019 at 17:26, Daniel Vetter <daniel@xxxxxxxx> wrote: > > On Thu, Jun 27, 2019 at 09:55:59PM +0100, Matthew Auld wrote: > > Support basic eviction for regions. > > > > Signed-off-by: Matthew Auld <matthew.auld@xxxxxxxxx> > > Cc: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx> > > Cc: Abdiel Janulgue <abdiel.janulgue@xxxxxxxxxxxxxxx> > > So from a very high level this looks like it was largely modelled after > i915_gem_shrink.c and not i915_gem_evict.c (our other "make room, we're > running out of stuff" code). Any specific reasons? IIRC I think it was originally based on the patches that exposed stolen-memory to userspace from a few years ago. > > I think i915_gem_evict is a lot closer match for what we want for vram (it > started out to manage severely limitted GTT on gen2/3/4) after all. With > the complication that we'll have to manage physical memory with multiple > virtual mappings of it on top, so unfortunately we can't just reuse the > locking patter Chris has come up with in his struct_mutex-removal branch. > But at least conceptually it should be a lot closer. When you say make it more like i915_gem_evict, what does that mean? Are you talking about the eviction roster stuff, or the placement/locking of the eviction logic, with it being deep down in get_pages? > > But I might be entirely off the track with reconstructing how this code > came to be, so please elaborate a bit. > > Thanks, Daniel _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
