Quoting John Harrison (2019-04-01 22:02:07) > On 3/30/2019 00:59, Chris Wilson wrote: > > Quoting John.C.Harrison@xxxxxxxxx (2019-03-30 00:10:45) > >> From: John Harrison <John.C.Harrison@xxxxxxxxx> > >> > >> With virtual engines, it is no longer possible to know which specific > >> physical engine a given request will be executed on at the time that > >> request is generated. This means that the request itself must be engine > >> agnostic - any direct register writes must be relative to the engine > >> and not absolute addresses. > >> > >> The LRI command has support for engine relative addressing. However, > >> the mechanism is not transparent to the driver. The scheme for Gen11 > >> (MI_LRI_ADD_CS_MMIO_START) requires the LRI address to have no > >> absolute engine base component. The hardware then adds on the correct > >> engine offset at execution time. > >> > >> Due to the non-trivial and differing schemes on different hardware, it > >> is not possible to simply update the code that creates the LRI > >> commands to set a remap flag and let the hardware get on with it. > >> Instead, this patch adds function wrappers for generating the LRI > >> command itself and then for constructing the correct address to use > >> with the LRI. > >> > >> v2: Fix build break in GVT. Remove flags parameter [review feedback > >> from Chris W]. > > I'm still asking why are we "changing" instructions that we know are tied > > to an engine? The instruction is the same, it just gained an extra bit > > to denote relative mmio offset. > > -Chris > > I'm not sure that I understand your question. It's not really an option > to just add the extra bit wherever an LRI is used on account of the > decision of which bit to add is complex. Also, it's not just the LRI > command that needs to change but the address used within the LRI too. > And it is only getting more complex in the future. Rather than add all > that extra code to each LRI instance, it is far simpler to add a helper > function for generating the LRI. I disagree that adding complexity and obfuscation to old platforms is simpler. I disagree that it makes any sense to add those options to paths that are explicitly targeting a physical engine. That whittles it down to intel_lrc.c. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
