Good news regarding tearing and low EmulationStation performance on Pi 4
-
@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.
-
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?
-
@George-Spiggott You run one of
apt show libglapi-mesa dpkg -l | grep mesa -
@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.
-
@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.
-
@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.
-
@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.
-
@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.
-
@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.
-
@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.
-
@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
bcmstatoutput 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 0This is with the default (Carbon) theme, default
config.txtand a 1600x1200 resolution. -
@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
bcmstatoutput while switching systems rapidly and then entering a system:This is with the default (Carbon) theme, default
config.txtand a 1600x1200 resolution.corefreq andv3dfreq are independent of each other on the RPi 4.Use
vcgencmd measure_clock v3dto monitor the issue. -
@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.
-
@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.
-
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.
-
-
@SeraphisCain Amiberry uses the
dispmanxapi for display, so it won't work with the full KMS driver, regardless of the kernel version used. -
@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. -
@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,daphnejust to name a few). -
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.
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.