An input lag investigation

RetroArch General
#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…

#274

Yep, he just ignored it. I thought I was being pretty polite, forthcoming and had some interesting test results, but apparently it wasn’t worth bothering with. It’s almost comical how that thread managed to exceed my very worst expectations, with a pretty bloated discussion that quickly veered off course and was then ignored. Now that I’ve looked a lot more into this, I realize that my initial four questions in that thread should have been pretty easy to answer in a succint way.

EDIT: Ohh, and thanks for the compliments! :slight_smile:

#275

Heh, incredible… I think the worst part may be that no one else challenged him to respond. I know there are many people there interested in decreasing input latency.

Now, please, don’t give me any reason to visit that place again. :stuck_out_tongue:

#277

I think he basically sees certain keywords and then puts on blinders. libretro, latency/lag, a few others. He apparently feels like there’s no possibility of new information in these areas, so it’s not worth his time to consider it.

#278

I’ve been reading through this thread, and I’m seeing quite a bit of testing data. Unfortunately, what I don’t see is information about how to set some of the variables used during testing (such as enabling dispmanx) on my Pi.

To start, how do I enable dispmanx, and how/should I set the frame delay for the NES emulator? Thanks!

#279

Hi. I don’t have much to add but thought you might like to know that the same reordering of polling code to fix lag was discovered independently in the Provenance emulator for tvOS and iOS:

Anyway, thanks for your work!

#280

Based on the timing, I’m not sure that ‘discovery’ was truly independent. Cool to see it spread anyway.

#281

Just quickly looking through the commit i don’t think it’s the same. I’m guessing they had even one more additional frame of delay due to polling after instead of before so would still benefit from the code changes mentioned in this thread.

#282

Looks like your thread’s been locked on byuu’s forum, Brunnis. If anyone wants to stick around for post-game coverage, byuu’s rant continues on his Twitter .

Ethos, ethos, ethos… Who needs logos when you have twelve years of ethos…

#283

Regarding the frame advance latency test, the libretro-test core seems to react to inputs the very next frame. Since this core is extremely simple and just simply polls inputs then draws a checkerboard that scrolls in the direction that was pressed, it should be a good baseline to compare any emulator cores against.

This should also disprove any claims about RetroArch or libretro having a broken input system, since this core responds basically instantly with frame advance, so any extra latency seen with this method would be with the game or the emulator code.

#285

[QUOTE=ralphonzo;43627]Looks like your thread’s been locked on byuu’s forum, Brunnis. If anyone wants to stick around for post-game coverage, byuu’s rant continues on his Twitter .

Ethos, ethos, ethos… Who needs logos when you have so much ethos…[/QUOTE]

Took seven pages and some drama to get those 3 lines:

Gonna take some vacations now, I had to quote twice in a single message. :slight_smile:

#286

[QUOTE=Tatsuya79;43635]Took seven pages and some drama to get those 3 lines: [/QUOTE]

I’m left with the impression that the difficulty of that conversation was a feature and not a bug.

#287

Sorry, slow to respond right now. I’m spending a week in Tuscany, so input lag is not the only thing on my mind right now. :slight_smile:

[QUOTE=UvulaBob;43126]I’ve been reading through this thread, and I’m seeing quite a bit of testing data. Unfortunately, what I don’t see is information about how to set some of the variables used during testing (such as enabling dispmanx) on my Pi.

To start, how do I enable dispmanx, and how/should I set the frame delay for the NES emulator? Thanks![/QUOTE] To enable Dispmanx, edit the main retroarch.cfg and make sure video_driver is set to “dispmanx” instead of the default “gl”. Frame delay can be set via the frame_delay setting in retroarch.cfg. To only enable it for NES, you need to use per-core configuration. If need be, I can give you a more detailed answer once I get back home.

[QUOTE=matt;43327]Hi. I don’t have much to add but thought you might like to know that the same reordering of polling code to fix lag was discovered independently in the Provenance emulator for tvOS and iOS:

Anyway, thanks for your work![/QUOTE] Thanks! However, as larskj alluded to, the Provenance fix is not the same as what was done for bsnes/bsnes-mercury and snes9x/snes9x-next. The libretro implementations of those cores were already polling at the right place. The issue that was fixed was in fact in the emulator code, where rearranging the emulator loop provided for a further one frame reduction of input lag. So, Provenance would actually have had a best case input lag of 3 frames before their fix and before applying my emulator loop rearrangement. :slight_smile:

The libretro implementation of fceumm had the very same problem as the Provenance one you linked to, though.

[QUOTE=ralphonzo;43627]Looks like your thread’s been locked on byuu’s forum, Brunnis. If anyone wants to stick around for post-game coverage, byuu’s rant continues on his Twitter .

Ethos, ethos, ethos… Who needs logos when you have twelve years of ethos…[/QUOTE] Amazing… He still doesn’t get it. Thanks for giving it a try, though. It’s interesting to see what a firm conviction can do to one’s ability to process new information. While it’s hard to accept that he doesn’t understand the theory behind the fix, it’s even harder to accept, baffling even, that he can ignore the test results. He’s so convinced that it’s impossible to improve input lag, that he’d rather believe that not only is the theory bollocks but all test results are botched as well. Quite a stretch.

EDIT: I could of course make the same changes to Higan and send a working build to byuu. However, since I don’t really care that much and I’m 90% sure he’d ignore it anyway, I think I’ll pass. :stuck_out_tongue:

#288

Yeah, I wouldn’t bother.

#289

Has anyone else done any testing with the DRM driver on Raspberry Pi? I’ve been testing it with several different Retroarch cores and with Brunnis’ lag fix it’s the most responsive I’ve found. Unfortunately it isn’t compatible with EmulationStation and has bilinear filtering permanently enabled, but the input lag is as close to real hardware as I’ve seen even on a full PC. I’m hoping once the driver matures some more it will be included in EmulationStation.