Re: [PATCH] drm/panfrost: Add governor data with pre-defined thresholds

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 22/01/2021 10:00, Lukasz Luba wrote:


On 1/22/21 8:21 AM, Steven Price wrote:
On 21/01/2021 17:04, Lukasz Luba wrote:
The simple_ondemand devfreq governor uses two thresholds to decide about
the frequency change: upthreshold, downdifferential. These two tunable
change the behavior of the governor decision, e.g. how fast to increase
the frequency or how rapidly limit the frequency. This patch adds needed
governor data with thresholds values gathered experimentally in different
workloads.

Signed-off-by: Lukasz Luba <lukasz.luba@xxxxxxx>
---
Hi all,

This patch aims to improve the panfrost performance in various workloads,
(benchmarks, games). The simple_ondemand devfreq governor supports
tunables to tweak the behaviour of the internal algorithm. The default
values for these two thresholds (90 and 5) do not work well with panfrost.
These new settings should provide good performance, short latency for
rising the frequency due to rapid workload change and decent freq slow
down when the load is decaying. Based on frequency change statistics,
gathered during experiments, all frequencies are used, depending on
the load. This provides some power savings (statistically). The highest
frequency is also used when needed.

Example glmark2 results:
1. freq fixed to max: 153
2. these new thresholds values (w/ patch): 151
3. default governor values (w/o patch): 114

It would be good to state which platform this is on as this obviously can vary depending on the OPPs available.

Sorry about that. It was Rock Pi 4B and I have mesa 20.2.4.


Of course the real fix here would be to improve the utilisation of the GPU[1] so we actually hit the 90% threshold more easily (AFAICT kbase uses the default 90/5 thresholds), but this seems like a reasonable change for now.

Agree, improving the scheduler would be the best option. I'll have a
look at that patch and why it got this 10% lower performance. Maybe
I would find something during testing.

I'm afraid it'll probably need a fair bit of work to rebase - things have changed around that code. I'm hoping that most of the problem was really around how Mesa was driving the GPU at that time and things should be better. The DDK (hacked to talk Panfrost ioctls) saw a performance improvement.

Let me know if you hit problems and need any help.


Reviewed-by: Steven Price <steven.price@xxxxxxx>

Thank you for the review. I guess this patch would go through drm tree?

Yes, I'll push it to drm-misc-next later.

Thanks,

Steve

Regards,
Lukasz


Thanks,

Steve

[1] When I get some time I need to rework the "queue jobs on the hardware"[2] patch I posted ages ago. Last time it actually caused a performance regression though...

[2] https://lore.kernel.org/r/20190816093107.30518-2-steven.price%40arm.com


_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel



[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux