An input lag investigation

RetroArch General
#176

[QUOTE=xadox;41800]Brunnis keeps going with great findings! Are some devs already involved into this?[/QUOTE] Thanks! Here’s another one: I believe I just found and fixed the lag issue in fceumm. Pull request is here: https://github.com/libretro/libretro-fceumm/pull/46

Guess I can be counted as a dev now… :stuck_out_tongue:

I’ve tested the fix and it performs as expected, i.e. it removes a full frame of lag and brings fceumm up to the same level of input lag performance as Nestopia. Talk about small fix (moving one line of code one line up…).

EDIT: Repo with the fix can be found here: https://github.com/Brunnis/libretro-fceumm

EDIT: I can see that twinaphex just merged the fix into the fceumm master. Yay!

#177

I’ve spent the better part of the day looking at bsnes-mercury and the viability of my first fix. The problem with that one was that it could break compatibility if a game were to change the overscan setting mid-frame. Apparently, no commerical software does, but still… So, I went in again and devised what I believe to be a much better solution. For the details, please see this pull request:

I’d really appreciate some feedback. The code is available in this repository:

Below are downloads to all core variants (accuracy, balanced, performance) for Win x64. I would very much appreciate if you helped test these out. If you do, please use the frame advance method to confirm the improvement.

Accuracy Balanced Performance

Cheers!

#178

That sounds like a much safer/smarter fix. Good work, dude :slight_smile:

#179

Thanks a lot, Brunnis, that does seem very interesting and I’d love to test it out immediately! However, the links you have posted for the Win x64 DLL’s don’t seem to be functional, because they require the user to type the corresponding decrypt-key.

#180

Ouch, how noobish of me… Not at home right now, but I’ll fix it as soon as I’m back.

EDIT: Links updated! Here they are again:

Accuracy Balanced Performance

Also, from Alcaro’s comment in the pull request:

Does anyone feel up to testing this and reporting back? Perhaps with screenshots?

#181

Do we need to test any specific game with regards to the bottom scanline and overscan features?

#182

No, I don’t think so. Just one game with overscan and one without.

#183

Hi ! Really enthusiastic to read what’s going on here. Great work !! Input lag has made me upset for years ! (which is why I tended to give up on emulation and use real hardware or FPGA machines). Just a stupid user question : what does the frame_delay option do ? I thought it had to be set to 0 to reduce lag ? Also, if would be great if other devs, inspired by your findings, could check other libretro cores… There are many games that are made difficult (or almost unplayable)… For instance, Star Soldier on the PC Engine ; Gigawing (MAME)…

#184

Thanks!

Actually, it’s the other way around. What the frame delay setting does is that it delays the running of the emulator core (and the polling of input) a specified number of milliseconds after receiving vsync. This is actually a good thing. Normally, when frame delay is set to 0 ms, the emulator runs and generates the next frame immediately after receiving the vsync event. It then idles until the next vsync event. If the emulator runs in a short time, such as 1 ms, the wait period is almost a whole frame. It’s not until the next vsync event that the frame that was generated is actually passed on to the graphics pipeline for display. So, after receiving vsync, the ideal thing to do is to wait with polling input and running the emulator for as long as possible and instead run it as close to the next vsync as possible. This way, the time you’d otherwise spend on just waiting can be used to accept input.

The frame delay setting is specified in milliseconds and it’s the performance of the system/emulator (i.e. the time it takes to run the emulator loop) that decides how high you can set it. The faster the emulator runs, the higher you can put this setting. I managed 12 ms on my Core i7-6700K when running Nestopia and snes9x-next. This corresponds to a reduction of input lag of 12 ms or ~0.7 frames.

#185

Noobish question : do I have to change frame delay to something else than zero, if I have a Gsync monitor ? Or is that irrelevant ?

#186

Thanks for the quick reply ! Hmm, if I understand correctly, if you wait for half a frame (about 8 ms)after the vsync, you need twice the CPU power to render the frame in half the time ? So, when using a slow CPU (Raspberry Pi) one has to check the ideal value for each platform I guess. For instance on my Pi 3 it seems a value of 8 is good for the Neo Geo ; but the PGM platform requires me to set it very low.

#187

I’m not 100% sure, but I would guess that you’d want it at zero in the Gsync case.

[QUOTE=bidinou;41845]Thanks for the quick reply ! Hmm, if I understand correctly, if you wait for half a frame (about 8 ms)after the vsync, you need twice the CPU power to render the frame in half the time ? So, when using a slow CPU (Raspberry Pi) one has to check the ideal value for each platform I guess.[/QUOTE] Yup, that’s correct. The frame delay basically decreases the time you have available to render the frame. On the Pi you don’t have that much extra performance. I would guess that a Pi 3 running snes9x-next could accept 4 ms tops and maybe 8 ms if running fceumm or Nestopia.

The main problem with this setting is that you have to manually tweak it for each host system and emulator.

#188

May I ask a last question ? Did you measure any input lag difference with the video_threaded option ?

Thanks again ! I’m happy to know I can tweak one more setting :slight_smile:

Edit : value of 7 seems OK for Neo Geo and SNES on the Pi 3. I’ll try to pay more attention to subtle sound distortion and try more demanding titles. Edit : after further tests on Pi 3 / RetroPie : frame delay of 9 seems ok for Neo Geo & PSX, 5 for the SNES, 10 for the PC Engine & Megadrive (on Pi 3). No Edit : final values : SNES : 4 // Neo Geo & PSX : 9 / PC Engine : 9 // Megadrive : 10

#189

Nope, I haven’t. I may give it a shot, but don’t count on it. Getting a bit sick of testing right now, to be honest. :stuck_out_tongue:

[QUOTE=bidinou;41847]Edit : value of 7 seems OK for Neo Geo and SNES on the Pi 3. I’ll try to pay more attention to subtle sound distortion and try more demanding titles. Edit : after further tests on Pi 3 / RetroPie : frame delay of 9 seems ok for Neo Geo & PSX, 5 for the SNES, 10 for the PC Engine & Megadrive (on Pi 3). No[/QUOTE] Thanks for testing. Give Yoshi’s Island a try. It’s a SuperFX game and it seems pretty demanding. It was the only game where I noticed slowdown on the Pi 2. Even if the Pi 3 is decent amount faster, there can’t be a huge margin left for frame delay.

#190

Indeed, there is a slight slowdown on the menu with a frame delay of 5. It’s OK with 4. I give up to set this for MAME games :slight_smile:

#191

Think it’s time to try RetroPie, Recalbox or Lakka again. Are the fixes to the emualtors already in the repository or do I have to manualy update them?

#192

Just made a pull request for implementing the exact same fix for bsnes as bsnes-mercury: https://github.com/libretro/bsnes-libretro/pull/16

Hopefully they’ll both be merged very soon. :slight_smile:

[QUOTE=xadox;41852]Think it’s time to try RetroPie, Recalbox or Lakka again. Are the fixes to the emualtors already in the repository or do I have to manualy update them?[/QUOTE] I know RetroPie binaries have been updated with the fix for fceumm, but otherwise I’m not sure.

#193

[QUOTE=xadox;41852]Think it’s time to try RetroPie, Recalbox or Lakka again. Are the fixes to the emualtors already in the repository or do I have to manualy update them?[/QUOTE] for retropie, you’ll have to update lr-fceumm and lr-snes9x-next via the retropie setup script via binaries.

#194

Thanks brunnis. On Gsync it feels pretty reactive already.

#195

You know what I’m doing now (well, in 10 secs)? Actually gaming, not performance testing, on my RetroPie setup. :smiley: