Triple Buffering on the 360

Double buffered v-sync drops are going to be 1/2, 1/3, 1/4... of the refresh rate depending on how long it takes for successive frames to be rendered. So for 60Hz sync, the frame rates will be 60, 30, 20, 15 and so on. Or rather, if the next frame isn't ready at +16.666ms, it will continue to show the current/old frame until the next frame is done, but only at successive sync times.

30fps games are just frame-limited. If they're DB'd they drop to 20fps and so on.

 

Thanks for the explanation

 

Frame-rate is dependent on sampling time; rate = frames/time. If you take a single frame interval, with v-sync'd DB it'll be 1/60th of a second, or if it overruns that period, 1/30th second, and if it overruns that, 1/20th. However, over the course of a second, with v-sync'd double buffering you may have one dropped frame out of 60, resulting in 59 fps.

Frame interval depends on how much time between refreshes, and if you are v-sync'd you can't have a frame interval any less than an integer ratio to the display refresh, 1:60, 2:60, 3:60 etc.

 

COD is pretty unlikely, they went for 60fps because they wanted the fastest possible feedback and triple buffering would go against that goal.

 

That's what I thought, for both games actually, but if I'm understanding the posts here, it would have to be triple buffered since the game is v-synced but still have variable frame rates.

Forza I question still since that game doesn't have the wavering frame rate CoD games have.

 

Twice as much.

 

You're still confused.

 

Nope exactly the same amount, you're not drawing to more than one buffer in a frame, so the amount you copy/frame is invariant.

 

That doesnt make sense.

You're generating more frames per second, then you're copying more out of the EDRAM per second.

The only way what you're saying makes sense is if everything I've heard about tiling is wrong, since if the EDRAM can hold 2 frames at once, it can clearly hold one whole one. Thus tiling should never be needed

 

see above

 

As I said earlier, the games are totally v-synced, so having a double buffered setup would actually make the control sluggish due to constant drops.

 

Yes because that was so insightful

Oh wait, no it wasnt

Look, the problem with tiling was copying the buffer out of the EDRAM (cause it cant fit a whole one in some cases) is a bottleneck. So if it cant fit one, then it cant fit two.
So it makes sense copying another buffer out is that much larger of a bottleneck/disadvantage. Either that or all the times I read tiling was a problem, were all wrong. I am not confused, and it's arrogant to assume so.

I find it funny people are getting offended I suggested it. Someone asked for a reason, I gave my theory. Even if it's wrong that doesn't mean I was confused.

So please, if you have more info than I, by all means correct me. It was the first theory that came to mind. I'm not offended by it being wrong. I don't care if I'm wrong. I like being taught. I come here for technical information.
I don't like being insulted. So don't make assumptions about me.

 

NeoTechni, if you like being taught, then please reread Graham's considerate and considered posts. If they don't enlighten, then consider searching for 'multiple buffering' on Wikipedia. If that doesn't help, then let me take a feeble stab at it (though people with a better understanding than me have already tried). AFAIK, triple buffering neither makes your GPU render faster nor makes it render multiple frames at once, which seems to be your misunderstanding. TB simply creates another back buffer for the GPU to render to. At 30fps, it's still drawing a frame every 1/30th of a second, only there's an extra frame (buffer) between your input and the display (a1/30th of a second delay b/w your input and the resultant rendered frame). The EDRAM doesn't hold two back buffers when TBing. it still works on one at a time, tiled or not. And as it's not rendering two frames at once, just rendering one frame behind what you see on screen, there's no worry about having to move twice as much data to RAM per frame. Same framerate ==> same amount of data written to main mem per frame ==> same mem space per buffer, just an extra rendered frame (buffer) b/w the one being displayed and the one being rendered.

 

I accept that, and thank you for not resorting to insults like the above.

 

You would never have felt insulted (and no-one insulted you, as you were confused!) if when several fairly knowledgeable people started explaining that eDRAM has no effect, instead of telling us we're wrong, you questioned your own position and asked how it works, elliciting an explanation of what triple-buffering is to correct your misunderstanding.

 

It gets me sometimes, but it's basically down to a difference between vsych and a vblank isn't it? In that, if your game is vsynced under normal load in a double buffer situation, and cannot hit say 60fps, and you want to avoid tearing, the front buffer is output twice as the back buffer is being finished.

Even if you only miss the vblank (the point where the display output hardware wants to go through another cycle) by say 10 vertical lines, you can't swap the buffers until the next vblank, thus having to display the same front buffer twice, and not being able to render another frame until the front/display buffer pointer has been swapped. In this case, you're always going to be behind, and the frame rate lowers accordingly.

In a triple buffer situation, if you miss your render time frame by 10 lines rendering into the back buffer, you can still swap the front buffer/display pointer to the middle buffer that is already complete, have the back buffer finished 10 lines later, and then continue with the next frame in what was previously the front buffer, making the previous back buffer now the middle buffer. You never have to skip a full frame or even a 99% frame waiting for the swap with the front buffer.

Is this correct?

 

i hate how every time i read about frame buffers i just end up having more questions and becoming more confused. is there a resource that better explains this stuff with pictures

im a visual learner.

 

I'm sure someone could do that with a bit of work, but I see it like this

Double buffer situation

Frame 1
1: Display Output Hardware -> Buffer A
2: Rendering Hardware -> Buffer B

In a 60fps situation, 1 wants to know where in memory it should start fetching data from every 16ms. In this case Buffer A.

As the display output hardware is sending data to the display device, the game is rendering the next frame in 2 or Buffer B.

If the game can render Buffer B faster than 16ms, when the display output hardware asks for a new position in memory to start outputting from, the game tells it to now look at Buffer B, as it is finished. So..

Frame 2
1: Display Output Hardware -> Buffer B
2: Rendering Hardware -> Buffer A

Then the cycle repeats with the display output hardware sending data from Buffer B to the display device and the game renders the new frame on top of Buffer A without clearing it.

In the situation now where the display output hardware asks for a new position, and the rendering hardware has not finished with Buffer A, two things can occur. It can either swap the two regardless, but then part of Buffer A will still have data from Frame 1, inducing a tear, or it can let the display output hardware show Buffer B for a second time while it finishes with Buffer A.

When this happens, the display output hardware may only be say 5% into sending out the data from Buffer B when the game has finished rendering into Buffer A. It now has to wait 95% of a frame before it can do anything more - when they are finally swapped again.

If I'm right the following happens.

Triple buffer situation

Frame 1
1: Display Output Hardware -> Buffer A - Blank, totally black.
2: Middle Buffer B - Totally black.
3: Rendering Hardware -> Buffer C

The display output hardware shows a blank screen - Buffer A. In the mean time, the rendering hardware is rendering into Buffer C. If when the display hardware asks for a new cycle, it is given Buffer B. So you get this situation:

Frame 2
1: Display Output Hardware -> Buffer B - Blank, totally black.
2: Rendering Hardware -> Buffer C
3: Old Buffer A - now the back buffer.

The display output hardware is now sending data to the display, again a total blank. In the mean time, the game finishes off rendering into Buffer C. Once this is done, the game starts rendering the next frame into Buffer A. If at any point, when the display output hardware requests a new frame, and 2 is not complete, it's forced again to display 1 twice.

So, in these circumstances, if your renderer misses say 20% of the 60fps in a triple buffer situation, it will still output a higher fps than 30, as it never has to stall and entire frame for up to 99% of a frame waiting for the next swap with the front buffer. It can finish what it was doing and then get on with rendering into the third frame buffer.

 

still an insult
i was not confused
i was under the impression that triple buffers was done to increase the framerate, that was wrong but that doesnt make me confused

 

It is used to increase the frame rate without tearing. As far as I understand.

With the 360 though, the eDRAM sort of gives you a scratchpad for rendering, what is in it still needs a copy out to the back buffer if it's double buffered or not. The display hardware still needs a completed true back buffer in main RAM before it can do the pointer swap though.