Dispmanx video driver stutter on SNES

silentq

So in the past I have noticed on the gl driver that input lag is a real problem when it comes to SNES. I have always just used the dispmanx video driver instead with SNES. Today though I started noticing a lot of stutter when it comes to this driver. Is there a better way to strike a balance between the two? Meaning is there a way to have as little input lag as possible but also have next to no video stutter? I know this may not be possible but I figured I would ask.

dankcushions

@silentq please provide all the info as per https://retropie.org.uk/forum/topic/3/read-this-first

pjft

@silentq I found significant input lag differences between different SNES emulators as well. Try a few different ones to see if it helps.

And, of course, please provide more info if you'd want to have hopes of a more useful answer :)

silentq

Pi Model or other hardware: Pi3
RetroPie Version Used: 4.2.1
Built From: Pre made SD Image on RetroPie website
USB Devices connected: PS3 Controller
Controller used: PS3
Emulator: snes9x2010
Retroarch Config File for SNES:
#Settings made here will only override settings in the global retroarch.cfg if placed above the #include line
input_remapping_directory = "/opt/retropie/configs/snes/"
video_driver = "dispmanx"
#include "/opt/retropie/configs/all/retroarch.cfg"

So all the SNES9x varients other than the one called just SNES9x seem to work but the same exact issue gl no stutter better graphics but input lag and with dispmanx worse graphics stutter but almost perfect in the input lag department. pisnes and armsnes seem to have just awful sound issues and not really any better in either department.

silentq

I just stumbled upon this within retroarchs git page:
https://github.com/libretro/RetroArch/issues/4782

Any way Retropie could possibly revert back to an old version of the driver?

pjft

Conceptually it could but it's likely but going to happen because it would negate all other improvements for everyone. Especially if nobody has tested it to confirm that it is indeed the case.

However, it should not prevent you from doing that yourself in your installation and testing it out.

Are you familiar-ish with git and comfortable with the command line interface? They detail the way to do it in the comments, to test.

pjft

@silentq so, a way for you to test that on your end is to edit the RetroArch install script in RetroPie Setup, and change the v1.5.0 version lock to the previous v1.4.1 (from February 2nd), which seems to predate the fix (February 12th).

The script in referring to should be editable via:

sudo nano ~/RetroPie-Setup/scriptmodules/emulators/retroarch.sh

Then you may try to reinstall RetroArch from the script and see if it helps.

I am unsure if it won't cause other problems with some of the patches RetroPie applies on RetroArch as well, though. It shouldn't, but bear that in mind.

Let us know how it goes!

silentq

Is this just as simple as the command line listed:

git clone https://github.com/libretro/RetroArch.git
cd RetroArch
git revert 0b75671

and then going into retropie setup and hitting build retroarch if so I could easily do that myself.

My concern is for future updates and the fact that it doesn't really solve the root of the problem that the driver is essentially broken. I will try this out tomorrow but if it does in fact fix it I would imagine something needs to be done with the Retroarch install since this seems to really wreak havoc on NES and SNES which in my opinion are two very upfront uses for Retropie/Retroarch in general.

pjft

@silentq check my second post, which apparently I was writing at the same time :)

For future updates if you update the RetroPie Setup scripts, you should be good to go!

silentq

Thanks @pjft I will indeed try your fix in the morning just to clarify after modifying the script will a the normal update instructions through Retropie setup reinstall Retroarch with the v1.4.1 assuming I modify retroarch.sh correctly?

pjft

@silentq that is the correct assumption. I'm sure you'll be able to verify by yourself if you check the version in one of the RetroArch menus (I don't know where, though!). Also, some emulators may already depend on newer RetroArch features, though it's unlikely.

You're just reverting the file to this version of it:

https://github.com/pjft/RetroPie-Setup/commit/6e3e5299c77797404434c979ed88f8a0c127b938

Albeit manually:)

silentq

Doing it right now already modified the script will let you know the results shortly.

silentq

Seems kind of better its a very subtle thing and its late at night as saw "some" stutter. I am unsure how to verify the version of the driver though. The menus don't seem to give me any indication of which build this is of the driver. Any way to find out through command line?

pjft

@silentq unsure.

Try

https://github.com/libretro/RetroArch/wiki/Using-the-command-line

Or running

/opt/retropie/emulators/retroarch/bin/retroarch --help

And see if it runs. It should be version 1.4.1.

Also, unclear whether you'd need to recompile the emulator. I doubt it's the case, but could be worth a shot if it's the right version, though I doubt it's necessary.

silentq

So yeah it shows as :

RetroArch: Frontend for libretro -- v1.5.0 -- 51581e1 --
Compiler: GCC (4.9.2) 32-bitBuilt: Mar 19 2017

so I guess just straight updating it didn't revert it back. Although shouldn't it have only changed the driver back?

Either way I have a feeling its not reverted.

pjft

@silentq yeah, so that did not revert it.

So, just re-checking:

can you confirm that the RetroArch script indeed states 1.4.1 as discussed? Meaning that it hasn't been overwritten by RetroPie Setup for whatever reason?
do you confirm that you selected install the RetroArch module from source? And only that module?

When you install it, you should see on the terminal the execution of the git command. Do confirm that it's indeed checking out the v1.4.1 release as discussed.

Best of luck.

BuZz

I have reverted the triple buffer removal in retropie-setup - please update retropie-setup script and update retroarch from source (binaries are not yet updated).

BuZz

Please let me know if this resolves the stuttering.

silentq

@BuZz this does seem to help the situation a bit, although I see some stuttering but I compared to using gl driver and it seems to be a match now in the amount of stuttering from both drivers. I am starting to wonder if this has always been there just it wasn't as noticable until the dispmanx driver started doing it more. I would say this I tested it with both drivers on Super Mario All Stars and Super Mario World and both now seem to be equally albeit very slight when it comes to stuttering. Maybe I am just being nitpicky now haha. What I would say is I would suggest more testing from the community and see if anybody really notices when using either driver anymore.

silentq

On a somewhat related question I notice the gl driver has no input lag and fantastic performance on windows machines which makes me think if or when the next Pi comes out what specs would need to be achieved to run SNES with ease without any bit of stutter or input lag? Essentially as my initial question was alluding to the perfect balance?