Retroarch 1.6.9 update slowing emulations down?
-
@darksavior said in Retroarch 1.6.9 update slowing emulations down?:
@slimy As I already told @AndersHP, we are getting nowhere in troubleshooting this...
As I stated, I'm no coder. But I provided a list above, hopefully this could help? Otherwise, please tell me what to look for.
the easiest way is to try a clean install. Also, try building the emulators from source to see if that makes a difference.
I will try rebuilding from source and then ultimately a clean install.
This is great and all, but as all my scraped art is on the SD, this process will take me many days to recover from, and will tell nothing about what happened.@Darksavior when you say Filezilla via Ethernet, do you mean connecting my pi to my router or Ethernet between pi and computer? Have you tried writing to EXT4 with either Paragon (Windows) or Fuse (Mac)?
-
@andershp i suspect it's your lag reducing settings: https://retropie.org.uk/forum/topic/13263/input-lag-guide/7
retroarch updates may have changed how they affect things, who knows. if you've been changing that sort of stuff then all bets are off.
-
@andershp You can make a backup of your whole Image with win32diskimager too if you don’t want to manually backup with transferring by FileZilla.
-
@dankcushions said in Retroarch 1.6.9 update slowing emulations down?:
@andershp i suspect it's your lag reducing settings: https://retropie.org.uk/forum/topic/13263/input-lag-guide/7
retroarch updates may have changed how they affect things, who knows. if you've been changing that sort of stuff then all bets are off.
You, sir, just saved me from a ton of work! Thank you!
@Slimy have you tried deleting your retroarch.cfg file in opt/retropie/configs/all and then reinstall Retroarch from the Retropie setup menu?I just did this, and then transferred only my changes regarding controls, to the newly generated retroarch.cfg file, and it helped in every one of the games with issues!
-
Can any folks who are experiencing slowdown with the new RetroArch 1.6.9 let me know their video_max_swapchain_images setting? If you check via the interface, it's the "Max swapchain images" in the Video menu.
The Broadcom vendor driver was not respecting a swapchain value of 2 or lower until support was added in RetroArch 1.6.9. Now it works, and a lower value does decrease input latency, but it also increases the GPU rendering strain. It's likely a good setting for 8-bit era emulators, but will cause strain for more CPU/GPU intensive emulators...
-
@psyke83 Yes. My old retroarch.cfg file had video_max_swapchain_images set to 2, and now I'm running it at 3. I don't know if this was the entire solution for me though, I can see there's many new lines in the new file.
-
Thanks. So the "solution" is to use the default swapchain of 3 for the intensive systems such as SNES. Guides that advocated using a swapchain of 2 were technically correct, but it never made any difference until now.
You could try tweaking other settings (e.g. enable threaded video rendering) to see if the stutter can be improved with a swapchain of 2, but I'm uncertain if that will put you in a better or worse situation when it comes to input latency.
-
@gamez-fan How do I get the optimized Batrider experience? I tried the 0.78 rom and lr-fbalpha, but this game generally ran much better on my old setup in 1.6.7 (with video frame delay 5 and video threaded set to false) in either case.
But should I update lr-MAME2003 from source before I get these optimizations?
-
@psyke83
Yes, this solved the problem, but had other video settings added, (see post above) - don't know if these added to the problem also. -
@andershp said in Retroarch 1.6.9 update slowing emulations down?:
@gamez-fan How do I get the optimized Batrider experience? I tried the 0.78 rom and lr-fbalpha, but this game generally ran much better on my old setup in 1.6.7 (with video frame delay 5 and video threaded set to false) in either case.
But should I update lr-MAME2003 from source before I get these optimizations?
Sure grab the the latest source and give the game a whirl i hear it does perform a bit better now.
-
@psyke83 said in Retroarch 1.6.9 update slowing emulations down?:
Thanks. So the "solution" is to use the default swapchain of 3 for the intensive systems such as SNES. Guides that advocated using a swapchain of 2 were technically correct, but it never made any difference until now.
You could try tweaking other settings (e.g. threaded video rendering) to see if the stutter can be improved with a swapchain of 2, but I'm uncertain if that will put you in a better or worse situation when it comes to input latency.
latency and stutter are two different things. these aggressive latency tweaks can only cause or increase stutter (frame drops) at the possible improvement in input latency. i cover them all here: https://github.com/RetroPie/RetroPie-Setup/wiki/Input-Lag
not that it appears it has dissuaded anyone from using these tweaks :/
-
@dankcushions said in Retroarch 1.6.9 update slowing emulations down?:
@psyke83 said in Retroarch 1.6.9 update slowing emulations down?:
Thanks. So the "solution" is to use the default swapchain of 3 for the intensive systems such as SNES. Guides that advocated using a swapchain of 2 were technically correct, but it never made any difference until now.
You could try tweaking other settings (e.g. threaded video rendering) to see if the stutter can be improved with a swapchain of 2, but I'm uncertain if that will put you in a better or worse situation when it comes to input latency.
latency and stutter are two different things. these aggressive latency tweaks can only cause or increase stutter (frame drops) at the possible improvement in input latency. i cover them all here: https://github.com/RetroPie/RetroPie-Setup/wiki/Input-Lag
not that it appears it has dissuaded anyone from using these tweaks :/
In an ideal world, reducing the swapchain count can theoretically work without introducing stutter. The problem is that the Pi is a low power device and many of the emulators are approaching the CPU/GPU limits.
My suggestion to enable threaded video with a swapchain of 2 is worth checking, since the Pi is quad core, but most emulators' logic runs on a single core. That may eliminate stuttering caused by a lower swapchain setting, but threaded video also increases latency, so the question becomes whether you will get a net benefit of reduced latency vs. a swapchain of 3 and threaded video disabled.
-
@psyke83 i see what you mean, but you should be clear that you mean to turn threaded_video on as typically they're all turning it off (on is the default in retropie). i actually have started making a little automated test suite which could be used to finally dial in what can and can't be handled by a pi: https://github.com/dankcushions/retropie-auto-testing (it's super not finished now), but it would still need a brunnis-style input lag test to see if there's actual benefits in such situations.
-
OK, I edited my post to make it clearer. I was replying to @AndersHP with the assumption that he/she applied all tweaks on the "Input Lag" page (including threaded video set to disabled), so I thought it would be obvious.
-
@andershp I knew it was a config problem. Try the same method for any other emulators causing slowdowns after updating to 1.6.9
-
@darksavior I did and it seems like it worked. My go-to point for latency testing has always been Batrider though, and this surely plays slower (=input laggier) than it did before. But I have not tried updating MAME2003 from source, will do this soon.
Maybe Batrider is generally just a game that's on the limit of the pi.. I tested a bunch of shooters and fighters yesterday and they all seem fine now.
-
@andershp Since batrider runs flawlessly for me, i'd say you still have a config problem. Retropie is already optimized for input lag so anything you modify you're on your own..
As I already said, fba is best with batrider. With the mame2003 binary I got like a .3 fps drop at best, with source like .2-.1 drop in areas where there's a lot happening. If I didn't have the fps counter on then I wouldn't notice.
-
@darksavior How sensitive are you personally to input lag? Because I'm not sure any of my friends would notice. I'm not talking about framerate drops for Batrider after I reset the cfg, but just input lag - this felt better in Retroarch 1.6.7 with threaded video = false and video_frame_delay = 5 , close to no input lag, and with 1.6.9 and no lag reducing settings I would say it feels like 200-300 msecs (no scientific investigation done, just a feeling), and WAY more than e.g. Dodonpachi or Fangun Feveron.
Tested Batrider with both fba and MAME2003 (binary), actually the latter ran better, but that could just be me. I did nothing to reduce input lag in the new cfg file and I do not run emulator-specific cfg files. Both FBA emulator and rom is 0.2.97.42.
Is there any other than the opt/retropie/configs/all/retroarch.cfg that needs resetting...?
-
@andershp said in Retroarch 1.6.9 update slowing emulations down?:
@darksavior How sensitive are you personally to input lag? Because I'm not sure any of my friends would notice.
I don't think I'm very sensitive to input lag. I've adjusted nothing but the tv's game mode (26ms according to rtings), because I did notice input lag without it. I can play mario and other platformers just fine. My tv's pc mode's (44ms) input lag seems fine for pc and console gaming but I really notice it on retropie.
Is there any other than the opt/retropie/configs/all/retroarch.cfg that needs resetting...?
I believe that's all you need to do. As I said, I just uninstall the emulator to empty the folder, then reinstall.
The sensitive people tend to swear by the dispmanx driver, but I don't believe it's supported anymore. I tested it against mike tyson himself, and I didn't notice a difference. I can't use shaders so that's a deal breaker. Maybe the input lag can improve whenever retropie is updated to stretch.
-
@andershp
Deleting the cfg files then reinstalling, (in my case, that included emulator-specific cfg files,) did the trick. You've bailed me out of having to redo everything, thanks.
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.