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

[John Harrison]

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.

John.