Low framerate on main EmulationStation menu - Pi 4

[stoo]

@bluestang I'll check your fix out soon.

I have no idea about the Pi4 arch, but in my completely ignorant opinion, this sounds like a firmware problem.

[bluestang]

@stoo Yea this could be an issue with how the kernel handles the scaling_governor on the ondemand setting. In fairness though, this could be expected behavior on this setting but I just asked the question on the official forums in the 5.4 Kernel thread.

In RetroPie's use case, it would make sense to scale the GPU to its highest allowable setting but that might not be the desired effect for users outside of RetroPie.

[stoo]

@bluestang How does it differ from the Pi3? How much does the Pi3 scale the GPU while ES is running?

The reason I ask is that while forcing the GPU to remain at 500MHz does indeed make ES much smoother on the Pi4, I can't help wondering whether we're just masking a deeper performance issue with ES...

...or a deeper performance issue somewhere else in the Pi4.

[dankcushions]

@bluestang said in Low framerate on main EmulationStation menu - Pi 4:

In RetroPie's use case, it would make sense to scale the GPU to its highest allowable setting but that might not be the desired effect for users outside of RetroPie.

i don't agree. my retropie box spends 99% of it's uptime idling in ES, so I don't want it maxed out at CPU/GPU frequencies when it doesn't need them - that's just wasting power. for portable users on batteries, it's even more important.

if the issue is confirmed i guess it's a bug with the governor not correctly evaluating the GPU demand.

[bluestang]

@stoo said in Low framerate on main EmulationStation menu - Pi 4:

@bluestang How does it differ from the Pi3? How much does the Pi3 scale the GPU while ES is running?

The reason I ask is that while forcing the GPU to remain at 500MHz does indeed make ES much smoother on the Pi4, I can't help wondering whether we're just masking a deeper performance issue with ES.

Now you are talking about hardware differences between the Pi 3 and Pi 4. There are a lot of variables involved so it's hard to even begin to go down this road.

The Pi 4 is taking a more standard approach to Linux when it comes to software development. What worked on the Pi 0-3 may not work on the Pi 4.

[stoo]

Also, the reason that this issue is so noticable on the Pi4 seems to be a difference in the way they handle framerate drops, compared to the Pi3.

On the Pi3 (at least, on my Pi3) if you open the "Start" menu in ES (the Main Menu with Scraper etc.), the framerate will drop to around 50fps. This menu seems to have a fairly heavy performance impact.

On the Pi4, opening this menu (and you may have to go into a System and look at a game list to make this happen) causes the framerate to drop to 30fps.

In other words:

Pi3, when losing v-sync, will drop to whatever framerate it can manage.

Pi4, when losing v-sync, will drop to half the refresh-rate.

[bluestang]

@dankcushions said in Low framerate on main EmulationStation menu - Pi 4:

@bluestang said in Low framerate on main EmulationStation menu - Pi 4:

In RetroPie's use case, it would make sense to scale the GPU to its highest allowable setting but that might not be the desired effect for users outside of RetroPie.

i don't agree. my retropie box spends 99% of it's uptime idling in ES, so I don't want it maxed out at CPU/GPU frequencies when it doesn't need them - that's just wasting power. for portable users on batteries, it's even more important.

if the issue is confirmed i guess it's a bug with the governor not correctly evaluating the GPU demand.

And this is the exact reason why I think the ondemand setting may be operating as advertised. No point in wasting cpu/gpu cycles for "low demand" apps.

Without any answers as to why this setting is causing this issue I can speculate all day long but no need to waste anyone's time with that.

[bluestang]

@stoo I am aware of this too. This is good info for future reference.

@stoo said in Low framerate on main EmulationStation menu - Pi 4:

Also, the reason that this issue is so noticable on the Pi4 seems to be a difference in the way they handle framerate drops, compared to the Pi3.

On the Pi3 (at least, on my Pi3) if you open the "Start" menu in ES (the Main Menu with Scraper etc.), the framerate will drop to around 50fps. This menu seems to have a fairly heavy performance impact.

On the Pi4, opening this menu (and you may have to go into a System and look at a game list to make this happen) causes the framerate to drop to 30fps.

In other words:

Pi3, when losing v-sync, will drop to whatever framerate it can manage.

Pi4, when losing v-sync, will drop to half the refresh-rate.

[FrancesKelsey]

you need to change some keys before launching

[bluestang]

The ondemand setting ramps the frequency of the gpu to its default/overlocked setting and then will downclock the gpu when not in use.

It appears that the EmulationStation OpenGL/ES calls do not trigger the gpu to ramp up its frequency therefore the gpu stays downclocked and renders 30 fps when downclocked. If it did, then the gpu would be constantly be at the 500 Mhz default setting. Just as it does for video snap playbacks, and even then after the gpu is no longer being used for video playback the kernel downclocks the gpu again. Or if you play a game from an emulator, the gpu clock rate may temporarily stay at its setting but will eventually downclock.

So there are several options, one of them was already posted earlier as to what can be done to fix this. I'm not sure opening an issue with the RPi team will fix this since the kernel seems to be behaving as expected in the ondemand setting.

The issue for me is trivial and fixable by the setting the v3d minimum frequency. My temps did not increase, in fact the only time when my temps increase to eye popping levels is during code compiles rather than the emulators I normally play.

[dankcushions]

@bluestang said in Low framerate on main EmulationStation menu - Pi 4:

So there are several options, one of them was already posted earlier as to what can be done to fix this. I'm not sure opening an issue with the RPi team will fix this since the kernel seems to be behaving as expected in the ondemand setting.

i'm not sure i understand this - emulationstation is rendering via the GPU so if it's dropping down to 30fps that implies to me that the demand is not being correctly identified, however i'm not sure how it detects GPU load/demand. i wonder if it's the same using the GLES2 version of ES? https://github.com/RetroPie/EmulationStation/commit/55df3d833235976585d549d0a0548244ab838ebf

in any case, to report it to the firmware we'd need to create a simple example program.

[bluestang]

@dankcushions said in Low framerate on main EmulationStation menu - Pi 4:

@bluestang said in Low framerate on main EmulationStation menu - Pi 4:

So there are several options, one of them was already posted earlier as to what can be done to fix this. I'm not sure opening an issue with the RPi team will fix this since the kernel seems to be behaving as expected in the ondemand setting.

i'm not sure i understand this - emulationstation is rendering via the GPU so if it's dropping down to 30fps that implies to me that the demand is not being correctly identified, however i'm not sure how it detects GPU load/demand. i wonder if it's the same using the GLES2 version of ES? https://github.com/RetroPie/EmulationStation/commit/55df3d833235976585d549d0a0548244ab838ebf

I've also tested the GLES 2.0 renderer in EmulationStation's master branch and it exhibits the same behavior.

in any case, to report it to the firmware we'd need to create a simple example program.

Agreed.

[BuZz]

Not directly related but new Mesa was mentioned. I have a branch with a module I use for testing latest mesa. It should be considered development only and it breaks often due to upstream changes. It should be considered unsupported so don't try it unless you are confident at fixing problems.

https://github.com/joolswills/RetroPie-Setup/tree/mesa

You will need to manually enable deb-src for the raspbian repos so the apt build-dep works (in raspi.list).

The module will also upgrade meson, and build new libdrm and libglvnd packages.

This builds the latest git Mesa. Using Debian package info from latest Debian experimental with some patches.

retropie_packages.sh mesa 

To install. But safer to do depends, sources, build, install separately in case of error.

retropie_packages.sh mesa downgrade

To restore to raspbian versions.

[stoo]

the only time when my temps increase to eye popping levels is during code compiles rather than the emulators I normally play.

The GPU just doesn't seem to generate that much heat. Maybe if we had a FurMark equivalent or something it would, but under normal operation, even with the frequency locked high, it seems fine.

As you say, the only time the fan on my Argon ONE case actually comes on is during compiles. Even then it tops out at around 56c (and this is with the Pi4 oc'd to 2GHz).

[bluestang]

@BuZz installed your mesa module without issue. One thing that can be done to possibly cut down on the build time/size of the mesa libraries is to just pass the needed Gallium drivers - v3d,vc4,kmsro for the Pi platform. Drm and surfaceless are default as well, so you also can just pass x11 for -Dplatform argument. I am glad to see a module that brings the latest and greatest from mesa on the pi platforms.

I don't have any experience with Debian packages so I've grown accustomed to just installing things through source.

Unfortunately, as am sure you are aware...the upstream mesa drivers don't resolve the topic of this thread (I wasn't expecting as much though just based on what I've found to be the cause personally). I also have SDL2 v2.0.12 installed on my Pi 4 and that also does not solve this issue either. I've seen that upstream "v2.0.13" has a lot of changes to the KMS/DRM driver so I guess its a wait and see approach there.

https://github.com/raspberrypi/linux/blob/rpi-5.4.y/drivers/gpu/drm/v3d/v3d_drv I believe this is the source of where the issue lies but I don't much time as of late to go through it.

[BuZz]

@bluestang Upstream changed the debian rules around a fair amount - I built with everything as it's easier to maintain and wanted to keep my rules patch minimal (See history - and meson array changes).

Current SDL2 master doesn't work at all currently on the RPI4 (the atomic code isn't supported - related to EGL_KHR_fence_sync). I plan to do a ticket upstream.

[bluestang]

@BuZz

Current SDL2 master doesn't work at all currently on the RPI4 (the atomic code isn't supported - related to EGL_KHR_fence_sync). I plan to do a ticket upstream.

Is this just a Pi4 issue or does it affect all Pis? I did learn this the hard way, so I ended up going back to v2.0.12 release.

[mtucker6784]

Don't know if this will help, or be beneficial at all to anyone at this point; but if you're still in this position, I hope this post will help you.

I have a 75" LG TV with an Rpi4 box, the tearing was pretty awful (but I never saw this problem with my previous Rpi3 box.)

Here is what I did, and followed is my configuration which seems to have done the trick.

sudo apt-get install libgles2-mesa libgles2-mesa-dev xorg-dev

Here's my config file

[pi4]
cpu_freq=1800
over_voltage=5
gpu_freq=700

[all]
dtoverlay=vc4-fkms-v3d
gpu_mem=128
hdml_drive=2
hdmi_group=1
hdmi_mode=76
dtparam=audio=on

No turbo flag, cpufrequtil or things like that. Short and simple config file.
Emulationstation shows no lag between screens, games play without tearing.

I'm sure the config file can be improved upon, or my flags aren't 100% correct and are open to criticize, or maybe the drivers weren't necessary---but in the offshoot someone is still looking for answers, I hope this helps none the less.

Good luck!

[Kestrel42]

@mtucker6784 I am running a 4 GB Pi4 B and this certainly made a noticeable difference, thank you.

I didn’t make any other changes except this.

I am using a retroflag NES case with the SSD cartridge on a 65” 4K tv.

[bluestang]

@buzz said in Low framerate on main EmulationStation menu - Pi 4:

@bluestang Upstream changed the debian rules around a fair amount - I built with everything as it's easier to maintain and wanted to keep my rules patch minimal (See history - and meson array changes).

Current SDL2 master doesn't work at all currently on the RPI4 (the atomic code isn't supported - related to EGL_KHR_fence_sync). I plan to do a ticket upstream.

Have you checked out SDL2 v2.0.14 and the 5.10.2 KMS driver? Everything seems to be working AFAIK. Considering that 5.10 is the next LTS for RPiOS that is good news.

The PulseAudio update kinda came out of nowhere, but with the KMS audio driver it is playing nice.

The 5.10.2 FKMS driver has a nasty screen tearing issue that will never be fixed. The current roadmap has the RPi4 ditching FKMS entirely.