Adaptive Sync behaves similarly to RTSS scanline sync, although RTSS scanline sync can have lower lag.Amoda154 wrote:Yeah i know
But tearing happens randomly in the game, like in assassin creed odyssey which is a demanding game, tearing occurs in dense areas. I tested gpu usage which stays below 60%.
What is the cause of random tearings happening?
It seems like same behavior as adaptive sync , tearing occurs in dense areas where system cannot sustain certain fps.
Easy Fix:
You can solve this by combining NVIDIA Fast Sync (or AMD Enhanced Sync) simultaneously with RTSS scanline sync if you follow these instructions: HOWTO: Combining RTSS Scanline Sync with Fast Sync. You essentially have to pre-calibrate first.
Advanced Explanation: Why this happens:
<technical>
Here, I have to explain the science of tearing: why tearlines occur where they occur.
This is because of ultra-precise timing required to hide tearlines in the blanking interval between refresh cycles. (Push tearline below bottom edge of screen, but before tearline reaches the top edge of next refresh cycle). VSYNC OFF tearlines are rasters, and coincide to the position of the display output's raster scanout.
Now, video outputs have a scanrate associated to it (number of pixel rows output per second, including the dummy scanlines of the blanking interval). All GPU outputs transmit 1 pixel row at a time continually, to deliver a refresh cycle. That's a raster-based scanout. It's top-to-bottom. You see this number as "Horizontal Scan Rate" or "Horizontal Refresh Rate" when you open up NVIDIA Custom Resolution or ToastyX Custom Resolution Utility. It's often in thousands per second, e.g. 67.5 kilohertz scanrate for a 1080p 60Hz signal.
Tearlines exists because of the scanout mechanism, you're essentially "splicing" a new frame into the existing refresh cycle, mid-scanout. The tearline exactly corresponds to the current raster position of the display's scanout at the time a new framebuffer is presented during VSYNC OFF. (You game programmers... That's the API call of Present() in Direct3D, or glutSwapBuffers() in OpenGL. The position of the tearline depends on the timing of that API).
This is what happens with Quake Arena at framerates approximately 3 times the refresh rate. As the display scans out, you're continually splicing a new frame into the existing scanout position of the graphics output. Tearlines are raster-based.
If you're old enough to remember analog TVs with a VHOLD adjustment, the blanking interval is that black bar between images when the TV picture rolls. A bigger VBI means the bar is thicker, and a smaller VBI means the bar is thinner. It's often just dummy black lines as hidden temporal padding (on the video cable) between refresh cycles. Even digital cables too. DisplayPort, HDMI, etc. This is where hidden tearlines go if RTSS scanline sync is perfect.
If the blanking interval is only 45 scanlines, and the scanrate is 67500 scanlines per second, that means the game must have an impeccable timing precision of 45/67500th of a second to successfully hide a tearline between the refresh cycles! It's miraculous we can do that nowadays, but frametime spikes causes major problems with this -- even a single disk access can disrupt this. So a momentary tearline can appear. At higher refresh rates, even a 10 microsecond delay can mean the difference between a hidden tearline and a visible tearline!
The size of the blanking interval is (Vertical Total) minus (Vertical Active Resolution) in the custom resolution. Most 1080p modes have a Vertical Total 1125 (VT1125) which means (1125 - 1080) = 45 scanline blanking interval.
To successfully hide a tearline in a 45-scanline blanking interval, your error tolerance is:
1080p 60Hz .......... 67.5 KHz scanrate .......... 45/67500th of a second error margin
1080p 120Hz ........ 135 KHz scanrate .......... 45/135000th of a second error margin
1080p 240Hz ........ 260 KHz scanrate .......... 45/260000th of a second error margin
Ouch. Such incredible precision to successfully hide a tearline between refresh cycles!
Needless to say, that's why you want your GPU to be framespike-free. To be framespike-free you typically want to keep your GPU below 50%-ish, with only brief forays into 60-75% during dense moments. However, if you hate the occasional tearing from the frametime spikes, just re-calibrate RTSS scanline sync for a non-VSYNC-OFF mode to make it compatible with NVIDIA Fast Sync / AMD Enhanced Sync.
Expert Trick: (Very few users bother). People familiar with custom timings & resolution can use Large Vertical Totals to hide tearlines better and reduce input lag further (the "Quick Frame Transport" effect, found in HDMI 2.1 spec, but works on any cable if the display supports large blanking intervals!), though that is only worthwhile if you're able to get large margins with large vertical totals. For more information on how to do this, see the bottom section of this HOWTO. This can be useful if you're already doing Large Vertical Total for a different reason such as strobe-crosstalk reduction (cramming LCD GtG into VBI), so you might as well hit two birds with one stone, e.g. the VT1302 trick with the LG 240Hz monitor, or if you're using Strobe Utility with a BenQ monitor.
</technical>
