From: Lucas Stach <l.stach@pengutronix.de> To: Christian Gmeiner <christian.gmeiner@gmail.com>, linux-kernel@vger.kernel.org Cc: David Airlie <airlied@linux.ie>, "moderated list:DRM DRIVERS FOR VIVANTE GPU IP" <etnaviv@lists.freedesktop.org>, "open list:DRM DRIVERS FOR VIVANTE GPU IP" <dri-devel@lists.freedesktop.org>, Daniel Vetter <daniel@ffwll.ch>, Russell King <linux+etnaviv@armlinux.org.uk> Subject: Re: [PATCH v2 4/4] drm/etnaviv: export loadavg via perfmon Date: Fri, 24 Jun 2022 11:44:26 +0200 [thread overview] Message-ID: <2d475e77dca2395ee5b6fcff0e1d3ade2b0a36ef.camel@pengutronix.de> (raw) In-Reply-To: <20220621072050.76229-5-christian.gmeiner@gmail.com> Am Dienstag, dem 21.06.2022 um 09:20 +0200 schrieb Christian Gmeiner: > Make it possible to access the sub-GPU component load value from > user space with the perfmon infrastructure. > You need to explain a bit more how you intend to use those. Contrary to all other perfmon values, where we go to great lengths to only count the load put onto the GPU by the specific process requesting the perfmon, the loadavg values also include the load caused by other submits. Due to this difference in behavior I fear that those new counters might be confusing to use. But maybe you have a use-case in mind that I don't see right now. Regards, Lucas > Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> > --- > drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 79 +++++++++++++++++++++++ > 1 file changed, 79 insertions(+) > > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c > index bafdfe49c1d8..d65d9af3a74a 100644 > --- a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c > +++ b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c > @@ -120,6 +120,19 @@ static u32 hi_total_idle_cycle_read(struct etnaviv_gpu *gpu, > return gpu_read(gpu, reg); > } > > +static u32 load_read(struct etnaviv_gpu *gpu, > + const struct etnaviv_pm_domain *domain, > + const struct etnaviv_pm_signal *signal) > +{ > + u32 load; > + > + spin_lock_bh(&gpu->loadavg_spinlock); > + load = gpu->loadavg_percentage[signal->data]; > + spin_unlock_bh(&gpu->loadavg_spinlock); > + > + return load; > +} > + > static const struct etnaviv_pm_domain doms_3d[] = { > { > .name = "HI", > @@ -419,6 +432,72 @@ static const struct etnaviv_pm_domain doms_3d[] = { > &perf_reg_read > } > } > + }, > + { > + .name = "LOAD", > + .nr_signals = 12, > + .signal = (const struct etnaviv_pm_signal[]) { > + { > + "FE", > + 0, > + &load_read > + }, > + { > + "DE", > + 1, > + &load_read > + }, > + { > + "PE", > + 2, > + &load_read > + }, > + { > + "SH", > + 3, > + &load_read > + }, > + { > + "PA", > + 4, > + &load_read > + }, > + { > + "SE", > + 5, > + &load_read > + }, > + { > + "RA", > + 6, > + &load_read > + }, > + { > + "TX", > + 7, > + &load_read > + }, > + { > + "VG", > + 8, > + &load_read > + }, > + { > + "IM", > + 9, > + &load_read > + }, > + { > + "FP", > + 10, > + &load_read > + }, > + { > + "TS", > + 11, > + &load_read > + } > + } > } > }; >
WARNING: multiple messages have this Message-ID (diff)
From: Lucas Stach <l.stach@pengutronix.de> To: Christian Gmeiner <christian.gmeiner@gmail.com>, linux-kernel@vger.kernel.org Cc: David Airlie <airlied@linux.ie>, "moderated list:DRM DRIVERS FOR VIVANTE GPU IP" <etnaviv@lists.freedesktop.org>, "open list:DRM DRIVERS FOR VIVANTE GPU IP" <dri-devel@lists.freedesktop.org>, Russell King <linux+etnaviv@armlinux.org.uk> Subject: Re: [PATCH v2 4/4] drm/etnaviv: export loadavg via perfmon Date: Fri, 24 Jun 2022 11:44:26 +0200 [thread overview] Message-ID: <2d475e77dca2395ee5b6fcff0e1d3ade2b0a36ef.camel@pengutronix.de> (raw) In-Reply-To: <20220621072050.76229-5-christian.gmeiner@gmail.com> Am Dienstag, dem 21.06.2022 um 09:20 +0200 schrieb Christian Gmeiner: > Make it possible to access the sub-GPU component load value from > user space with the perfmon infrastructure. > You need to explain a bit more how you intend to use those. Contrary to all other perfmon values, where we go to great lengths to only count the load put onto the GPU by the specific process requesting the perfmon, the loadavg values also include the load caused by other submits. Due to this difference in behavior I fear that those new counters might be confusing to use. But maybe you have a use-case in mind that I don't see right now. Regards, Lucas > Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> > --- > drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 79 +++++++++++++++++++++++ > 1 file changed, 79 insertions(+) > > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c > index bafdfe49c1d8..d65d9af3a74a 100644 > --- a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c > +++ b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c > @@ -120,6 +120,19 @@ static u32 hi_total_idle_cycle_read(struct etnaviv_gpu *gpu, > return gpu_read(gpu, reg); > } > > +static u32 load_read(struct etnaviv_gpu *gpu, > + const struct etnaviv_pm_domain *domain, > + const struct etnaviv_pm_signal *signal) > +{ > + u32 load; > + > + spin_lock_bh(&gpu->loadavg_spinlock); > + load = gpu->loadavg_percentage[signal->data]; > + spin_unlock_bh(&gpu->loadavg_spinlock); > + > + return load; > +} > + > static const struct etnaviv_pm_domain doms_3d[] = { > { > .name = "HI", > @@ -419,6 +432,72 @@ static const struct etnaviv_pm_domain doms_3d[] = { > &perf_reg_read > } > } > + }, > + { > + .name = "LOAD", > + .nr_signals = 12, > + .signal = (const struct etnaviv_pm_signal[]) { > + { > + "FE", > + 0, > + &load_read > + }, > + { > + "DE", > + 1, > + &load_read > + }, > + { > + "PE", > + 2, > + &load_read > + }, > + { > + "SH", > + 3, > + &load_read > + }, > + { > + "PA", > + 4, > + &load_read > + }, > + { > + "SE", > + 5, > + &load_read > + }, > + { > + "RA", > + 6, > + &load_read > + }, > + { > + "TX", > + 7, > + &load_read > + }, > + { > + "VG", > + 8, > + &load_read > + }, > + { > + "IM", > + 9, > + &load_read > + }, > + { > + "FP", > + 10, > + &load_read > + }, > + { > + "TS", > + 11, > + &load_read > + } > + } > } > }; >
next prev parent reply other threads:[~2022-06-24 9:44 UTC|newest] Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-06-21 7:20 [PATCH v2 0/4] Add support for GPU load values Christian Gmeiner 2022-06-21 7:20 ` Christian Gmeiner 2022-06-21 7:20 ` [PATCH v2 1/4] drm/etnaviv: add simple moving average (SMA) Christian Gmeiner 2022-06-21 7:20 ` Christian Gmeiner 2022-06-24 9:22 ` Lucas Stach 2022-06-24 9:22 ` Lucas Stach 2022-07-02 11:41 ` Christian Gmeiner 2022-07-02 11:41 ` Christian Gmeiner 2022-06-21 7:20 ` [PATCH v2 2/4] drm/etnaviv: add loadavg accounting Christian Gmeiner 2022-06-21 7:20 ` Christian Gmeiner 2022-06-24 9:38 ` Lucas Stach 2022-06-24 9:38 ` Lucas Stach 2022-07-02 11:53 ` Christian Gmeiner 2022-07-02 11:53 ` Christian Gmeiner 2022-06-21 7:20 ` [PATCH v2 3/4] drm/etnaviv: show loadavg in debugfs Christian Gmeiner 2022-06-21 7:20 ` Christian Gmeiner 2022-06-21 7:20 ` [PATCH v2 4/4] drm/etnaviv: export loadavg via perfmon Christian Gmeiner 2022-06-21 7:20 ` Christian Gmeiner 2022-06-24 9:44 ` Lucas Stach [this message] 2022-06-24 9:44 ` Lucas Stach 2022-07-02 11:57 ` Christian Gmeiner 2022-07-02 11:57 ` Christian Gmeiner
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=2d475e77dca2395ee5b6fcff0e1d3ade2b0a36ef.camel@pengutronix.de \ --to=l.stach@pengutronix.de \ --cc=airlied@linux.ie \ --cc=christian.gmeiner@gmail.com \ --cc=daniel@ffwll.ch \ --cc=dri-devel@lists.freedesktop.org \ --cc=etnaviv@lists.freedesktop.org \ --cc=linux+etnaviv@armlinux.org.uk \ --cc=linux-kernel@vger.kernel.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: linkBe 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.