Quoting Tvrtko Ursulin (2019-10-11 10:11:58)
>
> On 10/10/2019 08:14, Chris Wilson wrote:
> > +#include "intel_context.h"
> > +#include "intel_engine_heartbeat.h"
> > +#include "intel_engine_pm.h"
> > +#include "intel_engine.h"
> > +#include "intel_gt.h"
> > +
> > +static void idle_pulse(struct intel_engine_cs *engine, struct i915_request *rq)
> > +{
> > + engine->wakeref_serial = READ_ONCE(engine->serial) + 1;
> > + i915_request_add_active_barriers(rq);
>
> Why do you need active barriers with the idle pulse? Just because it is
> a handy point to release the previously pinned contexts? But they may
> get reused as soon as idle pulse finishes, no?
Yes. It is a known point in time where the other context has finished,
and when this request runs has completed a context switch.
Remember all that time we were arguing about idle barriers and how we
needed to run them periodically to allow them to be reaped and avoid
having the entire aperture pinned with stale contexts forcing a stall.
And avoiding making the idle barriers themselves a global serialising
barrier. :|
The idea we had was that we would take advantage of any guaranteed
context switches and send regular pulses from the kernel context to pick
up stragglers. So we could use any context switch after the we retire
the old context to unpin it, but to keep the locking and preallocations
of the rbtree simple (you've seen i915_active, simple is anything but),
I left it to the engine->kernel_context to manage.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
