All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
	Daniel Vetter <daniel@ffwll.ch>
Cc: "Intel-gfx@lists.freedesktop.org"
	<Intel-gfx@lists.freedesktop.org>,
	Tvrtko Ursulin <tvrtko.ursulin@intel.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"Nieto, David M" <David.Nieto@amd.com>
Subject: Re: [RFC 7/7] drm/i915: Expose client engine utilisation via fdinfo
Date: Fri, 21 May 2021 14:32:27 +0200	[thread overview]
Message-ID: <cc77a39c-2de3-b049-e485-78f4a496b649@amd.com> (raw)
In-Reply-To: <1159220c-1a40-3e38-5885-2c8c72408da0@linux.intel.com>

Am 21.05.21 um 14:26 schrieb Tvrtko Ursulin:
>
> On 20/05/2021 18:47, Daniel Vetter wrote:
>> On Thu, May 20, 2021 at 6:31 PM Christian König
>> <christian.koenig@amd.com> wrote:
>>>
>>> Yeah, having the timestamp is a good idea as well.
>>>
>>>    drm-driver: i915
>>>
>>> I think we should rather add something like printing 
>>> file_operations->owner->name to the common fdinfo code.
>>>
>>> This way we would have something common for all drivers in the 
>>> system. I'm just not sure if that also works if they are compiled 
>>> into the kernel.
>>
>> Yeah common code could print driver name, busid and all that stuff. I
>> think the common code should also provide some helpers for the key:
>> value pair formatting (and maybe check for all lower-case and stuff
>> like that) because if we don't then this is going to be a complete
>> mess that's not parseable.
>
> I see we could have a few options here, non exhaustive list 
> (especially omitting some sub-options):
>
> 1)
> DRM core implements fdinfo, which emits the common parts, calling into 
> the driver to do the rest.
>
> 2)
> DRM adds helpers for driver to emit common parts of fdinfo.
>
> 3)
> DRM core establishes a "spec" defining the common fields, the optional 
> ones, and formats.
>
> I was trending towards 3) because it is most lightweight and feeling 
> is there isn't that much value in extracting a tiny bit of commonality 
> in code. Proof in the pudding is how short the fdinfo vfunc is in this 
> patch.
>

I would say that we should add printing the module name to the common 
fdinfo function for the whole kernel.

And for the DRM specific stuff either 2 or 3 is the way to go I think. 
Number 1 sounds to much like mid-layering to me.

Regards,
Christian.

>> And value should be real semantic stuff, not "here's a string". So
>> accumulated time as a struct ktime as the example.
>
> Ideally yes, but I have a feeling the ways how amdgpu and i915 track 
> things are so different so first lets learn more about that.
>
>>> Am 20.05.21 um 18:26 schrieb Nieto, David M:
>>>
>>> [AMD Official Use Only]
>>>
>>>
>>> i would like to add a unit marker for the stats that we monitor in 
>>> the fd, as we discussed currently we are displaying the usage 
>>> percentage, because we wanted to to provide single query 
>>> percentages, but this may evolve with time.
>>>
>>> May I suggest to add two new fields
>>>
>>> drm-stat-interval: <64 bit> ns
>>> drm-stat-timestamp: <64 bit> ns
>>>
>>> If interval is set, engine utilization is calculated by doing <perc 
>>> render> = 100*<drm_engine_render>/<drm_stat_interval>
>>> if interval is not set, two reads are needed : <perc render> = 
>>> 100*<drm_engine_render1 - drm_engine_render0> / <drm-stat-timestamp1 
>>> - drm-stat-timestamp0>
>
> I would like to understand how admgpu tracks GPU time since I am not 
> getting these fields yet.
>
> 1)
> You suggest to have a timestamp because of different clock domains?
>
> 2)
> With the interval option - you actually have a restarting counter? Do 
> you keep that in the driver or get it from hw itself?
>
> Regards,
>
> Tvrtko


WARNING: multiple messages have this Message-ID (diff)
From: "Christian König" <christian.koenig@amd.com>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
	Daniel Vetter <daniel@ffwll.ch>
Cc: "Intel-gfx@lists.freedesktop.org"
	<Intel-gfx@lists.freedesktop.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"Nieto, David M" <David.Nieto@amd.com>
Subject: Re: [Intel-gfx] [RFC 7/7] drm/i915: Expose client engine utilisation via fdinfo
Date: Fri, 21 May 2021 14:32:27 +0200	[thread overview]
Message-ID: <cc77a39c-2de3-b049-e485-78f4a496b649@amd.com> (raw)
In-Reply-To: <1159220c-1a40-3e38-5885-2c8c72408da0@linux.intel.com>

Am 21.05.21 um 14:26 schrieb Tvrtko Ursulin:
>
> On 20/05/2021 18:47, Daniel Vetter wrote:
>> On Thu, May 20, 2021 at 6:31 PM Christian König
>> <christian.koenig@amd.com> wrote:
>>>
>>> Yeah, having the timestamp is a good idea as well.
>>>
>>>    drm-driver: i915
>>>
>>> I think we should rather add something like printing 
>>> file_operations->owner->name to the common fdinfo code.
>>>
>>> This way we would have something common for all drivers in the 
>>> system. I'm just not sure if that also works if they are compiled 
>>> into the kernel.
>>
>> Yeah common code could print driver name, busid and all that stuff. I
>> think the common code should also provide some helpers for the key:
>> value pair formatting (and maybe check for all lower-case and stuff
>> like that) because if we don't then this is going to be a complete
>> mess that's not parseable.
>
> I see we could have a few options here, non exhaustive list 
> (especially omitting some sub-options):
>
> 1)
> DRM core implements fdinfo, which emits the common parts, calling into 
> the driver to do the rest.
>
> 2)
> DRM adds helpers for driver to emit common parts of fdinfo.
>
> 3)
> DRM core establishes a "spec" defining the common fields, the optional 
> ones, and formats.
>
> I was trending towards 3) because it is most lightweight and feeling 
> is there isn't that much value in extracting a tiny bit of commonality 
> in code. Proof in the pudding is how short the fdinfo vfunc is in this 
> patch.
>

I would say that we should add printing the module name to the common 
fdinfo function for the whole kernel.

And for the DRM specific stuff either 2 or 3 is the way to go I think. 
Number 1 sounds to much like mid-layering to me.

Regards,
Christian.

>> And value should be real semantic stuff, not "here's a string". So
>> accumulated time as a struct ktime as the example.
>
> Ideally yes, but I have a feeling the ways how amdgpu and i915 track 
> things are so different so first lets learn more about that.
>
>>> Am 20.05.21 um 18:26 schrieb Nieto, David M:
>>>
>>> [AMD Official Use Only]
>>>
>>>
>>> i would like to add a unit marker for the stats that we monitor in 
>>> the fd, as we discussed currently we are displaying the usage 
>>> percentage, because we wanted to to provide single query 
>>> percentages, but this may evolve with time.
>>>
>>> May I suggest to add two new fields
>>>
>>> drm-stat-interval: <64 bit> ns
>>> drm-stat-timestamp: <64 bit> ns
>>>
>>> If interval is set, engine utilization is calculated by doing <perc 
>>> render> = 100*<drm_engine_render>/<drm_stat_interval>
>>> if interval is not set, two reads are needed : <perc render> = 
>>> 100*<drm_engine_render1 - drm_engine_render0> / <drm-stat-timestamp1 
>>> - drm-stat-timestamp0>
>
> I would like to understand how admgpu tracks GPU time since I am not 
> getting these fields yet.
>
> 1)
> You suggest to have a timestamp because of different clock domains?
>
> 2)
> With the interval option - you actually have a restarting counter? Do 
> you keep that in the driver or get it from hw itself?
>
> Regards,
>
> Tvrtko

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2021-05-21 12:32 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-20 15:12 [RFC 0/7] Per client engine busyness Tvrtko Ursulin
2021-05-20 15:12 ` [Intel-gfx] " Tvrtko Ursulin
2021-05-20 15:12 ` [RFC 1/7] drm/i915: Explicitly track DRM clients Tvrtko Ursulin
2021-05-20 15:12   ` [Intel-gfx] " Tvrtko Ursulin
2021-05-20 15:12 ` [RFC 2/7] drm/i915: Update client name on context create Tvrtko Ursulin
2021-05-20 15:12   ` [Intel-gfx] " Tvrtko Ursulin
2021-05-20 15:12 ` [RFC 3/7] drm/i915: Make GEM contexts track DRM clients Tvrtko Ursulin
2021-05-20 15:12   ` [Intel-gfx] " Tvrtko Ursulin
2021-05-20 15:12 ` [RFC 4/7] drm/i915: Track runtime spent in closed and unreachable GEM contexts Tvrtko Ursulin
2021-05-20 15:12   ` [Intel-gfx] " Tvrtko Ursulin
2021-05-20 15:12 ` [RFC 5/7] drm/i915: Track all user contexts per client Tvrtko Ursulin
2021-05-20 15:12   ` [Intel-gfx] " Tvrtko Ursulin
2021-05-20 15:12 ` [RFC 6/7] drm/i915: Track context current active time Tvrtko Ursulin
2021-05-20 15:12   ` [Intel-gfx] " Tvrtko Ursulin
2021-05-20 15:12 ` [RFC 7/7] drm/i915: Expose client engine utilisation via fdinfo Tvrtko Ursulin
2021-05-20 15:12   ` [Intel-gfx] " Tvrtko Ursulin
2021-05-20 16:26   ` Nieto, David M
2021-05-20 16:26     ` [Intel-gfx] " Nieto, David M
2021-05-20 16:31     ` Christian König
2021-05-20 16:31       ` [Intel-gfx] " Christian König
2021-05-20 17:47       ` Daniel Vetter
2021-05-20 17:47         ` [Intel-gfx] " Daniel Vetter
2021-05-21 12:26         ` Tvrtko Ursulin
2021-05-21 12:26           ` [Intel-gfx] " Tvrtko Ursulin
2021-05-21 12:32           ` Christian König [this message]
2021-05-21 12:32             ` Christian König
2021-05-20 15:55 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Per client engine busyness Patchwork
2021-05-20 15:56 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2021-05-20 16:26 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-05-22  0:22 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork

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=cc77a39c-2de3-b049-e485-78f4a496b649@amd.com \
    --to=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 \
    --cc=tvrtko.ursulin@intel.com \
    --cc=tvrtko.ursulin@linux.intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.