All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Airlie <airlied@gmail.com>
To: Matt Roper <matthew.d.roper@intel.com>,
	 Linus Torvalds <torvalds@linux-foundation.org>,
	Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Intel Graphics Development <Intel-GFX@lists.freedesktop.org>,
	dri-devel <DRI-Devel@lists.freedesktop.org>,
	John.C.Harrison@intel.com
Subject: Re: [Intel-gfx] [PATCH 1/1] drm/i915/guc: Update to GuC version 70.1.1
Date: Fri, 15 Jul 2022 09:08:51 +1000	[thread overview]
Message-ID: <CAPM=9txdca1VnRpp-oNLXpBc2UWq3=ceeim5+Gw4N9tAriRY6A@mail.gmail.com> (raw)
In-Reply-To: <Yli4/8OIbjyRaQAK@mdroper-desk1.amr.corp.intel.com>

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.

Dave.

WARNING: multiple messages have this Message-ID (diff)
From: Dave Airlie <airlied@gmail.com>
To: Matt Roper <matthew.d.roper@intel.com>,
	 Linus Torvalds <torvalds@linux-foundation.org>,
	Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Intel Graphics Development <Intel-GFX@lists.freedesktop.org>,
	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: Fri, 15 Jul 2022 09:08:51 +1000	[thread overview]
Message-ID: <CAPM=9txdca1VnRpp-oNLXpBc2UWq3=ceeim5+Gw4N9tAriRY6A@mail.gmail.com> (raw)
In-Reply-To: <Yli4/8OIbjyRaQAK@mdroper-desk1.amr.corp.intel.com>

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.

Dave.

  reply	other threads:[~2022-07-14 23:09 UTC|newest]

Thread overview: 16+ 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 ` [Intel-gfx] " 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-12 22:59   ` [Intel-gfx] " John.C.Harrison
2022-04-15  0:14   ` Matt Roper
2022-07-14 23:08     ` Dave Airlie [this message]
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-15  9:04         ` Thorsten Leemhuis
2022-07-17 15:33           ` Thorsten Leemhuis
2022-07-21 12:51             ` Thorsten Leemhuis
2022-07-20  8:28       ` [Intel-gfx] [PATCH 1/1] drm/i915/guc: Update to GuC version 70.1.1 Jordan Justen
2022-07-20  8:28         ` Jordan Justen
2022-04-13 19:02 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for Update to GuC v70 Patchwork
2022-04-13 19:25 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-04-13 21:35 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork

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='CAPM=9txdca1VnRpp-oNLXpBc2UWq3=ceeim5+Gw4N9tAriRY6A@mail.gmail.com' \
    --to=airlied@gmail.com \
    --cc=DRI-Devel@lists.freedesktop.org \
    --cc=Intel-GFX@lists.freedesktop.org \
    --cc=John.C.Harrison@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.