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)
I was wondering if I could suggest adding one feature to RTSS - a global hotkey (that works during the game) to toggle the FPS limiter on/off. The reason why something like that would be useful is that some games during some moments can behave in a weird ways because of FPS cap. It would also be helpful in older games where you can unlock the FPS - they usually work fine, but sometimes some parts of the game are bugged and require temporary FPS lock when you interact with them to avoid bugs. Here are some examples.
Dragon Age Inquisition has a weird engine mechanic where the speed of loading the game is controlled by the FPS you get during the loading screens. Even if you play at @60Hz monitor with in-game VSync enabled, the FPS on loading screen goes up to 200, so the game can load at its normal pace. Once the game loads, the FPS goes down to 60 again. If you limit the FPS to 30 or 60 with any of the external tools (including RTSS) in Inquisition, it will also limit the FPS on loading screens, which causes the game to load dramatically slow (since it cannot reach that 200 anymore). The lower the FPS, the longer loading screns are.
I think that similar thing happened in original Skyrim when people tried to lock the game at 30 FPS. The game would load a lot slower than without FPS cap. I also read that people who played Fallout 4 with high refresh rate monitors and unlocked FPS used to have (still have?) a bug where the game would get stuck after interacting with a terminal. The reason was that terminal interface was not designed to work at 90+ FPS. The solution was to ALT+TAB, open RTSS window and lock the game temporarily to 90 FPS to interact with terminal. Once you were done with the terminal you had to ALT+TAB again to disable that 90 FPS cap and play with unlocked FPS.
These are just three examples from the top of my head. A hotkey toggle for FPS limiter in RTSS would fix all these issues. In Fallout 4 you could just quickly toggle the FPS cap to avoid that terminal bug and then toggle it off once you're done. In Inquisition we could just disable the FPS cap during the loading screen with one finger tap and enable it again once the game loads. I know that it would be useful only for few problematic games, but I think it would be a great feature to have. Would something like that be hard to implement?
I must agree, the possibility to make changes to frame limiting settings and seeing results directly in real time is as good as it gets. Imagine modifying some of these without tabbing out for testing: FPS/MS Limit up/down, scanline sync settings, RTSS VS in game fps limiter, etc.
In Rainbow Six Siege the in game limiter must be set 2 fps below max Hz not to jump over, and it still tears considerably with G-Sync active. Ubisoft.
I would love to help test something like that. I believe Fallout 4 has the same engine thing as DA:I where the loading screens FPS determines how quickly loading can be done. There is a mod that unlocks vysnc in Fallout 4 just for loading screens and it makes a HUGE difference on a SATA/M.2 SSD.
Some development news:
My vacation is over (sadly) and I'm back to work. I spent these weekends on implementing support for upcoming NVIDIA cards and the first beta with initial support for new GPU architecture is ready (basic overclocking, voltage control, monitoring and fan control support), we'll upload it once the cards are officially announced.
Some more development news.
MSI Afterburner 4.6.0 beta (currently beta 7, may change on release) with basic RTX 20x0 series support is around the corner with the following changes:
· Added NVIDIA Turing GPU architecture support:
o Added voltage control for reference design NVIDIA GeForce RTX 20x0 series graphics cards
o Advanced GPU Boost control for NVIDIA GeForce RTX 20x0 series graphics cards. Extended voltage/frequency curve editor on GeForce RTX 20x0 family graphics cards allows you to tune additional piecewise power/frequency floor and temperature/frequency floor curves. Control points on those new curves allow you to control GPU Boost power and thermal throttling algorithms more precisely than traditional power limit and thermal limit sliders
o Hardware abstraction layer has been revamped to provide support for multiple independent fans per GPU due to introducing dual fan design on reference design NVIDIA GeForce RTX 20x0 series graphics cards and due to introducing native dual fan control in NVAPI. Both fans of NVIDIA GeForce RTX 20x0 can be monitored independently in hardware monitoring module now and can be controlled synchronically in manual mode
· Hardcoded voltage/frequency curve clock multiplier implementation has been replaced with heuristic multiplier detection in order to provide unified voltage/frequency curve control implementation for NVIDIA Pascal and newer NVIDIA GPU architectures
· Improved realtime voltage/frequency curve editor GUI scaling. Now GUI is scaled property when adjusting skin scaling with open voltage/frequency curve editor window
· Added Monolithic Power Systems MP2888A voltage controllers support to provide compatibility with future custom design MSI graphics cards
· Added thermal offset for CPU temperature monitoring on AMD Ryzen 7 2700X processors
· Pagefile usage” graph in hardware monitoring module has been renamed to “Commit charge”
· RivaTuner Statistics Server has been upgraded to v7.2.0 (currently beta 4, changes list were documented in this thread earlier)
Public beta is hopefully expected in the end of this week. That's everything related to new generation of GPUs, which I can squeeze from RTX 20x0 cards with remote debugging and without having it installed here. I expect my card to arrive in the beginning of September, then probably we'll add some more RTX 20x0 related features to AB. NVIDIA introduced new overclocking scanner API for these cards to allow vendors to provide automated overclocking, it sounds rather promising but I'll need to play with it a bit myself to decide if it is reliable and worth being supported in MSI AB.
I presume that it is not possible to include this excellent new feature for previous hardware (10x0 for example)?
Probably not, but I can dream
It sounds like nvidia are allowing us to get 'under the hood' of GPU Boost more with the new cards.
New API requires R400 or newer driver series, I don't have them installed on my GTX 10x0 rig so I cannot say for sure and comment backward compatibility with it. But I'd guess that power/frequency and temperature/frequency curves will be editable on RTX only.