Do video games come with triple buffering built in?

[grandos_tabetos]

I've never used triple buffering in the Nvidia CP, and even if I did use it, it would be useless since it only applies to OpenGL games. I only use regular Vsync alone in all my games. And yet I've never seen the framerate dipping to 30 when it drops below 60; e.g. 50 fps is still 50fps. So does this mean that the games come with triple buffering built into them already?

 

[Jaydip]

I've never used triple buffering in the Nvidia CP, and even if I did use it, it would be useless since it only applies to OpenGL games. I only use regular Vsync alone in all my games. And yet I've never seen the framerate dipping to 30 when it drops below 60; e.g. 50 fps is still 50fps. So does this mean that the games come with triple buffering built into them already?

TB only helps in OpenGL games(correct me if I am wrong here).

 

[grandos_tabetos]

TB only helps in OpenGL games(correct me if I am wrong here).

Triple Buffering works for both kinds of games. The one in the nvidia control panel only works for OpenGL games. You can download D3dOverrider that forces triple buffering in DirectX games.

 

[Jaydip]

Triple Buffering works for both kinds of games. The one in the nvidia control panel only works for OpenGL games. You can download D3dOverrider that forces triple buffering in DirectX games.

OK, to answer your original question do you use adaptive vsync?

 

[grandos_tabetos]

OK, to answer your original question do you use adaptive vsync?

//

I only use regular Vsync alone

 

[Jaydip]

//

Lol too much beer is taking it's toll :$

 

[BrightCandle]

There is no triple buffering in DirectX. Even DXOverrider does not add triple buffering. DXO is a hack on the way frames are placed into the command queue, it allows frames to replaced such that the game can continue to produce frames and override the newest if there is a newer one available and the command queue is full.

DX does not support triple buffering at all, in any way. It has various simulations but none of them act the same or do the same thing.

The 30 fps thing with vsync is that @ 60fps a frame comes along every 16.6ms onto your monitor. Because of vsync if a frame misses that 16.6ms threshold then it will delayed until the next sync, ie another 16.6ms. Thus any frame above the threshold will be 33.3ms, which is the exact times you would see consistently at 30 fps.

About the worst case for this is 45 fps. This will often produce a pattern of 16,33,16,33,16,33 which will look very uneven to those that spot stutter (not everyone seems to, although when shown side by side everyone can see it, so its potentially a matter of training and knowing what to look for). Vsync forces frames into either a 33.3 or 16.6ms timing (or 49ms and above) and hence produces discrete steps.

 

[Red Hawk]

DX does not support triple buffering at all, in any way. It has various simulations but none of them act the same or do the same thing.

Do you have a source on this? Because some DX games, such as Deus Ex: Human Revolution, specifically have a triple buffering option, so I would need to see a source before I believe that they're being dishonest about that setting. And even if it's just some sort of "simulation", that's still supporting a form of triple buffering, even if it's not "true" triple buffering (which you haven't really defined in the first place).

It's more plausible to me that D3D Overrider isn't really triple buffering though, since if neither Nvidia or AMD seem able to make a triple buffering override driver option, so why would a 3rd party modification be able to do it? It seems to me that triple buffering is something that has to be specifically coded for in the game.

 

[grandos_tabetos]

There is no triple buffering in DirectX. Even DXOverrider does not add triple buffering. DXO is a hack on the way frames are placed into the command queue, it allows frames to replaced such that the game can continue to produce frames and override the newest if there is a newer one available and the command queue is full.

DX does not support triple buffering at all, in any way. It has various simulations but none of them act the same or do the same thing.

The 30 fps thing with vsync is that @ 60fps a frame comes along every 16.6ms onto your monitor. Because of vsync if a frame misses that 16.6ms threshold then it will delayed until the next sync, ie another 16.6ms. Thus any frame above the threshold will be 33.3ms, which is the exact times you would see consistently at 30 fps.

About the worst case for this is 45 fps. This will often produce a pattern of 16,33,16,33,16,33 which will look very uneven to those that spot stutter (not everyone seems to, although when shown side by side everyone can see it, so its potentially a matter of training and knowing what to look for). Vsync forces frames into either a 33.3 or 16.6ms timing (or 49ms and above) and hence produces discrete steps.

Ok so if games show a 58fps when they're at 58fps, and show 50fps when they're at 50fps, and only vsync is being used, then the game does have a built in triple buffering simulation? Otherwise it would be 30fps right?

 

[brag.yondide]

@BrightCandle (or other experts). Can you enlighten me: how do deferred rendering, flip queue (Radeon)/render ahead (Nvidia) size, triple buffering, and frame buffer relate to one another?

My (very confused) understanding is:
-deferred rendering is essentially queuing of graphics commands for multiple frames by the CPU. Is this done by the application, D3D, or the graphics driver, or in the GPU?
-flip queue/render ahead size. How many frames are 'deferred' as above maybe?
-triple buffering. A general buffering technique, sure. But what does it apply to in D3DOverrider/RadeonPro?
-frame buffer. This is output buffer for the display and is essentially the last buffer in the graphics pipeline. This could be single (not usually), double, or triple buffered.

Anand's article on this was a bit too general.
http://www.anandtech.com/show/2794/2

Any clarifications appreciated.

 

[Dankk]

Do you have a source on this? Because some DX games, such as Deus Ex: Human Revolution, specifically have a triple buffering option, so I would need to see a source before I believe that they're being dishonest about that setting. And even if it's just some sort of "simulation", that's still supporting a form of triple buffering, even if it's not "true" triple buffering (which you haven't really defined in the first place).

Seconded. Tomb Raider has a built-in setting for triple-buffering as well, and that's a DX game.

Ok so if games show a 58fps when they're at 58fps, and show 50fps when they're at 50fps, and only vsync is being used, then the game does have a built in triple buffering simulation? Otherwise it would be 30fps right?

Last game I played like this was Metro: Last Light. The Vsync option didn't explicitly say "triple-buffering", but it allowed the framerate to move anywhere below 60 fps without snapping to 30, and it felt very smooth.

Contrastly, I was playing Crysis 2 last night and the screen-tearing is absolutely awful with Vsync off, but with Vsync on it does the dreaded snapping to 30 frames anytime the framerate sinks below 60. I couldn't use Vsync anywhere around 40 or 50 fps. Crysis 2 is the kind of game that could really benefit from a triple buffering option.

 

[bystander36]

I have had the same experience as most of you. Most DirectX games do not get stuck at 30 FPS when they can't maintain 60 while v-sync is on. Some sort of triple buffering must be in place for that to happen.

 

[brag.yondide]

Ok so if games show a 58fps when they're at 58fps, and show 50fps when they're at 50fps, and only vsync is being used, then the game does have a built in triple buffering simulation? Otherwise it would be 30fps right?

I understood it depends on how the frame rate is measured. For instance, if frame rate is measured over a several frames, and you had frame times of 16.7ms, 16.7ms, and 33.4ms (equivalent to 60, 60, and 30 fps), it could show the average of 50 fps.

 

[bystander36]

I understood it depends on how the frame rate is measured. For instance, if frame rate is measured over a several frames, and you had frame times of 16.7ms, 16.7ms, and 33.4ms (equivalent to 60, 60, and 30 fps), it could show the average of 50 fps.

That is what they are saying is happening, which is why they believe triple buffering or something similar is happening. Otherwise when you fail to maintain 60 FPS, the GPU is forced to stop working while waiting for the next refresh, which puts the GPU in the same position as when it rendered the first frame, it can't do it within 16.7ms, forcing it to wait again, and do nothing during that time. This results in a constant 30 FPS until it can render a frame within 16.7ms. Triple buffering allows the GPU to work towards the next frame during that wait, so it may not have to wait an extra refresh the next time, allowing FPS in between 30 and 60.

Of course this behavior can cause a bit of stuttering, which is very apparent when your FPS drop from 60 to 50 with v-sync on.

 

[Red Hawk]

Seconded. Tomb Raider has a built-in setting for triple-buffering as well, and that's a DX game.

Worth noting is that both games are built with the Crystal Dynamics engine. So that indicates to me that triple buffering has to be supported specifically by the engine.

 

[BrightCandle]

If triple buffering is genuinely working then despite vsync the game can and will see frame rates higher than the refresh rate of the monitor. 1000 fps is perfectly possible if triple buffering is working. But if you are capped at 60 hz and vsync is on (no tears) then there is not true triple buffering. Not a single game on DirectX actually supports triple buffering, its simply a misnaming slightly marketing term, its being abused. Its using three buffers but the algorithm is wrong.

In DirectX you can setup a "flip queue" that has more than the usual 2 buffers (double buffering). However you can't set a strategy of flipping these buffers to allow one buffer to be constantly overwritten, they must be played through in order. Thus despite there being a third buffer the GPUs output will be limited to the frequency of the monitor. Much of the benefit of triple buffering comes from the ability to replace the oldest frame and to allow flipping in such a way that you can always get a newer frame. Without this strategy in place you just get a lot of latency and you don't eliminate the discrete 16/33 ms jumps present with the usual duouble buffering and vsync. In essence it is "triple buffered" but its not the real thing.

Games do not magically snap to 30 fps when they drop below 60 fps, because frames per second is an average. If all the frames are delivered in 16.6ms timing except for one frame that was delivered in 33.3ms then your tool will tell you that you got 59 fps, but you didn't get 59 evenly spaced frames, you got 58 perfect ones and 1 frame that took twice as long. We call this the 60/30 problem. Those little judders are very noticeable to those with experience.

-deferred rendering is essentially queuing of graphics commands for multiple frames by the CPU. Is this done by the application, D3D, or the graphics driver, or in the GPU?

Nope deferred rendering is a technique where some of the fixed pipeline functionality of the graphics card is skipped or nullified and then filled in using post processing. In essence the programmers of the game take on some amount of core functionality of the rendering of the scene and run it on the GPUs processing cores. Typically today this is done with lighting as the fixed function lighting on the GPU is not very good. It has nothing to do with the way in which the frames are delivered, it only has an impact on the GPU pipeline itself making some hardware features (AA) unavailable.

-flip queue/render ahead size. How many frames are 'deferred' as above maybe?

The buffers that the GPU renders into are organised into flip queues.

Render ahead is the size of the command queue, the commands before they go into the GPU.

-triple buffering. A general buffering technique, sure. But what does it apply to in D3DOverrider/RadeonPro?

It doesn't, these tools can't make directX do something it can't do. It is technically changing a game to use three buffers, but as I explain above without the algorithm it just adds a lot of latency and maybe a bit of smoothness.

-frame buffer. This is output buffer for the display and is essentially the last buffer in the graphics pipeline. This could be single (not usually), double, or triple buffered.

Triple buffered means more than just having 3 frame buffers however.

 

[bystander36]

If triple buffering is genuinely working then despite vsync the game can and will see frame rates higher than the refresh rate of the monitor. 1000 fps is perfectly possible if triple buffering is working. But if you are capped at 60 hz and vsync is on (no tears) then there is not true triple buffering. Not a single game on DirectX actually supports triple buffering, its simply a misnaming slightly marketing term, its being abused. Its using three buffers but the algorithm is wrong.

It is quite possible to have triple buffering and a FPS limit of the refresh rate in place. I have only seen one case where this has ever happened, which is in Metro 2033 with 3D Vision. For some reason, even though v-sync is forced on due to 3D Vision, it can go beyond 60 FPS, but this is most likely a bug and not a feature.

V-sync only allows the access to the front buffer during vertical retrace mode. Triple buffering allows the GPU to render when being forced to wait for vertical retrace mode. That does not mean there cannot be a FPS limit in place at the same time.

Do you have any link that could back you up?

I find it hard to believe rendering times are radical enough to allow for such gradual and consistent loss of FPS with small visual differences, that I've seen in many games.

As many others have noted, several games give you the option to use triple buffering. This is a lot more credible than nothing supporting that there is no form of triple buffering.

It is also quite possible that triple buffering is only activated when v-sync is, since it is only useful if you have to preserve a frame while waiting for vertical retrace/blanking mode.

Triple buffered means more than just having 3 frame buffers however.

That is news to me. Care to clarify? As we have been saying, the way it behaves would require triple buffering or something similar. Something similar would be what we are talking about if "Triple buffered" has some special meaning to you.

 

[bystander36]

Here is something that describes things quite well, and explains why triple buffering with v-sync prevents higher FPS than your refresh rate when using DirectX.

https://en.wikipedia.org/wiki/Multiple_buffering

Another method of triple buffering involves synchronizing with the monitor frame rate. Drawing is not done if both back buffers contain finished images that have not been displayed yet. This avoids wasting CPU drawing undisplayed images and also results in a more constant frame rate (smoother movement of moving objects), but with increased latency. This is the case when using triple buffering in DirectX, where a chain of 3 buffers are rendered and always displayed.

That is under the Triple buffering section, btw.

 

[BrightCandle]

bystander36 has it nailed. Effectively there are a few different ways to go about choosing what to do when all the buffers are full and which one to take when a vsync occurs. From a latency and performance perspective you want the oldest of the two back buffers to be overwritten if you happen to have another frame ready for a back buffer and the newer one can be ready incase a vsync occurs in the middle of that. This ensures that the frame rate can exceed the monitor refresh rate and images are as new as they can be when a vsync does occur. The GPU can effectively choose which of the back buffers to overwrite and then on vsync which to swap in.

The algorithm DX uses however is to treat the buffers as a chain where they must come one after the other. You put a frame in one end and it will propogate through each buffer. If all the buffers are full the GPU stops processing and waits for the buffer to clear before accepting a new frame. It is thus locked to the frequency of the monitor, it simply has one extra stage of buffering to soak up any inconsistencies coming out of the GPU. So technically there are three buffers, but the algorithm used doesn't fix any of the problems with dual buffering, it simply adds more latency.

One of the reasons why triple buffering is important is that typially frame to frame the GPU is remarkably consistent in how long it takes to render a frame. Most are very similar and thus it puts out frames on a very reliable schedule. Its only during major changes of scenario that this situation changes. Conversely the game world production on the CPU along with passing the commands to DX is highly variable. Many games show significant differences in processing time frame to frame and the game world sampling is often not at nice regular periods. Triple buffering with 2 back buffers both usable by the GPU helps soak up some of the irregularity and maintain a decent average latency in doing so, Microsoft's DX implementation does not help with that at all, it just adds latency.

Its not the algorithm and technique I covered at University, infact it was discussed at the time as a brand dead naive way to do it that followed naturally from double buffering but which no one would ever want to do in practice because it was mostly drawbacks and didn't solve the same problem as "real" triple buffering.

 

[bystander36]

I'm not sure how it is a dead end. It incurs some latency, but so does dropping the FPS down to 30 FPS.

And I don't see how it isn't "real" triple buffering. I believe a better term might be, it isn't the "original" triple buffering. The original version would also have some latency as well when used with v-sync, though it should be less most the time, especially in cases where your FPS are much higher than your refresh rate.

 

[brag.yondide]

-deferred rendering is essentially queuing of graphics commands for multiple frames by the CPU. ...

My mistake. I was incorrectly looking at this from Microsoft which is an unrelated (but seemingly unfortunately named) thing:
http://msdn.microsoft.com/en-us/library/windows/desktop/ff476892(v=vs.85).aspx

Deferred Rendering
Deferred rendering records graphics commands in a command buffer so that they can be played back at some other time. Use a deferred context to record commands (rendering as well as state setting) to a command list. Deferred rendering is a new concept in Direct3D 11; deferred rendering is designed to support rendering on one thread while recording commands for rendering on additional threads.

Thx for the input. A little knowledge is a dangerous thing. So give me some more and I can really do damage!

Edit: I went back to Anand's article. It has been updated since my original reading and came across this:

...If you are implementing render ahead (aka a flip queue), please don't call it "triple buffering," as that should be reserved for the technique we've described here in order to cut down on the confusion. There are games out there that list triple buffering as an option when the technique used is actually a short render queue...

 

[tweakboy]

If you enable it in nvpanel, and it doesnt work I dont think its your end

 

[PrincessFrosty]

DirectX is an API which defines a bunch of standards and built in features, to my knowledge triple buffering is not one of them.

However if you write your own game engine you can internally handle this feature, or anyone writing tools can do a hacked together version that mimics the behaviour.

 

[BrightCandle]

DirectX is an API which defines a bunch of standards and built in features, to my knowledge triple buffering is not one of them.

However if you write your own game engine you can internally handle this feature, or anyone writing tools can do a hacked together version that mimics the behaviour.

Actually you can't. Your interaction with the GPU is limited by directx and there is no way to tell the GPU about buffers except the flip queue setup. Since there is no option as part of that api to change the flipping strategy you can't do anything about it.

Its rubbish really, so many people have problems with vsync off and vaync double buffering that you would have thought ms would make triple buffering available. I guess the move to command queues has added quite a lot of latency already, yet more is likely a bad plan.