I've never had any problems with OOMs in FSX since I switched to a 64bit OS. But recently there was a discussion in another forum about FSX RAM usage and how GPUs with large amounts of video memory might cause OOMs. The discussion was inspired by these two threads here on Avsim:
There were some questions whether GPUs with high amounts of VRAM installed could actually deprive FSX of virtual address space and cause an OOM. So I ran a few tests trying to prove it.
I only have a GPU with 1GB VRAM, but since the GPU drivers can throw in some shared system memory if the installed VRAM is not enough (dxdiag reports around 4GB video memory on my system), I was hoping to show that if I tell FSX that there's plenty of video memory available using the VideoMemoryOverride switch in fsx.cfg I could actually cause OOMs.
Well, the result in short is that I couldn't find that VideoMemoryOverride does anything at all. Neither increasing nor decreasing the values seemed to have any effect on VAS usage or VRAM usage as reported by Nvidia Inspector. I was only able to show that use of the DX10 preview mode can actually reduce VAS usage significantly. However I would be interested if that's just my system or if other people can't make this tweak work as well.
So I will write up the test details here, hoping that someone will be able to reproduce my findings.
(I do not know much about DirectX, so this stuff is just what I read somewhere else. Please correct me if I'm wrong.)
FSX is a 32bit application that --when run on a 64bit OS-- can address at most 4GB of virtual memory (->Virtual Address Space, VAS). DirectX9 applications must use their in-process VAS to address the GPU's video memory. Hence the more video memory FSX uses, the less address space is left for the actual application.
There is an undocumented tweak found by ******* 'Bojote' Altuve called VideoMemoryOverride that is supposed to limit the maximum amount of video memory used by FSX. It should go in the section of fsx.cfg that contains the actual graphics card being used by the app:
[DISPLAY.Device.NVIDIA GeForce GTX 460 SE.0] //VideoMemoryOverride=268435456 //0.25 GB //VideoMemoryOverride=536870912 //0.5 GB //VideoMemoryOverride=1073741824 //1.0 GB //VideoMemoryOverride=1610612736 //1.5 GB //VideoMemoryOverride=2147483648 //2.0 GB //VideoMemoryOverride=2684354560 //2.5 GB //VideoMemoryOverride=3221225472 //3.0 GB //VideoMemoryOverride=3758096384 //3.5 GB //VideoMemoryOverride=4294967296 //4.0 GB Mode=1680x1050x16 Anisotropic=1 AntiAlias=1 [DISPLAY.Device.NVIDIA GeForce GTX 460 SE.0.0] Mode=1680x1050x32 Anisotropic=1 AntiAlias=1 //VideoMemoryOverride=268435456 //0.25 GB //VideoMemoryOverride=536870912 //0.5 GB //VideoMemoryOverride=1073741824 //1.0 GB //VideoMemoryOverride=1610612736 //1.5 GB //VideoMemoryOverride=2147483648 //2.0 GB //VideoMemoryOverride=2684354560 //2.5 GB //VideoMemoryOverride=3221225472 //3.0 GB //VideoMemoryOverride=3758096384 //3.5 GB //VideoMemoryOverride=4294967296 //4.0 GB
I don't know why I have two entries in my config (with suffix .0 and .0.0). I guess the second one is for a specific display (I only have one monitor connected to my GPU).
Since I do not have problems with OOMs the way I use FSX, I tried to conceive a scenario that would bring FSX down to its knees. I chose the PMDG 737 NGX and OrbX's PNW demo area for the tests, since these two are the most complex aircraft/scenery addons I have on my system.
For these tests I programmed a Flight KSEA->KHQM->KSEA and recorded VAS usage on the return leg at 25nm distance to KSEA. I chose this scenario because the flight goes both over FSX default terrain as well as OrbX's addon scenery. Also, there is a lot of AI traffic at KSEA.
I disabled all addons in dll.xml and exe.xml that could possibly interact with FSX during the tests and thus mess with the results (except the PMDG/OrbX libraries of course). FSUIPC unreg was also disabled. I actually wanted to record VAS usage even closer to KSEA (7nm) because it showed in some preliminary tests that VAS usage was highest there. However I got g3d.dll errors on the return leg pretty consistently shortly after passing the 25nm distance mark (at approx 24.5 nm), so I had to choose the 25nm mark as the point to record the test data.
The programmed flight was low and slow to put max stress on the scenery engine (155kts, 1400ft altitude). I also opened a second window in fly-by view to keep the scenery engine busy. Additionally, I used the thunderstorms weather theme and enabled the NGX's head up display and ND terrain mode, hoping that it would further increase memory usage.
The tests were all performed using a saved situation to ensure that the tests are repeatable. After loading the situation, I only pressed the NGX's TOGA clickspot, took off and enabled the autopilot at 400ft AGL (I left the gear extended). No messing around with view points or anything durring the flight.
I recorded VAS usage using VMMap and GPU VRAM usage with NVidia Inspector.
After each test, FSX was restarted.
Once the test situation was loaded, I reset the stats in NVidia Inspector and selected the fsx.exe process to monitor in VMMAp.
At the 25nm mark on the return leg, I pressed F5 in VMMap to display the current memory usage and took a screenshot to record the results.
Additional test and system details:
- Windows 7 Pro 64bit
- FSX Acceleration
- NGX Sp1c
- Orbx PNW demo area (the current one with KHQM)
- Latest Orbx libs at that time (120328)
- FTX night mode on
- REX2 with HD textures installed (DXT5)
- Bojote's shader 3.0 mod
- JustFlight's TrafficX with recompiled traffic bgl
- All kinds of freeware replacement textures by Aime Leclerq installed (including TreeX)
- FSX ran in windowed mode for the tests, window maximized at 1680x1050 resolution (minus what the Windows task bar and window frame steal from that)
- Screensaver disabled
- NVidia driver v295.73, NVidia inspector v184.108.40.206
- GPU settings as detailed here, using 8xS settings, frames locked to 30fps in the driver, no VSync
I ran tests using VideoMemoryOverride (VMO) settings for 0.25,0.5, 1 and 3 GB of video memory.
This is a screenshot of a typical test situation:
During these tests, VAS usage was pretty high (300-500 MB free VAS left). Occasionally, VAS usage went further up (100-200MB free VAS) but dropped shortly thereafter. However, sometimes during these VAS usage peaks an OOM would occur.
In those cases where I didn't get a g3d.dll error at 25nm before KSEA, I let the test run to see what happens when getting closer to KSEA with all its AI traffic. At approx 10nm distance, VAS usage went up (100-200MB free VAS left), but unlike above, it stayed at this level. I did not include these test results as there were too few of them.
Furthermore, I ran a series of tests using FSX's DX10 preview mode. As expected, the VAS usage was significantly lower during these tests. But the VideoMemoryOverride switch didn't work there either, which I didn't expect since video memory is adressed differently anyway. The actual VRAM usage was a little higher in DX10, but it was the same for all values of VideoMemoryOverride.
Also, here is a representative screenshot from one of the DX10 tests:
As you can see, there is little variation in the numbers apart from the differences between DX9 and DX10 which leads me to the conclusion that the VideoMemoryOverride config switch does not work.
However, I do not want to write off this switch so early. There's still a possibility that the switch can work in other situations. So I would be interested if someone else (especially those people with a 3GB GPU) can try these tests on his or her system and post their findings.