Re: drm/etnaviv: slow down FE idle polling

[Lucas Stach <l.stach@pengutronix.de>]

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