The Framerate Analysis Thread part 2

liolio said:
Same player shoot again, how can you tell appart double buffering + v-sync and triple buffering?
You can't if the game doesn't "release" v-sync to preserve framerate.
Click to expand...
:???: Is it possible don't take how something a personal, thanks? This type of comment is really annoying. Sorry for the ot mod. A question for Mazinger: the triple buffer require 60hz to guarantee a smooth fps?
 
Last edited by a moderator:
MazingerDUDE said:
When a game is v-locked with double buffering, its frame rate will be locked at low common denominator of 60 devided by an integer (60, 30, 20, 15, 12 etc..) which means when the game can render a scene at constant 29 fps, it will be locked down to 20.

No matter how steady an engine can render, it can go below 30 at times and if you test to stress the engine you can easily tell whether it's v-locked or not.
Click to expand...
OK, I guess I'll make you suffer some more, actually triple buffering is clearer (it's pretty straigh forward AND elegant solution) to me in the way it works. I understand why you have to choose finite values for frame rate when you v-lock a game.
(Basically synch has happen at a multiple of 1/60 second). You can't exceed this value (whereas triple buffering allows any value from zero (bothering :LOL:) till 60 fps).
What I don't get is why the frame rate would have to go all way down from say 30 to 20. (I don't exactly don't get it it's more like it sounds weird to me).
I'll take the most likely case say the game is locked/synched @30 fps.
Basically One new frame is supposed to be ready every 33ms (if the display refresh rate is 60Hz then every frame is displayed twice). Then if a new frame is not ready there is different choices about what to do (if I understand the mechanic properly):
1. the frame is dropped (thus the previous frame will be displayed to more times)

2. the frame is granted extra time to complete.Say on extra refresh of the display (16ms).
Basically it's equal to switch v-sync/lock @20fps (one new frame is displayed every three refresh of the display). Thus as you state the render can only run at 60/(x+1) frame per second. In our case 20fps. If you allow your frame more extra time to complete (33ms) then it's the same as lock your render @15 fps, right?
So far, so good. The interesting part is what happens next? The most logic possibility is that the next frame is handle in the standard fashion that is with v-sync/v-lock @30fps.
So basically if v-sync is never "released" (not sure this is the proper term) the render could fluctuate between successive 30fps, 20fps, 15fps modes but on an extend period of time you render can fluctuate anywhere between 15fps to 30fps depending on how many frames failed to complete in time. If the render never manage to deliver a frame every 33ms then the game runs @20fps, but it's really unlikely to happens.

3. you give up on v-sync/lock and you display the unfinished frame and you have a torn frame.

It looks like when the render runs good enough it's the option devs on the 360 favors as it allows for a more consistent frame rate and doesn't induce extra input lag and frees some few MB of RAM.
 
liolio said:
3. you give up on v-sync/lock and you display the unfinished frame and you have a torn frame.

It looks like when the render runs good enough it's the option devs on the 360 favors as it allows for a more consistent frame rate and doesn't induce extra input lag and frees some few MB of RAM.
Click to expand...
I don't know the reason but seems the ati card tend to lose more fps (10 fps) than the nvidia (3 fps), when vsync is totally actived, so it seems there is an explanation after all to prefer the double buffer on the 360. I search the link. P.S. Unfortunately I don't found a link :cry: Later I try again.
 
Last edited by a moderator:
assurdum said:
:???: Is it possible don't take how something a personal, thanks? This type of comment is really annoying. Sorry for the ot mod. A question for Mazinger: the triple buffer require 60hz to guarantee a smooth fps?
Click to expand...
OT
I'm really sorry . Actually I already ask how one can tell appart both technique. The same player shooting was me, I was indeed asking again because I didn't get answer earlier. Basically I miss this very point a "triple buffered" game is likely to render at more than 30 fps at some point whereas a standard "double buffered v-locked" will never go above of 30 fps (bar it reaches 60fps) (it's a pretty easy differentiator but the idea didn't flash into my head). Thus as I had no response I entered a somewhat paranoid mode about people possibly trying to make point out of thin air...
It ends in a pretty inelegant manner as I asked you in a pretty rought manner you didn't deserve, how you can tell both techniques apart, etc. I'm really sorry and onlyit's only a proof of my own dumbness.
I really apologise :)
/OT

For your question (I'm not Mazinger Dude) from my understanding triple buffering as no impact on performances/frame rate, thus I guess it's smooth (depending on taste or perception of the frame) as long as the render run @30 fps and more.
 
liolio said:
OT
I'm really sorry . Actually I already ask how one can tell appart both technique. The same player shooting was me, I was indeed asking again because I didn't get answer earlier. Basically I miss this very point a "triple buffered" game is likely to render at more than 30 fps at some point whereas a standard "double buffered v-locked" will never go above of 30 fps (bar it reaches 60fps) (it's a pretty easy differentiator but the idea didn't flash into my head). Thus as I had no response I entered a somewhat paranoid mode about people possibly trying to make point out of thin air...
It ends in a pretty inelegant manner as I asked you in a pretty rought manner you didn't deserve, how you can tell both techniques apart, etc. I'm really sorry and onlyit's only a proof of my own dumbness.
I really apologise :)
/OT

For your question (I'm not Mazinger Dude) from my understanding triple buffering as no impact on performances/frame rate, thus I guess it's smooth (depending on taste or perception of the frame) as long as the render run @30 fps and more.
Click to expand...

Ah ok. ;) No problem.
 
liolio said:
OK, I guess I'll make you suffer some more, actually triple buffering is clearer (it's pretty straigh forward AND elegant solution) to me in the way it works. I understand why you have to choose finite values for frame rate when you v-lock a game.
(Basically synch has happen at a multiple of 1/60 second). You can't exceed this value (whereas triple buffering allows any value from zero (bothering :LOL:) till 60 fps).
What I don't get is why the frame rate would have to go all way down from say 30 to 20. (I don't exactly don't get it it's more like it sounds weird to me).
I'll take the most likely case say the game is locked/synched @30 fps.
Basically One new frame is supposed to be ready every 33ms (if the display refresh rate is 60Hz then every frame is displayed twice). Then if a new frame is not ready there is different choices about what to do (if I understand the mechanic properly):
1. the frame is dropped (thus the previous frame will be displayed to more times)

2. the frame is granted extra time to complete.Say on extra refresh of the display (16ms).
Basically it's equal to switch v-sync/lock @20fps (one new frame is displayed every three refresh of the display). Thus as you state the render can only run at 60/(x+1) frame per second. In our case 20fps. If you allow your frame more extra time to complete (33ms) then it's the same as lock your render @15 fps, right?
So far, so good. The interesting part is what happens next? The most logic possibility is that the next frame is handle in the standard fashion that is with v-sync/v-lock @30fps.
So basically if v-sync is never "released" (not sure this is the proper term) the render could fluctuate between successive 30fps, 20fps, 15fps modes but on an extend period of time you render can fluctuate anywhere between 15fps to 30fps depending on how many frames failed to complete in time. If the render never manage to deliver a frame every 33ms then the game runs @20fps, but it's really unlikely to happens.

3. you give up on v-sync/lock and you display the unfinished frame and you have a torn frame.

It looks like when the render runs good enough it's the option devs on the 360 favors as it allows for a more consistent frame rate and doesn't induce extra input lag and frees some few MB of RAM.
Click to expand...

It seems that you misunderstood the whole concept of triple buffering.

The frame rate is locked to the low common denominator in double buffering with v-sync, not because of the sync itself, but because your GPU is stalling once back buffer is complete. You have no more buffer to draw in until next vertical blank (waiting for sync) because both buffers are in use: front buffer - currently being displayed, back buffer - complete.

For example, let's say in a game you're able to draw 80% of image in each frame (1/60s). It'll take about 1.25 frame to complete an image, and without the v-sync, your completed image will go out to display in middle of 60hz refresh process of display, hence screen tearing occurs. (what you do is basically swapping buffer numbers, say buffer 1 is being drawn by display, and in the middle of it, you swap the buffer you'll get the rest of image to be buffer 2) Basically what v-sync does is to hold your image until next vertical blank to prevent this to happen. As I mentioned earlier, while you're holding the completed image (back buffer) for the next vertical blank, there's no more buffer to draw image to. In this case 80% + 80% = 160%, so 60% of GPU rendering is lost by the stalling, which will happen in every cycle, and the frame rate will be locked to 30, even when you are able to draw 48 images per sec (80% x 60 = 48), 18 will be lost due to the GPU stalling.

Triple buffering is as the name states, about using a third buffer to prevent GPU stalling. (you can continue to draw into the third buffer, once the second buffer is done) So you're able to output maximum frame rate with v-sync.

(I'm afraid grandmaster will be pissed off for me lecturing here while his frame rate detector is still not complete. I mean really, it takes no more than 5 min of wiki reading to figure out what this is all about ;))
 
Last edited by a moderator:
MazingerDUDE said:
It seems that you misunderstood the whole concept of triple buffering.

The frame rate is locked to the low common denominator in double buffering with v-sync, not because of the sync itself, but because your GPU is stalling once back buffer is complete. You have no more buffer to draw in until next vertical blank (waiting for sync) because both buffers are in use: front buffer - currently being displayed, back buffer - complete.

For example, let's say in a game you're able to draw 80% of image in each frame (1/60s). It'll take about 1.25 frame to complete an image, and without the v-sync, your completed image will go out to display in middle of 60hz refresh process of display, hence screen tearing occurs. (what you do is basically swapping buffer numbers, say buffer 1 is being drawn by display, and in the middle of it, you swap the buffer you'll get the rest of image to be buffer 2) Basically what v-sync does is to hold your image until next vertical blank to prevent this to happen. As I mentioned earlier, while you're holding the completed image (back buffer) for the next vertical blank, there's no more buffer to draw image to. In this case 80% + 80% = 160%, so 60% of GPU rendering is lost by the stalling, which will happen in every cycle, and the frame rate will be locked to 30, even when you are able to draw 48 images per sec (80% x 60 = 48), 18 will be lost due to the GPU stalling.

Triple buffering is as the name states, about using a third buffer to prevent GPU stalling. (you can continue to draw into the third buffer, once the second buffer is done) So you're able to output maximum frame rate with v-sync.

(I'm afraid grandmaster will be pissed off for me lecturing here while his frame rate detector is still not complete. I mean really, it takes no more than 5 min of wiki reading to figure out what this is all about ;))
Click to expand...
I understand triple buffering. I'm speaking about double buffering with v-sync.
 
Last edited by a moderator:
Thats a fairly good job with UE3 on PS3 imo...no tearing & 30FPS on avg can be considered as perfect.
 
MazingerDUDE said:
That's dissapointing

You get like 50% increase in frame rate in trade of.. something like 500% decrease in IQ :LOL:

http://www3.telus.net/public/dhwag/gundam1.jpg (Gundam Senki)

http://www3.telus.net/public/dhwag/gundam2.jpg (Gundam Crossfire)


(sorry for not so tech post, I couldn't help it :LOL:)

BTW the game's double buffering with v-lock

This game seriously needs triple buffering ;)
Click to expand...

very sad indeed, cant JP gundam dev learn how to make gundam games look good and runs good........ Best Gundam game I have seen is probably the one year war thats done by the ace combat team for PS2, best for system anyway but still got some slow down.
 
grandmaster said:
Well not really because Stranglehold and Blacksite Area 51 share an engine! Look at the gulf in performance there :D
Click to expand...

Aren't those quite old games with an old version of the engine? I assume EPIC pushed out most optimizations for PS3 after they compleated UT3....
 
ps360 said:
TRIALS HD DEMO
http://zoome.jp/ps360/diary/346/
Click to expand...
Nice to see they analyzed Trials HD too, and chose the largest track in the game for the analysis source. I was wondering if the analysis tools show full 60 fps, and how well the v-synch lock works in practice on various HDTVs. According to this analysis it seems to be perfect tearless 60 fps. Except after the level finish line. We intentionally put huge explosions after many track finish lines to promote the track finish. In the final game optimization phase we didn't optimize the level ending effects at all, because we kind of liked the slow motion effect. And that is visible in the analysis as well. All gameplay in the full version too is perfectly v-synch locked 60 fps. I am personally very nit picky on frame rate issues, and we spent a lot of time to verify that all our levels run at constant 60 fps without dropping a single frame.

I am not myself a huge supporter of triple buffering as it adds a slight bit more input lag. We made several technical choices to reduce input lag in Trials HD, but still our new fully multithreaded game engine provides approx 0.5 frames more input lag compared to our old single threaded game engine.
 
Last edited by a moderator:
I am noticing that a lot of the user-content in Trials does impact FPS in-game though, even when the scenes are nowhere near as complex as your own maps... are there level-specific optimisations?
 
You must log in or register to reply here.

Similar threads

Shifty Geezer
Digital Foundry Article Technical Discussion [2024]
138 139 140
Replies
3K
Views
246K
Boss
B
L
ARM based Game Consoles on the way?
2 3 4
Replies
73
Views
8K
Lurkmass
L
R
State of GDeflate *spawn
2
Replies
25
Views
2K
Remij
R
BRiT
  • Locked
Digital Foundry Article Technical Discussion [2023]
252 253 254
Replies
5K
Views
534K
chris1515
C
G
Nvidia G-Assist
Replies
2
Views
1K
Davros
D
Back
Top