Good news regarding tearing and low EmulationStation performance on Pi 4

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.

zerojay

@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.

No.

Brunnis

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

@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.

No.

The tearing issue is probably a separate issue. What video driver (fake KMS or KMS) and Linux kernel version are you running? So far I've not been able to reproduce any tearing issues with my test setup (i.e. kernel 5.9, full KMS and Mesa 20.3 (devel)), but I'm still testing.

EDIT: And, as mentioned by @dankcushions , since the tearing issue appears to be sporadic, it requires some extra testing to ascertain if it's been solved or not. I perform frequent restarts of each emulator when testing, along with quite short tests between each restart. I'm also doing some cold starts, in case there's an element of chance involved during HW initialization.

For people that have spent more time with the current 5.4 kernel and full KMS: Have you confirmed that the issue is still present with this configuration? My initial tests from back when I started this thread indicated that the tearing issue was solved. While, I subsequently found out that the EmulationStation 30FPS issue remained (or resurfaced), I don't remember ever seeing tearing with this configuration.

SeraphisCain

Tested 5.9 myself a couple days ago. A couple observations:

The micro-stuttering/jerkiness that I would frequently notice (especially in 2D games) when using the 5.4 KMS driver seems to be completely resolved now. This was my biggest barrier to using KMS, so I'm happy to see that it's no longer an issue.
This one's emulator-specific, but Amiberry seems to be completely broken when using KMS on 5.9. It boots to a black screen, and while there is audio, it's extremely slow/choppy. Reverting to FKMS resolves the issue completely.
The new Alsa driver causes frequent audio drop-outs in more demanding games/less optimized emulators (3DO, Jaguar, N64, CAVE games on MAME 2015/2016).

EDIT: I guess I hadn't noticed or hadn't tested Amiberry on 5.4 KMS, because I just did and it's also broken there as well, although in a different way compared to 5.9 KMS. On 5.4, the TV/monitor completely loses signal when Amiberry boots. Exiting the emulator brings the signal back. And once again, switching back to FKMS resolves the problem.

mitu

@SeraphisCain Amiberry uses the dispmanx api for display, so it won't work with the full KMS driver, regardless of the kernel version used.

SeraphisCain

@mitu Yeah, I discovered as much earlier today after searching around on Github a bit. Are there any other emulators in RetroPie that use dispmanx in the way Amiberry does? Thus far it's been the only one I've found that doesn't work with KMS.

mitu

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

Are there any other emulators in RetroPie that use dispmanx in the way Amiberry does? Thus far it's been the only one I've found that doesn't work with KMS.

Yes - dosbox, SDL1 based emulators that don't have SDL2 support (fuse, openbor, daphne just to name a few).

zerojay

And then there's also the problem of not being able to change the framebuffer, so you can't use tvservice nor use the resolution switching from runcommand.

Otherwise, I never saw screen tearing ever during my testing, but the drawbacks were too much in my opinion.

bluestang

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

@SeraphisCain Amiberry uses the dispmanx api for display, so it won't work with the full KMS driver, regardless of the kernel version used.

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

@mitu Yeah, I discovered as much earlier today after searching around on Github a bit. Are there any other emulators in RetroPie that use dispmanx in the way Amiberry does? Thus far it's been the only one I've found that doesn't work with KMS.

Is their wiki out of date?

https://github.com/midwan/amiberry/wiki/First-Installation

If you want to use Full KMS driver, then you should pick the SDL2 target instead.

mitu

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

Is their wiki out of date?

No, but SDL2 can use various video drivers and Amiberry supports both (KMS and Dispmanx).

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.

I am not able to get any tearing in emulators with this setup (i.e. Linux 5.9 64-bit, full KMS, Mesa 20.3-devel). I've tested with and without v3d_freq_min=500, with and without threaded video and with max swapchain images 2 and 3. No tearing observed in emulators.

During my testing, v3d_freq_min=500 has effectively cured the EmulationStation 30 FPS issue. The issue is very easy to reproduce once v3d_freq_min=500 is removed from config.txt.

Brunnis

This comment from Dom at Raspberry Pi serves as additional confirmation:

“The fkms driver does suffer from tearing. We are in the process of moving to the kms (fully arm side) driver which doesn't have this issue.”

https://www.raspberrypi.org/forums/viewtopic.php?p=1745410&sid=aa92eea8ecb7815b4496546f7a697857#p1745410

So it seems tearing will be history once the switch to full KMS is made. I will try to find some time to look into the 30 FPS issue, which appears to be completely separate.

Brunnis

I Just experimented a little:

Removed v3d_freq_min=500 from my config.txt.
Performed a cold reboot and started EmulationStation
Logged into the Pi using SSH from my PC and ran bcmstat to print clock frequency info (see https://github.com/MilhouseVH/bcmstat):

./bcmstat.sh xgpd1 -o+V3D

Started another SSH session and installed cpufrequtils:

sudo apt install cpufrequtils

Started scrolling left and right in EmulationStation. The 30 FPS was immediately present at all times. Then started changing between the "ondemand" and "performance" CPU governors:

for ((i=0;i<$(nproc);i++)); do sudo cpufreq-set -c $i -r -g performance; done
for ((i=0;i<$(nproc);i++)); do sudo cpufreq-set -c $i -r -g ondemand; done

With "performance", the CPU and V3D (GPU 3D core) frequencies are clocked up to 1500 and 500 MHz respectively. I changed between the governors while holding left or right on the D-pad to keep scrolling in EmulationStation. Every time the performance governor is set, the FPS immediately jumps up to 60 FPS. Every time the "ondemand" governor is set, the FPS goes back doen to 30 FPS.

Below is the output from bcmstat. At the bottom, where the V3D frequency jumps to 500 MHz is where I set the "performance" CPU governor and where the FPS jumps from 30 to 60 FPS.

This was pretty much expected, but I thought I'd detail the testing anyway if you want to experiment. The next step should be to prepare an image for the Raspberry Pi devs and supply these steps to them for reproducing and hopefully solving the issue.

Darksavior

Oh sweet. Compiling the 5.10 kernel also installs its headers. My snes pads works :D

Darksavior

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

@SeraphisCain Amiberry uses the dispmanx api for display, so it won't work with the full KMS driver, regardless of the kernel version used.

Semi offtopic, but is that why daphne gives me a black screen with the full kms driver? I can hear the audio.

mitu

@Darksavior https://retropie.org.uk/forum/topic/25370/good-news-regarding-tearing-and-low-emulationstation-performance-on-pi-4/125?_=1603777936887

Brunnis

I just created an issue for this at the Raspberry Pi github: https://github.com/raspberrypi/linux/issues/3935

bluestang

@brunnis @dankcushions

Give upstream SDL2 a whirl and fresh build of MESA too, it seems to improve if not fix the Pi4 30 FPS EmulationStation issue.
In a rom selection screen with video snaps, I am getting upwards of 120 fps!

stoo

@bluestang Hey, could you give me a quick tutorial for installing upstream SDL2 and MESA to test them out?

Brunnis

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

@brunnis @dankcushions

Give upstream SDL2 a whirl and fresh build of MESA too, it seems to improve if not fix the Pi4 30 FPS EmulationStation issue.
In a rom selection screen with video snaps, I am getting upwards of 120 fps!

That's quite an interesting change. No time to test at the moment, but looking forward to seeing more reports from people using it. By the way, how well does RetroPie keep up with upstream SDL2?