D
Deleted member 11852
Guest
That is actually in there, right under the other statistics.
Digital Foundry Article Technical Discussion Archive [2015]
- Thread starter Deleted member 11852
- Start date
-
- Tags
- digital foundry
- Status
I know, I hit the "post reply" accidentally, and I had to edit my post. You are too fast for me!
Technically it's not "dropped" quite contrary, it stays longer than expected.
But what does this metric means? If the target was 30 fps, relative amount of "dropped" will be 50% and the absolute probably huge. Why they state the absolute amounts then?
The previous frame is longer, the missing frame is dropped.
You only drop frames when the renderer cannot catch up with the target refresh rate due to the new frame being unfinished. You don't drop frames if your performance is way above the target. You only drop frames if you go under the target.
liquidboy
Regular
I can only speak on behalf of Dx and XB1 ...
XB1 has the ability to render 3 surfaces in parallel, known as HW Display planes ..
Display Plane 1 & 2 is for the Title (game) - a games 3D content and HUD can be displayed in 1 & 2 respectively
Display Plane 3 is for the System - eg. the snapped app, or tiled HUB home page is rendered in this surface
Each Display Plane consists of a single DirectX object called a Swap Chain. Which is a chain of buffers that contain the pixels for displaying ( technical term is presenting) ...
DP1
- Swapchain 1
DP2
- Swapchain 2
DP3
- Swapchain 3
note: each of the swapchains can run at different framerates..
Now each SwapChain can have up to 3 back buffers , and each of these BB's can exist in a state of Available, Pending, Visible
DP1
- SC1
-- BackBuffer 1 (state : available, pending, visible)
-- BackBuffer 2 (state : available, pending, visible)
-- BackBuffer 3 (state : available, pending, visible)
DP2
- SC2
-- BackBuffer 1 (state : available, pending, visible)
-- BackBuffer 2 (state : available, pending, visible)
-- BackBuffer 3 (state : available, pending, visible)
DP3
- SC3
-- BackBuffer 1 (state : available, pending, visible)
-- BackBuffer 2 (state : available, pending, visible)
-- BackBuffer 3 (state : available, pending, visible)
The "States" are defined as ....
- Available: the driver can target it for rendering.
- Pending: the game enqueued the buffer into the presentation queue by calling " Present()" on it at some time in the past, but the driver has not yet shown it on the screen yet.
- Visible: the back buffer is currently being displayed on the screen.
VSync can automatically flip these BB's between these states
Basically each swapchain can have only a single BB in "Visible" state, and it got there when a VSync switched it from "Pending" ..
"Available" => "Pending" => "Visible"
Now a "Dropped" frame technically, in Xbox One's case, is when a BackBuffer in a "Pending" state (ready to be switched and presented in "Visible" state) is switched to "Available" instead .. ie. "Pending" => "Available" (skipped going to "Visible")
Now : Xbox One XDK as of December 2013 stopped frames from being allowed to be dropped , that is its impossible to go from "Pending" to "Available" without having gone thru "Visible" ...
Now I've great skipped lots of details especially around the different vSync intervals (0 = immediate swap, 1= 60fps swap, 2= 30fps swap etc ) Those details can be found in the leaked xdk documentation...
Also the other major piece of information I left out is how there is a separate "presentation" queue devoted to presenting the buffers, and no longer will this be done by the CPU/GPU (as per xbox360).. again the details for this are in the leaked xdk
BUT to sum up .. there should be no dropped frames as of dec 2013, as all "pending" back buffers become "visible" and composited via the presentation queue..
Sry for long winded answer BUT I found presentation interesting on the xb1 and dx and wanted to share
I can only speak on behalf of Dx and XB1 ...
...
BUT to sum up .. there should be no dropped frames as of dec 2013, as all "pending" back buffers become "visible" and composited via the presentation queue..
Sry for long winded answer BUT I found presentation interesting on the xb1 and dx and wanted to share
It's technically very interesting about the XB1 'guts', but that is not what means dropped frames in the context of the Digital Foundry article which is:
In a uncapped 60fps game outputting at 60hz: 2 consecutive identical frames = 1 dropped frame.
liquidboy
Regular
My apologies ....
I got caught up in the idea of "dropped frames" and totally missed the context, that being the DF article..
Whilst the XB1 does not "drop" frames, assuming my understanding of the xdk is correct, what happens is ....
1. Stalled presents - the CPU/GPU runs too far ahead and thus stalls a present of the Back Buffer, this might have the appeareance of the "visible" BB appearing longer than a frame..
2. Screen Tearing - VSync disabled and a threshold is set eg. 10%.. thus 2 back buffers are presented .. so backbuffer 1 currently visible and backbuffer 2 10% presented .. these 2 rendered back buffers appears like a screen tear..
So knowing the above.. It could be that DF interprets these "stalled" presents as a "dropped frames" because the present is delayed making it appear like the same "visible" BB stays longer than 1 frame?! Totally guessing here ..
I have seen in Assasins Creed Unity situations where frames are backed up then suddenly several frames suddenly render consecutively making it appear like a fast-forwarded video .. I guess under DF's definition most of those frames were "dropped" .. However in reality those frames actually rendered in the end, albeit delayed (stalled presents) ..
See below.
Same as above: that's cool and all that, but there is no way that information is available to DF upon examination of the video stream.
That's also cool and all that, but how DF know that we are in "uncapped 60fps game outputting at 60hz"?
It's obviously not capped to 30, and the consoles both output on 60Hz progressive-scan video signals.
Calling it a "60fps game" is a little nebulous, but the assumption is that "a 30fps game" implies capping to 30fps.
If we want to speak more precisely, we can just say that (as a vsync'd game on a 60Hz signal) it's a game that's capped at 60fps.
Ok, if it's capped. What will be the "dropped frame" number?
Which is a very strange thing to say.
To me "30 fps game" means "30 fps target", not more not less.
And obviously there is no way to know that using video stream analysis.
TL;DR as I suspected this whole "dropped frame" business is some strange number that does not represent anything of value.
It it were capped at 30fps, they'd assume dropped relative to the (presumed) 30fps target, and the number would be much lower.Ok, if it's capped. What will be the "dropped frame" number?
(And at its current performance level, if it were capped at 30fps, it would spend most of its time not dropping frames.)
If you're vsync'd and your target is 30, it's usually considered a good idea to cap at 30fps since going over will add judder. Being smooth while resting at 30 is the entire reason to use the cap, so any games capped at 30fps are generally considered to be "targeting" 30fps.
I think it's a little weird, but it's not something wildly abstract.
I'm still in awe that some very simple topics like measuring frame times are handled so poorly in the internets.
It's easy: everybody will agree that the perfect frame time graph is the one that is perfectly horizontal.
So, to measure the "imperfection" we just produce a derivative of the frame times. And because first order derivative will not tell us much (sampling, linear aproximation and all that jazz) we use second derivative, i.e. "average of abs of second order central difference" is probably the best estimator we will ever get. That's it.
It's easy: everybody will agree that the perfect frame time graph is the one that is perfectly horizontal.
So, to measure the "imperfection" we just produce a derivative of the frame times. And because first order derivative will not tell us much (sampling, linear aproximation and all that jazz) we use second derivative, i.e. "average of abs of second order central difference" is probably the best estimator we will ever get. That's it.
Yeah, but if we are talking about game with existing judder. Because there is no point in talking about perfectly synced ones.
There should be a way to measure that judder. Which is not achieved by measuring the "dropped frames".
It will produce the same result if 50% of our frames are 1 ms below or above target frame time or 10 ms above or below. Where I think most people will obviously see that first game is much more stable.
I know people who work on games who would disagree.
Any frame that they would like to display in order to meet their target frame rate of unique, properly paced frames, but are unable to display, is a missing, skipped, dropped ... (whatever) ... frame. "We were dropping frames when ...." etc. It's very conversation friendly terminology that artists, testers, journalists, reviewers, ineternetians use to talk about new, unique frames that "aren't there" for whatever reason.
It's the same information, presented differently, that could make up a frame-time graph for a vsynced game.
Such data and such conversations may not mean anything to you, and that's your right! But to say it doesn't represent anything of value is simply your opinion. To many (most?) who like to talk about these things it's neither strange nor valueless.
Well, not without better granularity. Simply giving a number of dropped (relative to a standard) frames over a duration is equivalent data to giving the number of new frames over that duration, and thus is the same as giving the average framerate over the duration, except in a way which is rather weird and requires more context to understand what it means.
I don't follow.
Last edited:
Ok, if it's capped. What will be the "dropped frame" number?
Which is a very strange thing to say.
To me "30 fps game" means "30 fps target", not more not less.
And obviously there is no way to know that using video stream analysis.
TL;DR as I suspected this whole "dropped frame" business is some strange number that does not represent anything of value.
In that particular game the "dropped frame" data is directly another way to present the average framerate. In the case of the PS4 game, 19054 being the total number of measured frames, 5332 is the number of consecutive identical frames ('dropped frames'):
(19054 - 5332) * 60 / 19054 ~= 43.2 which is the exact average framerate number given by DF.
You could say in this particular game this data is redundant but even if repetitive it's another way to present the data, like the 28% number is another.
You can't know the number of dropped frames unless you know the number of frames that you were expecting, which necessarily requires expected/targeted frame rate and sampling interval.
Dropped frames and presented frames are directly related. If you capture the data for frames presented, you have the data for "frames dropped".
Whether you compare to a baseline of 0 fps or 30 fps or 60 fps or whatever, you're basically looking for the same thing, so long as you're ignoring accurate temporal representation in the frames that are presented at the time they are presented.
That would be 100% correct if all games were targeting 60Hz, but that's not the case usually. And even more so with PC games where vsync and frame limiters are not that common.
It's not valueless if we intended to draw these frames but di not succeed. But that's true only if you know for sure what was the plan. Blindly assuming that everybody wants 60Hz at all times is strange.
+1
If you're able to somehow measure correct frame times for each frame. Then I propose the following (to get an estimation of judder):
let t_n denote a frame time for frame n
t_(n-1) denote a frame time for frame (n-1), previous frame
t_(n+1) denote a frame time for frame (n+1), next frame
then:
diff_k = (t_(k-1) + t_(k+1) - 2*t_k)/2
AVG(ABS(diff_k), k=2, k=(n -1)) will be our estimator of the judder
the bigger the number the more judder we have
- Status
Similar threads
