Got a question anout beam racing and how it applies to my set up. I am using a pro crt monitor with crtemudriver to output 15khz.
As I understand it beam racing wouldn’t directly eliminate any input ag for me because I am using a crt but it could eliminate screen tearing and allow me to turn off v-sync, thereby indirectly reducing lag. Is this correct?
No that’s not correct. On a powerful enough pc, beamracing will eliminate (very close to) all input lag and deliver true hardware like response. It will work for both CRT or LCD. Relatively speaking it will even work better on CRT, as the hardware requirements will be much less compared to an LCD setup with resource intensive (CRT) shaders.
But don’t get your hopes up, because getting this implemented for Libretro cores is easier said than done. I guess the question for libretro is more an “if” than a “when”.
Rafan, thanks for clarifying. For now I’m really happy with run ahead.
So what are currently the best overall settings for acceptable input lag across all cores? I’ve been using vulkan because I was under the impression that it had similar input lag to opengl+hardsync, but without the performance impact. However, according to this thread, it seems to maybe be worse depending on the driver? Is that an AMD issue or does it affect Nvidia as well?
I suppose I could have a separate install of retroarch with opengl+hardsync for older systems, but then what would be the best configuration for more hardware intensive cores that don’t perform well with hardsync?
I’m currently on Windows 10 because I don’t feel like rebooting into Linux just to get lower input lag if that’s still a thing. I’ve used KMS in the past and never really noticed much difference in input lag. Plus, doesn’t nvidia not support any of that stuff?
It depends on how resource intensive the core is and game you’re playing.
For me I have an i5 4670k not oc’ed and GTX 770 and spent a good day off going through all the cores I use and obtained a general idea of what my machine can and can’t handle.
Using the OGL backend For example systems up until say PSX my machine can handle GPU hard sync 0, frame delay of 10 and run ahead of 2 frames (could handle even more frames but then the game starts to glitch) Using Game mode on my Plasma and DS4 Bluetooth connnection (4ms polling rate) I can’t tell the difference between my CRT and my Plasma with input lag. After PSX I cannot handle run ahead that well but I can get away with shaving off some lag with frame delay.
But what about vulkan vs opengl for hardware intensive cores?
I’ve never felt compelled to Use Vulkan because OGL has done the job for me so there I can’t really help you.
Some cores can’t be helped with whatever options you can throw at them. Mednafen Saturn and the more recent PPSSPP updates are the worst offenders. Same with some N64 games that use framebuffer. That’s more than 4 full frames of lag on top of any other lag from the LCD, etc. GPU sync, frame delay, etc barely do anything.
could you test the other input methods for the 8bitdo sfc30? I was under the impression that the xbox mode (x then turn on)of the control was faster than the d-input (turn on without pressing any extra button) one when conected over cable.
doesn’t mednafen saturn have have midframe input sync option to reduce input lag?
Yeah but it makes no difference. At least on the core/my system.
You probably have the equivalent of that playing with the “frame delay” value.
But that’s still really stressful on the cpu anyway.
Does enabling rewind increase the input lag?
Enabling rewind adds a savestate to every frame, which increases processing time by a very small amount. Saving state is usually far less work than emulating a frame.
It’s so insignificant that it only matters for people who are using the Frame Delay feature, and might need to turn that down a notch.
Processing time as in additional input lag or additional cpu usage? I’m aware that it increases the cpu requirements for a core but didn’t know if it increased input latency.
Rewind does have a significant performance hit though. It may depend on how the savestate code is implemented in each core I guess.
If you’re using frame delay, at worst, rewind is going to cost you a couple of milliseconds for most cores (i.e., you might only get up to frame delay 8 instead of 10 or whatever). So, that’s a couple more milliseconds of latency. If you’re not using frame delay, there won’t be any increase at all.
How does it impact run ahead?
It shouldn’t have any effect at all, as both rewind and runahead require taking states on each frame.
Does using either gsync or freesync decrease input lag? I know that in traditional pc games, using either helps to eliminate most of regular vsync lag.
edit: Wow, using scan line sync from RTSS with SSF brings the input lag below beetle saturn + vulkan. Also am not noticing any tearing or stuttering. Hopefully retroarch can get that some day.