What input lag reduction settings are you using on your Pi 4?
-
The Pi 4 is usually 100-150 % faster than the Pi 3 for CPU limited emulation scenarios. It won't allow for all input lag reducing settings at once, but will be a nice improvement over the Pi 3. A few things to check:
- Make sure that you're not using shaders or overlays.
- Make sure your resolution is no higher than 1080p (don't use 4K).
- Don't start out with any frame delay. This should usually be the last setting to tweak.
- Also, critical when setting max swapchain images to 2: You must go into the runcommand editor and set CPU governor to "performance". Otherwise, you will get framerate issues.
In my quite limited testing using lr-snes9x2010 (i.e. an older SNES emulator), the Pi 4 handles:
- video_threaded = false
- video_max_swapchain_images = 2
- video_frame_delay = 6
This seems to work fine even in the most demanding SNES titles (such as the title screen of Yoshi's Island). The Pi 3B+ could not do this even with frame delay set to 0. I believe I could use one frame of run-ahead if I removed the frame delay, which will in fact provide more of a latency reduction.
Finally, please note that:
- Hard GPU sync setting has no effect in RetroPie
- Max swapchain images set to less than 2 makes no difference (at least not with the OpenGL driver)
-
@scoularis For most older consoles, setting things to 4:3 aspect ratio and 480p resolution typically takes care of it for me.
-
@themazingness said in What input lag reduction settings are you using on your Pi 4?:
@scoularis For most older consoles, setting things to 4:3 aspect ratio and 480p resolution typically takes care of it for me.
You mean it improves input lag? Aspect ratio should make no difference, and setting 480p resolution would probably result in worse input lag on most modern TVs (due to internal upscaling).
EDIT: Sorry, I guess you mean it gives you a performance uplift. There may be a slight positive effect due to the lowered bandwidth requirements for the smaller framebuffer, but as I stated above it's probably counter productive since it may increase input lag (extra delay in the display).
-
@scoularis said in What input lag reduction settings are you using on your Pi 4?:
I just got my Pi 4 the other day and did a clean install of Retropie 4.7.1 before moving all of my ROMs into the new Pi. I had upgraded from a Pi 3B in the hopes of being able to enjoy significant reduced input lag. I'd been reading everywhere online that the Pi 4 had the necessary overhead to allow for runahead, lower swapchain images, Hard GPU Sync, threaded video disabled, etc.
we can't legislate for "everywhere online" but the official documentation is clear that such tweaks are 'unsupported'
People were making it sound like these settings were viable across the board for anything up to the GBA. Well, in my experience that is far from true.
again the official docs don't imply that: https://retropie.org.uk/docs/Input-Lag/#raspberry-pi-4 - some headroom. there's no guarantee and it's all experimentation.
I've been going down the rabbit hole of trying to find a nice, safe configuration that can be applied to most of my retro 2D cores and FBNeo to get the input lag down to a minimum without having to worry about performance issues for most games.
the only 'safe' configuration is the defaults.
In my case I had to leave everything at default except for disabling threaded video and enabling one frame of runahead for all of my cores aside from Genesis. For some reason Runahead being enabled on Genesis caused a bunch of games that I tested to jump around, screen tear, and drop frames. I have no idea why since Genesis emulation on the Pi 4 should have tons of available headroom.
not at all. the default emulator (lr-genesis-plus-gx) is quite demanding on system bandwidth. a pi3 will lose frames at default settings with a light shader on. if you swap to lr-picodrive, you may have more headroom.
I'm frankly exhausted from trying to get input lag down without causes weird hitches and screen tearing in these main cores. So I'm looking to all of you to share your findings on this matter. What settings did you tweek to achieve the lowest input lag possible without hurting performance? So far I'm pretty disappointed in the Pi 4 in this regard. Some posts I've seen on Reddit make it sound like the Pi 4 can handle swapchain set to 1 with Hard GPU Sync AND Runahead, but in my experience that's far from the truth.
i recommend avoiding reddit for retropie matters. it's full of misinformation. in fact, avoid everywhere but here and the docs :)
before you go down the unsupported tweaks route, ensure all the fundamentals are in place as per https://retropie.org.uk/docs/Input-Lag/
-
@themazingness said in What input lag reduction settings are you using on your Pi 4?:
@scoularis For most older consoles, setting things to 4:3 aspect ratio and 480p resolution typically takes care of it for me.
only if you were somehow losing frames at the default resolution, which would be troubling on a pi4 and 2d consoles, and imply some general issue with your setup.
-
Just the two I was hoping to hear from. Thanks for your input.
So, I do use the Z-fast CRT shader across all of my retro 2D cores (and FBNeo as well). I always have across all of my previous Pi's and never noticed any performance reduction in any normal gameplay scenarios over many years. Using a shader like this is important to me, so I keep that in place and try to make input lag adjustments around it.
I'm also outputting at 1080p, performance governor, and not using any frame delay.
I think the point about not trusting Reddit is where I went wrong. The claims some people on there were making about the results they were getting with virtually every input lag reduction setting cranked up to 11 simply must be false. From my testing there's just no way. As I said plenty of Genesis games running on the lr-genesis-plus-gx core couldn't even handle one frame of runahead with 3 swapchain images. It was the only retro console for which I had to disable runahead altogether.
Since I know that video threading comes into play when using shaders I tried most of these tweaks with it left ON, but honestly I'm getting better results with swapchain 3, video threading OFF, and one frame of runahead than any other combination I tried throughout yesterday. To me it seems that swapchain 2 with a shader enabled is just too unreliable when it comes to performance on the Pi 4, even with performance governor enabled.
Do shaders play a significant role when it comes to the viability of max swapchain images being set to 2?
Also, are the new KMS drivers for the Pi 4 still relatively unoptimized? I ask because performance in general sometimes feels less consistent than it was on the Pi 3B. For example, the EmulationStation frontend seems to be dropping down to 30fps quite often when scrolling through consoles.
-
@scoularis said in What input lag reduction settings are you using on your Pi 4?:
Do shaders play a significant role when it comes to the viability of max swapchain images being set to 2?
it would make sense. both tax system bandwidth.
Also, are the new KMS drivers for the Pi 4 still relatively unoptimized? I ask because performance in general sometimes feels less consistent than it was on the Pi 3B. For example, the EmulationStation frontend seems to be dropping down to 30fps quite often when scrolling through consoles.
please see https://github.com/raspberrypi/linux/issues/3935 - you could try the settings suggested here: https://github.com/raspberrypi/linux/issues/3935#issuecomment-717870449
-
I've been doing similar, and I've started using a camera phone to video the effect of each change to validate if it actually has any effect - I'm not sure if video_max_swapchain_images always does have any effect, or only sometimes.
[Edit: There is not expected to be any effect reducing this to 1, 2 is as low as it can go - https://retropie.org.uk/docs/Input-Lag/]I have just done a quick test on a Pi 4 using the crt_pi shader (except for asteroids, with no scan lines shader because it's a vector game).
For lr_fbneo with asteroids:
- runahead stops it working (stuttery sound, video doesn't update)
I assume that each of these removed 1 frame of latency (I've not measured these):
- video_threaded = false
- video_max_swapchain_images = 2
For lr_fbneo with bubble bobble these each remove 1 frame of latency so 3 frames all together:
- enable runahead, 1 frame, second instance mode
- video_max_swapchain_images = 2
- threaded_video = false
For lr_genesis_plus_gx with Gunstar heroes (measured 3 frames reduced latency on this one):
- enable runahead, 1 frames, second instance mode
- video_max_swapchain_images = 2
- threaded_video = false
[edit: there's only 1 frame of internal latency to remove with runahead in this game]
[edit: I also need to turn off my shader with these settings, whether I used the crt-pi or z_standard_crt shader]
For lr_snex9x with Mario Kart (latency effects not measured, 3 frames assumed removed)
- enable runahead, 2 frames, second instance mode
- video_max_swapchain_images = 2
- threaded_video = true
I needed to keep threaded video enabled for this one.
I usually try to reduce swapchains, enable runahead and then disable threaded video in that order, but bearing in mind that I can usually get at least two of those options working together.
The arcade roms I tested have only a single frame of internal latency to remove using runahead. The console games that I've measured usually have 2 frames, but other people here have reported 3 frames for some games.
My 4GB Raspberry Pi 4B has an Aluminium Armour heatsink/case, and is overclocked to 1.8GHz. If your Pi does not have a heatsink or other cooling it will slow down to keep itself cool.
I've installed the 5.10 test kernel and am running the pure KMS DRM video driver, but I don't know if that makes any difference.
-
I'm using the Canakit case with fan + heatsinks installed and an overclock to 1.75Ghz.
But I'm surprised by your lr-genesis-plus-gx results. For me if I used swapchain = 2 in conjuction with runahead, even with threaded video still left enabled, I'd get severe hitching in several games that I tried. Alien Soldier and Disney's Aladdin being the two that I tested that made it clear to me that I just had to leave runahead and swapchain at 3 for that core. Video threaded being disabled seems to be fine with those settings though.
You mention the 5.10 test kernel and pure KMS video driver. Are those something you'd recommend at this time? Are the performance gains worth possible instability, and if so how do I go about trying them out?
-
@scoularis said in What input lag reduction settings are you using on your Pi 4?:
You mention the 5.10 test kernel and pure KMS video driver. Are those something you'd recommend at this time? Are the performance gains worth possible instability, and if so how do I go about trying them out?
Kernel 5.10rc7 has been stable for me - I use Emulation Station and Raspberry Pi Desktop with a browser and YouTube.
The problem you might notice is that some older APIs are not supported any more, so apps need to be rewritten to support the new APIs. For example (I think) Kodi relies on some OMX features for video coding that aren't supported any more.
As long as you have time and a spare SD card it's safe to test. Some previous 5.10-rc kernels did have a problem when the Pi was booted from USB I think, but my simple setup didn't hit that.
-
Yeah, I think I've settled on some good enough latency with these settings to just leave things as they are:
Video Threading OFF
Max Swapchain = 3
One frame of Runahead enabled (with some per-game exceptions for FBNeo)And this is with the zfast crt shader applied across the board.
These settings give me input lag that feels very close to playing these systems on a CRT. If I push some of them to two frames of runahead it feels even more responsive than original hardware, but since I don't feel like managing that on a per-game basis I just left it at one frame globally.
Hopefully this post will help someone out there save some time. Trust me, if you're using shaders it's not worth even trying to use max swapchain = 2 in conjunction with Runahead or other input latency-related settings. You're gonna run into inconsistent performance across a wide variety of games with the default emulators.
-
@scoularis said in What input lag reduction settings are you using on your Pi 4?:
@busywait
But I'm surprised by your lr-genesis-plus-gx results.You are right:
I couldn't reproduce my test of Gunstar Heroes running smoothly in lr_genesis_plus_gx with runahead on, threaded video disabled and max swapchains = 1.I can do max swapchains = 1 plus runahead of 1 with second instance if I leave threaded video enabled, so most likely I was confused about the actual settings I used together, or I didn't do any playthrough to check that it was still smooth.
-
@scoularis said in What input lag reduction settings are you using on your Pi 4?:
For me if I used swapchain = 2 in conjuction with runahead, even with threaded video still left enabled, I'd get severe hitching in several games that I tried. Alien Soldier and Disney's Aladdin being the two that I tested that made it clear to me that I just had to leave runahead and swapchain at 3 for that core. Video threaded being disabled seems to be fine with those settings though.
Disney's Aladdin is an interesting rom (and nice to play :) ) - there seem to be 4 frames of internal latency in the game [edit: no, there is only 1], so the lowest latency working configuration that I had was to set threaded video on (the default), swapchains at 3 (the default), and use 4 frames of runahead (which I tested in single instance mode/second instance = no)
[Edit: It plays OK with 4 frames removed, but when I stepped through a frame at a time I can see that removes 3 frames of animation after the button press]That's with a shader running (I'm trying zfast_crt_standard.glslp - thanks for the suggestion)
I haven't found any situation on a Pi4 where zfast_lcd_standard.glslp allows me to run anything that crt-pi didn't yet.
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.