[Intel-gfx] [PATCH 3/6] drm/i915/execlists: Force single submission for sentinels

Chris Wilson chris at chris-wilson.co.uk
Thu Mar 19 15:21:41 UTC 2020


Quoting Tvrtko Ursulin (2020-03-19 15:11:49)
> 
> On 19/03/2020 15:02, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2020-03-19 14:31:36)
> >>
> >> On 19/03/2020 09:19, Chris Wilson wrote:
> >>> +                             if (has_sentinel(last, rq))
> >>>                                        goto done;
> >>
> >> I am only confused by can_merge_rq saying two sentinel requests can be
> >> merged together:
> >>
> >>          if (unlikely((i915_request_flags(prev) ^ i915_request_flags(next)) &
> >>                       (BIT(I915_FENCE_FLAG_NOPREEMPT) |
> >>                        BIT(I915_FENCE_FLAG_SENTINEL))))
> >>                  return false;
> >>
> >> What am I missing?
> > 
> > I thought it was fine to coalesce consecutive sentinels within the
> > context into one.
> > 
> > Except you're thinking about gvt, and not my usage :|
> 
> Sentinel is like "only one context in elsp at a time", right?
> This is what GVT wants.

GVT wants one request. For my purpose, it was just one context.

> And for the active barrier we want single elsp and not 
> coalesced with non-sentinel from the same context. But sentinels are 
> kernel context, so should be fine. Although it still may be clearer to 
> make then not coalesce as well.

The frequency should of non-barrier operations along the kernel context
should not be high enough that we gain anything by coalescing mixed
barrier/non-barrier request streams. I hope.

On the other hand we do want to coalesce NOPREEMPT streams. Oh well, my
hope for pulling it all in one bitops seems to be fading away.

First though, I have to answer the question of how I broke persistence.
-Chris


More information about the Intel-gfx mailing list