BTW, apparently I was wrong and it's after SP2 and not SP1 when FSX started shipping with the LAA flag. So Errol, just in case you don't have SP2 or Acceleration installed, you should do it or you'll be stuck with only 2GB of VAS for FSX

 

This to me is the last word on this subject. Mark Russinovich is probably the most knowledgeable person on the planet on how Windows works at the core. His sysinternals tools are legendary and he was hired by Microsoft 5 or 6 years ago as a kernel design specialist.

 

The short answer on getting out of memory errors in FSX is that the "memory" being referred to isn't your physical RAM, it's the virtual address space for the FSX.exe process, which is mathematically limited to no more than 4GB. (it's technically the number of possible values for a bit - 1 or 0, so 2, raised to the 32nd power, which is 4GB when you do the conversion math to get to GB) Your in-use video memory also counts against this 4GB limit, so if you're running really high resolutions and setting really high AA levels and stuff, that's increasing the memory load on the video card, which means there's less address space available for FSX itself to use. It's very easy to get FSX itself up above 2 or 2.5GB of memory usage if you're using a lot of high end scenery and a high end addon aircraft - add a bunch of video memory usage to that and you're running on the edge - if it tries to go even 1 bit past 4GB you're going to get a crash.

 

This addresses something I have been trying to figure out for some time.  Does the physical size (mb amount) of your card's VRAM effect the VRAM usage of VAS or just the graphic settings?   For example, say you were using 3.5 gb of VAS in a flight scenario with certain graphic settings on a 2 gb video card and the video card is using 1.5 gb of VRAM. If you then install a 4gb video card and make the same flight with the same graphic settings would you still only be using 3.5 gb of VAS and 1.5 gb of VRAM? Or would you use up more VAS with the larger VRAM card and possibly have an Out of Memory (OOM) error?

 

My gut tells me you would use the same VAS with the 4gb card as with the 2 gb card otherwise everyone buying the 6gb Titans would be crashing their sims as soon as they hit the "fly now" button.  I'd appreciate hearing any knowledge on this as I am about to buy a new video card and prefer not to make a $500 mistake.

 

Ted.

 

My gut tells me you would use the same VAS with the 4gb card as with the 2 gb card otherwise everyone buying the 6gb Titans would be crashing their sims as soon as they hit the "fly now" button.  I'd appreciate hearing any knowledge on this as I am about to buy a new video card and prefer not to make a $500 mistake.

You are correct.  FSX has limited memory address space, so the only way to avoid OOM is to make compromise.  You want to start with the aircraft and lower everything else to complete your flight.  You can use DX10 mode with the current fixes, but you will need to live with the shortcomings with airport(s) at night.  Find your happy mid-road and just leave it alone.  As the PMDG T777 release approaches I can start hearing OOM beep beep from FSUIPC at a distance.  LOL

 

My gut tells me you would use the same VAS with the 4gb card as with the 2 gb card otherwise everyone buying the 6gb Titans would be crashing their sims as soon as they hit the "fly now" button.

 

Ted, I think you're confusing VAS (the amount of space a process can address) with the amount of memory that's actually allocated and consumed, and all of that with video memory.  With 64 bit Vista, all of the rules changed, and then changed again when MS realized a problem was looming.

 

Assuming a modern video card with dedicated VRAM - in today's 64 bit operating systems, that VRAM is addressed in its own space and that address space is not shared with an application.  In DX9 and previous directX versions, for a variety of reasons the graphics memory being used was duplicated in a processes' address space as well (FSX's in this case).  But a couple of things to remember: that duplication was only of graphics memory actually used, not the full VRAM available on the card, so just the fact of having a 4 or 6 G card wouldn't shoot you down, but more importantly in DX10 and later, this graphics duplication no longer occurs and in DX9, following a change MS made early in Vista 64 and subsequent releases (basically anyone's 64 bit system running today), it has been scaled back.  Bottom line - in DX10 and later, a process no longer needs to mirror its graphics memory in its own address space, while in DX9 and earlier it may still mirror some.

 

We have plenty of empirical evidence showing that DX10 can reduce OOMs in high use situations reflecting the above, though my own tests in more modest circumstances surprisingly show FSX running in DX9 mode often using less of its available VAS than it does in DX10.  Your mileage will vary depending on what you're running and how hard you're pushing limits.

 

Hope this helps more than it confuses.  :blush:

 

Scott

It's all here

 

because even though...

 

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.

 

MS addressed this

 

 

To address this problem, Microsoft is changing the way that the video memory manager maintains the content of video memory resources. This change is being made so that a permanent virtual address range does not have to be used for each virtualized allocation. With the new approach, only allocations that are created as "lockable" consume space in the virtual address space of the application. Allocations that are not created as "lockable" do not consume space. This approach significantly reduces the virtual address space that is used. Therefore, the application can run on large video memory configurations without reaching the limits.

 

You definitely don't substract your entire amount of available VRAM to the 4GB VAS limit. Actually, it's not even all of your VRAM in use that is mirrored into VAS all of the time. There may be a correlation, but in my experience it's nothing to worry about.

 

Going by that last paragraph in the MS KB article, the closest to the VAS limit you get, the more data video data related stuff is evicted from FSX's VAS. It may make transitions between full screen & windowed mode slower perhaps, but I believe VRAM is the least of the factors when it comes to VAS depletion.

 

Would be cool if someone did some tests at low VAS usages, and see if VRAM usage effects VAS more than it does when it's close to those 4GB limit

 

UPDATE

 

After some googling I stumbled upon this http://www.gamedev.net/topic/564589-is-it-possible-to-create-vertex-buffers-in-dx9-that-are-not-lockable-kb940105/

 

So it looks like there's no creating unlocked video resources under DX9, and those are always taking up VAS no matter what. I have no idea how much of the total VRAM usage is vertex buffers or whatever other stuff the app has mirrored in VAS

for 64bit windows to use 4GB with 32bit application, application must be LARGEADDRESSAWARE. FSX SP2 and Acceleration are LARGEADDRESSAWARE by default. So, use 4GB patch only if you have 32bit windows or for some reason you dont have SP2 or Acceleration(very unlikely scenario). Otherwise, all you can do to prevent OOM's is to use microsoft fix that i posted somewhere above and to disable all sceneries and DLL's which are not required for current flight. That really works

Ted, I think you're confusing VAS (the amount of space a process can address) with the amount of memory that's actually allocated and consumed, and all of that with video memory.  With 64 bit Vista, all of the rules changed, and then changed again when MS realized a problem was looming.

 

Assuming a modern video card with dedicated VRAM - in today's 64 bit operating systems, that VRAM is addressed in its own space and that address space is not shared with an application.  In DX9 and previous directX versions, for a variety of reasons the graphics memory being used was duplicated in a processes' address space as well (FSX's in this case).  But a couple of things to remember: that duplication was only of graphics memory actually used, not the full VRAM available on the card, so just the fact of having a 4 or 6 G card wouldn't shoot you down, but more importantly in DX10 and later, this graphics duplication no longer occurs and in DX9, following a change MS made early in Vista 64 and subsequent releases (basically anyone's 64 bit system running today), it has been scaled back.  Bottom line - in DX10 and later, a process no longer needs to mirror its graphics memory in its own address space, while in DX9 and earlier it may still mirror some.

 

We have plenty of empirical evidence showing that DX10 can reduce OOMs in high use situations reflecting the above, though my own tests in more modest circumstances surprisingly show FSX running in DX9 mode often using less of its available VAS than it does in DX10.  Your mileage will vary depending on what you're running and how hard you're pushing limits.

 

Hope this helps more than it confuses.  :blush:

 

Scott

 

Thanks for responding to my question on this Scott. It wasn't clear to me whether it was just the VRAM being used that was duplicated or mirrored in the FSX 4gb VAS space or some larger amount. You clarified that it was just the VRAM being used so the physical size of the VRAM on the card should not make any difference in OOMs as long as you control how much is being used. I realize that using DX10 helps but I didn't want to be forced to use it all the time as some add-ons don't support it.

 

Ted

Found the link, Memory and Address Space Limits: http://msdn.microsoft.com/en-us/library/windows/desktop/aa366778(v=vs.85).aspx#memory_limits

 

And all about Memory Limits for Windows Releases: http://msdn.microsoft.com/en-us/library/windows/desktop/aa366778(v=vs.85).aspx