Discussion in 'MSI AfterBurner Overclock Application Discussion' started by Unwinder, Feb 20, 2017.
Similar to framerate limit, 0 disables it.
Aha. Ironically, that will be okay to end users, but may confuse programmers (since raster veterans know scanline #0 is top edge of screen). Ha ha, make it easy for users but confuse me, clever! Personally, just display "OFF" whenever trying to display a "0" there -- only if that's an easy 1-line fix.
It's actually easier when one understands now-obscure "raster programming" tricks back in the 8-bit days.
It does help to understand that 2D imagery (refresh cycles) are serialized into 1D graphics (rows of pixels) pushed over the video cable. That's how you squeeze elephants through a drinking straw -- one pixel row at a time.
This act of serializing 2D graphics into 1D video cable wire is called "scan-out" or "scanning out".
In the olden days, 8-bit and 16-bit platforms often changed the graphics during mid-scanout using techniques such as like "raster interrupts". Whether it be the Atari TIA or the Amiga Copper. This created scrolling zones, split screens, extra sprites, more colors on same screen, or other tricks. Terminologically, a "raster" is a scan line. A "raster number", "raster register", "raster position" the current scan line number or pixel row number currently being transmitted on the video output (whether analog or digital). A "raster operation" is a graphics operation precisely timed at a raster number.
VSYNC OFF tearlines behave as rasters too, unbeknownst to many. They are essentially framebuffer splices wherever the existing scan-out position is. By knowing the scan-out position (raster number) at the instant a new frame is presented, software can successfully time the exact position of a tearline. This new RTSS capping feature allows steering the position of these tearlines to occur between refresh cycles, hiding them. Or moving tearlines to stay in an unimportant region of your screen (e.g. HUD bar or score bar).
It was not easy to achieve in the past because 3D graphics were too slow and variable, but today, we have GPUs capable of blasting 300+fps in CS:GO and other older games, and modern platforms have microsecond-accurate counters, so these scan line tricks are now much easier to achieve today when playing older games where you can channel the excess performance into creating a new low-lag VSYNC ON mode.
A good book to read is "Racing the Beam" -- https://www.wired.com/2009/03/racing-the-beam/
Whether a 1930s analog TV broadcast or a 2020s DisplayPort cable -- 60Hz, 144Hz, 240Hz, VRR -- the concept of raster scanning (serializing 2D into 1D) is essentially unchanged over the period of a century, and racing-the-beam remains possible today, as a tearline control technique and latency-reduction technique.
Here's a time-based graph of what happens at the graphics output of a GPU. Present() -- the common Direct3D API call -- is when a new framebuffer is delivered to the graphics driver to handle it.
The number of tearlines per second is typically equal to the number of frames per second (although there can be fewer tearlines if some tearlines are hidden in the VBI blanking interval between refresh cycles -- VBI is also known as a "VSYNC interval" too in terminology, and "wait for VSYNC" is a pause to that interval between refresh cycle)
Behind the scenes -- on the graphics card -- the "front buffer" is not transmitted instantly or displayed instantly to the full screen. There's a finite time to deliver the graphics to the display over the cable.
The GPU is still transmitting the front buffer one pixel row at a time at a constant rate, taking 1/120sec to finish scanning out top to bottom on a 120Hz monitor (plus a very small "blanking interval" pause between consecutive scanouts).
So during VSYNC OFF, the front buffer is always preemptible with a new frame, so you get a tearline where the new frame is spliced into the scanout position of the scanning-out process on the graphics output.
The new RTSS features simply steers the Present() to a specific scan line number (pixel row number) which allows you to attempt to hide the tearline offscreen. The tearline position roughly corresponds to the Scan Line number that you choose.
But there's often an offset (caused by things like graphics card performance) so often you want to use negative scanline indexes (i.e. -25 equals timing the Present() the time-equivalent of 25 pixel rows BEFORE the top edge of the screen).
Hope that explains the "VSYNC OFF tearlines are rasters" concept a little bit better! And the new "Scan Line" setting!
On other side, programmers and power users normally do read documentation and context help for new options unlike the majority of regular end users. And it clearly documents that 0 is disabling the setting, so it won't be a problem for those who peek in context help. Furthermore, changing that is not a trivial thing for skinned GUI implementation and do not worth the efforts I'm afraid.
RTSS 7.2.0 beta 3 is online and available for download:
Changes list includes:
- Improved compatibility with third party skins. Now you can switch between framerate and frametime limit modes in outdated third party skins having no native framerate/frametime limit switching support. Now you may click framerate limit edit field while holding <Ctrl> pressed to switch between framerate and frametime limit modes on such skins.
- Framertime limit value is no longer reset to 0 on skin change.
- Added scanline index wrapping support for scanline synchronization mode. Now you may specify negative index value to specify offset from VTotal.
- Basic scanline synchronization mode settings are now controllable from main window GUI. Now you may enable scanline synchronization by specifying non-zero target scanline index (with wrapping support) and click "Scanline sync" caption to switch between single and double scanline synchronization modes.
- Changed hotkeys for scanline synchronization control from <crap>+... tp <Ctrl>+<Shift>+...
Thanks for all the good work you're doing Unwinder. Scanline sync is the best rtss feature yet for me.
Is it possible to get scanline sync x0.5 as well for 60fps@120hz/30fps@60hz etc?
Some games don't support refresh rate changes ingame or are too demanding on the gpu for tearlingless vsync off to work at current refresh rate.
Sorry, I’m afraid that I don’t see it as an important and useful mode that worth changing main windiw skin again. Skin modifications are rather time consuming. But I can offer such mode as power user profile switch.
That works fine, as long as it's there in some capacity.
Thanks a lot!
Ok, I've added new SyncPeriods profile entry. It is ignored for double scanline sync mode, for single scanline sync mode it defines number of sync periods - 1 (e.g. if SyncPeriods=1 then synchronization is performed twice, so framerate is limited to RefreshRate/2; if SyncPeriods=2 then synchronization is performed 3 times, so framerate is limited to RefreshRate/3 and so on).
Hi! First of all I'd like to thank Unwinder for this awesome piece of software, as well as all the other contributors for providing helpful posts on the subject. I've been experimenting with a bunch of games over the past few days and playing them properly framepaced with lowered input lag on top of that is almost like discovering them again in some way. It kinda blows my mind that I spent so much time playing PC games often without looking at actual, proper smooth 60fps (or 30 for that matter). Again big thank you for what you're doing here.
Question time! Right now I'm using the low lag VSYNC ON method (-0.01 cap). The one problem I have so far is I've stumbled upon some titles (Resident Evil 6 for example) that exhibit the behavior described in the tutorial posted on blurbusters: a period of time with perfect, smooth pacing followed by 15-20 seconds of significant stutter. Is this just the nature of the beast, or is there a particular cap value or additional setting I should be looking for to alleviate this? In the end I obviously still take it over non-framepaced, laggier game but I thought I'd ask.
I think I'll keep SyncPeriods enabled for double scanline mode sync as well. This way you'll be able to use 2x scanline synchronization (so 1 sync period will be equal to 1/120s for 60Hz) then set SyncPeriods to 2 to achieve 2/3 refresh rate (i.e. 40Hz).
New RTSS beta is available for download:
- Added new SyncPeriods profile entry for scanline synchronization mode. SyncPeriods is defining number of full synchronization periods to be waited for when performing scanline synchronization. Other words, it is limiting framerate to RefreshRate/(SyncPeriods+1).
- Added tri-state skinned buttons support in the skin engine
- Now "Scanline sync" button is a tri-state button allowing you to switch between single, double and half scanline synchronization modes.
- Slightly improved VTotal calibration implementation.
- Updated context help for scanline synchronization related controls.
P.S. I'm not sure if you realize it, but you can combine single scanline synchronization mode with various scanline sync timeout settings to achieve 3x/4x/5x and so on refresh rates. For example, if you enable single scanline synchronization mode and set target scanline to 1, you're waiting for exact rasterizer position (scanline 1) before presenting each frame, i.e. get a functionality similar to traditional VSync with adjustable tearline position and reduced input lag. Then, if you edit profile and set SyncTimeout to 1, you're defining timeout as RefreshPeriod/SyncTimeout = RefreshPeriod and getting something close to NVIDIA's adaptive VSync, when synchronization is NOT performed when you're waiting longer than timeout, i.e. when the framerate drops below refresh rate. Now, if you set SyncTimeout to 3 for example, then you're defining timeout as RefreshPeriod/3. So the first frame will be synchronized to scanline 1, the second and the third frames sync will take exactly RefreshPeriod/3 due to timeout, the fourth frame will be synchronized to scanline 1 again and so on in the loop. So you'll effectively get scanline synchronized 3x refresh rate framerate.
Tried the new sync x/2 mode. It seems that using this mode slightly improves tearline positioning accuracy when using SyncFlush=0. For example, 60Hz normal sync mode has slightly worse tearline control than 120Hz sync x/2. (Both result in 60FPS.)
Combined with the lower input lag of 120Hz, I'd say sync x/2 mode is the mode to use for people who have high refresh rate monitors and want to play at 60FPS (120Hz,) 72FPS (144Hz) or 82.5FPS (165Hz).
(Note that the tearline improvement though really is very minor. The bigger benefit is the lower input lag of 120Hz or higher.)
Unfortunately, that's just the nature of the beast -- the tighter you make the cap, the longer the sustained "smooth-stutter-smooth-stutter" cycle is. It's caused by microscopic framerate capping inaccuracies. As the cap beat-frequencies the refresh rate, frametimes can jittter rapidly before/after a VSYNC blanking interval -- causing the really sustained stuttering.
Reducing this can be done by two means:
- Use a bigger difference (e.g. 0.05 instead of 0.01). At some equilibrium point, the smooth:stutter ratio maxes out and it becomes a single stutter instead of a sustained stutter.
- Or try the new scanline sync method (beam raced RTSS!) since you can get perfect frame rate match automatically. Permanent smooth and lower lag, no stutter except some occasional tearlines (unless using flushing)