Frame rate low for compositor on idle

[rinigus]

There is some choppiness while moving between pages in compositor (opened apps grid and notifications page). When checking frame rate using Developer tools, the compositor value (lower bar and number next to it) indicates low refresh rates.

In idle, while showing desktop, I get large sections with red in the line on the bottom with the rate going down to 30 (fps?). The bottom line can get almost fully red in these conditions.

With an app opened, all is in "green", bottom and top (value 62).

Such issue was not observed on AOSP9 based port.

[rinigus]

After some time, it just disappeared. There is no choppiness and frame rate is fine. Closing

[rinigus]

Just came back with the network switched on. Would have to monitor it

[rinigus]

When booting on charger, there is no slowdown (and no suspend). With usb is out, reduction of framerate will start again (and suspend will appear).

For now, not clear where is it coming from. Fortunately, it looks to be not interfering with apps.

[ApostolosB]

I see this and i have a question. Does this affect the volume bar in an app. It seems to be tearing when you turn the volume up or down.

[rinigus]

Not for me. Sorry, don't remember which device do you have, was it XZ2c? I don't see any tearing over here.

Note that there is a separate issue #150 which maybe related

[ApostolosB]

Yes xz2c. I kind of suspect all these issues will go away once this issue is solved. And as you said. At least it doesn't affect apps.

[rinigus]

The main problem is that I have no clue how to fix it yet. :)

[rinigus]

I am not sure it is a composer as such. In apps, composer refresh rate can still go lower than 62 (fps, I presume), but apps are not showing any sluggishness. Lipstick though can get sluggish...

[pagism]

i am wondering if this issue is any relevant

[rinigus]

Don't think so, as we can fix it by boosting GPU frequency.

[rinigus]

@pagism: would you mind please check on XZ3 what would be minimal frequency at which you will

• not see any XZ3 glitches in form of lines as you reported earlier
• lipstick will be smooth in transitions

For that, use

cd /sys/class/devfreq/soc:qcom,gpubw
echo FREQ > min_freq

Available frequencies are given in a separate file in this folder.

[pagism]

Available freq are: 381 572 762 1144 1720 2086 2597 2929 3879 4943 5931 6881

I had to go up to 1720 for min_freq in order not seeing those glitch lines, also transitions are smooth too.

[rinigus]

Same for me on XZ2c. I will ask regarding it - maybe there is some data the governor does not see on SFOS when compared to AOSP. Or SFOS is more demanding in drawing, which is not what I expected.

[pagism]

it's strange, increasing freq seems to fix the problem, however, checking xa2 is using the same gov and min freq is 0. xz3 gpu should be better than xa2, although xz3 has higher resolution. there was no issue earlier with aosp9 tho.

[rinigus]

I suspect that the governor is missing some data and doesn't ramp up frequency as it should. will have to ask about it.

[rinigus]

Issues with GPU on 4.14 Tama are known on AOSP side as well. According to Sony developers there seem to be some issues with blobs, some computations could be broken in those blobs, random corruptions could be there as well.

There is a "msm_legacy" driver in 4.14 tree, maybe should test that. Although, it shouldn't change idle battery drain.

If legacy will not help, it maybe the best 4.14/AOSP10 could do. we can in principle bump frequency, but that will probably induce larger drain.

[ApostolosB]

I am kind of sure i am asking a stupid question but anyway. Since the problem is in the GPU blob isn't it possible to use the freedreno driver for it?

[rinigus]

I don't know the state of freedreno on Tama, unfortunately.

[ApostolosB]

https://cgit.freedesktop.org/mesa/mesa/commit/?id=de3b34df97326b793fac2152eedbd25a0c2d0812

This exists but i suspect its not production ready. Or at least a drop in replacement.

Forget i asked.

[rinigus]

I have added GPU frequency switching to the latest zgovernor. It should bump min frequency when in Lipstick, but not in apps or while display is off. At the same time it is switching power-hungry CPUs while display is switched off.

Please install and test:

# as root
zypper ref
zypper in zgovernor

If you already have zgovernor installed then just update.

I hope that this will resolve:

• choppiness of transitions while in Lipstick
• glitches in XZ3 #150

So, looking forward to feedback.

[pagism]

thanks, updated and rebooted now, zgovernor is working and no low frame observed in lipstick, I will keep monitoring

[rinigus]

What about glitches?

[pagism]

sorry I meant both low frame and glitches are gone now, let's see battery-wise how it goes!

[rinigus]

Great! Hopefully not much as GPU is boosted only while you have display on AND are in Lipstick :)

[vladosix]

That is awesome! Helped a/with lagging and glitches!

On Sat, 10 Jul 2021, 16:05 rinigus, @.***> wrote:

Great! Hopefully not much as GPU is boosted only while you have display on AND are in Lipstick :)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/sailfishos-sony-tama/main/issues/143#issuecomment-877652220, or unsubscribe https://github.com/notifications/unsubscribe-auth/AM6ZVOBSWTX3JLN2C2AN3U3TXBOUDANCNFSM432NMGTQ .

[vladosix]

Is there a script which helps to monitor hardware states?

On Sat, 10 Jul 2021, 17:06 Владислав Могилев, @.***> wrote:

That is awesome! Helped a/with lagging and glitches!

On Sat, 10 Jul 2021, 16:05 rinigus, @.***> wrote:

Great! Hopefully not much as GPU is boosted only while you have display on AND are in Lipstick :)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/sailfishos-sony-tama/main/issues/143#issuecomment-877652220, or unsubscribe https://github.com/notifications/unsubscribe-auth/AM6ZVOBSWTX3JLN2C2AN3U3TXBOUDANCNFSM432NMGTQ .

[rinigus]

No, not really. You could use lscpu to see whether some CPUs are offline (should be when display is off) and cat /sys/class/devfreq/soc:qcom,gpubw/min_freq to see minimal frequency of GPU set by zgovernor

[pagism]

@rinigus does min_freq 381 means that GPU will keep running at that speed while the screen is off? in other devices the min_freq is 0, which I would assume that the whole GPU unit is turned off while not in use?

[rinigus]

@pagism: I did experiment by trying to enable zero MHz as well, but it was not loaded. so, probably something changed in the driver. whether it is switching gpu off or not while screen is off, I don't know. hopefully it is switched off with display off or at least during suspend, but I don't know how to check

[pagism]

I do not know either, but maybe it's worth checking, because if the clock is running indeed, that will inevitably increase power consumption. A similar situation is also observed with CPU min_freq which might be higher that the previous release?

Is there any way someone still in AOSP9 to report GPU and CPU available frequencies for comparison? is there any way to verify that while the screen is off, the GPU is inactive?

[rinigus]

Re MHz question: that is easy, GPU had the same frequencies defined in kernel as before.

As for digging out status of GPU during suspend, I can ask - had the same concerns. However, let's follow real-life battery consumption and see if it is OK or not. To me it seems fine...

Re CPU: those should be running mainly via cpufreq and I don't expect that something changed there

[pagism]

This is my feeling, (very scientific lol) I suspect blobs do lot allow running in minimal frequencies and hence we observe higher current drain. I am wondering if there is anyway to read available_frequencies in oem android, I am almost convinced that GPU ones go to 0 and the CPU ones can go lower to what we have available.

[rinigus]

OEM Android is using kernel 4.9, same kernel major version as AOSP9 is using. They both have 0 available and it is used.

I doubt that GPU is active during suspend, but maybe have to ask about it.

[vladosix]

Still see some glitches on terminal and when switching apps on xz3, but less on home screen. zgovernor is active.

[rinigus]

@vladosix: is it many glitches? are they reproducible?

if they are reproducible, what would happen if you

• turn on the screen
• switch off zgovernor (systemctl stop zgovernor)
• set min_freq at /sys/class/devfreq/soc:qcom,gpubw/min_freq to 1720

[vladosix]

Not really reproducible, sometimes happens with zgovernor on. Sporadic behaviour.

Turning on the screen with the power button is fine 9/10, reliable with no glitches.

The glitches appear during navigation on home screen, straight after zgovernor was switched off. Also glitching during turning screen on from idle. Also navigation seems slow.

Works just fine after min_freq is set to 1720.

[rinigus]

If it is rare, I would presume that it is better to keep frequency lower than have occasional issues with the terminal

So, start zgovernor again and hopefully it will be OK

[pagism]

i have not used tge device much but since the latest zgovernor update, i haven't experienced any screen glitches, transitions are smooth too, and i have the feeling power consumption is.improved .

[rinigus]

@pagism: I have a similar feeling and haven't used it much either. Let's see what will the next few days bring

[rinigus]

It all looks good to me now. Closing as zgovernor seems to be able to resolve it well. ReOpen if needed.