that implies the default is actually 2, and that setting it to 3 is simply non-functional. This is also what flood's testing shows. This is probably a d3d issue, not a GPU or game issue.Glide wrote:I'm not sure that I understand what point you are trying to make here.
All of the discussion here is about a V-Sync On scenario, where the goal is to get the smoothest gameplay possible.
Keeping things low latency at the same time is nice, but not the primary concern.
And you seem to be contradicting yourself in the same post.The upper graph shows that the max pre-rendered frames makes no difference to latency when V-Sync is disabled.Sparky wrote:Dunno why you say that it reduces latency, the difference between 2 3 and 4 is within the error bars for the first graph, and they're all over the latency of 1.
However, the lower graph shows that setting the max pre-rendered frames to 1 (the default is 3) removes a frame of latency when V-Sync is enabled - which is why I said that it reduces latency.
And repeat that for every single step in the pipeline. Say the GPU spends 2.5ms on each frame, and the CPU spends 1ms working on each frame. With v-sync off, you get a buffer flip every 2.5ms, so you get 2.5ms of latency from the GPU calculation time, 2.5 or 5ms from the flip queue, 1ms from CPU calculation time, 1.5ms from the CPU waiting on the flip queue, a random 0~2.5ms of input data waiting on the CPU, and then tack on the USB, mouse, and monitor latency. With v-sync on(double buffered) and no framerate cap, you get 2.5ms from the GPU calculation time, 14.2ms from the GPU waiting on the display, 16.7 or 33.3ms from the flip queue, 1ms from CPU calculation time, 15.7ms from the CPU waiting on the flip queue, a random 0~16.7ms of input data waiting on the CPU, and then tack on the monitor/mouse/USB latency.And in my own testing, reducing this to 1 also improves frame pacing in most games.
In CS:GO, latency seems to be the same for all values >1.
In other games, each pre-rendered frame may add an additional frame of latency.
In the same post, and the subsequent post, you do seem to agree that setting it to 1 reduces latency??
I guess I just don't understand the mechanics of this.Sparky wrote:If it's not missing frames, the cap isn't doing anything. That would be identical to the latency for whatever v-sync PRF combo you were using uncapped. There is a caveat here in that a framerate cap very close to your refresh rate can take longer to creep into a high or low latency region, but a cap very slightly higher than your refresh rate will end up in the same place as no cap at all.
I thought the point of the cap was to push the render time to the last possible moment before it is sent to the display, to reduce latency.
Using Max Payne 2 as the example again, it's running at over 400 FPS (with 8xSGSSAA enabled)
So without a cap, the frame is rendered in the first 2.5ms and there's 14.2ms latency while it waits for the next refresh.
I thought the point of the cap was to push the render time towards the end of that 16.67ms period, to minimize the delay between your input and the screen updating.
Now, if you leave v-sync on and cap framerate at 59.9fps in the game engine(like fps_max), you get a random delay between 0 and 16.7ms for the input data to get read by the CPU, 1ms of CPU processing, 0ms for the flip queue, 2.5ms for the GPU, and a random 0~16.7 of the GPU waiting on the next refresh.
Understand?
you'd still get tearing. The best option is g-sync or freesync. with framerate capped in game just inside the VRR range.
If you have access to that game, I suggest you try it rather than making assumptions.
Implementing a cap, whether that's 58 FPS or 65 FPS (for 60Hz V-Sync) makes a huge difference to latency when it's set to 8 pre-rendered frames.
65 FPS does not reduce latency as much as 58 FPS (I guess there is an additional frame) but it is still a significant reduction from running uncapped.
I'm not sure how you are supposed to get smooth gameplay if you are capping the framerate below the refresh rate.
That just results in tearing (adaptive v-sync) the frame-rate dropping to 30 FPS (regular v-sync) or stuttering. (triple-buffering)
All of which go against the intended goal here of having the smoothest gameplay possible.
And if that's the case, why not just run with V-Sync switched off at the highest framerate you can?
you can hover over the different bars to see the actual number.Well it makes a huge difference in a number of games/engines. That is why I started this topic, if you read the first post.Sparky wrote:prerendered frames shouldn't really do anything to frame pacing, except provide some buffer if the cpu portion of the graphics pipeline freezes for a bit.
Here are the results when the game is allowed to set the max number of pre-rendered frames, and I used an RTSS cap since people said that may improve frame-pacing. (it did nothing)
And these are the results when the max number of pre-rendered frames is set to 1.
Zero allows the application to specify what value to use. The default is 3 if it does not specify anything. That's why NVIDIA replaced "0" with "Use the 3D application setting".Sparky wrote:I did just test flip queue 0, 1, 2, 3, and 5 in CS:GO with double buffered v-sync and no cap(via radeonpro). 1 reduced lag by 1 frame, 0,2,3,5 did nothing. I added the data from 1 to the graph
I'm sorry, but the labels on your graph are quite cryptic.Sparky wrote:The implementation of triple buffering should be the same regardless of where you turn it on. If your framerate is limited by v-sync, it does add input latency, othewise, not so much: https://docs.google.com/spreadsheets/d/ ... nteractive
If I am reading this correctly, in-game triple buffering has a frame of latency (I assume - the scale is useless) lower than forcing it externally via RivaTuner? You also mention that RadeonPro has an additional frame of latency over RivaTuner.
Uncapped with vsync off is about 7.3ms
In game framerate cap at 85fps with vsync off is about 14ms.
In game framerate cap at 85fps with vsync on is about 21ms.
RT cap at 85fps with v-sync off is about 24.5ms.
RT cap at 85fps with v-sync on is about 31~32ms.
Uncapped with v-sync on is 56, 67, or 78, (double buffered with FQ=1, Double buffered with default FQ, and triple buffered with default FQ.)
triple buffering is set in game for all test runs, the only thing changing between triple buffered runs is where the FPS cap is coming from.
This suggests that the implementation differs depending on where it is set.
No idea, I haven't used the d3d overrider to force triple buffering. Have a reference?I am using a GTX570 just now. NVIDIA only have the option to force triple-buffering for OpenGL.Sparky wrote:Dunno what GPU you have, but radeonpro also lets you force triple buffering. In the above graph I just turned it on in game.
I was under the impression that D3D Overrider's "triple buffering" increases the flip queue size, which is not the same thing as true triple-buffering - hence the additional frame of latency.