FSX:Tweak of the Week ( or 2 )


Originally posted on fsinsider.com


 


Now that I have  burst peoples bubble on PerfBuckets and Procspeed on my blog ( http://blogs.msdn.com/ptaylor ), let’s talk some real tweaks, TEXTURE_BANDWIDTH_MULT and BUFFERPOOLS.


 


These are tweaks in the fsx.cfg file.  If you don’t know what that is, you probably don’t want to be using these.


 


TEXTURE_BANDWITH_MULT (EDIT:this is in DISPLAY, not GRAPHICS)


 


The mysterious sounding TEXTURE_BANDWITH_MULT is our first target.  This is a setting in the [DISPLAY] section of the file, formatted like this:


[DISPLAY]


TEXTURE_BANDWIDTH_MULT=n


 


Where n can range from 10 to some reasonable value that is related to your frame rate limit.


 


From Rafael Cintron, part of the FS Graphics and Terrain team, comes this description:


 



The TEXTURE_BANDWIDTH_MULT option in the Graphics section is the target frame rate use for calculating texture bandwidth.  The higher you set this value the more textures we will allocate and copy per frame to the graphics card.  The lower you set this value, the less we will allocate and copy up to a minimum limit.  As an example, the default rate in the “high” perf bucket setting is 40.  The lowest perf bucket setting is 10. 


 


Higher settings on this flag can cause stutters on frames where the terrain system has finished compositing lots of textures.  Lower settings can reduce stutters on busy frames and spread out the load across multiple frames



 


So thinking this thru, if the value you set is 40, and your frame rate limit is 30, then we will send 40/30 or 4/3 as much textures per frame.


 


Moving this value to 400, like I have seen some users post in the forums, is probably *not* what you want to do since that increases the texture load on the graphics card by 10x, eg 400/40 = 10x. And after talking about this to Raf, setting it to 0 is ignored and can be validated by setting it to 10 which should give no different results.


 


BUFFERPOOLS


 


The pedestrian sounding BUFFERPOOLS is a section of its own in the fsx.cfg file. There is a setting in there called Poolsize, as in


[BUFFERPOOLS]


Poolsize=n


Where n is the amount of bytes we will allocate for one pool of vertex and index buffers to store geometry.


 


Again from Raf:



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



 


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 )


 


 


So there you go, some real tweaks to begin your weekend with!

Comments (25)

  1. MauiHawk says:

    Haha… that’s pretty funny… how long have the flight sim forums been bandying about TEXTURE_BANDWITH_MULT without knowing really knowing what it meant (though I guess the general idea was still understood).

    Although, I’m actually not sure I completely understand this explanation.  Getting back to your example of a setting of 40 and fps of 30… so you will be set up to send at most “40/30x” texture data to the card per frame…. what is x exactly?  But ignoring that for now, 40/30x*30 = 40x is the amount of texture data sent to the card per second.  But say you could actually only run at 20fps.  Guess what: 40/20x*20 = 40x texture data per second.  So actually, it seems that fps would play no role at all in how this setting affected overall texture data transfer rates.  Am I wrong?

    I guess the part of this setting I think would be important to understand is over the long term, on a typical system, how possible is it that the texture generation will outpace the rate at which it is sent to the card… a lower value will spread it out across more frames, but how at risk are we of spreading it out so far that some texture data never makes it to the card?

  2. Phil Taylor says:

    Maui:

    dont try to read more into it than is there.

    40/30 = 1.3x as much texture per frame. over our default.

    40/20 = 2x as much texture per frame. again over our default.

    so in those cases, we would allocate and upload using those multipliers. thats what the _MULT is, this is a multiplier factor.

    thats all there is to it. multiplying by seconds is something you made up and has nothing to do with the discussion.

  3. MauiHawk says:

    Thanks for your reply, but I still don’t see how the time period has nothing to do with it.  Time is a component of bandwidth.

    If you don’t want to talk about it in terms of seconds, think about it per frame.  With 40/30, the frame lasted 1.33 times as long as with 40/40.  So while you’d be pushing 1.33 times as much per frame, you’d also have 1.33 times as much time to do it in.  The ratio of time rendering the frame to time pushing the data would stay constant.

  4. Phil Taylor says:

    Maui:

    ah, I see the disconnect.

    this could as easily be called "TEXTURE_LOAD_MULT" dont get hung up on the word "bandwidth" in there.

    all this does is establish a ratio wrt fps that tells the app what additional texture load you the user will accept if you are overachieving your fps.

  5. jordanal says:

    BufferPools clarification Please:

    When you say the default is now 4MB, is this independant of detected hardware or perfbuckets?  I.e., all SP1 users have 4MB set when bufferpools is not declared in the FSX.cfg file?

    You also mention the 4 to 10MB range unless you have a GPU with more than 512MB RAM.  Since I have a newer 8800GTS card with 640MB RAM, which way does the tweak go?  Should I consider tweaking towards BufferPools=10M since I have a 640MB card?

    Thanks for the clarification.  Good blog info…

    Al

  6. Phil Taylor says:

    Jordanal:

    yes, the SP1 default is 4M, it was 1M in RTM.

    yes, if you have the vidmem to spare bumping it up is worth testing.

  7. SilentGenie says:

    Hi phil,

    This may sound daft but i have vista and cannot find the FSX.cfg file anywhere, i’ve tried various blogs stating where it should be but it’s not there. I’ve enabled Show hidden files in the control panel but it still doesnt show, I’ve also used the vista search option in the toolbar but it doesn’t find anything. Do you know where it should be ? before i installed SP1 i removed FSX Defragged then installed a clean copy of fsx then stuck SP1 on so its gotta be in there somewhere. Thank’s again

  8. Phil Taylor says:

    Silent:

    it should be in C:UsersUSERNAMEAppDataRoamingMicrosoftFSX

  9. SilentGenie says:

    Phil a while back when SP1 was cooking you mentioned that with the DX10 update users may get a little boost with performance, do you have any estimates as to what we may expect or is it too early, also what eye candy would come around with the dx10 update ?

    Thank’s for your time

  10. Tabs says:

    Phil,

    Thanks so much for these posts dispensing with the voodoo surrounding some of these alleged tweaks – I’ve long suspected many of the gains alleged from them were psychological.  Keep it up!

  11. Phil Taylor says:

    Silent:

    we are aiming for another performance bump as well as visual features.

  12. lukeharvest says:

    Correct me if I’m wrong here Phil…

    But generally the DX10 patch for FSX, if nothing performance wise was done to amend FSX directly, you will see an increase in performance as DirectX 10 is not just another version of DX. DX10 has been completely rebuilt to change how material management and load balancing (between the CPU and GPU) is utilised in Applications. DX10, unlike DX9, takes advantage of the CPU and GPU by managing the load share between the two. Basically within most games there will be less CPU intervention which is good because when you have a very heavily dependant CPU game like FSX the more we hand off to the GPU the better really.

    With DX10 you’ll get more pixels and more material like the scenery complexity will be able to be increased exponentially without any hit in the CPU.

    The DX10 patch is going to be extremely useful to MS as DX10 comes with something called volumetric effects which hopefully will revoluntionise FSX because things like clouds, water and the bloom effect will be massively enhanced.

    Also DX10 comes with an enhancement in motion blurring. Now this could be used in FSX for things like panning and maybe if your in the VC and around 70-90 degrees of either side of you could be blurred at high speeds. Of course this would have to be done real professionally as in the RW motion blurring is only noticeable if you focus on something other than what you want blurred. So if FSX were to do this it would be very subtle.

    As I said the bloom effect would be improved because of volumetric effects but also because there will be softer and sharper shadows varying in opacity so more realistic shadows will be avaliable as an option for MS.

    But because of the new structure within DX10 we should be an improvement in performance in FSX through both less CPU intervention but also because of the new graphics processing.

  13. Phil Taylor says:

    Luke:

    Agreed the API is designed to be more efficient. And the D3DX effects framework is supposed to be more efficient. Which should all help.

    But.

    There is still a need for application side work, though, to best use DX10.

    Better app state management depends on the app implementating state blocks and managing state correctly.

    More shader constants means many more skinning operations for animations ( that have high matrix parameter requirements ) could be batched up now, since the set of constants available is so high. Still even there, this still depends on setting up shader constant blocks by update frequency and then enforcing that as policy.

    TextureArrays and Instancing are a perfect chance to expand on the batching we did and further reduce Draw and SetTexture calls. But that too requires setup work as well as the in-render invocations.

    As far as effects; volumetric, motion blurring, or bloom – this all depends on feature implementation by the app.

    Soon, in a month or so, I will post about what our implementation plan is and what features are likely to actually ship. But it is still too early for details, all I can say is we do aim to hit the performance as well as the visual feature wickets. And some of the things I have mentioned here and elsewhere in my blog are part of the plan.

  14. NickN says:

    Hi Phil

    It would be an exceptional help if you can verify and explain the following:

    1.  In RTM it was posted in a developer’s blog the default values for:

    TERRAIN_MAX_AUTOGEN_TREES_PER_CELL=  is 4500

    TERRAIN_MAX_AUTOGEN_BUILDINGS_PER_CELL= is 3000

    …when the lines are -NOT- in the config file and the autogen slider is at 100% (Extremely Dense). Please confirm SP1 uses the same default values @ 100% slider.

    2. Please post the divider or ratio for each autogen slider as compared to the max value:

    Sparse

    Normal

    Dense

    Very Dense

    Extremely Dense= max value

    3. I know you stated ProcSpeed and PefBucket are only written values placed into the config file when it is first written and as you stated those values determine the base slider and settings when FSX if first run. I wish to confirm that ProcSpeed and PefBucket do not in any way change the default max autogen numbers for the autogen slider.

    Just some comments about blurries on dual core:

    My findings with respect to blurries remain the same for yet another system…

    a. Increasing the Texture_Bandwidth_Multiplier (usually to 60-80)

    b. Setting texture resolution to 7cm

    c. Adding in the FIBER_FRAME_TIME_FRACTION=0.34 (no lower or higher)

    d. Setting a reasonable frame lock (18-28 depending on the card and processor)

    e. Leave out the Affinity mask tweak

    And most important:

    f. All of the above in relation to the CORRECT autogen config line values and slider combination

    g. Set the view in the cockpit to 70% zoom and the exterior views to 80% zoom. That increases the illusion of how far sharp textures are being displayed and hides the fact that SP1 significantly reduced how far out the sim ‘precisely’ sharpens the textures around the aircraft.

    And traffic above 20GA – 30AL for anyone running below an 8800/Core2 is close to impossible and still have good scenery.

    Once all of the above is in order the blurries are gone and the sim produces a nearly razor sharp, photo-real flying environment under and around the aircraft a few miles. However, change the aircraft to something that stresses the system, or, change the location in example form Seattle where it was calibrated to LAX, and tweaking is again required.

    I am not into tweaking 10 config files just to accommodate the software. I should not have to.

    With SP1 the distance scenery ring sharpening appears to have been significantly reduced. In RTM I could easily sharpen well past a radius of 5 miles. With SP1 I am lucky to be able to sharpen razor clear past 3. In my opinion anything less than 10 is a waste and ruins the illusion.

    What I find ridiculous is what one must go through to get that all locked down. I really hope you guys listen to the community and get it fixed in DX10. The sim seriously lacks correct flight dynamics as are found in XPlane. Because most of better future add-ons will require SP1 I am stuck on SP1 and it’s frustrating. I find it quite annoying I can not revert to RTM, which looked better all the way around and allowed me to easily tweak without changing the ground sharpness because I changed airports or cities. What’s even worse is flying out of one airport perfect to discover the destination is a blurry or stuttering mess,..

    back to the tweaks and the never ending circle continues.

  15. Phil Taylor says:

    Nick:

    thats too much to respond to in a comment, that deserves a separate post. I will have to research, and this is behind the water topic that was asked for previously. Good ask, though, I will get to it.

  16. NickN says:

    Thanks for looking into the technical info. Knowing that information will help because autogen setting methods can be applied based on the hardware and the amount of information being processed.

    One item I left out of my list for blurries is to let the sim handle both Anisotropic Filtering -and- AA and set the adapters to “Application Preference”. That was true for the Nvidia adapters I have set up. ATi seems to prefer handling the AA on the card. With RTM it was best to let the card work that area but in SP1 that seems to have changed.

    Also, scenery radius set to LARGE with a Global Texture Resolution and Mesh Complexity @ 100% were required.

    As far as I can tell, the MipBias= tweak is only good for photo-scenery. When applying that tweak on the default scenery it does require the addition of SS or QxS which is a give and take area that I find pulls more from the card than its worth. Those running the faster video adapters can probably take the hit where those running 7900 and under will see other losses.

    Most people are not running Core2 and 8800. I understand the need to innovate and plan for the future, but when the majority of the market is not running such hardware I also think there should be room for today. A later patch could have easily provided the over the top information requests the next gen of hardware may take advantage of.

    With DX10 there is much room for additional. I sincerely hope that is not overstuffed in the name of innovation.

    Please do not take any of my comments as being negative or putting down the team. I know you guys work(ed) hard on the software and will continue to do so. I am sure the initial write was in need of serious changes that did not have the time or budget to be re-deveopled and you are doing the best you can with what you have to work wth.

    🙂

  17. NickN says:

    As a side note, and there is no need to publish this, I followed your suggestions in the AVSIM forum for setting up a clean RTM, getting it stable and sharp at 20FPS in Seattle (I did that with the 747 and the Baron with different weather to assure max loads were applied), Then install SP1 and repeat the setup. I followed your list very carefully. I was unable to get rid of blurs and stutters without making the tweaks I mentioned.

    It appears, at least with certain combinations of hardware, that the simulator likes to look away from the fiber frame unless it is set up in such a way it is forced to focus on the mesh and textures. I will say that ATi and Intel are much easier to get locked down than Nvidia.

    Also, I have never seen any OOM errors (out of memory) but I am also running Vista and XP x64. I may be mistaken but I have also never come across anyone posting problems running an ATi adapter with OOM issues, only Nvidia.

  18. NickN says:

    Another item that does not need to be published.. I am just trying to help Phil by providing a bit of insight and first hand testing knowledge:

    AVSIM, topic #402165

    The user Galant VR4 unistalled then cleaned up his system and tried FSX again. I know there can be many reasons for blurries, including a poorly set up rig for games,, but in his case, he also said:

    =======================

    “Last night I decided to up the scenery. I moved the autogen to max and the road traffic to max. My frames did drop to around 19 but the sim was smooth. I did notice at these settings that off in the far distance the terrain looked blurred. I dropped the road traffic down to 20% and my blurries cleared up again.”

    ===================

    My thought here follows the same pattern I have seen on at least 6 systems that have blur problems,,.. raising the load in autogen and scenery forces the sim to focus on the terrain.

    I think it is well worth a look into the priority of the core threads which devote time to the frame. I definitely found setting 7cm with the right autogen and scenery levels forced the sim to display the textures sharper. By using 7cm it appears the initial display is focused better than 1m in which minor sharpening is not noticed as much.

    It appeared to me the sim makes 3 sharpening passes. If the system is in balance and the sim is focused on the frame what you will get is a slightly blurred texture that “snaps” sharp (2 passes max) very quickly as the aircraft approaches an area. If this is done fast enough you cant really see it taking place. It is when the sim has to make 3 passes (blurred, focused, sharpened) that it is noticed.

    In the past we could use fiber frame time factor to trim that but with SP1 that setting with dual core is practically useless. Bumping it up to .34 actually causes micro-stutters but that is balanced out by lowering the config file AG numbers. When you hit the right combo, the sim is smooth and the scenery ring is sharp.

  19. SilentGenie says:

    Phil,

    I found the CFG file on Vista and have changed the TEXTURE_BANDWIDTH_MULT but i cant find the Bufferpools section in my CFG file. I have an 8800GTX which obviously houses alot of vid mem so would like to bump up from the 4mb SP1 gives us, do i have to add that line to my CFG as im a little confused, would i benefit from upping it a little. maybe someone in this blog could help

    Thank’s

  20. Phil Taylor says:

    Silent:

    LOL, the only person in this blog is me.

    any tweak entries that arent present need to be added.

  21. SilentGenie says:

    i know its you mate just thought some peeps who read this might be able to help, do i have to addd that line anywhere or does it have to be in a specific part of the cfg

  22. SilentGenie says:

    phil, is there a way to change the way the draw distance is defined ? i would like to have things sharper at a longer distance, my system is running perfect with everything maxed @ a constant 30fps which is what ive set, i have increased the bufferpools to =10000000 and havent noticed any drop or gain in performance, all i want now is to maximise the visuals, dont get me wrong its stunning now with sp1 but as you may be aware that if you look ahead a few miles things dont tend to be as sharp and i would like to increase the sharpness. hope you can help 🙂

  23. Phil Taylor says:

    Silent:

    as my post says

    [GRAPHICS]

    TEXTURE_BANDWIDTH_MULT=n

    so TEXTURE_BANDWIDTH_MULT has to go in the graphics section

  24. Phil Taylor says:

    Silent:

    changing the LOD radius slider is the only way to affect what is drawn in the distance.

  25. SilentGenie says:

    oh well im stumped then as my lod slider is set to maximum, maybe some addon scenery will change that ? thanks again