From: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
To: Ashutosh Dixit <ashutosh.dixit@intel.com>
Cc: <intel-xe@lists.freedesktop.org>,
Harish Chegondi <harish.chegondi@intel.com>
Subject: Re: [PATCH v2 0/1] Add support for EU stall sampling
Date: Fri, 19 Jul 2024 14:32:28 -0700 [thread overview]
Message-ID: <ZprbY4TXmfXXBpgu@orsosgc001> (raw)
In-Reply-To: <20240707224141.2865472-1-ashutosh.dixit@intel.com>
On Sun, Jul 07, 2024 at 03:41:40PM -0700, Ashutosh Dixit wrote:
> The following patch adds support for EU stall sampling, a new hardware
>feature first added in PVC and is being supported in XE2 and later
>architecture GPUs. This feature would enable capturing of EU stall
>data which include the IP address of the instruction stalled and
>various stall reason counts. More details are explained in the patch
>commit message.
>
>I am posting this patch as an RFC to get early feedback in the uAPI
maybe not an RFC anymore?
>while support for this feature is being added into Mesa. A new test
>in the IGT repo: https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
>is also under development to test this feature in the driver. This
>patch has undergone basic testing with the new IGT test that is under
>development.
>
>The EU stall data from the driver include a header with additional
>information about the data that follows the header. The header
>includes flags one of which indicate if data has been dropped has
s/has been dropped//
>been dropped by the hardware due to buffer being full. While read
>returns the total bytes read, any data dropped by the hardware will
>be indicated in the flags.
>One feedback received so far is to make
>read return an error when data has been dropped by the hardware
>instead of setting a flag in the header.
if dropped data can be mapped to an intuitive error in the return of
read, we should definitely do that. If multiple headers are returned in
a read call and only some header blobs are affected, then, IMO, we
should also set the flag for the relevant headers.
>One suggestion received
>is to consider two FDs per EU stall data stream with one fd to read
>data and other fd to pass any errors. please comment on this idea
>that's not represented in the code
If it is just one stream of data, then I would avoid an additional FD
for passing errors. Read should be able to handle returning errors. Is
there a limitation in the generic file ops (like read()) that EU stall
supports? Are errors very common when consuming EU stall data?
Regards,
Umesh
>
>Thank You.
>
>v2: Rename xe perf layer as xe observation layer
>
>Harish Chegondi (1):
> drm/xe/eustall: Add support for EU stall sampling
>
> drivers/gpu/drm/xe/Makefile | 1 +
> drivers/gpu/drm/xe/regs/xe_eu_stall_regs.h | 33 +
> drivers/gpu/drm/xe/xe_eustall_cntr.c | 1005 ++++++++++++++++++++
> drivers/gpu/drm/xe/xe_eustall_cntr.h | 62 ++
> drivers/gpu/drm/xe/xe_gt.c | 3 +
> drivers/gpu/drm/xe/xe_gt_topology.c | 9 +
> drivers/gpu/drm/xe/xe_gt_topology.h | 3 +
> drivers/gpu/drm/xe/xe_gt_types.h | 4 +
> drivers/gpu/drm/xe/xe_observation.c | 14 +
> drivers/gpu/drm/xe/xe_trace.h | 35 +
> include/uapi/drm/xe_drm.h | 77 ++
> 11 files changed, 1246 insertions(+)
> create mode 100644 drivers/gpu/drm/xe/regs/xe_eu_stall_regs.h
> create mode 100644 drivers/gpu/drm/xe/xe_eustall_cntr.c
> create mode 100644 drivers/gpu/drm/xe/xe_eustall_cntr.h
>
>--
>2.41.0
>
prev parent reply other threads:[~2024-07-19 21:32 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-07 22:41 [PATCH v2 0/1] Add support for EU stall sampling Ashutosh Dixit
2024-07-07 22:41 ` [PATCH v2 1/1] drm/xe/eustall: " Ashutosh Dixit
2024-07-12 20:34 ` Souza, Jose
2024-07-19 20:21 ` Souza, Jose
2024-08-26 17:32 ` Harish Chegondi
2024-08-16 22:37 ` Dixit, Ashutosh
2024-08-21 19:35 ` Cabral, Matias A
2024-08-22 22:53 ` Dixit, Ashutosh
2024-08-23 13:09 ` Souza, Jose
2024-08-23 19:24 ` Dixit, Ashutosh
2024-08-23 21:22 ` Souza, Jose
2024-08-26 16:48 ` Dixit, Ashutosh
2024-08-26 17:31 ` Cabral, Matias A
2024-08-30 6:20 ` Harish Chegondi
2024-08-30 8:24 ` Ranjan, Joshua Santhosh
2024-08-30 15:58 ` Cabral, Matias A
2024-08-30 20:31 ` Harish Chegondi
2024-08-22 23:41 ` Matt Roper
2024-07-07 22:46 ` ✓ CI.Patch_applied: success for Add support for EU stall sampling (rev2) Patchwork
2024-07-07 22:46 ` ✗ CI.checkpatch: warning " Patchwork
2024-07-07 22:47 ` ✓ CI.KUnit: success " Patchwork
2024-07-07 22:59 ` ✓ CI.Build: " Patchwork
2024-07-07 23:02 ` ✗ CI.Hooks: failure " Patchwork
2024-07-07 23:03 ` ✓ CI.checksparse: success " Patchwork
2024-07-07 23:22 ` ✓ CI.BAT: " Patchwork
2024-07-08 0:25 ` ✗ CI.FULL: failure " Patchwork
2024-07-19 21:32 ` Umesh Nerlige Ramappa [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=ZprbY4TXmfXXBpgu@orsosgc001 \
--to=umesh.nerlige.ramappa@intel.com \
--cc=ashutosh.dixit@intel.com \
--cc=harish.chegondi@intel.com \
--cc=intel-xe@lists.freedesktop.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