Sign in to follow this  
777simmer

GPU memory size and influence on VAS

Recommended Posts

Hi guys,

 

I have been doing some long haul flights to test my VAS usage.

Used Process explorer to monitor VAS during several flights.

 

During those flight my VAS steadily goes up by about 100Mb per hour.

(even if I do a holding at the same spot over default FSX scenery, VAS goes up from 2.5G. to 3.5Gb in 10hrs)

 

I dont like what I am seeing (VAS creeping up) yet I believe this behavior is normal.

(Word Not Allowed posted it is normal for VAS to keep rising as well)

Just how much VAS increases during a flight depends on how many and what addons you are using.

 

Recently someone commented to me that the size of GPU memory has an influence on VAS as it is "shadowed?" in VAS.

 

Is this true?

A 3Gb GPU has a higher VAS footprint than a 1Gb GPU regardless of what scenery you are flying over?

 

(I allways thought more GPU memory only increases its footprint on RAM, but not on VAS)

 

Thx.

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

Here's a post from Ryan a while back on the dangers of using video cards with large amount of onboard RAM. From what I have read the reason DX10 has eliminated OOMs for some, especially those who have 3gb or larger cards is that DX10 addresses the video memory differently than DX9 does. 

 

When I built my latest system I got a card with only 2gb of RAM knowing that I would most likely stick to using DX9. I've flown the T7 and NGX all over the world, sometimes leaving FSX running for 2 or three days in a row while in flight and never had an OOM. That's flying into addon sceneries like Dubai, LAX, JFK, etc., also with some photo scenery enabled in the scenery.cfg.

 

Ryan's quote comes from this thread, post 48-> http://forum.avsim.net/topic/349324-service-pack-better-be-good/page-2

 

 

 

Bert, How do the CTDs you're seeing happen? If they're completely random and happen out of nowhere they're almost surely the result of resource starvation in FSX (contiguous virtual address space) and not something we can really "fix". What are your system specs and what scenery addons are you running at the time when this happens? The basic background is that FSX is a 32-bit application and there's absolutely no way around the hard 4GB VAS limit. If it tries to allocate more than that or if it tries to allocate a large contiguous chunk and can't find unfragmented space for it, the sim is gonna CTD every time. It's the "physics" so to say of how applications work in Windows and DX9. Your video memory amount counts against the 4GB limit too because in order for FSX to address it, it has to be copied/shadowed into the application's VAS. We've had cases at support where people install 3GB video cards and the sim won't even run because it's sitting there with 1GB or less of addressable space after the video memory, which isn't enough to even load the sim and plane. If your crashes are a repeatable thing that's caused by doing something in the FMC or if it's the type of thing where the panel freezes but the sim keeps running, then it'll likely be solved in SP1. 

 

Sean Campbell

Share this post


Link to post
Share on other sites

Here's a post from Ryan a while back on the dangers of using video cards with large amount of onboard RAM. From what I have read the reason DX10 has eliminated OOMs for some, especially those who have 3gb or larger cards is that DX10 addresses the video memory differently than DX9 does. 

 

When I built my latest system I got a card with only 2gb of RAM knowing that I would most likely stick to using DX9. I've flown the T7 and NGX all over the world, sometimes leaving FSX running for 2 or three days in a row while in flight and never had an OOM. That's flying into addon sceneries like Dubai, LAX, JFK, etc., also with some photo scenery enabled in the scenery.cfg.

 

Ryan's quote comes from this thread, post 48-> http://forum.avsim.net/topic/349324-service-pack-better-be-good/page-2

 

 

 

 

Sean Campbell

excellent info, thx a bunch!

 

(not good News, but good to know)

Share this post


Link to post
Share on other sites

Here's a post from Ryan a while back on the dangers of using video cards with large amount of onboard RAM. From what I have read the reason DX10 has eliminated OOMs for some, especially those who have 3gb or larger cards is that DX10 addresses the video memory differently than DX9 does. 

 

When I built my latest system I got a card with only 2gb of RAM knowing that I would most likely stick to using DX9. I've flown the T7 and NGX all over the world, sometimes leaving FSX running for 2 or three days in a row while in flight and never had an OOM. That's flying into addon sceneries like Dubai, LAX, JFK, etc., also with some photo scenery enabled in the scenery.cfg.

 

Ryan's quote comes from this thread, post 48-> http://forum.avsim.net/topic/349324-service-pack-better-be-good/page-2

 

 

 

 

Sean Campbell

o.k. If I understand that correct than this means that FSX should not run with modern 4GB or 6GB cards in DX9 at all.

 

Is that true? Maybe someone with a Titan or R9 290x can comment on this.

 

I hope (and trust) that in P3D 2.0 this is no longer the case as it uses DX11.

Share this post


Link to post
Share on other sites

In a 64-bit OS the effect of VRAM on a 32-bit app such as FSX is negligible.  If you look in device manager you will see vram located a couple of times in 128Kb blocks - hardly significant.  However it does impact significantly in a 32-bit OS.  Mark Russinovich (Google) explains this very well.

 

The reason that the OP is seeing a rise in VAS usage has little to do with his/her video card - Phil Taylor on his FSX blog talks about this in great detail.  As FSX runs longer the VAS becomes more and more defragmented and the contiguous space fro FSX to load into becomes less and less - and in VMMAP that will show as an increase in VAS usage.  Eventually under certain circumstances even in a 64-bit OS you may get an OOM.

 

The statement above, I presume, refers to a 32-bit OS because there is little impact by the video card in a 64-bit OS eg Win 7 which has up to 8 TERABYTES of VAS to load into and can utilise any amount of VRAM without impacting on the 4GB VAS allocated to FSX.  Ryan's post is also out of date since WDDM v 1.1.

 

If there was any effect in a 64-bit OS by the VRAM on FSX using a video card with 4GB VRAM then FSX would never start it would be impossible as it would have NO VAS to load into.  Multiple and large monitors would also be out.

 

This has nothing to do with physical RAM installed.

 

PeterH

Share this post


Link to post
Share on other sites

As far as I understand the difference with DX9 vs DX10 is that DX9 requires to keep a copy of the information that's sent to VRAM in the regular RAM as well, eating up VAS, while DX10 doesn't need the copy in the RAM, it just moves the information.

Share this post


Link to post
Share on other sites

As I said in another post:

I don't believe that [graphics card total memory counts against VAS] is the case. A graphics card is a separate computer with its own processors and memory. there is no reason why FSX should need direct access to all the graphics card memory.

This view is supported by bhollis of Lockheed Martin said on the Prepar3D forum "a high end 2 GB card will likely run better than a low end 4GB card". The implication is that a high--end 4GB card would be even better.

Prepar3D (like FSX) is a 32-bit application which has a maximum of 4GB VAS on a 64-bit system. If all the graphics card memory counted against VAS then a 4GB would use it all and FSX/Prepar3D couldn't run at all. A 3GB card would leave only 1GB. A 2GB card would leave 2GB VAS which is the unsatisfactory amount FSX had on a 32-bit system.

 

Share this post


Link to post
Share on other sites

In a 64-bit OS the effect of VRAM on a 32-bit app such as FSX is negligible.  If you look in device manager you will see vram located a couple of times in 128Kb blocks - hardly significant.  However it does impact significantly in a 32-bit OS.  Mark Russinovich (Google) explains this very well.

 

The reason that the OP is seeing a rise in VAS usage has little to do with his/her video card - Phil Taylor on his FSX blog talks about this in great detail.  As FSX runs longer the VAS becomes more and more defragmented and the contiguous space fro FSX to load into becomes less and less - and in VMMAP that will show as an increase in VAS usage.  Eventually under certain circumstances even in a 64-bit OS you may get an OOM.

 

The statement above, I presume, refers to a 32-bit OS because there is little impact by the video card in a 64-bit OS eg Win 7 which has up to 8 TERABYTES of VAS to load into and can utilise any amount of VRAM without impacting on the 4GB VAS allocated to FSX.  Ryan's post is also out of date since WDDM v 1.1.

 

If there was any effect in a 64-bit OS by the VRAM on FSX using a video card with 4GB VRAM then FSX would never start it would be impossible as it would have NO VAS to load into.  Multiple and large monitors would also be out.

 

This has nothing to do with physical RAM installed.

 

PeterH

Thx for that very informative reply.

 

In the mean time another knowledgable, well known hardware/FSX source has confirmed that GPU memory is not mapped or shadowed in VAS when on Win7!

 

quote

Driver model was changed with Vista SP1/Windows7 and GPU memory is not mapped like it was with XP

 

VAS creeping up as the flight continues is normal. Time + scenery/aircraft is your enemy with FSX

unquote.

 

So the info and links above must have been old (its from 2011).

 

I am sorry for the confusement, but with one saying this and another that I decided to do some digging/asking around.

 

For me it is now a fact that GPU memory is NOT mapped in FSX VAS when you use above mentioned OS!

Share this post


Link to post
Share on other sites

 

 


VAS creeping up as the flight continues is normal.

 

I'm not sure I'd call that normal ... lets just say I'll disagree with Phil T. on this one ... with proper GC implementation the fragments can be recovered an organized so as to keep total VAS reduction at a minimum (still fragmentation but it will not grow excessively).  My hunch is FSX had too much legacy code or the design just didn't make it possible or desirable to implement GC (garbage collection) and/or performance considerations.  But if this were "normal" then 64bit games like Crysis 3 with 4096 textures would eventually consume all my RAM after a few hours ... this has never happened to me ... also think there are some mods out that push textures to 8192 for Crysis 3 (not sure how playable they are).

 

There definitely IS a fragmentation problem in FSX, easy to demonstrate - simply allow 4096 textures, load up an airport and/or aircraft that uses 4096 textures and then set a high LOD (9.5 or 11) and sit and do nothing and watch the VAS get consumed within a few minutes and OOM.  Now keep the same LOD and use 1024 textures and do nothing and the VAS will not get consumed and will stabilize (the smaller texture sizes aren't causing as much fragmentation).  IMHO, this is a clear demonstration of a fragmentation problem.  And like I said, there are solutions to fragmentation problems, they just aren't in FSX.  And I may not actually be in conflict with Phil's statement, as I'm sure he knows there are solutions but those solutions could be governed by time constraints, code compatibility, design constraints, and more which may have made it impractical to implement changes in FSX.

 

Texture size will contribute to VAS usage but it's still very much a function of software and how it's coded.  AA will not use VAS but it will use VRAM (vary based on the types of AA used and resolution).

 

So to answer the question, 4GB VRAM can use up all your VAS if the software is coded to do so.  The max VRAM usage I've seen FSX use just before it OOMs (>4GB VAS) was around 1.6-1.8 GB (VRAM).  But because you have 4GB VRAM on your video card doesn't mean VAS is automatically used/allocated by the software, but it will allow the software too run out of VAS because the VRAM is available.  I hope that makes sense.

 

Rob

Share this post


Link to post
Share on other sites

Rob

So to answer the question, 4GB VRAM can use up all your VAS if the software is coded to do so.  The max VRAM usage I've seen FSX use just before it OOMs (>4GB VAS) was around 1.6-1.8 GB (VRAM).  But because you have 4GB VRAM on your video card doesn't mean VAS is automatically used/allocated by the software, but it will allow the software too run out of VAS because the VRAM is available.  I hope that makes sense.

 

Sorry Rob - That can't happen there is no connection between VAS and VRAM in a 64-bit OS. 

Its the cpu that deals with the Video card sending data that has already been processed -  so the VAS doesn't know or care what's happening with VRAM. 

The problem with VAS in FSX has always been loss of contiguous space and defragmentation and that's caused by the way it has been coded and how it interacts with the OS then to the cpu and the working set.

 

The VRAM and physical RAM are part of the hardware and neither has a direct link to the VAS which is part of the OS.

pH

 

 

Share this post


Link to post
Share on other sites

 

 


Sorry Rob - That can't happen there is no connection between VAS and VRAM in a 64-bit OS. 
Its the cpu that deals with the Video card sending data that has already been processed -  so the VAS doesn't know or care what's happening with VRAM. 

 

No connection at all ... could you clarify?  VAS is virtualized but at some point their is a managed reference to the physical (managed by the OS).  There has to be a connection at some point?  

 

In my experience, increasing texture sizes from 1024, 2048, 4096 has increased VAS and VRAM usage.  

 

Would like to understand your comment better.  But agree my wording is perhaps lacking.  Completely agree that FSX fragmentation is a result of how it was coded.  

 

Cheers, Rob.

Share this post


Link to post
Share on other sites

Very interesting thread, so am I correct in saying I can go and buy a 780 GTX 4 GIGS and run it on my windows 7 64 bit without causing any issues with VAS (Running DX10 and based on what I just read above)

 

Regards
Wayne

Share this post


Link to post
Share on other sites

I agree with everyone regarding 64 bit operating systems, the whole issue with V ram dates back to when the bulk of simmers had a 32 bit OS. I remember when I had to pick my cards carefully due this limitation, with Win7 64 bit no issues.

Share this post


Link to post
Share on other sites

Very interesting thread, so am I correct in saying I can go and buy a 780 GTX 4 GIGS and run it on my windows 7 64 bit without causing any issues with VAS (Running DX10 and based on what I just read above)

 

Regards

Wayne

Yes. I am sure there are many out there today that use a 3Gb or 4Gb GPU but do not use 3Gb or 4Gb VAS right at startup of GSX.

Share this post


Link to post
Share on other sites

If defragmentation amd carbage collection is the problem then it sounds we need something like TRIM for FSX.

 

can this be done?

Share this post


Link to post
Share on other sites

Very interesting thread, so am I correct in saying I can go and buy a 780 GTX 4 GIGS and run it on my windows 7 64 bit without causing any issues with VAS (Running DX10 and based on what I just read above)

 

Regards

Wayne

+1

A very interesting and informative thread!

I hope though it is okay to ask as well:

Does a DX10 user need to worry about what has been mentioned here above if upgrading the graphiccard is being considered?

Cheers, Christoph

Share this post


Link to post
Share on other sites

+1

A very interesting and informative thread!

I hope though it is okay to ask as well:

Does a DX10 user need to worry about what has been mentioned here above if upgrading the graphiccard is being considered?

Cheers, Christoph

I am not a DX10 user but I am going to say No to that.

 

GPU memory size has not influence on FSX DX10 mode VAS nor FSX DX9 mode VAS.

 

Soem DX10 users have reported that VAS is taxed less under DX10 than under DX9 (which is good for you).

 

However it would be nice if some of the very knowledgeable people in this thread could confirm or unconfirm this.

Share this post


Link to post
Share on other sites

 

 


There definitely IS a fragmentation problem in FSX, easy to demonstrate - simply allow 4096 textures, load up an airport and/or aircraft that uses 4096 textures

 

I've no doubt that is the case, but according to the FSX SDK "For Aircraft, texture maps cannot currently exceed 1024x1024 pixels in size..."  Maybe there was a reason for that?

Share this post


Link to post
Share on other sites

Very interesting thread, so am I correct in saying I can go and buy a 780 GTX 4 GIGS and run it on my windows 7 64 bit without causing any issues with VAS (Running DX10 and based on what I just read above)

 

Regards

Wayne

Yes...I use a 4GB GTX680 in Win7 x64...no OOM issues here.

 

Cheers

Share this post


Link to post
Share on other sites

Yes...I use a 4GB GTX680 in Win7 x64...no OOM issues here.

That puts it to bed them.

 

Graphics memory doesn't count against application VAS. If it did there'd have been no VAS left for FSX.

Share this post


Link to post
Share on other sites

Will a person with a high end computer hardware run out of VAS at the same rate as someone with a lower end system assuming they run all the same addons and everything else is identical?

Share this post


Link to post
Share on other sites

I think perhaps this mis-conception is my fault ... because a video card has more VRAM it doesn't take away VAS on a more modern OS (including Windows 32bit).  

 

Can read more about it here:  http://msdn.microsoft.com/en-us/library/windows/desktop/aa366912(v=vs.85).aspx  32bit

and here: http://msdn.microsoft.com/en-us/library/windows/desktop/aa384271(v=vs.85).aspx 64bit

 

 

 

A virtual address does not represent the actual physical location of an object in memory; instead, the system maintains apage table for each process, which is an internal data structure used to translate virtual addresses into their corresponding physical addresses. Each time a thread references an address, the system translates the virtual address to a physical address.

 

As for fragmentation, look into Hoard or Maged Michael memory allocation implementations.

Share this post


Link to post
Share on other sites

I am not a DX10 user but I am going to say No to that.

 

GPU memory size has not influence on FSX DX10 mode VAS nor FSX DX9 mode VAS.

 

Soem DX10 users have reported that VAS is taxed less under DX10 than under DX9 (which is good for you).

 

However it would be nice if some of the very knowledgeable people in this thread could confirm or unconfirm this.

 

 

Yes...I use a 4GB GTX680 in Win7 x64...no OOM issues here.

 

Cheers

 

Thank You both very much for Your replies!

Well then i may seriously consider upgrading my GPU and stay with DX10 as i already do now!

Thank You very much again for the info!

Cheers, Christoph

Share this post


Link to post
Share on other sites

Thank You both very much for Your replies!

Well then i may seriously consider upgrading my GPU and stay with DX10 as i already do now!

Thank You very much again for the info!

Cheers, Christoph

I am not sure ugrading from a GTX580 to a GTX780 on your CPU will do you much good. (things might even become worse!)

 

It makes more sence to couple a GTX780 with an (overclocked) i7 4770k

Share this post


Link to post
Share on other sites

Can read more about it here

Those links refer to VAS in general - not the way in which a graphics card uses it.

 

This link is helpful

 

http://msdn.microsoft.com/en-us/library/windows/hardware/gg487348.aspx

 

Dedicated graphics memory, as the name suggests, is memory that is available for exclusive use by the graphics subsystem. Non-graphics applications and other subsystems in the operating system cannot access this type of memory. An example of dedicated graphics memory is the memory that is physically present on the “discrete” graphics adapter. This has been commonly referred to as “on-board” or “local video memory”—that is, close to the graphics processing unit (GPU). Dedicated memory, however, isn’t limited to on-board memory. A portion of system memory can also be dedicated to the graphics subsystem. This portion of system memory is never available to other subsystems or applications and is exclusively owned by the graphics subsystem.

 

Shared system memory is a portion of the system memory that can be used by the graphics subsystem when needed. For discrete graphics adapters, this type of memory is often referred to as “non-local video memory”—that is, far from the GPU. The shared memory is available to other subsystems or non-graphics applications when it is not being used by the graphics subsystem. Thus, it is never guaranteed to be available for graphics because it could already be in use.

 

 

I checked the memory used by my 1Gb graphics card and found:

 

Total Memory 2814 Mb

Dedicated Memory 1024 Mb

System Video Memory 0 Mb

Shared system Memory 1791 Mb

 

This shows the card isn't taking up any exclusive system memory.

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