Re: drm/etnaviv: slow down FE idle polling

From: Chris Healy <cphealy@gmail.com>
To: Lucas Stach <l.stach@pengutronix.de>
Cc: Sui Jingfeng <suijingfeng@loongson.cn>,
	etnaviv@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	patchwork-lst@pengutronix.de, kernel@pengutronix.de,
	Russell King <linux+etnaviv@armlinux.org.uk>
Subject: Re: drm/etnaviv: slow down FE idle polling
Date: Thu, 15 Jun 2023 06:41:06 -0700	[thread overview]
Message-ID: <CAFXsbZo8Kcy0OAM61ENUE64-b0imbH8yHd68Mz-4=4sNGJ5x-A@mail.gmail.com> (raw)
In-Reply-To: <7bbad708041fffac5fcaf5c0ef2b0e53c29c682a.camel@pengutronix.de>

Jingfeng,

Does your design have any bus PMU counters that can be used to measure
DRAM bandwidth of the 3D GPU directly or even indirectly?

Regards,

Chris

On Thu, Jun 15, 2023 at 2:53 AM Lucas Stach <l.stach@pengutronix.de> wrote:
>
> Am Donnerstag, dem 15.06.2023 um 17:37 +0800 schrieb Sui Jingfeng:
> > Hi,
> >
> [...]
> > > > > > > +
> > > > > > > +   /*
> > > > > > > +    * Choose number of wait cycles to target a ~30us (1/32768) max latency
> > > > > > > +    * until new work is picked up by the FE when it polls in the idle loop.
> > > > > > > +    */
> > > > > > > +   gpu->fe_waitcycles = min(gpu->base_rate_core >> (15 - gpu->freq_scale),
> > > > > > > +                            0xffffUL);
> > > > > > This patch is NOT effective on our hardware GC1000 v5037 (ls7a1000 +
> > > > > > ls3a5000).
> > > > > >
> > > > > > As the gpu->base_rate_core is 0,  so, in the end gpu->fe_waitcycles is
> > > > > > also zero.
> > > > > >
> > > > > Uh, that's a problem, as the patch will then have the opposite effect
> > > > > on your platform by speeding up the idle loop. Thanks for catching
> > > > > this! I'll improve the patch to keep a reasonable amount of wait cycles
> > > > > in this case.
> > > > It's OK, no big problem as far as I can see. (it my platform's problem,
> > > > not your problem)
> > > >
> > > It will become a problem as it eats up the bandwidth that you want to
> > > spend for real graphic work.
> > >
> > > > Merge it is also OK, if we found something wrong we could fix it with a
> > > > another patch.
> > > >
> > > Hmm.. I think that the fix for this problem is more or less an extra
> > > if so I would love to see a proper fix
> > > before this patch gets merged.
>
> Right, we don't merge known broken stuff. We are all humans and bugs
> and oversights happen, but we don't knowingly regress things.
>
> >
> > It just no effect(at least I can't find).
> >
> > I have tried, The score of glmark2 does not change, not become better,
> > not become worse.
>
> That's because it only affects your system when the GPU is idle but
> isn't in runtime PM yet. If you measure the DRAM bandwidth in that time
> window you'll see that the GPU now uses much more bandwidth, slowing
> down other workloads.
>
> Regards,
> Lucas
>