Why not always have triple buffering on?

Ah, this topic again.

Again..enabling triple buffering in DirectX just induces another buffer in the stack sequentially.

There is no real triple buffering available in DirectX.

I think this is the right link to reference this -> http://msdn.microsoft.com/en-us/library/windows/desktop/bb173393(v=vs.85).aspx

And may be this is the right info too ->

----
Edit
Oh someone already mentioned the Wiki quote previously...didn't see it.

 

That is why I wrote that theory does not match reality and everyone uses different implementation. Those sequential buffers are like worst case scenario and is in use if TB is enabled in game, unless game engine has it's own method linked to that option.

 

Unless Radeon Pro or D3Doverrider does it another way?

Note: Positive that either of the authors did mention it once, as in what behavior their Triple Buffering options execute.

 

I don't think I followed through on fully understanding this explanation -- could you rephrase why setting a frame cap of -1 less than screen refresh is preferable?

What would be the noticeable effects with them being equal to each other (60fps | 60hz)?

What would be the noticeable effects with framerate being -1 less than screen refresh (59fps | 60hz)?

 

In reality, setting a hard limit for FPS as 60 doesn't absolutely reflect 60FPS output down the render pipeline. It can fluctuate around 61 (62 is rare). May be this contributes to having -2 or -1 FPS less than Vsync Refresh rate idea.

But yes, having a third buffer is a must in this case..else Vsync with DB might step down.

Also many are missing the point that no frames are skipped with Vsync + Third Buffer in DirectX, so the overall frame rate of the game will be smooth.

 

This is not true TB, this is called flip-que or render ahead (yes, i am aware a lot of people call it triple buffering, it technically has 3 buffers)

in a true TB setup, the 3rd buffer is PARALELL to the existing back buffer. Not sequential.

If your saying that DX does not implement the 3rd buffer in paralell to the back buffer, its the first ive heard of it. ALthough ive never really got into the technical aspects that deeply.

AFAIk, RP implements it correctly as John, the delveloper has said so.

based on RPs behavior with vsync on and TB disabled dropping to 30fps when 60fps cannont be reached, i would say its correctly implemented. In a render ahead setup that behavior would not be seen.

 

depends on your perspective i guess.

Theoretically any frame discarded from the back buffers as being older than the most current frame technically can be called "skipped", as its never sent to the front buffer for rendering.

As far as DFC @ 59, 1 frame out of 60 per second is not being rendered in the back buffers. Again depending on your persective, this could be construed as skipped.

 

sry to bring this back up, but i am always forgetting and stumbling upon this subject especially due to my inactive periods in gaming..

my question is, which is the best setting flip size queue when using tb and v-sync?
is it working together or at all in such a setup?

right now i am trying to find a good way to play the new pro evo soccer game, fps is 60 most of the time(60 hz monitor), rarely goes up to 61
that is during gameplay, i dont care about the fps drops in cut-scenes/replays that much
their new engine(some sort of adapted fox-engine) has no vsync setting any more and therefore i guess no tb as well

vsync is a must due to tearing and generally in PES to avoid this jerkiness

will a fps cap to 59 help in my scenario?
(all using Radeon Pro, i have D3DOverrider too)

 

Wroooooooong. Ugh sometimes I wonder where people come up with this stuff. So much misinformation on the web. As a species we are fixated with the easiest solution which in the case of the web is always a crapshoot. In this case, triple buffering does not work in SLI until nvidia gets with the program. It can't be forced in win8/8.1 because A) nvidia likes to keep the cool features in NVCP for OGL and B) d3doverrider is incompatible.

If your fixated on using Vsync (as I am) and your using SLI (as I am) you either cope, or deal with miserable fps faceplants.

Perfect example. Wow has an in game triple buffering yes? (Rhetorical)

I use 4 titans and every time it drops below 60fps it insta drops to the 30 range. It's miserable. Ffxiv same thing. However it doesn't have a triple buffering option anyhow. (In an older OS forcing it via d3doverrider would likely work but) you get the point.

Unfortunately it's one more reason to stay away from multi gpu if at all possible. Especially on the nvidia end.

With that said, This is the internet so take what I say with a grain of salt and check it out for yourself.

Until next time! (This message will self destruct in . . . )

 

wow, necro thread is necro

lol

 

http://stackoverflow.com/questions/3082379/is-triple-buffering-really-a-free-performance-boost

A quote from the excellent "Real-Time Rendering" book (http://www.realtimerendering.com/) by Akenine-Möller and others, page 835, which pretty much sums up what you have already suggested in the answer to your own question, considering lag:

"Triple buffering has one major advantage over double buffering. Using it, the system can access the pending buffer while waiting for the vertical retrace. With double buffering, a swap can stall the graphics pipeline.[...]The drawback of triple buffering is that the latency increases up to one entire frame. This increase delays the reaction to user inputs, such as keystrokes and mouse or joystick moves."

As a side note 'up to' can mean 0 (linguistically, not sure if that applies here).

 

little bit of lag in responding to the thread

 

"Why not always have triple buffering on?"
Until DirectX 11, triple buffering increase input latency, so having it always enable is not a good idea. About increased memory usage, with today hardware that's not a big deal. So it's all about latency.
Fortunately, starting with WDDM 2.0 there is a better alternative. You can read more about here (in the article Intel calls it "Game Mode", while classic DX triple buffering is "Classic Game mode"): https://software.intel.com/en-us/articles/sample-application-for-direct3d-12-flip-model-swap-chains

 

wddm 2.0 and dx12 werent really a thing when this thread started.

lol

 

oh, I did look at the OP date, I checked only the last post timestamp :formal: