Support NeoGAF

[Durante]

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]

Have you gathered statistics about how often the waiting period is predicted too large?

 

[Truant]

This looks awesome. What will you do next?

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

 

[Durante]

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]

On-topic: will this help with games like FFXIII?

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

 

[Durante]

On-topic: will this help with games like FFXIII?

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

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.

 

[Miker]

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.

 

[la_briola]

Interesting, thanks for sharing.

 

[Durante]

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

Thanks for reporting the issue, that was stupid

 

[NumberThree]

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]

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.

 

[Crayon]

Nice work! Thank you!

 

[epmode]

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]

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.

 

[la_briola]

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!

Sure, but time is a issue! ;-)

 

[Durante]

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.

 

[dr_rus]

Cool stuff. I wish GeDoSaTo worked on my machine -)

 

[TheTux]

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?

 

[Durante]

Cool stuff. I wish GeDoSaTo worked on my machine -)

What's the problem?

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?

Yes, that's probably the easiest solution.

 

[TronLight]

I was literally just about to ask what had happened to GeDoSaTo. This is awesome.

 

[shockdude]

This looks like fun. Will have to check it out later.

 

[TheTux]

What's the problem?

Yes, that's probably the easiest solution.

Done and works now. Sorry for the random bug report.

 

[Aeana]

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]

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

 

[dr_rus]

What's the problem?

No idea. Tried it a couple of times and it didn't work at all. Probably some conflict with AB or such. I'm mostly fine with DSR anyway.

 

[Aeana]

It might, but the Witcher 3 will be out quite soon and I can guarantee that GeDoSaTo won't support DX11 by then

Aw, man.

 

[ssss]

I am eager to try this Durante! Thank you very much for your work

 

[Fafalada]

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]

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]

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.

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]

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)?

 

[OnionPowder]

I was just thinking the other day that GeDoSaTo should have some sort of frame limiter. It's like you read my mind.

 

[Durante]

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]

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]

Dude, you are an entrepreneur!
Maybe your work can be implemented in RTSS or something, they should probably hire you.

 

[Fafalada]

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]

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.

 

[LiquidMetal14]

This is amazing. And you should be getting some money for this. And also never charge us for these types of fixes. Excellent work.

 

[M3d10n]

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]

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]

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]

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]

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.

 

[UpDownLeftRight]

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]

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]

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]

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]

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.

 

[Prime crotch]

random question, why visual studio as an ide for c++? not fronting, just curious about the pick

 

[TaintedHotSauce]

random question, why visual studio as an ide for c++? not fronting, just curious about the pick

I'm obviously not Durante, but I'm not aware of a better IDE/debugger than the one Visual Studio packs for C++. What were the alternatives you had in mind?