[Intel-gfx] [PATCH 5/5] drm/i915/gt: Split logical ring context manipulation into intel_lrc.c
Chris Wilson
chris at chris-wilson.co.uk
Tue Jan 28 22:08:36 UTC 2020
Quoting Daniele Ceraolo Spurio (2020-01-28 21:55:02)
>
>
> On 1/28/20 12:43 PM, Chris Wilson wrote:
> > Extract the core functions for setting up the machine dependent logical
> > ring context to intel_lrc.c. This will be shared by all submission
> > backends that utilise logical ring contexts.
> >
>
> I still don't understand why you don't want to put the lrc and ring
> object creation and initial setup (populate_lr_context) somewhere
The initial setup is common in intel_lrc.c, the rest is really just
mapping the local context layout, which will vary depending on the
different abstractions for the backends.
> common. I see no way we could do that differently for GuC submission,
> since the HW obviously requires the same objects and IMO it makes sense
> to keep the same initialization flow, so we'd have to copy that logic
> and maintain 2 identical copies of it. The redzone is the only thing
> that is not hw-enforced, but I believe it makes sense to keep that on
> the GuC side as well to catch possible issues. Or am I missing something?
They don't have the same execution flow, and I expect the differences in
context bookkeeping will continue to grow. Certainly there's an
abstraction around virtual engines to come, because the current struct
is heavily tied into the backend.
populate_lr_context is one that might be shared, but I just didn't see
much point in sharing a couple of very minor routines, when the
common mechanism is available. I'm still waiting for the other shoe to
fall and wide-contexts to become a necessity again.
-Chris
More information about the Intel-gfx
mailing list