On Mon, Jun 28, 2021 at 12:18 PM Tvrtko Ursulin
wrote:
>
>
>
> On 14/05/2021 16:10, Christian König wrote:
> > Am 14.05.21 um 17:03 schrieb Tvrtko Ursulin:
> >>
> >> On 14/05/2021 15:56, Christian König wrote:
> >>> Am 14.05.21 um 16:47 schrieb Tvrtko Ursulin:
>
> On 14/05/2021 14:53, Ch
On 14/05/2021 16:10, Christian König wrote:
Am 14.05.21 um 17:03 schrieb Tvrtko Ursulin:
On 14/05/2021 15:56, Christian König wrote:
Am 14.05.21 um 16:47 schrieb Tvrtko Ursulin:
On 14/05/2021 14:53, Christian König wrote:
David also said that you considered sysfs but were wary of
expos
On 20/05/2021 09:35, Tvrtko Ursulin wrote:
On 19/05/2021 19:23, Daniel Vetter wrote:
On Wed, May 19, 2021 at 6:16 PM Tvrtko Ursulin
wrote:
On 18/05/2021 10:40, Tvrtko Ursulin wrote:
On 18/05/2021 10:16, Daniel Stone wrote:
Hi,
On Tue, 18 May 2021 at 10:09, Tvrtko Ursulin
wrote:
I was
> Well if it becomes a problem fixing the debugfs "clients" file and
> making it sysfs shouldn't be much of a problem later on.
Why not to try using something in terms of perf / opensnoop or bpf
to do the work. Should be optimal enough.
ie.
http://www.brendangregg.com/blog/2014-07-25/opensnoop-fo
021 11:23 AM
To: Tvrtko Ursulin
Cc: Daniel Stone ; jhubb...@nvidia.com ; nouv...@lists.freedesktop.org
; Intel Graphics Development ; Maling list - DRI
developers ; Simon Ser ; Koenig, Christian
; arit...@nvidia.com ; Nieto, David M
Subject: Re: [Intel-gfx] [PATCH 0/7] Per client engine busyness
On
lopment
> ; Maling list - DRI developers
> ; Simon Ser ; Koenig,
> Christian ; arit...@nvidia.com
> ; Nieto, David M
> Subject: Re: [Intel-gfx] [PATCH 0/7] Per client engine busyness
>
> On Wed, May 19, 2021 at 6:16 PM Tvrtko Ursulin
> wrote:
> >
> >
> >
On 19/05/2021 19:23, Daniel Vetter wrote:
On Wed, May 19, 2021 at 6:16 PM Tvrtko Ursulin
wrote:
On 18/05/2021 10:40, Tvrtko Ursulin wrote:
On 18/05/2021 10:16, Daniel Stone wrote:
Hi,
On Tue, 18 May 2021 at 10:09, Tvrtko Ursulin
wrote:
I was just wondering if stat(2) and a chrdev majo
;
Nieto, David M
Subject: Re: [Intel-gfx] [PATCH 0/7] Per client engine busyness
On Wed, May 19, 2021 at 6:16 PM Tvrtko Ursulin
wrote:
>
>
> On 18/05/2021 10:40, Tvrtko Ursulin wrote:
> >
> > On 18/05/2021 10:16, Daniel Stone wrote:
> >> Hi,
> >>
> >&
On Wed, May 19, 2021 at 6:16 PM Tvrtko Ursulin
wrote:
>
>
> On 18/05/2021 10:40, Tvrtko Ursulin wrote:
> >
> > On 18/05/2021 10:16, Daniel Stone wrote:
> >> Hi,
> >>
> >> On Tue, 18 May 2021 at 10:09, Tvrtko Ursulin
> >> wrote:
> >>> I was just wondering if stat(2) and a chrdev major check would
On 18/05/2021 10:40, Tvrtko Ursulin wrote:
On 18/05/2021 10:16, Daniel Stone wrote:
Hi,
On Tue, 18 May 2021 at 10:09, Tvrtko Ursulin
wrote:
I was just wondering if stat(2) and a chrdev major check would be a
solid criteria to more efficiently (compared to parsing the text
content) detect d
u show by pid/tgid or by fd.
Regards,
Tvrtko
*From:* Tvrtko Ursulin
*Sent:* Monday, May 17, 2021 9:00 AM
*To:* Nieto, David M ; Daniel Vetter
; Koenig, Christian
*Cc:* Alex Deucher ; Intel Graphics
Development ; Maling list - DRI
developers
*Subject:* Re: [PATCH 0/7]
On 18/05/2021 10:16, Daniel Stone wrote:
Hi,
On Tue, 18 May 2021 at 10:09, Tvrtko Ursulin
wrote:
I was just wondering if stat(2) and a chrdev major check would be a
solid criteria to more efficiently (compared to parsing the text
content) detect drm files while walking procfs.
Maybe I'm mi
[PATCH 0/7] Per client engine busyness
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 suggest
Hi,
On Tue, 18 May 2021 at 10:09, Tvrtko Ursulin
wrote:
> I was just wondering if stat(2) and a chrdev major check would be a
> solid criteria to more efficiently (compared to parsing the text
> content) detect drm files while walking procfs.
Maybe I'm missing something, but is the per-PID walk
On 17/05/2021 20:03, Simon Ser wrote:
On Monday, May 17th, 2021 at 8:16 PM, Nieto, David M
wrote:
Btw is DRM_MAJOR 226 consider uapi? I don't see it in uapi headers.
It's not in the headers, but it's de facto uAPI, as seen in libdrm:
> git grep 226
xf86drm.c
99:#define DRM
Am 17.05.21 um 16:30 schrieb Daniel Vetter:
[SNIP]
Could be that i915 has some special code for that, but on my laptop
I only see the X server under the "clients" debugfs file.
Yes we have special code in i915 for this. Part of this series we are
discussing here.
Ah, yeah you should mention th
On Monday, May 17th, 2021 at 8:16 PM, Nieto, David M
wrote:
> Btw is DRM_MAJOR 226 consider uapi? I don't see it in uapi headers.
It's not in the headers, but it's de facto uAPI, as seen in libdrm:
> git grep 226
xf86drm.c
99:#define DRM_MAJOR 226 /* Linux */
evelopment
; Maling list - DRI developers
Subject: Re: [PATCH 0/7] Per client engine busyness
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 we
; Maling list - DRI developers
Subject: Re: [PATCH 0/7] Per client engine busyness
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 o
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
; Intel Graphics
Development ; Maling list - DRI developers
; Daniel Vetter
Subject: Re: [PATCH 0/7] Per client engine busyness
On Fri, May 14, 2021 at 05:10:29PM +0200, Christian König wrote:
> Am 14.05.21 um 17:03 schrieb Tvrtko Ursulin:
> >
> > On 14/05/2021 15:56, Christ
On Fri, May 14, 2021 at 05:10:29PM +0200, Christian König wrote:
> Am 14.05.21 um 17:03 schrieb Tvrtko Ursulin:
> >
> > On 14/05/2021 15:56, Christian König wrote:
> > > Am 14.05.21 um 16:47 schrieb Tvrtko Ursulin:
> > > >
> > > > On 14/05/2021 14:53, Christian König wrote:
> > > > > >
> > > > >
On Thu, May 13, 2021 at 11:48:08AM -0400, Alex Deucher wrote:
> On Thu, May 13, 2021 at 7:00 AM Tvrtko Ursulin
> wrote:
> >
> > From: Tvrtko Ursulin
> >
> > Resurrect of the previosuly merged per client engine busyness patches. In a
> > nutshell it enables intel_gpu_top to be more top(1) like use
Am 14.05.21 um 17:03 schrieb Tvrtko Ursulin:
On 14/05/2021 15:56, Christian König wrote:
Am 14.05.21 um 16:47 schrieb Tvrtko Ursulin:
On 14/05/2021 14:53, Christian König wrote:
David also said that you considered sysfs but were wary of
exposing process info in there. To clarify, my patch
On 14/05/2021 15:56, Christian König wrote:
Am 14.05.21 um 16:47 schrieb Tvrtko Ursulin:
On 14/05/2021 14:53, Christian König wrote:
David also said that you considered sysfs but were wary of exposing
process info in there. To clarify, my patch is not exposing sysfs
entry per process, but
Am 14.05.21 um 16:47 schrieb Tvrtko Ursulin:
On 14/05/2021 14:53, Christian König wrote:
David also said that you considered sysfs but were wary of exposing
process info in there. To clarify, my patch is not exposing sysfs
entry per process, but one per open drm fd.
Yes, we discussed thi
On 14/05/2021 14:53, Christian König wrote:
David also said that you considered sysfs but were wary of exposing
process info in there. To clarify, my patch is not exposing sysfs
entry per process, but one per open drm fd.
Yes, we discussed this as well, but then rejected the approach.
T
*From:* Alex Deucher
*Sent:* Thursday, May 13, 2021 10:58 PM
*To:* Tvrtko Ursulin ; Nieto, David
M ; Koenig, Christian
*Cc:* Intel Graphics Development ;
Maling list - DRI developers ;
Daniel Vetter
*Subject:* Re: [PATCH 0/7] Per client engine busyness
+ David, Christian
On Thu, May 13, 2021 a
-
*From:* Alex Deucher
*Sent:* Thursday, May 13, 2021 10:58 PM
*To:* Tvrtko Ursulin ; Nieto, David M
; Koenig, Christian
*Cc:* Intel Graphics Development ;
Maling list - DRI developers ; Daniel
Vetter
*Subject:* Re: [PATCH 0/7] Per client engine busyness
+ David, Christian
On
;
Maling list - DRI developers ; Daniel
Vetter
*Subject:* Re: [PATCH 0/7] Per client engine busyness
+ David, Christian
On Thu, May 13, 2021 at 12:41 PM Tvrtko Ursulin
wrote:
>
>
> Hi,
>
> On 13/05/2021 16:48, Alex Deucher wrote:
> > On Thu, May 13, 2021 at 7:00 AM Tvrt
Vetter
Subject: Re: [PATCH 0/7] Per client engine busyness
+ David, Christian
On Thu, May 13, 2021 at 12:41 PM Tvrtko Ursulin
wrote:
>
>
> Hi,
>
> On 13/05/2021 16:48, Alex Deucher wrote:
> > On Thu, May 13, 2021 at 7:00 AM Tvrtko Ursulin
> > wrote:
>
+ David, Christian
On Thu, May 13, 2021 at 12:41 PM Tvrtko Ursulin
wrote:
>
>
> Hi,
>
> On 13/05/2021 16:48, Alex Deucher wrote:
> > On Thu, May 13, 2021 at 7:00 AM Tvrtko Ursulin
> > wrote:
> >>
> >> From: Tvrtko Ursulin
> >>
> >> Resurrect of the previosuly merged per client engine busyness p
Hi,
On 13/05/2021 16:48, Alex Deucher wrote:
On Thu, May 13, 2021 at 7:00 AM Tvrtko Ursulin
wrote:
From: Tvrtko Ursulin
Resurrect of the previosuly merged per client engine busyness patches. In a
nutshell it enables intel_gpu_top to be more top(1) like useful and show not
only physical GP
On Thu, May 13, 2021 at 7:00 AM Tvrtko Ursulin
wrote:
>
> From: Tvrtko Ursulin
>
> Resurrect of the previosuly merged per client engine busyness patches. In a
> nutshell it enables intel_gpu_top to be more top(1) like useful and show not
> only physical GPU engine usage but per process view as we
From: Tvrtko Ursulin
Resurrect of the previosuly merged per client engine busyness patches. In a
nutshell it enables intel_gpu_top to be more top(1) like useful and show not
only physical GPU engine usage but per process view as well.
Example screen capture:
~
35 matches
Mail list logo
