RTSS Feature Idea: GPU Load Based Framerate Limit

Everything about displays and monitors. 120Hz, 144Hz, 240Hz, 4K, 1440p, input lag, display shopping, monitor purchase decisions, compare, versus, debate, and more. Questions? Just ask!
Post Reply
shamelesscookie
Posts: 2
Joined: 16 Oct 2018, 08:42

RTSS Feature Idea: GPU Load Based Framerate Limit

Post by shamelesscookie » 16 Oct 2018, 08:53

So, RTSS is commonly used by Twitch streamers running Windows 10, as (for reasons unknown to me) a 99-100% GPU load prevents OBS capture software from being able to render a full 60fps scene. Just look at everyone having the issue: https://www.google.com/search?hl=en&q=o ... gh%2060fps

This apparently wasn't an issue on Win7, but with Win10, the only way to prevent this is to limit framerate with something like RTSS to keep GPU load < 90% and thus able to render the scene in OBS for encoding. This is fine, except it's also common for Twitch streamers to want to play the latest games on high refresh GSYNC monitors (144Hz+) at high framerates. Even with the most powerful hardware, the latest games can fluctuate between 80-150fps depending on what's happening on scene. That means that in order to make sure the GPU is NEVER above 90%, these streamers have to cap framerates down in the 60-70 range, even though they could be getting well beyond that the majority of time.

Enter my idea: A dynamic framerate cap set on-the-fly by RTSS based on GPU load... so when GPU load spikes over 90, the framerate limit drops in order to keep usage down. This could be in addition to the traditional framerate limit that we use to eliminate tearing and such.

So, an ideal setup could be, for a 144Hz monitor:

- Hard framerate limit of 140
- GPU load-based limit of 85%

I have no idea if this is possible, or if the hardware monitoring polling is fast enough to adjust and apply framerate limits before the GPU spikes so high.

Any thoughts? Should I share this idea elsewhere? I came here because this community has the best advice for framerate limiting and such.

Thanks!

User avatar
RealNC
Site Admin
Posts: 3737
Joined: 24 Dec 2013, 18:32
Contact:

Re: RTSS Feature Idea: GPU Load Based Framerate Limit

Post by RealNC » 16 Oct 2018, 13:12

SteamGitHubStack Overflow
The views and opinions expressed in my posts are my own and do not necessarily reflect the official policy or position of Blur Busters.

User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: RTSS Feature Idea: GPU Load Based Framerate Limit

Post by Chief Blur Buster » 16 Oct 2018, 14:54

I have collaborated with Unwinded (RTSS author) in the Guru3D forums.

This could be a good feature, to have an automatic mandatory GPU load cap, e.g. a 20ms frametime forces a mandatory 2ms sleep. And to d this in a way that doesn't add appreciable lag.

Ideally, in the future, there should be a "GPU priority" concept where streaming renderers are always higher priority than game renderers. But in the abscece of this, a dynamic "cap on GPU load" would be a great idea.

This thread is being moved to General.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

shamelesscookie
Posts: 2
Joined: 16 Oct 2018, 08:42

Re: RTSS Feature Idea: GPU Load Based Framerate Limit

Post by shamelesscookie » 16 Oct 2018, 19:05

Thanks for moving the thread and linking to Guru3D. I've started a thread here: https://forums.guru3d.com/threads/rtss- ... rs.423488/

I'm not sure of the best way to trigger the throttling ONLY when GPU load is high without using GPU load itself as the trigger. Is there a way to detect load spikes without having to poll hardware? (Or is polling hardware a viable option at a frequency high enough to enable this kind of a feature?) Maybe use the delta in frametimes to infer load spikes? I wouldn't want to slow down the GPU if it's producing, e.g. 20ms frames at 60% usage, because that's fine. It's when it produces 20ms frames at 99% usage that this becomes an issue.

User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: RTSS Feature Idea: GPU Load Based Framerate Limit

Post by Chief Blur Buster » 17 Oct 2018, 11:28

shamelesscookie wrote:Thanks for moving the thread and linking to Guru3D. I've started a thread here: https://forums.guru3d.com/threads/rtss- ... rs.423488/

I'm not sure of the best way to trigger the throttling ONLY when GPU load is high without using GPU load itself as the trigger. Is there a way to detect load spikes without having to poll hardware? (Or is polling hardware a viable option at a frequency high enough to enable this kind of a feature?) Maybe use the delta in frametimes to infer load spikes? I wouldn't want to slow down the GPU if it's producing, e.g. 20ms frames at 60% usage, because that's fine. It's when it produces 20ms frames at 99% usage that this becomes an issue.
Delta in frametimes can be a suitable approximate stand-in for GPU load. That would be very easy to mathematically derive an automatic frame rate capping.

When you post at Guru3D, be very careful and very specific/clear. They are very busy and they prefer proof/evidence based information. Guru3D is a wonderful place but is not as newbie-friendly as Blur Busters Forums.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: RTSS Feature Idea: GPU Load Based Framerate Limit

Post by Chief Blur Buster » 17 Oct 2018, 12:07

I have taken the time to read the thread, and I've tagged Unwinder to look at the thread.
Chief Blur Buster wrote:Chief Blur Buster here.

Maybe I can help because I have an understanding of the problem, and what modifications are needed to RTSS to help a lot of streamers. I was the person who suggested to Unwinder to add the Scanline sync feature.

What I believe that ShamelessCookie is asking for is a special feature in RTSS to automatically prevent GPU load from going above 90% (or a predefined threshold trigger).

Basically when this proposed modified RTSS mode is enabled -- if a frametime takes 18.5ms -- RTSS should forces a mandatory 1.85ms CPU-busywait sleep until the next frame render. Basically if framerate is maxing out 50fps at 99% GPU, the mandatory ~10% autosleep would result in an approximately 9/10ths of 50fps = ~45fps. Basically, mandatory sleeps that are percentage-proportional to the previous frame rendering time. This can help GPU load to stay below a threshold.

This plummets the GPU load, while increasing CPU load a little (because of precision busywait loop on CPU -- but Unwinder is also using intentional busywaits for scan line sync due to microsecond accuracy requirements)

This new RTSS mode would probably be relatively simple to implement as (A) a configuration-file-only change specific to streamers and (B) take only a few lines of code.

This could be trialled in a beta-only copy of RTSS, to prove/disprove whether this is a massive problem-solver -- for streamers playing games -- playing games that fluctuate massively in frametimes -- causing those GPUload-spikes above ~90% to cause dropped streamable frames.

This could be implemented as a blocking sleep before returning from Present(). Certainly this will add a tiny bit of lag (most of the time, sub-millisecond lag for 100fps+ operation). But successful streaming at 110fps is superior to heavily framedropped streaming at 120fps.

Games often vary hugely from 40fps thru 200fps, so anytime there's a big shooting fight and there's a temporary GPU load spike (99%), this cause framedropping during streaming. By forcing a blocking CPU busywait before returning from a Present() or glutSwapBuffers() that's proportional to the previous frametime, the streaming features notices the GPU is idling and grabs the GPU to process the frame.

Essentially.... You trade a bit of lag (sub-millisecond), a bit of lower framerate (e.g. 1% or 5% or such), in exchange for perfect streaming with zero framedrops -- no matter how much your game framerate fluctuates.

And would perform SO much better than other drastic solutions (like capping to the bottom dip, e.g. capping at 40fps because your framerate fluctuates 40fps-200fps....UGH.... :D ).

As you can see, this Hail Mary solution is what they're doing today -- making huge sacrifices like this by being forced to cap just below the bottom of your framerate valleys!. So even (figuratively speaking, from the streamer's perspective) -- Compared to a massive hobbling of your framerate, even just a mere optional 1ms busywait ends up being a massive upgrade almost akin to buying 3 generations newer GPU -- For those streamers who do not want dropped frames.

Viewers of streams complain of stuttery streams during the "heated moments" of firefights that they visited the stream for. That's what happens; GPU load spikes, stream compressor fails to catch all frames, and the exciting moments are not enjoyed by stream viewers.

Essentially, a defacto GPU-load-adapting framerate cap -- as a very simple autosleeper that's proportional to the previous frametime.

Even if the streamer is only transmitting 60 frames per second when playing at 100fps-200fps. Stream-framedrops are still happening in Windows 10 that never happened in Windows 7

Alternatively -- even simpler idea -- it could be a configurable fixed busywait (e.g. 0.5ms always) rather than an adaptive busywait. Since the stream renderer probably has a fixed threshold, and only needs a fixed time per frame to compress it. This is even simpler mod to RTSS). So you'd have negligible framerate decrease (0.5ms increase to frametimes), but sufficient microscopic CPU busywait to cause the GPU to focus on stream compression task. Obviously, 0.5 would be a value, but tweakable until the streaming worked flawlessly. (e.g. 0.25ms, or 1ms, 2ms or whatever busywait is required to force GPU idle time between frame renders).

Other techniques (other than busywait) can also be used, if more appropriate (e.g. dynamically free-floating framerate cap that that avoids GPU from exceeding a percentage threshold). I only simply suggest initially trying the busywait technique because it's quick-and-dirty minor-code-change test to at least validate one RTSS beta on whether it helps streamers...

Possible secondary purposes: This advanced-user-only or betas-only INI config feature can in theory be a a useful developer engineering/debugging feature, because anecdotally, some games suddenly gain mysterious input lag whenever GPU-bottlenecked (even when not using VSYNC ON). Experimenting with this forced GPU-load-capping feature can, in theory, help advanced tweakers debug whether the game has a strange block occuring on GPU load (despite running in uncapped modes such as VSYNC OFF or Fast Sync, etc).

I know Unwinder is reluctant to add new INI options because newbies copy and paste them all the time without understanding. You can even name the option "AddLagPerFrame=0.5" (fixed ms) or, say "AddLagPerFrame=10%" (perc) to discourage everyday users from randomly copy and pasting it into their RTSS INI files. To reduce/prevent those newbie-complainer side effects that go with advanced options. Twitch streamers will be able to study this option and find it's a lesser-of-poison to add 0.5ms lag per frame (or calibrated value) to get perfect frame-drop-free streaming, while most everyday competitive players will just say "ugh, no lag, won't use it".

Yes, this is kind of a workaround for a Windows 10 defect to streamers, but it would be a huge boon to many high performance streamers. Yes, I know it's hairpulling; I know, I know, I've been there.

This just sounds so deceptively simple for an INI-only option -- so minor a programming modification -- probably mainly consisting of one-line to three-line mods in approximately three places -- that can be trialled in a beta-only RTSS -- yet appears potentially to a huge windfall problem-solve for high-performance twitch streamers.

Certainly -- with busy people -- it's up to the key RTSS authors (@Unwinder) but hopefully I've explained the purpose of this better?
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

Post Reply