Re: [Intel-gfx] [PATCH 5/5] drm/i915/gt: Split logical ring context manipulation into intel_lrc.c

[Chris Wilson <chris@chris-wilson.co.uk>]

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