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,
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
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
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] Per client engine busyness
On 17/05/2021 15:39,
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
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: [PAT
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
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
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 */
; 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 sim
; 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
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,
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
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.
sday, 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 at 12:41 PM Tvrtko Ursulin
wrote:
--
*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, 2
;
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
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
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
27 matches
Mail list logo
