Quoting Tvrtko Ursulin (2020-02-07 16:49:17)
>
> On 07/02/2020 16:33, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2020-02-07 16:13:30)
> >> static inline void
> >> -__intel_context_stats_start(struct intel_context *ce, ktime_t now)
> >> +__intel_context_stats_start(struct intel_context *ce,
> >> + struct intel_engine_cs *engine,
> >> + ktime_t now)
> >> {
> >> struct intel_context_stats *stats = &ce->stats;
> >> -
> >> - if (!stats->active) {
> >> - stats->start = now;
> >> - stats->active = true;
> >> + struct i915_gem_context *ctx;
> >> +
> >> + if (stats->active)
> >> + return;
> >> +
> >> + stats->start = now;
> >> + stats->active = true;
> >> +
> >> + rcu_read_lock();
> >> + ctx = rcu_dereference(ce->gem_context);
> >> + if (ctx && ctx->client) {
> >
> > I'd rather avoid having to dig into the GEM context down here next to
> > the HW.
> >
> > First thought would be to keep the stats local on the intel_context and
> > for the client to chase collate them when the user reads the fd.
> >
> > Hmm, didn't you structure it like so earlier? What made you change your
> > mind?
>
> Yes, it's in the cover letter - we must not have disappearing
> contributions - client can submit from one context for a bit, close it,
> and oops usage history lost.
If only we had a mechanism for accumulating contributions from stale
engines and then from stale contests?
> ce->drm_client? :)
Yeah that is equally icky for swimming upstream.
Ok, I have an idea for capturing the contributions at close rather than
having to do global accumulations at runtime.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
