[Intel-gfx] [PATCH 2/3] drm/i915: Don't update fence mru upon end-of-flush

Daniel Vetter daniel at ffwll.ch
Mon Apr 5 21:58:27 CEST 2010


On Sun, Apr 04, 2010 at 10:35:20PM +0100, Chris Wilson wrote:
> The fence mru list needs to be ordered based on the most recent access,
> which is either an invocation from a batch buffer or mapping into the
> GTT via a fence. During the processing of a flush, we do not actually
> initiate a new access but just demarcate the end of the current use and
> so should not refresh its position on the mru list.
> 
> Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> ---
>  drivers/gpu/drm/i915/i915_gem.c |    5 -----
>  1 files changed, 0 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index c148170..8f7b3c3 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1563,11 +1563,6 @@ i915_gem_process_flushing_list(struct drm_device *dev,
>  			list_del_init(&obj_priv->gpu_write_list);
>  			i915_gem_object_move_to_active(obj, seqno);
>  
> -			/* update the fence lru list */
> -			if (obj_priv->fence_reg != I915_FENCE_REG_NONE)
> -				list_move_tail(&obj_priv->fence_list,
> -						&dev_priv->mm.fence_list);
> -
>  			trace_i915_gem_object_change_domain(obj,
>  							    obj->read_domains,
>  							    old_write_domain);

IMHO a bad idea. The fence stealing code takes the lru fence to avoid
waiting on the gpu. When we flush an object, it's last_rendering_seqno
gets updated. So when you don't update the fence lru, the fences used by
the gpu are no longer ordered according to the last_rendering_seqno of the
associated objects. Which will cause additional fence stealing related
stalls.

Yours, Daniel

btw, my pipelined fencing stuff contains a few patches to improve fence
lru tracking in the face of mixed fenced/unfenced execbuf2 workloads. I
intend to extract and post them some when later.
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48



More information about the Intel-gfx mailing list