Quoting Tvrtko Ursulin (2020-07-17 15:36:04)
>
> On 15/07/2020 12:50, Chris Wilson wrote:
> > Remove the stub i915_vma_pin() used for incrementally pining objects for
> > execbuf (under the severe restriction that they must not wait on a
> > resource as we may have already pinned it) and replace it with a
> > i915_vma_pin_inplace() that is only allowed to reclaim the currently
> > bound location for the vma (and will never wait for a pinned resource).
> >
> > Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
> > ---
> > .../gpu/drm/i915/gem/i915_gem_execbuffer.c | 69 +++++++++++--------
> > drivers/gpu/drm/i915/i915_vma.c | 6 +-
> > drivers/gpu/drm/i915/i915_vma.h | 2 +
> > 3 files changed, 45 insertions(+), 32 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > index 28cf28fcf80a..0b8a26da26e5 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > @@ -452,49 +452,55 @@ static u64 eb_pin_flags(const struct
> > drm_i915_gem_exec_object2 *entry,
> > return pin_flags;
> > }
> >
> > +static bool eb_pin_vma_fence_inplace(struct eb_vma *ev)
> > +{
> > + struct i915_vma *vma = ev->vma;
> > + struct i915_fence_reg *reg = vma->fence;
> > +
> > + if (reg) {
> > + if (READ_ONCE(reg->dirty))
> > + return false;
> > +
> > + atomic_inc(®->pin_count);
>
> Why is this safe outside the vm->mutex? It otherwise seems to be
> protecting this pin count.
I was working on having the fence protected by the vma. It's important
that we do avoid the fallback scheme -- although not strictly as
important for gen2/gen3 as they do not need the ppGTT preallocations.
If I adapt find_fence() to operate against a concurrent atomic_inc()
that should dig myself out of the hold. (Another cmpxchg, oh my.)
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
