shmups.system11.org

I am trying to play retro games on my LCD screens with as little input lag as possible. I mostly care about NES. I read about the new feature being developed for Retroarch called "beam racing" which is supposed to nearly eliminate input lag in Retroarch. Will beam racing actually eliminate input lag? I am also considering getting a Gsync monitor and Nvidia video card and using that with Retroarch? Does anyone have any idea how well Gsync works with Retroarch and how much it would reduce input lag? How would these options compare to getting something like an AVS NES as far as input lag?

AFAIK, beam racing is not currently implemented for any NES emulator.

So, you can't do that right now and nobody knows.

I do understand that beam racing has not been implemented in NES emulators and I did note that it is a feature being worked on in Retroarch. What I'm really asking is, as a general concept, does beam racing truly allow for no input lag and can it actually be used with retro games?

There is currently a github bounty to add the beam racing feature to Retroarch and the github page can be found here, https://github.com/libretro/RetroArch/issues/6984

From what I'm reading. It looks like beam racing is going to reduce one aspect of lag internal to the GPU. This particular aspect could only ever generate a maximum of 1 frame of lag unless the programmers were making rookie mistakes (which I doubt)

Assuming your CPU isn't a bottleneck. A significant chunk of your input lag is coming from work your monitor itself is doing after the signal is already on the vga/dvi/hdmi/displayport cable.

RunAhead is still something you'll want if your goal is zero. It's not going to eliminate your lag. But it's going to hide it really well.

The process is asynchronous, so the latency associated with building a full frame buffer, sending it along, and waiting for sync can exceed a frame.



Yep. It's been on the front page of libretro's site for a while. Thanks.

You know, WinUAE and Blur Busters put this idea forward in June, right?

Download the Amiga emu and try it out for yourself.
http://www.winuae.net/

Beam racing is only a synchronization technique.

Comparing it to naive synchronization:

If you're vsynced, then it's pretty trivial to start building your frame right as the previous one starts going down the display cable. And, once again assuming you're not CPU bound, your next frame will fill the buffer in less than a frame's worth of time.

If you're not vsynced then you'd have to really get creative to create more than a frame of latency just in the synchronization steps.

Yes, I'm aware of all this, genius. You're initial response suggested that you were not.

Are we using frame rate conversion? When is the emulator finished rendering the frame? When did the emulator poll the controller? Is the "vsync" really synced up to our emulator application output or is it synced to the OS? (It isn't sync to our emulated machine, mate.)

My initial response told you it doesn't exist and there's no answer to your question. You assumed. Relax.

Admittedly I don't know the emulator terminology. I do know modern graphics API's quite a bit though.

The only scenarios where a well implemented vsync pipeline should produce more than 1 frame of lag on it's own is when the game is trying to display more than 1 frame per monitor refresh. Or when simulation and rendering of a frame takes longer than the monitor refresh interval.

If we're talking older monitors. We can assume 60Hz refresh rate. But if we're talking gsync then it's pretty safe to assume it's upwards of 120. Let's call this

Is frame rate conversion attempting to produce more than frames per second?
Is the emulator taking more than 1/ to produce a frame from start to finish?
Is the emulator caching controller inputs at some odd time? Or is it adapting the emulator poll to a current hardware poll?
vsync doesn't synchronize to the OS. It's either synchronized to the gpu itself or completely disabled under the hood. And if the OS is disabling it under the hood then that's a strictly different problem set than beam racing is attempting to solve.

So, assuming the emulator has some notion of when the emulated game would have expected the television to restart at the top. It's pretty trivial to synchronize it's modern output to that emulated wait state. And as long as it finishes everything else in less than 1/ then it shouldn't matter. You're capped at 1 frame of lag generated by vsync itself.

Yep. Fair enough.

In most cases, emulators don't try to change the system refresh rate and users rarely bother. Vsync is set to the OS setting--not to sync up with the machine we are emulating. So, yes, it is synced to the OS. With beam racing and adaptive sync, we are able to move the contents of the software frame buffer to the GPU for immediate display and we don't have to worry about differences between the emulator's refresh rate not matching the OS. Now, the emulator is able to feed video more directly (that will vary based on the implementation the developer uses) down the wire.

When we add adaptive sync and beam racing, the asynchronous issues disappear--from a general point of view. Of course, for devs, racing the beam creates a new set of optimisation challenges. The emulator can focus on being accurate, but the machine and code can't afford to fall behind.

I didn't assume anything. As I said in my second post, I had already noted that it is a feature being worked on in Retroarch and not yet implemented. What I was ultimately asking was if beam racing could actually work in an emulator with the way retro consoles output video to the screen. Anyone that has knowledge about beam racing, retro consoles and emulation could potentially answer this question. Obviously, the answer wouldn't be definitive as beam racing hasn't been implemented in console emulators but people could still give an answer about what they theoretically think is possible.

Yes. It's possible.

About G-sync, Retroarch is usually adjusting to your monitor refresh if it's close to the game timing, dynamically adapting the audio to that.
That's good for fixed refresh monitors but was causing issues for VRR ones.

I added an option to force the exact speed (similar to force max speed x1 in the frame throttle menu) and to adapt the fast forward mode.
That should be merged soon.

That works fine for most cores I use; PAL console ones, x68000 games with their 55.5hz and FBA, Mame particular ones like mortal kombat 1 (you have to enable throttle in the options).
Some cores have particular issues though (related to sound synchronization it seems, bad internal timing acting up). I noticed that for mgba, reicast and dolphin.
They exhibit some stuttering here and there, unless you disable audio sync but then you'll get some crackling.

I'm not sure you'll get any extra input lag reduction with gsync/freesync.
Hard sync to 0 frame and the frame delay setting were already reducing it to the minimum on the "vsync front".

Very nice work. It will be good to unwind some of the consequences of this convoluted "fixed 60Hz" output mess. Compatibility is nice enough, but the trade offs shouldn't be forced on everybody.

--------

Also...

With SNES and NES cores in particular, the adjustment I see to get a proper 60Hz manifests itself with tearing and dropped frames--or classic frame rate conversion. It looks bad.

I'm looking forward to beam racing and variable refresh together so I can run cycle accurate emulators on a CRT. I'll go ahead and trick the GPU into enabling Freesync and the results should be very good.

For just variable sync, that's probably true if the core and the display are using the same frame rate.

-----


But, racing the beam should streamline the process, am I correct?

Could you explain the current hard sync? As I understand it, Retroarch is currently sending each frame as a full buffered frame, correct? (Although, I admit the GPU can pass that along very quickly and many monitors can draw a frame faster than 16.6ms.) Does the hard sync at zero buffer a full frame?

As I understand it, the Blur Busters beam racing technique uses two video/frame buffers at the GPU and copies the current state of the emulator frame buffer (in timed increments) to each individual buffer alternately while pointing the GPU to the other--and this is repeated multiple times during each frame. The GPU "draws" while the emulator frame buffer simultaneously fills the video/frame buffer. The result is a series of incremental frame slice updates to the video/frame buffer that happen very soon after the emulator machine has each frame slice (partial frame) rendered.

That should create a situation where the frame buffer is completely passed on to the GPU at virtually the same moment the current implementation begins sending an entire buffered frame, correct?

For me, the best news here is the possibility of alllowing emulator to be as accurate as possible--if the host machine is powerful enough to stay ahead of the raster--by simulating the way the emulated machine originally sent video to the CRT.

Hard sync is just gl fencing.
Repeating what I was told, you're saving 1 frame of buffering with it set to 0.
It seems vulkan offers that by default at no extra cost.

About beam racing it's confusing for me as well!
I feel like it won't offer much (like 1 frame best case like you said earlier) but reading some explanations (from the blurbuster owner) it feels like you can get more than that.
I'd have to test it myself in some controlled scenario honestly.
I'm not familiar enough with winUAE to test with it in details, I even failed at starting a single game lol.

BTW the VRR option has been merged in retroarch.
It's in "frame throttle" settings menu.
You need to set your monitor refresh at its desktop value in the video menu too (clicking "set display reported refresh rate" there should be enough).