Fixing Screen Tearing issues on RPI4
-
What resolution are you outputting?
What specific game+emulator combos are showing a problem?
Enable the on-screen FPS count in the emulator, that may narrow down the problem.
You really shouldn't see any problem with NES/SNES/pre-2000 arcade games, have you tried those? I would think PS1 games would work ok on the Pi4 but haven't tried them myself.
-
So, I'm running the pi at the default monitor resolution of my TV, which is 720p, so the games launch at 1280x720 @ 60hz, according to the pre-launch menu. The emulators I see tearing the most are in lr-snes9x and lr-pcsx-rearmed.
The thing is, the tearing will also happen on all of the other emulators too, it is just a matter of frequency and certain games seem to trigger it worse. Donkey Kong Country 3 on lr-snes9x teared a lot on certain stages, which I know the pi is not struggling to run that (at least I think)!
Thanks for the fps counter suggestion, I didn't think about looking into that.
This might be a really silly question, but I have the pi right now sitting on a paper note pad to keep it from falling off of my table. Can that cause some kind of video short to enable the tearing?
-
An interesting tidbit of information I have looked into was that the pi, while running games, had high cpu usage with systemd-journald (58%, more than retroarch!). It seems that there might be errors in the logs. I had a look at /var/log/syslog and had some error messages being placed there, also in dmesg:
This is happening many, many times per second. Could this be related? Is there something wrong with the wireless card?
EDIT: It is also only happening during gameplay in retroarch, not in emulationstation or sm64pc. Coincidentally, the tearing doesn't happen during sm64pc at all, even with fast movement. Maybe the kernel errors is spiking cpu with systemd-journald and is causing the video to be affected?
EDIT2: So, I discovered what was causing this systemd-journald error, it was a shader called snes_scnaline.glsp that I was using. I turned off the shader and even switched to pi-crt and systemd-journald stopped hogging so much cpu. The snes_* shaders seem to be causing this error, spiking journald. Still haven't figured out if this is causing the shaders. I will edit again if this is the case.
EDIT3: Just found out that the shaders are not causing the tearing, I can get them without shaders even on. That cpu spike with the snes_* shaders is definitely bug though!
-
@brandflake11 Screen tearing has been happening on the pi4 since day 1 on all emulators for me. My pi is fully updated, so I'm not using outdated kernels/drivers. My wifi and bt are disabled.
The new experimental kms driver supposedly fixes it but I haven't done enough testing. No idea if it would even work on a portable screen. -
@Darksavior Thanks for the response! Maybe I'll try the experimental driver and see if it works. Quick question if you know it, is the video driver just a debian package that I can go in and downgrade back to stable with something like synaptic? That way I could switch back to stable if needed.
-
@brandflake11 You may find the thread I started relevant: https://retropie.org.uk/forum/topic/27299/low-framerate-on-main-emulationstation-menu-pi-4/
I've also been encountering tearing issues as well as framerate drops, and a few users with more technical knowledge than me are trying to figure out the cause + any potential fixes.
-
@rilight Thanks, I took a look at it and may try some of the manual editing of config files. I really hope we get a tearless graphics experience on the pi4 soon, like the pi3 has!
I did install the experimental firmware, and can say that it tears much less, and much less intense. It still happens, but not as frequently or as badly, so that's a plus! I also haven't found too many bugs either, so that's good! It definitely helps with Crash Bandicoot and Kirby's Nightmare in Dreamland, which was another game that would tear here and there.
@rilight Did you find anything in particular from that thread helpful to get a tearless experience?
-
I tried the v3d min freq with no success just now. I also have tearing on games in NES and others. No shader on, just bezel overlay.
-
@brandflake11 said in Fixing Screen Tearing issues on RPI4:
@rilight Did you find anything in particular from that thread helpful to get a tearless experience?
Unfortunately I've been pretty busy recently, so I haven't had a chance to really mess around with the more recent suggestions. I did find that enabling the force_turbo option seemed to help, as well as forcing the resolution to 720p. I talked about the results of those tests in the thread, but other than that I haven't done anything else myself.
-
v3d_freq_min only addresses the low/30 fps framerate issue that happens within EmulationStation.
The screen tearing issue from this thread is a separate issue is appears.
With the kernel setting set to ondemand, the expected behavior of the gpu clock is to ramp up the frequency to the default and then downclock to 300 Mhz when not used to conserve resources.
Also RetroArch v.1.8.9 and above made a lot of changes to the graphics side of their drivers. Once RetroPie devs update the setup script to implement those changes it may be worth waiting to see if the screen tearing has been fixed in those versions.
-
Maybe I'll look into installing the newest version of retroarch from source to see if it helps. Thanks for the suggestion @bluestang!
-
@bluestang I'm using the retropie draft build script for 1.9.0 and there is no change with the screen tearing.
-
Well darn, there has to be something we can do. I guess we should just keep waiting for better firmware? For the meantime, maybe I can go back to my pi3, or just suck it up and enjoy the pi4 with tearing.
Has anyone tried turning on the compositor? Does that affect retroarch if you are not running a desktop environment?
-
For anyone looking for a solution to this, I have found this thread.
Enabling the kms driver (although a work in progress) has fixed all tearing I was having. The tearing is replaced with some stuttering in some games, but I am more than okay with this.
To enable, I went to /boot/config.txt and edited this part:
[pi4] # Enable DRM VC4 V3D driver on top of the dispmanx display stack #dtoverlay=vc4-fkms-v3d dtoverlay=vc4-kms-v3d-pi4,noaudio max_framebuffers=2 [all] #dtoverlay=vc4-fkms-v3d
Basically, comment out dtoverlay=vc4-fkms-v3d with a #, and then put in the the dtoverlay=vc4-kms-v3d-pi4,noaudio line. For my setup, I was getting a black screen until I added the ,noaudio part to it.
Also, under [all] comment out the other dtoverlay underneath it if it is not commented out.I hope this helps others!
-
@brandflake11 Thank you, this absolutely fixed the really weird screen tearing issues I was having even with NES games. Thank you so very much.
-
@zerojay You're welcome, I'm glad it helped you. I hope having a clear topic like this addressing this issue helps others as well.
-
@brandflake11
I applied your changes to the /boot/config.txt and it helped a lot.
But some tearing was still visible when many sprites and layers were active in some situations. (Aliens 3 / SNES)What helped for me was reducing the overclocking from 2250 to 1950.
Now I cannot reproduce the tearing any more. -
That is very interesting @hgill that overclocking would affect that. I don't use overclocking on my pi and so I don't get any screen tearing. But, that's good to hear to keep note of for others!
-
@brandflake11 said in Fixing Screen Tearing issues on RPI4:
vc4-kms-v3d-pi4
This solution works great in my case in terms of fixing the screen tearing issues - thanks a lot.
However, I noticed that after applying such settings, the hardware accelerated OMXPlayer no longer plays video inside EmulationStation (but the sound plays just fine), which is a deal breaker for me.
-
@huey Yeah, there are definitely compromises with the experimental driver. I found kodi and the pixel desktop don't work super well with the kms driver either. If you don't want to play n64 and Dreamcast, honestly the pi3 may have a better experience at the moment. Maybe we'll get a complete kms driver eventually that fixes everything!
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.