Skip to content
View in the app

A better way to browse. Learn more.

The AVSIM Community

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

[BufferPools] PoolSize=0 the holy grail of FSX performance...

Featured Replies

From Aces Team member Rafael Cintron:"In RTM, the default setting was 1MB (1000000). The lower this number, the more pools the allocator will have to rummage through to find space for buffers and the more stutters you may have. In Sp1, we raised the default to 4MB (4000000) and optimized the underlying algorithm for finding free buffers"Aces PT: "So be careful here, making this smaller can hurt you, since searching for space takes time and can cause stutters, and making the number too large can waste space. 4-10m is probably the range to be thinking about using unless you have a very high memory graphics card ( >512 )"-------End of Quote ---------
Let's not forget that in those days there weren't 1Gb GPU's (afaik). That changes the whole story because the 1 Gb GPU's have enough memory to do things on its own, for some at least :( .Anyway, no matter what Aces or anyone said: at this moment with an addon like Darrington I get superior performance with BP at zero. Just now I had that weird thing happening again: after testing various settings for an hour or so, and getting artifacts all the time, I suddenly was able to fly without any artifacts and autogen at Extremely dense... It now seems as if the GPU has to be running for some time before it can handle my settings. (I don't know if that makes sense but that's how it seems.) As I said, it all seems so utterly random...! And the weird thing is this happened with different settings than when it happened yesterday.Right now on my computer it is too random to figure out what works and what doesn't...
  • Replies 1.1k
  • Views 261.9k
  • Created
  • Last Reply

Top Posters In This Topic

Let's not forget that in those days there weren't 1Gb GPU's (afaik). That changes the whole story because the 1 Gb GPU's have enough memory to do things on its own, for some at least :( .Anyway, no matter what Aces or anyone said: at this moment with an addon like Darrington I get superior performance with BP at zero. Just now I had that weird thing happening again: after testing various settings for an hour or so, and getting artifacts all the time, I suddenly was able to fly without any artifacts and autogen at Extremely dense... It now seems as if the GPU has to be running for some time before it can handle my settings. (I don't know if that makes sense but that's how it seems.) As I said, it all seems so utterly random...! And the weird thing is this happened with different settings than when it happened yesterday.Right now on my computer it is too random to figure out what works and what doesn't...
Hi Jeroen,Did you read the whole post?I think it is a bit sidetracking to my post above to suggest I was posting the relavance of BP=0 to YOUR system not that you meant to. I wasn't.The quotes from Aces are there as a reference to what I had just posted was all.This isnt about BP=0, This is about the reoprts on DIFFERENT settings and how it IS or IS NOT relating. > Testing < Properly or Improperly as I stated way at the beginning of this thread to the OP. Just look at the results being reported and at what settings and coming to or going from BP=0 and do the Math, some things are not adding up <Which is the point I expressed above.What is your method of testing?Paul
I think it is a bit sidetracking to my post above to suggest I was posting the relavance of BP=0 to YOUR system not that you meant to. I wasn't.Just look at the results being reported and at what settings and coming to or going from BP=0 and do the Math, some things are not adding up <Which is the point I expressed above.What is your method of testing?
I know, it was just a sidenote and then I went on with my personal experiences (not related to anything you said).I do agree however that things are not adding up, which is exactly what I mean when I say things seem to happen (work) at random.I usually test various settings and when I think I am on to something I reboot and give it another go to see if I am really on to something or not. Up to now I can't say I am up to something... I just can't make sense of it all. I only know BP=0 gives the best performance but 95% of the time comes with artifacts.I am not posting as an expert on these things (I know nothing about it at all): I just say what I see happening on my computer, hoping the experts can make some sense of it. :(
Mitch,I have a 2 Gb card and unfortunately get the same artefacts.It's not yet the holy grail but it's positively a good tweak and I hope we'll find "the" way to get rid of the bogie's :--)
----------------------------------------------Oh really? OK....hmmm. Well, as I stated David, the BP=500000 is working on my system. How frustrating it was to almost be near your destination...and then the bogies put an end to it. Not any more. I did go back to BP=0 for one ten minute flight...and it truly does give the best flight experience to date. Too bad, it produces 'system anxiety' for me, lol.Mitch
Yes, I'm familiar with its purpose. I just notice people with the highest end systems don't seem to have issues with latency. Are you saying DPCalls relating wireless networking in FSX are impacting FSX performance? Would that be in picking up weather updates? Otherwise, I'm not sure how that would come into play for FSX.
Depending on the hardware and driver.....yes...the result is noticeable stutters (coincide with the latecny spikes)

Here are couple of more tests and observations, maybe we can make something out of it:I noticed that depending if you fly over heavy scenery (for example city) or nature, it depends how FSX reacts and also yields different performance.EDIT: I posted some comparisons, but since not consistent, deleted. Only thing I can say one weird thing: if 0, then FPS don't tend to change if flying or paused, if higher BP, they tend to drop low when flying and climb up to 3x more if paused.To me this is really unexplainable, and FSX stutters a lot out of the box. I still didn't find a solution to calm it, except BP=0!It's not something I can pinpoint, same as everyone else.EDIT: Please someone try BP=10 or even BP=1 - I know it doesn't really make sense, but I'm currently testing 1, and I can't get it to "snow". Performance is very similar to 0, MUCH better than any other "suggested" setting above 500000 (which sux here).

  • Author
From Aces Team member Rafael Cintron:"In RTM, the default setting was 1MB (1000000). The lower this number, the more pools the allocator will have to rummage through to find space for buffers and the more stutters you may have. In Sp1, we raised the default to 4MB (4000000) and optimized the underlying algorithm for finding free buffers"Aces PT: "So be careful here, making this smaller can hurt you, since searching for space takes time and can cause stutters, and making the number too large can waste space. 4-10m is probably the range to be thinking about using unless you have a very high memory graphics card ( >512 )"
I tried contacting Rafael a while ago, evidently, never got an answer. (I used his personal email, which anyone can find with a little effort)One of the reasons I was interested in clarifying the issue with him:1) Why, if BP is supposed to 'allocate' a geometry buffer to store indexes I never saw a video usage memory increase? even MORE weird, was the fact that the fsx.exe process INCREASED its memory usage, proportionally to the number of bytes set in PoolSize... so, this so called 'pool' seemed to be created using SYSTEM memory and NOT video memory.2) Why, when using HIGH PoolSize values, GPU utilization sky rockets and VIDEO memory utilization is decreased slightly?3) Why, *SOME* found BP=0 to be an excelent 'tweak' for them, while others found no benefit at all?Points #1 and #2 didn't make any sense to me, so I assumed the new driver architecture WDDM 1.0 to WDDM 1.1 was responsible, yet, I did experience great performance using BP=0 also in XP (32 Bit) using a 512GB ATI card! conclusion?? well.. NONE, thats the problem with BP=0Also, take a look at the g2d.DLL and g3D.dll files in the FSX folder, open those with a HEX editor, there are tons of usable 'variables' there, one I found: UsePools (which also goes under [bufferPools] seems to 'toggle' pool usage on and off.as for 'my' theory, I think it is ALL wrong, it fails to 'prove' anything.. however, BP=0 is no placebo at all... if anything, its just a big mistery.
I tried contacting Rafael a while ago, evidently, never got an answer. (I used his personal email, which anyone can find with a little effort)One of the reasons I was interested in clarifying the issue with him:1) Why, if BP is supposed to 'allocate' a geometry buffer to store indexes I never saw a video usage memory increase? even MORE weird, was the fact that the fsx.exe process INCREASED its memory usage, proportionally to the number of bytes set in PoolSize... so, this so called 'pool' seemed to be created using SYSTEM memory and NOT video memory.2) Why, when using HIGH PoolSize values, GPU utilization sky rockets and VIDEO memory utilization is decreased slightly?3) Why, *SOME* found BP=0 to be an excelent 'tweak' for them, while others found no benefit at all?Points #1 and #2 didn't make any sense to me, so I assumed the new driver architecture WDDM 1.0 to WDDM 1.1 was responsible, yet, I did experience great performance using BP=0 also in XP (32 Bit) using a 512GB ATI card! conclusion?? well.. NONE, thats the problem with BP=0Also, take a look at the g2d.DLL and g3D.dll files in the FSX folder, open those with a HEX editor, there are tons of usable 'variables' there, one I found: UsePools (which also goes under [bufferPools] seems to 'toggle' pool usage on and off.as for 'my' theory, I think it is ALL wrong, it fails to 'prove' anything.. however, BP=0 is no placebo at all... if anything, its just a big mistery.
Hey *******,Your going to put me in a time warp!Not sure If I can handle it either, and its late...but I'm Med free today! So...I hope this can help answer some of the questions you pose and maybe will help to get to the bottom of it.First I ws surprised you bring this up now after all the posting, however I looked thru this thread and thought I had addressed those questions to you already, but it was on three other post back in January.1.Perfect question Because FSX is rendered in software, that is - the Geometry and calculation is done on the CPU with exception of a few things like the use of Shader for water -FX, light bloom etc. Now Rafael makes the statement "amount of bytes we will allocate for one pool of vertex and index buffers to store geometry." - Most of this would be CPU But then PT asserts the thought behind different sized Frame Buffers which is >GPUClue#2:FSX SP2 included more efficient batch proccessing of AG, and I beleive BP was directlty related to AG, but still the question is that CPU or some of the new SP2 GPU threads, thats the question that still remains. I know I have some material on that, just have to finid it. However eiiether way in the end I think it would have some sort of impact on the GPU lanes.2.Because the FSX engine does not perform or render in a linear state, it is compounded by our settings. Capped FPS or not, the Hardware's ability or lack there of and the scenery/aircraft/AI/Weather scenario we are trying to run at that moment.(which is why testing needs to be done in a certain state that takes out the variables of moving changing weather/traffic loading at am airport, time of day etc to get an accurate result through the whole flight regime, or just one depending on the goal, as they all are different, I.e., Flat terrain, clear sky with lots of water mixed in with lots of AG trees vs hills and various landclass and a city with traffic and and airport but no water etc- these are two totaly different scenarios, and there are many..I know I'm just repeating myself) The Time Warp:Years ago I felt really frustrated at the lack of proper testing of hardware when it came to FS, as you may know FS was THE benchmark to run if you really wanted to see how well a system ran, ZifDavis and others used FS on a regualr basis.However, test were all over the place and very innacurate because variables were not taken into account, as well as how NV vs ATI used different filtering especially Anisotropic, IQ was not on par sometimes etc. It was suggested by a freind that I set it up...I got myself in a bit deep and in the end did a few reviews for a German site, NVnews and a local concern, nothing much but I got decent press and some free hardware to boot! :) Just have a look at some of the testing methods we had yo use to make the test fair, maybe it will help you set up something of your own, or not... I use something quite different now myself.Best version I could find of part of the review it is not the final published version and it is missing many images and is slow to load (from the "way back machine"): GForce3 vs GForce4 for FS2k2 Ha Also found this creeky old thread into what the meaning of FS secrets from back in the day here at Avsim (Good old days) hereOk, Back to the future....3.OK, well this is the thing of it all I think, Some results we can count on and some we cant, but we dont know which ones. Why? Because hardly anyone mentioned important things like what state was before and what kind of flying scenrario was being flown and then for how long. And then there is the whole difference of perception, that why laboratories use calibration equipment, not that we need that but,... Some dont mind low resolutions than others etc, Some are not used to real testing and expect things that arent even there, like "Hey I swaped my driver and now the colors and FPS are so much better", when in reality nothing changed at ALL. One thing is for sure, BP=0 changes things, but so does just leaving it at default if it ws set up at some strange high number that was creating an imbalance, or visa versa or what are AG sliders at etc etc, so you need to come up with a way to nail it down.Hey, sorry this post is a mess, I'm tired and just going to post a link of FS info and call it a night!http://msdn.microsoft.com/en-us/esp/cc789357.aspxPaul

I just posted my findings on tweaking a few things and then running a recorded flight over Seattle to measure FPS. I did test BufferPools. I found the following:1. Set to 1000000 = 17.40 FPS2. Set to 4000000 = 17.59 FPS3. Set to 6000000 = 18.76 FPS4. Set to 10000000 = 18.38 FPSSo there appears to be a spot where you get best performace and is probably different for each user. For me I am sticking with 6M.Scott

I just posted my findings on tweaking a few things and then running a recorded flight over Seattle to measure FPS. I did test BufferPools. I found the following:1. Set to 1000000 = 17.40 FPS2. Set to 4000000 = 17.59 FPS3. Set to 6000000 = 18.76 FPS4. Set to 10000000 = 18.38 FPSSo there appears to be a spot where you get best performace and is probably different for each user. For me I am sticking with 6M.Scott
Hi Scott,Interesting findings, however this is a tweak for stutters, mainly but not limited to higher image IQ and scenery density AG and scenery settings and encompasses being able to use spot view and others that show up the stuttering.Paul
  • Author
First I ws surprised you bring this up now after all the posting, however I looked thru this thread and thought I had addressed those questions to you already, but it was on three other post back in January.
The post went crazy, it got out of control for a while :) holy hand granades etc. it got back to normal :)
Some results we can count on and some we cant
Thats why I rather call them 'observations', they are subjective, inconclusive and lack evidence... :) same can be said for 'my' tests, they are specific to my setup, yet, I jumped in with conclusions 'assuming' it would apply to 'ALL' well.. lesson learned, it is UP TO US, to test and determine what works and what doesn't.Last week, for example, I think I discovered a PERMANENT solution for black screens/corrupted textures in FSX, I've been testing it.. daily. when I can confirm (and UNDERSTAND) why it solved everthing, I'll share. (it requires a change in the Shaders folder for texture compression) its not a compatibility mode change or fsx.cfg change.. but yes, I perfectly understand your point, and its difficult to test things when we all have our own methods..ok, on to bed.. tired here
Last week, for example, I think I discovered a PERMANENT solution for black screens/corrupted textures in FSX, I've been testing it.. daily. when I can confirm (and UNDERSTAND) why it solved everthing, I'll share. (it requires a change in the Shaders folder for texture compression) its not a compatibility mode change or fsx.cfg change.. but yes, I perfectly understand your point, and its difficult to test things when we all have our own methods..
Feel free to PM me how it works and I will happilty test along. :(
Last week, for example, I think I discovered a PERMANENT solution for black screens/corrupted textures in FSX, I've been testing it.. daily.
If you are looking for another tester, with different equipment than you have, I volunteer.
  • Author
If you are looking for another tester, with different equipment than you have, I volunteer.
Sure Stephen!, thanks for your offer.YOU NEED to read carefully and follow the steps EXACTLY, then report back your findings.1) Locate the ShadersHLSL inside your FSX folder.2) Now, locate and browse inside the 'Common' folder inside ShadersHLSL3) You'll see a file called: Common.fxh, make a backup of it, because you'll be editing it.Locate the following line in the Common.fxh file: dword State_TextureWrap : STATE_TEXTUREWRAP = D3DTADDRESS_WRAP;and change it to: dword State_TextureWrap : STATE_TEXTUREWRAP = 0;REMEMBER, after you make the above change, you'll need to delete the shaders cache (so it is rebuilt again using the new parameter) the shaders cache is located in C:\Users\USERNAME\AppData\Local\Microsoft\FSX\Shaders where USERNAME is your Win/Vista username. If you don't delete the shader cache, the above change is useless.Stephen, to properly test you need to have a situation where you can replicate, consistently, a black screen/corruption scenario. So, don't run Vista compatibility mode, that mode helps prevent the black textures.report back with your observations, in my particular case, texture 'corruption' and or black screens was an event I was able to 'replicate' consistently always at the same place/location.
The post went crazy, it got out of control for a while
So in this thread we are now on to disabling part of the FSX effects pool to solve your BlackScreen problems?You guys have fun with that.
Guest
This topic is now closed to further replies.

Account

Navigation

Search

Search

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.