NVIDIA 174.74 (beta) drivers new 3D setting

[Warmech]

Hey everyone, long time reader first time poster.

I just downloaded the new NVIDIA beta drivers 174.74 and under advanced settings > 3D settings I found a new option called "Maximum pre-rendered frames" which changes the number of frames the CPU can prepare before the frames are processed by the GPU (it ranges from 0-8). I figured I would see if it made any difference in performance so I decided to run the Crysis GPU benchmark tool a couple times, once at the default setting of 3, and then again at the max setting of 8.

My rig is:
CPU q6600 @ 3160 (395x8)
RAM 4-4-4-12 395MHz (1:1)
GPU 7900GS @570/765 (174.74 drivers, 'quality' setting /w gamma correction on)
MoBo MSI Neo2 FR

The first benchmark at the setting of '3' gave me an avg of 33fps
The second benchmark at the setting of '8' gave me an avg of 44fps

an 11fps (or 33%) increase in avg FPS... i know i only tested twice but it cant vary that much just between two benchmarks.

Has anyone else tested this setting and seeing similar results? My apologies for such little information but I was so shocked at the results I felt the need to post this asap and see if anyone else could verify or test on their own with different GPUs and CPUs. I will make another post hopefully soon after I change the detail settings and try a few more benchmarks.

 

[DerekWilson]

haven't tested it, but this kinda makes sense -- though i doubt you'd want to game like this...

what this setting does is tells the CPU to setup upto 8 frames at a time for the GPU. since all of these frames are setup as quickly as possible and they have to queue up to the GPU for rendering, it could significantly increase input lag (meaning you could move your mouse but the GPU would still be working on finishing the last 8 frames the CPU sent it).

I've been menaing to play with this setting, but I've had a lot of other things to get done.

 

[chizow]

Hmm interesting, I didn't see this option but I'll have to check it out. This is Vista only right? This would certainly explain the FPS caps in Crysis and give weight to the claims CPU performance is bottlenecking high-end GPU solutions. But like Derek said, the risk is excessive input lag.

 

[AuDioFreaK39]

This option has been implemented in all of the ForceWare 174.xx drivers actually. I'll give the feature a shot when I get my Q9550.

 

[AzN]

This did nothing for more dx9 benchmark but it did improve my dx10 benchmark by 2fps.

I ran it on high settings though. It might help more in lower settings.

 

[DerekWilson]

Originally posted by: Azn
This did nothing for more dx9 benchmark but it did improve my dx10 benchmark by 2fps.

I ran it on high settings though. It might help more in lower settings.

honestly the place it is likely to help most is quad sli ... depending on how the game handles sharing information between frames that were rendered ahead.

 

[BFG10K]

This is Vista only right?

No, this setting has been around for years, just not visible in nVidia's control panel.

I've extensively tested it and like Derek says it'll introduce input lag if you go too high. In fact the default of 3 is already too high so I set it to 2.

8 would cause horrific lag in gameplay, assuming it?s really is doing 8 (I've heard the driver clamps past 4 or 5).

 

[theprodigalrebel]

Is this the same thing as 'Flip Queue Size' in ATI Tray Tools?

 

[BFG10K]

Yep.

 

[tuteja1986]

lol would be funny if Nvidia released a drive on April 1st claiming it increased Crysis performance by 100%

 

[j0j081]

Originally posted by: BFG10K

This is Vista only right?

No, this setting has been around for years, just not visible in nVidia's control panel.

I've extensively tested it and like Derek says it'll introduce input lag if you go too high. In fact the default of 3 is already too high so I set it to 2.

8 would cause horrific lag in gameplay, assuming it?s really is doing 8 (I've heard the driver clamps past 4 or 5).

so does lowering it also lower your avg fps? Maybe 2 would be better for me as I play a lot of shooters.

 

[BFG10K]

so does lowering it also lower your avg fps?

Not that I saw. Anyway, even if it did the visible reduction of input lag is worth it.

Also it's already 2 in OpenGL so you don't have to worry there.

 

[lavaheadache]

this tweak has been all over the Crysis on line forum for the last couple days. I'm very sensitive to input lag and let me tell you there is none, atleast under crysis there isn't. Could be due to the fact that the FPS arent very high to begin with. My game experience was improved greatly by changing to 8 from the default 3. I could imagine it is around 33%

 

[chizow]

Originally posted by: BFG10K

This is Vista only right?

No, this setting has been around for years, just not visible in nVidia's control panel.

I've extensively tested it and like Derek says it'll introduce input lag if you go too high. In fact the default of 3 is already too high so I set it to 2.

8 would cause horrific lag in gameplay, assuming it?s really is doing 8 (I've heard the driver clamps past 4 or 5).

Hmmm, but isn't this the same as setting double/triple buffering with XP limited to 3 frame buffers? I know there was talk about pre-rendered frames beyond 3-4 with the latest Xfire and SLI configurations but I figured that was part of the reason more than 3 GPU resulted in very small returns due to drive clamps beyond 3 in XP and 4 in Vista. I'd be interested to see if this helps improve multi-GPU solutions for sure. Would be good news in the sense end-users would have more control over hardware performance, bad news in the sense its another check-box and potential oversight in driver profiles.

 

[lavaheadache]

Originally posted by: chizow



Hmmm, but isn't this the same as setting double/triple buffering with XP limited to 3 frame buffers? I know there was talk about pre-rendered frames beyond 3-4 with the latest Xfire and SLI configurations but I figured that was part of the reason more than 3 GPU resulted in very small returns due to drive clamps beyond 3 in XP and 4 in Vista. I'd be interested to see if this helps improve multi-GPU solutions for sure. Would be good news in the sense end-users would have more control over hardware performance, bad news in the sense its another check-box and potential oversight in driver profiles.

I know for sure it helped my sli rig in crysis

 

[manowar821]

Awesome. I will be testing this.

 

[BFG10K]

Hmmm, but isn't this the same as setting double/triple buffering with XP limited to 3 frame buffers?

No, this setting has nothing to do with the GPU or GPU buffers, it?s purely a CPU/driver function.

A GPU can only render one frame at a time and the rest of the time the driver reports it?s ?busy? to the game. With pre-rendering the driver pretends the GPU isn?t busy (even when it is) and allows the game to send frame data (e.g. vertices) as normal.

Of course the GPU isn?t available so the driver buffers the data externally somewhere, probably in the system RAM, queued up for when the GPU is really ready. Obviously the pre-render setting determines how many such frames are buffered up in such a fashion.

The advantage of this is when the GPU is really ready the frame data is immediately available so the framerate increases, especially in GPU limited situations.

The disadvantage of this is obviously input lag, since you?re rendering ahead and buffering up frames.

I know there was talk about pre-rendered frames beyond 3-4 with the latest Xfire and SLI configurations but I figured that was part of the reason more than 3 GPU resulted in very small returns due to drive clamps beyond 3 in XP and 4 in Vista.

It?s a bit different with SLI/Crossfire because at any given time you can have multiple GPUs available even when one or more is working on a frame (assuming AFR style rendering). This situation would never happen on a single GPU setup.

That and nVidia sets OpenGL to 2 by default but we know OpenGL games can scale to four GPUs, so clearly there?s some internal pre-rendering going on in the driver that?s separate to this setting. My guess is that nVidia has hard-coded their own figure into SLI profiles that use AFR.

 

[ViRGE]

Originally posted by: BFG10K

Hmmm, but isn't this the same as setting double/triple buffering with XP limited to 3 frame buffers?

No, this setting has nothing to do with the GPU or GPU buffers, it?s purely a CPU/driver function.

A GPU can only render one frame at a time and the rest of the time the driver reports it?s ?busy? to the game. With pre-rendering the driver pretends the GPU isn?t busy (even when it is) and allows the game to send frame data (e.g. vertices) as normal.

Of course the GPU isn?t available so the driver buffers the data externally somewhere, probably in the system RAM, queued up for when the GPU is really ready. Obviously the pre-render setting determines how many such frames are buffered up in such a fashion.

The advantage of this is when the GPU is really ready the frame data is immediately available so the framerate increases, especially in GPU limited situations.

The disadvantage of this is obviously input lag, since you?re rendering ahead and buffering up frames.

Didn't we have a long thread on the issue with Derek coming in and settling the issue stating that triple buffering leads to less input lag than double buffering?

 

[lopri]

I think triple buffering occurs in local memory (video RAM)?

 

[BFG10K]

Didn't we have a long thread on the issue with Derek coming in and settling the issue stating that triple buffering leads to less input lag than double buffering?

Pre-render has nothing to do with the GPU or triple buffering. Nothing. It's a CPU/driver function.

 

[chizow]

Ah that makes sense, I glossed over the pre in pre-render. Still, makes sense about some of the developments and news related to Crysis performance of late. It certainly helps substantiate some of the findings that Crysis is CPU limited, with these self-imposed driver caps. Also with Derek's findings in the Skulltrail review, where he found that number of cores did not matter, only speed of the cores. If running a single thread this makes sense as the next frame would not begin until the first finished. A faster core would obviously speed that process up.

But with this pre-rendered frames setting, especially with multi-GPU set-ups, it seems horribly inefficient to wait for the CPU to finish one frame before beginning the next when the driver/GPU will be ready 2x as fast or more. If input lag isn't too bad, this setting should probably be increased with each GPU added. Also may explain the much worst performance of Skulltrain vs. 780i with the FB-Dimms slowing down Skulltrail. Like lopri said, these pre-rendered frames are probably streaming from system RAM and CPU L2 and the increased latency would certainly impact performance there. Will have to check this out once I get access to my rig again, also would be nice to see some more multi-GPU results and comments about input lag. I'll also try and take note of how much more, if any system RAM is being used with each increase in pre-rendered frames.

 

[BFG10K]

But with this pre-rendered frames setting, especially with multi-GPU set-ups, it seems horribly inefficient to wait for the CPU to finish one frame before beginning the next when the driver/GPU will be ready 2x as fast or more.

It would only do that if pre-render is set to 0. Also in GPU limited situations the CPU is finishing its tasks faster than the GPU.

If input lag isn't too bad, this setting should probably be increased with each GPU added

Yep, this pretty much happens with AFR and why it leads to input lag. The more boards in the system the more lag since you have render ahead more to keep them busy.

 

[taltamir]

we have so many ifs, ands, onlys and what have you nots. Any chance of an in depth review and test of this function?

 

[BFG10K]

we have so many ifs, ands, onlys and what have you nots. Any chance of an in depth review and test of this function?

Like I said earlier, I've tested it on single card configurations and the general conclusion I came to is to leave OpenGL at 2 (default) and lower Direct3D from 3 (default) to 2.

Going lower than 2 can cause performance drops, stuttering/pausing/hitching, and even a BSOD on XP in certain situations.

Going higher than 2 can result in substantially increased mouse lag, especially if you use combined AA modes in old games (which I do quite a lot).

 

[chizow]

Yep, this pretty much happens with AFR and why it leads to input lag. The more boards in the system the more lag since you have render ahead more to keep them busy.

It shouldn't be any more than with fewer pre-rendered frames, as there's already a delay while the GPUs wait on the CPU for a new frame to render. Increasing pre-rendered frames shouldn't introduce more input lag if those pre-rendered frames aren't sitting in the queue as long and are being rendered by the extra GPUs.

Anyways, I didn't see any improvements messing with this setting with the rig in my sig. 31/32 FPS out to varying decimal points for about 8 different settings with DX10 and 32 and 64 bit @1900x1200, Texture and Object at High, most everything else Medium, 0AA/16AF and a few custom settings. I did notice DX9 performance finally increased beyond DX10 performance in Vista for me with 174.74 Beta drivers. In the past DX9 ran 3-5 FPS slower than DX10 with everything else the same, so I did see a rather massive difference (8-10FPS) improvement in DX9.