drm/etnaviv: slow down FE idle polling

[Sui Jingfeng]

Hi,

On 2023/6/15 21:41, Chris Healy wrote:
> 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?

No,  It seems that we don't have such hardware.


What we can do is measure by the CPU,  say write a memcpy program.

Testing the system ram to vram and vram to system bandwidth.

system ram to system ram bandwidth.

Out 3a5000 system RAM bandwidth can be 10 GB/s (tested by memcpy testing 
program 1920x1080)

But the GPU is inside the north bridge,  Access memory from there is a 
bit slower.

because it need cross the HT bus.  But I don't mind.

> Regards,
>
> Chris
>
> On Thu, Jun 15, 2023 at 2:53 AM Lucas Stach <l.stach at 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
>>
-- 
Jingfeng