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