Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
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
>

      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