I just wanted to say, thank you so much for taking a stab at this ! I’m so happy to finally see any G-Sync support happening and it looks like it’s working pretty well. After playing with some cores, everything appears to be scrolling so much more smoothly than before. If I may make a request, if you put out a new .exe, would you be willing to have Discord’s Rich Presence enabled?
So Vulkan seems perfectly smooth with G-sync, but GL doesn’t. I’m guessing that’s because of this issue on Windows 10 1803. The Mupen64Plus core requires GL, and doesn’t feel smooth.
Is there any way to actually force GL to run in exclusive fullscreen mode? The problem is that whether or not you set ‘windowed fullscreen’ to true or false in RetroArch appears to have no bearing on the presentation method - neither setting runs in exclusive fullscreen, at least not when using GL on Windows 10.
I don’t have windowed GSync enabled in my NVidia CPL and it still activates with Windowed Full Screen set to off in RA using the GL or Vulkan video drivers. I’m on Win10 too.
That said, there’s a new hotfix driver that is supposed to fix windowed GSync you could try: http://nvidia.custhelp.com/app/answers/detail/a_id/4693
Merged, in the nightly build now.
i’m glad this is finally being provided its own option in retroarch, but i must admit i’m not a fan of the name “VRR Runloop”.
for one thing this feature is also useful to those without displays capable of adaptive sync, as if they’re willing to disable vsync (and accept tearing) they can use it to run content at the guest’s native refresh rate. using the system’s clock and sleep functions to sync host time to guest time once per frame, as this feature does, is sometimes more accurate and reliable than syncing on audio, it all depends on the users hardware, quality of audio drivers, sound server issues (audioflinger, for example), etc.
for another, using “Runloop” in a option name to be exposed to end users just doesn’t seem very appropriate, it’s programmer terminology and doesn’t have much meaning outside the context of the source code to retroarch itself.
but since this has already been merged i’m guessing it’s too late to propose alternative name suggestions, so i’ll just shut my big mouth for now.
It’s not that hard to change the name exposed to users, whether the actual internal name is changed or not.
Would you prefer something like “Match Content Timing”? We can provide more context in the subtitle, like “Sync to content timer instead of user’s monitor refresh rate. Useful for variable refresh rate displays”.
i think “Match Content Timing” sounds pretty good, actually. prior to hearing that i didn’t have any specific suggestion in mind myself, i was thinking more along the lines of just something with “Sync” in it, since this is another method of syncing host time to guest time and i thought it would fit well with the terminology currently in use by the other two options in retroarch: “Vertical Sync” and “Audio Sync”.
here were some ideas i was going to throw out: Clock Sync, Time Sync, Timer Sync, Throttle Sync, Content Sync, Core Frame Rate Sync, Adaptive Sync, Variable Refresh Rate Sync, Variable Refresh Sync
and whether the “(G-Sync, FreeSync Mode)” note should be kept appended to the main label or moved into the sub label would depend on what name is chosen, like for “Adaptive Sync” it would probably make more sense to be in the sub label.
but i do like “Match Content Timing”. i’m wishy-washy here, i don’t have too strong an opinion over what i think is optimal, just what i think is confusing.
the sub label suggestion sounds good too, as long as the feature is disabled by default i don’t think there’s a real need to add much else there. if this were enabled by default it might cause problems for users without an adaptive sync display who have both vertical sync and audio sync enabled (both of which are by default).
I could only agree with what Hunterk suggested, everything else seems more confusing.
For what it does, it could even be named “Disable Audio Dynamic Rate Control” as it’s that standard RA feature we are avoiding here. (not that I think it should be named like that)
I thought about all that, and apart from “runloop” it was already an effort to make it easy to understand.
I thought it was important to have “G-sync/FreeSync” in the main title as it’s the 1st thing users will use it for, nobody reads the sub-labels first…
It could be “Respect strict Core Timing (recommended for G-sync/FreeSync)” or something like that.
I have noticed that the bsnes-mercury core is more prone to audio issues (crackling / dropouts, depending on which driver you use) with the vrr option on. That core was always the hardest to eliminate audio issues on, but for now at least I get a better experience with that option turned off.
Hi @Tatsuya79,
Thanks for implementing the sync to exact content framethrottle option, it works really well with my G-Sync screen.
I do encounter one oddity. Everything works very well and smooth when using X-Audio as sound driver, but when I switch to WASAPI, the scrollling gets jerky.
Do you guys get the same experience or does the G-Sync/Freesync modification (sync to exact content frame rate) work as smooth with WASAPI as it does with XAudio?
It’s supposed to work the same, but the audio has a direct influence on the motion too when “audio sync” is active.
I’m not using wasapi at all as I noticed several problems with different cores in the past… so it’s probably one kind of issue.
So whith the new NVIDIA Driver I can use my FreeSync Monitor, I just want to now if any Audio configurations is required (or enhance the experience), like change something in Dynamic Audio Rate Control and Audio Maximum Timing Skew.
All you have to do is enable the ‘sync to exact content framerate’ in the ‘frame throttle’ menu.
1 Like
I am kind of confused with this option. I have a 144hz 1440p gsync monitor and i notice no difference in scrolling with this option on or off. The only thing i notice is that once in a while my frame rate monitor(RTSS) will go up to 61 when this option is turned off. Also certain cores run badly with it turned on such as reicast with internal upscaling. My main question is should I enable this on all cores that it works well with to get the most accurate frame rates in games? Does it actually affect gameplay at all? Thanks for any input.
Not for anything that’s close to 60 Hz, which is most things. However, some consoles/games use crazy refresh rates like 53 Hz (Mortal Kombat) or 75 Hz (Wonderswan) that are so far off that it does affect gameplay.
1 Like
Reicast is particular as it is one of the multithreaded cores and it syncs to the audio on a different thread.
Using “exact sync” with a gsync screen, my best setting is to disabled the threaded rendering in core options, framerate to original, TV(RGB)/NTSC/Japan.
Even like this I see some small occasional stutters. Disabling audio>audio sync get completely rid of them but then the audio will sometimes pop or crackle.
I also tried without “exact sync”, gsync off in nvidia pannel and various other settings (threaded + synchronous in core option): I just get more stutters than with the settings above.