Re: [PATCH 10/10] drm/i915: Flush idle barriers when waiting

[Chris Wilson <chris@chris-wilson.co.uk>]

Quoting Tvrtko Ursulin (2019-10-11 15:56:35)
> 
> On 10/10/2019 08:14, Chris Wilson wrote:
> > If we do find ourselves with an idle barrier inside our active while
> > waiting, attempt to flush it by emitting a pulse using the kernel
> > context.
> 
> The point of this one completely escapes me at the moment. Idle barriers 
> are kept in there to be consumed by the engine_pm parking, so if any 
> random waiter finds some (there will always be some, as long as the 
> engine executed some user context, right?),

Not any random waiter; the waiter has to be waiting on a context that
was active and so setup a barrier.

> why would it want to handle 
> them? Again just to use the opportunity for some house keeping? But what 
> if the system is otherwise quite busy and a low-priority client just 
> happens to want to wait on something silly?

There's no guarantee that it will ever be flushed. So why wouldn't we
use a low priority request to give a semblance of forward progress and
give a guarantee that the wait will complete.

It's a hypothetical point, there are no waiters that need to wait upon
their own barriers at present. We are just completing the picture for
idle barrier tracking.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx