An input lag investigation

RetroArch General
#251

[QUOTE=bidinou;42111]Apparently there was some additional input lag specific to the (s)nes. There is one more frame of lag specific to opengl (you can work around it by using the dispmanx video driver but then you have no pixel shaders – btw, I’d love to know what good overlays you can use with it :slight_smile: I tried a few but the result was not satisfying – and there seems to be one more frame of lag which is not understood for the time being.

Also I read this, is it relevant ? “Also, Lakka has now been modified upstream to apply the rt-kernel patch for more consistent scheduling with 1Khz tick rate, preemptible etc. (frame delay setting can be increased further)”

Finally, there is this frame_delay_setting that can help you get back up to one other frame of lag but you need a very fast CPU and this is super annoying to tweak. (different optimal value per system or even per game)

/me enjoys reading this thread even if he is just a dumb user

Edit : brunnis made a summary here : http://libretro.com/forums/showthread.php?t=5428&page=18 Without frame delay, there is up to 5 frames of delay while he only measures about 2 on a real SNES. I clearly see a huge difference between RetroPie on a Pi and the NES/PCE/… FPGA core on my MiST for instance. But FPGA computers are 1) very expensive 2) support few systems.[/QUOTE] Does the windows version have the dispmanx video driver? Which, has no shaders and has to use the blurry bilinear filter, right? Does that shave 1 frame off 5 frames of delay and thus you get 4 frame delay?

#252

[QUOTE=MrPoe;42584]Does the windows version have the dispmanx video driver?[/quote]no. it’s raspberry pi only.

Which, has no shaders true

and has to use the blurry bilinear filter, right?

no

re: gl shader lag - if your shader is running at 60fps i don’t think the shaders will be causing lag? also i thought someone tested with shaders and said it didn’t cause (additional) lag?

#253

Great that Brunnis findings and work was mentioned in the 1.3.5 release!

#254

Yeah, it is great that his fix was actually recognised on the official Libretro blog. Once again, great work and I’m truly grateful for the improvements and efforts that all contributors are making here to achieve a perfectly responsive experience. :slight_smile:

That being said, I have also noticed that Alcaro had disabled the lagfix on both bsnes and bsnes-mercury, as evidenced here and here. As far as I understand, this has to do with the issues recently brought up by Radius with regards to MSU-1 patched games, which seem to break entirely with the Lagfix on and Rewind enabled.

I would humbly request for it to be turned back on, for two reasons mainly:

  1. The benefits introduced by the lagfix largely exceed the entity of the problem that was documented for MSU-1 games. We are talking about a proportionally small subset of hacked / patched titles that do not work - and they actually malfunction only if you activate the Rewind function on RA - as opposed to an option that has been measured and verified as an improvement to all compatible software.

I feel that it should be better left ON by default, at least on bsnes-mercury, while emphasizing that MSU-1 patched games currently work only with Rewind OFF.

  1. The latest blog entry specifically mentioned the lagfix being implemented on all existing SNES cores as a major breakthrough for version 1.3.5 - and this includes bsnes and bsnes-mercury. That implies a contradiction between what has been publicly stated on the blog and what is actually being downloaded by the end user.

Thanks in advance, looking forward to an update on the matter.

#255

Awesome, I hadn’t seen that yet. :slight_smile:

Thanks!

[QUOTE=Geomancer;42647]That being said, I have also noticed that Alcaro had disabled the lagfix on both bsnes and bsnes-mercury, as evidenced here and [B]here[/B]. As far as I understand, this has to do with regards to MSU-1 patched games, which seem to break entirely with the Lagfix on and Rewind enabled.

I would humbly request for it to be turned back on, for two reasons mainly:

  1. The benefits introduced by the lagfix largely exceed the entity of the problem that was documented for MSU-1 games. We are talking about a proportionally small subset of hacked / patched titles that do not work - and they actually malfunction only if you activate the Rewind function on RA - as opposed to an option that has been measured and verified as an improvement to all compatible software.

I feel that it should be better left ON by default, at least on bsnes-mercury, while emphasizing that MSU-1 patched games currently work only with Rewind OFF.

  1. The latest blog entry specifically mentioned the lagfix being implemented on all existing SNES cores as a major breakthrough for version 1.3.5 - and this includes bsnes and bsnes-mercury. That implies a contradiction between what has been publicly stated on the blog and what is actually being downloaded by the end user.

Thanks in advance, looking forward to an update on the matter.[/QUOTE] Yep, I was aware of that. I am looking into it. Here’s a comment I just posted on GitHub, in response to Alcaro defending the disabling of the lagfix:

“I agree, Alcaro. I’ve spent the better part of the day looking at this and I’ve found that the issue has nothing to do with the lagfix or MSU-1 games. It appears to be a bug within state_manager.c and/or mismatch.c in RetroArch. I’ve been able to make a workaround by doing a small change in state_manager.c, but I’m not done with my investigation yet. Hopefully I’ll have some more info tomorrow.”

#256

Typical users will benefit from fixing the input latency bug which makes many games unplayable. And the msu1 system requires special setup that typical users will not use, so it is better to fix the snes emulation/latency first and then work next on the msu1 system and its interaction with retroarch.

#257

“unplayable” is hyperbole of the highest order. Very few people have complained about the single frame of extraneous latency in the 11 yrs bsnes has been around and in the 5+ years RetroArch has been around. OTOH, MSU1 is a flagship feature of bsnes and one of the main reasons people use it over snes9x.

If you guys value that one frame of extraneous latency over MSU1 support, you’re welcome to enable the option and compile your own copies of the core while we look for a proper solution to the serialization issue(s). In the meantime, snes9x/next doesn’t appear to have any issues with brunnis’ patches, so if latency is your biggest concern, just use it instead.

#259

As long as one of them (Snes9X) has this fix inclided in mainline updates, awesome :slight_smile:

What about FCEUmm? It’s mentioned on the 1.3.5 post (now 1.3.6, for some reason). Does the regular FCEUmm include the lag fix now? (By regular, I mean the one provided by the online updater)

#260

I believe I’ve found and fixed the issue. Please see pull request:

#261

Hey, that’s great, Brunnis. Thanks for your continued attention and contributions on this.

#262

Would it be possible to have a compiled .dll bsnes / bsnes-mercury with the lagfix ON, in order to test MSU-1 games with the latest commits? Unfortunately I lack any means to build it by myself as of now, but I would love to give it a try.

As usual, many thanks in advance. :slight_smile:

#263

Please turn on the lagfix in libretro-bsnes so that others may test Brunnis’ input latency and serialization bug fixes. Work should be an open libretro community effort as the developers posted on the blog.

#264

Sorry for adding this noise but : thanks a lot to all involved :slight_smile:

#265

@Sam33 We’ll run our projects how we see fit, thankyouverymuch.

Anyway, here are a couple of builds with it turned on for testing:

#266

Thanks everyone! Nice to be able to contribute. :slight_smile:

The fix is now in the latest nightly RetroArch build here: http://buildbot.libretro.com/nightly/windows/x86_64/

I just saw that the lag fix was re-enabled on both bsnes and bsnes-mercury, so it should soon be in the nightly core builds as well. It would be great if you guys could help out with additional testing, both with/without rewind enabled and on games with/without MSU-1 hack.

By the way, hunterk, I noticed that only the bsnes-mercury core in the zip file you posted has the lag fix enabled.

#267

/shrug, I just git-pulled and changed ‘lagfix’ in the makefile to 1. I didn’t check to see if there was anything missing/required.

#268

Okay, strange… I just made a fresh git clone and managed to compile all core variants with and without the lagfix and could confirm that the lag fix indeed works. Anyway, the code in the repo seems fine, so let’s not dwell on that.

I’ve compiled all bsnes and bsnes-mercury variants (for 64-bit) with and without the lagfix and provide a download link below. I’ve tested them all and confirmed that they work as expected. I’d be grateful if you guys would use them together with the latest RetroArch nightly to provide some more test results and confirmation that things now work as expected (i.e. without crashes).

bsnes_64bit.zip

I’ve performed tests on MegaMan X (MSU-1) and SMW2 (no MSU-1) in both RetroArch 1.3.4 and the latest nightly with the savestate fix. All tests were done with rewind enabled. I tested both bsnes and bsnes-mercury, but the results were exactly the same.

RetroArch 1.3.4, lag fix off

Accuracy:

  • SMW2: OK
  • MM X MSU-1: OK

Balanced:

  • SMW2: OK
  • MM X MSU-1: OK

Performance:

  • SMW2: Crash immediately on start
  • MM X MSU-1: Crash on entering title screen

RetroArch 1.3.4, lag fix on

Accuracy:

  • SMW2: Crash immediately on start
  • MM X MSU-1: Crash on entering title screen

Balanced:

  • SMW2: Crash immediately on start
  • MM X MSU-1: Crash on entering title screen

Performance:

  • SMW2: OK
  • MM X MSU-1: OK

RetroArch 1.3.6 + savestate fix, lag fix off

Accuracy:

  • SMW2: OK
  • MM X MSU-1: OK

Balanced:

  • SMW2: OK
  • MM X MSU-1: OK

Performance:

  • SMW2: OK
  • MM X MSU-1: OK

RetroArch 1.3.6 + savestate fix, lag fix on

Accuracy:

  • SMW2: OK
  • MM X MSU-1: OK

Balanced:

  • SMW2: OK
  • MM X MSU-1: OK

Performance:

  • SMW2: OK
  • MM X MSU-1: OK

So, as expected, the crash could occur even without MSU-1 or the lag fix. Also as expected, the fix seems effective for all of the observed failure cases. This issue must have caused crashes here and there for a long time…

#271

[QUOTE=Brunnis;42871]

  • KMS + experimental OpenGL driver on Raspberry Pi[/QUOTE]

About this one, I have yet to upload the system image so you can easily test, Brunnis, but I am on a far off village right now, without a Raspberry Pi at hand or it’s SD, so I won’t be able to upload it for 1-2 weeks. Should have done it before I left my hometown, but I had no time. In case you want to try yourself, disable X11 server in Raspbian, and pass the overlay parameter I told you about in config.txt.

#272

[QUOTE=vanfanel;42882]About this one, I have yet to upload the system image so you can easily test, Brunnis, but I am on a far off village right now, without a Raspberry Pi at hand or it’s SD, so I won’t be able to upload it for 1-2 weeks. Should have done it before I left my hometown, but I had no time. In case you want to try yourself, disable X11 server in Raspbian, and pass the overlay parameter I told you about in config.txt.[/QUOTE] No worries, I should be able to get this up and running myself. However, I probably won’t have any time for this during the coming two weeks. I’ll let you know then if I run into any problems.

#273

Amazing work. I just have to ask… Did byuu seriously just ignore this post of yours? I know it’s a bubble over there, but I’m still quite blown away if he didn’t at least PM you a sincere response…