RTSS Scanline Sync HOWTO

[terry98]

yeah all the time, if you don't use the color bar is difficult to identify the tearing

[Unwinder]

Did you use the frame colour indicators? Those I found to be more accurate than frame times as even with a 100% stable frame time, sometimes the frame colour indicators flickered and if I focused on the flickers instead, I got it smoother than if I focused at the frame time.

There will be a few more additional performance counters in the next RTSS in scanline sync info panel (enabled via SyncInfo = 1 in profile), which will be helpful when calibrating scanline sync settings. New performance counters include:

Sync start - index of scanline where 3D application is calling Present() and Scanline Sync implementation inside the hook starts waiting for target scanline
Sync end - index of scanline where Scanline Sync stops waiting for target
Present - index of scanline where real Present() is called after scanline synchronization
Present latency - time spent inside real Present() call

Sync end/Present counters stability are helpful to see if tearline jittering is caused by synchronization inaccuracy or GPU rendering time variations. Present counter is also helpful if you’re trying to steer tearline with a pure framerate limiter @ display refresh rate and without engaging ssync

[Chief Blur Buster]

As for increasing the total vertical, with cru I can only increase the front porche 64 pixels, more than that and the value turns red and doesn't let me save the setting.. In the amd drivers I can go up to 1195 total before the screen starts to skip frames.. damn lg hdtv xD but at least I can play nice with these settings.

Try reducing Horizontal Total to get easier bigger Vertical Totals. This helps pixel-clock-limited situations, since some bandwidth is wasted on unnecessarily large Horizontal Totals more designed for CRT tubes.

1125 is a 45-line VBI (1125 minus 1080), while 1195 is a 115-line VBI (1195 minus 1080), so your VBI is still more than twice the size, makes it easier to hide tearing between refresh cycles.

[Chief Blur Buster]

Sync end/Present counters stability are helpful to see if tearline jittering is caused by synchronization inaccuracy or GPU rendering time variations. Present counter is also helpful if you’re trying to steer tearline with a pure framerate limiter @ display refresh rate and without engaging ssync

IDEA! (Usability/Debugging):
A mode where a horizontally moving vertical bar is overlaid on game graphics (like this one) could be great for RTSS Scanline Sync. Make that a transparent overlay on top of RTSS, perhaps colored the same as the graph/framerate counter.

It's much easier to monitor tearing during horizontally panning motion, but if a game is not doing that (can't operate RTSS concurrently with the game), so adding a horizontally moving transparent vertical bar might be a great tearing-calibrator for RTSS Scanline Sync.

One could also use the colorcoded VSYNC markers, though tearing is more obvious with a moving bar than the edge-colorcoding. Having both is super-useful visual tearing-debugging indicators. However, the average layperson will find it easier and more self-explanatory (tearing familiarity) with the moving-bar test for RTSS Scanline Sync, though.

This might reduce the questions about "How do I adjust RTSS Scanline Sync?" by providing an easy tearing-visible test.

This can also help with game developers debugging precise frametime modulations (since tearing mechanics are another great way to debug all kinds of sync issues, including accuracy/inaccuracy of in-game framerate caps during VRR operation of GSYNC+VSYNC OFF).

[terry98]

Try reducing Horizontal Total to get easier bigger Vertical Totals. This helps pixel-clock-limited situations, since some bandwidth is wasted on unnecessarily large Horizontal Totals more designed for CRT tubes.

1125 is a 45-line VBI (1125 minus 1080), while 1195 is a 115-line VBI (1195 minus 1080), so your VBI is still more than twice the size, makes it easier to hide tearing between refresh cycles.

by reducing Horizontal total I managed to get to 1230 Vertical total, that's going from 45 line to 150 line VBI, I lost the 422 color settings but now I have more room to play with the tearing line.

Attached is a screenshot with the driver custom resolution timmings.

[terry98]

ok, my preferred settings no longer work with the increased vertical total... now fps are fixed to 40, after moving the syncscanlines I manage to get 60 fps 16.6ms, but it lags like every 3 or 4 seconds the latency goes up to 33.4ms and 59/58 fps.

Any idea??

BTW Chief, is there a rule for increasing the VBI? what I mean is, I normally only increase the vertical front porch while maintaining the same sync and back porch, should I increase them as well or keep doing it like that?

[Unwinder]

IDEA! (Usability/Debugging):
A mode where a horizontally moving vertical bar is overlaid on game graphics (like this one) could be great for RTSS Scanline Sync. Make that a transparent overlay on top of RTSS, perhaps colored the same as the graph/framerate counter.

Personally I use RTSS FCAT overlay as is for the same purpose, it also easily visualizes the tearline position. Besides native FCAT overlay mode there are a few alternate modes avaialable for FCAT overlay: 2 bars, 3 bars and 4 bars modes. They were actually requested by NVIDIA, they used it to visualize per-GPU frametimes for AFR rendering modes on 2-way/3-way/4-way SLI configs. I see no problems with adding one more alternate mode there - moving bar, which will do exactly what you want.

[Chief Blur Buster]

IDEA! (Usability/Debugging):
A mode where a horizontally moving vertical bar is overlaid on game graphics (like this one) could be great for RTSS Scanline Sync. Make that a transparent overlay on top of RTSS, perhaps colored the same as the graph/framerate counter.

Personally I use RTSS FCAT overlay as is for the same purpose, it also easily visualizes the tearline position. Besides native FCAT overlay mode there are a few alternate modes avaialable for FCAT overlay: 2 bars, 3 bars and 4 bars modes. They were actually requested by NVIDIA, they used it to visualize per-GPU frametimes for AFR rendering modes on 2-way/3-way/4-way SLI configs. I see no problems with adding one more alternate mode there - moving bar, which will do exactly what you want.

True! I agree FCAT analyzer works great for this! It's great!

That said, so many newbies keep asking me about RTSS Scanline Sync (PMs, DMs, social media, emails, forum, etc). I'm kinda hoping to teach them using more-familiar tools such as tearing in a moving bar. Fewer people understand tearing in static color-alternates, than tearing in moving bars, so sometimes I have to explain that the FCAT artifact is a tearing artifact.

It's easier to have a static simulated-screenshot of a tearing artifact in a moving-bar than a FCAT flicker. A picture is worth a thousand words. So training and explaining is easier with traditional tearing. So add a tearing overlay, and then writing HOWTO's will become much easier + users will more easily figure out how to calibrate RTSS Scanline Sync. FCAT analyzer is harder to explain to newbies in under 1 minute in a HOWTO.

I once tried to hire a writer to try to write an RTSS Scanine Sync HOWTO (been too busy on other projects), but it failed because even the writer couldn't figure out how to reliably calibrate it. So there's no blurbusters.com RTSS Scanline Sync HOWTO yet, just this forum thread. But I think a few extra steps of ease-improvements later -- including an easier more-user-intuitive easier-HOWTO-explain tearing test -- would probably help solve this problem.

Adding features that helps to miniaturize a HOWTO, will probably allow me to finally launch a mainsite blurbusters.com RTSS Scanline Sync HOWTO -- because I probably will have to personally write the HOWTO myself (since my remote freelancers had a hard time figuring out RTSS Scanline Sync).

Bonus: Hotkeys to realtime enable-disable force-flush would be nice too. I'd love to watch what happens to tearing + framerate (simultaneously) in realtime when that feature is enabled/disabled. It'll make it easier to watch pick-your-poison effects, and easier to explain to users the pros/cons. For the Tips/EasterEggs section at the bottom of any future Scanline Sync HOWTO.

(I'm trying to figure out how to make RTSS Scanline Sync easier to explain to users, and easier to adjust)

[terry98]

So, I remembered that my TV is 4K after all and supports up to 594Mhz so I went and created a new 1080p resolution with a total horizontal of 2050 and total vertical of 4829 with a 3749 line VBI, with this the tearing line is no where to be found xD everything is super clean and steady and I don't even need any kind of sync anymore.

Also, it took some hours of testing and could not get to work the 2nd sync scanline very well.. so I kept only one with this config:

[Framerate]
Limit=0
LimitDenominator=1
LimitTime=0
SyncScanline0=2952
SyncScanline1=0
SyncPeriods=0
SyncHotkeys=1
SyncFlush=0
SyncTimeout=0

As for the resolution the timmings are these:

Horizontal Vertical
Total 2050 4829
Display 1920 1080
F Porch 43 1872
Sync Width 44 5
B Porch 43 1872

if anybody is interested.

[Unwinder]

IDEA! (Usability/Debugging):
A mode where a horizontally moving vertical bar is overlaid on game graphics (like this one) could be great for RTSS Scanline Sync. Make that a transparent overlay on top of RTSS, perhaps colored the same as the graph/framerate counter.

Done, it is implemented in upcoming RTSS beta.
https://forums.guru3d.com/threads/rtss- ... st-5845445