mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: "André Almeida" <andrealmeid@igalia.com>,
	dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org,
	linux-kernel@vger.kernel.org
Cc: kernel-dev@igalia.com, alexander.deucher@amd.com,
	pierre-eric.pelloux-prayer@amd.com,
	"'Marek Olšák'" <maraeo@gmail.com>,
	"Samuel Pitoiset" <samuel.pitoiset@gmail.com>,
	"Bas Nieuwenhuizen" <bas@basnieuwenhuizen.nl>,
	"Timur Kristóf" <timur.kristof@gmail.com>,
	michel.daenzer@mailbox.org
Subject: Re: [RFC PATCH 0/1] Add AMDGPU_INFO_GUILTY_APP ioctl
Date: Tue, 2 May 2023 09:48:41 +0200	[thread overview]
Message-ID: <31380dad-1206-5f3c-ab7d-1f448c6a7cb3@amd.com> (raw)
In-Reply-To: <20230501185747.33519-1-andrealmeid@igalia.com>

Well first of all don't expose the VMID to userspace.

The UMD doesn't know (and shouldn't know) which VMID is used for a 
submission since this is dynamically assigned and can change at any time.

For debugging there is an interface to use an reserved VMID for your 
debugged process which allows to associate logs, tracepoints and hw 
dumps with the stuff executed by this specific process.

Then we already have a feedback mechanism in the form of the error 
number in the fence. What we still need is an IOCTL to query that.

Regarding how far processing inside the IB was when the issue was 
detected, intermediate debug fences are much more reliable than asking 
the kernel for that.

Regards,
Christian.

Am 01.05.23 um 20:57 schrieb André Almeida:
> Currently UMD hasn't much information on what went wrong during a GPU reset. To
> help with that, this patch proposes a new IOCTL that can be used to query
> information about the resources that caused the hang.
>
> The goal of this RFC is to gather feedback about this interface. The mesa part
> can be found at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22785
>
> The current implementation is racy, meaning that if two resets happens (even on
> different rings), the app will get the last reset information available, rather
> than the one that is looking for. Maybe this can be fixed with a ring_id
> parameter to query the information for a specific ring, but this also requires
> an interface to tell the UMD which ring caused it.
>
> I know that devcoredump is also used for this kind of information, but I believe
> that using an IOCTL is better for interfacing Mesa + Linux rather than parsing
> a file that its contents are subjected to be changed.
>
> André Almeida (1):
>    drm/amdgpu: Add interface to dump guilty IB on GPU hang
>
>   drivers/gpu/drm/amd/amdgpu/amdgpu.h      |  3 +++
>   drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c  |  3 ++-
>   drivers/gpu/drm/amd/amdgpu/amdgpu_job.c  |  3 +++
>   drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c  |  7 ++++++
>   drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h |  1 +
>   drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c   | 29 ++++++++++++++++++++++++
>   include/uapi/drm/amdgpu_drm.h            |  7 ++++++
>   7 files changed, 52 insertions(+), 1 deletion(-)
>


      parent reply	other threads:[~2023-05-02  7:48 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-01 18:57 André Almeida
2023-05-01 18:57 ` [RFC PATCH 1/1] drm/amdgpu: Add interface to dump guilty IB on GPU hang André Almeida
2023-05-01 19:27   ` Alex Deucher
2023-05-01 19:24 ` [RFC PATCH 0/1] Add AMDGPU_INFO_GUILTY_APP ioctl Alex Deucher
2023-05-02  1:26   ` André Almeida
2023-05-02  7:59     ` Christian König
     [not found]       ` <CAFF-SiV0=WNmRW-D9uYUuj68Zq0APxtGLya9KR6FfZ7v0Zf2RQ@mail.gmail.com>
2023-05-02  9:30         ` Bas Nieuwenhuizen
     [not found]         ` <fcca2934-a556-797c-535d-a66fc67bbe30@amd.com>
2023-05-02 13:34           ` Timur Kristóf
2023-05-02 13:45             ` Alex Deucher
2023-05-02 15:22               ` Timur Kristóf
2023-05-02 18:41                 ` Alex Deucher
2023-05-03  7:59                   ` Christian König
2023-05-03 15:08                     ` Felix Kuehling
2023-05-03 15:23                       ` Christian König
     [not found]                         ` <CAAxE2A7wzrt9m0LifB=vPFr7aEtwyh9zzDDh9DkZJux2A4kKqw@mail.gmail.com>
2023-05-03 18:52                           ` André Almeida
2023-05-03 17:43                       ` Timur Kristóf
2023-05-03 19:14                         ` André Almeida
2023-05-04  6:43                           ` Christian König
2023-05-02  7:48 ` Christian König [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=31380dad-1206-5f3c-ab7d-1f448c6a7cb3@amd.com \
    --to=christian.koenig@amd.com \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=andrealmeid@igalia.com \
    --cc=bas@basnieuwenhuizen.nl \
    --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 \
    --cc=samuel.pitoiset@gmail.com \
    --cc=timur.kristof@gmail.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

all inboxes | Powered by JetHome®