Input Lag Compensation to compensate for game's internal lag?

RetroArch General
#247

Software renderer version does use the usual framebuffer and video callbacks, so it actually does work with runahead. The emulator is a little slow, so it doesn’t have enough oomph to runahead with secondary core and do Hard GPU sync at the same time. When I disable hard gpu sync, it can run at 60FPS with secondary core (this is emulating two systems at once) as long as you don’t hit any buttons.

Only issue is that savestates are very slow, so resyncing, and not using the secondary core are really slow. Also there is no frameskip feature in there yet, so there is no optimization due to skipping audio or video emulation.

#248

I see, that is coherent with what I am observing since I typically only use the software renderer. Secondary Core performs fine unless you start pressing any inputs - and that’s when it begins stuttering.

I wonder if some of the optimizations that you had applied to snes9x, or in general some way to achieve faster savestates for example, might be worked into the software renderer of Beetle PSX to make it usable in actual gameplay with Run-ahead.

#249

The first test is the actual arcade board? The game runs at 53 FPS I think on the actual hardware. I actually just picked up a umk3 pcb and plan on supergunning it to a pvm. I also have a x360 in a mk cab that runs mk9 and the arcade collection. I had an arcade player over a while back who said it felt different. I don’t have my cab wired jamma anymore. I might put in some work so I can have the 360 and pcb easily switchable or might just play the pcb on the pvm. I can’t decide yet.

#250

Just seeing why Mednafen PSX core is so slow at runahead…

The reason seems to be that saving state is really really slow.

I briefly tried Runahead at the save game menu of Dragon Warrior 7, and it was spending just as much time saving state as it was running the game twice over.

Looking at the savestate code, it is going out of its way to avoid calling memory management functions on the pointer it was given by allocating a big buffer, and doing copies. The memory allocation/copying alone is eating up all the time, and not so much the actual job of saving the state.

3 Likes
#251

Yeah, the savestate code in Mednafen is based on the savestate code in FCEU, it started out as an FCEU-based emulator before it grew into th multisystem project it is now.

I would be totally fine with you breaking the current existing savestate compatibility in Beetle PSX if you can get big performance gains out of doing so. It could also actually make netplay feasible hopefully.

#252

I finally started playing around with this. In Genesis Plus GX, if you enable BootROMs for Gen, MS and GG there are issues if runahead is enabled when booting a game. Genesis games will show the TMSS bootscreen for a split second, then freeze on a black screen and crash. Master System games just freeze on a black screen. Game Gear games skip the boot logo, but play fine. Runahead works fine if I disable the BootROM core option.

#253

This problem can also be triggered by simply saving and loading state during the TMSS screen, runahead has nothing to do with this here.

#255

I deleted an inflammatory post not because I’m trying to silence the author or anything like that. I just don’t want to be a party to more silly scene drama.

#256

Hey all. I did this video almost a month ago after playing with this feature which at the time was hot off the press. Just thought I’d share my results. Please forgive me calling the feature “look ahead” instead of it’s actual name “run ahead” because at the time this was one of the possible names for this feature before it was officially named “run ahead”. Thanks again to Dwedit and the Libretro Team for such an incredible breakthrough in latency.

5 Likes
#257

I want to test this! do i need to download retroarch 1.71 and just replace the exe file with the experimental one?

#258

It’s part of RetroArch now — you should download the latest “nightly” from the RetroArch site and then update the cores you want to test it with.

#259

Thanks! Will try it later! is there an option i have to turn on to get it work?

#260

Has there been a standardized place to put internal lag findings? I would love to be a part of crowd sourcing the data for a future meta data entry.

#261

Settings -> Frame Throttle -> Run-Ahead to Reduce Latency: ON

#262

hmm, i’m not so sure trying to document what value to use for each game is such a good idea. not only is what value works best going to be somewhat subjective, it would also need to be defined per emulator core as certain factors, such as when vblank is emulated in the frame slice, can cause it to vary between cores. and while the latter isn’t so much of an issue anymore, thanks to the efforts of people like Brunnis and the libretro maintainers who reorganized many of the emulator cores to address this, i imagine there are other factors, like perhaps differences in timings that, while not likely, could potentially also affect the results.

1 Like
#263

Not to mention, display latency.

Some displays are laggier than others, so some people may use bigger RunAhead values for those laggier displays. Also, if you enable interpolation on your television, RunAhead can also compensate for interpolation lag. Also, people using low-Hz (125Hz) cordless USB gamepads, combined with a laggier display, may sometimes choose 1 or 2 extra RunAhead frame over people using wired 1000Hz gamepads.

So there are external latency-varying factors, and RunAhead is capable of “compensating” for these external latency causes – RunAhead techniques is one of the only ways to successfully do so.

So there will always be reasons (e.g. display lag, enabling Sony Motionflow, etc) to increase RunAhead counts on a system-by-system basis.

At least for situations where backticking artifacts from larger-RunAhead isn’t a problem.

#264

One other issue with Mednafen PSX is that its savestates are saving and restoring data chunks of size 4 (one word large), with the full name of the variable (bigger than 4 bytes large) specified as the chunk name.

Then the code which seeks through the names to find the correct name has a N^2 complexity, so it’s basically checking 932 chunks against 932 names, getting slow as it is closer to the bottom of the savestate.

1 Like
#265

Can’t thank you enough for looking into this. I would be overjoyed to actually be able to use Runahead with the software renderer of Beetle PSX.

Do you think the savestate system in this core can be feasibly made faster?

#266

I just got the savestates performing much better. When it does a Fast Savestate, it excludes all text labels from every variable now. I also fixed the N^2 complexity bug.

Before:

  • Saving State: 1.787 frames worth of time
  • Loading State: 0.667 frames worth of time

After:

  • Loading State: 0.186 frames worth of time
  • Saving State: 0.144 frames worth of time

(edited post, changed units to make it more clear)

Edit:

In terms of what it does in a frame (just at the title screen and menu of Dragon Warrior 7), some rough estimates of performance:

  • Sound: 13.94%
  • Cpu: 47.03%
  • Video: 33.23%

Now the hard part is eliminating Sound and Video, and enabling the JIT for CPU. Yes, that will be hard to do.

edit: submitted pull request for the savestate fixes, and was accepted. This should show up in nightlies soon.

5 Likes
#267

Display lag, controller, and smooth motion should have no effect on results derived from the pause + “k” frame advance.

1 Like