46 replies to this topic

[Cell]

I just thought I'd fire these over here from Phil's blog.

There is a tweak to control scheduling of threads on cores.



It is not recommended to change these settings unless you have a performance reduction and/or maxed out CPU loads in the PerfMonitor. The tweak is

Edit:Fixed a typo here
[JOBSCHEDULER]
AffinityMask=n
where
n      num of cores scheduled
1  = 1 core           0001
3  = 2 cores         0011
7  = 3 cores         0111
15= 4 cores         1111



----



There is additional code to reduce blurries. If you get random texture tiles that appear in a solid color this may help.



In some cases, the textures generated from this code can get throttled and will be timed out.  The time out config value is

[TERRAIN]

SWAP_WAIT_TIMEOUT=<number_of_frames>

The default is 30 frames.



--



There are new config items to control VSYNC for fullscreen and windowed separately



[DISPLAY]

ForceFullScreenVSync, default is TRUE

ForceVSync, default is FALSE



We have seen cases where when VSYNC is on in fullscreen causing major fluctuations in frame rate especially when setting the rate limiter above 45.  If you run into widely fluctuating FPS in fullscreen when aiming for above 45, try turning VSYNC off or reducing below 40.



--



For the dusk/dawn textures some people feel, subjectively, the result is too dark or too light. There are 2 items that allow the transition time to be changed:

[GRAPHICS]

DAY_THRESHOLD

NIGHT_THRESHOLD



acceptible values are 0 to 65535.

Defaults:

DAY: 32768

NIGHT: 4096



These represent the amount of 'ambient' light at the ends of the day/night blend threshold. Zero is perfect dark, 65535 is full day sun at noon in the summer.

--



There is a tweak that helps with panel updates, especially the glass panel. If you use the glass panel and notice very slow updates. There is a  2 part tweak:



[GRAPHICS]

DirtyRegionUpdateLimit=<integer>



By default this UINT32_MAX (i.e. four billion or so) so it has no effect.

Setting it to zero effectively forces full texture updates instead.



Setting it to smaller numbers (1-1000) might improve performance if the card is slow at full texture updates and does not have a high overhead for incremental updates.



[GRAPHICS]

MergeDirtyRegionUpdates=<0/1>



By default this is 0 (i.e. disabled) so it has no effect.

Setting it to 1 (enabled) causes us to merge all of the dirty rects into a single large dirty rect. This means that we will only do a single partial texture update.



This may work well if the card is slow at full texture updates and does have high overhead for incremental updates.



---



There is a scenery tweak to eliminate very small objects, which can reduce render time.



[SCENERY]

SmallPartRejectRadius=<pixels>



Basically this culls out small model parts (e.g. air conditioners on roofs of buildings, aircraft doors) if their radius would occupy less than the specified number of screen pixels.



The default is 1.0 (i.e. 1 pixel). 2, and 4 are the next 2 settings we advise. Can significantly improve performance but may cause “popping" of small objects

Acouple of other things to note, which hve been mentioned but worth bringing them together.

Texture_bandwidth= Setting a higher value pre SP1 did help with blurries, this can now have a detremental effect using SP1. Mango and I managed to get find a nice happy medium by setting the value to 40. This helps eliminating stutters.

FIBER_FRAME_TIME_FRACTION= This has a smaller effect on ground texture loading now as these processes have been moved onto the second core.
Again lifted from PT's blog.
So here is an idea. Occasionally I will publish information on various "tweaks" to the product and what they do. A "Tweak of the week" if you will.



So let's start with the mysterious sounding FIBER_FRAME_TIME_FRACTION.



There are page after page of google, I mean livesearch, hits on this term. Obviously people have been talking. That's probably due to the post Adam, our resident terrain guru, made here.



Now we hope people don't hurt themselves with settings that deeply affect the engine like this, because there is always the possibility of misuse. Usually that is outweighed by the value of being informed, and the great thing about the community is sometimes interesting questions do crop up out of people using these settings.



Christian Buchner, author of TileProxy, recommended that Win64 users of TileProxy set FIBER_FRAME_TIME_FRACTION to 2.0 when the base value is .33. A lot of speculation about what that would be doing cropped up.



Adam Szofran, our resident terrain guru, gave out the skinny for everyone. I posted it first on avsim.com, but wanted to repost it here so the information didn't get lost.



Here are 2 quotes from Adam, verbatim:

    "

    FIBER_FRAME_TIME_FRACTION determines the maximum amount of time per frame that we will run fiber jobs on the primary thread. We measure how long it took to simulate and render and then multiply that time by FIBER_FRAME_TIME_FRACTION to determine how long to run the fibers. For example, if it took 10 milliseconds to simulate and render and FIBER_FRAME_TIME_FRACTION was set to the default value of 0.33, then we would allow the fibers on the primary thread to run for up to 10 * 0.33 = 3.3 milliseconds. For fraction values of 1.0 and 2.0, the time given to fibers would be 10 milliseconds and 20 milliseconds, respectively.

    

    The operation of FIBER_FRAME_TIME_FRACTION on single core machines has not changed since RTM.

    

    On multi-core machines in SP1, we moved many fiber jobs off of the primary thread and onto secondary threads. Since FIBER_FRAME_TIME_FRACTION only affects scheduling of jobs on the primary thread, it will have less of an impact on the performance of Flight Sim on multi-core machines. In fact, we moved so many jobs off of the primary thread that there probably isn't enough fiber work left to soak up the full time allowed by the default value of 0.33.

    

    Therefore, on multi-core machines, there's very little reason to tweak the fraction because it really only impacts performance of single core machines.

    "



and



    "

    Please emphasize the pointlessness of tweaking this value on multi-core machines.

    

    Further, setting it to values greater than the default value on single-core machines can increase frame rate volatility because it increases the amount of time we *might* allocate to fibers if there is adequate work waiting in the queue. When the queue is full, we'll allocate the full amount of time to fibers but when the queue is empty, fibers get no time because there is no work to do. If the rate of new jobs entering the fiber queue is bursty and the full time allowed for fibers is large, then you can imagine how this would increase volatility.

    

    If people feel like the fibers aren't getting adequate resources, they would be better off leaving the fiber fraction alone and just lowering the frame rate limit slider, which helps divert more CPU time to primary thread fibers without increasing volatility.

    "

I'd take those words as golden.



He also wanted me to mention that TileProxy is using a FS9 path, basically because it is the only path available for the style of source data involved. However, that path requires massive amounts of file I/O and because of the huge number of files involved it completely blows the texture cache used by the terrain texture compositor. So there is a limit to how efficient that will ever be until we rework the architecture to be more accommodating.



Another question was does photo-scenery benefit from the multi-core work, and Adams' answer was:

    "

    Photo scenery loading, like loading of all terrain data, benefits greatly from our multi-core work. The more cores the better.

-------------------------------------------------------------------------------------

TERRAIN_MAX_AUTOGEN_TREES_PER_CELL=

TERRAIN_MAX_AUTOGEN_BUILDINGS_PER_CELL=

This is still valid with a maximum value of 6000

-------------------------------------------------------------------------------------
After looking round several forums it seems simmer are not taking note of one important thing regarding SP1. It's been mentioned so many times but here we go again.
To guarantee the best results using SP1 Aces request that you install on a FRESH copy of FSX, or RTM as it's celled (This is your DVD version)
Again information supplied from Phil's blog

FSX SP1:Preparing to Install

Setting up for SP1



SP1 needs a pristine RTM.



That includes no add-ons. Many 3rd party add-ons can cause crashes, especially if they load dlls. In that case they will likely need to be refreshed.



If you really don't want to do this, then perhaps you can consider running FSX from the command line using



>fsx /ManualLoad



This provides a dialog for every dll or xml exe that gets loaded so you track down who is the offender if there is an issue.



However, most people don't know how to run FSX from the command line, thus it's safest to uninstall all add-ons.



If you have performed any file modification tweaks, you will need to uninstall or repair RTM.



Then install SP1.



Then start installing your add-ons 1 by 1.



Note:

Uninstalling RTM deletes ALL content of -
C:\Documents and Settings\All Users\Application Data\Microsoft\FSX
C:\Documents and Settings\USERNAME\Application Data\Microsoft\FSX

That is EVERY subfolder & file in that branch.

If you don't back up and save, you will loose config files, flights, logbook, and rewards.

Two files to consider saving:

Logbook.bin &
GrantedRewards.bin



FSInsider.com will have an article live that discusses the uninstall scenario in more depth, please take the time to read it.

-----------------------------------------------------------------------------------------------------

I'll keep adding things as tweaks become available but to be honest, I think SP! rock as it is lol !!!!!!

[cyvr]

Nice info, thanks for posting.

[viDTek]

i wish i cou;ld run fsx i have had it since it came out bu i cant play it with out getting less than 5 fps

[Mango]

Excellent Cell - pinned !

[Vlad]

Great stuff!

[Random Variable]

The only tweak that I'm using now is the tweak that reduces the number of autogen trees.

Edited by Random Variable, 16 May 2007 - 09:40 AM.

[AgonisNewton]

Thanks for this info Cell! I might try these later on together with the new SP1

[Bman.]

Good stuff.  I haven't tried any of these as most of them are "if you have this issue, try X"... not "to boost performance, try X".  Looks like the autogen tweak is still good.  However, the patch has done such a good job with the autogen that it seems I don't even really need to adjust the tree cells.

Just an observation and opinion - It would be nice as the tweaks start rolling in that this pinned tweak thread becomes just that - A refined (1 Post) list of tweaks moderated by one person.  A cleaner bulleted list that's easy to view and understand would be great (like Mango's original thread).  I am certain that the tweak list will be cleaned up and this is what it is from the developers.

Good stuff.  Excited.

[Beefcake]

So you are supposed to get rid of any tweaks we have had before then, right?  How can I do that?

[MrSteve]

Beefcake311, on May 16 2007, 03:47 PM, said:

So you are supposed to get rid of any tweaks we have had before then, right?  How can I do that?

If you installed the patch already, I would have to assume the patch has done a new config, so your tweak settings in that file would be removed already because of the replaced config file.

[Beefcake]

MrSteve, on May 16 2007, 04:33 PM, said:

Beefcake311, on May 16 2007, 03:47 PM, said:

So you are supposed to get rid of any tweaks we have had before then, right?  How can I do that?

If you installed the patch already, I would have to assume the patch has done a new config, so your tweak settings in that file would be removed already because of the replaced config file.

Didn't install it yet... waiting for that reply.  Thanks  

edit: crapdamnit, it didn't change it back to normal after install...

Edited by Beefcake311, 16 May 2007 - 06:29 PM.

[rsperge]

Maybe someone could give me some advise about this issue on which would be a good tweak:

first of all I don't really have a problem with the bluurries,

but my main isue is that I have objects popping up buildings trees and so forth like miles ahead, which one would you suggest cause just a bit confused on how you would write itin the cfg file ?

[Lucas]

Great work Cell !  

[Andydigital]

Quote

Maybe someone could give me some advise about this issue on which would be a good tweak:

first of all I don't really have a problem with the bluurries,

but my main isue is that I have objects popping up buildings trees and so forth like miles ahead, which one would you suggest cause just a bit confused on how you would write itin the cfg file ?

It's supposed to do that now, Phil mentioned it in his blog. It's a trade off for now, they thought higher frame rates were better than lack of popup scenery in the distance. They turned off Alpha Blending (i think it was) to improve the frame rate. Apparently they are going to try and bring it back in the DX10 patch, so the scenery will gently melt into view rather than suddenly just appear. .

Edited by Andydigital, 17 May 2007 - 05:20 AM.

[ditopilot07]

Friends,

Is there a seperate FSX SP1 cfg on which these tweaks should be made to? I ask this question because for some reason, my fsx cfg (in notepad) does NOT have some of those entries, such as:

JOBSCHEDULER]
AffinityMask=n
where
n num of cores scheduled
1 = 1 core 0001
3 = 2 cores 0011
7 = 3 cores 0111
15= 4 cores 1111


[TERRAIN]

SWAP_WAIT_TIMEOUT=<number_of_frames>


[DISPLAY]

ForceFullScreenVSync, default is TRUE

ForceVSync, default is FALSE

[GRAPHICS]

DAY_THRESHOLD

NIGHT_THRESHOLD



acceptible values are 0 to 65535.

Defaults:

DAY: 32768

NIGHT: 4096


What is wrong? And what sould I do????


dito

[iTom73]

ditopilot07, on May 17 2007, 01:28 PM, said:

Friends,

Is there a seperate FSX SP1 cfg on which these tweaks should be made to? I ask this question because for some reason, my fsx cfg (in notepad) does NOT have some of those entries, such as:

....

What is wrong? And what sould I do????


dito

You ADD these entries to your cfg file.

Edited by iTom73, 17 May 2007 - 12:59 PM.

[ditopilot07]

iTom73, on May 17 2007, 12:59 PM, said:

ditopilot07, on May 17 2007, 01:28 PM, said:

Friends,

Is there a seperate FSX SP1 cfg on which these tweaks should be made to? I ask this question because for some reason, my fsx cfg (in notepad) does NOT have some of those entries, such as:

....

What is wrong? And what sould I do????


dito

You ADD these entries to your cfg file.

Where, at the end of each section? E.g. At the end of [TERRAIN]?

Thanks

[iTom73]

ditopilot07, on May 17 2007, 02:06 PM, said:

iTom73, on May 17 2007, 12:59 PM, said:

ditopilot07, on May 17 2007, 01:28 PM, said:

Friends,

Is there a seperate FSX SP1 cfg on which these tweaks should be made to? I ask this question because for some reason, my fsx cfg (in notepad) does NOT have some of those entries, such as:

....

What is wrong? And what sould I do????


dito

You ADD these entries to your cfg file.

Where, at the end of each section? E.g. At the end of [TERRAIN]?

Thanks

Exactly, just put it at the end of the corresponding section. If the section does not exist, add it at the end of the file.

[ditopilot07]

iTom73, on May 17 2007, 01:46 PM, said:

ditopilot07, on May 17 2007, 02:06 PM, said:

iTom73, on May 17 2007, 12:59 PM, said:

ditopilot07, on May 17 2007, 01:28 PM, said:

Friends,

Is there a seperate FSX SP1 cfg on which these tweaks should be made to? I ask this question because for some reason, my fsx cfg (in notepad) does NOT have some of those entries, such as:

....

What is wrong? And what sould I do????


dito

You ADD these entries to your cfg file.

Where, at the end of each section? E.g. At the end of [TERRAIN]?

Thanks

Exactly, just put it at the end of the corresponding section. If the section does not exist, add it at the end of the file.

Thank you so very much!

dito

[h.V]

Can't wait to get a new pc with FSX to try this tweaks