Good news regarding tearing and low EmulationStation performance on Pi 4
-
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.
-
@mitu said in Good news regarding tearing and low EmulationStation performance on Pi 4:
@SeraphisCain Amiberry uses the
dispmanxapi 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
dispmanxin 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. -
@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).
-
@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.
-
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.”
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.
-
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.
-
Oh sweet. Compiling the 5.10 kernel also installs its headers. My snes pads works :D
-
@mitu said in Good news regarding tearing and low EmulationStation performance on Pi 4:
@SeraphisCain Amiberry uses the
dispmanxapi 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.
-
-
I just created an issue for this at the Raspberry Pi github: https://github.com/raspberrypi/linux/issues/3935
-
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! -
@bluestang Hey, could you give me a quick tutorial for installing upstream SDL2 and MESA to test them out?
-
@bluestang said in Good news regarding tearing and low EmulationStation performance on Pi 4:
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?
-
@stoo said in Good news regarding tearing and low EmulationStation performance on Pi 4:
@bluestang Hey, could you give me a quick tutorial for installing upstream SDL2 and MESA to test them out?
Not a quick tutorial and it will break your current image. RetroPie will adopt these things when they are ready, and at this point SDL2 upstream is a constant WIP.
-
@brunnis regarding keeping up to date. It depends on whether we encounter issues with upstream. We will update when we are sure everything is ok and our rebased customisations work etc. Until recently sdl2 Kms driver had issues so we were waiting.
-
Anyone have any luck using the full KMS driver over composite? I've created a support topic regarding this, but perhaps someone here has had some luck with it?
-
@setiawan Not tried composite, but I've encountered similar issues where the full KMS driver isn't respecting some of the config.txt video options.
Right now, I'm having to choose between:
- Tearing issues, but supporting deep blacks via FKMS (hdmi_pixel_encoding=2)
- Fixed tearing, but limited-range blacks via KMS ('hdmi_pixel_encoding' is ignored, so all blacks are slightly grey, which doesn't look great on an OLED)
-
@philcsf Quite a bummer. It is a pre-release kernel I guess so I can only hope that these problems get sorted or clarified some time soon.
-
If you unplug your controller/joystick for about 3-5 secs and then replug it back in does the framerate jump back to 60 FPS again? Anytime the framerate dips to 30 FPS in the main menu if I unplug/replug my controller the framerate will go back to 60 FPS.
My Setup:
- RPi4 4GB, stock clock speeds.
- 64-bit RPiOS with RetroPie built from the setup script.
- Cosmic Rise theme (Hursty)
-- this theme seems to cause the 30 FPS anomaly fairly quickly. - I'm using emulationstation-dev.sh from the master RetroPie branch with the build flag
-DUSE_MESA_GLES=Oninstead of-DGL=Onin emulationstation.sh
-- this will link the GLESv2 driver vs GL one. - RetroPie's SDL v2.0.10
- Stock 19.3.2 MESA drivers
What has been true in all my testing is that the clock speeds of the ARM or GPU will influence the framerate, if either one dips below a certain threshold the framerate will be reduced. (seems obvious =] )
Thresholds to trigger 30 FPS:
GPU MHz < 450 Mhz
ARM MHz < 900 MhzWhat befuddles me is that the framerate is not affected when you go to the options menu or a game system w/ roms menu. Every time you are in those menus the framerate is 60 FPS.
-
So the latest update is supposed to fix this? I've updated everything but NES games like Metroid stil get me frustrated.
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.