[Feature Request] Improvements to input latency and/or Runahead support

[Ryunam]

I am opening this more as a general discussion on latency with this core, since I don't know if and how an improvement might be viable.

This request comes from having played yesterday with an N64 on a CRT and noticing once again a substantial difference in latency and responsiveness between the real hardware and all the Mupen cores. I have yet to measure the difference, but there have been several reports on the matter already, both here and on the Libretro forums, and it would be great to shave off at least 1-2 frames compared to what we have right now.

These are a few links and references I could gather on the matter. People mention specifically that framebuffer emulation seems to increase latency quite a lot compared to when it's disabled, but then others pointed out that with framebuffer emulation active the latency is faithful to real hardware:

https://www.reddit.com/r/emulation/comments/7qh9hb/psa_reduce_input_lag_in_mupen64plus_retroarch/ https://forums.libretro.com/t/mupen-core-has-more-input-lag-than-parallel/14279

I'm wondering if something akin to the modification that Brunnis did to the SNES cores a few years ago could be applicable.

In addition to this, the ultimate icing on the cake would be to have Runahead support. Currently when enabling Runahead Parallel slows down to a crawl (probably because the savestates are too big to support that functionality?) while enabling Secondary Instance will trigger a message stating that Runahead could not be activated and was disabled automatically.

[dankcushions]

i think real world latency data for real hardware and the cores is crucial to any kind of progression on this issue. it's been lacking in the past. if you can do that, it would be great! remember that n64 games often aren't 60fps, but may report as such in mupen64plus cores, depending on their configuration. so, it's important to get ms mesurements also.

[m4xw]

Irrelevant since reported fps are vi/s

[Ryunam]

I will definitely try to get some measurements to support these observations and I agree that real world data would be imperative. I was just wondering how doable the following would be:

• Runahead compatibility. @hunterk was pointing out on Discord that with ParaLLEl RDP it would be unlikely, since it uses vulkan compute, but perhaps Angrylion could support it in the future. With ParaLLEl RDP it seemed to kind of work at first, like I said in the first post: it’s just terribly slow and it stops working completely when you enable Second Instance.

• Brunnis-Style lagfix. Maybe the moment when the core polls the inputs could be optimized? I remember that for the snes cores it was just a matter of moving the input calls right before the creation of the new frame and that removed 1 entire frame of latency.