I can't explain why you'd be seeing the error at only 2.7GB virtual size. That doesn't make any sense at all to me. I didn't make up the analysis that's in the manual - a large part of it was paraphrasing Mark Russinovich from Microsoft, who literally is one of the designers of this system on the Windows kernel team. If we can't trust his explanation of how VAS works, then there is absolutely no one that we can trust. In every case of this that I've dealt with with customers, the number was getting very close to or over 4GB.

 

OOMs can also occur when the VAS gets largely fragmented (link). So if FSX needs to allocate 1MB of memory and there is no contiguous block of free address space with at least 1MB size, on OOM would also occur.

 

VMMap can display the structure of the free address space. However, since the OP stated that he is getting OOMs at around 2.7G VAS usage, I doubt that the memory is that much fragmented at this point.

VMMap can display the structure of the free address space. However, since the OP stated that he is getting OOMs at around 2.7G VAS usage, I doubt that the memory is that much fragmented at this point.

Thank you, Tom. Phil makes it clear that there are two proximate causes of an OOM condition:

 

In the "Out of Memory" case, 2 things can be happening to cause this issue:

1)the app is running out of contiguous blocks in the 2G process address space

2)the app is running out of virtual address space period

It is reason #1 which is listed first, because this is the most frequent cause. Once folks understand the difference between addresses and the physical memory in which the data bytes are stored, this concept suddenly becomes more clear.

 

As an analogy, suppose we have one block on a street with ten brownstone houses (buildings built side-by-side). No matter how much you might wish otherwise, unless you are Harry Potter (or one of the other Wizards), it is physically impossible to put a new, additional building in that block. Why?

 

Because there is no empty "address" in which to place one. It really is that simple!

 

If the system has 1MB of data to map to physical memory at any given point and there's only 0.99 MB of contigous virtual address space remaining, it will simply go "BOOM" and stop with an OOM Error message.

 

Additionally, unless something has changed since I last looked, all PCIe video cards have their entire physical memory mapped to the system's side of the available VAS table. Linked here is an interesting article that explains "Understanding Address Spaces and the 4GB Limit"

 

http://hardforum.com/showthread.php?t=1035670

Additionally, unless something has changed since I last looked, all PCIe video cards have their entire physical memory mapped to the system's side of the available VAS table. Linked here is an interesting article that explains "Understanding Address Spaces and the 4GB Limit"

 

http://hardforum.com/showthread.php?t=1035670

 

As far as I understand, that is only relevant to 32bit operating systems.

 

Under Win7 64bit, only the parts of the video memory that are actually used by FSX for GPU resources such as textures are mapped into the address space and that only applies to DX9.

If the system has 1MB of data to map to physical memory at any given point and there's only 0.99 MB of contigous virtual address space remaining, it will simply go "BOOM" and stop with an OOM Error message.

 

 

 

Under Win7 64bit, only the parts of the video memory that are actually used byFSX for GPU resources such as textures are mapped into the address space and that only applies to DX9.

 

...and that's why we don't see DX10 with this issue....

 

(of course, never say 'never')  :lol:

 

 

 

If the system has 1MB of data to map to physical memory at any given point and there's only 0.99 MB of contigous virtual address space remaining, it will simply go "BOOM" and stop with an OOM Error message.

 

...and that's why DX10 doesn't have this issue....

 

(of course, never say 'never')  :lol:

 

Um, there's a distinct difference between the program's code and the video output of that program's code. The limitation of 1 MB contiguous VAS still applies to the core program, whether this 32bit program is executed on a 32bit or 64bit machine. This limit is dictated by FS's program code.

I've made a whole bunch of tweaks to the Windows settings I wasn't aware of in the past, I have the T7 standing at the gate at KIAD for almost 5 hours now without an issue yet. I will take it for a KIAD-OMDB flight later tonight. Max VAS usage so far was at 3.4gigs, is that normal at a high quality airport like KIAD?

 

Also, could anyone confirm if UT2's AI density sliders are overriding the FSX AI slider?

This is an automatic message.

 

This topic has been moved from "MS FSX Forum" to "Crash To Desktop (CTD) Forum". This move has been done for a number of possible reasons.

• The most likely reason is that the post was off topic.
• The topic could also have contained images or a video that were not appropriate to the original forum it was posted in.
• The images might not have been "illustrative" or "explanatory" in nature.
• The topic could have been moved because we deemed it to be more appropriately placed elsewhere.

Please ensure that your posts are "on topic" and contain illustrative images or videos as appropriate. Do not post videos or images just for entertainment purposes anywhere but in the screen shot or video forums. See our image posting rules here.

 

Members who continue to post off topic posts can be denied entry to specific forums in order to reduce and remove the practice. Your cooperation is appreciated.

I've made a whole bunch of tweaks to the Windows settings I wasn't aware of in the past, I have the T7 standing at the gate at KIAD for almost 5 hours now without an issue yet. I will take it for a KIAD-OMDB flight later tonight. Max VAS usage so far was at 3.4gigs, is that normal at a high quality airport like KIAD?

 

Also, could anyone confirm if UT2's AI density sliders are overriding the FSX AI slider?

 

Same here I don't go above 3.2......Is that good?

I just installed scenery editor and groups all my scenery but continent. I did 2 test flights back to back last night with the pmdg 777. First flight was from miami to orlando. I had Drezwecki miami city and ftx global activated. With opus and my traffic x set at 35 %, my vas was 2.7 when I landed.

 

Second flight was from KJac from orbx to salt lake city and VAS was 2.9 when I landed so deactivating the scenery thats not been used makes a big difference

 

Autogen is set to normal and scene complexity set at dense. That is a good balance on my system

...and that's why we don't see DX10 with this issue....

 

(of course, never say 'never') 

 

 

I wonder if P3D will do something in this arena, i.e. DX10 or DX11 and therefore make more memory address available.

 

Can I ask you how to get rid of the jaggies when in DX10 mode?  I use some very advanced AA modes in Inspector and when I try DX10 mode I get horrible jaggies!

To Fr. Bill: I'm kinda referring to the different way that resource allocation is managed in DX10, that's all.

 

To Noel: As far as I know, LM are building P3d v2.0, such that it will be DX11-compliant.

To the jaggies, Noel - you need to become a reader of the DX10 forum, so that you can assimilate the experiences and advice that the users there are having. Neither the Inspector "AA-Mode", nor the "AA - Setting" work in DX10: this is set within the fsx.cfg. Other settings in the Nvidia/AMD control panels (such as Super Sampling / Transparency AA) work normally. AA must be ticked, and Anisotropic selected in the FSX Settings. You can then use the info contained here to set some reasonable parameters that will meet that goal. It will give you 8x CSAA. I would recommend you save your current (DX9) Inspector .nip and fsx.cfg settings as a backup first, then delete the cfg, allowing fsx to create a new one, and then follow the pinned guide at the top of the forum. Using the Titan - the one setting that you can set with impunity, is BP=0!

 

Hope this helps!

 

All the Best,

 

pj

 

 

To the jaggies, Noel - you need to become a reader of the DX10 forum

 

Thanks for taking the time to write that--if I recall I think you directed me there previously however since I have yet to have an OOM I'm probably going to hold off--i.e., I hate to rock this boat as it's really running great!  I really like the CSAA settings I'm using.  That doesn't sound possible w/ DX10 do you know?

Here is what I have with the 777....Is that bad? I do get OOM on approach.

 

Capture.JPG

Can you help me interpret what I'm seeing here?  What do I need to look at to see how close I am getting to total committed or active VAS?  It looks like maybe I need to be viewing Process Explorer rather than sysinternals VMmap so that I can see all processes running?

You dont need to monitor other processes.

 

Highlight the "Free" row in VMMap and sort by block size descending in the bottom part of the screen like so:

 

http://imageshack.us/a/img580/941/fsxmemvmo1gdefdrv125m.png

 

First key indicator is the total amount of free VAS, that is the number showing in the "Free" row. Your second indicator is the largest contigous block size of free VAS which shows in the bottom part of the screen. That should show at least 1 meg.

 

Note that VMap doesnt update auotmatically like ProcessExplorer does. So you need tohit F5 from time to time. IIRC you can set it to update automatically, but that degrades performance and ultimately let to VMMap crashing on my system after a while.

 

 

First key indicator is the total amount of free VAS, that is the number showing in the "Free" row.

 

Thank you Tom.  So what am I looking for?  As I understand it in the 32-bit Windows environment each process gets 2Gb of VAS allocated to it.  I see from my brief look that I had ~1.5Gb of free VAS.   Are folks experiencing OOMs seeing this number get down to zero?