Quoting Joonas Lahtinen (2019-06-04 12:37:03) > Quoting Chris Wilson (2019-06-03 20:11:30) > > Instead of relying on the caller holding struct_mutex across the > > allocation, push the allocation under a tree of spinlocks stored inside > > the page tables. Not only should this allow us to avoid struct_mutex > > here, but it will allow multiple users to lock independent ranges for > > concurrent allocations, and operate independently. This is vital for > > pushing the GTT manipulation into a background thread where dependency > > on struct_mutex is verboten, and for allowing other callers to avoid > > struct_mutex altogether. > > > > Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> > > Cc: Matthew Auld <matthew.a...@intel.com> > > Cc: Mika Kuoppala <mika.kuopp...@intel.com> > > <SNIP> > > > @@ -1684,9 +1752,7 @@ static void gen6_ppgtt_clear_range(struct > > i915_address_space *vm, > > > > num_entries -= count; > > > > - GEM_BUG_ON(count > pt->used_ptes); > > This seems to be lost, and it's definitely a valid check, still. > > With that retained, this is: > > Reviewed-by: Joonas Lahtinen <joonas.lahti...@linux.intel.com> > > Operations *_ppgtt_set_* + atomic_inc(used_*) and *_ppgtt_set_*(scratch) + > atomic_dec() appear repetitive, but as they're for each different level, > a helper might or might not make it cleaner.
Mika is working on refactoring the layers, so I'm hoping that mostly falls out in the wash. Or at least becomes easier to do so. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
