Jump to content
Sign in to follow this  
tom79

VideoMemoryOverride: Does it really work?

Recommended Posts

Hi all!

 

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:

 

http://forum.avsim.n...x/#entry2160874

http://forum.avsim.n...25#entry2100237

 

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.

 

Theoretical Background

(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).

 

Test Setup

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 v1.9.5.11
  • GPU settings as detailed here, using 8xS settings, frames locked to 30fps in the driver, no VSync

My fsx.cfg and the saved situation files are included as attachments (please rename to .zip):

 

 

Test Results

 

I ran tests using VideoMemoryOverride (VMO) settings for 0.25,0.5, 1 and 3 GB of video memory.

vas1.png

vas2.png

 

 

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.

 

vas3.png

 

Also, here is a representative screenshot from one of the DX10 tests:

 

 

 

Summary

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.

Share this post


Link to post
Share on other sites

Tom

The 'VAS depletion' issue by VRAM only applies in a 32-bit OS. As you know in a 32-bit OS running a 32-bit app you get 4GB VAS, but 2G is given to the system/kernel and 2GB minus the VRAM is for the 32-bit app like FSX. If the 32-bit app is Large Address Aware you can in a 32-bit app allocate up to 3Gb of VAS. In a 64-bit OS the 32-bit app can use all of the 4GB VAS (There is a very minor impact from the VRAM but it is negligible compared to a 32-bit OS scenario.

What you should see with VMMAP is that as FSX runs the contiguous block size gets smaller and defragmentation gets larger ie free space is reduced. Nice test.

Regards

PeterH

Share this post


Link to post
Share on other sites

My understanding is that while it's of course true that fsx is a 32 bit app, from the system view it is 64 bit with wow64 dlls providing the link between the 32 bit VAS and the OS. That's why fsx can fill the whole 4 Gb of the 32 bit VAS.

 

scott s.

.

Share this post


Link to post
Share on other sites

Hm, I know that OOM issues are more pressing on 32bit operating systems due to the limitation of 2GB VAS (or whatever you set with the userva switch), but they can also happen on 64bit Windows as well. I mean, 4GB VAS is not much if you try to max out FSX.

 

And the amount of VAS used to access video memory is not negligible, especially when using high res textures.

 

Earlier, most people were more likely to experience a g3d.dll CTD when trying to max out FSX (see here for example) on a 64bit OS, so OOMs were not so much an issue. But since Pete Dowson fixed that (million thanks btw!), OOMs are back and I've seen quite a few topics lately from people experiencing OOMs even on 64bit Windows.

 

<speculation>

My whole idea was that if the GPU has plenty of video memory, FSX would be less eager to remove unneeded textures and such from the GPU, which would in turn keep in-process VAS reserved for video memory access high and consequently bring total process VAS usage closer to the 4GB limit.

 

Or the other way around: If video memory available (or restricted through VideoMemoryOverride) would be too small to fit all objects that are supposed to be displayed on screen, FSX would simply not load certain textures. I was actually hoping for this to work, as I guess it's better to see some missing textures in some situations instead of getting an OOM.

</speculation>

 

But like I said above, if VideoMemoryOverride were actually working, it should have at least some measurable effects. Some people claim that it fixed OOM issues for them, but that might also be a conincidence.

Share this post


Link to post
Share on other sites

I keep seeing statements that if you're running a 64bit OS that the OS/Kernel is no longer addressed into the 32bit application's memory block. I'd like to see empirical information regarding these statements.


Ed Wilson

Mindstar Aviation
My Playland - I69

Share this post


Link to post
Share on other sites

Tom

The 'VAS depletion' issue by VRAM only applies in a 32-bit OS. As you know in a 32-bit OS running a 32-bit app you get 4GB VAS, but 2G is given to the system/kernel and 2GB minus the VRAM is for the 32-bit app like FSX. If the 32-bit app is Large Address Aware you can in a 32-bit app allocate up to 3Gb of VAS. In a 64-bit OS the 32-bit app can use all of the 4GB VAS (There is a very minor impact from the VRAM but it is negligible compared to a 32-bit OS scenario.

What you should see with VMMAP is that as FSX runs the contiguous block size gets smaller and defragmentation gets larger ie free space is reduced. Nice test.

Regards

PeterH

 

This isn't really correct - the core issue is DX9 itself, not 32-bit vs. 64-bit OSes.

 

Here's what the DirectX SDK says:

 

"If an application creates its own in-memory copy of its video resources, or the application uses DirectX 9 or an earlier version, the virtual address space contains the WDDM video memory manager's virtualized range and the application's copy. Applications that use graphics APIs that are earlier than DirectX 10 and that target GPUs that have large amounts of video memory can easily exhaust their virtual address space."

 

This has nothing to do with the OS, it's a limitation of the DX9 API itself. You'd have the same problem with any other game that had the ability to take up the crazy amounts of memory that FSX can be pushed to. (in fact it has happened - a few months ago a big first person RPG called "The Elder Scrolls V: Skyrim" shipped without the Large Address Aware flag on its exe and people were getting OOMs with it until the developers added it) Tom's conclusion regarding reduced VAS usage with DX10 is correct for exactly the reason outlined in the SDK: DX10 (and 11) work differently and don't have to shadow the video RAM into VAS like DX9 does. When DX9 was designed 10+ years ago, video cards had nowhere near the RAM amounts they do today - my first DX9 card was a 128MB Radeon 9800 Pro - no one intended for DX9 games to run on cards with 2+GB of RAM on them. My current card is a 1.28GB GTX 570 - 10 times the amount of RAM.

 

The way 64-bit OSes help with this is by giving you more total VAS for the app itself (4GB max for 32-bit apps) - they don't eliminate DX9's need to shadow the video memory. It helps only because there's more total space for the shadow copy to fit in. In a 32-bit OS you have 4GB *total* addressable VAS - so everything running on the system needs to fit within that 4GB - the OS's processes, FSX, any other apps running, background processes, etc. With a 64-bit OS, every 32-bit process can have its own separate 4GB VAS range to work with because the actual OS total limit is something like 16TB, not 4GB.

 

Tom's results are interesting. If the video memory is limited to 250MB in the cfg, yet inspector still shows 700+MB VRAM usage, I'm not entirely sure how that's possible then if the setting is working. One idea though is that maybe the VRAM usage stats include processing that's being done on the card that doesn't originate within the FSX engine - AA, AF, etc - all that type of stuff happens on the card and the sim isn't "aware" of it in any way because it's happening at the driver and the hardware level after the sim already sends its data to the card. With any supersample AA mode on, the card is rendering internally at a higher resolution than you're actually displaying - that takes up more RAM to do. I wonder what repeating the test with no forced driver AA or AF would show... that should control for the effects of those things that use RAM but aren't being commanded by the FSX engine.

 

The thing is, we do have evidence at PMDG for that setting and video memory in general being involved in certain customers' issues. After the NGX released we had several customers running really overkill systems - two 2GB GTX580s in SLI to a single monitor, 3GB Radeon cards etc. With one guy, I asked him to try removing one of the SLI 580s and that cured his OOM problems. I guess I can't say for certain that it was the video memory VAS issue, but I think that's pretty strong evidence. After ******* told me about the VideoMemoryOverride command I tried that with a different customer and it did seem to solve the problem. That setting is actually right there in the default FSX display.cfg file that's in the root FSX folder. This file sets up predefined compatibility settings for different video cards (most of them really old). For example you see stuff like this in there:

 

;----------------------------------------------------------------------
; Intel 810
; this is an 8m video card, and it lies about available VidMem b/C it
; is integrated to the Motherboard
;----------------------------------------------------------------------
[00008086:00007121]
VideoMemoryOverride=8388608
Disable=1

 

That leads me to believe it must have SOME function if ACES went to the trouble of creating a lengthy definition file like this that has numerous instances of that setting in it.

 

One thing I am still unclear on with this entire VAS business is whether or not DX9 requires that the entire video memory size be shadowed into VAS or if it's just the part that's actively in use. I've looked for information on this and wasn't successful in finding anything definitive on it. I'm going to do some more research and see if I can't get something definitive - I know someone who is a developer at DICE, the makers of the Battlefield games, and I'm going to ask him if he can run the question by one of their Direct3D programmers and see if we can't get an answer.

 

Nice job though compiling all that data Tom. I'm always impressed when someone tries to investigate something like this scientifically rather than relying on hearsay, supposition and the opinions of so-called experts (myself included) - good on you for that!

 

I keep seeing statements that if you're running a 64bit OS that the OS/Kernel is no longer addressed into the 32bit application's memory block. I'd like to see empirical information regarding these statements.

 

You know, I'm not sure where this comes from either honestly, it's just always something I've heard - but I feel like it's on better footing experimentally - we have countless cases at support here where someone was getting OOMs on XP or 32-bit Win7 etc - we tell them to upgrade to 64-bit and that basically always fixes the issue. I believe it's been an issue with other games as well ala the Skyrim thing I mentioned above too.

 

Perhaps this could be another experiment to run - at what point in VAS usage will you get the OOM with 32-bit Win7 and can you reliably go higher with 64-bit?


Ryan Maziarz
devteam.jpg

For fastest support, please submit a ticket at http://support.precisionmanuals.com

Share this post


Link to post
Share on other sites

Ryan

We may have to agree to disagree.

Regards

PeterH

 

So, are you saying Microsoft's wrong in stating this?

 

Here's what the DirectX SDK says:

 

"If an application creates its own in-memory copy of its video resources, or the application uses DirectX 9 or an earlier version, the virtual address space contains the WDDM video memory manager's virtualized range and the application's copy. Applications that use graphics APIs that are earlier than DirectX 10 and that target GPUs that have large amounts of video memory can easily exhaust their virtual address space."


Ed Wilson

Mindstar Aviation
My Playland - I69

Share this post


Link to post
Share on other sites

Ryan

We may have to agree to disagree.

Regards

PeterH

 

In what respect is what I said wrong? You provided no evidence for what you're claiming...


Ryan Maziarz
devteam.jpg

For fastest support, please submit a ticket at http://support.precisionmanuals.com

Share this post


Link to post
Share on other sites

Ed

No I am not saying that, just that we have to be careful to distinguish between a 32 bit OS and 64 -bit OS where the effects of VRAM etc) are quite different . For example in a 3e2-bit OS setting the /3G switch doews not affect DirectX WDDM or anything it just allocates more space to the app toi run but the penalty is that the VRAM still "hogs" its part in the VAS where it doesn't in a 64-bit OS where the whole 4GB is available. Of cours the SDK is correct re the WDDM memory manager loading into the VAS, it has to in order for you to see the end result on the monitor, but that is independent of the VRAM and that's what I am talking about. Many many processes load into the VAS that's how it works, but the don't all have the propensity to cause OOMs.

If you look in device manager in either a 32-bit or 64-bit OS you will see different memory block (size) allocations given over to the video card, all I am saying that in a 64-bit OS the effects of VRAM are negligible compared to a 32-bit OS, and WDDM 1.1 fixed a lot of video related issues.

If what you say is true you need to explain how video card with 4+GB of VRAM will run a 32-bit app in a 64-bit OS without issue.

You usually see touble occurring in FSX as you start adding in complex additions. DirectX or WDDM don't cahnge they are the constant.

Run a plain vanilla FSX install in a 64-bit OS and I guarantee that you will never see an OOM, and VMMap confirms that much less VAS resources are used in a plain FSX installation (running).

 

This is what Phil Taylor said:

wrt FSX OOM errors http://blogs.msdn.com/b/ptaylor/archive/2007/06/15/fsx-and-win32-process-address-space.aspx

 

So how is this helping with the “Out of Memory” error? 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.

 

I also stand by what Mark Russinovich states in his various publications on the process address space.

VMMap shows me that in running FSX that the contiguous block size gets smaller and defragmentation becomes larger. Tha's the root cause of OOM's in FSX and how you solve them is beyond me.

This is a Vista article which does apply to a 32-bit OS: http://support.microsoft.com/kb/940105

A modern graphics processing unit (GPU) can have 512 MB or more of video memory. Applications that try to take advantage of such large amounts of video memory can use a large proportion of their virtual address space for an in-memory copy of their video resources. On 32-bit systems, such applications may consume all the available virtual address space.

 

 

This is one of the few posts that Microsoft mentions this topic wrt to the VAS.

 

I am not going to contribute further, as you are entitled to your own opinions, and I respect those. As I say we have to agree to disagree.

Regards

pH

Share this post


Link to post
Share on other sites

One thing I am still unclear on with this entire VAS business is whether or not DX9 requires that the entire video memory size be shadowed into VAS or if it's just the part that's actively in use.

 

If I'm reading materials presented below correctly, this is described in Microsoft resources:

"Existing games and other graphics applications frequently allocate virtual memory for a copy of the video memory resources that the application uses."

 

"The virtual memory that the copy uses is directly proportional to the video memory resources that the application allocates."

 

"A modern graphics processing unit (GPU) can have 512 MB or more of video memory. Applications that try to take advantage of such large amounts of video memory can use a large proportion of their virtual address space for an in-memory copy of their video resources."

 

source:

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

http://www.microsoft...ay/WDDM_VA.mspx

 

It is clearly written that VAS is allocated according video memory resources used by the application. There isn't any material where Microsoft points that application must to duplicate whole linear address space of graphics card's video memory in application's virtual address space. The way of managing video resources under DirectX9 is described here: http://msdn.microsof...2(v=vs.85).aspx

and all discussed methods are using proportional amount of memory and VAS to size of created resources.

 

 

It is possible to check that in practice - if Sysinternals Process Explores is showing allocated VAS size correctly - test confirms my words. Only you need is FSX running with simple scenery and low settings, graphics card with 1GB or more video memory and Sysinternals Process Explorer to check size of FSX's allocated space (Virtual Size).

 

In my case, FSX run on GTS450 with 1GB video memory is reporting total used virtual address space below 0,9GB. According to theory about shadowing entire video memory into VAS, total used virtual adress space should be significantly bigger than 1GB as a sum of memory allocated for FSX program, data and 'duplicated' 1GB of video memory.

 

PS.

Under Vista or Win7, size of VAS allocated for storing video resources, may be smaller or even bigger than graphics card's video memory due to duplication by WDDM video memory manager virtualized range in addition to the application’s copy of used resources while working under DirectX 9. In such case data is stored in application's VAS twice.

Share this post


Link to post
Share on other sites

Tom's results are interesting. If the video memory is limited to 250MB in the cfg, yet inspector still shows 700+MB VRAM usage, I'm not entirely sure how that's possible then if the setting is working. One idea though is that maybe the VRAM usage stats include processing that's being done on the card that doesn't originate within the FSX engine - AA, AF, etc - all that type of stuff happens on the card and the sim isn't "aware" of it in any way because it's happening at the driver and the hardware level after the sim already sends its data to the card. With any supersample AA mode on, the card is rendering internally at a higher resolution than you're actually displaying - that takes up more RAM to do. I wonder what repeating the test with no forced driver AA or AF would show... that should control for the effects of those things that use RAM but aren't being commanded by the FSX engine.

 

Right, I was suspecting something like that too but couldn't find any information on the web about how much memory the GPU hogs in addition to what the application can control. I'm gonna try to re-run some of the tests with default driver settings and AA/AF turned off in FSX's display settings.

 

The thing is, we do have evidence at PMDG for that setting and video memory in general being involved in certain customers' issues. After the NGX released we had several customers running really overkill systems - two 2GB GTX580s in SLI to a single monitor, 3GB Radeon cards etc. With one guy, I asked him to try removing one of the SLI 580s and that cured his OOM problems. I guess I can't say for certain that it was the video memory VAS issue, but I think that's pretty strong evidence. After ******* told me about the VideoMemoryOverride command I tried that with a different customer and it did seem to solve the problem. That setting is actually right there in the default FSX display.cfg file that's in the root FSX folder. This file sets up predefined compatibility settings for different video cards (most of them really old). For example you see stuff like this in there:

 

;----------------------------------------------------------------------
; Intel 810
; this is an 8m video card, and it lies about available VidMem b/C it
; is integrated to the Motherboard
;----------------------------------------------------------------------
[00008086:00007121]
VideoMemoryOverride=8388608
Disable=1

 

That's interesting indeed. I never looked into display.cfg. Maybe the VideoMemoryOverride switch works, but it's not supposed to be placed in fsx.cfg. I'll try if I can add something for my card in display.cfg. I suppose the numbers in the top section are PCI IDs.

 

I don't know if the DirectX API has methods to tell the actual physical VRAM installed on a GPU. If not, I guess FSX actually queries the device drivers, which raises a new question: Is this possible under Win7/Vista without elevated privileges?

 

At least I can remember Austin Meyer talking about a similar problem with OpenGL: There's no (unified?) way to query how much physical memory is installed on a GPU because the driver can add shared memory at any time. That's why the display settings dialog in X-Plane shows an info at the bottom about how much VRAM XP uses in the current situation to give users a hint that they might get a performance hit if the value exceeds the GPU's dedicated memory.

 

One thing I am still unclear on with this entire VAS business is whether or not DX9 requires that the entire video memory size be shadowed into VAS or if it's just the part that's actively in use. I've looked for information on this and wasn't successful in finding anything definitive on it.

 

I don't know that either. I can imagine the following scenarios how this could work:

 

a ) FSX allocates the entire amount of dedicated VRAM in its address space through DirectX (that would show up as reserved memory I guess).

b ) FSX does not allocate the entire amount of VRAM through DirectX, but reserves the address space. (I don't do much win32 programming, but I think this would use the VitualAllocfunction)

c ) FSX does not reserve anything through the memory manager, but internally. Say FSX has determined that 800MB if VRAM shall be used, it could split its address space to allocate memory for the GPU using only the top 800MB and the lower 3.2GB for its private data and such.

d ) FSX only uses address space for GPU access on demand.

 

Here's a screen of how VMMap looks when I start FSX looking at the free flight menu only. I believe the plane preview window uses DirectX already, so if the entire GPU's memory is reserved, it should be at this point already:

 

Total address space used in this scenario is 593.853K. Minus 480.284K of committed space leaves 113.569K of reserved address space. With a 1GB GPU that's not enough. So scenarios a ) and b ) can be ruled out.

 

To see if scenario c ) is the case one would actually have to dig deeper into the distribution of memory. This is what the address space looks like after starting FSX:

 

 

I'm not sure what to make out of this picture. There are some huge gaps in the address space, but don't know what that big yellow chunk of private data in the middle of the address space is used for. However when I start the flight, it looks like this:

 

 

 

FSX should use way more video memory than what that chunk in the middle of the address space uses (it's around 15MB) so I guess scenario c ) doesn't apply as well.

 

And that leaves scenario d ) as the only plausible explanation left.

 

Nice job though compiling all that data Tom. I'm always impressed when someone tries to investigate something like this scientifically rather than relying on hearsay, supposition and the opinions of so-called experts (myself included) - good on you for that!

 

Thanks for the compliment!

 

You know, I'm not sure where this comes from either honestly, it's just always something I've heard - but I feel like it's on better footing experimentally - we have countless cases at support here where someone was getting OOMs on XP or 32-bit Win7 etc - we tell them to upgrade to 64-bit and that basically always fixes the issue. I believe it's been an issue with other games as well ala the Skyrim thing I mentioned above too.

 

Perhaps this could be another experiment to run - at what point in VAS usage will you get the OOM with 32-bit Win7 and can you reliably go higher with 64-bit?

 

Yeah, that would be interesting. As I understood, the GPU's VRAM is directly mapped into the upper 2GB address space when running a 32bit OS (as explained by Phil Taylor here). It would be interesting to see what happens if FSX requests video memory through DirectX:

Does the API return a pointer in the upper 2GB area or is it still restricted to the lower 2GB (which would essentially waste precious address space)? I have a feeling that the HIGHMEMFIX=1 config switch has something to do with that.

 

Maybe someone with a 32bit OS could try that.

 

I will perform a few more tests as mentioned above, but I'm still *really* interested if people with 3GB GPUs can see any measurable effects of VideoMemoryOverride on their systems, because I'm not sure how much FSX can be outsmarted when running it with a 1GB GPU.

 

Will report back!

 

PS:

These two presenations are the most detailed and comprehensive pieces about Windows memory management I have ever seen. Everyone interested should have a look at them (it's really worth it):

 

http://channel9.msdn...ica/2011/WCL405

http://channel9.msdn...ica/2011/WCL406

 

Ed

No I am not saying that, just that we have to be careful to distinguish between a 32 bit OS and 64 -bit OS where the effects of VRAM etc) are quite different . For example in a 3e2-bit OS setting the /3G switch doews not affect DirectX WDDM or anything it just allocates more space to the app toi run but the penalty is that the VRAM still "hogs" its part in the VAS where it doesn't in a 64-bit OS where the whole 4GB is available. Of cours the SDK is correct re the WDDM memory manager loading into the VAS, it has to in order for you to see the end result on the monitor, but that is independent of the VRAM and that's what I am talking about. Many many processes load into the VAS that's how it works, but the don't all have the propensity to cause OOMs.

If you look in device manager in either a 32-bit or 64-bit OS you will see different memory block (size) allocations given over to the video card, all I am saying that in a 64-bit OS the effects of VRAM are negligible compared to a 32-bit OS, and WDDM 1.1 fixed a lot of video related issues.

If what you say is true you need to explain how video card with 4+GB of VRAM will run a 32-bit app in a 64-bit OS without issue.

You usually see touble occurring in FSX as you start adding in complex additions. DirectX or WDDM don't cahnge they are the constant.

Run a plain vanilla FSX install in a 64-bit OS and I guarantee that you will never see an OOM, and VMMap confirms that much less VAS resources are used in a plain FSX installation (running).

 

This is what Phil Taylor said:

wrt FSX OOM errors http://blogs.msdn.co...ress-space.aspx

 

 

 

I also stand by what Mark Russinovich states in his various publications on the process address space.

VMMap shows me that in running FSX that the contiguous block size gets smaller and defragmentation becomes larger. Tha's the root cause of OOM's in FSX and how you solve them is beyond me.

This is a Vista article which does apply to a 32-bit OS: http://support.microsoft.com/kb/940105

A modern graphics processing unit (GPU) can have 512 MB or more of video memory. Applications that try to take advantage of such large amounts of video memory can use a large proportion of their virtual address space for an in-memory copy of their video resources. On 32-bit systems, such applications may consume all the available virtual address space.

 

 

This is one of the few posts that Microsoft mentions this topic wrt to the VAS.

 

I am not going to contribute further, as you are entitled to your own opinions, and I respect those. As I say we have to agree to disagree.

Regards

pH

If I'm reading materials presented below correctly, this is described in Microsoft resources:

"Existing games and other graphics applications frequently allocate virtual memory for a copy of the video memory resources that the application uses."

 

"The virtual memory that the copy uses is directly proportional to the video memory resources that the application allocates."

 

"A modern graphics processing unit (GPU) can have 512 MB or more of video memory. Applications that try to take advantage of such large amounts of video memory can use a large proportion of their virtual address space for an in-memory copy of their video resources."

 

source:

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

http://www.microsoft...ay/WDDM_VA.mspx

 

It is clearly written that VAS is allocated according video memory resources used by the application. There isn't any material where Microsoft points that application must to duplicate whole linear address space of graphics card's video memory in application's virtual address space. The way of managing video resources under DirectX9 is described here: http://msdn.microsof...2(v=vs.85).aspx

and all discussed methods are using proportional amount of memory and VAS to size of created resources.

 

 

It is possible to check that in practice - if Sysinternals Process Explores is showing allocated VAS size correctly - test confirms my words. Only you need is FSX running with simple scenery and low settings, graphics card with 1GB or more video memory and Sysinternals Process Explorer to check size of FSX's allocated space (Virtual Size).

 

In my case, FSX run on GTS450 with 1GB video memory is reporting total used virtual address space below 0,9GB. According to theory about shadowing entire video memory into VAS, total used virtual adress space should be significantly bigger than 1GB as a sum of memory allocated for FSX program, data and 'duplicated' 1GB of video memory.

 

PS.

Under Vista or Win7, size of VAS allocated for storing video resources, may be smaller or even bigger than graphics card's video memory due to duplication by WDDM video memory manager virtualized range in addition to the application’s copy of used resources while working under DirectX 9. In such case data is stored in application's VAS twice.

 

...but the point is: If FSX wants to load a texture into the GPU (using DX9), it has to shadow that memory into its own address space. And that adress space cannot be freed after the texture has been sent to the GPU. At least that's how I understood it.

 

So the more graphics intensive your FSX gets, the more of that 4GB in-process VAS has to be used for GPU access. Which raises the question: If you tell FSX that video memory is sparse, can you force the application to be more eager to remove textures and other objects (vertices etc) once they are no longer needed ?

Share this post


Link to post
Share on other sites

Can someone translate to plain English for me?!? :LMAO:

Share this post


Link to post
Share on other sites

So the more graphics intensive your FSX gets, the more of that 4GB in-process VAS has to be used for GPU access.

 

Yes, that is true and easy to check observing how VAS allocation grows while flying from default FSX low urbanized area to dense custom airport scenery with large amount of 3D objects and textures located in highly urbanized area.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Tom Allensworth,
    Founder of AVSIM Online


  • Flight Simulation's Premier Resource!

    AVSIM is a free service to the flight simulation community. AVSIM is staffed completely by volunteers and all funds donated to AVSIM go directly back to supporting the community. Your donation here helps to pay our bandwidth costs, emergency funding, and other general costs that crop up from time to time. Thank you for your support!

    Click here for more information and to see all donations year to date.
×
×
  • Create New...