P3D: 64-bit development appears hopeful ;o)

[Guest]

 

You can live in denial all you want, but the simple fact is your setup is the problem.

 

I love simple facts ... especially the ones that have no supporting evidence.  

 

FYI, memory leaks don't multiply ... hence why they are called leaks.  But please do share what you think a memory leak is, details please?

 

P.S. warning, I am a software engineer and have over the past 30+ years of coding created a few of my own memory leaks in some of the applications I've created and I'm very aware of how memory leaks start.

[HighTowers 1,434]

Because the only reason you hit a limit is because the architecture of the graphics engine is ancient. If you could run proper DX10 or DX11 then you would never get close to the limit.

 

You should never be hitting the limit unless your setup is bad.

 9.5 is ridiculous, why don't you also assign the PMDG 737NGX as Ai aircraft since all you want to do is crash the sim. I don't even think that was supported, I know P3D sets 6.5 to default.

 

But either way you don't seem to understand that all this proves that a proper graphics engine is what is needed. A DX10/11 engine could easily run 4096 textures and 6.5 radius on a high resolution.

 

What does x64 have to do with that??? Nothing!

 Of course there's something wrong with your system. You have a memory leak somewhere. Either a duplicate afcad file, corrupted scenery, corrupted AI texture, or an empty texture folder.

 

You can live in denial all you want, but the simple fact is your setup is the problem.

 

The only thing an x64 version of P3D would do is let that memory leak multiply like crazy.

Sorry . Have to disagree. I did this test before on another thread.   Brand new FSX install. Optimized FSX.CFG. No addons.  Running default 737 at max settings everything I barely hit 1.6 gb on the VAS.  Then I slowly added a few addons. First FSDT CYVR and KLAX. Still default 737 and now Im hitting 2.5GB.  Next add weather and traffic, Orbx PNW, and a couple other addons and voila, 3.6-3.8GB.  Once im in the air with all kinds of scenery reloads the warning bell goes off.  Running DX10 reduced it to acceptable levels again along with reducing the texture resolution.  Nothing wrong with the setup. All Fresh installs. If I use a less complicated aircraft its reduced yet again. Clearly there is an impact on RAM usage. There is no way that it could stay the same unless you run absolutly crap resolution and settings. 

Fact is that all these addons use memory. Other games dont have all these addons that eat up memory. Once the game loads, the VAS stays relatively around the same. 

[JSkorna 137]

Your weather program or data does not use any FSX memory space, nor do any other utilities that run outside of FSX.

[Q_flyer 766]

This can be managed, in the dll.xml file. by adding the following line in each optional entry (The dll's that are used on every flight leave alone.)

 

<ManualLoad>True</ManualLoad>

 

This will cause FSX to ask at startup whether to load them. It's a little inconvenient, but you can save enough address space, that you can run without OOM's. Since doing this I can now run the NGX without OOM's before I rarely completed a flight without OOMing when flying the NGX. I'm still on 32bit Vista which makes my system even more susceptible to OOM's, then those on Win 7 or 8 64bit. 

 

This is EXCELLENT info, that I was not aware of.    Thank you!

[tttocs 301]

But either way you don't seem to understand that all this proves that a proper graphics engine is what is needed. A DX10/11 engine could easily run 4096 textures and 6.5 radius on a high resolution.

Be careful with your attributions and the use of "you", please. I was simply pointing out that robains' OOM errors were coming with some very extreme settings that will certainly stress any system. Run high res, high LOD radius, add in some clouds and a good mix of add-ons and you're going to get OOMs in FSX. There's nothing "wrong" per se, but compromise is required. Removing the 4G VAS limit would certainly help push limits, but no I don't believe that's the only path to nirvana, it's only one potential element of such a path.

 

Scott

[HighTowers 1,434]

Your weather program or data does not use any FSX memory space, nor do any other utilities that run outside of FSX.

No but clouds and other textures certainly do. See what your VAS is with 4096 cloud and runway textures vs 1024. 

[tf51d 284]

 

You can live in denial all you want, but the simple fact is your setup is the problem.

 

The problem isn't setup per say, but that we're using much more demanding addons like OrBX and the NGX that eat, VAS. If FSX was meant to handle 4096x4096 resolution graphics and extending the LOD values etc, it would be an option in the GUI! It's nice that FSX even allows this, but when problems like OOM's occur because of it, it's disingenuous to blame it, for something ACES haven't even thought of at time of development.  (From the SDK "For Aircraft, texture maps cannot currently exceed 1024x1024 pixels in size. However they can be smaller, as long as the dimensions remain a power of 2. It is also possible to make more than one of each map type for a single model.") Even with this as I said it is currently manageable to a point, but loaded this way it wouldn't take much to push it over edge. The good news is the current trend of creating external addons that run in their own address space. While DX11 may improve performance I'm not sure it will help reduce address space usage, so I think going 64bit would still be necessary, for capabilities of the sim to continue to advance in the future.

[JSkorna 137]

Tom,

 

You hit the nail on the head. Users set up FSX beyond the limitations of the base program and then point their expert fingers at it, complaining.

[Noel 4,504]

ever

 

Eventually flight simulation will, just like all computing progressed in bit depth since the dawn of programming.  XPlane did already.  And they were wise to do it BEFORE the devs jump in.  As parallel processing improves so does the need to address larger and larger address spaces.  Whether or not LM does, you are right who knows.  THEY ARE at least discussing it at some level.

[JSkorna 137]

Fair enough!

[Guest]

Sorry folks, but this debate is getting a little nuts ... lots of bad information about DX11 and 64bit and RAM usage.

 

As much as I like Tessallation (and I do), it produces a huge performance hit as it subdivides a poly and that's NOT done for "Free".  And graphics performance is VERY much about poly count and textures.

 

Yes, I push the envelope of FSX -- why?  To increase visuals and the presentation of reality ... isn't that the entire purpose of a "simulation" - hence the word simulation ... to simulate reality (be it visually and/or in aircraft systems)?  I'm certainly not complaining, I know FSX limitations and work with them ... but it's a compromise that seems to increase each year with every update of various 3rd party products (PMDG 777 for example is going to be more RAM hungry than NGX).  

 

So are people here suggesting to 3rd party developers to NOT improve their products??  They can't add functionality or improve texture quality without using more RAM, just impossible.  But I'm confused, is anyone here really suggesting to NOT buy 3rd party add-ons because they are pushing the limits of FSX??  This is good how?

 

Someone show me how DX11 is going to reduce memory usage over FSX's current DX10 preview?  Some details please, not speculation of how you think DX11 works vs. DX9c or DX10.  I know everyone here is aware that FSX works in DX10 mode?  Look up the feature differences between DX10 and DX11 and tell me how DX11 is going to make improve FSX frame rates of current DX10 mode?

 

You can change how FSX renders and make it multi-GPU friendly but you'll find that could be done with DX9c and DX10, it's not a "feature" specific to DX11.  FSX sadly was not coded to do that ... I'm betting the usage of some Assembler code as the source of this "not friendly to multi-GPU".

 

Anyway, whatever you folks wanna believe ... it's not like anyone here actually has any influence on what LM do and don't do.  Lets re-visit this in 2016 with P3D v2.0 that "might" be DX11 shall we?

 

Every simulation or game I'm aware of that pushes the envelope of poly count and texture quality has moved to a 64bit path ... from Crysis to XP10 to iRacing ... and it has NOTHING to do with DX11.

[Noel 4,504]

But I'm confused, is anyone here really suggesting to NOT buy 3rd party add-ons because they are pushing the limits of FSX??

I'm suggesting (to myself only) to NOT to buy add'l 3rd party add-ons because I really don't want to invest in this dead pathway any longer as I see its future demise is in sight. Actually, maybe it's more accurate to say I hope its demise is in sight. It runs good enough to enjoy on current hardware as we know. But we also all know it bogs down greatly still under complex conditions, and next gen hardware will not affect this meaningfully IMO. I'm quite frankly unimpressed in 2013 w/ the need to use a brute-force approach to overcome the dated engine built for a different hardware environment--i.e., the need to buy deluxe cooling solutions, perform risky de-lidding procedures, inane fine tuning of memory timings, just to get a few more clock cycles and frames per second. I currently fortunately have enough add-ons to enjoy the sim immensely. I'm still not sure if I should jump in to XP10 64bit, but I'm tempted if only to give a tiny bit more attention to more forward looking, albeit currently not nearly as deep product. Maybe we need to harangue Donald Trump and get him behind building a new core engine yeah, 64bit 12-core support, full utilization of physical ram on board within the limits of the OS, multi-GPU support. This stuff already is here, i.e. the hardware. It's just the bloomin' software! Or maybe Richard Branson ...

[TheDanger 182]

Tom,

 

You hit the nail on the head. Users set up FSX beyond the limitations of the base program and then point their expert fingers at it, complaining.

The purpose of going 64bit is to expand those limitations.

 

If you had a car and went camping each weekend but the camping gear wouldn't fit in the car so had to have some trailing out of the window, some lying across the passengers, some tied to the bonnet etc eventually you'd either

 

a downsize the amount of camping gear - reduce FSX addons

b give up camping - uninstall FSX

c buy a bigger car - move to 64bit

 

I did option a and I am happy with it and am currently waiting for the possibility of option c

[ChaoticBeauty 6,692]

There's no need for a 64-bit version of FSX. All Prepar3D 2.0 needs to do is learn how to clear the VAS when you fly to another area, so there won't be any OOM errors after a long flight.

 

OOM happens after a long flight and not at the beginning, right? That's because FSX cannot clear the VAS for the previous scenery area efficiently. With even more VAS available, more can be done in add-ons. Have it use 4GB efficiently, and then move to beyond.

[virtuali 4,421]

Your weather program or data does not use any FSX memory space, nor do any other utilities that run outside of FSX.

 

The weather program itself might not, but if it's asking FSX to create multple layers of 4096x4096 textured clouds, you can be sure it will use FSX memory space.

 

What can be successfully modified to be run externally, and save memory from FSX, is the program *logic*.

 

For example, airplane developers who explains their product is memory hungry because of the complexity of the simulated systems, could probably modify their gauges to have that logic running externally, but if the memory occupation is caused by creating lots of graphics inside FSX, there's not much one can do, other than trying to optimize it as best as possible.