[Intel-gfx] [PATCH 12/15] drm/i915: Replace the hardcoded I915_FENCE_TIMEOUT
chris at chris-wilson.co.uk
Sat May 9 10:46:26 UTC 2020
Quoting Ruhl, Michael J (2020-05-08 14:54:50)
> >-----Original Message-----
> >From: Chris Wilson <chris at chris-wilson.co.uk>
> >Sent: Thursday, May 7, 2020 9:57 AM
> >To: Ruhl, Michael J <michael.j.ruhl at intel.com>; intel-
> >gfx at lists.freedesktop.org
> >Subject: Re: [Intel-gfx] [PATCH 12/15] drm/i915: Replace the hardcoded
> >Quoting Ruhl, Michael J (2020-05-07 14:53:00)
> >> >-----Original Message-----
> >> >From: Intel-gfx <intel-gfx-bounces at lists.freedesktop.org> On Behalf Of
> >> >Wilson
> >> >diff --git a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
> >> >b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
> >> >index 3a146aa2593b..d3a86a4d5c04 100644
> >> >--- a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
> >> >+++ b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
> >> >@@ -288,8 +288,7 @@ int i915_gem_schedule_fill_pages_blt(struct
> >> >drm_i915_gem_object *obj,
> >> >
> >> > i915_gem_object_lock(obj);
> >> > err = i915_sw_fence_await_reservation(&work->wait,
> >> >- obj->base.resv, NULL,
> >> >- true, I915_FENCE_TIMEOUT,
> >> >+ obj->base.resv, NULL, true, 0,
> >> Did you miss this one, or is the '0' on purpose?
> >It should be 0, as it should be only handling internal fences which may
> >take as long as required and should not be timed out.
> >Still this is a placeholder function and should not be taken too
> Assuming that the "placeholder function" is the _fill_pages_blt()...
It is. I'm not fond of await_reservation either. That extra 'exclude'
parameter belies a weakness of the one-size fits all approach. Just look
at the trouble we go to with i915_request_await_dma_fence() to determine
the "best" means of waiting on the fence, and then worry about how to fit
that into a more generic api.
More information about the Intel-gfx