The truth about PRE-RENDERING 0?

[kalston]

And how about using the GTX 670 without touching the so-called "input lag settings"? Quake games certainly work fine on my GTX 670 (using dev drivers 305.67 atm). It's also running in 3d clocks constantly just by having the "prefer max perf mode" in nvidia's global settings so I don't need to overclock or anything to avoid frequency fluctuations.

[SadButTrue]

Using default settings the GTX670 feels unplayable for me. I only recently gave up on CRTs so my tolerance for input lag is very low. The two biggest improvements are switching to No Scaling (which doesn't work properly) and disabling PowerMizer.

[zansiball]

in battelfield bc2 you can set renderaheadlimit=0 in the game config.

if you set it to "let 3d application decide" in the nvidia control panel will it be 0 in bf bc2?

[Prophet]

Originally Posted by zansiball

in battelfield bc2 you can set renderaheadlimit=0 in the game config.

if you set it to "let 3d application decide" in the nvidia control panel will it be 0 in bf bc2?

I set it to 0 in nvcpl and in the game and its more responsive than when having '1'. Why dont you try it. I also like to use rinput with bfbc2.

[SLI-756]

Arkham City pre-rendering can be disabled, the command OneFrameThreadLag=True, can be set to False.
it's found in bmengine.ini (C:\Users\yourusername\Documents\Config), set the bmengine.ini to 'read only' after tweaking and see how much input lag you've been playing Arkham with, note: without silly pre-rendering it's more hardware demanding.

[SLI-756]

OK i ran Arkham benchmark with pre-render set to app controlled then set to 1, setting it to 1 gave me a better framerate and interestingly enough was more demanding on gpu, gotta see how gameplay feels cause this '1' setting might just be what i'm looking for. lol
*the gpu boost kicked in with it set to 1, but didn't under app controlled.
First run 'app controlled', second (which produced better frames) '1', note how the '1' is more gpu intensive - ever so slightly lol, the first run got to 42% usage the second 47%
So yeah i'm gonna start using '1' and see how it feels.



--
MAX PRE-RENDERED FRAMES BENCHMARKS
http://forums.laptopvideo2go.com/top...es-benchmarks/

I tested Arkham gameplay, '1' is so much less input laggier!!!!!

wo Hoo!!!!!!!!!!!


Grapnel Boosting around Harley Quinn's Revenge for a short spell, gpu boost was enabled most of the time (1189MHz), max core usage 95% --using the '1'.

[rewt]

If you set the application to 0 in the ini, it could make sense that 1 gives better GPU utilization and framerate than app controlled (provided that the driver overrides it, which I have not tested myself). My earlier graphs demonstrated a similar concept. But what do we know, this thread only deserved a 1-star rating.

Here's a great explanation detailing the game's "OneFrameThreadLag" setting and how it works.

Originally Posted by [TW]redeye

The game runs essentially on 2 main threads - a game thread and a rendering thread. The game thread calculates all gameplay aspects such as shooting, hit registration, animation, IK, etc. The rendering thread calculates shadows, updates particle systems (such as smoke), and sends all the draw calls to the GPU for rendering.

Although for most parts the rendering thread can run on its own, it is not entirely independent of the game thread. The game thread "tells" the render thread where your camera is so that the rendering thread can draw the environment from your current location. Another example would be when you shoot, the game thread evaluates your mouse click, computes the ballistics, and if it hits a wall, it "tells" the render thread the location where it hit so that the render thread can draw a bullet impact decal at that location.

Because of this, the game thread needs to "talk" with the render thread. However, it cannot do so anytime it wants (effective threading simply doesn't work that way). So, it syncs from time to time, but otherwise goes about its own business. This sync time is usually at the end of a frame.

Now, let's assume that your game thread is running faster than your render thread. The game thread computes the Nth frame, sync happens, and then your render thread renders your Nth frame. While the Nth frame is being rendered, the game thread can compute your (N+1)th frame in parallel. By the time the (N+1)th frame is finished by the game thread, the Nth thread MAY or MAY NOT be finished by the rendering thread. This is where "One Frame Thread Lag" comes in. If OFTL is off, the game thread will STALL at this point, waiting for the render thread, resulting in a performance drop. But, if you play with OFTL turned on, it will allow the game thread to queue up the (N+1)th frame and start working on the (N+2)th frame immediately, and the render thread can pick up and render the (N+1)th frame once it has finished rendering the Nth frame. This gives you MORE PARALLELISM, and hence better performance. Keep in mind that this will only happen for one frame - your render thread will NOT keep falling behind more and more as your game progresses.

[With OFTL off, parallelism] is negligible to the point that you are 'essentially' running single threaded.

Ok, for the sake of argument let's assume that your game thread consistently takes 5ms to run and the render thread takes 10ms to run.

If you run with OFTL off, once the render thread has finished rendering the frame (10ms), it has to wait an additional 5ms for the game thread to finish computing the next frame before it can do any work. Since the render thread is not allowed to lag behind (also read as since the game thread is not allowed to work ahead) there is no queued frame. Hence, the effective time to render a frame from the render thread's perspective becomes 15ms.

On the other hand, if you have OFTL enabled, by the time the render thread has finished rendering one frame, it will already have a queued up frame to work on immediately. So the effective render time is now 10ms as opposed to 15ms.

Of course, if the render thread is more than 2 times slower than the game thread, then it will not always have a queued up frame, and as a result OFTL will yield diminishing returns.

The game thread is not dependent on the render thread, and hence can start computing the next frame before the render thread has finished. But the render thread is dependent on the game thread, and cannot begin a frame before the game thread has finished.

Also, I was being very simplistic in my 5ms, 10ms example. I hope you get the idea. You'll just have to put 2 and 2 together. Unfortunately, this is about as much detail I can go into in the forums.

[tweakpower]

Originally Posted by rewt

If you set the application to 0 in the ini, it could make sense that 1 gives better GPU utilization and framerate than app controlled (provided that the driver overrides it, which I have not tested myself). My earlier graphs demonstrated a similar concept. But what do we know, this thread only deserved a 1-star rating.

Here's a great explanation detailing the game's "OneFrameThreadLag" setting and how it works.

If you set 0 pre-rendered frames instead of 3, it will not make any sense to have FPS gain, at least from great explanation you quoted above, i see exact same thing. While it is great explanation how some games engines work, i don't quite understand the connection here, and all i can pull out from that explanation, is that 3 frames ahead = more lag, 0 = less lag, and that's basically we all agree on.

[SLI-756]

Originally Posted by rewt

[...]

Here's a great explanation detailing the game's "OneFrameThreadLag" setting and how it works.

Thanks rewt, had a quick scan of this in work and i'll now give this the attention it deserves, Arkham is one of my FAV games so thanks very much for posting this.
Peace.

Edit : i just tested game many many times alternating between the Arkham One Frame Thread Lag setting, i'm gonna revert it back to the default setting now (enabled), before when i was using app controlled pre-render it felt very laggy so i disabled the OFTL and it was better, but now i'm using pre-render '1' and with the OFTL enabled it feels more responsive, is more gpu demanding (just how we like it ) and it gives better FPS.
So yeah, shame i've been telling everyone on the web to disable this setting for the last 6 months when i should have been mentioning the nvidia pre-render setting.
Not to worry there are some other nice arkham tweaks we got out there, like the DOF & Bloom disable. : )

[kilyan]

range of setting is 0-8...i always set it to 8, i don't have any imput lags and games feel smoother when u have low fps.
tht's why i can play gw2 with 10 fps with no problem,when there are crowded events

[marcosamerio]

Originally Posted by kilyan

range of setting is 0-8...i always set it to 8, i don't have any imput lags and games feel smoother when u have low fps.
tht's why i can play gw2 with 10 fps with no problem,when there are crowded events

Hi kilyan, i dont thing u dont have no input lag, maybe for u is no noticeable

But at this value that u use in my opinion on test i do in my machine in games

like TF2, BFBC2, PD, KF the input lag get worse and worse when i was

trying higher values, this is why im stick all the way for "0" for mftra.

Bye

[SLI-756]

Flying round Arkham City taking out snipers(1080 v synced @60fps), pre-render @ '1', detail extreme, physx high, DOF & Bloom disabled.
In the benchmark i now average around 56 FPS.
Yip Yip YipEE!11!!
lulz.

[SLI-756]

I've had to set max payne3 to the '2' preset, the pre-render '1' was too choppy, i believe i may have to do the same for sleeping dogs too so long as it doesn't make the combat too laggy, however i'll keep Arkham at the '1'.
I imagine FPS games will greately benefit from the '1' preset too(for aiming & greater crosshair control) so long as gameplay isn't too much degraded.

I gave sleeping dogs a go @ '2' : it made no difference, still occasional choppyness and increased input lag so i'll be glad to have it back at '1'.
shame about the DOF can't be disabled in the game.

[rewt]

Originally Posted by tweakpower

i don't quite understand the connection here

"OneFrameThreadLag" and pre-render limit both serve the same purpose; enhancing parallelism/efficiency and preventing stalls.

Originally Posted by tweakpower

is that 3 frames ahead = more lag, 0 = less lag, and that's basically we all agree on.

Yes, we here agree on it, but apparently Nvidia doesn't.

Originally Posted by marcosamerio

Hi kilyan, i dont thing u dont have no input lag, maybe for u is no noticeable

A CPU-bound system may be unlikely to pre-render 8 frames ahead, even if that is the setting chosen in the driver. Key word maximum pre-rendered frames

Originally Posted by SLI-756

Thanks rewt

I'm glad it helped. Thanks for posting your results!

[connta]

btw, have we come to the final conclusion on triple buffering with vsync?

namely when using vsync which does introduce some input lag, no doubt, will triple buffering help reduce that input lag, increase it or is it irrelevant to the input lag? also what happens when we introduce distinction between developer implemented triple buffering and forced triple buffering with D3DOverrider, is there any from the point of input lag?

i must say i have never found a clear answer to these questions

also how does setting max pre rendered frames to less than 3 correspond with triple buffering and vsync? does enabling triple buffering and vsync makes max pre rendered frames a moot setting?

[SLI-756]

I always have triple buffering disabled (and i'll disable it in-game if option is present), i've always used v sync (now using adaptive), and with the '1' max pre-render setting i feel i've found the correct settings for my taste.
In the end that's what it comes down to, you just gotta test the settings by toggling them on and off and see which is more comfortable.
I've never liked the idea of triple buffering anyways, and yes i know exactly what it does, it worked best around 10 years ago.

[rewt]

Vsync can cause games to become artificially GPU bound, which means the CPU renders further ahead and increases input lag. In my experience more input lag is caused by pre-rendering than vsync or triple buffering.

[SLI-756]

Originally Posted by rewt

Vsync can cause games to become artificially GPU bound, which means the CPU renders further ahead and increases input lag. In my experience more input lag is caused by pre-rendering than vsync or triple buffering.

Hi, rewt, is the max pre-rendered frames setting in the ncp relating to the CPU or the GPU?
Just to confirm, thanks.

[rewt]

Max pre-rendered frames relates to CPU and double/triple buffering relates to GPU.

[SLI-756]

Originally Posted by rewt

Max pre-rendered frames relates to CPU and double/triple buffering relates to GPU.

Many thanks, much appreciated, dude.
That exlains the Arkham City cpu thrashing i seen before.

[rewt]

Sure thing bud

Originally Posted by connta

btw, have we come to the final conclusion on triple buffering with vsync?

namely when using vsync which does introduce some input lag, no doubt, will triple buffering help reduce that input lag, increase it or is it irrelevant to the input lag?

Triple buffering is not useful at FPS higher than refresh rate, nor without vsync, but at FPS lower than refresh rate it can cut milliseconds between frames in half.

Originally Posted by connta

also what happens when we introduce distinction between developer implemented triple buffering and forced triple buffering with D3DOverrider, is there any from the point of input lag?

i must say i have never found a clear answer to these questions

D3DOverrider, like its predecessor DXTweaker, injects code into application which modifies the back buffer count during swap chain creation. In games that already natively support that method of triple buffering (e.g. BackBufferCount = 2) then D3DOverrider will just behave passive anyway, and there will be no difference.

Originally Posted by connta

also how does setting max pre rendered frames to less than 3 correspond with triple buffering and vsync? does enabling triple buffering and vsync makes max pre rendered frames a moot setting?

In Direct3D pre-rendering can have some effect on buffering. For example I've seen where a pre-render limit of zero makes so-called "triple buffered" games perform as if they were only double buffered. It's usually detected as a huge FPS loss whenever vsync is enabled and FPS falls below refresh rate.

[kn00tcn]

Originally Posted by rewt

Vsync can cause games to become artificially GPU bound, which means the CPU renders further ahead and increases input lag. In my experience more input lag is caused by pre-rendering than vsync or triple buffering.

& in my tests, manually capping to 60 or 59 reduces the input lag

some engines do this already, others dont & have extreme lag, so... another variable in the quest to get rid of tearing & stay playable

[rewt]

Originally Posted by kn00tcn

& in my tests, manually capping to 60 or 59 reduces the input lag

Yes, I mentioned limiting/capping FPS helps.

Originally Posted by rewt

A workaround which helps with a majority of game engines is to limit FPS such that the GPU is not overloaded. That typically prevents the CPU/driver from queuing up too many commands before the GPU is ready for them.

[kn00tcn]

i mean, i'm confirming

[rewt]

If @60Hz vsync'd you cap to 60/59FPS then there may still be 2 or 3 pre-rendered frames.

With a pre-render limit of 3 (which is typical), capping 2 or 3 frames below refresh rate is known to minimize input lag with vsync (and it's why for example tools like Nvidia Inspector already includes settings for it).