They all have it or didn’t have that issue.
Snes9x2010 = Snes9x Next Snes9x2005 = CAT SFC Snes9x2002 = Pocket Snes
older = faster = less compatible
[QUOTE=Tatsuya79;49322]They all have it or didn’t have that issue.
Snes9x2010 = Snes9x Next Snes9x2005 = CAT SFC Snes9x2002 = Pocket Snes
older = faster = less compatible[/QUOTE] Are you sure? Out of the snes9x based cores, I have only reviewed and fixed snes9x and snes9x2010. But maybe someone else looked into the others?
I thought you said they were OK but I’m probably mixing it up with the NES cores, my bad.
Heh, that’s really promising ! 2 fewer frames of lag on the Pi, on par with a regular PC then ! Games will be definitely more playable.
Is there really no way to add scanlines (overlays) in dispmanx mode ?
Awesome improvements, thanks !
For those of you that want to try video_max_swapchain_images = 2 on the Raspberry Pi with DispManX: I have noticed that there’s a big difference in smoothness when using force_turbo=1 in /boot/config.txt. With the default setting of 0, the Raspberry Pi will downclock itself to 600 MHz whenever it feels the processor load is low. With video_max_swapchain_images = 2, the Pi evidently decides to downclock itself periodically, which causes major hiccups. Even Super Mario World, which is pretty easy to run, had obvious performance issues while playing just half of the first level.
The good news is that setting force_turbo=1 seems to have solved those issues quite effectively. I played through a couple of levels of SMW and SMW2 and didn’t notice any issues. The intro and menu in SMW2 are slow, though, but those are quite demanding. force_turbo=1 pins the Raspberry Pi’s CPU to its maximum frequency at all times (1.2 GHz). There are rumors that this can void the warranty of the Pi, but that’s not true. It’s only when this setting is used in conjunction with overclocking that you may void your warranty.
I will update the settings guide a few pages back with the info about the force_turbo setting.
[QUOTE=bidinou;49366]Heh, that’s really promising ! 2 fewer frames of lag on the Pi, on par with a regular PC then ! Games will be definitely more playable.
Is there really no way to add scanlines (overlays) in dispmanx mode ?
Awesome improvements, thanks ![/QUOTE] You’re welcome! Regarding scanlines and such using DispManX: Not possible, as far as I know.
Brunnis, I’m re-reading your post from page 36 and you recommend Linux w/KMS as the best for low latency, but the first post in this thread suggests that Windows 10 has the lowest latency.
Has any of this changed?
[QUOTE=sofakng;49377]Brunnis, I’m re-reading your post from page 36 and you recommend Linux w/KMS as the best for low latency, but the first post in this thread suggests that Windows 10 has the lowest latency.
Has any of this changed?[/QUOTE] Yes, before the video_max_swapchain_images setting was introduced, I could never get Linux to match Windows with GPU hard sync. Thanks to user larskj (see this GitHub issue: https://github.com/libretro/RetroArch/issues/3100) the possibility of disabling triple buffering was added to RetroArch’s OpenGL driver. To be honest, though, this puts Linux and Windows at equal footing. I have removed that comment regarding preferring Linux DRM/KMS, because it was more based on a hunch than scientific knowledge. While I did see a regression in terms of input lag when updating my Radeon driver on Windows 10, the same could just as well happen on Linux. It seems both OSs are pretty much equal in terms of input lag and it’s all down to how your particular GPU driver behaves.
Yes this is great progress, Linux users like me won’t have to make a compromise or dual boot.
Btw is a Nuc fast enough for libretro-reicast ? Sorry for this offtopic, just assessing the raspberry vs the nuc which is always considered for libretro ! Anyway I’ll get back to you and give results… Getting an i5/iris 540 NUC for this purpose. I’ll set what shaders run properly.
I know that using a shader to display scanlines is not possible with dispmanx driver, but would it be possible to use a scanline overlay as a workaround ?
[QUOTE=Brunnis;49375]For those of you that want to try video_max_swapchain_images = 2 on the Raspberry Pi with DispManX: I have noticed that there’s a big difference in smoothness when using force_turbo=1 in /boot/config.txt. With the default setting of 0, the Raspberry Pi will downclock itself to 600 MHz whenever it feels the processor load is low. With video_max_swapchain_images = 2, the Pi evidently decides to downclock itself periodically, which causes major hiccups. Even Super Mario World, which is pretty easy to run, had obvious performance issues while playing just half of the first level.
The good news is that setting force_turbo=1 seems to have solved those issues quite effectively. I played through a couple of levels of SMW and SMW2 and didn’t notice any issues. The intro and menu in SMW2 are slow, though, but those are quite demanding. force_turbo=1 pins the Raspberry Pi’s CPU to its maximum frequency at all times (1.2 GHz). There are rumors that this can void the warranty of the Pi, but that’s not true. It’s only when this setting is used in conjunction with overclocking that you may void your warranty.
I will update the settings guide a few pages back with the info about the force_turbo setting. [/QUOTE] FYI i think the same result can be used at runtime by setting the CPU governor to ‘performance’. retropie can be configured to do this via its ‘runcommand’ bash script: https://github.com/retropie/retropie-setup/wiki/runcommand#configuring-runcommand
this would turn ‘turbo’ on for only the duration of a game being ran, rather than for the whole time your pi is booted. perhaps something similar could be integrated into retroarch. there are probably analogous CPU/GPU governors on other operating systems/hardware that could be bundled together under the same config option.
May be an issue for the Pi 3, though, as it tends to dispel way more heat than the previous Pi. Running it constantly at a higher clock rate probably requires heatsinks or even a fan ?
the pi would still throttle itself if it hit thermal (or voltage) limits, AFAIK. this just stops it downclocking if it’s idle (or at least, thinks it is).
I think it needs a water-cooler (that would be 3 times its price lol).
I’ve run some more tests with the “dispmanx” video driver and video_max_swapchain_images = 2 using snes9x2010. It works quite well, but there are some issues. Although video looks smooth, there are some audio glitches here and there. It’s pretty obvious in Star Fox. Probably not much to do about it, but let me know if you have any ideas.
Maybe, but someone else will have to answer that, since I don’t know enough about it.
[QUOTE=dankcushions;49439]FYI i think the same result can be used at runtime by setting the CPU governor to ‘performance’. retropie can be configured to do this via its ‘runcommand’ bash script: https://github.com/retropie/retropie-setup/wiki/runcommand#configuring-runcommand
this would turn ‘turbo’ on for only the duration of a game being ran, rather than for the whole time your pi is booted. perhaps something similar could be integrated into retroarch. there are probably analogous CPU/GPU governors on other operating systems/hardware that could be bundled together under the same config option.[/QUOTE] Wow, I had no idea about that! And you’re right, using the performance governor is the same as setting force_turbo=1, so that solution is perfect.
Yeah, force_turbo does not push the Pi out of spec. It just makes sure it actually keeps itself at max clock and not fool itself to lower the clocks. Heat shouldn’t be a problem in this case, since the core’s actually have to be used to really heat up. Since emulators are generally single threaded, three of the cores will be mostly idle.
I believed I had played around with the audio_latency setting and tried to get rid of the audio issues that way, but apparently I didn’t test it well enough. I tried again, setting audio_latency to 96 instead of the default 64 (milliseconds). This seems to have solved most issues with Star Fox, which was the worst offender. So, it seems we may have to add some audio lag to get less input lag… I didn’t notice any delay with the added audio latency during a few quick tests, though, so it seems like a fair trade-off.
Also, I removed force_turbo=1 from my boot/config.txt and followed dankcushion’s advice to modify RetroPie’s runcommand instead. Seems to work great!
You’re mileage will vary of course, depending on what cores/games you run. I only run NES/SNES games and hopefully my testing can at least give you some idea of what to expect. I’ll test this setup by actually playing games over the coming days to see how it works out.
I am also for root enabled features in retroarch.(On rooted android too)
Set max clock speed. Set cpu governor. Set realtime priority. Read/write device files in /dev.
I have installed a fresh RetroPie 4.1 image on my Pi2 and edited the retroarch.cfg to this:
video_driver = "dispmanx"
video_vsync = true
video_threaded = false
video_max_swapchain_images = 2
video_frame_delay = 0
I also edited the runcommand to use Cpu in performance mode.
Is there something else to do to get less LAG?
Just out of curiosity, does anyone know how the new Nintendo NES Mini compares to a real NES regarding input lag ?
Also, there was definitely some lag detected when using it; It wasn’t bad and certainly much better then the Retron 5, but any hardcore gamer will notice right away.
[QUOTE=xadox;50737]I have installed a fresh RetroPie 4.1 image on my Pi2 and edited the retroarch.cfg to this:
video_driver = "dispmanx"
video_vsync = true
video_threaded = false
video_max_swapchain_images = 2
video_frame_delay = 0
I also edited the runcommand to use Cpu in performance mode.
Is there something else to do to get less LAG?[/QUOTE] That’s it! The only thing I don’t know is when the RetroArch executable in RetroPie 4.1 was built. I’d assume it is new enough to include the updated DispManX driver with support for the video_max_swapchain_images setting, but I don’t know for sure. I’d probably rebuild RetroArch from source to be sure.