MSI AB / RTSS development news thread

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!

 

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.

 

That works fine, as long as it's there in some capacity.
Thanks a lot!

 

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.

 

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.

 

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.