Is there any reason to leave the runahead feature in the code?

General Development
#1

For the sake of simplicity and decluttering, I am wondering if preemptive frames is always a superior choice to its predecessor runahead.

If so, I feel like there should be only one feature in retroarch - for the sake of having one less GUI menu in that gazillion of entries. I am not a RA beginner any longer, but I remember the frustration I’ve been through when I was one. So any step towards making things less cluttered should IMHO been taken. I’d just leave the most efficient one and leave it called “runahead” - most documents and tutorials are named as such, plus the name is much more effective imho in describing what the feature is about.

So preemtive frames would just be the new, more efficient code to “run ahead” some frames.

Of course if the current runahead would still make sense in some situations, then it’d be a totally different story.

Thanks for reading!

#2

yeah, we hope to merge them at some point. I think there are some differences at the moment, though i don’t personally know what those are.

1 Like
#3

I think it’s nice how when you turn Preemptive Frames on it automatically disables Run-Ahead and transfers the number of frames to Run-Ahead to the preemptive frames setting.

If one has less potential side effects then it’s probably good to have them both for scenarios where you can’t use Preemptive Frames.

I think they did a good job explaining what Run-Ahead was when it was implemented and launched and the same goes for when the RetroArch team implemented Pre-emptive Frames.

Maybe the issue here is finding a way so that users can easily get the information about the new features if they might have missed the introductory posts.

The tooltips also play a huge role here. So in my opinion the advanced features should be left as is - exposed because they’re intended for an advanced audience.

Do casual users even know how to properly setup Run-Ahead, Pre-emptive Frames or Frame Delay?

Lately I’ve been fiddling around with setting up “Sync To Content Refresh Rate” because some cores work best if V-Sync is left on together with this feature, while others absolutely require it to be turned off.

1 Like
#4

Afaik it’s not for 2 reasons :

  • cores that require second-instance runahead won’t work properly with preemptive frames (which is basically an alternative version of single-instance runahead)
  • i remember reading that, under heavy input stress, single-instance runahead is still superior
4 Likes
#5

In Bettle Saturn, I noticed some games can be set to Run Preemptive Frames 2, while even setting it to 1 with Run Ahead is enough to run below its otherwise full speed (mostly). I’m not technical, but since Preemptive Frames were introduced, it really does feel lighter.

#6

This latency-reducing feature only requires to rollback in the worst case scenario, which is when an input has been pressed.

This is not what’s happening with single-instance runahead, single-instance runahead will always rollback. I’m not entirely sure if it is “by design” or if it is a bug in the current implementation.

Long story short, under heavy input stress, performance will decrease with preemptive frames and second-instance runahead, while it’ll always remain stable with single-instance runahead.

2 Likes
#7

I haven’t tested Preemptive frames enough, but I have noticed some differences. It works better on fast machines with Vulkan and Run-Ahead gives better results on slow machines only with glcore.

Documentation is something vital, although it is something that comes slowly.
Run-Ahead has good support information in the docs, in official videos and also the blog presentation.
Preemptive Frames is new, there is not too much documented information, but in the release it basically explains what it does and what is the difference. Perhaps the most notable is that Run-Ahead is not compatible with OpenGL/Direct3D11/Vulkan.

#8

Please explain this? I use Run-Ahead as well as Preemptive Frames with Vulkan. Why do you say it’s not compatible?

#9

In the article it says:

Biggest one being steep performance requirements and (so far) no hardware context support (so cores that currently rely on OpenGL/Direct3D11/Vulkan are a no-go).

I’m not sure, but I guess that the cores that only work with those drivers, can’t use Run-Ahead.

Do you know that the cores change the driver automatically, no matter what you chose in the interface?

#10

To clarify, this statement was about cores using hardware-acceleration (i.e. 3D graphics drawn using your gpu), not about the usage of specific video drivers in retroarch. All video drivers are supposed to be equal as far as runahead is concerned.

My understanding is that it used to be impossible to use runahead with those cores, because all “frame iterations”, including the ones runahead wants to “mute”, would directly access the gpu.

I say “used to” because it should be possible to get around this with the runahead context awareness apicalls. Theoretically you just need to remove those gpu accesses for the “frame iterations” that are supposed to stay “silent”. Edit: to clarify, i’m talking about the RETRO_ENVIRONMENT_GET_AUDIO_VIDEO_ENABLE apicall, which lets you know if a frame should be displayed on screen or not.

3 Likes
#11

I feel like since it’s possible to ‘know’ the required run-ahead amount, it should be automatic or use a database.

4 Likes
#12

Yes, this is essentially what “shmuparch” provides. It’s a thing we could provide, as well, if anyone wanted to go through the trouble of generating such a list.

5 Likes
#13

A database and auto run-ahead setting could be nice but personally I will still be doing the “old” pause+nextframe to set it correctly: it only takes 2 seconds.

IMHO, a good “free” feature would be to show a description text with the instructions on how to set it. At the moment this info is not there (in the menu) nor in the “select” pop-up.

1 Like
#14

The idea is nice but who’s gonna build and test such a thing for thousands of compatible games?

Perhaps the data could be crowdsourced if RetroArch collected analytics or allowed interested users to submit Run-Ahead config data but it would still need to be verified. Also, what do we do about games that natively have more than 1 frame of lag on real hardware? Some of us would prefer the accurate setting while others would prefer the lowest input lag settings even if it’s lower than real hardware.

I’m with you on this!

Maybe we could have a default setting of 1 Frame of Run-Ahead or Preemptive Frames as a baseline if it’s safe for the vast majority of situations in conjunction with Auto Frame Delay?

1 Like
#15

Actually it was not very clear to me, because the article is from the current version 1.15.0 and cores with hardware acceleration, such as Flycast have been working for quite some time.
Could it be that Run-Ahead does the calculations by CPU and Preemptive by GPU, which is why Run-Ahead works better on slower computers?

#16

No, they’re doing almost exactly the same thing using the same mechanisms. They differ by very small, technical things.

2 Likes
#17

Who else? The community, as many other things are done.
It would be interesting while we are here, to take @hunterk 's idea, to agree as a group and adjust the delays to the minimum, because nobody knows how many delay frames the original hardware has, it’s a lot of games but it’s done once and it works for Run-Ahead and Preemptive frames.

Although, you have to be very, very careful not to break the gaming experience, Latency is a tool for the gaming experience, not just a physical bug of the console.
In Mario World, there are 2 for normal jump, but 3 for whirlpool. On the other hand, King of Figther has 7 for punch and kick, 5 for block and only 2 for escape.

I forgot, the dynamic ones, some like Metal Slut have 4 frames or 7 or 5, they do it to make it more natural (?) and those with programming errors like Mortal Kombat 1 from Snes, which sometimes takes 6 or 9.

1 Like
#18

Just like you can replace “the cloud” with “someone else’s computer”, you can replace “the community” with “one determined guy” lol. I will not be that guy, but if someone else wants to be, I’m all for it. I think a github repo would work well for vetting submissions from others.

4 Likes
#19

Let’s see what fate has in store for us, in the meantime, we do it manually.
Something I was thinking, a counter next to frames would be useful. Something like F=1, F=2, etc. when pressing the K button, and when pressing pause, return to zero.

I was thinking that a little drawing would be very useful to make it understandable to new people, and there is…

retroarchr1ppd-768x464
retroarchr1ppd-768x464768×464 141 KB

In this article with the release it is well explained.

2 Likes
#20

“techno-social engineering humans” that is to say, neuromarketing. :smiley:
This article is very interesting, thank you.
It seems a bit harsh to me, human nature is to reject the difficult (and to be contrary), that’s why it is simplified, but in the social context, this does more harm than good.

In reference to collaborative projects, there are cases of success, for example the piracy sharing pages, the community shares non-stop. Basically they have 4 things. They like it. There are clear rules of what they have to do and there is a reward system, I don’t mean an economic one, but a moral one, gratitude, comments, likes. The last one is perhaps the most complex, to go against the system.

Although, the emulation community is a special case.

1 Like