Blur Busters Forums

http://blog.metaclassofnil.com/?p=715 seems to do the predictive capping that I talked about a few posts later. Have anybody tried it out?

andrelip wrote:http://blog.metaclassofnil.com/?p=715 seems to do the predictive capping that I talked about a few posts later. Have anybody tried it out?

Yes, old thread: viewtopic.php?f=10&t=2168

It's a very old utility (2015) and needs a big refresh. That said, I wish this feature was in RTSS.

Sparky did a lot of tests with GeDoSaTo, see his graphs from 2015 in that thread.

sharknice wrote:Would it be possible to cap GPU utilization instead of capping framerate? Or would the algorithm be impossible?

Do we even know exactly why lowering utilization reduces input lag?
100% gpu utilization causing extra input lag makes sense to me because the cpu finishes and has to wait for the gpu. That waiting period would be the extra delay, although I would think that would be almost unnoticeable with a good frame pacing algorithm. And what's the reason for the 94 to 97% sweet spot or whatever it was in his tests.

I'm bumping this because I want to know this as well.

tygeezy wrote:

sharknice wrote:Would it be possible to cap GPU utilization instead of capping framerate? Or would the algorithm be impossible?

Do we even know exactly why lowering utilization reduces input lag?
100% gpu utilization causing extra input lag makes sense to me because the cpu finishes and has to wait for the gpu. That waiting period would be the extra delay, although I would think that would be almost unnoticeable with a good frame pacing algorithm. And what's the reason for the 94 to 97% sweet spot or whatever it was in his tests.

I'm bumping this because I want to know this as well.

It's possible, but it still has to be implemented by the game or engine developer.

It is possible in the driver, and most likely third-party software. For example, can limit cpu to make the video card wait for the processor.
The question is different. When to stop? 1 frame delay, 234? or in milliseconds?
Waiting for 1 frame at 240hz is not the same as waiting for 1 frame at 60hz.
An algorithm that reduces the expectation of a video card is guaranteed to lead to fps surges and drops, and the harder the algorithm, the stronger the fps fluctuations.

1000WATT wrote:It is possible in the driver, and most likely third-party software. For example, can limit cpu to make the video card wait for the processor.
The question is different. When to stop? 1 frame delay, 234? or in milliseconds?
Waiting for 1 frame at 240hz is not the same as waiting for 1 frame at 60hz.
An algorithm that reduces the expectation of a video card is guaranteed to lead to fps surges and drops, and the harder the algorithm, the stronger the fps fluctuations.

To implement a low latency framerate cap, you need to block the game immediately before it checks for user input. Now who exactly has control over that code?

game specific code-injection might be able to get similar results(at the expense of setting off every hack detector ever), or maybe you could modify an OS function like GetRawInputData, but I don't know how that would work for games that don't use raw input.

1000WATT wrote:

ffr.jpg

don't understand =\

They have a response to this:

"For those wondering about us not testing in GPU limited scenarios, we did. But here's further testing in even MORE GPU limited scenarios, in two games which didn't benefit from frame caps"

https://twitter.com/HardwareUnboxed/sta ... 4048084992





It was pretty sily of them to "myth bust" and provide next to no examples of being gpu bottlenecked. However, here are two instances that show them at 99 % usage and no hit to input lag. Maybe these games don't exhibit this behavior? I know division 2 also has dx 12 and they didn't note which api they used here. Or maybe they just didn't test right? Its hard to believe that far cry 5 has this much input lag with that high of a framerate.

They also don't specify what capper they are using. I'm going to assume they used rtss, but they need to make this stuff clear.

I wanted to say. I don’t understand how with the setting of future frame rendering off(renderdevice.renderaheadlimit 1) it was possible to load a video card 90%.

I'm guessing the gpu sweet spot percentage is based on the framerate fluctuation.

The gpu utilization is taken over a timespan. So at 95% utilization it's waiting for the next frame 5% of the time. But that measurement is taken over the span of many frames. Some of those frames take longer to render and it may have no wait time at all between some frames. Which means the cpu rendered early and was waiting for the gpu causing additional input lag.

That shouldn't really be a high amount of added lag unless the game was programmed so that the gpu skips that frame and waits for the next frame from the cpu which would essentially add a full frame of input lag.

The perfect frame pacing algorithm for lowest possible input lag would need to know both the cpu and gpu render times and adjust the wait time of the cpu so that the gpu gets a new frame from the cpu just as the gpu it finishes rendering the last frame.

That's the way I understand it, but I probably oversimplified it and there are probably a lot of other factors involved.

What is the verdict on NULL Ultra in high-FPS, entirely CPU-driven games (e.g. CSGO)? Enable or disable?