Requesting Scanline Sync Tutorial

Hi there guys,

I recently updated Rivatuner to the latest version and noticed the new Scanline Sync feature I've been reading about round these forums.

I Googled around for awhile trying to find a tutorial for setup, but -- after digging through a couple forums there, I'm a bit lost on how to get this to work correctly.

For example,

1) What value do I enter into the Scanline Sync field in the Rivatuner User Interface? (The one set to 0 by default and positioned just beneath the framerate limiter)

2a) What do the "Flush" options mean? I read in other forums that you could set a value (not sure where) to 0, 1, or 2 for full flush or just making the tear move to a less noticeable part of the screen, but I'm not really sure what that means or where to do this.
2b) Can this value be set on a game-by-game basis? Would be great to set this to highest value for games with low GPU utilization while keeping it at another value as default based on what I've read.

3) Is there a way to use Scanline Sync at 30 fps? Traditionally the approach there has been 1/2 Refresh Double Buffered V-sync then framelimiting to 0.01-0.1 beneath monitor refresh/2 + max-prerendered frames forced to minimum, but I'm not sure how to target 30 with Scanline Sync or if it's even possible

Anyway, sorry for the trouble or if I missed an actual guide that's already been posted there, I'm just sorta at a loss for how to begin experimenting with this new feature and any help would be really appreciated.

Thanks for your time.

 

@RealNC @CaptaPraelium @mdrejhon

Sorry for any trouble -- thought I'd tag you guys since I saw you comment previously in other Scanline Sync related threads.

 

A few things first:

Scanline sync replaces the normal FPS limiter. If you set a non 0 value in scanline sync, the FPS limiter value is ignored.

For scanline sync to work correctly, the game needs to run vsync OFF. That means either just plain old vsync OFF or fast sync. (Fast sync will work because it runs games with vsync OFF.)

OK, so now as to how to use it, you need to enter the scanline RTSS should try to sync the FPS limiter against. Using "0" is special and means "disable scanline sync." We'll call it "s-sync" from now on because I don't want to have to type the word "scanline" over and over again

The most useful way to use s-sync is to use a negative value. RTSS interprets this as an offset relative to the last scanline in your current monitor resolution. The goal of s-sync is to give you a way of syncing the FPS limiter against a scanline that is not visible. At 1080p, you have 1080 visible scanlines, plus a couple dozen more that are invisible. If you sync against an invisible one, that means tearing will be invisible. If the total amount of scanlines is 1130 for example, if you enter "-50", then you are trying to sync against scanline 1080, which is the last visible one. This is not perfect however, and in reality RTSS will be only able to sync against a scanline greater than the one you specified. So you need to experiment. -20, -30, -40, and so on, until you see the tearline disappear off the bottom of the screen.

The flush option makes s-sync more accurate. Without flushing, syncing can be very erratic and jittery. The tearing will probably not be located around the target scanline, but will jump up and down seemingly at random. Flush will make it more accurate. "1" is only available in DX 10, DX 11 and OpenGL games. It's very fast but can be less accurate. "2" also works in DX 9, DX 12 and Vulkan games, but is slower and requires a stronger GPU to work without stutter. If you use flush=1 in a DX9/12 or Vulkan game, it's treated as flush=2.

Yes, you can do "1/2 s-sync", by clicking the "scanline sync" button until it says "scanline sync x/2". This will cap your FPS to half your refresh rate. The "x*2" setting will do the opposite, it will cap to double your refresh rate.

If your GPU is not fast enough, or the game is too heavy and you can't get the tearing to be hidden, you can instead use fast sync in the nvidia panel, and sync against scanline "1". This will have more input lag (because you're syncing against the first scanline instead of the last one), but this will allow fast sync to hide the tearline. If you try to sync against a higher scanline, input lag goes down, but the possibility of fast sync stutter will increase.

 

Thank you very much -- that was all really helpful! I'll start trying to experiment with the values then.

 

Is using the fast sync method you describe here compatible with scanline sync x/2? (So I set fast sync on in nvidia inspector, set scanline sync x/2 = 1 and set flush = 1 in the framerate section of the game config file?)

The reason I ask is because I'm trying to cap my framerate at half refresh and the low lag vsync method doesn't seem to work for me (I always seemed to get fps over 1/2 hz). I'm playing on my TV with a controller and want to crank everything to Ultra detail. I was just using scanline sync x/2 = -1. My GPU is usually only hovering around 50% with this configuration and it looks really great on my PC but on my TV which is connected through HDMI I'm getting some noticeable tearing as well as horizontal lines that start at the top of the screen and scroll to the bottom of the screen (and repeat this pattern) as I pan the camera around in game...

 

@rob151515

Fast sync is compatible with x/2 scanline sync. Just use "1" as the target scanline and see how it runs.

 

@RealNC

Oh, so I seem to have gotten the Scanline Sync feature working (it's great -- even at 30 fps), but I have one more question based on your explanation above.

You mention setting the Scanline Sync field to a negative value like -20 or -50 for example.

I noticed when I set the value from -25 to -50 to -60 and so on that the placement of the screen tear moved upwards on the screen (around the middle at -25, around the top at -50 and off the screen at -60).

You mention (if I understand right) that syncing to some scanlines can result in more or less latency than others. Suppose instead of moving the tear UPWARDS with negative values, I moved it DOWNWARDS off the screen with higher values (I assume values like 1080 + 25 or + 50 for example).

Would that result in lower input lag than the negative approach? Or would it result in more input lag? Or the same input lag?

-60 seems to hide the tear completely for me on stock Rivatuner 7.2 settings and using 30 fps (refresh over 2), but I'm curious if there's more I can do here to get latency down. No problem if not of course, I just wanted to double check and make sure I understood everything you explained above correctly there.

Thanks so much for your time with all this, it's really helpful.

 

Thanks I'll do some testing.

 

@StephenEnzor

It makes no difference whether you use negative or positive values. They mean the same thing. If your resolution has 1100 scanlines total, then -60 and 1040 mean exactly the same thing. The reason why negative values are more useful is because you don't have to know how many scanlines your screen resolution is using. All you need is to say "40 scanlines before the bottom one, whatever that is" by using -40.

Also, input lag gets lower the closer to the bottom of the screen the tearing is. Note that if you move the tearline past the top of the screen, that just means it wraps around to the bottom. The extra invisible scanlines are at the bottom, not the top. When you reach scanline 1, moving it one more scanline up just wraps it to scanline 1100.

The tearline position depends on the load the GPU is under. If the GPU has lower than about 50% load, the tearline will be quite stable. As load increases, it will start to move around, unless you use flush 1 which makes it a bit more stable, or flush 2 which makes rock solid and completely fixed in-place.

If your GPU load is too high and can't get a stable tearline that's hidden near or past the bottom, then you can use fast sync instead and sync to scanline 1.

 

(Replying to myself here just to clarify that in a more visible manner.)

That statement is only true when using fast sync. With normal vsync OFF, moving the tearline closer to the bottom does not impact average input lag, it only changes the input lag difference between top and bottom of the screen, which doesn't really matter. All you want is, if possible, make the tearing only happen near the bottom so it's not visible.

With fast sync, if tearing would happen at the top, you get more input lag overall. Tearing of course doesn't happen with fast sync, but if it would, then the further up the screen it would be, the more input lag there is. So using "1" as the scanline value will have more input lag than trying to use a value near the bottom (like -30 or something like that.) However, the extra input lag acts as an anti-stutter buffer. If you use fast sync with a scanline target that is close to the bottom, then missing that scanline means fast sync will produce a stutter.

 

@RealNC

Thank you very much for explaining all of that, it's helpful.

Alright then -- currently I'm using the Flush value = 1 (Default out of the box with 7.2 iirc) and I've only tested the feature in DOOM (2016) so far using Scanline Sync/2 with the Scanline Sync value set to -60.

I'm not using Fast Sync (just Vsync OFF in conjunction with the Scanline Sync) and, in the case of DOOM at least, this seems to result in 0 tearing 99% of the time -- the only exception I've seen being occasionally when I'll get a rare framedrop -- then tearing creeps into the top of the frame before returning to normal.

I mostly just wanted to verify that which scanline I track didn't have an input lag difference so it's good to know in my case at least (no fast sync) moving the tear up off screen should result in the same input lag as moving it down off the screen since both just loop round to the other as I'm understanding you.

Thanks again, this was really helpful for me.

 

Hm. I thought flushing is disabled by default (0) unless you explicitly enable it.

Correction to what I said earlier: flush=1 is only supported in DX10, DX11 and OpenGL. If you use it in a DX9, DX12 or Vulkan game, then flush=1 is actually treated as flush=2.

So if you get performance problems in Doom in Vulkan mode, try OpenGL and see if that actually works better.

 

@RealNC

Huh, that's odd -- I didn't change the Flush value in the Global file. I went in to manually edit it, but it was already set to 1 after I updated my Rivatuner to 7.2.

What does a flush value of 0 do then? I noticed above you said it could result in jitter/erratic, but in practice does that simply mean lots of tearing?

So far I've only tested RAGE (not sure if it's opengl or dx9 or what) and DOOM (OpenGL) where a value of 1 seems to work almost flawlessly for DOOM, but RAGE (with flush still set to 1 in the Global file) has a rather erratic tear that the best I can do is get it off screen "sometimes" while the rest of the time the tear creeps into either the top or bottom of the frame. Occasionally, there's a big tear in the center, but that'll only be for a split second and much of the time there's no tearing and the game looks fine.

I wish there was a way to manually set 0, 1, or 2 for each individual game's profile. Would be nice if the flush was an option underneath the Scanline Sync/FPS limit options in my view.

 

Yes. With syncflush=0, tearline positioning can be very jittery. syncflush=1 is the recommended value, but can introduce performance issues in DX9, DX12 and Vulkan.

The Afterburner OSD will tell you the API. It's displayed next to the FPS count.

Yeah, scanline sync requires the GPU to not be loaded too much. If it has too much load, scanline positioning becomes more and more erratic.

You can. Just add SyncFlush=N to the game's profile in the [framerate] section. If the game doesn't have a profile, just create one by running the game, then hold shift and click the "add" button. Select the game from the list. This will create a profile.

 

Thanks a lot, that's very helpful for me.

 

Seems to be working quite well thanks. Only issue I've noticed is that when I pan the camera around in game it seems to periodically drop a frame causing a sort of consistent small hitch when turning 360 degrees. Is there anyway to address this? Scanline Sync /2 without fast sync on doesn't seem to exhibit this same behaviour...

 

That's the nature of fast sync, I'm afraid. You can try syncing near the bottom of the screen instead with something like -50, -100 or -150 and see if that helps, but I doubt it.

 

Ok no worries thanks, appreciate the help!

 

Are there any hard numbers out there for how much input lag is affected by the various scanline settings?

Also, any recommendations for settings for capping to 30 fps, reducing tearing, and having input lag as low as possible?

I've found that if I want a 60 fps cap, a simple RTSS cap + AMD's enhanced sync does the job (seemingly less input lag compared to using FRTC + Chill too). However, enhanced sync doesn't work at 30 fps, and I'd prefer not to use normal V-sync if possible. Is the scanline value necessary to hide the tear line going to vary between games a lot? I noticed that the scanline sync value that worked for Oblivion isn't working as well for Metro Last Light. Also, is scanline sync gonna add a lot of input lag if it's anything besides 0 anyway? How would that compare to how much V-sync adds?

 

@belmonkey

Scanline sync means vsync OFF. So there's no added latency. You will get the same latency with scanline sync as you do without it, at the same FPS limit. As an example, if you use RTSS to cap to 60FPS and get a total latency (button to pixels) of 30ms, then using scanline sync instead will also give you 30ms. Nothing has changed. The only thing that changed is the position of the tear line.

So scanline sync is just a different mode the RTSS limiter operates in. In normal mode, it syncs against time; if you enter "60", that means it syncs each frame to an interval of 1000/60 milliseconds (16.7.) In scanline sync mode, it syncs against a target position on the display; if you enter "1", it will try and sync against the first row of pixels on the display. Nothing actually changed in the FPS limiter itself, so in both cases, latency is the same. And it doesn't matter which scanline you try to sync against. Scanline 1 (first row of pixels) or -1 (last row of pixels), you will get the same latency, just the tearline has moved.

However, when using enhanced sync (amd) or fast sync (nvidia) instead of just vsync OFF, then there is a latency difference between which scanline you sync against. The closer to the bottom of the screen RTSS will sync against, the less latency there is. At 60Hz, if you can sync at the very bottom, you'd get 0ms of added latency. At the very top, you'd get 16.7ms of added latency. This is because enhanced sync will hold back the frame for up to 16.7ms.

However, using enhanced sync with scanline sync is only useful if you can't actually have accurate scanline syncing. If you get random tearing and can't keep it fixed to the bottom of the screen, that's when you'd use enhanced sync. In that case, you need a safe "buffer" for all that tearline jitter, so you'd just sync against scanline 1 in this case. Trying to sync closer to the bottom with all that jitter means enhanced sync will produce stutter, as missing the bottom of the screen deadline will make enhanced sync hold back the frame for another 16.7ms (33.3ms total.)

As for the target scanline varying between games, yes, that is common. In fact, it can vary in the same game, depending on the GPU load in the current location. Or if you crank graphics setting up and the GPU gets more load. With scanline sync, it's best to stay below 50% GPU load. At least that's my experience on nvidia. If you get close to about 70%, you need syncflush=2 to keep the tearline stable. But it might stutter the higher GPU load gets.