Dispmanx video driver stutter on SNES

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.

mrgibby

Hey thanks. It removed the stutter. Actually now I found this: https://forums.launchbox-app.com/topic/33911-retroarch-input-lag-settings/. It claims it has no effect but for sure it caused stutter for me. Also it says input lag increases by one frame moving from 3 to 2. With the settings I had NES games felt really good at least (punchout with gl felt quite horrid compared to dispmanx).

dankcushions

@mrgibby yeah i think dispmanx was fixed to respect the swapchain setting, and now the following applies:

Note on video_max_swapchain_images setting
When using the OpenGL ("gl") video driver, this setting switches between using two or three buffers for rendering. Without going into details, a setting of 3 allows the emulator to run ahead and prepare the next frame before the current one has even been shown. This improves performance (i.e. makes framerate hiccups less likely), especially on slow hardware, but increases input lag by one whole frame in the general case.
So, the general rule is to use a setting of 2 if the system can handle it. It will shave off one frame of input lag compared to the default setting of 3. Please also note that a setting of 2 forces vsync on.

i guess in this case the system couldn't handle it :(