Input Lag guide

dankcushions

Wait till you see what is about to hit in 1.7.3 in terms of native CRT support in RetroArch

i don't think this helps retropie - pi uses a bespoke API for CRT resolutions and the current PR is only relevant to windows, right?

dankcushions

@markwkidd said in Input Lag guide:

Have you all been tracking the new run-ahead lag reducer function for libretro/RetroArch cores that just debuted around the beginning of the month?

My understanding is that it should be able to shave a frame or two off of the lag for older console emulators even with low-power architectures like rpi.

it needs 100% headroom, right? do we have any cores that have 100% headroom on a pi3 (eg, fast forward runs at 2x)?

mediamogul

@dankcushions said in Input Lag guide:

i like this! that's good wording. i think with this change I would be happy with the rest of the updates.

I reworked the headers and added a message regarding their status as specifically being unsupported on the forums. Let me know if you can think of anything else that would make this come across more clearly, and of course, feel free to change any of my wording yourself as you see fit.

markwkidd

@dankcushions said in Input Lag guide:

@markwkidd said in Input Lag guide:

Wait till you see what is about to hit in 1.7.3 in terms of native CRT support in RetroArch

i don't think this helps retropie - pi uses a bespoke API for CRT resolutions and the current PR is only relevant to windows, right?

Native RetroArch Linux support for CRTs is incoming as well. It may get broken up into a second PR or wind up as part of the original.

JasonBigham

This post is deleted!

tekn0

Im sorry for the double post but I just tested the new runahead feature on a Pi3B with the newest Retropie 4.4 and retroarch 1.7.3 compiled from source. It did make a nice difference. I was able to increase the fceumm core 2 frames, and picodrive 3-4 frames. It's awesome actually and feels really good/smooth.

Mame2003 has all types of errors, and Snes9x2010 was a nogo, even at 1 frame. All other snes cores also seemed to have issues, but fceumm and picodrive were champs and it made a noticable improvement. This was also while running crt-pi in nearest mode. The tv I tested on was not 1080p so I will have to test at that res next.

tekn0

@dankcushions The dev has said on his youtube channel he is porting retroarch crt mode to the pi and linux is already working.

pjft

@tekn0 Interesting. Full 60fps at those runahead frames sounds interesting, to say the least.

Could you test lr-genesis-plus-gx if you do have the chance?

I suppose I'll have to try that out myself then, you got me curious :)

tekn0

@pjft I did try it. I was unable to get an extra frame on the gx core. Only pico drive. I talk more about the other tests here. https://retropie.org.uk/forum/topic/17438/new-emulation-method-to-eliminate-input-lag/15

markwkidd

@tekn0 said in Input Lag guide:

@pjft I did try it. I was unable to get an extra frame on the gx core. Only pico drive. I talk more about the other tests here. https://retropie.org.uk/forum/topic/17438/new-emulation-method-to-eliminate-input-lag/15

Dang.. Dwedit specifically worked on the Genesis GX core so that it could use runahead on pretty much even the weakest systems RetroArch supports like the original xbox.

Something must not gel well with the rpi architecture. It may be worth filing an issue and getting Dwedit's attention, but it's good that picodrive works at least.

RedBatman

So when will 1.7.3 be available binary?

tekn0

@markwkidd I remember reading in the release notes he was working on adding support for that core. I just updated from source and I can get 1 frame stable on the new GX core. :)

youxia

I was involved in a discussion elsewhere regarding the results @Brunnis posted in that libretro thread and which were used in this guide (the Super Mario World test). I'm curious about one thing: my own test using the "frame advance" yields 2 frames of lag on average. Similar to mine setup here says 7 frames. Can anybody explain why do they differ and how this works in general?

My setup:
RPi 3B+ @800 Mhz, CRT TV, USB DS4 pad
Only setting used was threaded=off, everything else unchanged

pjft

@youxia the CRT is certainly the way to go. To the best of my knowledge, most of these effects, if the emulators are coded well, are only felt when using LCDs as they are the ones that have some delay in frame rendering. That's why some of them have game modes, to alleviate that by reducing some post-processing effects intended to improve video quality (mostly used for video).

So in summary, you shouldn't really feel much if on a CRT.

Edit: I'm tired and also not the most knowledgeable person about this here, so I'm sure someone will correct me and give you a better and more informed answer.

mitu

I don't think the video lag has much at stake here. If I remember correctly, from the libretro topic discussing this, the test was performed with a LCD having very little (<1 frame?) lag and the tests took into account the lag caused by the video display, so that only input + emulation lag was measured.
@youxia why not post on the libretro forum and ask about this ? Did you use the same testing process as @Brunnis ?

pjft

@mitu well, that's what I get for trying to talk about things I don't know much about:) good morning!

youxia

@mitu I don't want to join a huge megathread on another forum, I'm just posting here in hope somebody clarify this for me (especially seeing as our input lag guide in the doc is based on this thread)

I suppose it has to do with me using the "frame advance" method which is not real time, as he says

By not running the emulator in real-time, we remove the input polling time, the waiting for the emulator to kick off the frame rendering, as well as the frame output. We have isolated the emulator’s part of the input lag equation!

I thought this method is the definitive lag measurement when I read about it in some thread here.

mitu

@youxia said in Input Lag guide:

I thought this method is the definitive lag measurement when I read about it in some thread here.

Which method ? The input lag guide (in this topic) has recommendations for improving the performance, but doesn't offer a testing methodology.

youxia

@mitu I said it twice already :) Frame advance.
https://retropie.org.uk/forum/post/146923

mitu

@youxia The method in the topic just measures the internal emulator improvement, but - as you said - you need to measure externally - as @Brunnis did - the input lag to get a good result. Sorry for the double post.