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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
