Frame delay VS run-ahead

So, which is more efficient and less/more taxing on the CPU? Is Vulkan or GL a factor as well?

1 Like

They have nothing to do with each other, so not sure what kind of comparison you’re looking for :stuck_out_tongue:

GL vs Vulkan doesn’t matter, other than the one that gives you higher FPS will allow higher frame delay and has less chance of bottlenecking run-ahead.

As far as i understand, regardless of how they actually work, both are meant to reduce input lag, right? So they are both meant to do the exact same thing. Let’s say i want to cut 1 frame of lag; which of the two will do it with less CPU power?

No, they do different things. Run-ahead removes internal game lag caused by the game itself. Frame delay removes external lag caused by the delay between the emulator rendering a frame and the GPU displaying it.

Frame delay does not increase CPU load. It simply delays the emulator a bit so that it reads player input later.

Run-ahead does increase CPU load, because it needs to rewind the emulation and also run the emulator twice (if “use second instance” is enabled.)

Oh, thanks for the explanation :slight_smile:

However, it seems that, at least at first glance, frame delay does eat quite a bit of CPU, as setting it to more than 6 ms (half a frame), produces stuttering in audio and video. On the other hand, run-ahead set to 1 frame (which i imagine eliminates 1 frame of lag) still allows me to play the exact same game full speed (fbneo core).

The stutter is not due to more CPU load. It’s due to the emulator not being fast enough to render the frame in the remaining time. For a 60FPS core, you have 1000/60 (16.7) milliseconds of time to render one frame. If the emulator can render it in 10ms, then you can use a frame delay of 6ms. If the emulator can render each frame in 5ms, then you can use 11ms delay.

If you set the frame delay too high, then the emulator runs out of time to render the frame. That’s what causes the stutter. So the faster your system is, the higher a delay you can use, but doing so does not increase CPU load.

1 Like

Sorry for being such a knucklehead, but i always thought that a faster CPU equals better performance in emulation (especially 2d one). Are these lag oriented settings comunicating differently with the system CPU compared to the rest of the variables inside the emulator?

Edit: so, reading a bit more carefuly your reply, i think i understand. It’s about how a certain core/game is handled in Retroarch. So regardless of the hardware, that game in that core version will not be able to have a higher frame delay. Am i getting it right?

No. The faster your hardware is, the higher you can set the frame delay, because on faster systems, the emulator can emulate each frame in less time.

Let’s say the emulator can emulate 1 frame in 10ms. There’s still 6.7ms left until the next screen refresh (which happens every 16.7ms.) So the emulator emulates 1 frame, then RA waits 6.7ms doing nothing before it can show that frame. However, with frame delay, RA tells the emulator to start emulating the frame later. So instead of emulating the frame and then waiting 6.7ms, with frame delay you can first wait 6ms, then start emulating the frame, and by the time that’s done, RA can show the frame on the screen immediately.

3 Likes

So, if I understand correctly, the whole point of frame delay is to reduce the interval of time between the rendering of the frame (and consequently the detection of the user input) and the visualisation on the screen?

2 Likes

Exactly.


2 Likes

Should the Input polling be set to early, normal or late when using frame delay?

And what about the audio latency? Is lower the better?

1 Like

Depends on the core, but unfortunately, it’s not documented in the cores which is better. So… unknown! Usually “early” is just fine.

That doesn’t affect input lag, only audio lag.

Poll type is recommended to be set “late”.

However, I extensively tested ume2014 core and input lag is the same in all instances.

2 Likes

So if the box can handle 0 latency on the audio that’s the best to use?

0 probably means “auto”. It’s not possible to have zero audio latency because that value determines the audio buffer size. 0 size would mean no audio :stuck_out_tongue:

Also, there’s a minimum latency value. If a platform or audio driver can only go down to 8 for example, selecting a value lower than that has no effect.

In general though, you don’t need to bother with this setting. Do you notice any audio delay? Because if not, the only thing you’re doing when lowering it is increase CPU load.

2 Likes