From: Jordan Justen <jordan.l.justen@intel.com>
To: Daniel Vetter <daniel.vetter@ffwll.ch>,
Dave Airlie <airlied@gmail.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Matt Roper <matthew.d.roper@intel.com>
Cc: Intel Graphics Development <Intel-GFX@lists.freedesktop.org>,
John.C.Harrison@intel.com,
dri-devel <DRI-Devel@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH 1/1] drm/i915/guc: Update to GuC version 70.1.1
Date: Wed, 20 Jul 2022 01:28:25 -0700 [thread overview]
Message-ID: <165830570593.852381.752081233295547410@jljusten-skl> (raw)
In-Reply-To: <CAPM=9txdca1VnRpp-oNLXpBc2UWq3=ceeim5+Gw4N9tAriRY6A@mail.gmail.com>
On 2022-07-14 16:08:51, Dave Airlie wrote:
> On Fri, 15 Apr 2022 at 10:15, Matt Roper <matthew.d.roper@intel.com> wrote:
> >
> > On Tue, Apr 12, 2022 at 03:59:55PM -0700, John.C.Harrison@Intel.com wrote:
> > > From: John Harrison <John.C.Harrison@Intel.com>
> > >
> > > The latest GuC firmware drops the context descriptor pool in favour of
> > > passing all creation data in the create H2G. It also greatly simplifies
> > > the work queue and removes the process descriptor used for multi-LRC
> > > submission. So, remove all mention of LRC and process descriptors and
> > > update the registration code accordingly.
> > >
> > > Unfortunately, the new API also removes the ability to set default
> > > values for the scheduling policies at context registration time.
> > > Instead, a follow up H2G must be sent. The individual scheduling
> > > policy update H2G commands are also dropped in favour of a single KLV
> > > based H2G. So, change the update wrappers accordingly and call this
> > > during context registration..
> > >
> > > Of course, this second H2G per registration might fail due to being
> > > backed up. The registration code has a complicated state machine to
> > > cope with the actual registration call failing. However, if that works
> > > then there is no support for unwinding if a further call should fail.
> > > Unwinding would require sending a H2G to de-register - but that can't
> > > be done because the CTB is already backed up.
> > >
> > > So instead, add a new flag to say whether the context has a pending
> > > policy update. This is set if the policy H2G fails at registration
> > > time. The submission code checks for this flag and retries the policy
> > > update if set. If that call fails, the submission path early exists
> > > with a retry error. This is something that is already supported for
> > > other reasons.
> > >
> > > Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
> > > Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
> >
> > Applied to drm-intel-gt-next. Thanks for the patch and review.
> >
>
> (cc'ing Linus and danvet, as a headsup, there is also a phoronix
> article where this was discovered).
>
> Okay WTF.
>
> This is in no way acceptable. This needs to be fixed in 5.19-rc ASAP.
>
> Once hardware is released and we remove the gate flag by default, you
> cannot just bump firmware versions blindly.
>
> The kernel needs to retain compatibility with all released firmwares
> since a device was declared supported.
>
> This needs to be reverted, and then 70 should be introduced with a
> fallback to 69 versions.
>
> Very disappointing, I expect this to get dealt with v.quickly.
This reminds me of something. A distant memory, really. But, if you
can believe it, i915 used to actually be able to *do something*
without the *closed source* guc. Crazy, right?
Anyway, that's all ancient history now. I mean, you have to go back
pretty far for that. Let me check my notes. Yeah, you'd probably have
to go all the way back to 2021 for that. I guess a lot of things were
much simpler back then though.
Anyway... Always fun to reminisce.
-Jordan
prev parent reply other threads:[~2022-07-20 8:28 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-12 22:59 [PATCH 0/1] Update to GuC v70 John.C.Harrison
2022-04-12 22:59 ` [PATCH 1/1] drm/i915/guc: Update to GuC version 70.1.1 John.C.Harrison
2022-04-15 0:14 ` [Intel-gfx] " Matt Roper
2022-07-14 23:08 ` Dave Airlie
2022-07-15 8:34 ` [Intel-gfx] [PATCH 1/1] drm/i915/guc: Update to GuC version 70.1.1 #forregzbot Thorsten Leemhuis
2022-07-20 8:28 ` Jordan Justen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=165830570593.852381.752081233295547410@jljusten-skl \
--to=jordan.l.justen@intel.com \
--cc=DRI-Devel@lists.freedesktop.org \
--cc=Intel-GFX@lists.freedesktop.org \
--cc=John.C.Harrison@intel.com \
--cc=airlied@gmail.com \
--cc=daniel.vetter@ffwll.ch \
--cc=matthew.d.roper@intel.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).