Set "video_threaded" to "false" improves lag dramatically

xpz

The default configuration of Retropie 4.0RC1 is to set "video_threaded = true" in retroarch.cfg. According to the Retroarch documentation, this setting is a fallback and should only be used when full speed is unobtainable. Quote:

"If your video driver has very bad performance, it is possible to run it on a thread to avoid almost all video driver overhead. Set video_threaded = true in config. Butter smooth VSync behavior in this case is impossible however, and latency might increase slighly. Use only if you cannot obtain full speed otherwise." - https://github.com/libretro/RetroArch/wiki/Getting-optimal-vsync-performance

Why is this enabled in the default configuration of Retropie for Rpi2/3? This needs further testing, but my findings are that changing video_threaded to false decreases input lag and sudden slowdowns on RPi3 with Retropie 4.0RC1. This is especially noticeable using the SNES cores, i.e. lr-snes9x-next. I have not yet discovered any drawbacks.

BuZz

How have you measured this ? I have not noticed that big reductions to latency when switching it.

It is set for performance reasons - It was actually switched off by default before but I put it back on again, as it did affect performance when higher render resolutions and shaders were used. It won't be changed by default again, but it is easy to switch from the configuration editor.

If it is working well off you you, then stick with it.

also you can test with some more demanding emulators (eg PSX) and you may notice a more significant performance difference. I did, at least on the rpi1 and rpi2.

xpz

@BuZz I have not made any scientific measurements. Noticed a lot of input lag (200+ ms?) and sudden slowdowns in Super Mario World (lr-snes9x-next) and compared it to my Windows PC and the difference is night and day. I compared the Retroarch configs and discovered the video_threaded flag, which improves the laggyness quite a bit in lr-snes9x-next and others. Not using any advanced shaders though.

BuZz

If it works better for you keep it switched. There have been recent input lag improvements in the snes emulators afair - what version of retropie are you using ? have you updated the emulators recently ?

When the setting was switched before, there were complaints so I prefer to leave it as is. I don't have anything like the lag you are talking about though - some of it may be caused by your screen.

xpz

@BuZz I am using a fresh install of Retropie 4.0RC1 on Rpi3 and made a complete update yesterday. Not telling you to change the defaults, just a headsup that there may be a reason to investigate the video_threaded flag and it's impact on input lag. :)

For me the input lag is especially noticeable in timing based games such as Super Mario World and Street Fighter 2. The Rpi3 setup is connected to a high-end gaming monitor (Asus PG278Q), so the monitor itself should not have that much of an impact.

Will experiment with shader performance and PSX next!

BuZz

Thanks. There have been some threads on input lag, and I believe switching this option was tested. Also see this thread - http://libretro.com/forums/showthread.php?t=5428

davej

Shader performance is critical to maintaining speed without threaded video. One of the things threaded video does is skip frames if it hasn't finished rendering the previous one. This maintains game speed but screen updates don't look as smooth. Without threaded video, the game waits for each frame to be rendered - causing the game to slow down. crt-pi with its default settings is OK (one of the reasons I put so much effort into getting it to run at 60Hz) but if you change the setting it won't be. As a quick test, I enabled curvature and sharper and ran with threaded video off. On a Pi2, Retroarch reported an estimated monitor frequency of about 38 Hz. On a Pi1 it was about 31Hz.

I'd recommend keeping it on and let those who want to experiment turn it off.

dankcushions

if I recall turning it off caused performance issues on a pi2 without even using shaders. i can't find the issue/thread we discussed it on.. probably on the old forum somewhere.