On 1/15/2020 12:40 AM, Chris Wilson wrote:
Quoting Daniele Ceraolo Spurio (2020-01-15 01:31:36)
We currently wait until we attempt to load the GuC to confirm if we're
in GuC mode or not, at which point a lot of the engine setup has already
happened and needs to be updated for GuC submission. To allow us to get
the setup done directly into GuC mode, we need to commit to using GuC
as soon as possible.
I think this is the wrong direction; as I thought the goal was to allow
delayed loading of firmware, even going as far as allowing the system to
run a browser for the user to get the firmware first. I may be
We do indeed want to keep supporting execlists mode even as some HW
features move to the GuC to allow the user to get to the binaries, but
we don't want to switch between the 2 modes without a reboot. Switching
between the 2 modes is not a HW capability that we're committed to; the
guc->elsp transition is already not possible, while the elsp->guc one
still seems to work, but who knows for how long it will?
This series is also not really changing the commitment at the
implementation level, just making it "official" and acting based on
that. Even without these patches, if the blobs are on the system we will
attempt to get into GuC mode unless we get an allocation failure or
something similar, in which case it is extremely likely that the
fall-back to non-guc will not work either.
completely wrong about that, but imho I never want to have to build
firmware images into the kernel.
I do 100% agree with this statement, although I'm not sure how this
relates to the series. Are you planning to pull some of the engine setup
to an even earlier point?
The transition from execlists to guc could be just set-wedged; delete
old engines, build guc engines. [This should also work for guc -> guc.]
Throwing away context state is ugly, but simple enough.
As mentioned above, we can't switch between elsp and GuC modes so this
transition would have to be done before the first submission to HW. Why
not go directly in GuC mode then?
Daniele
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
