From: "Christian König" <christian.koenig@amd.com>
To: "André Almeida" <andrealmeid@igalia.com>,
"Alex Deucher" <alexdeucher@gmail.com>
Cc: dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org,
linux-kernel@vger.kernel.org, pierre-eric.pelloux-prayer@amd.com,
"Marek Olšák" <maraeo@gmail.com>,
"Timur Kristóf" <timur.kristof@gmail.com>,
michel.daenzer@mailbox.org,
"Samuel Pitoiset" <samuel.pitoiset@gmail.com>,
kernel-dev@igalia.com,
"Bas Nieuwenhuizen" <bas@basnieuwenhuizen.nl>,
alexander.deucher@amd.com
Subject: Re: [RFC PATCH 0/1] Add AMDGPU_INFO_GUILTY_APP ioctl
Date: Tue, 2 May 2023 09:59:22 +0200 [thread overview]
Message-ID: <cb3d2590-a1f8-fe7e-0bba-638ee80719af@amd.com> (raw)
In-Reply-To: <6ab2ff76-4518-6fac-071e-5d0d5adc4fcd@igalia.com>
Am 02.05.23 um 03:26 schrieb André Almeida:
> Em 01/05/2023 16:24, Alex Deucher escreveu:
>> On Mon, May 1, 2023 at 2:58 PM André Almeida <andrealmeid@igalia.com>
>> wrote:
>>>
>>> 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.
>>
>> Can you elaborate a bit on that? Isn't the whole point of devcoredump
>> to store this sort of information?
>>
>
> I think that devcoredump is something that you could use to submit to
> a bug report as it is, and then people can read/parse as they want,
> not as an interface to be read by Mesa... I'm not sure that it's
> something that I would call an API. But I might be wrong, if you know
> something that uses that as an API please share.
>
> Anyway, relying on that for Mesa would mean that we would need to
> ensure stability for the file content and format, making it less
> flexible to modify in the future and probe to bugs, while the IOCTL is
> well defined and extensible. Maybe the dump from Mesa + devcoredump
> could be complementary information to a bug report.
Neither using an IOCTL nor devcoredump is a good approach for this since
the values read from the hw register are completely unreliable. They
could not be available because of GFXOFF or they could be overwritten or
not even updated by the CP in the first place because of a hang etc....
If you want to track progress inside an IB what you do instead is to
insert intermediate fence write commands into the IB. E.g. something
like write value X to location Y when this executes.
This way you can not only track how far the IB processed, but also in
which stages of processing we where when the hang occurred. E.g. End of
Pipe, End of Shaders, specific shader stages etc...
Regards,
Christian.
next prev parent reply other threads:[~2023-05-02 7:59 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 [this message]
[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
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=cb3d2590-a1f8-fe7e-0bba-638ee80719af@amd.com \
--to=christian.koenig@amd.com \
--cc=alexander.deucher@amd.com \
--cc=alexdeucher@gmail.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®