Dispmanx video driver stutter on SNES

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?

herb_fargus

@silentq oh I'd say about.... 3GHz

silentq

@herb_fargus Interesting I was anticipating an answer like 2.4ghz but 3 makes sense for full accuracy. I would anticipate from looking around that at the very least less accurate snes9x would be fine at full speed somewhere around 1.6ghz maybe I am a little to naive there lol

mrgibby

Hi.. first time poster so please be kind. I wonder on which builds this is now fixed? I just updated everything from binary (retropie setup script and rest) and then updated retroarch from source. I still get terrible slowdown on SNES (super mario world) that is not there when using gl. Emulator lr-snes9x2010 and retroarch version v1.6.0 (f14473f). Other configs:

video_threaded = "false"
video_driver ="dispmanx"
video_max_swapchain_images = "2"

I quickly tested that setting video_threaded to true might improve it slightly but still noticeable.

dankcushions

@mrgibby what model of pi?

video_max_swapchain_images = "2"

i think this may cause problems. i would probably leave it at the default (3)

mrgibby

Oh, sorry.. maybe the most important info was missing. I am on Pi3. I will test the above. Thanks.