Good news regarding tearing and low EmulationStation performance on Pi 4

Darksavior

@Brunnis Are they still not providing kernel headers even if it's in the "next" branch? My snes pad driver needs it. It's why I've never bothered using bleeding edge kernels.

Brunnis

@Darksavior I’m not sure about that. I haven’t seen that they do, though, so maybe not then.

EmulationStation started up fine on my build, but there’s no sound. Need to get that working before I do any testing.

bluestang

@Brunnis If you are using the KMS audio driver then you need to replace the code in vc4-hdmi.conf in usr/share/alsa/cards with the following:

# 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
		}
	}
}

If you are trying to use the firmware Broadcom audio driver with the KMS audio disabled (vc4-kms-v3d,noaudio) then at present the 5.9 kernel is broken. A fix has been committed, but rpi-update has not been updated with the latest change.

Brunnis

@bluestang Ahh, thanks, that worked nicely! So, compared to current RetroPie images, I now have an installation that runs:

64-bit kernel and userland
Linux kernel 5.9
Bleeding edge Mesa ("20.3")
The full KMS video driver
The new ARM-side HDMI audio driver

That's quite a lot of under the hood changes. Despite this, I actually once again ran into the dreaded 30 FPS issue in EmulationStation. To the best of my knowledge, this only plagues the Pi 4, right? No other Pi and no other platform has this issue?

Darksavior

@Brunnis Last time I checked, ES runs at 60fps on my pi3b+ using the default low-res scraped box art. I switched to the pegasus-frontend with higher res box art, and it really lags on my pi3b+ (because of the box art) but on my pi4 it's butter smooth.

Also, Is there a real reason to go bleeding edge? I thought that in time, the pi4 would have drivers to handle the crt-pi shader at 4k, or at least the pc crt shaders at 1080p. I expected too much, I suppose.

bluestang

@Brunnis the "30 FPS issue" in EmulationStation on a Pi4 is something that requires a more in-depth investigation.

The only way I can overcome this issue is by setting v3d_freq_min=500 in /boot/config.txt, however, this is not a solution that works for everyone.

What I found out is that once v3d_freq is downclocked (~200-250MHz) when at idle the FPS will drop to 30 FPS in EmulationStation. Once v3d is taken off of idle (i.e. video playback, 3D game, etc) EmulationStation's FPS will jump up back to 60 FPS.

I've spent more time than I care to admit trying see what is the cause but have come up empty.

The one thing I have not tried is Batocera's implementation of EmulationStation. I'd be curious to know if it also has the same FPS issue. The reasoning behind my curiousity is that Batocera's OpenGLES implementation of EmulationStation was completely re-done.

If Batocera's EmulationStation doesn't have the same issue than that would narrow down what is causing the FPS problem.

Darksavior

@bluestang I'd test out batocera but I get a black screen. Might be the usb boot, I don't know (I'm not opening up my snes case to use the microsd).

Brunnis

@bluestang Interesting. It would make sense and could also explain the intermittent/unpredictable behavior. For example, at one point (when I started this thread) I could no longer reproduce the issue. Then it came back, perhaps after firmware changes to the clock frequency scaling were made. I know this part of the firmware has received several changes over the course of the 16 months since the Pi 4 was released.

I wonder why the Pi 4 can't determine that it needs to clock the V3D up in these situations... Have you had any discussions with the Raspberry Pi folks (i.e. 6by9) regarding this issue?

@Darksavior Real reason to go bleeding edge? Only for testing out what might become the future of RetroPie and report issues found to the involved parties. I wouldn't attempt it on a system I intend to actually use for gaming.

bluestang

@Brunnis said in Good news regarding tearing and low EmulationStation performance on Pi 4:

@bluestang
I wonder why the Pi 4 can't determine that it needs to clock the V3D up in these situations... Have you had any discussions with the Raspberry Pi folks (i.e. 6by9) regarding this issue?

I did bring it up in the RPi forums but without a solid example of duplicating the problem it’s hard for the engineers to diagnose it. Especially since the driver behavior norms are to downclock when it is idle.

I also managed to run a fresh install of Batocera on my Pi4 and it’s based on the 5.4 kernel and the KMS driver. Considering that the 5.4 KMS is WIP that will never progress like 5.9 I was pleased with the results I saw.

I need to do some further investigating.

George Spiggott

Not sure if this info has already been posted.

https://www.raspberrypi.org/blog/vulkan-update-merged-to-mesa/

BTW: How do you find which version of Mesa you currently have installed on your Pi?

mitu

@George-Spiggott You run one of

apt show libglapi-mesa
dpkg -l | grep mesa

Brunnis

@bluestang I just tried setting v3d_freq_min=500 and sure enough it seems to fully cure the problem on my side. I tried rebooting a couple of times with and without the setting and could easily reproduce the issue without it.

I can also report that N64 with mupen64plus-next is pretty terrible with this setup. Tried GoldenEye and Shadows of the Empire and the audio issues are massive. Instead of audio artifacts like I'm used to, the audio simply cuts out and can be gone for long stretches of time.

dankcushions

@Brunnis n64 is bad WITH v3d_freq_min=500? that doesn't seem very intuitive.

if it's an improvement, and if we can get a collection of results (via different emulators/programs) before/after this change i think we might have enough to submit as a firmware bug.

Brunnis

@dankcushions said in Good news regarding tearing and low EmulationStation performance on Pi 4:

@Brunnis n64 is bad WITH v3d_freq_min=500? that doesn't seem very intuitive.

if it's an improvement, and if we can get a collection of results (via different emulators/programs) before/after this change i think we might have enough to submit as a firmware bug.

Sorry, I was talking about two different things. 500MHz minimum V3D solved the EmulationStation bug. This has no effect on N64. It's bad either way with this setup. I'm guessing the new HDMI audio driver plays a part in that.

dankcushions

@Brunnis one issue at a time... does it (v3d_min) solve the tearing issues in other emulators? it's difficult to recreate as they seem to be sporadic.

Brunnis

@dankcushions said in Good news regarding tearing and low EmulationStation performance on Pi 4:

@Brunnis one issue at a time... does it (v3d_min) solve the tearing issues in other emulators? it's difficult to recreate as they seem to be sporadic.

Sorry, I have not really evaluated the tearing issue yet, only the EmulationStation 30 FPS issue. No idea if these two issues are related.

I will do some testing and look for tearing using different settings.

bluestang

@dankcushions I think we are also talking another 2 separate issues.

The 30 FPS bug in EmulationStation is an issue with v3d being downclocked below 500 MHz. As I previously posted, the only workaround at the moment is to set the v3d_freq_min parameter in config.txt.

The screen tearing issue is more than likely the FKMS driver or an incomplete 5.4 KMS driver that will not be fixed either. Since FKMS is closed source code it will not be fixed, hence why 5.9+ KMS is the future moving forward or at least that is what 6by9 is saying on the RPi forums.

Recent reports from the RPi forums have been positive with the regards to the 5.9 KMS driver. Unfortunately the 5.4 KMS driver will not be backported with the 5.9 KMS code. The 5.4 KMS code is incomplete and missing things that the 5.9 kernel has featured. At some point, maybe later this year or early next, RPiOS will make another kernel jump to 5.9 or 5.10 depending on what becomes the official LTS kernel at the end of this year.

bluestang

@Brunnis said in Good news regarding tearing and low EmulationStation performance on Pi 4:

@bluestang I just tried setting v3d_freq_min=500 and sure enough it seems to fully cure the problem on my side. I tried rebooting a couple of times with and without the setting and could easily reproduce the issue without it.

I can also report that N64 with mupen64plus-next is pretty terrible with this setup. Tried GoldenEye and Shadows of the Empire and the audio issues are massive. Instead of audio artifacts like I'm used to, the audio simply cuts out and can be gone for long stretches of time.

Have you tried 5.9 KMS with the Broadcom audio driver? The latest build of 5.9 has fixed the issue and you can go back and disable the KMS audio driver and enable the Broadcom audio driver like before.

The KMS audio driver is still a WIP. I don’t use it at all because it doesn’t support audio mixing from more than 1 audio source.

mitu

@bluestang said in Good news regarding tearing and low EmulationStation performance on Pi 4:

The 30 FPS bug in EmulationStation is an issue with v3d being downclocked below 500 MHz. As I previously posted, the only workaround at the moment is to set the v3d_freq_min parameter in config.txt.

Are you sure ? I rarely get the 30fps issue and usually the core freq is max 500 Mhz. Here's a bcmstat output while switching systems rapidly and then entering a system:

Time         ARM    Core    H264 Core Temp (Max)  IRQ/s      RX B/s      TX B/s
======== ======= ======= ======= =============== ====== =========== ===========
19:18:55  600Mhz  200Mhz    0Mhz 47.23C (50.63C)    319           0           0
19:18:58  600Mhz  200Mhz    0Mhz 46.74C (50.63C)    261           0           0
19:19:00  600Mhz  200Mhz    0Mhz 47.71C (50.63C)    258           0           0
19:19:02  600Mhz  200Mhz    0Mhz 48.20C (50.63C)    320           0           0
19:19:04  600Mhz  250Mhz    0Mhz 48.20C (50.63C)    263           0           0
19:19:06  600Mhz  200Mhz    0Mhz 48.20C (50.63C)    258           0           0
19:19:08  600Mhz  200Mhz    0Mhz 47.71C (50.63C)    253           0           0
19:19:10  600Mhz  200Mhz    0Mhz 47.71C (50.63C)    259           0           0
19:19:12  600Mhz  200Mhz    0Mhz 47.71C (50.63C)    255           0           0
19:19:14  600Mhz  250Mhz    0Mhz 48.20C (50.63C)    266           0           0
19:19:16  600Mhz  200Mhz    0Mhz 48.69C (50.63C)    315           0           0
19:19:18  600Mhz  200Mhz    0Mhz 47.23C (50.63C)    325           0           0
19:19:20  600Mhz  200Mhz    0Mhz 47.23C (50.63C)    250           0           0
19:19:22 1500Mhz  500Mhz    0Mhz 49.17C (50.63C)    617           0           0
19:19:24  750Mhz  250Mhz    0Mhz 49.17C (50.63C)    997           0           0
19:19:26  750Mhz  250Mhz    0Mhz 49.17C (50.63C)  1,221           0           0
19:19:28  750Mhz  250Mhz    0Mhz 49.66C (50.63C)  1,093           0           0
19:19:30 1000Mhz  333Mhz    0Mhz 50.15C (50.63C)  1,079           0           0
19:19:32 1000Mhz  333Mhz    0Mhz 50.15C (50.63C)  1,084           0           0
19:19:35  750Mhz  250Mhz    0Mhz 49.66C (50.63C)  1,076           0           0
19:19:37  600Mhz  200Mhz    0Mhz 49.17C (50.63C)    262           0           0
19:19:39  600Mhz  250Mhz    0Mhz 49.17C (50.63C)    263           0           0

This is with the default (Carbon) theme, default config.txt and a 1600x1200 resolution.

bluestang

@mitu said in Good news regarding tearing and low EmulationStation performance on Pi 4:

@bluestang said in Good news regarding tearing and low EmulationStation performance on Pi 4:

The 30 FPS bug in EmulationStation is an issue with v3d being downclocked below 500 MHz. As I previously posted, the only workaround at the moment is to set the v3d_freq_min parameter in config.txt.

Are you sure ? I rarely get the 30fps issue and usually the core freq is max 500 Mhz. Here's a bcmstat output while switching systems rapidly and then entering a system:

This is with the default (Carbon) theme, default config.txt and a 1600x1200 resolution.

core freq and v3d freq are independent of each other on the RPi 4.

Use vcgencmd measure_clock v3d to monitor the issue.