Blur Busters Forums

Probably their new DCH drivers that was wonky. Didn't autocap FPS in neither CSGO or Apex Legends. Reinstalled with standard drivers instead and it works.

jorimt wrote: ↑

12 Feb 2020, 09:37

As far as I'm aware, the NULL auto-cap with G-SYNC only engages in (non-DX12/Vulkan) games that allow external manipulation of the pre-rendered frames queue

My experience says otherwise. Frostbite3 based games in DX11 mode never seem to respond to LLM's queue manipulation (judging by the obvious effects of the renderaheadlimit dev.console parameter changes but no apparent effects of LLM) but the fps auto-cap of Ultra (usually) works correctly.

jorimt wrote: ↑

12 Feb 2020, 09:37

And through HDMI (aka the LG C9)?

Exactly. And yes, now with official G-Sync Compatible certification (fresh official firmware) but I noticed zero change with that last firmware update (other than G-Sync being automatically activated after a clean driver install rather than having to be activated/forced manually for older firmwares --- very old firmwares did have black blinking issues with G-Sync + HDR though but that was with beta drivers and stale firmware during autumn). There is still some mild brightness fluctuation during framerate spikes though (generally only noticeable on loading screens), even in SDR.

jorimt wrote: ↑

12 Feb 2020, 09:37

Even with an RTSS limit? If so, that does seem atypical, unless the frametime was micro-spiking near constantly in that instance, which I find unlikely from your description.

I can't remember if I used RTSS or the in-game limiter (but I changed it on the fly, so it wasn't the driver limiter). I think it was the in-game limiter. But that game is a bit jittery in general. I shall try this again with a different game (based on a different engine).

poppe wrote: ↑

12 Feb 2020, 10:04

Probably their new DCH drivers that was wonky. Didn't autocap FPS in neither CSGO or Apex Legends. Reinstalled with standard drivers instead and it works.

I guess "clean" installing the same version would have produced the same result.

janos666 wrote: ↑

12 Feb 2020, 11:01

My experience says otherwise. Frostbite3 based games in DX11 mode never seem to respond to LLM's queue manipulation (judging by the obvious effects of the renderaheadlimit dev.console parameter changes but no apparent effects of LLM) but the fps auto-cap of Ultra (usually) works correctly.

There you go then. I admittedly don't play enough with NULL's auto capping behavior to speak on this with 100% certainty, thus the "Could be wrong on this specific point though" in my last post.

janos666 wrote: ↑

12 Feb 2020, 11:01

I can't remember if I used RTSS or the in-game limiter (but I changed it on the fly, so it wasn't the driver limiter). I think it was the in-game limiter. But that game is a bit jittery in general. I shall try this again with a different game (based on a different engine).

Probably that specific game/in-game limiter then. And again, it doesn't mean the tearing you're seeing with G-SYNC + V-SYNC "Off" is causing V-SYNC input lag with G-SYNC + V-SYNC "On," just that the V-SYNC function is having to compensate alignment of more frames than it would with, say, an RTSS limit, and/or in another game with more stable frametime performance.

jorimt wrote:

janos666 wrote: ↑

12 Feb 2020, 09:03

What I am wondering about if it's normal to have tearing with a low fps cap and G-Sync without V-Sync. When I testes this, I had to go down from 120 (for 120 Hz) to 60-80 and some tearing still remained (always very close to the bottom of the screen, in the HUD area).

Even with an RTSS limit? If so, that does seem atypical, unless the frametime was micro-spiking near constantly in that instance, which I find unlikely from your description.

Isn't that typical of G-Sync without V-Sync?

1000WATT wrote: ↑

12 Feb 2020, 11:13

Isn't that typical of G-Sync without V-Sync?

During frametime spikes (from asset loads, etc), yes, typical. But tearing being seen with framerates well within the G-SYNC range (say, 60-80 FPS @120Hz) when there aren't frametime spikes occurring, no, not typical.

It usually means the given game (or its limiter) has very sporadic frametime performance.

The game from earlier was DA:I (Frostbite3) but it was always jittery (that's why I keep it around for testing, I wonder if I will ever have a PC which can run it without stutters ).
Today, I tested this with Half-Life 2 (last steam vanilla version). I was running in parallel with a metal fence which resembled a dynamic spectrogram when I managed to stop my eyes from tracking the motion: the dark bars become pale gray bars in motion (due to motion blur) but appear partially darker gray lines between the bottom of the screen and the tear line(s) (probably due to appearing for about twice as long in the same position). The tier lines are always close to the bottom of the screen (slightly above the HUD's bottom with 120fps limit, mostly below the HUD with 117, almost at the bottom with 113) and disappear around 108 fps. I need an RTSS limit of 108 or an in-game limit of 109 which RTSS then measures as 107. With these numbers there is may be one tiny hiccup really close to the bottom in every few 10-20 seconds. An in-game limit of 110 which measured as 108 was close to the RTSS 108 result but not as great (those small hiccups were not so rare but relatively still far and few).

janos666 wrote: ↑

13 Feb 2020, 18:45

I need an RTSS limit of 108 or an in-game limit of 109 which RTSS then measures as 107. With these numbers there is may be one tiny hiccup really close to the bottom in every few 10-20 seconds. An in-game limit of 110 which measured as 108 was close to the RTSS 108 result but not as great (those small hiccups were not so rare but relatively still far and few).

Yeah, while the basic recommendations remain the same across VRR implementations (VRR + V-SYNC "On" + minimum -3 FPS limit), it is possible certain non-G-SYNC module software variants of VRR are "looser" in their control of frametime management from frame to frame. This just means said variants probably need the V-SYNC option more (and more often) to prevent tearing within the VRR range than a G-SYNC module does.

Again though, even with any possible increase in drift in these instances, with VRR + V-SYNC "On" + an appropriate FPS limit, it shouldn't be enough to knock the display out of the range into sustained V-SYNC behavior, so long as the given display supports LFC, that is.

Hey @ jorimt - What games do you play and what settings do you have your monitor at? I just got the same one and don't know anyone else with it to ask.

Thanks if you answer.

spacerocktraveler wrote: ↑

19 Mar 2020, 20:06

What games do you play and what settings do you have your monitor at?

Lately, mostly SP games when I have the time; Black Mesa and Hollow Knight atm.

As for monitor settings, I'm a bit of a casual calibration enthusiast, so my settings would not be popular for the majority, and could be considered boring by typical gamer standards. For instance, I calibrate all of my displays to 100 nits ("Brightness 15" on the monitor), primarily because I also need this monitor to be color/luminance correct for work unrelated to gaming.

Contrast is set to the default "50", and all the extra settings are disabled. Colour Temp is set to "User," Saturate is at default "100," and "6-axis color" is also at default. Calibration was done with an i1Display Pro + DisplayCal software, and targets a 6500k, 2.2 gamma, 100 nit sRGB standard.