AMD-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: "Marek Olšák" <maraeo@gmail.com>,
	"Michel Dänzer" <michel.daenzer@mailbox.org>
Cc: "Pierre-Eric Pelloux-Prayer" <pierre-eric.pelloux-prayer@amd.com>,
	"André Almeida" <andrealmeid@igalia.com>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	"Tuikov, Luben" <Luben.Tuikov@amd.com>,
	"amd-gfx mailing list" <amd-gfx@lists.freedesktop.org>,
	kernel-dev@igalia.com, "Deucher,
	Alexander" <alexander.deucher@amd.com>
Subject: Re: [PATCH] drm/amdgpu: Mark contexts guilty for any reset type
Date: Tue, 25 Apr 2023 14:08:16 +0200	[thread overview]
Message-ID: <19406ec5-79d6-e9e6-fbdd-eb2f4a872fc4@amd.com> (raw)
In-Reply-To: <CAAxE2A6iuuVA7zjHM8YcTGMpEWuYV=hGRR1YW6W-qXHwAg9w7w@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2044 bytes --]

Well signaling that something happened is not the question. We do this 
for both soft as well as hard resets.

The question is if errors result in blocking further submissions with 
the same context or not.

In case of a hard reset and potential loss of state we have to kill the 
context, otherwise a follow up submission would just lockup the hardware 
once more.

In case of a soft reset I think we can keep the context alive, this way 
even applications without robustness handling can keep work.

You potentially still get some corruption, but at least not your 
compositor killed.

Christian.

Am 25.04.23 um 13:07 schrieb Marek Olšák:
> That supposedly depends on the compositor. There may be compositors 
> for very specific cases (e.g. Steam Deck) that handle resets very 
> well, and those would like to be properly notified of all resets 
> because that's how they get the best outcome, e.g. no corruption. A 
> soft reset that is unhandled by userspace may result in persistent 
> corruption.
>
> Marek
>
> On Tue, Apr 25, 2023 at 6:27 AM Michel Dänzer 
> <michel.daenzer@mailbox.org> wrote:
>
>     On 4/24/23 18:45, Marek Olšák wrote:
>     > Soft resets are fatal just as hard resets, but no reset is
>     "always fatal". There are cases when apps keep working depending
>     on which features are being used. It's still unsafe.
>
>     Agreed, in theory.
>
>     In practice, from a user PoV, right now there's pretty much 0
>     chance of the user session surviving if the GPU context in certain
>     critical processes (e.g. the Wayland compositor or Xwayland) hits
>     a fatal reset. There's a > 0 chance of it surviving after a soft
>     reset. There's ongoing work towards making user-space components
>     more robust against fatal resets, but it's taking time. Meanwhile,
>     I suspect most users would take the > 0 chance.
>
>
>     -- 
>     Earthling Michel Dänzer            | https://redhat.com
>     Libre software enthusiast          |         Mesa and Xwayland
>     developer
>

[-- Attachment #2: Type: text/html, Size: 3462 bytes --]

  reply	other threads:[~2023-04-25 12:08 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-24  1:43 [PATCH] drm/amdgpu: Mark contexts guilty for any reset type André Almeida
2023-04-24  5:11 ` kernel test robot
2023-04-24  7:03 ` Christian König
2023-04-24 13:26   ` André Almeida
2023-04-24 15:27     ` Michel Dänzer
2023-04-24 16:45   ` Marek Olšák
2023-04-25 10:27     ` Michel Dänzer
2023-04-25 11:07       ` Marek Olšák
2023-04-25 12:08         ` Christian König [this message]
2023-04-25 12:14           ` Michel Dänzer
2023-04-25 12:44             ` Christian König
2023-04-25 19:11               ` Marek Olšák
2023-04-26  9:51                 ` Michel Dänzer
2023-04-26 15:52                   ` Marek Olšák

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=19406ec5-79d6-e9e6-fbdd-eb2f4a872fc4@amd.com \
    --to=christian.koenig@amd.com \
    --cc=Luben.Tuikov@amd.com \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=andrealmeid@igalia.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=kernel-dev@igalia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maraeo@gmail.com \
    --cc=michel.daenzer@mailbox.org \
    --cc=pierre-eric.pelloux-prayer@amd.com \
    /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