PTaylor's WebLog : fsx

Acceleration and SP2

Phil Taylor — Wed, 03 Oct 2007 09:23:00 GMT

Overview

Acceleration has RTM’ed. Acceleration Pack contains the SP2 fixes; including both DX9 and DX10 work. Acceleration Pack looks really good, and for the $30 US list price there is a lot of value with 3 aircraft (F-18 jet, P-51 racer, EH101 helo), along with 30+ missions and several new “sim” features like a functional carrier, slingloads and hoists for the helo, as well as the multiplayer racing experience. And I am probably forgetting features. There is quite a bit of value there.

Acceleration will be available in late October. FSX-SP2 will be available sometime after Acceleration Pack and before Christmas. Edit:Acceleration includes SP2 bits, and SP1 and thus does not require SP1 to be pre-installed as there is room on the DVD for it, but the downloadable SP2 does require FSX-SP1 to be installed. As I have previously stated, SP2 will include DX9 fixes as well as DX10 support. So with the release of SP2, Aces will have fulfilled its commitment to 2 updates for FSX RTM customers in 2007.

I want to make clear two important details about the DX10 part of Acceleration and SP2:

1) From a feature perspective, we do not match the magic screenies item-for-item because those screenies ignored an important visual element—the aircraft. We added virtual cockpit shadows to the work list because this feature further enhances the immersion. Of course, we also faced schedule and other constraints.

2) We are not promising runtime backwards compatibility in the current DX10 code path now or in the future. This is for two reasons:

a)The first is to send a message that we are going to change the backwards compatibility story moving forwards.

b)The second is practical, in that continuing to provide the backwards compatibility we do is a huge drag on forward progress. Spending time on 4 or more code paths (FSX DX10, FSX DX9, FS2004, pre-FS2004) costs us time that could be spent polishing the existing features, working on resource management to fully eliminate out of memory errors, and working on performance. We have to change that balance and in the DX10 preview you can see the first notice of that. Yes, we know we have to address some features that are not possible using the FSX SDK in future SDKs so that 3rd party developers are enabled and do not depend on these old techniques and we accept that.

Because of these two issues, we are labeling the DX10 support a “preview” in the UI. We expect it will add value; but we are not expecting the DX10 path to replace the DX9 path as the primary experience in FSX and expect third parties to author to the DX9 path in the large. And yes most add-ons should continue to work in the DX9 code path in Acceleration/SP2, as long as they don’t depend on the old BGL compatibility path. An example that no longer works is the B-307 Stratoliner, it uses a decal alpha technique that we didn’t get re-enabled in either DX9 or DX10 after the re-plumbing work involved with SP2.

I know some are going to be disappointed, and some disappointment is reasonable. I will be the first to state that Aces releasing the magic screenies was flat out a mistake; but us not matching that level of “vision” ( and that is what the magic screenies were ) is not a cause for a flame war against Aces or DX10. I should note, for instance, that the DX10 code path performs better under load than the DX9 code path, and this means the DX10 features are more useable. And DX10 does look better, both in the cockpit and in the world.

Let’s move on to detail on the specific features in SP2, from both a DX9 and a DX10 perspective.

FSX SP2-DX9

Here is a list of what is in SP2 from a “global install perspective” and not just on Vista when DX10 is active:

Fixes and Features Core and Graphics

1) 8-core bug fix

2) 3G enabling FSX and Autogen memory use optimization

3) Exterior shadow quality improvements

4) Optimization of terrain IO for photo-scenery and “scenery load out of the zone” fixes to help reduce blurries

5) More batching of Autogen. This will help in areas where a lot of custom objects of the same material are authored and complements the SP1 batching work.

6) 737 and A321 night/taxi light fix with new models

7) Raindrops in the 2D cockpit

Audio, International, UI

8) Audio fix for soundcard/usb to speakers/headphones on Vista

9) Various internationalization fixes

10) Saving undocked panels

11) UI fix for flight list to be alpha-sorted when "Title" is clicked

Multiplayer

12) Multiplayer compatibility with XPack for free-flight. With all the changes in Acceleration, SP1 is not free-flight compatible. SP2 addresses that.

13) Multiplayer fixes for

a) when using DIRECT CONNECT, FSX now remembers the last IP used

b) COM1 shared cockpit sync

We didn’t get either the “w” key issue or the alpha-fade for Autogen into SP2. We just couldn’t get to those fixes. We still have a good set of fixes, even without those two, and we hope the DirectX9 user is happy with the two service packs we have delivered this year.

FSX-SP2 DX10

The features we do have are:

1) VC shadows

2) HDR Bloom

3) Water enhancements

4) Efficiency improvements via more Autogen batching, more efficient shaders, and a more efficient method of generating bloom.

In looking at the magic screenies, we realized those screenshots show nothing “in the plane” and instead concentrate on atmospherics and water effects that will only be visible when:

1) the right weather or angle of view happens

2) flying low and slow

So we went back to the drawing board and decided to invest differently. We decided atmospherics and water should still get some attention, just not the entire effort. And we decided we needed to do something for the pilot in the plane.

So we decided to enhance the VC experience with shadows. VC shadows greatly enhance the realism in the virtual cockpit, and are the logical extension of the airplane exterior self-shadowing.

Atmospherics are an important part of the flying experience, so we wanted to improve bloom. HDR Bloom takes a feature that is almost unusable in DX9 because of performance and makes it both visually better and usable from a performance standpoint.

Given the globe is 70 percent water or more - water enhancements still make sense. What wasn’t possible was to match the water in the magic screenies due to the confluence of hardware issues, constraints on new content, and schedule. What we have does make the water visually different with whitecaps and make water react to weather—wind causes whitecaps on water.

In terms of efficiency improvements – first the water shaders are more efficient, as is the way we generate bloom using HDR techniques. We now batch what are called “Autogen 2” objects in addition to the Autogen 1 objects that were batched in SP1. In areas where there are a lot of Autogen 2 objects ( library objects ), as opposed to the entirely procedural Autogen 1 objects, users will get a nice performance bump. If you don’t have a lot of Autogen 2 objects, then of course you won’t get much improvement.

Ok, that’s not what some people where expecting, even after I have tried to reset expectations, but it’s a nice bump for DX10 users.

Two things we had hoped to get in on the DX10 code path; but we just didn’t get to are crepuscular rays and improved world lighting. We had hoped to improve the world lighting, so that back sides of buildings and trees showed better rendering; as well as render crepuscular rays ( popularly called godrays ) through the clouds but those two features didn’t make the schedule when we added the VC shadows.

And the lack of FSX-SP1 level backwards compatibility is the key reason why what we decided to label the FSX-DX10 work “preview”.

With that said, you now know what is in FSX-SP2 from a DX10 perspective. At this point, from a studio perspective it is time to move on from FSX so we have no future updates planned for the engine.

Here are two screenshots to show the efficiency of the water and bloom improvements, taken on a 2.4 Ghz Intel Core Duo, with 1GB of RAM, and a GeForce 8800 GTX.

DX9 ( 24.1 FPS, 30 set as goal )

DX10 (30 FPS, 30 set as goal )

That is 20% better FPS under load.

I’ll get to feature by feature shots in a future blog, right now I have other tasks that are a bit higher priority.

Thanks for listening.

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.

Platform performance Update:early reports on Fall CPUs is that they rock!

Phil Taylor — Tue, 07 Aug 2007 22:17:00 GMT

It appears the promise of the Penryn/Wolfdale/Yorkfield Intel CPUs is being born out.

See http://www.guru3d.com/news.html#5723 for an early performance report.

This bodes well for the future, and is something I started mentioning months ago as a positive platform performance step that would help FSX like its going to help every app.

Windows update ( XP and Vista ) for Intel multi-core processors.

Phil Taylor — Tue, 17 Jul 2007 02:37:00 GMT

A microcode update from Intel that affects multi-core processors, here.

This seems like a good update to take, even if I don't have much more data than you do.

Vista Appcompat update for FSX

Phil Taylor — Tue, 10 Jul 2007 21:28:00 GMT

The KB located at

http://support.microsoft.com/kb/932246/

contains an application compatibility update for Vista that include changes for FSX that enable us to fix the disabling of Aero when you launch FSX on Vista.

This came out earlier this year, but I wasn't aware of anything that would make me recommend it. Now I do :--), as that is one of the few issues we are considering fixing in the FSX-DX10 release outside of adding Direct3D10 support. Edit:that doesnt mean we will, just that it is under consideration and this download will be a pre-req.

I highly suggest downloading this update:

Download the Windows Vista Application Compatibility Update for 32-bit editions of Windows Vista package now.

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:Performance work

Phil Taylor — Wed, 16 May 2007 01:55:00 GMT

Finally, we have shipped!

It’s been solid work since Nov from the Graphics and Terrain team on SP1 performance.

Here is a work-list on performance so you can understand what we did:

General Performance Work

1. performed more work on the LOD system,

2. optimized the UI rendering to reduce overhead when the UI is visible,

3. front-end texture loader no longer loads loads full mips when it doesn’t need to

4. removed redundant elevation queries when scenery complexity is low

5. avoid rasterizing water into the DEM for textures that are all land

6. fixed redundant vertex issue with key Autogen BGLs

7. updated XToMdl tool to leverage same vertex issue, resulting in model vertex reduction on the order of 25-40% for 3rd party developers.

D3D Performance Work

8. enabled skinning for more animated objects; which reduces Draw calls,

9. batched Autogen objects to reduce Draw calls,

10. optimized tree rendering to reduce SetTexture calls

11. coalesced shader state to reduce uploads to the card

12. fixed 3 FS8 AI aircraft in terms of Draw calls. This is the MD-80, Dash-8, and Cherokee. This is a >10x reduction. They are 25% of the worldwide air traffic DB so this can be significant.

Multi-core Performance Work

13. moved DEM loading to threads,

14. moved terrain texture synthesis ( the process itself is documented in Adams' "Global Terrain Technology for Flight sim paper at http://fsinsider.com/Community/Developers-Corner/Global+Terrain+for+Flight+Simulator.htm, see the bit about the layers and texture synthesis ) to threads,

15. moved Autogen batch rebuilds to threads

That’s 15 different work items. We were busy!

How it went together

Now, don’t think because we are calling it a “patch” that we are doing binary patches. We are not.

Yes, we use a delta-patching technology in the installer. For scenery bgls and the like. Even there some files have changed enough that the delta-patcher cannot handle them and we have to have a "full file" in the patch. The bgl for the Japanese traffic data is an example, we reversed the traffic vectors for the entire country, and almost every byte changed. We tried to put it through the delta-patcher, but it keeled over and gave up and errored out during setup.

We *are* rebuilding the binaries from scratch. Thats not trying to patch the old binaries, its replacing them with new files, many of which have quite a bit of new code. The multi-core work, for instance, went thru the terrain code stack from top to bottom. Thats one reason why SP1 took so long. The multi-core infrastructure is solid, will use up to 256 cores if available, and will continue to be used as we migrate systems to it as it makes sense. Terrain and autogen are it for now, we'll be evaluating when to do more.

General Performance Work

The general performance work reduced the amount of work we try to do in various scenarios. I want to call out the redundant vertex issue, that’s a key thing we fixed in the Autogen blgs (autogen.bgl, vegetation.bgl, and roofs.bgl) as well as in the SDK tool to pass the savings on to all 3rd party developers when they reauthor with the SP1 SDK.

D3D Performance Work

D3D API usage work was aimed at reducing our Draw and SetTexture API calls. So what are Draw and SetTexture calls? These are the D3D9 API calls that the engine issues to push textures and draw triangles down to the card, the bulk of the work in rendering. We were issuing way too many Draw and SetTexture calls; SP1 is a 35-40% reduction in both. Taking those optimizations is aimed at enabling the app to scale better on GPUs. We took some optimizations on shader state to, which is a nice win. And the 3 FS8 AI aircraft where just horrendous in RTM so that’s another nice fix.

Multi-core Performance Work

Intel is using FSX as one of their prime examples at IDF, we had a lot of engineering time from one of their threading guys. Intel doesn’t do that lightly. We used the time to good benefit.

During loading, we run the DEM loader on threads. You'll see good balanced usage across all cores; as well as about 1/3 faster load times on average.

During flight we spawn threads for Autogen batch rebuilds as well as the terrain texture synthesis. The terrain texture work tends to be a bit bursty; as an area gets generated the load reduces true. But as you fly forward, as you bank, and as the terrain is lighted ( once a minute ) threads are spawned. The terrain grid system is radial around the current viewpoint, and, depending on level of detail radius can be up to 4.5 tiles in either direction, something like 64 tiles. So there is plenty of work to go around. Autogen is more constant, with a 2km extent being batched.

Even given the bursty nature of the core usage when flying; when there is load, its pretty balanced across the cores. And we got rid of as much of the stutters as we could by going to a lock-free synchronization style. Its solid work that we are deservedly proud of.

As far as practical limits on number of usable cores; currently SetThreadAffinityMask only allows explicit scheduling of threads on 32 cores ( the mask is a dword ) on Win32. So thats our effective limit on number of cores. But as soon as there is a way to explicitly schedule them, we can handle 256 cores.

Conclusion

With all that said, the Draw and SetTexture API call reductions and Autogen size reductions are probably as important for FPS improvements; the multi-core work really shines for load balancing and reducing stutters and blurries. And both are critical for better scaling as CPUs and GPUs get better.

We think SP1 is going to deliver the goods for most users, and will reward users with better hw the most. We expect that, except in the very,very low end hw, all users should see a 20% gain. Some scenarios will see 40%, and some will see a bit more. Its really going to depend on a lot of variables. We hope this enables users to either fly at the same settings with greater FPS, or to bump the sliders up 1 or 2 ticks and still get the same FPS you had.

It’s going to take time to see if that holds true, but we had good results in our perf lab and with the beta testers.

Note 1:

The vastly improved batching of Autogen was one of the major performance items in SP1 and helps to reach our target reduction of 35-40% for Draw and SetTexure calls. However, it does have an implication that, when coupled with a feature we lost from FS9, you should be aware of.

FSX does not “alpha-fade” Autogen in the distance. This makes for a discernable “pop” of Autogen objects. SP1 batches objects in a 2 km boundary. This, when coupled with the lack of “alpha-fade”; does make the Autogen “pop” a little more obvious than in RTM. We think it’s a fair tradeoff, though, for the performance gain.

For DX10 we will look at bringing the “alpha-fade” back.

Note 2:

We changed our bucketing code in SP1, so if you use “Restore Defaults” from the UI, you may see different default settings. What did we do? Well, RTM only detected up to 512m of memory and used that as the “Ultra High” setting. With the 768m 8800 card out, there was no way to stratify that above the 512m 7950s. So we detect 640m of graphics memory and treat 640m and greater as “Ultra High”.

There is an issue on Vista, where on some cards it can report a “shared” memory value larger than the physical value and that confuses our bucketing code. If you don’t have a DX10 card and you are getting bucketed “Ultra High” for instance, change your settings down. We’ll take a look at this again in DX10 to adjust the Vista bucketing.

Heads up Vista FSX flyers – Vista multiple monitor fix now available!

Phil Taylor — Wed, 25 Apr 2007 06:33:00 GMT

There has been a known issue with Vista and multiple monitors, where trying to go full-screen with any application did not work. A black or flickering screen was the result. Fortunately running windowed was no problem.

Customers who called in were sent to the KB page here.

Now there is a fix available here. And the KB page has been updated to reflect that.

Just to clarify, this is a Windows Vista OS fix, not an FSX fix and not related in any way to SP1 for FSX.

Edit: Here is the link for 64-bit Vista.

The PC Industry, Multicore, and FSX ( with a little DX10 thrown in for good measure )

Phil Taylor — Wed, 14 Feb 2007 22:08:00 GMT

This is a recap of an AVSim.com post, that I wanted to capture here.

I'd like to take the time to address 2 areas that come up often:

1)FSX designing for multicore
2)FSX designing for DX10

1)FSX designing for multicore

As I stated in a previous post last year, the switch from Ghz to Multicore took most everyone by surprise in the entire industry. Reading a little history and thinking it through is informative.

All during 2004, when FSX was still in design stage and could be easily changed, the roadmaps were still predominantly Ghz based and multicore was a "variant".

Take AnandTech, a highly regarded site and look at their reviews throughout 2004.

Q1 2004 review
http://www.anandtech.com/cpuchipsets/showdoc.html?i=1948
no mention of cores

Q3 2004 review
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2233
cores are a "variant", as in "it would make sense if the FX-57 were to come with a dual core variant"

Q4 2004 review
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2303
It is only at the end of Dec 2004, with this review, that cores have been elevated somewhat in importance but note Ghz hasnt been deprecated hence quotes like this:
"There are other areas besides the high-end multi-core arena, and we haven't seen the end of increasing clock speeds yet"

Now move to 2005, and lets look at Toms' Hardware
http://www.tomshardware.com/2005/04/05/the_pentium_d/page2.html
and this review has a section "Sorry Guys, Clock Speed Does Matter" so the fact that the technology pony had jumped the tracks from Ghz to cores hadnt sunk it, even at sites whose job it was to keep up with this.

It isnt until 2006 that it has really sunk in and permeated the community. Mainstream sites have picked it up, like http://www.informationweek.com/shared/printableArticleSrc.jhtml?articleID=175802849.

Still enthusiast sites like http://www.guru3d.com/newsitem.php?id=3620 mention:
"Now through to the end of 2006, we will see Conroe taking up roughly 20% of Intel's shipments by then end of the year while the Pentium D processor will remain the largest bulk of Intel's desktop shipments."

So from a volume standpoint multicore wasnt seen as a majority in 2006 thru the entire 1st quarter and March IDF.

So while its easy to say "why didnt you see this coming" I think when you look at the available data it should be pretty clear that it wasn't that easy to see it coming.

Given where FSX was, by end of 2005 and early 2006, when this data started to sink in the project was so far past design the team couldnt react to rearchitect within the existing plan. It wasn't really an option to ditch the existing plan.

Even with that, we do have some multicore usage today and are working to get more. We reacted as we could within the original plan. So be careful with comments like "not once did they think" as that just isnt true.

2)FSX designing for DX10

With the last slip in Vista, combined with the associated slip in DX10 hw, the new DX10 schedule put it outside of the FSX ship timeframe. We didnt get DX10 prototype hardware until after the product was in manufacturing. Well after.

DX10 is a fairly major rewrite. And without hw on a title like FSX it is a major challenge to make forward progress. So we didnt think it wise to wait and shipped on DX9. We did think about what could be done with DX10 and we do have a good plan. And many of our existing features that challenge the DX9 pipeline should get better in DX10.

So we are really looking at what can be done with cool new features like texture arrays, large constant buffers for shaders, long shaders, low overhead API calls, better small batch Draw call behavior, etc. I have promised to go thru the "artistic impression" screenshots we have released and detail what features we see in them. We need to ship SP1 first and get back on to DX10 so I can talk to what features will actually be in the DX10 update and not a wish list. So give me time on that discussion.

In conclusion, given the jump from FS2004 to FSX, I think people should be a bit more careful in making accusations about the dev team and its thought process. We were most decidedly not sitting still. And its entirely too easy to play Monday-morning quarterback.