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