Messages in this thread | | | Subject | Re: [PATCH] drm/panfrost: Add governor data with pre-defined thresholds | From | Lukasz Luba <> | Date | Fri, 22 Jan 2021 10:54:18 +0000 |
| |
On 1/22/21 10:24 AM, Steven Price wrote: > 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@arm.com> >>>> --- >>>> 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.
OK, I will contact you when I face some problems.
> >>> >>> Reviewed-by: Steven Price <steven.price@arm.com> >> >> Thank you for the review. I guess this patch would go through drm tree? > > Yes, I'll push it to drm-misc-next later.
Thank you!
Lukasz
| |