PTaylor's WebLog : tips

Vista OOM fix:Must have update from the mother-ship

Phil Taylor — Tue, 14 Aug 2007 00:14:00 GMT

Aug 28th a fix became available for Vista from the Windows team.

The bits will be made generally available from the link here and relatively detailed KB is attached.

The issue is that Vista was creating an extra copy of graphics memory ( noted by AnandTech here ) and that was causing a pre-mature exhaustion of each process's address space and then the dreaded OOM error. AnandTech reviews this issue further and tests the hotfix here.

Run, don't walk to this download.

FSX Tip of the Week:Water slider and FPS costs

Phil Taylor — Sat, 09 Jun 2007 01:07:00 GMT

So why does FSX not render as fast as your typical FPS game?

The primary difference is the sheer amount of things we render, given a 120+km or greater viewing distance and trying to render the visible portion of the planet within that viewing distance and not some hand-tuned level like a first-person shooter style game. We dont "know" what is going to be rendered at a particular location in FSX, and we cant "tune" the content in any specific way to address performance. Once you establish that as the fundamental difference, it isn’t meaningful to talk about "FSX seems light on shaders" vs GameX, or "FSX seems heavy on CPU workload" vs GameX. FSX is just different.

What we do though, is let the user manipulate settings via sliders and hope they can find a level of detail and visual quality that are both "good enough to look at" and "perform good enough to fly". For the most part, this just works. For the "tweakers", though, I have been blogging on various topics to try to help people understand how FSX works and where different "sweet spots" can be found.

For instance, every one notes that water is a heavy cost, especially 2.x. Why is that so?

Here is a breakdown of what the water slider does:

1.x has no reflections:

· The lowest 1.x level does the basic shader.

· The mid 1.x level adds an animated detail texture.

· The highest 1.x level adds some specular effects

2.x adds a 2nd pass to get reflections and this can be a killer:

· 2.low reflects only the clouds and has a little more complicated shader – it can be a good compromise

· 2.med adds scenery, eg terrain and custom objects

· 2.hi adds Autogen (trees, generic objects ) and basically reflects the entire scene, which costs a lot

Water 1.x thus just increases the shader cost and adds sampling from more textures as you move the sliders to the right. For modern hw, thats no problem.

Water 2.x needs a 2nd pass to generate the reflection. That means rendering the world a 2nd time into a texture as a render target. Which is an obvious performance hit.

And thats just for the 1st 2.x level.

Reading my list above, with Water 2.hi the shader and rendering cost is intense and directly related to full scene complexity. So having Autogen and Scenery to extremely dense coupled with Water 2.hi has a direct negative impact on performance. Water 2.hi, like our other 2 2nd pass features ( shadows, bloom ) basically cuts your FPS in half.

Water 2.med with Scenery complexity at extremely dense and Mesh resolution all the way right means that the 2nd render pass is going to cost a lot. Lower your scenery and mesh settings, though, and 2.med might not be such a FPS killer while adding a bit more visual quality.

Water 2.lo renders only the clouds and the skybox on the 2nd pass, and can be a very good compromise. And in general when over water its mostly the cloud reflections you see except at the shoreline. So this choice doesnt sacrifice too much visual quality and is FPS friendly.

Understanding this lets you make intelligent choices. Water 2.lo with high Autogen and high Scenery is much better than any other Water 2.x because 2.lo doesn’t render the terrain or Autogen.

You have to understand FSX and its performance as a Socratic, holistic thing across all the subsystems and how they interact. It’s really hard to use try a simple Aristotelian breakdown as a vehicle to understanding FSX.

SP1 Tip of the Week:AI at 80% max

Phil Taylor — Mon, 04 Jun 2007 07:21:00 GMT

AI at high is a big cost, at least as much because some of the default aircraft have high Draw call counts. We fixed this for the 3 AI aircraft ( MD-80, Dash8, Cherokee ) and they are 25% of the world wide traffic DB, but default aircraft like the 747 and A320 get used a lot as well.

This adds up. Quickly. High AI is one of the quickest ways to cancel out the benefits of the Draw and SetTexure call reductions we did in Autogen buildings and vegetation.

Having fiddled around with 100% AI a bit, I think you are wiser off sticking at 80% max anyways.

And here is why:

1) Above 80% and the landing pattern gets thrown off, and the AI system injects a plane between 2 that are spaced at 5+ mi, and you get a lot of "wave offs or flybys" by that middle plane; which can be disconcerting because you would never see that at a commercial airport. You still see this at 90%. I haven’t tried 85% or any 1% increments between 80 and 90, but I didn’t notice the flybys at 80%

2) If you are flying the heavy iron, with more than 80% traffic its hard to get a gate, which means no jet way animations, no refueling.

So stick at 80% max.

Fun Factor Alert:

I will say that it’s worth parking on the grass at a busy airport somewhere that you can see both the landing and the takeoff pattern, switching to night time, and switching to 4x time factor. Extra bonus if you can view the terminal at the same time. It’s a hypnotic display at a busy airport and is great as a "screensaver". If you haven’t done this yet, take a couple of minutes and check it out!

FSX:Tweak of the Week ( or 2 )

Phil Taylor — Sat, 02 Jun 2007 03:05:00 GMT

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!

SP1:Tweak of the Week ( or not )

Phil Taylor — Fri, 01 Jun 2007 22:47:00 GMT

Its come to my attention that various people and forums are suggesting tweaks to the ProcSpeed and Perfbucket values in the config file.

Folks, I hate to tell you, but this is the placebo effect.

We generate those numbers at startup and use them to set the default slider values.

PerfBuckets range from 1-7 and correspond to Minimal, Very Low, Low, Medium Low, Medium High, High, Ultra High.

Procspeed is generated by some code we run on the CPU, to help bucket your CPU.

The procspeed and information about your graphics hw contributes to your default PerfBucket setting. Customizing your settings moves you out of the default PerfBucket setting, but there is no "number" for that.

They are not used beyond default settings, and we do not "read" the values back out of the config - they are "write only". We use them internally in our labs as extra verification of hw, there is no use in changing them. If you think that changing them is doing something, its not.

SP1 Tips

Phil Taylor — Thu, 24 May 2007 01:33:00 GMT

Here are some general suggestions and a few tips I have gleaned from the forums.

General Performance

The goal of SP1 was:

· to increase performance 20-40%

· to enable FSX to take advantage of multi-core machines

· fix some other bugs

There was not a goal to make FSX playable with all sliders to maximum. Those settings likely aren’t going to be possible in all cases with current hw.

Ok, so what is possible? That is dependent on your specific config and your specific flying profile.

A technique to determine what is possible is as follows:

· Decide on a minimum frame rate, like 20.

· Lock FPS to that rate.

· Start with all sliders left, and slowly turn them up until you find a setting that makes you dip below your rate.

· Then back off and you are at the level of what your machine can handle.

In general, even with SP1, it’s still true that at max settings FSX throws more at the CPU and GPU than the hw can handle. As I said last November, that is the way we designed FSX. SP1 helps some yes. And the Penryn 45-nm processors this fall will give us another boost. The DX10 update might help a bit, as will 2^nd generation DX10 cards. So more help is on the way. But, just as with FS9, in the 1^st year expecting to run on max settings is still going to be problematic.

I would also suggest saving a couple of different settings, one for dense urban, one for mixed coastal urban, one for mostly flat rural, and one for mountainous rural. That lets you have settings that bias towards what is most important in what region instead of a "one size fits all approach".

Specific Issues

I can’t claim to have a suggestion for all the specific problems I have seen so far, but here are a couple of good ones for specific issues. Note - I can only claim that multiple users state these work, I haven’t tried all of them myself:

Crashes in atiumdag.dll on ATI?

Reports indicate that disabling Catalyst AI fixes this.

Stutters on nVidia

dg on avsim reports indicate the following procedure greatly helps:

1. Update DirectX to the April 2007 release. The link is below.

April 2007 DirectX Link
http://www.microsoft.com/downloads/details.aspx?FamilyID=2da43d38-db71-4c1b-bc6a-9b6652cd92a3&DisplayLang=en

2. Install updated drivers ( nVidia recently released the 158.22 nVidia Forceware drivers ) and we hear that a release in 2-3 weeks will fix the texture locking issue that the glass panel tweak addresses.

3. Delete your fsx.cfg and let FSX generate a new one.

Blurries

Gary Summons reports that adding

[DISPLAY.Device.xxx.0]
MipBias=6

To your fsx.cfg file reduces or eliminates the blurries especially with photo-scenery

Note: xxx is whatever your fsx.cfg shows for your graphics config.

Edit1:

I have seen people try values of 4-7 with varying success as well.

Edit2:

Thanks to weeniemcween on avsim.com, if this tweak induces shimmer in the trees, there are 2 things to try:

1) nhancer nvidia control panel, turn supersampling on ( ati must have an equivalent, I just dont know it )

2) if the 4x4 overdraw from 1 is killing your perf, try setting "Negative LOD BIAS" to "Clamp" rather than "Allow"

FSX SP1:New tweaks

Phil Taylor — Wed, 16 May 2007 02:29:00 GMT

In fsx.cfg

---

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

Tweak of the Week

Phil Taylor — Fri, 11 May 2007 11:54:00 GMT

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.

"

Hope this helps.