Thinking about the max VAS size of 4 GB with a 64 bit OS (Win 7)  and the limits of a 32-bit application such as FSX, have any software gurus attempted to correct this issue short of suggesting FSX needs to be recoded entirely in native 64 bit format?

 

Thinking  about this issue and the workarounds to live with it, it is probably the real limiting factor to FSX at this stage - at least from the aspect of adding denser and more detailed scenery and aircraft. The g3dll crash issue was fixed finally - and perhaps the VAS limitation issue is beyond any real fix - but could any external software routines "flush" the VAS so that it doesn't max out and cause FSX to crash?

 

Scott

The only way that you can teach a computer to count more than 2 to the power of 32 bits, is to not program it in 32 bit.

 

2³² = 4294967296, aka 4GB.

 

To a 32 bit program,  

4294967295+1 =  4294967296

4294967296+1 = Error. Can not do.

 

Incidently 2 to the power of 64 (64 bit) isn't "Double" 32 bit.

It's a power,

 

so 1 to the power of 2 is 10, 1 to the power of 4 is 1000.

 

64 Bit can address something like 18446744073GB, rather than 32 bit's maximum of "4"GB

 

2 to the power of 64

 

So while 32 bit can read 4294967296 bits, 64 bit can read 18446744073709551616 bits.

 

Why powers of 2? Binary.

 

So while FSX is a 32 bit program, we might be able to find out how best to use the 4GB it can allocate by flushing out VAS and such things, but creating a new sim in a 64bit programming language would open up a theoretical 18446744073GB VAS.

Probably the closest thing we'll ever have to save FSX from crashing with OOM is if someone writes some sort of tool to clean up FSX's 'cache' and let FSX know it's fully available once again. Something in the lines of:

 

 - FSX is still caching some data from the airport we took off 200nm away

 - Clean up that data (where is it, how large it is... problematic)

 - Let FSX know how much cache it has free once cleaned up (yeah right...)

 - Loop back and clean other unecessary data

 

This is, obviously, a dream :rolleyes:

Or, how-about, if a piece of memory/cache hasn't been read by the executable in more than a certain amount of time, clean it out, make it available again...  :huh:

Or make a 64bit sim and have 18446744073GB available

 

Only time you'd need to clean out VAS is if you started simulating specific atoms in the world.

From what I understand, DX9 keeps a copy of the scenery in VAS and DX10 doesn't so I suspect with add ons like the PMDG 777 it will act as a catalyst for DX10 adoption for FSX. Not a cure but another band aid for sure.

Or, how-about, if a piece of memory/cache hasn't been read by the executable in more than a certain amount of time, clean it out, make it available again...  :huh:

 

This wouldn't work - you would need extremely good knowledge of what every single bit and byte stood for and that's just not going to happen without access to FSX's source code. You might clear away some unused stuff, but you also might clear away something important that does need to sit there for a while without being used - those do happen in programming.

From what I understand, DX9 keeps a copy of the scenery in VAS and DX10 doesn't so I suspect with add ons like the PMDG 777 it will act as a catalyst for DX10 adoption for FSX. Not a cure but another band aid for sure.

 

I swear this is like the telephone game - something different every time I see this lol. The true statement is that the in-use video memory is not copied into VAS in DX10. "The scenery" will always be there because that's what the FSX engine does. It is also not 100% clear that this doesn't still happen in some way in FSX DX10 given that it's an incomplete and preliminary "preview" implementation that MS never finished.

Thanks for the clarification, yes it was in use video memory, I remember now. My graphics card is over a gig in memory so any reduction there would help.

 

Forgot to mention have dropped clouds down to 1024 res max now.

 

Ryan has there been any thought about moving stuff out of the FSX process like a few add ons do? Would reduce the VAS constraint and also could utilise many cores. Of course would add complexity though.

Ryan has there been any thought about moving stuff out of the FSX process like a few add ons do? Would reduce the VAS constraint and also could utilise many cores. Of course would add complexity though.

 

I understand that most of the 777's background processing is already done outside FSX.

yeahm... I guess pulling the slider is the only way we can drive the 777 without OOM on finals

I understand that most of the 777's background processing is already done outside FSX.

 

In order to access to a separate VAS, a program must run as an external .EXE. Anything that runs in-process with FSX, which means any .DLL/.GAU file that are loaded either by DLL.XML or in the panel.cfg, will take away from FSX VAS space.

 

Maybe you are referring about the PMDG running its own internal system simulation in the background, but in order to do this without taking away memory from FSX, it would need to run as a separate .EXE file, which I don't think it's the case.

 

Some example of FSX add-ons that have their LOGIC running entirely outside the FSX are:

 

- Ultimate Traffic 2, because it generates AI traffic from the external UT2Services.exe program.

 

- Our own GSX, that runs all its code under the Couatl.exe program.

 

Note that, I've said the program's LOGIC is not taking any memory away from FSX, when it runs as an external .EXE. The graphic objects created by FSX when instructed to do so by such programs WILL, of course, take memory away from FSX, both because of their allocated space in RAM, but also (IN DX9) because the portion of the VRAM they use is also copied into system RAM.

 

To continue the example of the two add-ons above:

 

- When UT2 is making its own calculation to decide which AI it must create, by reading its database of schedules and locations, THIS processing doesn't take any memory from FSX, because it's happening in the VAS of the UT2Services.exe program. But every AI that is being created, will take some memory from FSX, just like if the same AI was created by the regular traffic engine.

 

- When GSX is calculating a path to move a vehicle from its starting location to the airplane door or it's calculating all the tricky mathematics needed to figure out a pushback route, THIS processing doesn't take any memory from FSX, because it's happening in the VAS of the Couatl.exe program. But the actual created vehicles will take some memory away from FSX.

 

To reply to the original question if the 32 bit memory limit can be somewhat "fixed", it can be, but only marginally, by moving everything that CAN be moved ( = code logic, systems simulations, etc.) outside the FSX process, under an external .EXE

 

The main issue is, although this IS a saving, and it also has additional benefits such being scheduled on free cores thanks to the automatic code allocation made by the OS without requiring any specific multi-core programming, it's not really much.

 

Code logic is not usually very large, not compared to GRAPHICS and, unfortunately, it's graphic that sells products which means, there's a strong drive for developers to push graphics further and further, which means whatever memory savings could be obtained by moving all code logic on external .EXE (which is the only option we have, as long as FSX remains a 32 bit app), I'm afraid they will always overshadowed by how easily memory gets used up with graphic, which CAN'T really be moved outside FSX.

Thinking about the max VAS size of 4 GB with a 64 bit OS (Win 7) and the limits of a 32-bit application such as FSX, have any software gurus attempted to correct this issue short of suggesting FSX needs to be recoded entirely in native 64 bit format?

 

For FSX core, not really, HOWEVER, for 3rd party products yes ... you would have a 32bit DLL using IPC (interprocess communications) to a 64bit process, however they don't reside in the same process space so the must use out-of-process COM components ... a very good read here (dated but still relevant): http://blog.mattmags.com/2007/06/30/accessing-32-bit-dlls-from-64-bit-code/ -- and I do mean a VERY good read.  But you are still bound by the FSX 32bit process, so there would not be much gained unless your 3rd party product does A LOT of memory intensive processing and needs more than 4GB (seems unlikely).

 

Also, IPC is going to be slower.

 

P3D/LM are the only folks that currently have the ESP that is based on FSX SP2, so if there is going to be 64bit version, it will most likely come from them.  Converting source code from 32bit to 64bit can be as easy as changing CPU Target in a compile OR very complex where are no equivalent 64bit DLLs and/or significant call changes ... not to mention it'll break compatibility with many 3rd party products.

 

So even if you got what you wanted, it most likely would not work with any existing 3rd party products.

 

 

Rob.

 

 

I'm afraid they will always overshadowed by how easily memory gets used up with graphic, which CAN'T really be moved outside FSX.

Thank you Umberto. Great read.

Wait for some Russian / Ucranian software house to write a new FSX... Whow, those guys really know how to make a lot from few resources - see DCS ( yes now also 64 bit only, but started 32 bit ), RoF, IL2... 

 

I many times ask myself why can't they invest on a civillian simulation. It would certainly show as all what a flight simulator is.

 

Why? Well, first they're excellent programmers, and are used to work with very few resources / low budgets, so... they can do miracles that run even on lower end PCs making FSX or X-Plane feel ashamed ...

 

Maybe PMDG could start some partnership with one of those software houses, just like ED did, and the FSNext simulator could finally see daylight ...

 

This is REALLY me dreaming....

My frame rates usually become unbearable before FSX runs out of available VAS on my system - FSX transformed to 64 bit without any other corrections would not really help me ...