Re: [PATCH 8/9] drm/i915: Wait on external rendering for GEM objects

[Daniel Vetter <daniel@ffwll.ch>]

On Mon, Jul 18, 2016 at 11:18:27AM +0100, Chris Wilson wrote:
> On Fri, Jul 15, 2016 at 11:11:20AM +0100, Chris Wilson wrote:
> > @@ -1366,6 +1368,16 @@ i915_gem_object_wait_rendering(struct drm_i915_gem_object *obj,
> >  		GEM_BUG_ON(obj->active);
> >  	}
> >  
> > +	resv = i915_gem_object_get_dmabuf_resv(obj);
> > +	if (resv) {
> > +		long err;
> > +
> > +		err = reservation_object_wait_timeout_rcu(resv, !readonly, true,
> > +							  MAX_SCHEDULE_TIMEOUT);
> > +		if (err < 0)
> > +			return err;
> > +	}
> 
> This introduces a potential WARN_ON into i915_gem_object_free() as the
> current i915_vma_unbind() calls i915_gem_object_wait_rendering(). To
> hit this path we first need to render with the GPU, have a dma-buf
> attached with an unsignaled fence and then interrupt the wait. It does
> get fixed later in the series (when i915_vma_unbind() only waits on the
> active VMA and not all, including third-party, rendering.
> 
> It's only a WARN, so I don't think it is worth deferring it to after
> the vma fix is in place.

Adding the above in a FIXME comment right before the callt to
resv_obj_wait might be a good interim idea. But yes, given that prime
buffer sharing always resulted in lockdep unhappiness around struct_mutex,
horrible tearing and other sad things I don't think a temporary WARN_ON is
all that bad. Acked.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx