dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: "Nieto, David M" <David.Nieto@amd.com>,
	Daniel Vetter <daniel@ffwll.ch>,
	"Koenig, Christian" <Christian.Koenig@amd.com>
Cc: Intel Graphics Development <Intel-gfx@lists.freedesktop.org>,
	Maling list - DRI developers <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 0/7] Per client engine busyness
Date: Mon, 17 May 2021 17:00:34 +0100	[thread overview]
Message-ID: <c85fc53f-d25b-464c-d411-eed4a509a009@linux.intel.com> (raw)
In-Reply-To: <BYAPR12MB2840C633CF05C1F29263F5BCF42D9@BYAPR12MB2840.namprd12.prod.outlook.com>


On 17/05/2021 15:39, Nieto, David M wrote:
> [AMD Official Use Only]
> 
> 
> Maybe we could try to standardize how the different submission ring 
>   usage gets exposed in the fdinfo? We went the simple way of just 
> adding name and index, but if someone has a suggestion on how else we 
> could format them so there is commonality across vendors we could just 
> amend those.

Could you paste an example of your format?

Standardized fdinfo sounds good to me in principle. But I would also 
like people to look at the procfs proposal from Chris,
  - link to which I have pasted elsewhere in the thread.

Only potential issue with fdinfo I see at the moment is a bit of an 
extra cost in DRM client discovery (compared to my sysfs series and also 
procfs RFC from Chris). It would require reading all processes (well 
threads, then maybe aggregating threads into parent processes), all fd 
symlinks, and doing a stat on them to figure out which ones are DRM devices.

Btw is DRM_MAJOR 226 consider uapi? I don't see it in uapi headers.

> I’d really like to have the process managers tools display GPU usage 
> regardless of what vendor is installed.

Definitely.

Regards,

Tvrtko

  reply	other threads:[~2021-05-17 16:00 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-13 10:59 [PATCH 0/7] Per client engine busyness Tvrtko Ursulin
2021-05-13 10:59 ` [PATCH 1/7] drm/i915: Expose list of clients in sysfs Tvrtko Ursulin
2021-05-13 10:59 ` [PATCH 2/7] drm/i915: Update client name on context create Tvrtko Ursulin
2021-05-13 10:59 ` [PATCH 3/7] drm/i915: Make GEM contexts track DRM clients Tvrtko Ursulin
2021-05-13 10:59 ` [PATCH 4/7] drm/i915: Track runtime spent in closed and unreachable GEM contexts Tvrtko Ursulin
2021-05-13 11:00 ` [PATCH 5/7] drm/i915: Track all user contexts per client Tvrtko Ursulin
2021-05-13 11:00 ` [PATCH 6/7] drm/i915: Track context current active time Tvrtko Ursulin
2021-05-13 11:00 ` [PATCH 7/7] drm/i915: Expose per-engine client busyness Tvrtko Ursulin
2021-05-13 15:48 ` [PATCH 0/7] Per client engine busyness Alex Deucher
2021-05-13 16:40   ` Tvrtko Ursulin
2021-05-14  5:58     ` Alex Deucher
2021-05-14  7:22       ` Nieto, David M
2021-05-14  8:04         ` Christian König
2021-05-14 13:42           ` Tvrtko Ursulin
2021-05-14 13:53             ` Christian König
2021-05-14 14:47               ` Tvrtko Ursulin
2021-05-14 14:56                 ` Christian König
2021-05-14 15:03                   ` Tvrtko Ursulin
2021-05-14 15:10                     ` Christian König
2021-05-17 14:30                       ` Daniel Vetter
2021-05-17 14:39                         ` Nieto, David M
2021-05-17 16:00                           ` Tvrtko Ursulin [this message]
2021-05-17 18:02                             ` Nieto, David M
2021-05-17 18:16                               ` Nieto, David M
2021-05-17 19:03                                 ` Simon Ser
2021-05-18  9:08                                   ` Tvrtko Ursulin
2021-05-18  9:16                                     ` Daniel Stone
2021-05-18  9:40                                       ` Tvrtko Ursulin
2021-05-19 16:16                                         ` Tvrtko Ursulin
2021-05-19 18:23                                           ` [Intel-gfx] " Daniel Vetter
2021-05-19 23:17                                             ` Nieto, David M
2021-05-20 14:11                                               ` Daniel Vetter
2021-05-20 14:12                                                 ` Christian König
2021-05-20 14:17                                                   ` [Nouveau] " arabek
2021-05-20  8:35                                             ` Tvrtko Ursulin
2021-05-24 10:48                                               ` Tvrtko Ursulin
2021-05-18  9:35                               ` Tvrtko Ursulin
2021-05-18 12:06                                 ` Christian König
2021-05-17 19:16                         ` Christian König
2021-06-28 10:16                       ` Tvrtko Ursulin
2021-06-28 14:37                         ` Daniel Vetter
2021-05-17 14:20   ` Daniel Vetter

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=c85fc53f-d25b-464c-d411-eed4a509a009@linux.intel.com \
    --to=tvrtko.ursulin@linux.intel.com \
    --cc=Christian.Koenig@amd.com \
    --cc=David.Nieto@amd.com \
    --cc=Intel-gfx@lists.freedesktop.org \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@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;
as well as URLs for NNTP newsgroup(s).