Hey gang,After reading somewhat about it on these forums, I recently added the following to my fsx.cfg file:[bUFFERPOOLS]PoolSize=0I have to say, this has given me a very nice performance boost. I am running an EVGA GTX 460 SSC video card, with 1gb of ram. I have flown about 5 flights now since adding this tweak, flights ranging anywhere from 45 minutes to just over 2 hours. I logged my video ram usage on one of the longer flights, and the max ram it used was app 770 mb, this was during a heavy weather flight - with REX2.So anyway, so far at least, I have been very pleased with this tweak. I have noticed also mentioned, some that also run something like a reject threshold along with this command - just curious, what is the reasoning behind doing so, and is that something I should consider? Or maybe not, since I am not running into any strange issues running it like I am?Thanks for any feedback, just trying to wrap my arms around what the reject threshold does...

UsePools=0 and RejectThreshold=xxxx do not go together. The UsePools=0 will cancel it out.UsePools=0 tells FSX to bypass the command buffer and send all render commands to the GPU to be drawn. RejectThreshold=xxxx allows you to set a size limit on the data buffered. Any data larger than the size of the RT bypasses the buffer (same effect as UP=0). Any data smaller is pooled as normal. It's kind of a medium between using no buffer (UP=0) and using a bufferpool, for those who get instability with UP=0.

Yep, I have used it for a couple of months along with Highmemfix=1, and I won't leave home without it. A few artifacts every now and then and a little cloud flashing, but NOT using it is unbearable.Bob

UsePools=0 and RejectThreshold=xxxx do not go together. The UsePools=0 will cancel it out.UsePools=0 tells FSX to bypass the command buffer and send all render commands to the GPU to be drawn. RejectThreshold=xxxx allows you to set a size limit on the data buffered. Any data larger than the size of the RT bypasses the buffer (same effect as UP=0). Any data smaller is pooled as normal. It's kind of a medium between using no buffer (UP=0) and using a bufferpool, for those who get instability with UP=0.

You da Man, Tom! Thank you for your reply to Don. This one comes up once a week!

You da Man, Tom! Thank you for your reply to Don. This one comes up once a week!

:( No problem!I actually find this sort of stuff quite interesting as i'm studying Computer Science with Games Technology at Uni, and a large part of this terms module is studying how different game engines work!

Wow, thanks for the quick replies and the great info Tom!I certainly understand now much better. I shall stick with UP=0 then.Bob - I too use the Himemfix=1, and would not go without it...Thanks again guys,

If I use UsePools=1 and ReJectThreshold=xxx, are they working together or is that a conflict?

If I use UsePools=1 and ReJectThreshold=xxx, are they working together or is that a conflict?

They will work together, but the UsePools=1 is not really needed - it doesn't change anything from the default behaviour when using a RT. What you can do is also set a PoolSize manually in addition to setting a RT. You'll have to experiment to find out what size works best for you though.

Edited February 19, 201214 yr by Tom Wright

Sorry folks - I'm confused ! I thought I'd gotten my mind round this BP=0 stuff, but you just threw me.The OP said he was using Poolsize=0, not UsePools=0. I understand Tom's reply relating to UsePools=0, but I <<thought>> PoolSize=0 was quite different ?

Sorry folks - I'm confused ! I thought I'd gotten my mind round this BP=0 stuff, but you just threw me.The OP said he was using Poolsize=0, not UsePools=0. I understand Tom's reply relating to UsePools=0, but I <<thought>> PoolSize=0 was quite different ?

They're essentially the same. By putting UsePools=0, you're saying "don't use a pool". By putting PoolSize=0, you're simply setting the size of the pool to 0 bytes. This is effectively the same as not using a pool.

Ah - I must have misread something somewheres. Wouldn't be the first time.

Thanks for the clarification, Tom.

Hi,I had tried to use this entyr with my older video card -gtx285, and it was not effective. When I got my gtx270, it worked great. Aside from speed and effeciency, the 270 had about 250 meg more in memory, so I guess that is what made the difference, as the drivers were the same for both.Bob

I think it boils down to the clock speeds of the card. It can work wonders on the right hardware and with realistic rendering settings, but if the card is too slow or you're asking too much from the sim it can be disastrous. Pooling the commands creates a safety net to catch the commands and hold them until the pool, or buffer, is full before sending them to the GPU. This can slow the sim down because the sim ultimately has to wait until the buffer is full before drawing the scene, but it means that corruption caused by high GPU load is quite unlikely. UsePools=0 can really speed things up because there's no more waiting, but it's only effective IF the card is fast enough to handle the influx of commands sent to it from the CPU without buffering them. If it isn't you will see corruption in the form of spikes and artefacts.

Hi,I had tried to use this entyr with my older video card -gtx285, and it was not effective. When I got my gtx270, it worked great. Aside from speed and effeciency, the 270 had about 250 meg more in memory, so I guess that is what made the difference, as the drivers were the same for both.Bob

You meant GTX570, yes?I just started experimenting with this setting again myself. I set a fairly low frame rate lock (22 fps) in nvidiainspector, and pushed my GTX580 all the way up to 1000 MHz core clock, and it really smoothed things out, especially with high levels of UT2 traffic. 22 fps with very little variance is really quite smooth...better I think than 30 fps with drops to the low 20s under load. I had tried using BP=0 some time back, but with less than spiffy results...I suspect that being able to throttle the frame rate right in the driver really helps to avoid overrunning the card.