[Intel-gfx] [PATCH] drm/i915: Engine relative MMIO

[Chris Wilson]

Quoting John Harrison (2019-04-01 22:02:07)
> On 3/30/2019 00:59, Chris Wilson wrote:
> > Quoting John.C.Harrison at Intel.com (2019-03-30 00:10:45)
> >> From: John Harrison <John.C.Harrison at Intel.com>
> >>
> >> 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