Re: [PATCH] drm/i915/scheduler: Assert that we do not have a dep cycle back to request

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jan 05, 2018 at 02:13:22PM +0000, Chris Wilson wrote:
> When reprioritising a request, we build a list of its dependencies in
> topological order. This should leave our origin request as the first
> element in our list, if it moves we have a dependency cycle and severe
> breakage. Assert that it doesn't move.
> 
> Complete, but expensive checking is done by swfence, this assert is more
> about documenting the topologically ordered list.
> 
> Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> Cc: Michał Winiarski <michal.winiarski@xxxxxxxxx>

Reviewed-by: Michał Winiarski <michal.winiarski@xxxxxxxxx>

-Michał

> ---
>  drivers/gpu/drm/i915/intel_lrc.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
> index 4e150b095a11..42705e3875cd 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1050,6 +1050,13 @@ static void execlists_schedule(struct drm_i915_gem_request *request, int prio)
>  		}
>  	}
>  
> +	/*
> +	 * We should never have a dep cycle back to ourselves, leaving
> +	 * the original request as the origin of our topologically sorted
> +	 * list.
> +	 */
> +	GEM_BUG_ON(list_first_entry(&dfs, typeof(stack), dfs_link) != &stack);
> +
>  	/*
>  	 * If we didn't need to bump any existing priorities, and we haven't
>  	 * yet submitted this request (i.e. there is no potential race with
> -- 
> 2.15.1
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux