New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Pi 4] Intermittent 30 FPS in RetroPie (EmulationStation) due to low V3D frequency #3935
Comments
The way the the arm side 3d driver works is there are a queue of jobs, and whenever the queue becomes non-empty it requests a boosted v3d frequency. Whenever the queue becomes empty if removes that request. It depends on workload whether the clock is continuously high, or oscillating every frame. It's not clear if this is an actual bug, or just how the system is designed. I would expect "force_turbo=1" in config.txt to avoid this issue. Note:
is sufficient to choose the performance governor. The core share a common clock so don't need to be set individually. |
Yeah, the dynamics of this are not obvious. It would be interesting if someone deeply familiar with the V3D could analyze the behavior.
Yes, v3d_freq_min=500 does "fix" the issue. Most probably force_turbo=1 as well. It would of course be nice if clocks/settings could be left at default, though.
Got it, thanks! |
Although this is the launcher so it's less ideal - it would be nice for the system to be able to downclock as much as possible if idle on the menu - we have a config to switch to performance when launching games but would prefer not to have to do a workaround for the menu. |
Just got a similar frame rate issue in EmulationStation, despite using v3d_freq_min=500 (which otherwise has worked well as a workaround). Running kernel 5.9.2 (64-bit) and Mesa 20.3-devel. Started EmulationStation from the command line and immediately noticed low performance. FPS hovered around 30-something up to 47 FPS, so not locked at 30 FPS as previously. I confirmed the V3D frequency was running at 500 MHz at the time. Unfortunately, at this point I have no idea how to reproduce this particular issue. |
I was just able to recreate the issue described in my previous comment. I can't know for sure if it's related to the initially reported issue or not, but I'll mention it here just in case: The issue of constantly fluctuating FPS, mostly between approximately 35 and 55 FPS is triggered when going from the default "ondemand" scheduler to "performance" and then back to "ondemand". Running EmulationStation, while issuing the following two commands will immediately trigger the low FPS on my setup: echo performance | sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor Just issuing the second command, i.e. skipping first going to "performance", does not activate the issue. Once the issue is active, going back to the "performance" governor will bring FPS back to 60. Below is a screenshot of bcmstat running before and after the issue occurs. Notice how the CPU frequency is stable at 800 MHz before the issue occurs, but fluctuates between 600-1300 MHz after issue manifests itself. For these tests, I'm running kernel 5.9.2 (64-bit) and Mesa 20.3-devel. |
How old is your firmware ( |
Oct 31 2020 13:45:56 |
@pelwell @popcornmix @6by9 Typical behavior I've noticed is that on initial startup of EmulationStation the FPS will be at 60 FPS, it will stay there for about 5-10 seconds and then dip down to 30 FPS and stay there. However, unplugging a USB gamepad, in my case a SN30 Pro+, and replugging back in will make the FPS jump back up to 60 FPS and it will stay there. Navigating the various menus can trigger the drop in FPS, especially when a video is played which is using VLC. The drop in FPS is directly triggered by a drop in either ARM frequency or GPU frequency. |
I would guess that that act of plugging in a new USB device is enough to tickle the governor (which must be on-demand) to jump into turbo mode for a while. Have you tried putting |
The real question at hand is if there anyway possible to get the best of both worlds in terms of conserving resources but also getting the framerate to be steady. As I mentioned before, just unplugging a usb gamepad is enough to keep the frequency for the GPU steady at 500 Mhz. Is there any C++ code that can be used to trigger the frequency changes other than just the governor? i.e. anything that can implemented that keeps the GPU/ARM locked at its operating frequency and then downclock when the user or the program just sits idle? |
You could try manually switching the Linux cpu freq governor between performance, on demand and, powersave. It’s just a sysfs file and can be done via a shell script. |
Hi, what’s the consensus? I’m dealing with the issue on my RPi4 as well. I’m editing config.txt, but I don’t know where to add the required lines. Can you help please? |
The advice is to change the governor during runtime by writing to the sysfs file - |
so is the fundamental issue that the governor adjusts frequencies of the v3d component based on ARM load, rather than load of the v3d component? so in instances where there is high GPU demand but low CPU demand, the GPU will be downclocked incorrectly? i am curious if this is a similar issue to raspberrypi/firmware#1543 it seems to me that the cpu governor should have no effect on gpu components. |
The v3d driver also requests a boosted clock when it has work to do: linux/drivers/gpu/drm/v3d/v3d_gem.c Line 43 in ec967eb
If either the arm is busy or the v3d driver has work to do the v3d clock is increased. |
An update from my personal tests with the application Emulation Station: If the GPU or the CPU clock down, the framerate drops to 30 FPS. The sweet spot for the GPU seems to be right at 400 MHz. IIRC, the CPU range is somewhere between 800-900 MHz so what @Brunnis posted earlier is fairly accurate if you are looking at an output of Either one hitting below those thresholds and the FPS drops to 30. All things considered, I think this seems to be a combination of issues:
|
Describe the bug
The issue is that EmulationStation on RetroPie intermittently runs at 30 FPS instead of the expected 60 FPS when running on a Pi 4. EmulationStation is the launcher/menu system used by RetroPie. This is a long-standing issue and I'm not sure it has ever worked correctly, since RetroPie implemented KMS support and released the first images supporting the Pi 4.
It has been observed that the V3D frequency is below 500 MHz when the issue occurs. Seemingly randomly, the V3D will clock itself up to 500 MHz and EmulationStation will run at 60 FPS.
To reproduce
I have used a 1080p TV for my testing. I can't guarantee the same results with other resolutions.
Use the SD card image from here (4GB): https://www.dropbox.com/s/7ekdwlluk7xp8ju/retropie-test-oct-27.img?dl=0
While doing the testing above, it's interesting to log in to the system via SSH and run bcmstat to observe the V3D frequency. Use the following command (from the pi user's home directory):
./bcmstat.sh xgpd1 -o+V3D
While the 30 FPS issue is present, the V3D frequency is below 500 MHz. Try switching between the "ondemand" and "performance" CPU governors. Using the "performance" governor makes the performance immediately jump up to 60 FPS again:
Expected behaviour
The Pi 4 should keep the V3D at 500 MHz if that's what's necessary in order to keep the performance at 60 FPS.
Actual behaviour
The Pi 4 downclocks the V3D below 500 MHz and the performance dips below 60 FPS.
System
raspinfo output: https://pastebin.com/0VNRp5vb
Additional context
The text was updated successfully, but these errors were encountered: