Low framerate on main EmulationStation menu - Pi 4

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.

paddydukes

Here's my 2c. I also have a 65" LCD tv. I am using the retropie exclusively for games. I was getting crazy low framerate in the main menu, and more worryingly in games. It turned out that the PI was detecting the 4k capabiltiy and autodefaulting to that mode.

I set it to output in 720p, set the TV to detect the resolution so that it adapts to etc. in game.

I am setting 16 bit consoles to runahead 2 frames. So far I've not noticed any tearing or slowdown in SNES and SEGA. I don't really play NES but can test. I haven't noticed any tearing in alphaneo.

I do notice some tearing in N64 and Dreamcast. Mostly in Redream though, and it is experimental. Still, it's the best Dreamcast emulator IMO.

I added comical notes to my config. Edited to remove some unnecessary settings that were the result of incremental change and experimentation:

# uncomment this if your display has a black border of unused pixels visible
# and your display can output without overscan
disable_overscan=1
# uncomment to force a specific HDMI mode (this will force VGA)
# Set to 720p 60hz
hdmi_group=1
hdmi_mode=4
#OVERCLOCK
# Up voltage
over_voltage=6
# Arm at 2
arm_freq=2000
# read loads of shite saying that you should edit v3d directly. It capped me at 500. Changed gpu_freq, boom 700. So I guess don't believe everything you read
gpu_freq=700

@bluestang I would like to do an experimental build on a different card. I couldn't find good simple instructions on using the KMS driver. When I tried to set the dt_overlay to kms as per online instructions it would fail to boot. If I removed the hdmi cable I could SSH in, but reconnecting it wasn't detected by the TV. Soon as I revert it is detected again. Wasn't sure if I was missing drivers or what I had to do to get them.

Also I've been noticing a few random crashes and reboots, so I might reduce some of the current overclock.

bluestang

@paddydukes said in [Low framerate on main EmulationStation menu - Pi 4]

@bluestang I would like to do an experimental build on a different card. I couldn't find good simple instructions on using the KMS driver. When I tried to set the dt_overlay to kms as per online instructions it would fail to boot. If I removed the hdmi cable I could SSH in, but reconnecting it wasn't detected by the TV. Soon as I revert it is detected again. Wasn't sure if I was missing drivers or what I had to do to get them.

Also I've been noticing a few random crashes and reboots, so I might reduce some of the current overclock.

First and foremost you need to run the latest kernel by running sudo apt update && sudo apt full-upgrade -y.

There are additional steps that you need to do to set up the KMS driver but first let's address your /boot/config.txt:

gpu_freq sets the core clock for various blocks in the gpu and is not recommended anymore.
Change gpu_freq to v3d_freq=700.
I also set the minimum v3d freq to 500, v3d_freq_min=500 but this is completely optional.
gpu_mem is also not a setting needed for the Pi4 either, you can delete this alltogether.

Proper overclocking documentation can be found here. Make sure that you are using an adequate cooling solution when overclocking.

Now there are 2 distinct configurations you can use from this point forward w/ KMS:

1. KMS w/ Broadcom Audio:
dtoverlay=vc4-kms-v3d,noaudio **AND** dtparam=audio=on in /boot/config.txt
***This uses the KMS driver only for display and uses the Broadcom firmware audio driver***
***dtparam=audio=on must be placed before dtoverlay=vc4-kms-v3d,noaudio or else you will have no audio!!!***

If you chose option 1, you can reboot after you have edited the /boot/config.txt file with the necessary changes.

2. KMS w/ KMS Audio: 
dtoverlay=vc4-kms-v3d ***AND*** dtparam=audio=off or commented in /boot/config.txt
***This uses the KMS driver for display and audio and disables firmware audio, however, it requires more files to be edited to get KMS audio to work***
Note: the KMS audio is capable of multi-channel audio i.e. 5.1, 7.1, etc. You will need to look at the volume control applet on the desktop and see what is available to your setup.

For both options, you will need to edit the /boot/config.txt.

If you choose to go with option 2, you will also need to edit the vc4-hdmi.conf file and the pulse audio rules file to get sound from the KMS audio driver to work properly.

Edit as follows w/ proper privileges:

/usr/share/alsa/cards/vc4-hdmi.conf

# Configuration for the VC4-HDMI sound card using software IEC958
# subframe conversion

<confdir:pcm/hdmi.conf>
vc4-hdmi.pcm.hdmi.0 {
	@args [ CARD AES0 AES1 AES2 AES3 ]
	@args.CARD {
		type string
	}
	@args.AES0 {
		type integer
	}
	@args.AES1 {
		type integer
	}
	@args.AES2 {
		type integer
	}
	@args.AES3 {
		type integer
	}
	type iec958
	slave {
		format IEC958_SUBFRAME_LE
		pcm {
			type hooks
			slave.pcm {
				type hw
				card $CARD
				device 0
			}
			hooks.0 {
				type ctl_elems
				hook_args [
				{
					name "IEC958 Playback Default"
					optional true
					lock true
					preserve true
					value [ $AES0 $AES1 $AES2 $AES3 ]
				}
				]
			}
		}
	}
	status [ $AES0 $AES1 $AES2 $AES3 ]
}

# default with plug
vc4-hdmi.pcm.default {
	@args [ CARD ]
	@args.CARD {
		type string
	}
	type plug
	slave.pcm {
		type softvol
		slave.pcm {
			@func concat
			strings [ "hdmi:" $CARD ]
		}
		control {
			name "PCM Playback Volume"
			card $CARD
		}
	}
}

The PulseAudio rules file needs to be edited as well.

/lib/udev/rules.d/91-pulseaudio-rpi.rules

SUBSYSTEM!="sound*", GOTO="end"
ACTION!="change", GOTO="end"
KERNEL!="card*", GOTO="end"
ENV{SOUND_FORM_FACTOR}!="internal", GOTO="end"

ATTRS{id}=="b1", ENV{PULSE_PROFILE_SET}="rpi-hdmi.conf", GOTO="end"
ATTRS{id}=="b2", ENV{PULSE_PROFILE_SET}="rpi-hdmi.conf", GOTO="end"
ATTRS{id}=="Headphones", ENV{PULSE_PROFILE_SET}="rpi-analog.conf", GOTO="end"

LABEL="end"

Reboot after all changes have been made and enjoy!

paddydukes

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

v3d_freq_min=500

When I changed V3d_freq to 700, and monitored it using bcmstat.sh while running games, it would not go over 500. When I set gpu_freq to 700, it goes to 700. I realise this goes against the pi4 documentation, but those are my results.

Earlier I added

dtoverlay=vc4-kms-v3d-pi4,noaudio
dtparam=audio=on

Tried also without -pi4 (docs say to add -pi4)
And HDMI was no longer recognizing the Pi...

I get:
Rom flash, Rainbow screen, First stream of kernel loading, then no signal.

If I change back to fkms it returns.

Also weirdly I have to unplug hdmi and reboot to be able to get back in via SSH.

Oh and Happy New Year!

bluestang

@paddydukes

What about just using vcgencmd measure_clock v3d?

the core freq will stay at 500, what you want to see is v3d at the overclocked setting instead.

As for the HDMI issue...can you post your whole /boot/config.txt?

And Happy New Year to you too!