Quoting Tvrtko Ursulin (2019-09-20 17:22:42) > > On 02/09/2019 05:02, Chris Wilson wrote: > > Since we cannot allocate underneath the vm->mutex (it is used in the > > direct-reclaim paths), we need to shift the allocations off into a > > mutexless worker with fence recursion prevention. To know when we need > > this protection, we mark up the address spaces that do allocate before > > insertion. > > > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > --- > > drivers/gpu/drm/i915/i915_gem_gtt.c | 3 +++ > > drivers/gpu/drm/i915/i915_gem_gtt.h | 2 ++ > > 2 files changed, 5 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c > > index 9095f017162e..56d27cf09a3d 100644 > > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c > > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c > > @@ -1500,6 +1500,7 @@ static struct i915_ppgtt *gen8_ppgtt_create(struct drm_i915_private *i915) > > goto err_free_pd; > > } > > > > + ppgtt->vm.bind_alloc = I915_VMA_LOCAL_BIND; > > So this is re-using I915_VMA_LOCAL_BIND as a trick? Is it clear how that > works from these call sites? Should it be called bind_alloc*s*? > bind_allocates? Or be a boolean which is converted to a trick flag in > i915_vma_bind where a comment can be put explaining the trick? Is it a trick? We need to differentiate between requests for LOCAL_BIND, GLOBAL_BIND, LOCAL_BIND | GLOBAL_BIND, for different types of vm. Then I have a plan on using the worker for GLOBAL_BIND on bsw/bxt to defer the stop_machine(). -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
