How does a frame rate limiter work

[pjbliverpool]

I've trawled the net but can't seem to find any specific definition of how a frame rate limiter of the sort enabled by Nvidia Inspector and similar third party applications actually works.

For example, if I set a 30fps limit, does that mean it will prevent every single frame from rendering in less than 33ms? So say even if you could render a given frame in 16ms, the GPU would somehow be prevented from doing that?

And then the follow on question would be how does that interact with vsync? For example if the above were true then I'd assume setting the framerate limit to even 59 (so that every single frame renders in more than 16.67ms) would automatically force the frame rate down to 30fps with vsync enabled?

 

[DavidGraham]

The engine will not prevent it, it will just update the screen every other refresh, irrespective of frame rendering time. The pattern will be like this on a 60Hz display: new frame followed by a duplicate one followed by a new one ..etc.

Consistency here is key, if your frame time varies greatly, the pattern will be disrupted, it could turn out like this: new then new then duplicate then duplicate, then new .. etc, which will manifest as judder.

Setting the limit to 59 will only half the frames if frame time exceeded 16.6 in every single frame, if that didn't happen you won't get this result.

Also You don't need the inspector to force half rate v.sync, you can do that from the control panel.

 

[homerdog]

I've trawled the net but can't seem to find any specific definition of how a frame rate limiter of the sort enabled by Nvidia Inspector and similar third party applications actually works.

For example, if I set a 30fps limit, does that mean it will prevent every single frame from rendering in less than 33ms? So say even if you could render a given frame in 16ms, the GPU would somehow be prevented from doing that?

And then the follow on question would be how does that interact with vsync? For example if the above were true then I'd assume setting the framerate limit to even 59 (so that every single frame renders in more than 16.67ms) would automatically force the frame rate down to 30fps with vsync enabled?

Capping the rendering fps is a very simple thing for a graphics programmer to do.

It's not like the GPU is rendering as fast as possible and the front-back buffer swap is limited to 30fps, the 'extra' frames will not be rendered at all. So yes, the GPU is prevented from doing that (the CPU never sends any commands to render >30fps).

 

[pjbliverpool]

Cheers guys, what I'm really trying to understand though is how the GPU actually achieves the fps limit. i.e. lets assume vsync is off and you set the limit to 30fps (33ms frame time assuming an even distribution of frames), lets also assume your GPU is capable of rendering every frame in 20ms. Would if simply render frame 1 in 20ms then wait another 13ms before starting to render frame 2 and so on?

 

[gamervivek]

dxtory is another 3rd party tool that can be used to limit the fps, not sure if they directly affect the gpu's frame production or merely display the ones within limit. I am leaning towards the latter.

 

[DavidGraham]

lets also assume your GPU is capable of rendering every frame in 20ms. Would if simply render frame 1 in 20ms then wait another 13ms before starting to render frame 2 and so on?

Yes, frames are just snapshots of the simulation running the game, it needs to be taken and displayed as close to the actual events in the simulation as possible, otherwise motion aliasing will occur. So the frame limiter will force the CPU to only send commands for 30 snapshots, if the GPU finishes one snapshot early, it can't start on a new one as this will necessitates caching frames and discarding them, one possible outcome of this is using old snapshots that are not in sync with the current simulation. So the GPU sticks to only rendering 30 fps with stalls in between.

In practice, I think it is a little bit complicated than this, if the workload is predictable and consistent, frame limiting will be successful. But, most workloads are not predictable especially on PCs using crazy ultra settings, so when the GPU finishes a frame early, it will start taking the next one immediately, the pipeline can not afford stalls, it will render frames as fast as possible then sort out the miss later on. This will manifest as uneven motion of course.

 

[pjbliverpool]

Cheers it's making more sense to me now but I don't understand the following statement:

so when the GPU finishes a frame early, it will start taking the next one immediately

I assume if the frame rate is limited to 30fps then the CPU is sending 1 snapshot to the GPU to render every 33ms. If that's the case and the GPU finishes that frame early, say in 16ms, how can it start on the next one? Surely that still hasn't been sent from the CPU yet?

 

[HMBR]

I normally use MSI afterburner to set a limit, it definitely lowers GPU/CPU load and temperature like vsync would if your hardware could render at a higher rate than the screen refresh rate

 

[DavidGraham]

I assume if the frame rate is limited to 30fps then the CPU is sending 1 snapshot to the GPU to render every 33ms. If that's the case and the GPU finishes that frame early, say in 16ms, how can it start on the next one? Surely that still hasn't been sent from the CPU yet?

Yes, but with the massively unpredictable nature of some PC workloads, the frame limiter clutch will be a lot less strict, when the frame time exceeds 33ms in some snapshots, the 30fps target will fall apart. For example, it could hit 25fps according to the frame time of the other remaining snapshots, so the limiter basically has two options:

1-The difference will be compensated by even more duplicate frames. The 30fps limit will be upheld, but at the cost of severe aliasing and out of sync experience.

2-Stalls will be eliminated to temporarily boost fps, in that case it's possible the 30fps limit will be overridden, though not necessary. Obviously this is the preferred method.

A good limiter is one that takes all of these possibilities into account, and acts accordingly.

 

[pjbliverpool]

Thanks I think that's clear now. So I guess then if you could render every single frame within say 20ms or less (40fps minimum) then limiting fps to say 30fps (33ms) would mean that the GPU renders every frame in 20ms (or less) then waits 13ms (or more up to the difference of 33ms) to start rendering the next scene and thus you'd get a completelty consistent 30fps as you'll only get one new frame every 33ms? And then of course vsyncing as well should result in a locked 30fps vsync with proper frame pacing?

 

[DavidGraham]

Yes and Yes. In the ideal world you described, V.sync will work flawlessly.
However, when frame time goes out of order (exceeds 33ms), then v.sync will add another complexity layer on top of all of that, as it needs to be synced in some form with the stalls/duplicate frames.

 

[sebbbi]

Limiting to 30 fps is easy. The driver just waits for even vsyncs instead of all of them. Limiting to an arbitrary fps number needs a software timer and this technique will cause tearing (unless you have freesync/gsync enabled monitor).

 

[pjbliverpool]

Thanks, the ultimate question I'm trying to answer is how to get the smoothest framerate in a game that varies all over the shop (like watch dogs) it seems a lock at 30 fps is the best way but since many games will often go over 60 fps then vsync alone wont cut it as you'll be jumping around between 30fps and 60fps with sync engaged. So I'm thinking something like vsync + a frame cap somewhere between 30 and 59 fps to prevent the game ever delivering a single frame within 16.67ms and thus acheiving a perfectly paced 30 fps. I'd assume if your minimum frame rate is well above 30fps then youd be able to acheive that with any cap between 30 and 59 and they would all produce exactly the same perfectly paced 30fps.

However my testing with Cyrsis seems to show the game getting progressively smoother even when vsync remains engaged as I raise the frame cap through 30, 35, 45 and 55 fps. Interestingly fraps frame time monitor also shows the game rendering at those associated different frame times (more or less fixed at those times) even though vsync is clearly working and they should all be at 30fps (of 40fps come to think of it given I have a 120hz monitor).

 

[AlNom]

However my testing with Cyrsis seems to show the game getting progressively smoother even when vsync remains engaged as I raise the frame cap through 30, 35, 45 and 55 fps. Interestingly fraps frame time monitor also shows the game rendering at those associated different frame times (more or less fixed at those times) even though vsync is clearly working and they should all be at 30fps (of 40fps come to think of it given I have a 120hz monitor).

Does the game enable triple buffering by default?

 

[pjbliverpool]

Good point, there's nothing in the graphics menu's but it might just be enabled by default.

 

[DavidGraham]

I think Watch_Dogs have a built in frame limiter to 60 or 30 (though I didn't try it), NV control panel can also be set to adaptive v.sync using half refresh rate(but since your monitor is 120Hz I guess that option is not for you).

Crysis is the wrong game to measure this on, because it is extremely smooth at 30fps due to the heavy use of motion blur, at 60fps it becomes silky smooth.

 

[homerdog]

Limiting to 30 fps is easy. The driver just waits for even vsyncs instead of all of them.

That is still vsync, which I don't think is what pjbliverpool is getting at. Also setting 1/2Hz vsync causes quite a lot of input lag in some games. I know that's because of stupid programming but it's still a thing. The software timer adds no additional input latency ever (beyond the latency inherent to lower fps) and can be enabled with vsync (double or triple buffer). The software timer is also very easy to implement..

Does the game enable triple buffering by default?

Yah.

 

[Simon F]

Q:How does a frame rate limiter work?

It's quite simple really. The generated frames make the central axle turn...

..and as it spins faster, the weights begin to rise up closing a valve which, in turn, reduces the flow of triangles to the vertex shader.

 

[AlNom]

Technology of the Ancients

 

[pjbliverpool]

Does the game enable triple buffering by default?

I tried testing with Tombraider which has a specific option in the graphics menu to select either triple or double buffering, so all of the following frame times were specifically taken with double buffering engaged:

http://img.photobucket.com/albums/v68/pjbliverpool/TombraiderFrameTimes.jpg

(sorry for the tiny size, best my hosting site would do)

So we're still seeing frame times which are clearly not in line with what would be expected from a vsync'd game. But as with Crysis 2 there is no tearing at all so vsync does seem to be engaged.

As you might guess from the graph, the best feeling of these was the 40fps frame lock. The quarter refresh rate vsync didn't feel as bad as it looks but it was a bit laggy. The effectively unlocked (even though vsync is on??) was smooth in parts but did suffer from stutter.