Discussion in 'Videocards - NVIDIA GeForce Drivers Section' started by Tastic, Jul 16, 2012.
I already posted that. Use CRU to see it, or use www.vsynctester.com.
At GTX 970/980 times, I benchmarked min-fps in cpu-limit and typical avg-fps in gpu-limit in BF4 quite thoroughly and prerenderlimit 1 definitely did not cost any performance over app-controlled, apart from a very minor deviation which could also be just pure chance.
I see, would you recommend 138 as a global cap for a 144hz G-Sync monitor and also, I see that it is preferable to use an in game FPS Cap if possible, would it be a bad idea to set the cap to the same limit as RTSS limit or should it be dropped x amount of frames below the RTSS cap?
I don't know. I don't use RTSS when I don't need it. For games that have their own good capper (not all in-game cappers are good), I disable the RTSS one.
I see, I'll consider that. Would there be any negatives for me setting certain in game FPS to 136 at all as 138 is a common recommendation?
I'm just making sure 138 isn't some magic number in the FPS limit world.
You can put it higher. 142Hz seems to be enough when using RTSS (as tested by jorimt on his Blur Busters forum thread.) The "6-8FPS lower" recommendation is just a safety-margin. A "just to be sure" thing. But jorimt's tests on the Blur Busters forum have shown that 142Hz *should* be enough.
136 vs 138 vs 140 vs 142 doesn't make any difference though. It's just a 6FPS/6Hz (0.3ms frame time) difference. Doesn't really matter, which is why I generally just recommend "~6FPS lower than max Hz".
When it comes to in-game frame cappers, Unreal Engine games always seem to have the best one. Other games are hit and miss. Many seem to have frame pacing issues. The worst of the lot seems to be CS:GO's frame limiter ("fps_max"). But who plays CS:GO with gsync anyway, we want 300FPS there
Appreciate the detailed response, sometimes you just a little clarification. I'll keep it in mind and yeah, CS:GO is one game we can agree needs FPS unleashed and wild.
There are few games that they DONT have good (responsive) fps capper, in that case you prefer RTSS (and disable or put highest setting, 144 if possible ingame fps limit).
TBH I mostly use rtss but I always test first ingame and compare after..
About global cap, it won't hurt to have 138 (or 139) but the gold rule is to cap per game @average fps, for example if you mostly see 100 cap to 100..
don't get crazy about it, let Gsync do it's job.
Dont care how old thread is as this is still relevant.
There is DEFINATELY a huge difference between pre-rendered frames 0 and 1 and i am very upset that i can no longer set it back to 0
I understand that technically you can not have 0 pre rendered frames as explained above. But there clearly is a difference so the only logical explanation is below.
The only logical explanation is that pre-rendered frames 0 in the past actually meant 1. THIS IS THE ONLY LOGICAL EXPLANATION! And 1 meant 2. and 2 meant 3. etc
Now we are all forced to have the setting on at least 1 instead of 0 which means we are all actually playing with 2 frames rendered ahead because new nvidia workers did not know that 0 is actually 1. This sucks
Perhaps new nvidia workers did not know that the 0 setting actually meant 1 so they removed the 0 setting and now the lowest we can go is 2 frames ahead instead of 1 which sucks.
1 is not 2.
Some games you can change pre-rendered frames via CFG such as bo3, bf1, overwatch etc.
Setting 1 via driver or CFG results in the same outcome.
Battlesense tested this and they both had the same frametime/input lag.
Therefore your assumption 1 is 2 is not correct.
Whatever your 'issue' is lies elsewhere
In darksiders2 at launch if you set max frames ahead to 0 it was a microstuttery almost unplayable disaster. But if you set it to 1 it was smooth as butter. And a lot of people were thankful for me finding this solution. So tell me again how they are the same
I think this is the same parameter Frostbite3 games let you control with RenderDevice.RenderAheadLimit and I think these games always override the driver setting (or more probably these games simply can't be forced to specific numbers by the driver).
According to my limited testing with MEA and DAI, a RenderAheadLimit 0 either means "unlimited" (no limit) or "default" (no-op), 1 causes a huge rise on the CPU utilization and I guess that's what causes a notable drop on GPU utilization (though I would need to test this with a much faster CPU or much slower GPU to confirm that correlation) resulting in a notable fps drop (although the games seem to feel a little more responsive when the fps is high enough regardless of this drop), I can't really tell the difference between 2 and 3.
Some people seem to think that V-sync buffers are technically part of this queue but that would make tripple-buffering V-sync and RenderAheadLimit 1 impossible (yet I get the same performance drop if I set the limit to 1 while keeping tripple-buffering ON and the fps drop helps to confirm I still have tripple-buffering). Although, the idea is interesting: why do you need both? Shouldn't it be possible to run without a queue when you have V-sync buffers (and effectively use those as your queue) to minimize the lag impact of legacy V-sync? (And my knowledge is even more limited about that but I think even G-sync has a buffer for a single frame on the GPU side.)
Regardless of the arguments, i really just want the 0 setting back
You can't have 0 pre rendered frames.
CPU HAS to render frames for GPU to process.
You can't argue against that.
So again, already have data testing what I said.
Regardless. 0 always = 1 in drivers a long time ago.
I thought there was still some proof that there is a measurable difference between the old drivers that have a 0 setting, and 1.
A potential misunderstanding could come from how we interpret the meaning of "rendered ahead of the GPU":
ZERO could mean: the CPU wakes up, processes a frame skeleton, passes it to the GPU and goes to sleep until the GPU fully finished with that frame, then the CPU wakes up again to render the next frame skeleton while the GPU sleeps... (and so on). If this is the "baseline" then ONE means the CPU is allowed to start processing a frame skeleton while the GPU is still busy with the last one (but every skeleton has to be flushed from the CPU before it can work on the next).
However ONE could also mean (if the "fully serial mode with sleeps" is simply never considered/allowed) that the CPU is allowed to put a whole frame skeleton into a CPU queue (ready to be passed to the GPU as soon as the GPU becomes ready to start working on it) and start working one step ahead (do it's job on the next, n+1 skeleton, ahead of the one which already sits in the CPU queue but didn't hit the GPU yet). In this case, if the CPU is very fast, the CPU queue might hit 2/2 (only ONE frame was worked on "ahead", yet the queue could rise to TWO frames: the one you wanted in order to keep the GPU busy and one extra ahead of that to keep the CPU busy while it waits for the GPU).
Somehow I doubt the "serial mode with sleeps" was ever considered a "sane" mode of operation in this century (but I guess that's what the ZERO setting was if those claims are true and not placebo memories).
You guys can use gpuview to view the effect of maximum pre rendered frames. From my testing I observed that setting maximum pre rendered frames to 1 is pretty much really 2 pre rendered frames. The driver lets 1 full frame into the context queue and then allows part of the next frame into the queue. I have read that with amd drivers, setting this to 1 really is 1 pre rendered frame.
plz papa OP tell us about HPET TOO!
The truth is that it's no longer available, so deal with it.
I find 1 causes no stutters in anything, so 1 seems to be the sweet spot.
In games where 1 stutters, 2 stutters too. 3 also. In fact, the higher this is set to, the more annoying the stutter gets. 1 has the least annoying stutter characteristic. The stutter is perfectly even (high frame times, but evenly so.) With higher values, the stutter is hiccup-like. Low frame times followed by high frame times, repeat.
I'm not sure why this setting even exists on non-SLI systems. It should be 1 for everything by default.