• Hey, guest user. Hope you're enjoying NeoGAF! Have you considered registering for an account? Come join us and add your take to the daily discourse.
  • The Politics forum has been nuked. Please do not bring political discussion to the rest of the site, or you will be removed. Thanks.

Predictive FPS limiting (implemented in GeDoSaTo)

Durante

Member
Oct 1, 2006
48,836
1
0
peter.metaclassofnil.com
I just implemented a somewhat unusual method of FPS capping in GeDoSaTo.

The full details are here (well, not really, the full details are here), but this image quickly sums it up:



The idea is to move as large a portion of the waiting period (generally used to implement FPS capping) as possible to the start of the frame rather than before its end, so that the game will do its input sampling later, which means feedback on inputs is slightly faster.

Does anyone know any other tool or game which does this?
 

ElTorro

I wanted to dominate the living room. Then I took an ESRAM in the knee.
May 15, 2013
16,946
1
675
Germany
twitter.com
Have you gathered statistics about how often the waiting period is predicted too large?
 

Truant

Member
Apr 23, 2007
12,311
3
0
This looks awesome. What will you do next?

nVidia GeForce drivers by Durante
ID Tech 7 by Durante
Playstation 5 by Durante
 

Durante

Member
Oct 1, 2006
48,836
1
0
peter.metaclassofnil.com
Have you gathered statistics about how often the waiting period is predicted too large?
I only tested in Ys Origin (which is fantastically stable), and even using a 0.9 prediction factor it was only predicted too large on loading, opening the menu and scene switches.

I'm sure other games would be much worse at 0.9, but I can't really imagine e.g. 0.5 being an issue in all but the most random (in terms of load) of games.
 

Miker

Member
Mar 23, 2012
5,241
5
0
On-topic: will this help with games like FFXIII?

Kinda-sorta-off-topic: I just updated GeDoSaTo, and it broke :( Error message:
 

Miker

Member
Mar 23, 2012
5,241
5
0
Oh, my fault, can you try again with the latest version?

As for FF13, sadly no, that game does its own (completely fucked up) framepacing.

New build is good to go, thanks! Too bad about FFXIII though.
 

NumberThree

Member
Sep 14, 2013
6,405
0
515
Finland
Seems like a great idea, especially for games that are relatively stable with their performance. I'm not one to notice such decreases in latency, but I'm always impressed with predictive stuff - at least when it actually works ;)
 

Dictator93

Member
Jun 29, 2011
23,811
4
850
Currently not on my rig to test this, but I definitely want to try it in TW2 and a couple other DX9 games.

I swear I read about some other game using this before... I cannot remember though.
 

epmode

Member
Jun 7, 2004
28,470
0
0
Is there any way to build a utility like this for DX11 or DX12 games? I don't know much about graphics programming so this is probably a silly question!
 

TheTux

Member
Oct 19, 2013
1,607
0
570
Oh, my fault, can you try again with the latest version?

As for FF13, sadly no, that game does its own (completely fucked up) framepacing.

I had that problem too and now it's fixed.

I can update as many times as I want though, the update button is not deactivated when you have the latest version anymore.
 

Durante

Member
Oct 1, 2006
48,836
1
0
peter.metaclassofnil.com
Is there any way to build a utility like this for DX11 or DX12 games? I don't know much about graphics programming so this is probably a silly question!
Absolutely, for DX11 at least. The only reason that GeDoSaTo doesn't work with DX11 already is my lack of time.

DX12 and other low level APIs could be impossible though, at least for many of the things it does, and at least if you want to implement something generically across games and not just for each one individually.

I had that problem too and now it's fixed.

I can update as many times as I want though, the update button is not deactivated when you have the latest version anymore.
Hmm, that's also strange. Are you sure you actually got updated to the latest version? It should be 0.17.1792.
 

TheTux

Member
Oct 19, 2013
1,607
0
570
Absolutely, for DX11 at least. The only reason that GeDoSaTo doesn't work with DX11 already is my lack of time.

DX12 and other low level APIs could be impossible though, at least for many of the things it does, and at least if you want to implement something generically across games and not just for each one individually.

Hmm, that's also strange. Are you sure you actually got updated to the latest version? It should be 0.17.1792.

Hmm updated a few times after your latest update to fix the update bug and I'm at version 0.17.1782 built at 17:45:54.

Should I just delete the folder and reinstall everything from scratch?
 

TronLight

Everybody is Mikkelsexual
Oct 2, 2011
3,317
0
775
I was literally just about to ask what had happened to GeDoSaTo. This is awesome.
 

Aeana

Member
Jul 10, 2006
42,062
4
0
This sounds pretty good. I'll definitely check it out. I end up limiting FPS to 30 in a lot of cases since if I can't get a smooth 60 then I'd rather have a smooth 30 than something completely unstable in between. I have a feeling it'll come in handy with Witcher 3.
 

Durante

Member
Oct 1, 2006
48,836
1
0
peter.metaclassofnil.com
This sounds pretty good. I'll definitely check it out. I end up limiting FPS to 30 in a lot of cases since if I can't get a smooth 60 then I'd rather have a smooth 30 than something completely unstable in between. I have a feeling it'll come in handy with Witcher 3.
It might, but the Witcher 3 will be out quite soon and I can guarantee that GeDoSaTo won't support DX11 by then :(
 

Fafalada

Fafracer forever
Jun 22, 2004
7,848
658
1,795
Durante said:
Does anyone know any other tool or game which does this?
Unless I'm misreading what you're trying to do - this is a win for codebases that process Logic and Render on the same frame (ie. coupled).

If that isn't the case (which is afaik the common case nowadays, possibly since PS2 days) you pretty much get early-wait by design(no prediction necessary) - ie. render frames coming below FrameLimit have no impact on input sampling(and on PC you don't have much control over GPU timings under pre-DX12 APIs anyway), but the logic frame must wait until last frame* was consumed by render(if it's early), so it's literally just how it works.

*I'm assuming only double-buffering here - there's some shipping games that completely decouple this with a queue, but that's a different tradeoff.
 

ussjtrunks

Member
Feb 24, 2010
1,551
0
570
Ireland
Only thing Id love to see after this is a program that could force triple buffering in 64bit games, gotta test this capping method out too
 

Durante

Member
Oct 1, 2006
48,836
1
0
peter.metaclassofnil.com
Unless I'm misreading what you're trying to do - this is a win for codebases that process Logic and Render on the same frame (ie. coupled).

If that isn't the case (which is afaik the common case nowadays, possibly since PS2 days) you pretty much get early-wait by design(no prediction necessary) - ie. render frames coming below FrameLimit have no impact on input sampling(and on PC you don't have much control over GPU timings under pre-DX12 APIs anyway), but the logic frame must wait until last frame was consumed by render(if it's early), so it's literally just how it works.
Blog post said:
The result (for games which do synchronous input sampling on the rendering thread or at least on another thread synchronized with it) is that the input after waiting is used for the new frame, reducing input lag by some fraction of the frame time.
However, I'm not sure I follow the second part of what you are saying. Even if the rendering thread is separate, there is still some point in time where it needs to sample the current world state and start to actually generate rendering commands. And if you were to limit FPS by waiting at the end of frames (before the v-sync) your data would still be more stale, no?

Also, you do have some (indirect) control over GPU timings in DX9, e.g. by using performance queries, or readbacks, or occlusion queries.
 

Wowfunhappy

Member
Jun 2, 2013
6,845
2
0
This sounds really cool!

Will this help for people who are using triple buffering? Either the proper kind (in-game option that presumably works correctly) or the improper kind (RadeonPro or D3D Overrider to queue frames)?
 

Durante

Member
Oct 1, 2006
48,836
1
0
peter.metaclassofnil.com
This sounds really cool!

Will this help for people who are using triple buffering? Either the proper kind (in-game option that presumably works correctly) or the improper kind (RadeonPro or D3D Overrider to queue frames)?
I haven't gone into the interaction of this with V-sync at all here or on my blog, since it makes the explanations more complicated. Generally, on a fixed refresh display, you'd probably want to only FPS limit to your refresh rate or integer fractions of that, so triple buffering should be unnecessary.

One of the reasons I implemented this is also to work well with G-sync, because with that it might make sense to e.g. limit the framerate to something which seems strange to us now (like, say, 42).
 

Wowfunhappy

Member
Jun 2, 2013
6,845
2
0
I haven't gone into the interaction of this with V-sync at all here or on my blog, since it makes the explanations more complicated. Generally, on a fixed refresh display, you'd probably want to only FPS limit to your refresh rate or integer fractions of that, so triple buffering should be unnecessary.

One of the reasons I implemented this is also to work well with G-sync, because with that it might make sense to e.g. limit the framerate to something which seems strange to us now (like, say, 42).

Ah, I saw "capped" and instantly thought of vsync "capping" the fps to a divisible value of your refresh rate. I guess this is different. Thanks!
 

PnCIa

Member
Nov 26, 2005
2,782
1
1,415
Germany
Dude, you are an entrepreneur! :)
Maybe your work can be implemented in RTSS or something, they should probably hire you.
 

Fafalada

Fafracer forever
Jun 22, 2004
7,848
658
1,795
Durante said:
And if you were to limit FPS by waiting at the end of frames (before the v-sync) your data would still be more stale, no?
Yes, but my point is that's a cumbersome/non-intuitive approach if your Logic is paralel to render. The only time Logic needs to wait is "if render is not finished with previous frame", right before working on next, so waiting at end of Logic frames is just backwards.
Maybe I'm wrong in terms of how common this is, but I'd find it pretty baffling if that's the case.

Also, you do have some (indirect) control over GPU timings in DX9, e.g. by using performance queries, or readbacks, or occlusion queries.
Sure - but while I haven't looked at it recently - I remember that under DX9 different vendors at least used to have opposite approaches to "when" work is submitted to GPU (one started with Present, other waited to finish with it).
 

daninthemix

Member
Jul 7, 2010
3,620
728
1,095
Have you checked out the FPS limiter in Nvidia Inspector? I always liked the simple elegance of doing it through the driver profiles rather than having an app running all the time (Rivatuner) or hooking Direct X.
 

M3d10n

Member
Aug 28, 2006
11,466
1
0
So the idea is to estimate how long my next frame will take to be generated and wait a bit before sampling input, right? I'm actually interested in implementing something like this in my own games.

It does sound more suited to games that are underutilizing the hardware, however.
 

mrklaw

MrArseFace
Jun 10, 2004
59,891
2
0
Windsor, UK
And for your next challenge - if you're predicting frame times, how about predicting when a frame then might go over 16/33ms and disabling some effects to bring it within budget? That would be crazy useful (this looks insane too)
 

Teeth

Member
May 7, 2014
2,755
1
300
And for your next challenge - if you're predicting frame times, how about predicting when a frame then might go over 16/33ms and disabling some effects to bring it within budget? That would be crazy useful (this looks insane too)

I don't know if this would even be possible without carving out entire render passes.

That said, I do wonder if it could be done by dynamically reducing the resolution like the wipeout hd and idtech engines do. With super sampling it would be even less noticeable. That said, predicting future frames without full access to the engine might not be possible without first having a bad frame time to predict ahead with.
 

Dictator93

Member
Jun 29, 2011
23,811
4
850
And for your next challenge - if you're predicting frame times, how about predicting when a frame then might go over 16/33ms and disabling some effects to bring it within budget? That would be crazy useful (this looks insane too)

I don't think Durante can do this really with in game graphical settings, but he can (and has done it before) with GeDoSaTo and PP effects he added in.
 

Arulan

Member
Dec 14, 2010
3,712
3
0
United States
I haven't gone into the interaction of this with V-sync at all here or on my blog, since it makes the explanations more complicated. Generally, on a fixed refresh display, you'd probably want to only FPS limit to your refresh rate or integer fractions of that, so triple buffering should be unnecessary.

Are there any negative effects to its use with V-sync? Generally I'm using V-sync (double-buffered) at integer fractions of 120, and obviously using half-refresh V-sync for 60, etc. I always combine them with a frame limiter (RTSS) too.

I'll have to compare this to RivaTuner Statistic Server's implementation, which is currently the gold standard in frame-rate limiting, at least as far as frame pacing is concerned.

If you have a second, any reason why half-refresh Vsync in GeDoSaTo doesn't work in certain applications? I'm specifically talking about Pillars of Eternity, because it lacks a (true) exclusive full-screen mode, meaning the implementation used in Nvidia's drivers doesn't work. Of course, that maybe the reason GeDoSaTo doesn't seem to work with it either.
 
Feb 27, 2014
8,414
0
0
Does anyone know any other tool or game which does this?

Yes dammit, the program I was intending to make as my project at the end of my course! I've been living under the impression I was the only one who had this idea, plan foiled.

Seriously though congrats on what I can really appreciate as a project that must have been rather awkward. In all honesty my 'program' doesn't actually do this since I've only been trying to draft ideas for how it may work and haven't actually got any solid code down, or even ideas for how it would work to be honest. I've been interested in something like this for quite a while and to just have an end product of it spring up out of nowhere is awesome, really can't wait to experiment with it.

Damn you though, I need a new project idea now!
 

Alo81

Low Poly Gynecologist
Jun 24, 2012
13,139
1
710
steamcommunity.com
Yes dammit, the program I was intending to make as my project at the end of my course! I've been living under the impression I was the only one who had this idea, plan foiled.

Seriously though congrats on what I can really appreciate as a project that must have been rather awkward. In all honesty my 'program' doesn't actually do this since I've only been trying to draft ideas for how it may work and haven't actually got any solid code down, or even ideas for how it would work to be honest. I've been interested in something like this for quite a while and to just have an end product of it spring up out of nowhere is awesome, really can't wait to experiment with it.

Damn you though, I need a new project idea now!

Just in case you didn't know, if you wanted to see how Durante pulled it off GeDo is open source and up on Github.

Here are the relevant commits.

Added FPS Limiting
Predictive FPS Limiting
 

Durante

Member
Oct 1, 2006
48,836
1
0
peter.metaclassofnil.com
Are there any negative effects to its use with V-sync? Generally I'm using V-sync (double-buffered) at integer fractions of 120, and obviously using half-refresh V-sync for 60, etc. I always combine them with a frame limiter (RTSS) too.
Basically, if you use this you won't need to (and probably shouldn't) half-refresh (or 1/3rd, etc.) V-sync. If you use an integral fraction of your refresh rate everything should work well with normal V-sync. One suggestion I'd make is to use something like 40.5 as the frame limit if you want 40 FPS (which is a possible choice on a 120 Hz screen).

If you have a second, any reason why half-refresh Vsync in GeDoSaTo doesn't work in certain applications? I'm specifically talking about Pillars of Eternity, because it lacks a (true) exclusive full-screen mode, meaning the implementation used in Nvidia's drivers doesn't work. Of course, that maybe the reason GeDoSaTo doesn't seem to work with it either.
You guessed it: an application can only set the V-sync behavior in exclusive fullscreen mode.
 

PnCIa

Member
Nov 26, 2005
2,782
1
1,415
Germany
Have you checked out the FPS limiter in Nvidia Inspector? I always liked the simple elegance of doing it through the driver profiles rather than having an app running all the time (Rivatuner) or hooking Direct X.
Actually the Nvidia limiter is kinda broken. It always clamps the framerate too high, for example if you set it to 120 a game can run up to 125-127 FPS. RTSS does not have this problem.
 

riflen

Member
Feb 12, 2013
2,402
0
0
Actually the Nvidia limiter is kinda broken. It always clamps the framerate too high, for example if you set it to 120 a game can run up to 125-127 FPS. RTSS does not have this problem.

Just create a custom rate to limit to by editing the Inspector config. Takes 5 minutes with a text editor.